Locking down my Ubuntu server with UFW

Question

I'm using Ubuntu 12.04 on an Amazon EC2 instance and new to the sysadmin side of things. I'm working on a little project of my own and I'm already starting to get targeted by bots (at least I hope they're bots).

I'm using PHP and in my error logs I noticed w00tw00t romanian anti-sec and /w00tw00t.at.blackhats.romanian.anti-sec:. I googled and I found several results such as this and this which both state it's most likely just some bots. They were looking for variations of PHPMyAdmin, PMA, MyAdmin. From what I can tell, they did not find anything and only got some 404 errors. As far as PHPMyAdmin goes, I'm using an alias and I have access restricted to a couple of IP addresses.

Currently I'm running UFW and I have these rules

To                         Action      From
--                         ------      ----
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
22                         ALLOW       MY.IP.ADDRESS1
22                         ALLOW       MY.IP.ADDRESS2
22                         ALLOW       MY.IP.ADDRESS3
80                         ALLOW       Anywhere (v6)
443                        ALLOW       Anywhere (v6)

All of the tutorials I've seen on UFW just say how to set it up, not suggestions on the configuration itself. Basically I use SFTP and SSH (with a key pair) to work on my server. Are there any rules that are a must have that I am missing?

Answer 1

I don't see how you would possibly use UFW to avoid these types of attacks.

If everything but 80/443 is denied to public access and you have specified only a few specific IPs for ssh access, then the problem lies with your application, not the network configuration.

Don't even touch firewall rules in this instance.

You need to protect yourself from:

• Weak passwords
• Obvious "Admin page" links, ie. website.com/admin, website.com/phpmyadmin
• Passwords embedded in your code
• SQL injections and other various web code/database vulnerabilities.

To further your server security, you can make Apache run chroot'ed, so that it is separated from the core system by a virtual layer.

You could also implement FIM(file integrity management) to ensure that files that aren't meant to change don't get changed (example: the apache/php config)

or you could write a script to log all commands run by root/apache, and send it out by email periodically.

Things like that are what you should look at once you've set up your firewall (which you have done)

Answer 2

All seeing w00tw00t traffic in your logs means exactly what you are seeing: You are bring probed by a script of some sort. I would not make that big a deal of it, but if you are truly concerned then using iptables & ufw won’t really help.

Since it seems like you are running a web server, I would recommend using ModSecurity instead.

Ubuntu has a package in the repo for ModSecurity, but it’s core ruleset (CRS) is out of date. So I would recommend downloading that here.

Which leads us down a rabbit hole of: ModSecurity is not that easy to setup for novices. I have done it tons of times, but even when it is running there are issues you need to be aware of. Like the fact that since ModSecurity operates heuristically & monitors web traffic, then sometimes expected behavior on your web server will be blocked due to a “false positive” popping up.

Which is all to say, you might be in a scenario where you really do not need to worry about anything yet. Web servers—and every server—is scanned all the time. Depending on what you are doing with that server, the best & most real security is to ensure your front-facing applications are secure. And if you are coding your own PHP codebase, you can be pretty much assured you are safe.

If you are using some off-the-shelf software like WordPress or Joomla!, my best advice is to do this: Simply place Apache web authorization passwords on the administration URLs/paths for your CMS. Seriously, this is one of the best security measures out there. Scripts that probe sites generally look for flaws in the scripting (PHP, Perl, Ruby, etc…) coding but by placing an Apacce web authorization password in place, you have pretty much blocked a good chunk of the of the scripts out there. The negative of this approach is now you have to remember your password for the CMS as well as the Apache password, but that is a trivial inconvenience compared to having your system compromised.

Answer 3

Probably the best way to protect yourself from control panel scanning is to not run a web control panel. If you can avoid doing that, you can totally ignore these attacks.

Another thing you can do to protect yourself from common attacks is to set up a VPN, and restrict access to administrative services (SSH, control panels, etc.) to IP addresses on that VPN. Use your firewall to make sure such traffic actually does come from the VPN and is not spoofed (eg. discard traffic bound for the VPN interface from the WAN).

If you use strong passwords, keep your applications up to date, use least-privilege users for daemons, and follow best practices like those, you have nothing to worry about from these types of automated attacks at all.

Keep in mind that there is no set of magic firewall rules, and a firewall can't protect you from a great deal of things. They were designed to keep "internal" services inaccessible to the public WAN (see my point about the VPN), and you can use them to discard certain types of traffic that would otherwise breach a security boundary, but they don't work at the application layer and you can't use this to secure your web applications.