On
June 19th Leandro Almeida
gave a presentation entitled "Single Packet Authorization - Increasing the security in SSH" at the
ENSOL
conference in João Person, Brazil. ENSOL is an open source conference that goes by
the title "Freedom in the Extreme", and given that Brazil is
highly supportive of Linux,
I'm sure that it is a good conference. Leandro has posted an English translation of
his slides here.
It is good to see some additional presentations on the SPA concept at open source conferences,
and Leandro emphasizes the usage of the fwknop SPA implementation to protect SSH.
The 1.0.6 release of fwsnort is ready for download.
This release fixes a bug that caused some Snort rules to not be translated into
iptables rules due to improper handling of escaped semicolons. Now that this
bug has been fixed, an additional 58 rules from the Emerging Threats rule set
are now properly supported. Also made it easier to point fwsnort at a single
file with a Snort rule set to be converted (see the --fwsnort-rfile command line
argument).
Recently I ran into a situation in which several Snort rules from the
Emerging Threats rule sets were not
being properly translated into iptables rules by fwsnort.
It turned out that fwsnort did not correctly parse Snort content fields
that contained escaped semicolons (e.g. "\;"). In the Snort signature
language, the argument to every keyword in the body of a Snort rule such as
content, pcre, and flowbits is terminated with a semicolon,
and some keywords also use opening and closing double quotes. But, Snort
supports escaping with a backslash so that these characters can easily be made
to be part of a keyword argument as opposed to the delimiting syntax. Snort
does not allow the argument of a content keyword to contain an embedded
semicolon that is not escaped (e.g. content:"distloc=;";), and will generate
an error similar to the following if a rule does not conform to this:
Sean Wilkerson convinced me to
join Twitter as a way to help increase
the exposure that the Cipherdyne projects have on the Internet, and also to
interact more with peers in the security community. After having used Twitter now
for a couple of weeks, I can see some benefit in its ability to rapidly broadcast
updates (140 characters at a time) and to make it easy to see what others are
working on (subject to what they choose to reveal of course). Further, it seems
plausible that Twitter's flexibility and speed would make it easier to acquire
answers to questions than trying to contact people directly via email. Sean also
had mentioned that after a recent talk he gave at
DojoSec (hopefully video of it will be posted soon) he noticed that people are
using Twitter during security talks as a way to organize the audience around the
topic at hand. This provides a way for the audience to converge on challenging
questions and bring participation to a higher level. Finally, as a measure of its
success, it might be worth noting that Twitter has also been in the news recently
as a mechanism for organizing a
revolution in the former-Soviet republic of Moldova.
Julien Picalaus recently posted a message to the fwknop mailing list in which he
explains how to use Strawberry Perl
(reportedly what Larry Wall uses for his perl distribution on Windows systems)
along with the
Perl Packager to create a native Windows binary for the fwknop client. The
result is a functional fwknop.exe binary that can be used on Windows
systems to gain access to services protected by an fwknopd server running on
other systems with iptables or ipfw policies.
The IPTables::ChainMgr module is now used by
the PacketFence NAC system in the
latest 1.8.0 release. The module is used to build iptables rules that match on source MAC
addresses, set a connection mark, and jump packets into a dedicated MARK chain.
Erik Heidt from the Art of Information Security recently
interviewed me
on various topics in computer security, and this is the first part. The history of
the psad project from its roots in
Bastille Linux along with
psad's three main goals for enhancing Linux system security are covered. Erik
concentrates on current issues in Information Security, and writes a series
called "Secure Your Linux Host".
Some of the latest articles in this series discuss locking down SSH. Thanks
to Erik for the opportunity to respond to his interview questions.
Recently on the fwknop mailing list,
Mark V asked whether Single Packet Authorization
is compatible with virtual Linux instances in Amazon's
Elastic Cloud (EC2) computing
service. After signing up for an account and running a few tests, it turns out that
fwknop can function properly on an EC2 instance and wrap an SPA hardening layer around SSHD.
The Amazon online documentation on how to
access Linux instances
over SSH recommends adding new rules for each IP source address you want to
use to access SSHD, which can become tiresome if you are on a network running DHCP. With
fwknop, you don't need to do any such thing - you can access SSHD via SPA from anywhere,
and anyone else scanning for SSHD on the instance can't even tell that it is listening.
After a few months of development, fwknop is now available as a Debian
package in the Debian Sid
distribution. Hopefully it won't be too long before it is also available through
the Debian stable repository. Thanks to Franck Joncourt
for developing the fwknop Debian package, and he has also created packages of
gpgdir and fwsnort as well. To view fwknop in the APT package cache
the following steps will do the trick:
Russ McRee of holisticinfosec.org
has written the October Toolsmith
issue from the ISSA Journal about fwsnort and intrusion detection.
Russ emphasizes practical usages of fwsnort with tuning the Snort signature set it translates into
an iptables policy, and after using fwsnort to build a detection policy, he sends several example
attacks at a webserver. These attacks include directory traversal, XSS, and CSRF attacks, and
he illustrates how the attacks are detected by fwsnort via the iptables log messages it generates.
Here is an attack identified as ET WEB-MISC Poison Null Byte by Snort rule ID 2003099, and
below is the log message generated by fwsnort when the attack is sent against a webserver:
A key advantage to using Single Packet Authorization (SPA) over
port knocking is the fact that it is trivially easy to harden SPA packets against replay
attacks by including a significant number of random bytes within each SPA packet. Then, by
tracking the SHA-256 message digest (or the digest from some other suitable cryptographic
hashing algorithm) for all incoming SPA packets, the server can enforce that only unique
SPA packets ever result in elevated access through a default-drop firewall policy. Any
duplicate SPA packet will match a previously calculated digest, and such a packet is
therefore flagged as a replay attack (subject to the usual concerns surrounding the
minuscule chance of a hash collision - though for SHA-256 this is exceedingly unlikely).
In the case of SPA packets generated by the fwknop client, a full 16 bytes of
random data is included at the beginning of each packet before it is encrypted.
You can see in the graph above that there are several spikes for a few character values.
These spikes correspond with the characters U2FsdGVkX1, which is the base64
encoded version of the string "Salted__". Every SPA packet in the spa_artifacts.pkts
file begins with this string, and so one would expect more of these characters on
average than the others. There is also a sharp dip to 20,000 on the right-hand
portion of the graph for the value 64, which corresponds to the = character.
This is because there is only one equals character at the end of each SPA packet in
the spa_artifacts.pkts file.
This graph shows us where the predictable bytes are. We know that each SPA
packet begins with U2FsdGVkX1 and ends with =, and the outliers (on the
left-hand side and one point on the right-hand side - all with Z-axis values of
about 20,000) in the above graph illustrate this. The X-axis represents the byte
positions of each packet, the Y-axis are the numeric character codes, and the
Z-axis is the number of times a character is counted.
Now that the invariant sections have been removed, the length of each packet is
161 characters, so if the randomness were perfect, we would expect the average
instance of each character to be 161 / 64 * 20000 = 50,300 (approximately), and
this is quite close to the value displayed by the graph.
There are still two minor spikes corresponding to the numeric values around 0
and 1, and then again around 10 and 11 on the X-axis. These bytes correspond to
the characters +, /, 8, and 9 respectively.
So, at the scale shown above, the 3D graph looks decently random - at least there
are far fewer outliers than for the first data set of 20,000 packets, and there aren't
any other obviously regular structures in the graph. However, if you look to the
left-hand portion of the graph, you will see there are
small outliers at position 0 on the X-axis - the very first byte of each SPA
packet. Looking through the spa_no_artifacts.pkts file, the graph is indeed
correct - every SPA packet begins with one of the bytes +, /, 8, or 9.
It appears that fwknop is going to be bundled within the next release of the
Fedora Linux distribution thanks to the
work of Mirek Trmac and sponsored by Red Hat.
One of the most significant contributions made by Mirek can be seen in
this patch that
removes the dependency in the fwknopd daemon on the NetPacket perl module, which
seems not to be actively developed anymore. An RPM of fwknop has been built for
Fedora 10,
and the build and approval status can be viewed on the
Fedora package page.
Over the past month, in my web logs for cipherdyne.{com,org} there have been suspicious web
requests against the file s_loadenv.inc.php even though this file does not exist
on cipherdyne.{com,org}. These web requests attempt to force the webserver to execute a
malicious PHP script via a web link provided in the DOCUMENT_ROOT form parameter. The
requests basically look like the following (shown here as strings split across the perl
'.' operator so that browsing this page does not set off any IDS alarm bells):