Thwarting Distributed SSH Brute Force Attempts

The SANS Internet Storm Center has an interesting diary entry that discusses a set of distributed brute force attempts against SSHD originating from a specific Class C subnet 58.147.10.0/24. According to the diary entry, a random selection of IP addresses within this subnet (which is owned by an organization in Thailand) are probing for listening SSH daemons on the open Internet, but each IP address is limiting the number of probes to two. Presumably this is to fly beneath the radar of any threshold-based detection mechanisms that might automatically block the attempts to communicate with SSHD.

     After rummaging around in my iptables logfiles, I noticed the following two log entries that show exactly two SYN packets from the IP 58.147.10.209 and destined for one of my systems:

Jun  3 14:55:06 minastirith kernel: DROP IN=eth0 OUT= \
MAC=00:13:d3:38:b6:e4:00:90:1a:a0:1c:ec:08:00 SRC=58.147.10.209 \
DST=71.N.N.N LEN=60 TOS=0x00 PREC=0x00 TTL=44 ID=11651 DF \
PROTO=TCP SPT=57473 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT \
(020405780402080A7CCF5BC50000000001030302)
Jun  3 14:55:09 minastirith kernel: DROP IN=eth0 OUT= \
MAC=00:13:d3:38:b6:e4:00:90:1a:a0:1c:ec:08:00 SRC=58.147.10.209 \
DST=71.N.N.N LEN=60 TOS=0x00 PREC=0x00 TTL=44 ID=11653 DF \
PROTO=TCP SPT=57473 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT \
(020405780402080A7CCF677D0000000001030302)

These two packets date back to June of last year, so the 58.147.10.0/24 network has apparently been active for quite some time. So, beyond the whois information mentioned in the ISC diary entry, can we tell anything more about our friend at 58.147.10.209? Because I always use the --log-tcp-options command line argument when building my iptables LOG rules, we have nice hex dumps included in the log messages above that represent the options portion of the TCP header. Having this information is necessary in order to passively fingerprint the remote TCP stack with p0f. The psad project re-implements the p0f algorithm over iptables log messages - p0f requires raw packet data acquired via libpcap - so what does psad have to say about the remote TCP stack?

[minastirith]# psad -A -m /var/log/messages --restrict-ip 58.147.10.209
[+] p0f(): 58.147.10.209 len: 60, frag_bit: 1, ttl: 44, win: 5840
[+] MSS: 1400, SACK, Timestamp: 2093964229, NOP, Win Scale: 2,
    Could not match 58.147.10.209 against any p0f signature.

Oh well, that is unfortunate. So, p0f does not seem to have a fingerprint that can characterize the remote TCP stack. I also looked through the passive OS fingerprinting database included with the ettercap project, but no luck there either. This was a manual process though because psad does not yet support the format of the fingerprints in ettercap, but this will be supported in the next release.

     In the meantime, the discussion in the diary entry advocates limiting the set of IP addresses that are allowed to talk to the SSH daemon, but ends with a comment stating that this is not always possible. I agree with this comment, and this is highlighted whenever you administer a system and you need access to SSHD from unpredictable source addresses (such as when travel is involved). A robust solution is to deploy Single Packet Authorization with a default-drop packet filter. Why let arbitrary source IP addresses communicate with your SSH daemon?

Hakin9 fwknop Article

The February issue of the "Starter Kit" edition of Hakin9 Magazine contains a lengthy article on fwknop written by Raul Siles. The Starter Kit edition aims to provide introductory articles and tutorials that explain important computer security technologies from the ground up, and I think this is valuable because security is a complex field and there is generally a lack of good material of this kind. Raul's article is entitled "Knock Knock Knocking on Firewall's Door", and is featured on the magazine cover. In the article, Raul provides a history of passive authorization technologies beginning with Port Knocking and extends the discussion into the latest generation of these technologies called Single Packet Authorization. He gives detailed information about how to install and configure fwknop-1.0 on a Fedora Core 6 system, and shows how iptables in a default-drop stance for protected services do not appear underneath the watchful eyes of Nmap. Here is a short excerpt from the article:

Although port knocking and SPA can be used to protect any service and its associated ports, they are mainly used to protect and enable access to remote management protocols, and especially long running TCP sessions, such as Secure Shell, SSH (TCP port 22).

The article presents two configuration example. The first one focuses on allowing access to SSH while the second allows the client to manage remotely the rules that should be applied in the iptables firewall.

Incidentally, the same issue of Hakin9 includes coverage of the psad and fwsnort projects in another article entitled "Much More Than Just a Firewall" written by Jess Garcia. His article covers several security technologies including honeypots and snort_inline, and makes the case that firewalls can do much more than simple filtering operations on network traffic. I'm happy to see Cipherdyne projects getting more exposure in the security literature.

Software Release - fwknop-1.8

The 1.8 release of fwknop is ready for download. This release includes major new functionality to allow fwknop to function in server mode with ipfw firewalls on *BSD systems, and the fwknop client now runs on Windows systems under Cygwin. Here is the ChangeLog:

• Added support for ipfw firewalls (found on *BSD systems). The IPTables::Parse and IPTables::ChainMgr modules are not installed on such systems.
• Added gpg-agent support for both the fwknop client and fwknopd SPA server.
• Updated client-only installation mode to restrict perl module installation to those module that are actually required by the fwknop client. This results in clean installs of the fwknop client on Windows systems running Cygwin.
• Added --Defaults to install.pl so that fwknop can be installed without prompting the user to answer any questions. This is to make it easier to install fwknop on the Source Mage Linux distro.
• Consolidated daemon config files into the fwknop.conf file (except for the access.conf file). This simplifies the configuration of fwknop.
• Added recursive variable resolution in the parsing routines for the fwknop.conf file. This allows variable values to contain embedded variables.
• Added init script for FreeBSD systems.
• Added --BSD-install command line argument to install.pl. This is not normally necessary since the installer should detect installations on *BSD systems, but this option can force this behavior.
• Updated knopmd and knopwatchd to use safe_malloc() instead of malloc().
• Bugfix to never time out rules from SOURCE blocks with FW_ACCESS_TIMEOUT set to zero.

Richard Bejtlich References Single Packet Authorization

Richard Bejtlich, founder of TaoSecurity, has made a posting to his blog that references Single Packet Authorization in the context of making it more difficult to discover and communicate with SSHD from arbitrary IP addresses. One of the points he makes in his blog posting is that it is important to force a would-be attacker to fight your fight instead of allowing an attacker to dictate the stage on which a battle is fought. For example, if an attacker possesses a zero-day exploit for SSHD, then the mere ability to access SSHD from an arbitrary source is taking a dangerous risk. One of Richard's readers posted a particularly cogent comment about the concept of "security through obscurity":

As for changing the port for SSH - my belief is that at times we get so hung up on the tags - "security by obscurity" that we cease to see the valid strategies that they can cover. Simply because we denigrate the people who rely solely on it doesn't mean that it isn't part of a valid defensive scheme.

I completely agree. Fortunately however, Single Packet Authorization does not suffer from security through obscurity. SPA essentially ties access through a default-drop packet filter to a protected service via strong cryptographic means. A nice byproduct of this is that services are not advertised to the world, but this is a consequence of the default-drop packet filter. The security of SPA does not rely on keeping the mechanism secret and hoping that it is not discovered; all source code to every SPA implementation that I am aware of is open and published to the world. SPA is no more security through obscurity than passwords or encryption algorithms themselves.

Techno Security 2007 Talk on Single Packet Authorization

At the Techno Security 2007 conference (June 3-6, Myrtle Beach, South Carolina) I will be giving a talk entitled "Zero-day Attack Prevention via Single Packet Authorization". My intention for this talk is to illustrate practical usages of fwknop with an emphasis on live demonstrations of the technology. There have also been some interesting developments in the Single Packet Authorization world since I last gave a talk on the topic at ShmooCon, 2006. In particular, Sebastien Jeanquier wrote a Master's Thesis on SPA entitled "An Analysis of Port Knocking and Single Packet Authorization" at the Information Security Group (ISG) at Royal Holloway College, University of London. His thesis is an excellent evaluation of the port knocking and SPA concepts, and is a must-read for anyone who would like to explore an authoritative treatment of the two security mechanisms. Sebastien uses a quote from Bruce Schneier's Applied Cryptography to help explain away the perception that some people have that SPA suffers from security through obscurity (which it thoroughly does not):

"...If I take a letter, lock it in a safe, hide the safe somewhere in New York, then tell you to read the letter, that's not security. That's obscurity. On the other hand, if I take a letter and lock it in a safe, and then give you the safe along with the design specifications of the safe and hundred identical safes with their combinations so that you and the worlds best safecrackers can study the locking mechanism - and you still can't open the safe and read the letter - that's security..."

Also, additional SPA projects have sprung up, such as an in-kernel implementation that is built entirely within the Netfilter framework. I will discuss these implementations, and make the case that SPA is maturing as a valuable protective mechanism against unknown zero-day exploits in server software.