Primary blog moved to cipherdyne.org

All current blog posts are located at cipherdyne.org.

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?

Article on psad at Linuxsecurity.com

Eckie Silapaswang has written an article on psad entitled "Meet the Anti-Nmap: PSAD" at linuxsecurity.com. This article focuses on installing and using psad on the EnGarde secure linux distribution. Topics covered include disabling SELinux, installation of psad via the Guardian Digital Secure Network (GDSN), psad configuration, and psad alerting. Eckie also covers the concept of active response with psad, and illustrates how psad responds to an attacker with the dynamic instantiation of iptables blocking rules.

gpgdir-1.7 released

The 1.7 release of gpgdir is ready for download. This release fixes a bug that was introduced in gpgdir-1.6 that caused previously encrypted directories to not be decrypted in --decrypt mode. This bug was reported by Per Ronny Westin, and the result is the addition of a new test suite so that bugs of this type don't creep back into the gpgdir development process. Here is some sample output of the new test suite in action:

[+] ==> Running gpgdir test suite <==

(Setup) gpgdir program compilation..................................pass (0)
(Setup) Command line argument processing............................pass (1)
(Test mode) gpgdir basic test mode..................................pass (2)
(Encrypt dir) gpgdir directory encryption...........................pass (3)
(Encrypt dir) Files recursively encrypted...........................pass (4)
(Encrypt dir) Excluded hidden files/dirs............................pass (5)
(Decrypt dir) gpgdir directory decryption...........................pass (6)
(Decrypt dir) Files recursively decrypted...........................pass (7)
(MD5 digest) match across encrypt/decrypt cycle.....................pass (8)
(Ascii-armor dir) gpgdir directory encryption.......................pass (9)
(Ascii-armor dir) Files recursively encrypted.......................pass (10)
(Ascii-armor dir) Excluded hidden files/dirs........................pass (11)
(Decrypt dir) gpgdir directory decryption...........................pass (12)
(Decrypt dir) Files recursively decrypted...........................pass (13)
(MD5 digest) match across encrypt/decrypt cycle.....................pass (14)

[+] ==> Passed 15/15 tests against gpgdir. <==
[+] This console output has been stored in: test.log

Here is the complete ChangeLog: for the 1.7 release:

• Bugfix to ensure that encrypted directories can actually be decrypted. This bug was reported by Per Ronny Westin.


• Updated to use the ".asc" extension for encrypted files in --Plain-ascii mode.


• Added gpgdir test suite. All future gpgdir releases (and including this 1.7 release) require that all gpgdir tests pass on the systems where gpgdir is developed.

Interfacing VIM with GnuPG Encrypted Files

Over the years the editor I have become the most familiar with is vim. It provides features that allow the software development process to go smoothly, such as split screens, syntax highlighting, integration with cscope tags, function folding, and more. By applying configuration directives to your ~/.vimrc file, you can instruct vim to perform some nice preprocessing functions against files. This blog post illustrates a ~/.vimrc tweak (originally from Wouter Hanegraaff) that allows vim to leverage GnuPG to decrypt a previously encrypted file, allow edits to be made, and then re-encrypted before it is written back to disk. Here is the section of the .vimrc file to allow such transparent encryption and editing:

" Transparent editing of gpg encrypted files.
" By Wouter Hanegraaff <wouter@blub.net>
augroup encrypted
au!
" First make sure nothing is written to ~/.viminfo while editing
" an encrypted file.
autocmd BufReadPre,FileReadPre *.gpg set viminfo=
" We don't want a swap file, as it writes unencrypted data to disk
autocmd BufReadPre,FileReadPre *.gpg set noswapfile
" Switch to binary mode to read the encrypted file
autocmd BufReadPre,FileReadPre *.gpg set bin
autocmd BufReadPre,FileReadPre *.gpg let ch_save = &ch|set ch=2
autocmd BufReadPost,FileReadPost *.gpg '[,']!gpg --decrypt 2> /dev/null
" Switch to normal mode for editing
autocmd BufReadPost,FileReadPost *.gpg set nobin
autocmd BufReadPost,FileReadPost *.gpg let &ch = ch_save|unlet ch_save
autocmd BufReadPost,FileReadPost *.gpg execute ":doautocmd BufReadPost " . expand("%:r")
" Convert all text to encrypted text before writing
autocmd BufWritePre,FileWritePre *.gpg '[,']!gpg --default-recipient-self -ae 2>/dev/null
" Undo the encryption so we are back in the normal text, directly
" after the file has been written.
autocmd BufWritePost,FileWritePost *.gpg u

You can combine this vim tweak with gpgdir to maintain recursively encrypted directories, and just edit the files directly. For example, the following sequence of commands shows the creation of an encrypted file and how vim then interfaces with GnuPG to allow transparent editing:

$ cat > somefile
private data
more private data
$ gpg -e somefile
$ wipe somefile
Okay to WIPE 1 regular file ? (Yes/No) yes
Operation finished.
1 file wiped and 0 special files ignored in 0 directories, 0 symlinks removed \
but not followed, 0 errors occured.
$ ls -l somefile.gpg
-rw-r--r-- 1 mbr mbr 618 2008-02-17 01:52 somefile.gpg
$ vim somefile.gpg
"somefile.gpg" [noeol] 3L, 618C

You need a passphrase to unlock the secret key for
user: "Michael Rash <mbr@cipherdyne.org>"
2048-bit ELG-E key, ID 1234ABCD, created 2007-05-01 (main key ID ABCD1234)

Enter passphrase:

<apply edits now, and hit :wq >

$ ls -l somefile.gpg
-rw-r--r-- 1 mbr mbr 932 2008-02-17 01:55 somefile.gpg

As you can see from the output above, the file was modified (and the original file somefile was deleted using wipe).

Finally, the 1.6 release of gpgdir is ready for download. This is a bugfix release that restores the exclusion of previously encrypted files from the file selection process, and includes a few minor install.pl enhancements as well. Here is the ChangeLog:

• Bugfix to not include previously encrypted files (i.e. those with a .gpg extension) in the encryption/decryption file list. This bug was introduced in gpgdir-1.5 when a change was made to ignore ascii-armored files.


• Added added LC_ALL=C locale setting for the install.pl script (this should help to ensure gpgdir is properly installed on most systems). Two new command line arguments --LC_ALL and --no-LC_ALL also allow the locale setting to be changed or not used at all.


• Added --Exclude-mod-regex option to the install.pl script so that it is possible to force the exclusion of perl modules that gpgdir would normally install. This is useful for ensuring that gpgdir references perl modules that are already installed in the system perl library tree instead of using those that are installed in /usr/lib/gpgdir.


• Updated to display command line usage warnings without automatically displaying the entire usage() page (which is quite long).

Software Release - gpgdir-1.4

The 1.4 release of gpgdir is ready for download. This release adds two new options that allow previously encrypted or decrypted files to be overwritten. Here is the ChangeLog:

• (Anthony Chivetta) Submitted patch to implement the --overwrite-encrypted command line argument to allow previously encrypted files to be overwritten. This is useful for updating an encrypted directory with new versions of the previously encrypted files. Also added the --overwrite-decrypted command line argument to perform the same function for previously decrypted files.
• (Anthony Chivetta) Submitted patch to fix a bug where a filename of "0.gpg" could not be decrypted because "0"

As an example, here is the output gpgdir produces when encrypting a directory:

[mbr@minastirith ~/src/gpgdir]$ gpgdir --Exclude "GnuPG-Interface/t" --encrypt GnuPG-Interface
[+] Executing: gpgdir --Exclude GnuPG-Interface/t --encrypt GnuPG-Interface
Using GnuPG key: A742839F
Enter password (for initial encrypt/decrypt test)
Password:

[+] Encrypting directory: /home/mbr/src/gpgdir/GnuPG-Interface
[+] Building file list...
[-] Skipping encrypted file: /home/mbr/src/gpgdir/GnuPG-Interface/test/pubring.gpg
[-] Skipping encrypted file: /home/mbr/src/gpgdir/GnuPG-Interface/test/encrypted.1.gpg
[-] Skipping encrypted file: /home/mbr/src/gpgdir/GnuPG-Interface/test/secring.gpg
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/lib/GnuPG/PublicKey.pm
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/lib/GnuPG/Options.pm
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/Makefile.PL
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/MANIFEST
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/README
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/NEWS
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/lib/GnuPG/Signature.pm
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/lib/GnuPG/Handles.pm
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/lib/GnuPG/PrimaryKey.pm
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/THANKS
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/lib/GnuPG/Fingerprint.pm
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/ChangeLog
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/lib/GnuPG/SecretKey.pm
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/lib/GnuPG/SubKey.pm
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/lib/GnuPG/Key.pm
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/VERSION
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/COPYING
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/lib/GnuPG/UserId.pm
[+] Encrypting: /home/mbr/src/gpgdir/GnuPG-Interface/lib/GnuPG/Interface.pm

[+] Total number of files encrypted: 19

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.

Techno Security SPA Talk Slides

The Techno Security 2007 conference is over, and I gave a talk entitled "Zero-day Attack Prevention via Single Packet Authorization". The major emphasis of this talk was to demonstrate some of the new capabilities offered by the 1.8 release of fwknop, including the ability to run the fwknop client on a Windows 2000 system under Cygwin and authenticate to a Linux system running the fwknopd server. This demonstration was accomplished from a single Ubuntu Linux system with a Windows 2000 instance under Vmware to execute the fwknop client. New capabilities in fwknop that I did not have time to demonstrate are the ability to run the fwknopd server on systems that use the ipfw firewall (such as FreeBSD and Mac OS X), and the usage of gpg-agent (part of the GnuPG project) to acquire passwords associated with GnuPG keys. At some point it might be interesting to devote more time to giving a lengthy demonstration of various fwknop authentication modes and features. One additional note is that I have released fwknop-1.8.1 after the conference talk to address an issue with the usage of the ipfw "keep-state" option when fwknopd creates new rules to accept connections from valid fwknop client systems; here is the ChangeLog.

You can download a PDF of my presentation slides here.

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.

Software Release - psad-2.0.7

The 2.0.7 release of psad is ready for download. This is a minor bugfix release, and here is the ChangeLog:

• Bugfix to define a custom 'source' definition for syslog-ng daemons - this fixes a problem on SuSE systems where the existing syslog-ng reconfig caused the daemon to not start.
• Bugfix to allow specific signatures to be ignored by setting SID values of zero in /etc/psad/snort_rule_dl.
• Added -X command line argument to allow the user to delete any psad chains (in auto-response mode). This is a synonym for the iptables -X command line argument.

Software Release - gpgdir-1.2

The 1.2 release of gpgdir is ready for download. This release concentrates on getting gpgdir to function on non-Linux systems - specifically Windows under Cygwin and FreeBSD. Here is the ChangeLog:

• Added support for installing gpgdir on Windows under Cygwin (via the install.pl script). Installing gpgdir on FreeBSD systems also works.
• Added support for installing gpgdir within a user home directory without the need for root access (this requires installing gpgdir with the install.pl script).
• Added --agent to have gpgdir acquire gpg key password from a running gpg-agent instance.
• Added --no-password so gpgdir can use a gpg key with no associated password (this is not common). The user is not prompted for a password in this case.

Software Release - gpgdir-1.1

The 1.1 release of gpgdir is ready for download. This is a major release with new functionality such as the ability to drive the wipe program to securely delete original files after successful encryption. Here is the ChangeLog:

• Added the ability to securely delete the original versions of files with the 'wipe' program (after they have been successfully encrypted). Also added --wipe-path to specify a path to the wipe binary (the default is /usr/bin/wipe), --wipe-interactive to force the wipe program to prompt the user before a file is deleted, and --wipe-cmdline to allow the user to build a set of command line arguments that are passed to the wipe program.
• Added --Force to have gpgdir skip over the error condition where a file cannot be deleted (because of a permissions issue for example).
• Added --Trial-run to allow the user to see what actions gpgdir would take to encrypt or decrypt files, but no files are actually modified.
• Added --Interactive to have gpgdir prompt the user before every file is encrypted, decrypted.
• Added the gpgdir.SlackBuild script (contributed by pyllyukko originally for the psad project) for building gpgdir on Slackware systems.

Kernel String Matching and IPS Performance

The iptables QUEUE and NFQUEUE targets are used by both open source and commercial Intrusion Prevention Systems. These targets allow a userspace process (the IPS in this case) to acquire packet data from the Linux kernel via a netlink socket and set verdicts on whether packets should be forwarded only after the IPS has sent the packets through its detection engine. This can provide a effective means from protecting other systems from attack (subject to the usual concerns over false positives).

Using iptables provides a flexible means for placing a QUEUE rule within an existing iptables policy. For example, if you are not running a DNS server behind an iptables firewall, then you can use the DROP target against any attempts to communicate with a DNS server before sending such packets to a userspace IPS - which would needlessly place additional load on the CPU when such traffic can just be dropped from within the kernel directly before it ever hits the QUEUE rule:

# iptables -A FORWARD -p udp --dport 53 -j DROP
# iptables -A FORWARD -j QUEUE

This is a nice consequence, but is only possible in this case because there is no internal DNS server to attack in the first place. What about using facilities provided by iptables to reduce the packet load that is queued to a userspace IPS for servers that do exist? Say, for a web server?

An IPS such as snort_inline can be deployed with a large signature set, and most Snort signatures use the content or uricontent keywords to search packet application layer data for malicious content. In the context of snort_inline, usually the QUEUE or NFQUEUE rule is the default rule in the FORWARD chain - this ensures that snort_inline inspects all packets before they are forwarded through the system. So, you could say the iptables policy has a "default QUEUE stance".

However, by using the iptables string match extension and an iptables policy built by fwsnort, we can change the "default QUEUE stance" to "only QUEUE packets that match a Snort content field". The resulting performance gain can be substantial as we will see below. Fwsnort accomplishes this by parsing the Snort signature set that is deployed in snort_inline, and then building an iptables policy that makes heavy use of the string match extension to ACCEPT all packets in the FORWARD chain that do not match any of the content fields in the signature set, and QUEUE those that do. In general, this greatly reduces the number of packets that have to be queued to snort_inline since (usually) most traffic is not malicious. As a simple example, consider the following Snort signature:

alert tcp any any -> any any (msg:"fwsnort download"; content: \
"fwsnort/download"; classtype:web-application-attack; sid:12325678; rev:1;)

This signature is for illustration purposes only and is written just to force snort_inline to inspect all TCP packets for the string "fwsnort/download". With this signature deployed in snort_inline on one of my systems (an old PIII with 100Mb Ethernet interfaces running the 2.6.20.3 kernel), I measured the following throughput with netperf. This test used a default QUEUE rule in iptables, so every TCP packet is queued to snort_inline:

# netperf -v 2 -L 192.168.50.1 -H 192.168.50.2
TCP STREAM TEST from 192.168.50.1 (192.168.50.1) port 0 AF_INET to \
192.168.50.2 (192.168.50.2) port 0 AF_INET
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.02      60.07

Alignment      Offset         Bytes    Bytes       Sends   Bytes    Recvs
Local  Remote  Local  Remote  Xfered   Per                 Per
Send   Recv    Send   Recv             Send (avg)          Recv (avg)
  8       8    0      0       7.524e+07  16384.33  4592    1444.75  52076

Maximum
Segment
Size (bytes)
  1448

The throughput number above indicates that netperf was able to achieve 60.07 Mb/sec over the life of the 10 second test. Now, let's use fwsnort to convert the Snort signature into an equivalent iptables rule, and deploy it:

# fwsnort --snort-sid 12325678 --QUEUE
[+] Parsing Snort rules files...
[+] Found sid: 12325678 in test.rules
    Successful translation.

[+] Logfile: /var/log/fwsnort.log
[+] Snort rule set directory for rules to be queued to userspace:
    /etc/fwsnort/snort_rules_queue
[+] iptables script: /etc/fwsnort/fwsnort.sh
# /etc/fwsnort/fwsnort.sh
[+] Adding test rules.
    Rules added: 2
[+] Finished.

Now, executing the netperf throughput test generates the follow result:

# netperf -v 2 -L 192.168.50.1 -H 192.168.50.2
TCP STREAM TEST from 192.168.50.1 (192.168.50.1) port 0 AF_INET to \
192.168.50.2 (192.168.50.2) port 0 AF_INET
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.01      94.11

Alignment      Offset         Bytes    Bytes       Sends   Bytes    Recvs
Local  Remote  Local  Remote  Xfered   Per                 Per
Send   Recv    Send   Recv             Send (avg)          Recv (avg)
    8    8      0     0       1.178e+08  16384.74  7189    1440.01  81798

Maximum
Segment
Size (bytes)
  1448

So, in this test we achieved 94.11 Mb/sec sustained throughput - that's about a 57% speed increase!

This may sound good, but as always there are some tradeoffs. First, because this strategy causes iptables to only selectively queue packets to userspace, snort_inline does not have the opportunity inspect an entire stream. This implies that the stream preprocessor needs to be disabled since otherwise signatures with the flow keyword will never match. Secondly, because the preliminary signature match is performed by iptables, taking into account application layer encodings (such as URL encoding used in web servers) is not possible. This results in a reduced ability to detect attacks. In some cases however, performance requirements may override these considerations. Also, some attacks do not need to bother with attempts at obfuscation because the target environment is so rich.

Significant work needs to be performed to validate this as a viable strategy for increasing IPS performance, but these preliminary results are encouraging. On a final note, this strategy is applicable to any IPS that makes use of the iptables queuing mechanism - not just snort_inline.

Also, thanks are in order to Hank Leininger of KoreLogic Security for suggesting the combination of the QUEUE target and string matching as a way to speed up inline Snort implementations at a talk I gave about Linux Firewalls at ShmooCon 2007. I implemented the --QUEUE and --NFQUEUE targets in fwsnort-1.0 as a result of meditating on this for a while.

fwsnort-1.0 release

The 1.0 release of fwsnort is ready for download. This release is a major update that adds the ability to build an iptables policy against the NFQUEUE or QUEUE targets in order to perform preliminary content matching in the Linux kernel using the iptables string match extension. Here is the full ChangeLog:

• Major update to include support for the NFQUEUE and QUEUE targets with new command line options --NFQUEUE and --QUEUE. This changes the default LOG target to the NFQUEUE or QUEUE targets instead, and at the same time builds a parallel Snort rule set in the /etc/fwsnort/snort_rules_queue directory. Every Snort rule in this directory has at least one "content" keyword, which fwsnort uses in the resulting iptables policy. This policy only sends those packets to snort_inline via the NFQUEUE or QUEUE target that match a content field within some Snort rule. The end result is that snort_inline should run faster because the vast majority of packets (which are not malicious) are processed via the Linux kernel without ever having to be sent to userspace for analysis. There is a tradeoff here in terms of attack detection; snort_inline does not receive all packets associated with a stream, so it cannot detect attacks quite as effectively (snort_inline does not have an opportunity to look at reassembled buffers). However, this trade off may be acceptable for large sites where performance is more important.
• Bug fix to remove any existing jump rules from the built-in INPUT, OUTPUT, and FORWARD chains before creating a new jump rules. This allows the fwsnort.sh script to be executed multiple times without creating a new jump rule into the fwsnort chains for each execution.
• Added the -X command line argument to allow fwsnort to delete all of the fwsnort chains; this emulates the iptables command line argument of the same name.
• Minor output enhancements and bugfixes to give more insight into the translation process. For example, if fwsnort is run in --snort-sid mode but is unable to translate the specified signatures, the user is notified. Also, any existing /etc/fwsnort/fwsnort.sh script is not archived and erased until fwsnort is actually going to write a new one.
• Added sid values to iptables comment match string.
• Bugfix for iptables string match --from and --to values to skip past packet headers. This is an approximation until a new --payload option can be added to the string match extension.
• Added a single iptables rule testing API internally within fwsnort; this adds a measure of consistency and removes some duplicate code.
• Added fwsnort mailing list at SourceForge.

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.

OSCON 2007 Talk on iptables Visualization

At the O'Reilly Open Source Convention of 2007 (July 23-27, Portland, Oregon) I will give a talk about visualizing iptables log data. Here is the talk abstract:

The iptables logging format provided by the Netfilter project contains a wealth of detailed information about network traffic. Nearly every interesting field in the network and transport layer headers is logged by iptables. By combining the graphing capabilities of AfterGlow with the attack detection capabilities of psad it is possible to render eye-catching graphical visualizations of network attacks. These visualizations can expose important relationships between attackers and their targets that are difficult to acquire in via non-graphical means. This talk will analyze iptables log data from two sources: the Honeynet Project, and from an Internet-facing Linux system. This data contains instances of the Nachi and Slammer worms, and suspicious outbound SSH and IRC connections from compromised systems. In addition, material from the book "Linux Firewalls: Attack Detection and Response" will be presented to show you how to deploy psad on a live firewall. As more people run Linux, mountains of iptables log data are piling up. It is time to maximize the effectiveness of this data and mine it for suspicious traffic and network-based attacks. This talk will show you how.

CipherDyne Blogspot Page Created

The current CipherDyne website is managed by a set of custom perl scripts that creates and edits a series of static HTML pages. This eliminates CGI scripts, which is good for security, but it means that people cannot leave comments for stories that are posted to the CipherDyne blog. I have created a parallel blog on Blogspot so that comments can be tied to stories. Another consequence is that Google searches for content related to CipherDyne projects and concepts may become more effective depending on how the new blog is indexed. The content on the new blog will be largely the same as the original, but occasionally I may post some stories there that are more speculative in nature than the generally technical or "software release" posts on the main blog. If people have comments about the stories, please post them on the new blog for all to see. In the spirit of open source development, this is the best way to share new ideas about the topics discussed here.

fwsnort Mailing List Started

The fwsnort project has been around for several years now, but has never had a dedicated forum for discussion of development and deployment issues that are unique to making heavy use of the Netfilter string match extension as done by fwsnort. That's changed now with the introduction of the fwsnort mailing list generously provided by SourceForge. If you are interested in learning more about fwsnort and would like to ask questions or post comments, the mailing list is the place to do it!

Protecting SSH Servers with Single Packet Authorization

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..."

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.