Port Knocking

A better approach here would be to include payload data in the packets, where the server has the "key" to what that data should be. Could be anything.

This would hopefully mitigate the chance that portscanners could trigger something unexpected.

Theres a good iptables port knocking script up at http://www.neep.co.uk/index.php?tab=Projects&menu=Port%20Knocking

Why not use UDP instead of TCP for "Port Knocking"? Using UDP allows you to pass real data without stretching the TCP/IP protocol rules and/or crafting strange IP packets.

To do this, you set up a non-responding UDP listener on one or more UDP ports. If no response is ever given, such ports are indistinguishable from ports filtered by a firewall (e.g. via iptables DROP).

When the UDP listener receives a packet it likes, it instructs the firewall to open up the desired TCP (or UDP) port for the service in question. If you want to be extra fancy, the UDP listener can be a state machine which listens for a sequence of packets on one or more ports, but this may be overkill.

The hidden service can be always "running" -- directly or via xinetd -- listening on the usually filtered port. When the firewall allows traffic on that port, the service can then become active. To be extra safe, a TCP service can immediately instruct the firewall to filter the port it is now using against further SYNs (until another UDP knock).

There are two advantages I see to using UDP. First, the UDP listener can be more easily responsive, since it is a regular network program and doesn't have to dig through firewall log files (which might even be "rotated" during the knock sequence).

Second, the knocks can be much less conspicuous to anyone monitoring traffic. For example, you could use the traditional traceroute ports, or other UDP service ports like DNS or NETBIOS with valid looking requests. If you do this, you might want to use a state machine to require a sequence such as: (1) "Traceroute on port 34567 TTL 3", followed by (2) "DNS lookup of foo.mydomain.com", followed by (3) "NETBIOS something-or-other COLORPRINTER" (my NetBios is sketchy). The point is that these look pretty innocuous to the snooper.

On the other hand, you might want to make things much more straightforward and just have "DNS lookup of pcXYZ.mydomain.com" mean "allow incoming SYNs on port 57XYZ for the next minute" so that you can set up a SSL/SSH/TLS connection to port 57XYZ. Of course, this assumes you aren't running DNS (and hence aren't responding), or you *are* running DNS but have hooked some kind of sniffer on port 53.

Finally, UDP "knock" packets (and even some TCP ones) work just as well with spoofed source addresses. But this should *not* be done without the approval of your network administrator, and is quite inappropriate -- or even illegal -- on the Internet (and may be grounds for your ISP to terminate your account).

Ok, here are some ideas I thought up after reading this initially great idea:

1. Improve it to make the port number sequence tied into something like cryptographic key services like SecurID. This prevents later abuse of the port by anyone who would be sniffing.

2. iptables doesn't need to allow all new connections for the ip after it is first established, since it is statefull, so the first connection attempt could succeed wheras any subsequent attempts would fail before another knock is given.

3. Using other garbage data inside a TCP connection attempt, like TOS, or some such garbage, even varying the TTL of each packet could be used to convey some simple type of number combination.

Internet Cafes, libraries, business partners will all present the potential to not allow outbound traffic to arbritrary ports. Indeed, a good firewall implementation would not allow such traffic. As an example, what business does a client have connecting to ports 822, 915, 341?