Server Security Brainstorm - Port Knocking…
Monday, January 2nd, 2006Lately, with my commencement of self-study for my Red Hat Certified Engineer exam and my continual drive to add yet more to my knowledge-base, to make myself a more valuable employee for those who do eventually employ me. I looked recently, after having been prodded with the idea by one of my class-mates, at ‘port knocking”, a form of client-to-server connection establishment and authentication.
This basic premise of port knocking is this:
Client A wants to establish a connection to secure server B
Server B is set to a ’stealth’ mode (all ports are closed, and connection attempts on these ports do not return an ICMP “connection Refused” packet. They are simply ignored, making it appear to the client as if the server itself doesn’t exist).
Server B has a port knock daemon (hereon called a PKD) running, and monitoring the firewall logs for connection attempts.
Client A has a file that contains the port-knock sequence. This is a series of ports that they will attempt to connect to, in sequence, to identify themselves to the PKD.
The PKD detects the port-knock sequence in the firewall’s logs, and sends the firewall a message instructing it to open a pre-decided port (not part of the knock sequence) for communication to take place through.
Client A does its communicating, then sends a second port-knock sequence to close the connection again.
Now, that’s port-knocking, basically. My brainstorm starts here: As port-knocking stands it’s nice and secure to the server, but still vulnerable to such attacks as man-in-the-middle. A skilled intruder could, theoretically, sit on the single-line path between client and server, and monitor the connection attempts, and learn the sequence, right? Right. Which, in the end, invalidates the hole process, an you may as well just leave the whole server open. I see the best implementation of this working like this:
The PKD is intergrated into the firewall itself, so it can monitor and control the IP stack itself directly, instead of having to work through another application to open and close access. Port knock sequences will be limited life-span, preferably one-use only. The new sequence will be transmitted to the client as part of the connection establishment sequence. Connections themselves will use an public/private key ecryption type, such as Kerberos, to encrypt transmissions between the serverand the authenticated client.
When the connection is opened the opening sequence is immediately moved to another database of ‘old sequences’, to prevent someone trying a playback attack with it. If the server detects this sequence being used again within a certain time-frame, then it will record the originating IP address and blacklist it for another set amount of time. As part of the connection-establishment, after the excryption sequence is complete, the server will generate and send to the client the next sequence, registering it in its own database. By this method the sequences are kept expirable, and secure from recording and playback-attack.
Sequence generation itself is the last point I’ve been thinking on. There’s two paths I could see here: multi-level randomisation to generate a series of numbers between 1024 and 65535 (the public, un-registered port number range). That could easily give you a nice long string of port numbers. That’s okay, but the problem with it is that true randomisation is difficult to achieve, and is processor intensive. The other option is algorithmic generation. Several factors can be taken into consideration and fed as variables into the algorithm to pull out the port numbers. The connection ID of the client. Their IP address. Their location in the world. The time of day. The phase of the moon. Anything, really, so long as you can assign a number to it. I personally like this one, for a couple of reasons. One, it messes with the attacker’s malicious little mind; that’s always fun. Two, and most importantly, the attack, through careful analysis, could theoretically find out the numbers used to generate the sequence, and the algorithm behind it. However, if they’re obscure enough they won’t have a snowball’s chance in hell of figuring out what the numbers mean, and so won’t be able to predict the next incarnation of that value.
Anyway, that’s the end of my brainstorm for now. If I had better (much better) programming skills, I think I could really make something out of this. Port knocking, in my opinion, represents one of the better security concepts of the last few years. I’d like to make it a part of my repetoire. Now I just have to find out how.
Powered by FireStats