msgbartop
Adam Palmer MBCS CITP, Linux, PHP Programmer, MySQL Developer, Embedded Hardware, Security Consultant
Did my blog help you? Please link to me!
  dns test
 
RSS Feed
msgbarbottom

10 Sep 09 Security Consultant – Ports & Port Knocking

Port Knocking is a clever and interesting method of allowing remote firewall manipulation whilst leaving all ports closed to all IPs. When I attempt to initiate a TCP connection to a remote host I send a packet with a ‘SYN’ flag, indicating my intention, along with other information such as a source port, destination port, source IP and destination IP. The target machine has the option of responding by accepting, responding by rejecting, or simply ignoring the packet alltogether, known under iptables and most other firewalls as ACCEPT, REJECT or DROP.

Should the target host explicitly reject my connection, I’ll immediately know about it, based on the timing and packet received, the target host will also inadvertently disclose information about itself. Should the target host simply ignore my connection, my own machine should and will eventually just time out and give up waiting for a response. Based on that alone, we have no way of knowing whether the target host even exists.

How do we hide a machine alltogether? By silently dropping everything that comes our way, i.e. every IP protocol. Dropping does not necessarily mean ignoring, and we can process packets received before dropping them, and then decide to take action whilst at the same time maintaining complete stealth mode. This is the essence of port knocking.

A firewall would be configured for example to wait for an attempted connection to ports 1337, 1338, 12345 and then 31337 in that order before opening port 8888 for the source IP only. In the mean time, should the correct ports not be hit in the correct order, continue to silently drop all data. Based on 65535 ports being available, even with a sequence of only 4 ports, chances of guessing the correct sequence are virtually nonexistant.

Further applications could be that once the correct sequence has been hit, to take further instruction based on ports hit, i.e. should I attempt to then connect to 192, 168,1, 100, 123 the target machine might connect out to 192.168.1.100 on port 123 – just a thought!

In the mean time, the target machine has absolutely no ports open nor has even given the slightest hint of it’s existance to the public.

Reader dmangot points out that packet sniffing defeats port knocking. This is entirely correct and I should have mentioned this earlier. Source and destination ports of a packet are easily sniffed and are entirely plaintext. Your port knocking sequence is as plaintext as transmitting a plaintext password itself.

Tags: , , , , , , , , , , , , ,



Reader's Comments

  1. |

    Yes, and a packet sniffer anywhere in your network path makes your port knocking worthless. You are putting a lot of faith on all your network hops being 100% secure for port knocking to be worth anything.

    Better to stick with authpf instead.

  2. |

    This is a very valid point. Post has been updated

  3. |

    dmangot, the purpose of such a port knock is to reduce exposure against randoms. If you have SSH open on your authpf box anyway, then you negate the reason for filtering SSH in the first place. Even if someone sniffs your port knock, all they get is access to your exposed services, if they are in a position to sniff you, once you are authenticated, they are in a position to access the system anyway usually due to the level of access to the network required for sniffing. Therefore it meets the security requirement of this scenario.



Leave a Comment