cipherdyne.org

25 August, 2008

In the latest issue (September/October 2008) of Hakin9 Magazine, I had an article published entitled Advanced SPA with fwknop. It was the goal of this article to introduce the port forwarding capabilities of fwknop that make it possible to reach internal services with automatically generated NAT rules, and also to show how fwknop SPA packets (prior to the 1.9.6 release) could be detected with some well-crafted Snort rules that look for certain encryption and encoding artifacts. Also, with the addition of source IP addresses to SPA digest tracking, it is possible to get a sense of routing paths that might at one time have had sniffers watching for SPA packets if a replay attack against the same fwknopd instance is detected at some later time.

The Snort rules mentioned in the article - updated to take into account the more recent 1.9.6 release - are displayed below. The first Snort rule is designed to look for UDP packets over port 62201 that end with two '=' characters - a potential marker of base64-encoded data (when the original data size was not a multiple of four). The second rule looks for the base64-encoded version of the string Salted__, which is added by the Crypt::CBC module to maintain compatibility with how the OpenSSL library encrypts data. The third rule looks for packets that begin with base64-encoded version of the string 0x8502 which is a marker for data encrypted with GnuPG, and also checks to see of the size of the payload is at least 1000 bytes (SPA packets encrypted with GnuPG tend to be larger than those encrypted with Rijndael). Here are the Snort rules: alert udp any any -> any 62201 (msg:"fwknop pre-1.9.6 SPA traffic"; dsize:>150; pcre:"/==$/"; sid:20080001; rev:1;)
alert udp any any -> any 62201 (msg:"fwknop pre-1.9.2 SPA traffic"; content:"U2FsdGVkX1"; depth:10; dsize:>150; sid:20080002; rev:1;)
alert udp any any -> any 62201 (msg:"fwknop GnuPG encrypted pre-1.9.6 SPA traffic"; content:"hQ"; depth:2; dsize:>1000; sid:20080003; rev:1;) Any recent release of fwknop (greater than 1.9.5) strips out these identifying markers before transmitting SPA packets on the wire, so these rules are no longer effective at detecting fwknop SPA communications. Also, strong port randomization features were added in fwknop-1.9.4, both for the randomization of the SPA packet destination port as well as the port where the actual connection (say, SSH) is made, so UDP port 62201 is not effective either when these features are used.

Finally, here is an excerpt from the conclusion of the article:

   In the continual arms race that is computer security today, having a good understanding of network communications and how to customize an IDS rule set to an emerging protocol is an important skill. Finally, SPA offers a compelling addition to the tools available for effective server defense; I personally sleep more soundly knowing that arbitrary IP addresses around the Internet cannot see that I have an SSH daemon running, and yet I can access it from wherever I like.

21 May, 2008

At linux.com Bob Currier has written a featured article on fwknop. He gives a good overview of how Single Packet Authorization (SPA) is different from port knocking, and illustrates how to use fwknop to harden SSH communications. Here is a quote from the article:

   Single packet authorization distills the essence of the port knocking concept down to a single packet. Rather than sending a series of packets to predefined ports, single packet authorization encodes the "knock" within the payload of one packet. Once a proper key has been received, SPA applications modify firewall rules to allow access to the authenticated host. We'll examine how this is accomplished by installing and testing the Firewall KNock Operator, better known as fwknop.

There are several comments attached to the article from interested users, and additional discussion of both port knocking and SPA topics can be found at Sebastien Jeanquier's online forum.

19 April, 2008

The March issue of Hakin9 Magazine contains some noteworthy articles and interviews. First is an article written by Ryan Maple entitled "Best Practices for Secure Shell" which discusses various security measures that an administrator can use to heighten the security of SSH. These measures include (among others) forcing the usage of SSH protocol version 2, restricting the address (via the ListenAddress variable) that SSHD binds to from the default of 0.0.0.0, using tcpwrappers, and configuring SSHD to listen on a port other than tcp/22. Covering Single Packet Authorization would have been difficult to include in the same article, but a reference is made to another online article Knock, Knock, Knockin' on EnGarde's Door (with FWKNOP) that does discuss protecting SSH with SPA. Next, is Matt Jonkman's fifth part in his series "Writing IPS Rules". This article covers the byte_test keyword in the Snort rules language and how to use it to write signatures against length encoded protocols. In particular, Matt illustrates using byte_test to look for specific byte values at particular offsets derived from data within the DHCP protocol. The offsets themselves are determined by the data on the wire and therefore cannot simply be hard coded within a signature beforehand. For those who are interested in the latest IDS signatures from Matt, he has updated the online home of the Bleeding Edge Snort ruleset to Emerging Threats. Finally, both Marcus Ranum and Richard Bejtlich were interviewed for the March issue. I would like to see Hakin9 do a more in-depth interview of Bejtlich though since he always has an insightful perspective on computer security - particularly as demonstrated in his book The Tao of Network Security Monitoring.

03 November, 2007

No Starch Press has posted Chapter 10: Deploying fwsnort for free download on their site. This chapter concentrates on the application of fwsnort to iptables rulesets, as mentioned in the chapter introduction:

   With the theoretical discussion in Chapter 9 on the emulation of Snort rule options within iptables behind us, we'll talk in this chapter about how to get fwsnort to actually do something! Namely, we'll discuss the administration of fwsnort and illustrate how it can be used to instruct iptables to detect attacks that are associated with the Snort signature ruleset.

When fwsnort is executed from the command line with no restrictive arguments to limit the scope of the translation process, the default output displays the success and failure rates for translating Snort signatures as seen below. Not all Snort signatures can be re-cast into an iptables rule because of complexities (such as PCRE's) that cannot (yet) be handled within iptables, but as you can see fwsnort achieves a 60% translation rate for the Snort-2.3.3 ruleset - this is more than sufficient to catch a lot of malicious traffic.

[iptablesfw]# fwsnort

    Snort Rules File           Success   Fail     Ipt_apply Total
[+] attack-responses.rules     15        2        0         17
[+] backdoor.rules             62        7        1         69
[+] bad-traffic.rules          10        3        0         13
[+] bleeding-all.rules         1076      573      5         1649
[+] exploit.rules              31        43       0         74
[+] web-cgi.rules              286       62       0         348
[+] web-client.rules           7         10       0         17
[+] web-coldfusion.rules       35        0        0         35
[+] web-frontpage.rules        34        1        0         35
[+] web-iis.rules              103       11       0         114
[+] web-misc.rules             265       61       0         326
[+] web-php.rules              78        48       0         126
[+] x11.rules                  2         0        0         2
                               2725      1761     91        4486
[+] Generated iptables rules for 2725 out of 4486 signatures: 60.74%
[+] Found 91 applicable snort rules to your current iptables policy.
[+] Logfile:         /var/log/fwsnort.log
[+] Iptables script: /etc/fwsnort/fwsnort.sh

The chapter goes on to give several specific attack examples, and how fwsnort can be used to detect them. Here is an example Bleeding Edge Snort rule for detecting the Dumador Trojan (which affects Windows systems and contains both a keylogger and a backdoor): alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BLEEDING-EDGE \
TROJAN Dumador Reporting User Activity"; flow:established,to_server; \
uricontent:".php?p="; nocase; uricontent:"?machineid="; nocase; \
uricontent:"&connection="; nocase; uricontent:"&iplan="; nocase; \
classtype:trojan-activity; reference:url,www.norman.com/Virus/ \
Virus_descriptions/24279/; sid:2002763; rev:2;) By using the fwsnort --snort-sid command line argument, fwsnort will build an iptables command that detects a specific Snort rule ID, so we use this to restrict fwsnort's translation process to just the Dumador signature: [iptablesfw]# fwsnort --snort-sid 2002763
[+] Parsing Snort rules files...
[+] Found sid: 2002763 in bleeding-all.rules
Successful translation. The result is a rather complicated iptables command that uses the string match extension multiple times to express the uricontent fields in the Snort rule. Also, the reference information and the Snort msg field are stored within the iptables rule with the comment match. Finally, the FWSNORT_FORWARD_ESTAB iptables chain is used to only perform the inspection over established TCP connections (the jump rule into this chain uses the state match): $IPTABLES -A FWSNORT_FORWARD_ESTAB -s 192.168.10.0/24 -p tcp --dport 80 -m \
string --string ".php?p=" --algo bm -m string --string "?machineid=" --algo \
bm -m string --string "&connection=" --algo bm -m string --string "&iplan=" \
--algo bm -m comment --comment "sid:2002763; msg: BLEEDING-EDGE TROJAN \
Dumador Reporting User Activity; classtype: trojan-activity; reference: \
url,www.norman.com/Virus/Virus_descriptions/24279/; rev: 2; FWS:1.0;" -j LOG \
--log-ip-options --log-tcp-options --log-prefix "[1] SID2002763 ESTAB "

22 September, 2007

The online site for the book Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort has been finished. This site serves as an online resource in support of the book where scripts, packet traces, configuration files, and other material discussed in the book can be downloaded. Many thanks go to Richard Bejtlich of TaoSecurity for writing an excellent foreword, and to Raffael Marty of SecViz and Ron Gula of Tenable Network Security for endorsing the book.

As an example of some of the resources that can be found online, all of the iptables visualizations in Chapter 14 can found along with the Gnuplot directive and data files here for easy downloading. Here is a sample visualization that shows a 3D Gnuplot view of a port sweep against a Honeynet (note the outlier above the general plane which indicates that the IP 200.216.205.189 has sent a total of 2,244 packets to TCP port 3306, and this is far in excess of any other IP address).

04 April, 2007

The current issue (May '07) of the Linux Journal, contains part II of my series on Single Packet Authorization (SPA). The article is entitled Protecting SSH Servers with Single Packet Authorization, and appears to not be available yet through the LJ website so I suppose that it may only be in the print edition for a while. Part II is a hands-on treatment of fwknop operations, and covers SPA with both symmetric and asymmetric ciphers. here is a short excerpt from the article:

"...This article gets away from theory and concentrates on the practical application of SPA with fwknop and iptables to protect SSHD from reconnaissance and attack. With this setup on a Linux system, no one will be able to tell that SSHD is even listening under an nmap scan, and only authenticated and authorized clients will be able to communicate with SSHD.
    To begin, we require some information about configuration and network architecture. This article assumes that you have installed the latest version of fwknop (1.0.1 as of this writing) on the same system where SSHD and iptables is running. You can download fwknop from http://www.cipherdyne.org/fwknop/ and install either from the source tar archive by running the install.pl script, or install via the RPM for RPM- based Linux distributions..."

04 March, 2007

For the April security issue of the Linux Journal, I have written the first of a two-part article on the concept of Single Packet Authorization (SPA). The first installment lays a theoretical foundation for why the security architecture and capabilities of SPA are superior to Port Knocking. The second installment (to be published in May) will provide a hands-on examination of how to use fwknop to harden an OpenSSH server behind a default-drop iptables policy. Here is an excerpt from the article:

"...When an attacker is on the prowl in an attempt to exploit a vulnerability in server software (as opposed to client software), the first step is reconnaissance; the attacker needs to locate a target. This process has been brilliantly automated by Nmap, so it is easy to construct a list of target systems that may be ripe for compromise. If the attacker has found a zero-day vulnerability in server software that you happen to be running, you don't want to appear in this list of targets! Both port knocking and Single Packet Authorization use a packet filter configured in a default-drop stance and simultaneously provide service only to those IP addresses that can prove their identity via a passive mechanism. No TCP/IP stack access is required to authenticate remote IP addresses via this passive means. Nmap cannot even tell that a server is running when protected in this way, and it does not matter even if the attacker has a zero-day exploit..."

26 December, 2006

Syngress Publishing has published a case study entitled "Active Response" I wrote for the book Wireshark & Ethereal Network Protocol Analyzer Toolkit (see pages 398-402). This case study explores the usage of Wireshark to examine the structure of TCP RST (reset) packets that are generated by the iptables REJECT target and by the flexresp and flexresp2 Snort detection plugins in response to malicious traffic sent against a webserver. Because each of these mechanisms employs a different strategy for creating the RST packets, it is possible for an attacker to perform some passive fingerprinting in an effort to discover the response mechanism. For example, iptables rules that utilize the REJECT target (see the iptables command below) generate packets from within the Linux kernel and hard code the TTL value at 255 for all kernel versions < 2.6.16.
# iptables -I INPUT 1 -p tcp --dport 80 -m string --string "/etc/passwd" --algo bm -j REJECT --reject-with tcp-reset The REJECT target can only send the RST packet to the source IP that matched the REJECT rule. The flexresp detection plugin can send RST packets to both sides of a TCP connection, always sets the TCP window size to zero, and selects a random TTL value between 64 and 255. The remaining analysis can be found in the book, and provides additional details on characteristics of the RST packets sent by each response mechanism.

16 December, 2006

No Starch Press has created a clever piece of cover art for my upcoming book Linux Firewalls: Attack Detection and Response. The book should be available in early to mid 2007, and discusses intrusion detection and response with iptables firewalls, including significant coverage of both psad and fwsnort. One chapter will also cover visualizing iptables logs, with particular emphasis on the Scan30 and Scan34 challenges from the Honeynet Project. Iptables log visualization is made possible by combining the new --CSV-* options available in psad-2.0 with the AfterGlow project. In addition, two chapters deal with the rise of port knocking and Single Packet Authorization, particularly with fwknop.

03 November, 2006

I am writing a book for No Starch Press entitled "Linux Firewalls: Attack Detection and Response". This book will be available for purchase in late February of 2007, but can be pre-ordered online through No Starch or through Amazon. Topics covered in the book include intrusion detection and prevention with iptables firewalls, and this includes significant coverage of both psad and fwsnort. In addition, two chapters deal with the rise of port knocking and Single Packet Authorization, particularly with fwknop. I'm currently writing the last four out of a total of thirteen chapters, so the bulk of the writing is finished. Pablo Neira Ayuso of Netfilter fame is the Technical Editor for the book, and his input has been invaluable to tightening many of the technical arguments. Ron Gula of Tenable Network Security has also written some kind words about the book.