Protecting your startup's server from attacks
Mar 30 2011 :: by Alex
Our server that powers the support ticket system
was kinda hacked the other day. The attacker has obtained an FTP password for one of our servers and was able to download some stuff - thank God nothing critical... While I'll save the details on the attack for my next blog post (this is quite a story
actually! hackers have fooled our hosting company submitting a fake support request), I'm going to share some knowledge I've accumulated during the last couple of days dealing with the consequences.
NB: my small company is powered by a bunch of Windows 2008 R2 servers, but some of these recommendations should fit any platform, not just Windows.
So, here we go. The steps I took to protect my VPS server from future attacks:
P.S. Dear attacker! If you're reading this - please let us know what you were looking for. Why not just send us a note and we'll give you what you need - for free... We provide free versions of our software to bloggers, non-profit organizations, we give away huge discounts etc. etc. We're a small friendly company, let's talk :)
- Set up the lockout policy. By default your windows-server is not protected from a brute-force attack. An attacker, for instance, can open a thousand RDP (Remote Desktop) connections trying different username/password combinations...
That's why you must set up the lockout policy for your server. Open "Start - Run - secpol.msc - Security Settings - Account Policies - Account Lockout Policy". Set it to "5 times" and "5 minutes" for example - this will block an account for 5 minutes after 5 invalid login attempts.
- Disable the "support user". If you rent a server, very likely there'll be a support user account for your hosting provider's tech team. Disable it. Sometimes the security is compromised by the hoster's staff (mine was).
- No FTP unless required. Disable FTP, SMTP and other unneeded services unless your customers/applications really need it. Enable the FTP only when you're actually uploading files onto the server and limit it to your IP address.
- Install a nice password manager. You'd be surprised how many people go for the "one password for everything" mode. Even some geeky tech nerds I know, even programmers and system administrators... Don't. Even the service accounts & database-users must have unique strong generated passwords only. I prefer the "LastPass" manager which is available as a Chrome extension, and it saved me a ton of headache.
- Backup. Backup. Backup. Backup. Both on-site and off-site. Create daily backup-jobs on your SQL server to backup your databases both locally and online. Even if you're running the free Express version of MS SQL Server there are still ways to create periodic "jobs".
Here's our configuration: all databases are backed up twice a day - locally, and twice a week - to an online storage. For the online storage we use Microsoft SkyDrive, it offers 25 gigs of free space (which is pretty amazing) and comes with a sync tool. Another similar option to consider would be DropBox of course.
- Firewall is a must. You can use the Windows Server 2008 built-in
firewall, it's pretty good for a start, and then upgrade to something more sophisticated later. The rule of thumb here is - DISABLE EVERYTHING. Leave ports 80 and 443 open - and that's it.
- Don't use standard ports. If you need anything beside the web-server open to the public (e.g. SQL server, terminal services) - then move the applications to non-standard ports, some weird number like 15089 etc.
The Terminal Services (RDP) port can be changed in the registry, at "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber" (remember to restart the RDP service and allow incoming connections on the firewall).
SQL Server ports can be adjusted in the "SQL Server Configuration Manager" tool - "Network Configuraion" - "Protocols for [INSTANCENAME]" - "TCP-IP" - right-click - "Properties".
- No "/admin/" folder or other standard names. Your website's CMS folder should not be named "http://www.website.com/admin/". Your admin user should not be named "administrator". The login page for ASP.NET forms authentication should not be named "login.aspx". Etc.. You get the point.
by Alex. CEO, founder