what are some things I may not be considering when setting up a web server running linux (ubuntu 14.04)
this is on a VPS on ramnode
- apache
- php
- mysql
random other shit like curl and etc, sendmail... nothing insane. FTP disabled (sftp/ssh only).
root has insane password, I have a user account w/ sudo, everything else runs on specific users.
databases are all single-user/db with local access only (no pw)
installed fail2ban to block random nignogs from ddos'ing
not a noob but not super elite when it comes to server admin crap, especially network shit
https://github.com/lfit/itpol/blob/master/linux-workstation-security.md
install openvpn onto your server, use ANY service that is only in use by you by tunnel and most important, allow ssh connections only from tunnel. this makes you pretty much invulnerable against ssh attacks.
take care of using right permissions, especially if you have multiple users.
take care of your software being up to date, for example i would never ever install nginx from the repos, it's 1.6. something. instead, you just compile the newest version.
take care of configuring your services the right way, read your way into every single service that is running on an open port.
you may want to install a firewall, not only for blocking incoming connections but for outgoing, so just in case someone was able to break in, he wouldn't be able to start some crap.
running rkhunter periodically is also not a bad idea to check if your system was infiltrated.
>>51960775
this is nice but I'm looking for tips for a public-facing server more than a workstation.
(pleb I know) all of my "workstations" are OS X. one is ubuntu but it's just an old laptop for backup.
>>51960718
Disable root login, use Keys for ssh access, setup permissions, install IDS and configure it right, automate updates, configure firewall, secure DBs, secure tour webserver against exploits or vulns, harden your OS, any ddos will lock up your server with fail2ban(resources) use proper firewalling rules for small TCP ddos attacks, if possible drop udp upstream (might not be possible depends on the ISP/hoster )
>>51960946
Most important, automate log warning / reading if something happends you'll be informed by e-mail or message
>>51960718
set unattended-upgrades up
>root as insane password
disable remote root login
disable password auth
use pub key auth
>databases with local access only (no pw)
you should still put a password on it
>>51960718
Fail2ban doesn't block ddos attacks, it makes them worse.
>>51961387
how so? I thought it blocked IPs that have failed logins...?
>>51961452
Go read wikipedia on what a ddos is, please.
>>51961452
The purpose of a ddos attack is to either use up your bandwidth, against which local blocking does nothing, or drain system resources, like memory.
You're suggesting adding a daemon that spends a bit of ram does a little cpu cycle dance for every new ip that contacts you, while you're being flooded from a fuckton different addresses at once?
the ddos attacks I see are technically from real IPs, they're not fake.
isn't there some way to block/ignore connections that don't answer back? I remember back in the day there were SYN packet floods...? rusty on this shit.
>>51961539
>>51961562
You can still try to block lowlevel TCP ddos by rate limiting in firewall ( this will consume recourses ofc )
Higher level ddos you will need a mitigation platform and they can be pretty costy
>>51961562
Pf can do syn proxying, which means it handles connection setup itself and doesn't forward anything to the server until the 3 way handshake is complete.
