cipherdyne.org | System and Network Security

Software Release - fwsnort-1.6.2

Michael Rash — 2012-04-28T21:01:30-05:00

The 1.6.2 release of fwsnort is available for download. The most impactful change in this release is a switch to how fwsnort loads translated rules into the running iptables policy. Instead of attempting to parse the local policy and only add those rules in that appear to match protocols that the policy allows, fwsnort now loads all translated rules by default. The reasoning for this change is in the ChangeLog below. There are a few bug fixes and updates to get fwsnort working without warnings on recent versions of perl as well as an ICMP type fix for recent versions of iptables. As usual, please let me know if there are any issues.

Here is the complete fwsnort-1.6.2 ChangeLog:

Switched --no-ipt-sync to default to not syncing with the iptables policy. By default fwsnort attempts to match translated Snort rules to the running iptables policy, but this is tough to do well because iptables policies can be complex. And, before fwsnort switched to the iptables-save format for instantiating the policy, a large set of translated rules could take a really long time to make active within the kernel. Finally, many Snort rules restrict themselves to established TCP connections anyway, and if a restrictive policy doesn't allow connections to get into the established state for some port let's say, then there is little harm in having translated Snort rules for this port. Some kernel memory would be wasted (small), but no performance would be lost since packets won't be processed against these rules anyway. The end result is that the default behavior is now to not sync with the local iptables policy in favor of translating and instantiating as many rules as possible.
Replaced Net::IPv4Addr with the excellent NetAddr::IP module which has comprehensive support for IPv6 address network parsing and comparisons.
Moved the fwsnort.sh script and associated files into the /var/lib/fwsnort/ directory. This was suggested by Peter Vrabec.
Bug fix for recent versions of iptables (such as 1.4.12) where the icmp match requires --icmp-type to be set - some Snort rules look for a string to match in icmp traffic, but don't also specify an icmp type.
Bug fix for 'qw(...) usage as parenthesis' warnings for perl > 5.14
Removed the ExtUtils::MakeMaker RPM build requirement from the fwsnort.spec file. This is a compromise which will allow the fwsnort RPM to be built even if RPM doesn't or can't see that ExtUtils::MakeMaker is installed - most likely it will build anyway. If it doesn't, there are bigger problems since fwsnort is written in perl. If you want to build the fwsnort RPM with a .spec file that requires ExtUtils::MakeMaker, then use the "fwsnort-require-makemaker.spec" file that is bundled in the fwsnort sources.

Software Release - psad-2.2

Michael Rash — 2012-04-21T21:01:30-05:00

After a long development cycle, the 2.2 release of psad is available for download. This release adds major new functionality for the detection of malicious traffic that is delivered over IPv6 by parsing ip6tables logs. A significant portion of this capability is enabled by the excellent NetAddr::IP CPAN module that can properly handle IPv6 addresses. In addition, speed optimizations have been made that result in psad-2.2 being about 15% faster than previous releases, several bugs have been fixed (including one that caused compile time warnings on recent versions of perl), and a comprehensive test suite has been added. psad-2.2 is a stepping stone to the upcoming psad-3.0 release that will include support for both PF and ipfw firewalls running on *BSD systems. Quite a bit of this work has already been done in the openbsd_integration branch.

Here is an excerpt of the psad-2.2 ChangeLog:

Added support for detection of malicious traffic that is delivered via IPv6. This is accomplished by parsing ip6tables log messages - these are in a slightly different format than the iptables log messages. Here is an example:

Mar 17 13:39:13 linux kernel: [956932.483644] DROP IN=eth0 OUT= MAC=00:13:46:3a:41:36:00:1b:b9:76:9c:e4:86:dd SRC=2001:0db8:0000:f101:0000:0000:0000:0002 DST=2001:0db8:0000:f101:0000:0000:0000:0001 LEN=80 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=TCP SPT=50326 DPT=993 WINDOW=5760 RES=0x00 SYN URGP=0

Detection of malicious IPv6 traffic can be disabled via a new ENABLE_IPV6_DETECTION config variable.
For ICMP6 traffic, added protocol validation for ICMP6 type/code combinations.
Added a new test suite in the test/ directory to validate psad run time operations (scan detection, signature matching, and more). To support this, a new '--install-test-dir' option was added to the install.pl script. Once this is executed, the test suite can be run via the test-psad.pl script in the test/ directory.
Added a new MAX_SCAN_IP_PAIRS config variable to allow psad memory usage to be constrained by restricting the number of unique IP pairs that psad This is useful for when psad is deployed on systems with little memory, and is best utilized in conjunction with disabling ENABLE_PERSISTENCE so that old scans will also be deleted (and thereby making room for tracking new scans under the MAX_SCAN_IP_PAIRS threshold).
Bug fix for 'qw(...) usage as parenthesis' warnings for perl > 5.14
Bug fix that caused psad to emit the following:

Undefined subroutine &main::LOG_DAEMON called at ./psad line 10071.

This problem was noticed by Robert and reported on the psad mailing list.
Bug fix for ICMP packet handling where psad would incorrectly interpret ICMP port unreachable messages as UDP packets because the UDP specifics are included in the iptables log message. This bug was first reported by Lukas Baxa to the Debian maintainers and was followed up by Franck Joncourt: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596240 An example ICMP log message that exposed the bug is included below:

Sep 8 18:04:26 baxic kernel: [28241.572876] IN_DROP IN=wlan0 OUT= MAC=00:1a:9f:91:df:ae:00:21:27:e8:0a:a0:08:00 SRC=10.0.0.138 DST=192.168.1.103 LEN=96 TOS=0x00 PREC=0xC0 TTL=254 ID=63642 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.1.103 DST=10.0.0.138 LEN=68 TOS=0x00 PREC=0x00 TTL=0 ID=22458 PROTO=UDP SPT=35080 DPT=33434 LEN=48 ]

The complete psad-2.2 ChangeLog can be found here via the psad gitweb interface.

cipherdyne.org git Repositories Safe After github Hack

Michael Rash — 2012-03-07T21:01:30-05:00

After a widely publicized hack of github (now fixed), I thought it would be a good idea to ensure that the cipherdyne.org git repositories remain secure on both github and on the cipherdyne.org webserver. The techniques in the blog post may not be well suited to large git repositories with a lot of different people able to commit code, but for my repositories these checks provide a fairly high level of confidence that no malicious code has been introduced. First, the github hack was made possible through a "mass assignment" vulnerability in Ruby on Rails, and would have permitted an attacker to gain admin privileges to any project on github. Once admin access is acquired, an attacker would be in a position to do anything to the underlying code base - including adding new code that implements "undocumented features".

Now, in order to add a backdoor into a code base on github, what would an attacker need to do?

Altering the code base for a project would need to be done through standard git operations as a new commit - i.e., make code changes to a local copy, git add ..., git commit ... - as opposed to manually editing previously committed code in the git repository itself. This is because every commit must match a corresponding SHA1 hash according to git's object model, and a SHA1 collision such that the bogus data is also working code would be "computationally difficult" to say the least (attacks against SHA1 not withstanding). As a basic check, one can create a git repository for testing purposes, write a random byte to a random position within the .git/objects/pack/*.pack file and then try to clone it to see what happens:

error: packfile ./objects/pack/pack-9c886ed427d9a7538093f09edf516a0a718201ac.pack does not match index
error: packfile ./objects/pack/pack-9c886ed427d9a7538093f09edf516a0a718201ac.pack cannot be accessed
fatal: git upload-pack: cannot find object 7e8e48412ff985461095a09874059e955145d513:
fatal: The remote end hung up unexpectedly

The repository has essentially been corrupted and the clone operation fails.

Ok, so a malicious code modification would most likely need to be done via an entirely new commit. This could certainly be done by an attacker, but anyone who has cloned the repository would be able to see the change. For a large, highly active project without rigorous code review and committer hierarchy, it is conceivable that such a change might just get lost within the noise of lots of commits. After all, a human would need to review the change and recognize it as being malicious.

Could such a malicious code change affect the cipherdyne.org projects? In a word, "no", and here's why: all commits to the cipherdyne.org code bases are pushed to github from private git repositories on a dedicated system that is not generally accessible, and git pull ... is only done occasionally and every change comes from a known source and is reviewed. The accessible non-private git repositories on cipherdyne.org are mirrors of the github repositories, so if a malicious change were introduced into github, then they would have this change too. The private repositories would still be safe however. So, given this work flow, what I need is a way to verify that there are no commits in either the github repositories or cipherdyne.org mirrors that are not in private repositories. Further, I would like to be able to verify this without having to push or pull code into the private repositories (so I can regularly check at any time without any modifications coming through). There are probably many ways to do this in the git world - for example, one could just use git fetch to bring in changes into remote tracking branches and compare these against local branches (any malicious code would not be merged into a local branch after it is discovered), but here is an alternate solution:

On my system where the private repositories live, create two directories GH/ and CD/, and clone all of the github repositories into the GH directory and all cipherdyne.org repository mirrors into the CD directory. We'll assume that the private repositories live in a directory called private/
For each repository pair in the GH and CD directories, diff the output of git rev-list --all. There should be zero differences here.
If the step above checks out, then diff the git rev-list --all output across the GH/ and private/ pairs. For this step we expect that the private repositories will have local commits that are not necessarily pushed upstream - what we're concerned about is any commit in a GH/ that is not in a private/.

Here are a few commands to accomplish the above (we'll assume that the git clone --bare steps have already been done for brevity):

$ for r in fwknop psad gpgdir fwsnort IPTables-Parse IPTables-ChainMgr
> do
> echo "[+] Checking $r...";
> diff -u <(cd ~/CD/$r.git && git rev-list --all ) <( cd ~/GH/$r.git && git rev-list --all)
> done
[+] Checking fwknop...
[+] Checking psad...
[+] Checking gpgdir...
[+] Checking fwsnort...
[+] Checking IPTables-Parse...
[+] Checking IPTables-ChainMgr...

The output above indicates there are identical git commits in the github repositories vs. the cipherdyne.org mirrors. Good. Now, let's compare the github repositories vs the private ones - we grep on "+" which would indicate new commits in github that are not in the private repositories:

$ for r in fwknop psad gpgdir fwsnort IPTables-Parse IPTables-ChainMgr
> do
> echo "[+] Checking $r...";
> diff -u <(cd ~/private/$r.git && git rev-list --all ) <( cd ~/GH/$r.git && git rev-list --all) | egrep "^\+" | grep -v @
> done
[+] Checking fwknop...
+++ /dev/fd/62  2012-03-07 22:50:48.004281002 -0500
[+] Checking psad...
+++ /dev/fd/62  2012-03-07 22:50:48.054281002 -0500
[+] Checking gpgdir...
+++ /dev/fd/62  2012-03-07 22:50:48.164281002 -0500
[+] Checking fwsnort...
+++ /dev/fd/62  2012-03-07 22:50:48.194281002 -0500
[+] Checking IPTables-Parse...
[+] Checking IPTables-ChainMgr...

Again, good, no commits in github that are not in the private repositories. If there had been a line like the following I would have been concerned:

+fff688f5b4275152636d8959f67bbcd46839fbbb

Rather than modifying code and committing it to a git repository on github, it would have been far more damaging for an attacker to just alter the github website to serve up drive by exploits for a popular web browser. Either way, I'm glad they fixed the vulnerability.

On SPA Cross-Packet Ciphertext Entropy

Michael Rash — 2012-02-13T21:01:30-05:00

With fwknop now re-written in C for the 2.0 release, I thought it would be a good idea to take a look at how close encrypted SPA packet data comes to having high levels of entropy - as understood to be a measure of randomness - from one packet to the next. If fwknop is properly using encryption, and the ciphers themselves are also well-implemented (fwknop can use either Rijndael or GPG), then we would expect there to be no obvious relationship between SPA packets even for repeated access requests to the same service. If there are any such relationships in the encrypted data across multiple SPA packets, then an adversary might be able to infer things about the underlying plaintext - precisely what strong encryption is supposed to make difficult. This blog post covers SPA packet entropy for AES (Rijndael) CBC and ECB encryption modes, and leaves GPG to another post.

Although this post has some similarities with an older blog entry "Visualizing SPA Packet Randomness", a more rigorous and automated way of measuring cross-packet SPA entropy will be presented. In addition, we'll take a look at what happens when (normally) random salt values for AES encrypted SPA packets are artificially forced to be constant. This helps to highlight some real differences in AES electronic codebook (ECB) and cipher block chaining (CBC) encryption modes.

First, the next release of fwknop will most likely offer the ability to select different AES encryption modes (such as cipher feedback (CFB) mode and output feedback (OFB) mode), and a dedicated "crypto_update" branch has been created for this work. The default AES encryption mode used by fwknop is cipher block chaining (CBC) mode as defined here. Within the crypto_update branch there is a new script "spa-entropy.pl" that is designed to execute the fwknop client multiple times, collect the encrypted SPA packet data, use the ent program to measure the entropy in slices for each byte position across the SPA data set, and then plot the results with gnuplot. What does this accomplish? It allows us to easily see for any given byte position within a collection of SPA packets whether there is a relation from one to the next. If there is such a relation, then the cipher used to encrypt the data was not very good at achieving high levels of entropy in the ciphertext across multiple packets.

As a motivating example from Wikipedia, AES in ECB mode encrypts identical plaintext blocks into identical ciphertext blocks, and this results in patterns in plaintext data being preserved to some extent in the ciphertext. So, an adversary can make good guesses about the underlying plaintext just by looking at the ciphertext! Wikipedia does a nice job of illustrating this with the following two images of the Linux kernel mascot "Tux" - before and after AES encryption in ECB mode:

AES ECB encryption ->

Encryption Fail.

Now, let's take a look at SPA packet entropy with the spa-entropy.pl script. For reference, fwknop builds SPA packets according to the following data format before encryption:

[random data: 16 bytes]:[username]:[timestamp]:[version]:[message type]:[access request]:[digest]

So, if a user wants repeated access to the same service protected behind fwknopd on some system, then several fields above will be identical across the corresponding SPA packets before they are encrypted. The username, version, message type, and access request fields will likely be the same. If fwknop has made proper use of encryption, then the fact that these fields are the same across multiple SPA packets should not matter. After encryption, an observer should not be able to tell anything about the underlying plaintext (other than perhaps size since AES is a block cipher). Let's verify this for 1,000 SPA packets encrypted with the default CBC mode - they are all encrypted with the same key 'fwknoptest' by the spa-entropy.pl script:


$ ./spa-entropy.pl -f 1000_pkts.data -r -c 1000 --base64-decode

[+] Running fwknop client via the following command:



LD_LIBRARY_PATH=../../lib/.libs ../../client/.libs/fwknop -A tcp/22 -a 127.0.0.2 -D 127.0.0.1 --get-key local_spa.key -B 1000_pkts.data -b -v --test -M cbc



[+] Read in 1000 SPA packets...

[+] Min entropy: 7.75 at byte: 54

[+] Max entropy: 7.86 at byte: 115

[+] Creating entropy.gif gnuplot graph...

This produces the gnuplot graph below. Perfectly random data would produce 8 bits of entropy per byte, and the min/max values of 7.75 and 7.86 along with the fairly uniform distribution of similar values across all of the SPA byte positions implies that there is little relation from one SPA packet to the next - good. As an aside, here is what ent reports against the local /dev/urandom entropy source on my Linux system, and it is the "Entropy =" line that spa-entropy.pl parses for each SPA byte slice:


$ dd if=/dev/urandom count=1000 |ent

1000+0 records in

1000+0 records out

512000 bytes (512 kB) copied, 0.128497 s, 4.0 MB/s

Entropy = 7.999625 bits per byte.



Optimum compression would reduce the size

of this 512000 byte file by 0 percent.



Chi square distribution for 512000 samples is 265.77, and randomly

would exceed this value 50.00 percent of the times.



Arithmetic mean value of data bytes is 127.5076 (127.5 = random).

Monte Carlo value for Pi is 3.138715386 (error 0.09 percent).

Serial correlation coefficient is -0.001293 (totally uncorrelated = 0.0).

Now, let's switch to ECB mode and see what happens (just run the spa-entropy.pl script with '-e ecb'): Well, that still looks pretty good. Revisiting the ECB encrypted image of Tux above for a moment - the reason that the Tux outline can be seen in the encrypted version is that in the JPG image file there must be identical blocks in multiple locations to represent the solid black regions. These blocks are all encrypted in the same way by AES in ECB mode, so the outline persists. But, this is one instance of ECB encryption against a file that has multiple identical blocks. For the encrypted SPA packets, we're dealing with 1,000 separate instances of encrypted data (all with the same key). Across this data set there are certainly lots of identical plaintext blocks (all of the SPA packets request access for source IP 127.0.0.2 to destination port tcp/22 for example), but the encrypted data still shows a high level of entropy. This source of entropy is provided by the random salt values that are used to generate the initialization vector and final encryption key for each encrypted SPA packet. As proof, if we apply the following patch to force the salt to zero for all SPA packets (of course, one would not want to use this patch in practice):


$ git diff lib/cipher_funcs.c

diff --git a/lib/cipher_funcs.c b/lib/cipher_funcs.c

index 0a0ce3b..32c8bd6 100644

--- a/lib/cipher_funcs.c

+++ b/lib/cipher_funcs.c

@@ -153,6 +153,8 @@ rij_salt_and_iv(RIJNDAEL_context *ctx, const char *pass, const unsigned char *da

         get_random_data(ctx->salt, 8);

     }

 

+    memset(ctx->salt, 0x00, 8);

+

     /* Now generate the key and initialization vector.

       * (again it is the perl Crypt::CBC way, with a touch of

       * fwknop).

Here is what spa-entropy.pl reports after recompiling fwknop with the patch above: Now we can easily see where there are identical blocks across the SPA packet data set. The first eight bytes contains the salt, so these are all zero (note that fwknop strips the usual "Salted__" prefix before transmitting an SPA packet on the wire). The next 16 bytes are the random bytes that fwknop includes in every SPA packet so these bytes have high entropy. Next up are the username and timestamp - the later changes with each second, so there is some entropy there since it takes a few seconds to create the 1,000 SPA packet data set. Then the entropy goes back to zero with the next fields and there isn't any decent entropy until the final message digest.

As a final contrasting case, let's leave the patch applied to force the salt to zero, but now switch back to CBC mode: In CBC mode, the random data included by the fwknop client now results in decent entropy even though the salt is zero. This is because every ciphertext block in CBC mode depends on all previous plaintext blocks, so randomness in one plaintext block implies that every subsequent encrypted block will look different from one SPA packet to the next. This graphically shows that CBC mode is a better choice for strong security. Now, if the pseudo random number generator on the local operating system is poorly implemented, this will negatively impact ciphertext entropy regardless of the encryption mode, but still CBC mode is a better alternative than ECB mode.

Although spa-entropy.pl is geared towards measuring SPA packet entropy, this technique could certainly be generalized to arbitrary collections of ciphertext. If you know of such an implementation, please email me.

Bing Indexing of gitweb.cgi Links

Michael Rash — 2012-01-21T21:01:30-05:00

In June, 2011, all of the cipherdyne.org software projects were switched over to git from svn, and at the same time the web interface was switched to gitweb (along with hosting at github) from trac. Given the switch, I knew there would be a change to how search engines indexed the code/data, and one question would be whether any particular search engine would take a specific interest in the code provided via git and/or gitweb. Note that each of the fwknop, psad, fwsnort, and gpgdir projects have raw git repositories that can be cloned directly over HTTP from cipherdyne.org (a nice feature of git), or viewed with any browser through gitweb. (Personally, I like the "links2" text-based browser rendering of gitweb pages - nice and clean.)

First, here are some stats for indexing bots from major search engines across all cipherdyne.org Apache log data for hits against gitweb.cgi from June, 2011 to today:

Hits	Percentage	User-Agent
505055	81.01%	Mozilla/5.0 (compatible; bingbot/2.0;)
50242	8.06%	msnbot/2.0b (+http://search.msn.com/msnbot.htm)._
25707	4.12%	Mozilla/5.0 (compatible; Ezooms/1.0; ezooms.bot@gmail.com)
6583	1.06%	Feedfetcher-Google; (+http://www.google.com/feedfetcher.html;)
4310	0.69%	Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
1956	0.31%	Mozilla/5.0 (compatible; SISTRIX Crawler; http://crawler.sistrix.net/)
1905	0.31%	Mozilla/5.0 (compatible; Purebot/1.1; +http://www.puritysearch.net/)
1751	0.28%	Mozilla/5.0 (compatible; Yahoo! Slurp;)
1625	0.26%	Mozilla/5.0 (compatible; MJ12bot/v1.4.0;)
1451	0.23%	TwengaBot-Discover (http://www.twenga.fr/bot-discover.html)

Wow! So bots associated with Microsoft's Bing search engine take the top two spots for a combined hit total of well over 500,000 since June, 2011. If spread out over the entire time period (which it's not as we'll see) that would be an average of about 2,600 hits per day, and this figure is more than 20 times the third place bot. Google is in a distant forth place, even though Google used to heavily index Trac repositories.

So, let's see how the search engine hits are distributed since June, 2011. First, here is a graph of just gitweb hits by the top five crawlers: Clearly, that is not a very uniform distribution from day to day. It looks like Bing has been hitting the gitweb interface at a rate of over 17,000 hits per day for a significant portion of late December and early January. The other search engines hardly even show up in the graph - you know there are big spikes when everything looks better on a logarithmic scale: With some additional work, it looks like the gitweb.cgi links that Bing is indexing are not all unique. That is, one might expect that Bing would hit a link, grab the content, and then not return to the same link for a while. Some gitweb.cgi links were hit more than 10 times and more than 100,000 links were hit more than once during this time period.

How does this compare with hits across other portions of cipherdyne.org? Bing indexing is still far and away the largest outlier: Given that 1) all of the information gitweb displays is derived from the underlying git repositories, and 2) the git repositories are directly accessible via HTTP anyway, it would seem that a better way for search engines to behave would be to just ignore gitweb altogether and pull directly from git. That would certainly cut down on the server-side resources necessary to service search engine requests. Perhaps though the general strategy of search engines is not to be too smart about such things - they probably just want access to data, and when they see a link they go after it. Either way, the kind of dedicated and repetitive indexing the Bing is doing against gitweb is a bit much, and it certainly seems as though they could implement a less intensive crawler. I'm curious if other server admins are seeing similar behavior.

Update 01/23: There are tons of web analysis tools out there, but I wrote a couple of quick scripts to generate the data in this blog post. The first "user_agent_stats.pl" parses Apache logs and produces user-agent graphs with Gnuplot as shown in this post. The second "uniq_hits.pl" is extremely simple and just counts the number of hits against the same links within the Apache log data. Both scripts accept log data via TDIN - here is an example where user agents who hit any "index.html" link are plotted (graph is not shown):


$ zcat ../logs/cipherdyne.org*.gz |grep "index.html" | ./user_agent_stats.pl -p index_hits

[+] Parsing Apache log data...

[+] Total agents: 1769 (abbreviated to: 174 agents)

[+] Executing gnuplot...

    Plot file:  index_hits.gif

    Agent stats: index_hits.agents

Software Release - fwknop-2.0

Michael Rash — 2012-01-02T21:01:30-05:00

After a long development cycle, fwknop-2.0 has been released. This is the first production release of the fully re-written C version of fwknop, and is the culmination of an effort to provide Single Packet Authorization to multiple open source firewalls, embedded systems, mobile devices, and more. On the "server" side, supported firewalls now include iptables on Linux, ipfw on FreeBSD and Mac OS X, and pf on OpenBSD. The fwknop client is known to run on all of these platforms, and also functions on Windows systems running under Cygwin. There is also an Android client, and a good start on a iPhone client as well. On a personal note, I wish to thank Damien Stuart for a heroic effort to port most of the original perl code over to C. Also, several other people have made significant contributions including Jonathan Bennet, Max Kastanas, Sebastien Jeanquier, Ozmart, and others. If there are any issues, please get in touch with me directly or send an email to the fwknop mailing list.

Update 01/03: Both libfko library that powers much of fwknop operations and the fwknop client can be compiled as native Windows executables. In addition, there are perl and python bindings to libfko as well.

Update 01/07: Damien Stuart has built RPM files for fwknop on RHEL5, RHEL6, Fedora 15, 16, and 17 and for other architectures the Fedora koji build system can produce.

Software Release - fwknop-2.0rc5

Michael Rash — 2011-12-11T21:01:30-05:00

The 2.0rc5 candidate release of fwknop is available for download. There may be a few tweaks to the code before the official 2.0 release is made, but this is pretty close as-is. Significant development work has gone into fwknop since the 2.0rc4 release, and adds some major new functionality as well as fixing a few bugs. Here is a summary of the changes:

iPhone fwknop client: Max Kastanas has contributed an iPhone port of the fwknop client. He had already contributed on Android client, so the iPhone was the next natural step! We're looking for a maintainer of the iPhone code so that eventually it can be made available through the App Store. If you have iPhone development experience and are interested in taking this on, please contact me.

PF firewall support on OpenBSD: For quite a while now fwknop has brought Single Packet Authorization support to iptables firewalls on Linux and ipfw firewalls on FreeBSD and Mac OS X systems. The 2.0rc5 release now introduces support for the PF firewall on OpenBSD systems. By interfacing with the pfctl command, fwknop creates new rules to access a protected service (such as SSHD) to a PF anchor. Rules are deleted out of a running anchor with pfctl -a -f - with the expired rule(s) removed. There is support in the fwknop test suite (see the test/ directory in the fwknop-2.0rc5 sources) to validate fwknop operations on OpenBSD systems, and if there are any issues please let me know.

Expiring SPA keys: With large SPA deployments where many different encryption keys - either Rijndael or GPG keys - are used to service lots of external users, key management can become somewhat of a burden. This feature allows an expiration date to be set in the access.conf file on a per-key basis. Any SPA packet received for an expired key is ignored by fwknopd. This feature was suggested by ozmart from the fwknop mailing list.

FORCE_NAT mode: For iptables firewalls, a new FORCE_NAT mode has been implemented that works as follows: for any valid SPA packet, force the requested connection to be NAT'd through to the specified (usually internal) IP and port value. This is useful if there are multiple internal systems running a service such as SSHD, and you want to give transparent access to only one internal system for each stanza in the access.conf file. This way, multiple external users can each directly access only one internal system per SPA key.

lsof launcher: The fwknop lsof launcher (extras/fwknop-launcher/fwknop-launcher-lsof.pl) is a lightweight daemon that allows the user to not have to manually run the fwknop client when attempting to gain access to a service that is protected by via fwknopd. This is accomplished by checking the output of lsof to look for pending connections in the SYN_SENT state, which (usually) indicate that a remote firewall is blocking the attempted connection. At this point, the launcher executes the fwknop client with the --get-key arg (so the user must place the key in the local filesystem) to generate an SPA packet for the attempted connection. The remote fwknopd daemon will reconfigure the firewall to allow temporary access, and this usually happens fast enough that the original connection attempt will then succeed as TCP retries to establish the connection. The idea for this was originally for a pcap-based connection watcher by Sebastien Jeanquier.

Several other changes and small fixes have been made as well. The fwknop test suite supports running all tests through the excellent valgrind project, and this enabled several memory handling issues to be found and corrected.

fwknop is released under the GPL version 2, and the complete fwknop-2.0rc5 ChangeLog can be found here via the fwknop gitweb interface.

WebKnock.org Single Packet Authorization Proxy

Michael Rash — 2011-10-10T21:01:30-05:00

Vasilis Mavroudis has developed a web proxy called WebKnock.org that allows anyone to generate an fwknop SPA packet on their behalf with just a web browser. Although fwknop client portability has improved quite a bit in anticipation of the upcoming fwknop-2.0 release, it is a nice addition to the SPA world to not need the fwknop client installed at all. There are probably several platforms where the native client might not function but can run a web browser.

Using the webknock.org proxy requires that the user provide the SPA key over SSL to webknock.org, but this is a necessary step in exchange for not having to install the fwknop client. As of this writing, SPA via gpg keys is not yet supported, but there are plans to support this in the future. All requests to generate an SPA packet are protected by a captcha.

Behind the scenes, webknock.org executes the fwknop client on behalf of users, and Vasilis informed me that he's using the latest client code (written in C) instead of the older perl client. This is good since all recent development is done on the C version of fwknop in order to make it as small and lightweight as possible.

The service is free, and will hopefully be open-sourced at some point as well. If there are any issues, please either email me or open a ticket on the fwknop github interface. Here is a screenshot of the current webknock.org site:

fwknop in the OpenWrt and Pentoo Linux Distributions

Michael Rash — 2011-08-23T21:01:30-05:00

The C version fwknop has now made it into the OpenWrt Linux distribution for embedded devices. Jonathan Bennett made this possible by contributing a Makefile for OpenWrt, and it was picked up the OpenWrt maintainers. It is good to see progress made towards the integration of Single Packet Authorization into operating systems that are designed to function as secure gateway devices between multiple networks.

So far, fwknop is available in the OpenWrt trunk packages feed, but will eventually become available via the opkg package manager too. Fortunately, OpenWrt makes everything available via git:


$ git clone git://nbd.name/packages.git openwrt_packages.git

Initialized empty Git repository in /home/mbr/src/openwrt_packages.git/.git/

remote: Counting objects: 56118, done.

remote: Compressing objects: 100% (21342/21342), done.

remote: Total 56118 (delta 29694), reused 54875 (delta 29054)

Receiving objects: 100% (56118/56118), 11.85 MiB | 2.57 MiB/s, done.

Resolving deltas: 100% (29694/29694), done.

$ cd openwrt_packages.git

$ git ls-files |grep fwknop

net/fwknop/Makefile

$ git log net/fwknop/Makefile

commit 89475e5d6136833fa3b59c3d47c4f2be02718c7a

Author: florian 

Date:   Wed Aug 17 10:13:20 2011 +0000



    [package] add fwknopd



    Signed-off-by; Jonathan Bennett <[email removed]>



    git-svn-id: svn://svn.openwrt.org/openwrt/packages@28030 3c298f89-4303-0410-b956-a3cf2f4a3e73

In other news, both the perl and C versions of fwknop are also available in the Pentoo Linux distribution thanks to ozmart and the Pentoo maintainers. Pentoo is a live-cd distribution that is focused on security and derived from Gentoo. ozmart wrote a description of the use case for fwknop on Pentoo from a pentration testing perspective:

"...This is a useful script when combined with iptables and sshd. Configuration can accommodate pgp and replay attack checks. It allows the box to appear silent when running daemons if your box is deployed in say, a hostile environment.

It can also allow commands to be run without actually having to log into the box, say if you wanted to trigger something interesting from a remote location..."

Software Release - fwsnort-1.6

Michael Rash — 2011-07-28T21:01:30-05:00

The 1.6 release of fwsnort is available for download. This is a fairly significant release that adds support for the Snort fast_pattern keyword, makes enhancements to the --QUEUE and --NFQUEUE modes, supports the conntrack module for connection tracking, adds support for case-insensitive pattern matches using the --icase argument to the iptables string match extension, and several other things. The Snort fast_pattern keyword allows the rule author to influence the order in which Snort tries to match a pattern against network traffic. When multiple patterns are included in a rule, Snort usually tries to match the longest pattern first reasoning that the longest pattern is probably the least likely to trigger a match and therefore the remaining pattern searches would not have to be performed. But, there are times when the rule author would like to explicitly ask Snort to match on a particular pattern first, and the fast_pattern keyword is the mechanism that makes this possible. Because iptables matches are evaluated in order and a failing match short circuits a rule, fast_pattern support with the string match extension is possible through proper ordering in the iptables rule. Here is an example Snort rule from Emerging Threats with the fast_pattern keyword applied to the forth pattern:


alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET WEB_CLIENT Possible Internet Explorer srcElement Memory Corruption Attempt"; flow:established,to_client; file_data; content:"document.createEventObject"; distance:0; nocase; content:".innerHTML"; within:100; nocase; content:"window.setInterval"; distance:0; nocase; content:"srcElement"; fast_pattern; nocase; distance:0; classtype:attempted-user; reference:url,www.microsoft.com/technet/security/bulletin/ms10-002.mspx; reference:url,tools.cisco.com/security/center/viewAlert.x?alertId=19726; reference:url,www.kb.cert.org/vuls/id/492515; reference:cve,2010-0249; reference:url,doc.emergingthreats.net/2010799; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_MSIE; sid:2010799; rev:5;)

fwsnort translates this rule as follows in iptables-save format from the /etc/fwsnort/fwsnort.save file - the original iptables commands in non-save format are also available in the /etc/fwsnort/fwsnort_iptcmd.sh script:


-A FWSNORT_FORWARD_ESTAB -p tcp -m tcp --sport 80 -m string --string "srcElement" --algo bm --from 82 --icase -m string --string "document.createEventObject" --algo bm --from 64 --icase -m string --string ".innerHTML" --algo bm --to 190 --icase -m string --string "window.setInterval" --algo bm --from 74 --icase -m comment --comment "sid:2010799; msg:ET WEB_CLIENT Possible Internet Explorer srcElement Memory Corruption Attempt; classtype:attempted-user; reference:url,www.microsoft.com/technet/security/bulletin/ms10-002.mspx; rev:5; FWS:1.6;" -j LOG --log-ip-options --log-tcp-options --log-prefix "SID2010799 ESTAB "

Note that the srcElement string is matched first in the iptables rule even though it is the last string in the original Snort rule. With fast_pattern support, fwsnort policies should be a bit faster at run time in the in the Linux kernel. On a final note, the iptables multiport match is also supported with the fwsnort-1.6 release, so Snort rules with lists of source or destination ports (like this: "alert tcp $HOME_NET [0:20,22:24,26:138,140:444,446:464,466:586,588:901,903:1432,1434:65535] -> any any") can be translated.

The complete fwsnort-1.6 ChangeLog can be found here via the fwsnort gitweb interface.

Switched from subversion to git

Michael Rash — 2011-06-26T21:01:30-05:00

After using subversion for several years, I've switched to git for all cipherdyne.org projects. Subversion has certainly served its purpose, but it is hard to look at git and not feel a compelling draw. Further, with easy to set up web interfaces to git repositories such as gitweb and free hosting services such as github, providing a public git repository is trivial. Git itself can allow repositories to be cloned directly over HTTP without needing infrastructure like WebDAV, and here are links for the cipherdyne.org projects (github and gitweb links too):

The trac interface will remain active for a little while to see the legacy svn repositories, but the git repositories were all converted from these in order to preserve the history so trac is no longer important. If you are interested in the latest code changes in, say, fwsnort then just clone the repository and then you can make your own changes:


$ git clone http://www.cipherdyne.org/git/fwsnort.git

Initialized empty Git repository in /home/mbr/tmp/git/fwsnort/.git/

$ cd fwsnort

$ git status

# On branch master

nothing to commit (working directory clean)

$ git show --summary

commit 00c4379a69975097948ed9e5ba356eeba69c0c93

Author: Michael Rash 

Date:   Mon Jun 20 21:00:57 2011 -0400



    Added the --Conntrack-state argument



    Added the --Conntrack-state argument to specify a conntrack state in place of

    the "established" state that commonly accompanies the Snort "flow" keyword.

    By default, fwsnort uses the conntrack state of "ESTABLISHED" for this.  In

    certain corner cases, it might be useful to use "ESTABLISHED,RELATED" instead

    to apply application layer inspection to things like ICMP port unreachable

    messages that are responses to real attempted communications.  (Need to add

    UDP tracking for the _ESTAB chains for this too - coming soon.)

fwknop in BackTrack 5

Michael Rash — 2011-06-23T21:01:30-05:00

fwknop has made it into BackTrack Linux distribution. Well, it didn't make it into the default image, but it is in the BackTrack software repository so installing it is a snap with apt-get or aptitude. Below is a screenshot of the BackTrack 5 VM installed under VMware Player running on Ubuntu, and running a search shows both the fwknop-client and fwknop-server packages that are maintained by Franck Joncourt for the Debian distribution.
Update 06/24/2011: Thanks to Sebastien Jeanquier for calling this to my attention and helping to support the inclusion of fwknop in BackTrack Linux.

Software Release - fwsnort-1.5

Michael Rash — 2011-01-09T21:01:30-05:00

The 1.5 release of fwsnort is available for download. This is a major release that moves to using the iptables-save format for instantiating the fwsnort policy, and this allows the run time for adding the fwsnort policy to the kernel to be drastically reduced. fwsnort now splices in the translated Snort rules into the iptables policy in the running kernel at the time of translation. So, any updates to the iptables policy that are made after fwsnort is executed and before fwsnort.sh is run would be lost. Hence, it is advisable to execute fwsnort.sh soon after running fwsnort. This is a reasonable tradeoff though considering the performance benefit as seen below - which gives an example of how long it takes to add an fwsnort iptables policy via the old strategy of executing one iptables command at a time vs. implementing the same policy with iptables-restore. First, fwsnort is used to translate the Snort web-misc.rules, web-cgi.rules, backdoor.rules files like so:


[root@minastirith /etc/fwsnort]# fwsnort --snort-rfile web-misc.rules,web-cgi.rules,backdoor.rules --no-ipt-sync



[+] Generated iptables rules for 713 out of 754 signatures: 94.56%



[+] Logfile: /var/log/fwsnort/fwsnort.log

[+] iptables script (individual commands): /etc/fwsnort/fwsnort_iptcmds.sh



    Main fwsnort iptables-save file: /etc/fwsnort/fwsnort.save



    You can instantiate the fwsnort policy with the following command:



    /sbin/iptables-restore < /etc/fwsnort/fwsnort.save



    Or just execute: /etc/fwsnort/fwsnort.sh

The output above illustrates the changes for the fwsnort-1.5 release. All of the previous behavior in fwsnort has been preserved in the /etc/fwsnort/fwsnort_iptcmds.sh script. That is, each individual iptables command to add every fwsnort rule one by one is implemented in this script - this is analogous to how the fwsnort.sh script was built by older versions of fwsnort. But, with the 1.5 release the fwsnort.sh script now just executes the iptables-restore command against the new fwsnort.save file.

If we execute the fwsnort_iptcmds.sh script and time its execution, we get the following on my desktop system:


[root@minastirith /etc/fwsnort]# time /etc/fwsnort/fwsnort_iptcmds.sh

[+] Adding backdoor rules:

    Rules added: 122

[+] Adding web-cgi rules:

    Rules added: 696

[+] Adding web-misc rules:

    Rules added: 600

[+] Finished.



real    0m24.391s

user    0m1.560s

sys     0m11.500s

[root@minastirith /etc/fwsnort]# iptables -v -nL |wc -l

1509

So, the fwsnort policy together with the running iptables policy is about 1500 rules long, and it took over 24 seconds to add to the running kernel. Now, let's time the fwsnort.sh script instead (which is just a wrapper around the iptables-restore command):


[root@minastirith /etc/fwsnort]# time /etc/fwsnort/fwsnort.sh



[+] Splicing fwsnort rules into the iptables policy...

    Done.





real    0m0.121s

user    0m0.060s

sys     0m0.040s

[root@minastirith /etc/fwsnort]# iptables -v -nL |wc -l

1509

Ok, over 24 seconds to instantiate the fwsnort policy for the old strategy, and about a 10th of a second for the new strategy for a speed up of 240 times! This gets even better for an fwsnort policy with thousands of rules. Note that the number of iptables rules is the same between the two executions.

The complete ChangeLog entries are displayed below:

Major update to use the iptables-save format instead of the older strategy of always just executing iptables commands directly (which was very flow for large fwsnort policies). The /etc/fwsnort/fwsnort.sh script now just executes:

/sbin/iptables-restore < /etc/fwsnort/fwsnort.save

All fwsnort rules are now placed in the /etc/fwsnort/fwsnort.save file, but the older fwsnort.sh output (for the individual commands version) is still available at /etc/fwsnort/fwsnort_iptcmds.sh. This functionality extends to ip6tables policies as well. The fwsnort man page explain this in better detail:

"As of fwsnort-1.5 all iptables rules built by fwsnort are written out to the /etc/fwsnort/fwsnort.save file in iptables-save format. This allows a long fwsnort policy (which may contain thousands of iptables rules translated from a large Snort signature set) to be quickly instantiated via the "iptables-restore" command. A wrapper script /etc/fwsnort/fwsnort.sh is also written out to make this easy. Hence, the typical work flow for fwsnort is to: 1) run fwsnort, 2) note the Snort rules that fwsnort was able to successfully translate (the number of such rules is printed to stdout), and then 3) execute the /etc/fwsnort/fwsnort.sh wrapper script to instantiate the policy in the running kernel."
Added the --rules-url argument so that the URL for updating the Emerging Threats rule set can be specified from the command line. The default is:

http://rules.emergingthreats.net/open/snort-2.9.0/emerging-all.rules
Updated to automatically check for the maximum length string that the string match supports, and this is used to through out any Snort rules with content matches longer than this length.
Updated the iptables capabilities testing routines to add and delete testing rules to/from the custom chain 'FWS_CAP_TEST'. This maintains a a cleaner separation between fwsnort and any existing iptables policy even during the capabilities testing phase.
Added the --ipt-check-capabilities argument to have fwsnort test the capabilities of the local iptables firewall and exit.
Added the --string-match-alg argument to allow the string matching algorithm used by fwsnort to be specified from the command line. The default algorithm is 'bm' for 'Boyer-Moore', but 'kmp' may also be specified (short for the 'Knuth-Morris-Pratt' algorithm).
Updated to the latest complete rule set from Emerging Threats (see http://www.emergingthreats.net/).

Single Packet Authorization on Android

Michael Rash — 2011-01-07T21:01:30-05:00

Kicking off 2011 with a bang is easy this year - Max Kastanas has ported the fwknop client to the Android mobile operating sytem. This brings Single Packet Authorization to Google's smart phones, and was accomplished using Damien Stuart's libfko implementation. All of the Android code can be found in the Cipherdyne Trac respository. A couple of screenshots of using the SPA app from an Android phone appear below - after the SPA packet is sent and verified passively by the fwknop daemon on the remote system, the fwknop Android app automatically launches Connectbot to access SSHD:

How to avoid ClamAV matches on bundled Snort rules

Michael Rash — 2010-08-22T21:01:30-05:00

Recently a psad user notified me via email that the psad-2.1.7.tar.gz tarball was flagged by ClamAV as being infected with Exploit.HTML.MHTRedir-8. After checking a few things, it turns out that ClamAV is triggering on a Snort rule in the Emerging Threats rule set which is bundled in both psad and fwsnort. The following analysis shows exactly what ClamAV is detecting and why, and also provides some guidance for how to avoid this for any software projects that distribute Snort rules. Similar logic would apply to other software engineering efforts - including commercial intrusion detection systems - that are (by their nature) looking for malicious artifacts on the filesystem or within network traffic.

First, let's download psad-2.1.7.tar.gz and check the gpg signature (just to make sure we're talking about exactly the same file):


$ wget --quiet http://www.cipherdyne.org/psad/download/psad-2.1.7.tar.gz

$ wget --quiet http://www.cipherdyne.org/psad/download/psad-2.1.7.tar.gz.asc

$ gpg --verify psad-2.1.7.tar.gz.asc

gpg: Signature made Wed 14 Jul 2010 06:01:42 PM EDT using DSA key ID 0D3E7410

gpg: Good signature from "Michael Rash (Signing key for cipherdyne.org projects) "

Ok, now here is what clamscan says about the psad-2.1.7.tar.gz tarball:


$ clamscan psad-2.1.7.tar.gz

psad-2.1.7.tar.gz: Exploit.HTML.MHTRedir-8 FOUND



----------- SCAN SUMMARY -----------

Known viruses: 816934

Engine version: 0.96.1

Scanned directories: 0

Scanned files: 1

Infected files: 1

Data scanned: 6.42 MB

Data read: 1.16 MB (ratio 5.55:1)

Time: 7.169 sec (0 m 7 s)

Let's see which file within the psad-2.1.7 tarball matches the Exploit.HTML.MHTRedir-8 signature:


$ tar xfz psad-2.1.7.tar.gz

$ clamscan -r -i psad-2.1.7

psad-2.1.7/deps/snort_rules/emerging-all.rules: Exploit.HTML.MHTRedir-8 FOUND



----------- SCAN SUMMARY -----------

Known viruses: 816934

Engine version: 0.96.1

Scanned directories: 41

Scanned files: 405

Infected files: 1

Data scanned: 12.55 MB

Data read: 6.41 MB (ratio 1.96:1)

Time: 8.446 sec (0 m 8 s)

Intuitively, this makes sense. That is, given that ClamAV is out to identify nasty things within files, and given that Snort rules are designed to identify nasty things as they communicate over the network, it stands to reason that there might be some overlap. This overlap is not an indication of something wrong in either the Snort rules or in ClamAV. Now, let's find out specifically which Snort rule within the emerging-all.rules file is triggering the ClamAV match. We first take a look at the Exploit.HTML.MHTRedir-8 signature:


$ cp /var/lib/clamav/main.cvd .

$ sigtool --unpack main.cvd

$ grep Exploit.HTML.MHTRedir-8 main.ndb

Exploit.HTML.MHTRedir-8:3:*:6d68746d6c3a66696c653a2f2f{1-20}2168

The last line above is the entire ClamAV signature, and the pattern 6d68746d6c3a66696c653a2f2f is the key. The ":3:" part identifies the signature as type "normalized HTML", so ClamAV matches the pattern 6d68746d6c3a66696c653a2f2f against the "normalized HTML" representation of each processed file. We can decode the pattern as follows:


echo 6d68746d6c3a66696c653a2f2f | xxd -r -p

mhtml:file://

So, within the emerging-all.rules file, we are interested in any Snort rule that contains the string mhtml:file://. There is also the "{1-20}2168" criteria which says to match the hex bytes 2168 anywhere from 1 to 20 bytes after the first pattern match.


$ grep mhtml psad-2.1.7/deps/snort_rules/emerging-all.rules

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET MALWARE Bundleware Spyware CHM Download"; flow: to_server,established; content:"Referer\: ms-its\:mhtml\:file\://C\:counter.mht!http\://"; nocase; content:"/counter/HELP3.CHM\:\:/help.htm"; nocase; classtype: trojan-activity; sid: 2001452; rev:4;)

Sure enough, sid:2001452 "ET MALWARE Bundleware Spyware CHM Download" has the keyword content:"Referer\: ms-its\:mhtml\:file\://C\:counter.mht!http\://". Even though there are escaping backslashes, the normalized HTML processing in ClamAV takes this into account and matches the pattern anyway from the ClamAV signature.

So, how can we keep the original Snort rule, but change it so that ClamAV not longer flags it?

Fortunately, ClamAV does not interpret the Snort rules convention of specifying non-printable bytes between "|" characters within content fields, so we simply need to change one of characters to hex notation. Snort will still offer the same detection if network traffic matches the rule, and ClamAV won't flag it. So, let's just change the "m" in "mhtml\:file\://" to its hex equivalent, like so: "|6d|html\:file\://". Once we make this change and save the psad-2.1.7/deps/snort_rules/emerging-all.rules file, we rerun clamscan:


$ clamscan -r -i psad-2.1.7



----------- SCAN SUMMARY -----------

Known viruses: 816934

Engine version: 0.96.1

Scanned directories: 41

Scanned files: 405

Infected files: 0

Data scanned: 17.23 MB

Data read: 6.41 MB (ratio 2.69:1)

Time: 10.024 sec (0 m 10 s)

That's better. Over the next few days I'll re-release all affected versions of psad and fwsnort with the above change to ensure that there aren't any additional ClamAV matches.

In conclusion, if you are involved in any software engineering effort that distributes or makes use of Snort rules, it is probably a good idea to run distribution packages through ClamAV and see if there are any matches. If so, it may be possible to take advantage of Snort rule syntax options to still achieve the same signature coverage while not having ClamAV flag anything.

A new SSH password guessing botnet: dd_ssh

Michael Rash — 2010-08-20T21:01:30-05:00

Every few months it seems that there is a new variation of a password guessing botnet. This time around, as reported by the SANS ISC and also by malwarecity.com, a botnet called "dd_ssh" has been built up around a vulnerability in phpMyAdmin. (Here is the vulnerability announcement from the Debian security list.) Once a vulnerable webserver has been compromised, the botnet starts scanning random IP addresses for SSH servers and attempts to brute force passwords for those systems that accept an SSH connection. Although software like Fail2ban and DenyHosts can offer detection and mitigation by applying thresholds to the number of failed login attempts in the SSH log and communicate offending source IP's to a set of interested users, a fundamental problem is that the targeted SSH daemons are reachable in the first place from arbitrary source IP's. A more powerful solution is to hide your SSH daemon behind a default-drop firewall policy and only grant access through Single Packet Authorization. Any botnet that is scanning for SSH servers will not be able to guess any passwords or even exploit a zero-day vulnerability in an SSH daemon that is protected in this way.

Further, SSH brute forcing botnets have shown some innovative techniques where password guessing attempts are spread out over a long period of time and failed passwords are distributed across the botnet. The end result is that each botnet node knows the population of passwords that other nodes have already tried on each targeted SSH daemon, and so new passwords can be tried while still slipping beneath common detection thresholds. The same password never has to be tried twice botnet-wide. It is not clear yet whether the dd_ssh botnet uses a similar password distribution strategy, but either way I intend to stop such guessing games at the earliest stage possible and block all SSH connections by default.

HTTP Response Times for cipherdyne.org

Michael Rash — 2010-08-15T21:01:30-05:00

I'm a big fan of the Smokeping project developed by Tobi Oetiker, and I use it to graph ICMP, DNS, and HTTP round trip times for my local internet connections and also for cipherdyne.org. Since the beginning of 2010, I've switched around where cipherdyne.org was hosted from a system at a hosting provider in Canada to a system running on my home network (serviced by a Verizon FiOS connection). The drop in RTT's in mid-February was expected and quite large - going from an average of around 200ms down to about 20ms. Then, in June, I switched to a different Verizon DSL connection and moved the cipherdyne.org webserver system to a newer Verizon FiOS connection at a different location, and the RTT's went up a bit to about 50ms. Here is the graph:

fwsnort Available in Fedora Repositories

Michael Rash — 2010-08-13T21:01:30-05:00

The fwsnort project is now available directly through the Fedora RPM repositories (for Fedora 12 and 13) thanks to Guillermo Gomez. The version that is currently bundled is fwsnort-1.0.6. Once fwsnort-1.2 is released, the implementation of large iptables rule sets that are derived from Snort rules will become a lot faster. This is because fwsnort is going to support the iptables-save format by integrating the complex rules built by fwsnort with any existing iptables policy that is instantiated in the kernel. This is made possible by interpreting the local policy and splicing in all of the fwsnort rules in the right places - each iptables chain is built from scratch upon an iptables-restore (including the built-in chains), so integrating with a running policy is not as easy as just adding each fwsnort rule into a set of custom chains. Compatibility with the iptables-save format has largely been completed with this patch in the fwsnort-1.2 development effort.

If you are running a Fedora 12 or 13 system, you can install fwsnort like so:


# yum install fwsnort

Pure C Implementation of Single Packet Authorization

Michael Rash — 2010-07-25T21:01:30-05:00

For the past several months, the pure-C implementation of Single Packet Authorization with fwknop has been in development, and the first release candidate of fwknop-2.0.0 is ready for download. Damien Stuart is the primary developer of this code, and I wish to thank him for all of his efforts in making this release possible. The original perl version of fwknop will continue to receive bug fixes as they are found, but the primary development effort is now on the lightweight and portable C code. The Trac interface for the perl code has moved to fwknop-perl. Any release that is at fwknop-2.0.0 or above will be the C implementation, and any release in the 1.9 series or before are in perl (and will remain available here). The perl and C versions are compatible with each other, so SPA packets created by the fwknop perl client can be properly decrypted and decoded by the new fwknopd C server, and similarly SPA packets built with the fwknop C client can be interpreted by the fwknopd perl server.

The heart of the new C code is the libfko library, which is used by both the fwknop client and the fwknopd server for SPA packet encryption/decryption and interpretation. The libfko library is portable to several platforms including Linux and Windows, and the standard GNU autoconf project is used for building fwknop from sources.

Given the compact nature of the C code, the fwknop-2.0.0rc1 release candidate is already known to function on OpenWRT, and Damien Stuart (the primary developer of the fwknop C code) has built packages for the OpenWRT Kamikaze and Backfire releases. This brings SPA functionality to embedded systems, and has been tested on a Linksys WRT54GS V2.0 router. The OpenWRT packages are available here.

There will be a few release candidates of fwknop-2.0.0 to ensure proper operation on a variety of platforms, and the emphasis will be on stability and ironing out any bugs. Also, fwknop-2.0.0 will initially support iptables firewalls on the servers side, with ipfw support coming soon after. There is one nice feature in fwknop-2.0.0rc1 that deserves a mention - the fwknop client now supports the notion of a ~/.fwknoprc file that allows a set of stanzas to be defined for remote SPA servers and customize the command line arguments used to access each one. Here is an example stanza:


# Example for a destination server of 192.168.1.20 to open access to

# SSH for an IP that is resolved externally

#

[myssh]

SPA_SERVER          192.168.1.20

ACCESS              tcp/22

ALLOW_IP            resolve

SPA_SERVER_PORT     50023

Now, with the fwknop client, we reference this stanza with the -n command line argument like so:


$ fwknop -n myssh -vvv

Resolved external IP (via http://www.cipherdyne.org/cgi-bin/myip) as: 123.1.2.3

Enter encryption password:



FKO Field Values:

=================



   Random Value: 8308719569638051

       Username: mbr

      Timestamp: 1280030806

    FKO Version: 1.9.12

   Message Type: 1

 Message String: 123.1.2.3,tcp/22

     Nat Access: 

    Server Auth: 

 Client Timeout: 0

    Digest Type: 3



   Encoded Data: 8308719569638051:bWJy:1280030806:1.9.12:1:OTYuMjQ0LjE3MS4yNTMsdGNwLzIy



SPA Data Digest: WcUEVesZDIY+CKRKYTck8zMW7HG0S7RcqmXVIMC4L58



Final Packed/Encrypted/Encoded Data:



87wQ3s171if9x8628P6k1oBrQEJEmS5c/+ECed5cfDmu8hGhC5esUCEVcI8IH5TdjWva44efebX+cfXUVPBU9c/6tJpOLwC8k/8sN87SgYkBK+m64aD4FnnndaeqsrIcO/oHcpXHk9S/8rqqypcumNtlXVZD/isS3Q729LMTa+2uI6TsGX9OQ3



Generating SPA packet:

    protocol: udp

    port: 50023

send_spa_packet: bytes sent: 182

On the fwknopd server side, we see the following printed to the terminal in --foreground mode as the SPA packet is received and an iptables ACCEPT rule is added for SSH access and then removed after 30 seconds.


Using Digest Cache: '/usr/var/run/fwknop/digest.cache' (entry count = 93)

PCAP filter is: udp port 50023

Starting fwknopd main event loop.





SPA Packet from IP: 123.1.2.3 received.

SPA Packet: '87wQ3s171if9x8628P6k1oBrQEJEmS5c/+ECed5cfDmu8hGhC5esUCEVcI8IH5TdjWva44efebX+cfXUVPBU9c/6tJpOLwC8k/8sN87SgYkBK+m64aD4FnnndaeqsrIcO/oHcpXHk9S/8rqqypcumNtlXVZD/isS3Q729LMTa+2uI6TsGX9OQ3'



SPA Decode (res=0):

SPA Field Values:

=================

   Random Value: 8308719569638051

       Username: mbr

      Timestamp: 1280030806

    FKO Version: 1.9.12

   Message Type: 1

 Message String: 123.1.2.3,tcp/22

     Nat Access: 

    Server Auth: 

 Client Timeout: 0

    Digest Type: 3

   Encoded Data: 8308719569638051:bWJy:1280030806:1.9.12:1:OTYuMjQ0LjE3MS4yNTMsdGNwLzIy

SPA Data Digest: WcUEVesZDIY+CKRKYTck8zMW7HG0S7RcqmXVIMC4L58



Added Rule to FWKNOP_INPUT for 123.1.2.3, tcp/22 expires at 1280030886

RES=0, CMD_BUF: /sbin/iptables -t filter -L FWKNOP_INPUT --line-numbers -n 2>&1

RULES LIST: Chain FWKNOP_INPUT (1 references)

num  target     prot opt source               destination

1    ACCEPT     tcp  --  123.1.2.3       0.0.0.0/0           tcp dpt:22 /* _exp_1280030886 */



Removed rule 1 from FWKNOP_INPUT with expire time of 1280030886.

Software Release - psad-2.1.7

Michael Rash — 2010-07-14T21:01:30-05:00

The 2.1.7 release of psad is available for download. This release adds some relatively minor functionality to switch whois lookups to the destination IP whenever the source IP is part of a directly connected subnet. This change gives better reporting data in normal psad email alerts. The complete ChangeLog entries are displayed below. The psad-2.1.6 release was also made a few days ago, and fixes a bug that caused psad to die on some Ubuntu systems when using the Date::Calc Decode_Month() function, and it also added the --Override-config feature so that alternate configuration variables can be specified via config files besides psad.conf (implemented by Franck Joncourt).

(Dan A. Dickey) Added the ability to use the "ip" command from the iproute2 tools to acquire IP addresses from local interfaces. Dan's description is as follows: "...A main reason for doing this is in the case of multi-homed hosts. ifconfig sets these up on an interface using aliases, iproute2 does not. So, for a multi-homed interface (eth0 with multiple addresses), ifconfig -a only shows the first one configured and not the rest. ip addr shows all of the configured addresses...".
Added ENABLE_WHOIS_FORCE_ASCII to replace any non-ascii characters in whois data (which is common with whois lookups against Chinese IP addresses for example) with the string "NA". This option is disabled by default, but can be useful if errors like the following are seen upon receiving an email alert from psad:

<<< 554 5.6.1 Eight bit data not allowed
554 5.0.0 Service unavailable
Updated psad to issue whois lookups against IP addresses that are not directly connected to the local system. This is useful for example when an internal system is scanning an external destination system, and the scan is logged in the FORWARD chain. Issuing whois lookups on the internal system (frequently on RFC 1918 address space) is not usually very useful, but issuing the whois lookup against the destination system gives much more interesting data. This feature can be disabled with the new ENABLE_WHOIS_FORCE_SRC_IP variable.