Rick DeNatale wrote: > > > Port knocking seems to be a popular technique
I'm not sure it's being used a whole lot. FWIW, I've attached a short report on port knocking I wrote for the Govt last year. (Being written for the Govt it's public domain). Joe -- Joseph Mack PhD, High Performance Computing & Scientific Visualization LMIT, Supporting the EPA Research Triangle Park, NC 919-541-0007 Federal Contact - John B. Smith 919-541-1087 - [EMAIL PROTECTED]Title: Port Knocking: A Method for securing a computer by allowing connections when no ports are open
Apr 2004 Abstract Three implementations of port knocking, knockd, doormand and pasmal are tested. Port knocking is a new technique [1] which holds promise for adding to the armanetarium of security measures. The current implementations are only just coming out of the proof-of-principle stage and are not ready for regular use. Once implemented, these demons will require testing on sacrificial machines exposed to the internet, to show that they aren't vunerable to to compromises which are only obvious with hindsight. Implementations which are good enough to test should be available soon enough, and the EPA should be ready to use them as soon as they are seen to be useful. Table of Contents The EPA has been investigating methods of securing an ftp server and I had considered suggesting port knocking. Recently (mid Apr 2004), there were a series of security breaches at Supercomputing Centers across the US (e.g. Stanford University), I decided to investigate port knocking as a security measure. For access to computers, ports must be open. Port scans will reveal the open ports and in many cases will reveal the OS and OS version on the target computer. This information allows intruder to run known successful attacks agains the computers. There is reasonable evidence that most of the distributed DoS (DDoS) attacks are by home Windows machines sitting 24hrs/day open on cable modems, which have been compromised in this way. Thus 1000's of zombie machines can be coordinated to DDoS a target machine while the owners are sitting at the keyboard web surfing, oblivious of the mayhem their machine is helping to produce (or they could be asleep or at work). A proposal by Martyn Krzywinski, in Linux J. called port knocking turns off the open ports (e.g. with iptables) and listens for a pre-agreed sequence of connect requests to a series of ports (say port 5000,6000,7000) within a timeout period (say 15secs) and the port knocking demon will open the port (say 22 for an ssh connection) to only the client's IP, allowing the client to login. The ports chosen for the knocking (here 5000,6000,7000) can be open but are usually closed. On closing out their session, the client sends a different sequence of knocks (here called "un-knocking") to close down the port (this could be the same ports in the reverse order). Thus a computer with no open ports at all, and hence undetectable by port scanning, will still be available for logins. Even while the user is connected, the open port is open only to the client computer and will not be detected by port scanning. Port knocking then appears to be the perfect method for preventing unauthorised access through port scans. While not vunerable to port scanning, port knocking is vunerable to sniffers. A port scan can be done from any remote computer, but sniffing can only be done on a network segment between the client and server. The port knock sequence can in principle be determined, although possibly with difficulty and hence is insecure. By itself, it is not a method of securing a machine, but should be considered as an extra layer to hinder unauthorized attack. With port-knocking you are ahead of the situation were the ports are open and detectable by simple port scanning. The port knock demon is not likely to be triggered by port scanners. These accesses ports in order or in some random fashion. By requiring enough steps in the port knocking, the chances of a random port scan accessing a port knock can be reduced to an arbitrary level (a factor of 1:65536 for each extra port knocked). The original article by Krzywinski used iptables to log connect requests to the closed port, and a perl script scanned the logs to open the port for user login (say port 22). This was a proof of principle implementation and is too slow and clumsy for regular deployment. Only knockd will be analysed in detail. knockd-0.1 by Judd Vinet. This presumably is the first (and preliminary) release of the code. The server will have sshd running and an iptables rule like
preventing access by remote clients to sshd. On receiving the knock seqence (say connect request to ports 5000,6000,7000 in that order and within 15secs, using the knock client provided), knockd will execute the command.
allowing access to sshd from the only the user's IP (here called %IP%). Multiple accesses by other knockd clients will add similar rules for each client's IP, allowing connection each new client. After exiting the session, the user runs the knock client giving the un-knock sequence. knockd on the server will respond by closing down access to the client's IP with the command
which removes the rule (above) which allowed access from the client's IP. While knockd-0.1 fulfills the requirements above for a minimal port knocking demon, it has the following problems
The current implementation is easy to audit for security. However fixing the problems will require knockd to maintain state for each user. Much testing will have to ensure that the security of knockd has not been compromised by the added code. doormand by J.B. Ward. This port knocking demon maintains state with BerkeleyDB. Due to the mutually incompatible APIs of the different version of BerkeleyDB, I was not able to link doormand. Presumably with enough time I could eventually link it, but I wasn't prepared to spend the time. The author needs to recode the section using BerkeleyDB. Pasmal is in between knockd and doormand in features and complexity. Unfortunately the documentation is only for d00ds a lot c00l3r than I, and I didn't persevere. |
-- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
