Port Knocking

SahirH

Check the below link that I've come across. I'm not sure how much of help it would be in your research and development of PortKnocking techniques, that you have mentioned in one of our conversations.


www.hackerthreads.org/phpbb/viewtopic.php?t=6195

Thank you FallenZero. My research on port-knocking is almost done. Its one of those nice concepts that you can keep layering new ideas on top of. I have coded an implementation that is tentatively called 'OpenSaysMe'. Rather than doing what other people have been doing -- using a knock sequence to spawn a shell or add a firewall rule etc etc. I use the actual knocking to control the system. It gets quite complicated as it has been designed from the ground up to evade detection by IDS'. The traffic it generates appears as close to normal as possible, with all data / parameters / commands etc being embedded in the packet header fields such as the seq number, window size etc.

This initially started out as a trojan development project with a couple of coder friends and me, however as we started adding more functionality it has become a really really cool piece of software. The last 'features' I added were the fun ones (open CDROM, flip screen, hide taskbar, hide desktop kinda stuff ).

We're working out a nice structured system of control codes etc to do all the work. I'm currently using it to administer a couple of my boxes, including my main box at home. Great fun to whiz a packet by and control the system remotely.

From the network efficiency point of view, it is actually quite interesting... I theorize that since most TCP/IP networks today are very reliable, with low packet loss ratios, we can actually skip the overhead of the three way handshake and reliable delivery... so now someone will ask me "Why didn't you just use UDP".. Because I didn't want an open port, and I like the fact that TCP port 80 is allowed to go everywhere.. and I love the flexibility that is provided by the header values in TCP.

I'm not posting the code here yet as I haven't spoken to everyone else about GPL-ing their sections. You can track its progress here (I will post a nice big post when it's 'ready'), or at my blog -- tftfotw.blogspot.com.

Cheers,

Port Knocking seems to be good technology. But I was just wondering of it's implementation.

One of the techniques described was to have a Deamon on Layer-2 and listen to the requests from hosts and to see if the port sequence numbers from the hosts match exactly as it is in the configuration files and if it is, than accept the request and provide the necessary servies with a window of timeframe say 10-15 seconds.

The only disadvantages I see with this techniques is, what would happen,

1].If someone was able to randomly predict or break the port sequence numbers and able to do his/her thing?

2].Say, you give the sequence numbers ONLY to trusted users and if somehow fell into the wrong hands.

One has to carefully choose the port sequence numbers so they don't get mixed up with other regular public services like HTTP/SMTP etc.

I don't seem to get the picture of it yet. But it's good technology that defeats who is able to perform port probing with FireWalking.

Sahirh,BTW, what programming language are you writing the code in? I would greatly appreciate, if you could expand a little more on the subject or if you could list any other useful links.

You're right, the sanctity of the knock sequence is important, just as keeping a password secret is important, however there are ways you can counter this... make a cryptographic hash of a password with maybe a time value etc, and embed this into the packet. Since it is time based, it will defeat a replay attack.

While bruteforcing the knock sequence is of course possible, it can be made very very difficult. Think about it.... 65535 ports, with virtually unlimited options for manipulation in the packet header... I could use even a 3 packet knock sequence and make it unfeasible to brute force

packet 1 - SYN packet to port 300 with a winsize divideable by 13, prime sequence number etc etc
packet 2 - RST/ACK packet to port 5554 with ack number greater than 10000 and less than 20000
packet 3 - ACK packet to port 9923 with URG and PUSH flag set..

etc etc.. bruteforcing this is really difficult.. and even if you somehow brute it... how do you know what behaviour it has triggered..

as an example, my earliest implementation used a simple 3 knock SYN packet sequence and then spawned a listening command shell on port 55.. because it occured to me that a portscan with randomized ports *could* accidentally trigger off the knock sequence, I decided that the spawned shell would only accept one instance of a connection after it spawned and would then die...

If someone tried to bruteforce this, after each bruteforce attempt he would have to check the open ports on the system by portscanning it. The very act of doing this would use up the one instance shell, and he would see the open port, but then when he tried to connect to it, it would long be closed

As to your other point, you dont need to bother whether the sequences mix up with other services.. Thats the best part.. it doesn't matter where those packets go.. to closed ports, open ports etc etc.. its irrelevant..
The basic architecture of the knock server is this

SNIFFER
KNOCK PROCESSOR
COMMAND EXECUTION

So the sniffe will just look at any traffic running around, the knock sequence could even be going to a completely different host !! We even did this on a LAN... the knock server was running on 192.168.2.1, when it saw certain packets going to 192.168.2.6, it initiated a reverse connect shell to a prechosen IP address.

The concept relies on security by obscurity to some extent.. but that doesn't matter, as it does work. When you add in other access control mechanisms.. such as crypto in the header, or maybe just a password on the shell that spawns.. you realise that even if an attacker knows about the knocking, it will be frustratingly difficult for him to gain access..

From the other point of view, an admin, or even a seasoned network security monitoring pro will lose his mind trying to figure out what is the knock sequence an attacker is using.. or how he is communicating with the server etc etc.

Take this scenario.. I have compromised your network of 500 machines.. and installed my knocking program on all of them. You run your company's webserver in the DMZ, and it gets a large number of hits everyday. All my zombie systems have been instructed to look for an innocuous SYN packet to port 80 of your webserver (a perfectly normal occurence), but with some prechosen values in the headers.. the whole normal 3 way handshake between the webserver and the 'client' (which is actually me controlling the knocking) looks like a normal connection to the webserver.. but the zombies know better..... they know that when they see these packets, they have to start SYN flooding a particular host on the net.

the NSM practitioner or admin.. who is desperately watching all
traffic on the network, would be smart and correlate the sudden SYN flood.. he would look at all packets that were transmitted just before the flooding began, and would after a while figure out the webserver connection.. so we make all our zombies wait for a random time interval after they see the knock sequence (say < 5 minutes)... or even till they've seen a certain number of other packets whiz by..... then they start their SYN flood.

This is what I mean by layering concepts on portknocking.. it is highly extensible once you have a base framework in place.. you can do almost anything you want.

As far as the programming language is concerned, I'm a C purist. I should be writing sections of the code object oriented, but I like working this way

The client interface (that does the knocking) is currently a shell script using hping, but will soon be written in C, and a GUI created in VB for the windows world and QT for the Linux world.