Sunday, 1 July 2007

Thinking About Port Knocking

In a previous post I described how I'd tweaked my server's security with respect to SSH and Webmin however I really wanted to make it more difficult for a potential abuser to get anywhere near them. I also wanted, if possible, to rid my Logwatch reports of the hundreds (sometimes thousands) of lines reporting failed attempts to log in via SSH.

Using a non-standard port for these services is a commonly suggested 'solution' but while this may throw most of the current crop of bots off the scent, any half-serious hacker can easily do a port scan first. You can also be fairly certain that if the bots aren't currently doing a preliminary scan, it's only a matter of time before they will. Thus using a non-standard port is little more than a temporary side-stepping of the problem. Should you opt to try it, don't forget to open the new port in your firewall first or you'll lock yourself out of your server.

Secure Authentication - setting things up so that your computer authenticates itself to the server rather than logging in with a password - means you can then disable the ability to make connection by logging in with a password and this is very cool option so long as you don't find yourself away from home, needing to log into your server from another machine, and without your authentication keys on a memory stick.

Other solutions that I've seen use programs like fail2ban or denyhosts to scan logs and act upon what they find. Typically they'll scan the logs at a 20 minute intervals and block any IP address that has tried and failed to log in more than a specified number of times. As I see it, the problems with this type of approach is that you'll still see numerous attempts taking place because the IP address isn't blocked until the log scan takes place.

pam_abl, an addition to PAM, looks for repeated failures to log in and if a given IP address fails more than X times in Y seconds, it gets banned. This has a more immediate effect however the info I saw suggested that the bans were permanent and that's not what I want. Any defence mechanism that blocks IP addresses should also ensure that they are unblocked a short while later because if the attacker is logged into the web via an IP addess allocated from a pool at AOL or attacking via a hacked server, then you could end up blocking legitimate traffic when the address has been reallocated, or the server being sorted out. I guess using a cron job to unblock them would be an option.

Port knocking - a scheme by which you have to 'knock' on a number of prespecified ports in a set sequence in order to open another port - had an immediate appeal because the knock cab be carried out with something as commonly available as Telnet so getting access while away from your normal machine merely requires that you remember the port numbers. Wikipedia has a good article on port knocking with links to an article explaining how to do it using iptables (although you need to have the ipt_recent module loaded to do it).

However, while discussion port knocking over at the Fedora project forums (click here to see the topic), sej7278 suggested that you could use something on a webpage to trigger the opening an closing of a port. Further to that it occurred to me that you could use a url that was normally used for something else. For example, if the front page of my site were:

I could use:

to open SSH. All I'd need to do is to make the index.php script look for the additional parameters and use exec() to issue the command to open the port.

I'll explain how that works in a later post however for now I would just like to say to any crackers who may be reading this:

1. The front page of my site is not index.php and I'm not using a page at so you'll have to start by guessing the name an location of the .php file that I'm using. Note that there's no reason for the page to be linked into the rest of the site so you'll have to guess.

2. I wouldn't be so stupid as to use something as simple as open_port=22 and publish it here. So if you do manage to find the .php file, you'll need to guess what parameters are needed to trigger it. Note that there's no need for the parameter name and value to make any sense to anybody or anything other than myself and the .php script that's watching for it.

3. Probably your best bet for finding the above to monitor the network traffic to my server but even if you do find it, you will then need to figure out my SSH user login name, password, and root password (as described in my earlier post you can't just log in as root), and any failed attempts will be show up in my Logwatch report thus alerting me that you've found my port opener, and prompting me to change it.

No comments: