A door with no keyhole: port knocking at work

| | No TrackBacks
Door knocker

Standard vs. non-standard ports

The first problem system administrator face when setting any server accessible from Internet is to handle all the 'hackers' attacks, those aimed at gaining access via SSH and other means.

My experience shows that even if domain name was never exposed on the Net, it starts being under constant «knocking» almost immediately.

First, it is annoying.

Second, if there are users with weak passwords, it's constant security risk. No matter how much are the users held responsible, system administrators will have to clean the mess.

The simplest approach, when intruder is banned (firewalled) by IP after certain number of connection attempts isn't the ideal solution: IP addresses may also be spoofed, and a malevolent user may effectively block legitimate access from a given IP(s).

One of simplest solution is to use non-standard port numbers for standard services. They should be chosen wisely, in order not to interfere with other well-known services using the same port number. Also,when and if the «secret» port is leaked, we return to the original problem and should either choose another port number, or use another approach altogether.

Port scanning can also nullify the efficiency of non-standard ports, if connection isn't restricted to only known IP addresses («strict whitelisting»).

Port knocking

There's a solution, named port knocking. In short: it means the process/person wishing to connect, first tries to connect to a known sequence of ports («knocks»); if it knocked correct, its IP is granted right to connect to, say, SSH port.

The method is both simple and complex, has its advantages and disadvantages.

To implement port knocking in case of, say, iptables (netfilter) a special module can be used. Otherwise, a special daemon process may monitor firewall logs and, when detecting knocking, add (temporarily) a rule allowing connections for the knocking IP. The rule should be removed when the connection session ends.

The major disadvantage is this: if the watching daemon dies and/or starts to malfunction, you are effectively locked out of your server. Also, the knocking attempts may be recorded in logs in different order (although this is not a major problem, if the exact sequence isn't important).

My further experiments allowed me to admit that a «hybrid» security approach can be used in most cases.

First, I add permanent rule to allow connections from certain IPs (namely, the IPs of computers I mostly work at). That saves me from the worst scenario, when port-knocking daemon process dies for some reason and can't be automatically restarted.

Second, I set up a daemon process monitoring port knocking access able to restart/reload the control process if necessary.

Third, I use non-trivial unused unassigned port numbers.

Fourth, to prevent my administrative IPs spoofing I use encryption to prevent IP spoofing (to ensure it is me having initiated the connection).

So far, the method allows to ward off most of «knockers» wishing to find a weak password.

Perhaps you could suggest even more secure, yet still reliable and not-too complex scheme?

No TrackBacks

TrackBack URL: /blog/mt-tb.cgi/92

blog comments powered by Disqus

About this Entry

This page contains a single entry by Konstantin Boyandin published on March 15, 2010 2:59 PM.

Reliable email service: keep everything in order was the previous entry in this blog.

Can you spell 'password' or The weakest link in security is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.