Port Knocking

[LuAn]

I'm interested in using port knocking to open and close access to SSH and Webmin.

Now before somebody tells me that port knocking is no substitute for good passwords: I don't want to use it as a substitute. I already have good passwords. What I want is to block brute force attempts to gain entry before they even get to the point of trying to guess passwords and get all of those failed login attempts out of my Logwatch reports.

I've seen numerous references to "knockd" but no mention of it since 2006 and Core 4. Is it still valid to use it for Core 6?

[xDamox]

Hi LuAn,

Here is a guide on performing Port knocking with iptables:

http://www.debian-administration.org/articles/268

[marcrblevins]

Just install denyhosts.

[The_Jaymz]

Just install denyhosts.

I agree with marcrblevins.

[LuAn]

I took a quick look at denyhosts. Correct me if I'm wrong, but it works by checking the logs for offenders and blocking their IP address.

1. By the time it checks the log there could already be dozens of attempts from a given IP address.

2. As the IP addresses being used change regularly, denyhost will end up building an ever increasing list of addresses to block without stopping the attacks as they are taking place.

3. If any attacks come from somebody logged into AOL, Tiscali, or some other major ISP who allocates addresses from a pool denyhosts will be blocking addresses that could easily be allocated to other legitimate users at other times.

4. denyhosts seems to be aimed squarely at SSH but I also want to stop attempts to get in via Webmin.


@xDamox: That looks interesting but I don't know enough about iptables to be able to understand it. I guess I could copy, paste, and change the port addresses being used for the knock but I'd need to modify it to do the same thing for Webmin. I guess I need to do some reading about iptables but if you happen to know how to do that...

[sej7278]

yeah i agree with luan, denyhosts is a bit simplistic, it can lock out legitimate users and fill your logs with dynamic ip's from attacks - ddos'd by your own software? no thanks!

but i'm not at all keen on having webmin exposed to the world even with port knocking, i hope you're at least using ssl (https). i think i'd prefer to forward x11 over ssh and launch firefox locally, or just learn the commands and issue them over ssh, not via a web interface.

i've used port knocking and there's various implementations, the one i've got on debian has a really unreliable knockd which constantly dies leaving me locked out, so i'd avoid that one. there's some nice ones that you have to hack a packet payload as well as a range of ports to knock - so that a portscan doesn't accidently open your firewall.

[LuAn]

i hope you're at least using ssl (https).

I am.

so that a portscan doesn't accidently open your firewall.

A lot of examples use a sequence of ports. For example the one using iptables above uses 100, 200, 300, 400. A port scanner that's being used for 'legitimate' purposes will work in sequence (easier to program) and while it might 'stumble' on a sequence like that it would not stumble on 200, 400, 300, 100.

To find a sequence like 200, 400, 300, 100 a scanner would have to be trying ports at random in an attempt to find a knock. Of course there is no response from the system to say that a knock has worked so the cracker also needs to keep trying port 22 (within the 5 seconds that the port is opened by the knock).

Now let's say the cracker gets really lucky, finds your knock sequence and realises that port 22 is open: they can now guess at a username and password, and if they get it wrong, the failed attempt shows up in your logwatch report the next morning.

Bearing in mind that after inspalling port knocking there are only two reasons for a failed attempt:

1. you or one of your legitimate SSH users botched their login.

2. a cracker has discovered your knock sequence and is trying to break in.

In the case of the first you'll probably see a single failed attempt in your logwatch report whereas in the second you'll see a number of failed attempts as the cracker tries to get past your next line of defence (your passwords). This is your cue to change the knock sequence and send the cracker right back to square one.

Of course the two things you should not do with port knocking are:

1. use a knock to run an important command/script i.e. one that would cause problems if it did get triggered accidentally.

2. use a knock to open a port permanently (just open it long enough for a legit user to get in and then close it again).

[LuAn]

This morning I got a particularly good example of what I am wanting to stop:

My Logwatch report this morning tells me that there were 16721 failed attempts to SSH into one of my servers in the last 24 hours. 14179 were from a server in France that I've never seen before and 14161 of the attempts from that server were to log in as root.

They are all bouncing off. root is not allowed to log into my server with SSH. In fact there is only one user allowed in with SSH and that's a special user with a name that looks like a password (it's a random mix of numbers and letters). It'd take you a hundred years to guess the user name, another hundred to guess the password, and another hundred to guess the password to su to a user who had rights to actually do anything.

Something like denyhosts would have reduced the number of attempts but there would still have been a heck of a lot before it took action. On the other hand, port knocking, if I had it in place, would have blocked every single one of them.

[The_Jaymz]

This morning I got a particularly good example of what I am wanting to stop:

My Logwatch report this morning tells me that there were 16721 failed attempts to SSH into one of my servers in the last 24 hours. 14179 were from a server in France that I've never seen before and 14161 of the attempts from that server were to log in as root.

They are all bouncing off. root is not allowed to log into my server with SSH. In fact there is only one user allowed in with SSH and that's a special user with a name that looks like a password (it's a random mix of numbers and letters). It'd take you a hundred years to guess the user name, another hundred to guess the password, and another hundred to guess the password to su to a user who had rights to actually do anything.

Something like denyhosts would have reduced the number of attempts but there would still have been a heck of a lot before it took action. On the other hand, port knocking, if I had it in place, would have blocked every single one of them.

A heck of a lot? Not really, you can set denyhosts to start blocking after just 1 failed root login. Mine is set to block after 3 failed root logins, 5 regular user or 3 non existent users. It can also download IP addy's that attack others, you might not have been hit at all.

[LuAn]

A heck of a lot? Not really, you can set denyhosts to start blocking after just 1 failed root login. Mine is set to block after 3 failed root logins, 5 regular user or 3 non existent users. It can also download IP addy's that attack others, you might not have been hit at all.

As I understand it, denyhosts is not running constantly and you use cron to run it every 20 minutes or so. When an attack begins you therefore have a dely before denyhosts sees it and a large number of attacks could take place in that time.

I don't like the idea of blocking IPs that have attacked others. An IP address rarely equate to just one person/website. It could be a server that thousands of people connect through. It could be that just one of those people is bad. Or it could be that the server has been hacked and is temporarily bad. Blocking an IP address on the grounds that somebody else had a problem with it is like refusing to do business with anybody called Smith because a mate of yours was once ripped off by a guy called Simth.

[The_Jaymz]

You're right. It doesn't run constantly, but I don't think it's a cron job. It's setup as a service if you install it with yum. You just set the conf file to how often you want it to parse your log file. As for blocking IP which are dynamically assigned, you can set it to remove IPs from the hosts.deny file after a certain amount of time.
If I sound like a denyhosts zealot, I don't mean to. You have a few options: Connect the way you normally would, and have something to temporarily block hosts that are trying dictionary attacks, or you could use port knocking and use a different method to connect. You could also move the port to a non standard number. I worked for a company who had sshd restart at midnight and the port was changed to the first 4 digits of cosine of the date in DDMMYYYY format. If I were really concerned about unauthorized access, I think I might setup a VPN and only allow connections from the LAN.

[LuAn]

It doesn't run constantly, but I don't think it's a cron job.

I'm not sure. I've not read everything over at their site but I got the impression that it uses cron from this: http://denyhosts.sourceforge.net/faq.html#2_1

If I sound like a denyhosts zealot, I don't mean to.

Absolutely no problem. Always good to be made aware of useful kit and although I don't think denyhosts is the right thing for me in this situation I can see how it could be useful. I have the luxury of being the only person who needs to SSH into my server. Now if there were dozens of us who needed to so it and all needed to know things like which ports to access/knock, then I dare say that denyhosts would be my tool of choice.

I worked for a company who had sshd restart at midnight and the port was changed to the first 4 digits of cosine of the date in DDMMYYYY format.

The trouble is that these things all 'advance'. At the moment, changing the port will throw a lot of bots off the scent. However as more and more people do that the bots will 'advance' such that they do a port scan first.

[sej7278]

luan i think that's why you should use a combination of methods:

no root ssh - root is an easy username for brute force dictionary attacks, and don't use a regular username like your name - use something weird like "%^gdfgYsd" and su to your user once you're logged in.

put ssh on a high port - most port scans are just tcp/1024 or below, looking at 22 for ssh.

use denyhosts if you don't mind the possibility of locking out dynamic dns users, but don't rely on it i'd say. or if you know the fixed ip's of users, then setup an acl that only allows in from those whitelisted ip's.

don't use passwords, only pre-shared keys for ssh, with passphrases. make sure it's ssh2 not ssh1.

use port knocking but not on sequential ports, hell use udp instead of tcp, most portscans don't bother with udp as its slow/unreliable to scan, maybe use a packet payload too, or make the ports change based on the phase of the moon or something - this will stop packet sniffers noticing that you seem to connect to a pattern of ports a lot, which is the main problem with knocking.

you could even do something homebrew like have a (https) web page that you have to type something into or do something to, like click a hidden image or click buttons in a certain order to fire up the ssh daemon, so it's not running unless you need it.

[LuAn]

no root ssh - root is an easy username for brute force dictionary attacks, and don't use a regular username like your name - use something weird like "%^gdfgYsd" and su to your user once you're logged in.

I'm already doing that however I prefer something more memorable such as "mH1lL3Fww1S"

That's "Mary had a little lamb, it's fleece was white as snow". The 1st, 2nd, 3rd, 5th, 7th, and 11th characters get converted to upper case (because they are prime numbers) except for the first one which was already upper case and goes back to being lower case. Vowels are then converted to numbers such that aeiou = 12345. Of course you should choose your own memborable phrases and your own techniques for turning them into a password, and by the way: I just made that one up as an example so don't anyone bother trying to get in my server with it. ;-)

don't use passwords, only pre-shared keys

I like the idea of preshared keys but it means you have to use the same computer or carry they keys around with you on a memory stick. With a port knock however you just need to remember what ports to use and remember your passwords and you can access it from anywhere should the need arise.

portscans don't bother with udp as its slow/unreliable to scan, maybe use a packet payload too, or make the ports change based on the phase of the moon or something - this will stop packet sniffers noticing that you seem to connect to a pattern of ports a lot, which is the main problem with knocking.

I really don't see port scans as a problem so long as the ports you are using are not in any sequences i.e. low number, higher number, even higher number. A port scan will run through in sequence. If it jumps about randomly the odds of it stumbing on the knock sequence as miniscule. And even if they do get that for you'll see the subsequent attempts to crack your password in your logs and can change the ports.

you could even do something homebrew like have a (https) web page that you have to type something into or do something to, like click a hidden image or click buttons in a certain order to fire up the ssh daemon, so it's not running unless you need it.

Now I LIKE that idea.

Just be wary what you mean by things like 'hidden image' however. Remember that bots don't see pages the way we do. I actually use that to trap bots that ignore robots.txt and go into directories that I've told them to stay out of. I have .html files with 'blank' links at the top. By blank I mean like <a href="/trap.php></a>
With no space between the tags there's nothing for a human to click however a bot will see the link and follow it. trap.php then updates .htaccess to block that IP address for a while.

I've used a technique with some of my ecommerce systems such that I can place a test order by typing a specific name and address into the delivery details. Basically the code checks for that name and address. If it doesn't see them it knows it's a real customer placing a real order. If it sees them it knows it's me doing a test and doesn't try to charge my credit card.

I guess I could use something like a contact form, that would normally be filled in to send me a message, and get it to open a port if a specific message was entered. It wouldn't even need to be https:

sej7278, you're a genius. ;-)

[sideways]

Port Knocking sounds pretty cool, thanks for the info everyone. The wikipeia article has links to setting it up using iptables.

I don't see why you should limit the behaviour to just unlocking ports. You could code in two sequences, the first fires up the sshd damon and the second opens the port, a cracker would then have to guess two sequences, and in the correct order.

Having said that, you need to carry around the client connection script in a usb stick or floppy etc unless you are using a very simple and memorable sequence, the wiki article suggests dynamic and cryptographic algorithms are being favoured.