Welcome to Dirteam.com/ActiveDir.org Blogs Sign in | Join | Help

Paul's Holy Bible Of Everything

About projectmanagement, people and all those annoying aspects of life that get in the way of achieving anything.

Knock knock!

I've always been taught that knocking before entering a room is the polite and correct thing to do. Surely, this has in the past proved to be quite worthwhile, preventing me from wandering in on one or two rather disturbing scenarios. Silly as it may sound, when it comes to IT security, the same principle can be applied.

In the past years, remote management has become an everyday event. In environments where a small number of people are supposed to administer infrastructures that are well beyond their physical reach. there's nothing more normal than opening up an SSH, RDP or VNC connection to the remote system involved. All it requires is a simple client, a network connection and a firewall that accepts the incoming traffic and sends it on to the receiving system.

However, even though we consider protocols such as SSH to be rather secure, it is not unthinkable that any of these more 'secure' protocols contains a bug that will allow a malevolent attacker to gain access to our precious systems. Still, counting this as one of the cons of such a configuration, the requirement of administrative access often overrules any objections from the security corner. Sure, we can also decide to use static IP-addresses, limiting the number of stations that could gain access to the administrative entrance, but seeing how spoofing an IP-address isn't exactly the hardest task in the world, this doesn't give us the reassurance we'd like.

In an ideal world, we wouldn't want any ports listening on our firewalls. Drop all incoming traffic, no response, nothing. Our firewall would be a lovely black hole that wouldn't reveal anything and most certainly wouldn't allow anything; a firewall administrator's wet dream, perhaps ?

But what if we were to require remote access to a system ? As our firewall wouldn't be listening on any port, gaining access to the server behind it would become rather difficult indeed. Ideally, we'd allow the incoming traffic to pass through only when we'd desire so.

This is where the concept of knocking comes in handy; port-knocking. Knock on the correct ports and tada, our inbound SSH would be allowed! After a certain period of time, or even another knocking sequence, the firewall'd stop listening again. Is this possible ? It most certainly is.

So how does this work ?

Imagine a firewall that monitors all incoming traffic, not accepting any to pass through. Our client, eager to gain access to the system behind the firewall, sends a series of SYN packets to a set of predetermined ports (called the 'knock'). A daemon running on the firewall intercepts the data and recognizes the correct sequence of ports (say, ports 2000, 3000, 2500 and 1500 in that specific order). Naturally, other criteria could be added to the concept (source IP, packet data, etc), but for now, we'll stick to port-order. Authenticating the knock as genuine, the daemon can then fulfill a specific task, such as, say.. allowing incoming SSH-traffic to pass through to our server! Additionaly, we could specify the connection to stay open for a certain amount of time, or stay open indefinitely until a knock was sent that'd order the daemon to close the port again.

The concept of port-knocking itself isn't new; being used as a hardening technique in *nix systems for quite some time now, plenty of implementations are available. Some using the firewall logs, others more closely connected with the server's IP stack, there are various ways to accomplish this task. As it requires a lot of inside information to gain access with a knock, it is considered to be a very valid hardening technique.

Unfortunately, as far as I know, an implementation of this concept isn't available for ISA 2004; I might try to write one myself when the time for it presents itself, though I doubt I'll be able to write one that doesn't use the logfiles.

Oh yes, there is one pitfall to be taken into account: When choosing the order of ports, do NOT, for example, select the following sequence:

2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010

If it's not obvious to you why this is a particularly bad sequence to pick, I'd advise you to read up on the concept of portscanning..
Oh. And just like the common courtesy I described at the beginning: Knock before entering.. and close the door behind your sorry ass! ;o) In other words: If you open it, you'd better close it again as well..

Next weekend, we'll be taking a look at some of my favourite tools when it comes to breaking stuff!

 

Published Sunday, January 15, 2006 6:49 PM by Paul

Filed under:

Comments

No Comments

Anonymous comments are disabled
Powered by Community Server (Personal Edition), by Telligent Systems