<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns:dc="http://purl.org/dc/elements/1.1/"
 xmlns:admin="http://webns.net/mvcb/"
>
<channel>
<title>cipherdyne.org | System and Network Security</title>
<link>http://www.cipherdyne.org</link>
<description>The network and system security blog of Michael Rash</description>
<dc:language>en-us</dc:language>
<dc:rights>Copyright 2001-2010, Michael Rash.  All Rights Reserved.</dc:rights>
<dc:creator>Michael Rash</dc:creator>
<dc:date>2006-02-28T16:48:01-05:00</dc:date>
<admin:generatorAgent rdf:resource="http://www.cipherdyne.org" />

<!-- begin_stories -->
<item>
<link>http://www.cipherdyne.org/blog/2013/02/shmoocon-2013-talk-on-fwknop.html</link>
<title>ShmooCon 2013 Talk on fwknop</title>
<dc:date>2013-02-22T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="http://www.shmoocon.org">
<img align="right" src="/images/shmoocon.gif" title="ShmooCon 2013" alt="ShmooCon 2013" height="45" width="215" /></a>
<b><i>Update 03/24/2013:</i></b> All presentation videos have been uploaded to shmoocon.org,
and here is the full video for the talk discussed below:
<a href="http://www.youtube.com/watch?v=GCGiI6DJuIc"><b>video</b></a>.
<br/><br/>
This past weekend at <a href="http://www.shmoocon.org"><b>ShmooCon 2013</b></a> I gave a talk
entitled "<b>Generalized Single Packet Authorization for Cloud Computing Environments</b>"
(<a href="/talks/ShmooCon_2013_mrash_Cloud_SPA.pdf"><b>slides</b></a>,
<a href="http://www.youtube.com/watch?v=t7yGtr7KlrQ&amp;feature=youtu.be"><b>video demo</b></a>),
and in this blog post I thought it appropriate to give an introduction to the talk in blog
format.  The main point of the talk was to show that it is completely feasible to integrate
SPA as implemented by <a href="/fwknop"><b>fwknop</b></a> with Cloud Computing environments that
conform to the <i>Infrastructure as a Service</i> (IaaS) model.  In particular, it was shown
that SPA can be used to protect and access both SSH and RDP services running on EC2 instances
within a Virtual Private Cloud (VPC) in <a href="http://aws.amazon.com"><b>Amazon's AWS</b></a>
environment.  Accessing SSHD via SPA by itself is nothing new and has been a primary use case
supported by fwknop for a long time, but maintaining a default-drop packet filtering stance
for RDP is a different story due to the fact that fwknop does not support a Windows firewall.
However, through the use of both SNAT and DNAT capabilities within iptables, the fwknop
daemon is able to convert an Ubuntu EC2 instance running within Amazon's Cloud into an "SPA
gateway" that is able to then allow access to <i>any</i> service running on <i>any</i> other
system within the VPC network - including RDP on a separate Windows host.  Further, such
access is granted through a single externally routable Amazon Elastic IP that is associated
with the Ubuntu system.  The Windows host doesn't even need to have a default route back out to
the Internet - it always just sees incoming RDP connections from the Ubuntu host even though
they really originate out on the Internet from whatever system is allowed via the SPA protocol.
Here is a graphic to illustrate this scenario:

<img src="/images/ShmooCon_2013_AWS_network_setup.png" title="fwknop + Amazon integration" alt="fwknop + Amazon integration" height="500" width="700" />

If you want a video demonstration of this all in action, this demo was given during the
ShmooCon talk:
<br/><br/>
<center>
<iframe width="420" height="315" src="http://www.youtube.com/embed/t7yGtr7KlrQ" frameborder="0" allowfullscreen="1" ></iframe>
</center>
<br/>
Now, for more explanation, the following systems are depicted in the graphic above:
<br/><br/>
<ul>
<li>The SPA client system that runs the fwknop client to send SPA packets and from which
SSH and RDP connections originate.</li>
<li>The Amazon border firewall.</li>
<li>An Ubuntu host on the VPC network where the fwknop daemon runs.</li>
<li>A Windows system on the VPC network where RDP lives.</li>
</ul>

At the same time, the Ubuntu VPC host is also running a webserver.  This is to illustrate
that everyone out on the Internet can scan the externally routable Elastic IP (107.23.221.41
in this case) associated with the Ubuntu host and see that Apache is listening on port 80.
(Note that this IP is not currently associated with my Amazon account.)  But, <b><i>no</i></b>
other services are visible to a scanner on the Ubuntu system because iptables is deployed
in a default-drop stance for everything except for port 80.  Even so, fwknop is able to
create access through the iptables policy for SSH and RDP through the Ubuntu system over
port 80 (i.e. SPA "<a href="/blog/2009/11/creating-ghost-services-with-single-packet-authorization.html">ghost services</a>").
These two scripts that are shown in the demo video illustrate gaining access to SSH and
RDP:
<pre>
$ cat ssh_access.sh
#!/bin/sh -x

fwknop -A tcp/80 --server-port 40001 -R -D 107.23.221.41
sleep 2
ssh -p 80 -i ~/.ssh/cdyne-vpc-testing.pem ubuntu@107.23.221.41
exit

$ cat rdp_access.sh
#!/bin/sh -x

fwknop -A tcp/80 --server-port 40001 -N 10.0.0.223,3389 -R -D 107.23.221.41
sleep 2
rdesktop -u Administrator 107.23.221.41:80
exit

</pre>

To see all of the above in action just watch the video.  Hopefully the talk itself will
be posted online soon, and when it is I'll post a link.  More information can also be
found in the talk <a href="/talks/ShmooCon_2013_mrash_Cloud_SPA.pdf"><b>slides</b></a>.
<br/><br/>
Finally, I'd like to thank the ShmooCon organizers for putting on a great conference
as usual, and I'm looking forward to next year.

]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2013/01/software-release-psad-2.2.1.html</link>
<title>Software Release - psad-2.2.1</title>
<dc:date>2013-01-02T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/psad/download/">
<img align="right" src="/images/release.png" title="psad-2.2.1" alt="psad-2.2.1 released" /></a>
The 2.2.1 release of <a  href="/psad"><b>psad</b></a> is
available for <a  href="/psad/download/"><b>download</b></a>.  This release
adds new support for detecting a type of scan that psad has been previously
blind to - IP protocol scanning (nmap -sO).  Also in this release is the
ability to detect <a href="http://code.google.com/p/topera/">Topera</a> IPv6
scans and differentiate them from Nmap IPv6 scans.  Other important changes
include a new test suite, email throttling, and auto blocking timeouts that
can be set for each danger level.  Here is the complete ChangeLog:
<br/><br/>
<ul>
<li>Added IP protocol scan detection (nmap -sO).  A new psad.conf variable
PROTOCOL_SCAN_THRESHOLD defines the minimum number of different IP
protocols (default = 5) that must be scanned before an alert is
triggered.</li>
<li>Added detection for Topera IPv6 scans when --log-ip-options is used in
the ip6tables logging rule.  When this option is not used, the previous
psad-2.2 release detected Topera scans.  An example TCP SYN packet
generated by Topera when --log-ip-options is used looks like this (note
the series of empty IP options strings "OPT ( )":
<pre>
Dec 20 20:10:40 rohan kernel: [  488.495776] DROP IN=eth0 OUT=
MAC=00:1b:b9:76:9c:e4:00:13:46:3a:41:36:86:dd
SRC=2012:1234:1234:0000:0000:0000:0000:0001
DST=2012:1234:1234:0000:0000:0000:0000:0002 LEN=132 TC=0 HOPLIMIT=64
FLOWLBL=0 OPT ( ) OPT ( ) OPT ( ) OPT ( ) OPT ( ) OPT ( ) OPT ( )
OPT ( ) OPT ( ) PROTO=TCP SPT=61287 DPT=1 WINDOW=8192 RES=0x00 SYN
URGP=0
</pre>
</li>
<li>Bug fix in --Analyze mode when IP fields are to be searched with the
--analysis-fields argument (such as --analysis-fields "SRC:1.2.3.4").
The bug was reported by Gregorio Narvaez, and looked like this:
<pre>
Use of uninitialized value $_[0] in length at
../../blib/lib/NetAddr/IP/UtilPP.pm (autosplit into
../../blib/lib/auto/NetAddr/IP/UtilPP/hasbits.al) line 126.
Use of uninitialized value $_[0] in length at
../../blib/lib/NetAddr/IP/UtilPP.pm (autosplit into
../../blib/lib/auto/NetAddr/IP/UtilPP/hasbits.al) line 126.
Bad argument length for NetAddr::IP::UtilPP::hasbits, is 0, should be
128 at ../../blib/lib/NetAddr/IP/UtilPP.pm (autosplit into
../../blib/lib/auto/NetAddr/IP/UtilPP/_deadlen.al) line 122.
</pre>
</li>
<li>Added --stdin argument to allow psad to collect iptables log data from
STDIN in --Analyze mode.  This makes it easier to run an iptables logs
through psad from arbitrary files like so:
<pre>
# grep "IN=.*OUT=" /var/log/kern.log | psad -A --stdin
</pre>
</li>
<li>Added the ability to acquire Snort rule 'msg' fields from fwsnort if
it's also installed.  A new variable FWSNORT_RULES_DIR tells psad where
to look for the fwsnort rule set.  This fixes a problem reported by Pui
Edylie to the psad mailing list where fwsnort logged an attack that psad
could not map back to a descriptive 'msg' field.</li>
<li>Added the ability to set per-danger level timeouts when psad is
configured to run in auto-blocking mode.  These timeouts are implemented
with new AUTO_BLOCK_DL*_TIMEOUT variables - one for each of the five
possible danger levels that may be assigned to a scanning IP address.</li>
<li>Added the ability to throttle emails generated by psad via a new
EMAIL_THROTTLE variable which is implemented as a per-IP threshold.  That
is, if EMAIL_THROTTLE is set to "10", then psad will only send 1/10th as
many emails for each scanning IP as it would have normally.
</li>
</ul>

The complete psad-2.2.1 ChangeLog can also be found
<a href="/cgi-bin/gitweb.cgi?p=psad.git;a=blob;f=ChangeLog;h=3d068c237f1d880307bc5bd4746ac5a5178c82de;hb=7c4a910bab48160cca35117a59e3e58aa8d2233d">here</a>
via the psad <a href="/cgi-bin/gitweb.cgi?p=psad.git;a=summary">gitweb</a> interface.


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/12/software-release-fwsnort-1.6.3.html</link>
<title>Software Release - fwsnort-1.6.3</title>
<dc:date>2012-12-22T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/fwsnort/download/">
<img align="right" src="/images/release.png" title="fwsnort-1.6.3" alt="fwsnort-1.6.3 released" /></a>
The 1.6.3 release of <a  href="/fwsnort"><b>fwsnort</b></a> is
available for <a  href="/fwsnort/download/"><b>download</b></a>.  This release
adds a new test suite in the <b>test/</b> directory that sends fwsnort through its paces
for both iptables and ip6tables firewalls, speeds up iptables/ip6tables capabilities
testing, and fixes a few bugs.  In addition, one of the more significant changes is to
ensure that Snort rules with HOME_NET=any -&gt; EXTERNAL_NET=any are placed into the
OUTPUT chain instead of the INPUT chain.  This bug was reported by Dwight Davis.  I would
also like to thank Franck Joncourt for his support on the Debian side.  Other changes
were contributed by the open source community, and these are acknowledged in the complete
fwsnort-1.6.3 ChangeLog below:
<br/><br/>

<ul>
<li>Bug fix to ensure that !, &lt;, &gt;, and = chars in content strings are
converted to the appropriate hex equivalents.  All content strings with
characters outside of [A-Za-z0-9] are now converted to hex-string format
in their entirety.  This should also fix an issue that results in the
following error when running /var/lib/fwsnort/fwsnort.sh:

<pre>
    Using intrapositioned negation (`--option ! this`) is deprecated in
    favor of extrapositioned (`! --option this`).  Bad argument `bm'
    Error occurred at line: 64
    Try `iptables-restore -h' or 'iptables-restore --help' for more information.
    Done.
</pre>
</li>
<li>Bug fix to set default max string length in --no-ipt-test mode where
iptables capabilities are not tested.</li>
<li>(Andrew Merenbach) Bug fix to properly honor --exclude-regex filtering
option.</li>
<li>Added fwsnort test suite to the test/ directory.  This mimics the test
suites from the psad and fwknop projects, and it designed to examine
many of the run time results of fwsnort.</li>
<li>Added the ability to easily revert the fwsnort policy back to the
original iptables policy with "/var/lib/fwsnort/fwsnort.sh -r".  Note
that this reverts back to the policy as it was when fwsnort itself was
executed.</li>
<li>Implemented a single unified function for iptables match parameter
length testing, and optimized to drastically reduce run time for iptables
capabilities checks (going from over 20 seconds to less than one second
in some cases).</li>
<li>(Dwight Davis) Contributed patches for several bugs including not
handling --exclude-regex properly, not ignoring the deleted.rules file,
not handling --strict mode operations correctly, and more.  These issues
and the corresponding patch were originally reported here:
<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693000">
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693000</a></li>
<li>Bug fix for Snort rules with HOME_NET(any) -&gt; EXTERNAL_NET(any) to
ensure they go into the OUTPUT chain instead of the INPUT chain.  This
bug was reported by Dwight Davis.</li>
<li>Updated to bundle the latest Emerging Threats rule set.</li>
</ul>

The complete fwsnort-1.6.3 ChangeLog can also be found
<a href="/cgi-bin/gitweb.cgi?p=fwsnort.git;a=blob;f=ChangeLog;h=5f028cc3ecdef8791c70ee031147c2006bc3855d;hb=1634d5c82be8d1ad10c05841cfe1696c055bdbcd">here</a>
via the fwsnort <a href="/cgi-bin/gitweb.cgi?p=fwsnort.git;a=summary">gitweb</a> interface.


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/12/software-release-fwknop-2.0.4.html</link>
<title>Software Release - fwknop-2.0.4</title>
<dc:date>2012-12-09T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/fwknop/download/">
<img align="right" src="/images/release.png" title="fwknop-2.0.4" alt="fwknop-2.0.4 released" /></a>
The 2.0.4 release of <a  href="/fwknop"><b>fwknop</b></a> is
available for <a  href="/fwknop/download/"><b>download</b></a>.  This release
includes new support for fuzzing the SPA protocol powered by the perl FKO module along
with a set of patches designed to break libfko in subtle ways, and also includes several
bug fixes and small enhancements.  Among the most important of these include a new check
for fwknop chains on iptables firewalls after the initial fwknopd start up (so the fwknop
chains can be deleted out from under the fwknop daemon without affecting SPA operations),
and a new 'upstart' config for systems running the upstart daemon.  Many other changes
were contributed by the open source community, and these are acknowledged in the complete
fwknop-2.0.4 ChangeLog below:
<br/><br/>

<ul>
<li>[client] Misc fixes and the addition of save_args and last command 
(.fwknop.last) support on the Windows platform.</li>
<li>[client] Fixed bug in username determination code where a valid value
could be overrwritten in certain circumstances.</li>
<li>[server] Added upstart config at extras/upstart/fwknop.conf.  This
allows the fwknopd to easily be managed with upstart via commands like
"service fwknop start" and "service fwknop stop".</li>
<li>[server] (Vlad Glagolev) Submitted a patch to fix ndbm/gdbm usage when
--disable-file-cache is used for the autoconf configure script.  This
functionality was broken in be4193d734850fe60f14a26b547525ea0b9ce1e9
through improper handling of #define macros from --disable-file-cache.</li>
<li>[server] (Vlad Glagolev) Submitted a patch to fix command exec mode
under SPA message type validity test.  Support for command exec mode was
also added to the test suite.</li>
<li>(Vlad Glagolev) Submitted an OpenBSD port for fwknop-2.0.3, and this has
been checked in under the extras/openbsd/ directory.</li>
<li>[server] Bug fix to allow GPG_ALLOW_NO_PW to result in not also having
to specify a Rijndael key.</li>
<li>[Android] Added new .properties files to allow the fwknop client to
build and function properly on the latest Android release (4.1.2).</li>
<li>[client] Added '-P udpraw' to allow the client to send SPA packets over
UDP with a spoofed source IP address.  This is in addition to the
original 'tcpraw' and 'icmp' protocols that also support a spoofed
source IP.</li>
<li>[libfko] Bug fix to check b64_decode() return value to ensure that
non-base64 encoded data is never used.  Even though other validation
routines checked decoded results, it is important to discard invalid
data as early as possible.  Note too that such invalid data would only
be provided to b64_decode() after proper decryption, so the client must
provide authentic SPA data.</li>
<li>[libfko] Added validation of NAT access strings in the various NAT
modes.</li>
<li>[libfko] Restricted usernames embedded in SPA packets to be
alpha-numeric along with "-" chars.</li>
<li>[client] (Franck Joncourt) Contributed a patch to allow the fwknop
client to be stopped during the password entry prompt with Ctrl-C before
any SPA packet is sent on the wire.</li>
<li>[client+server] Applied patch from Franck Joncourt to remove unnecessary
chmod() call when creating client rc file and server replay cache file.
The permissions are now set appropriately via open(), and at the same
time this patch fixes a potential race condition since the previous code
used fopen() followed by chmod().</li>
<li>[server] Bug fix to accept SPA packets over ICMP if the fwknop client
is executed with '-P icmp' and the user has the required privileges.</li>
<li>[test suite] Applied patch from Franck Joncourt to have the perl FKO
module link against libfko in the local directory (if it exists) so that
it doesn't have to have libfko completely installed in the /usr/lib/
directory.  This allows the test suite to run FKO tests without
installing libfko.</li>
<li>[test suite] Significant update to include a set of fuzzing SPA packets
that are built using a patched version of libfko.  These packets are
located in the test/fuzzing/bogus_spa_packets file, and are designed to
ensure proper validation of SPA packet data.  This validation is
performed in --enable-perl-module-checks mode via the perl FKO module.</li>
<li>[client] Added --icmp-type and --icmp-code arguments so the user can
control the icmp type/code combination for spoofed SPA packets ('-P
icmp') mode.</li>
<li>[client] Updated default TTL value to 64 for spoofed SPA packets.  This
is closer to more OS default TTL values than the previous 255.</li>
<li>Updated build CFLAGS and LDFLAGS to conform to the Debian
hardening-includes file for PIE support (e.g. '-fPIE' for CFLAGS and
'-fPIE -pie' for LDFLAGS).</li>
<li>[test suite] For GnuPG tests that require a passphrase associated with
a gpg key, added a pinentry check to see if the local gpg engine
requires it.  If so, the gpg test that require a key are excluded since.</li>
<li>[server] Added a new '--pcap-file &lt;file&gt;' option to allow pcap files to
be processed directly by fwknopd instead of sniffing an interface.  This
feature is mostly intended for debugging purposes.</li>
<li>[server] Added chain_exists() check to SPA rule creation so that if any
of the fwknop chains are deleted out from under fwknopd they will be
recreated on the fly.  This mitigates scenarios where fwknopd might be
started before a system level firewall policy is applied due to init
script ordering, or if an iptables policy is re-applied without
restarting fwknopd.</li>
</ul>

The complete fwknop-2.0.4 ChangeLog can also be found
<a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=ChangeLog;h=f2593a481914d12793abfe7efc4d2bd11a612677;hb=92b648a08f1d98de4bafa6651eb119a3d72c0603">here</a>
via the fwknop <a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=summary">gitweb</a> interface.


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/10/tutorial-on-single-packet-authorization-with-fwknop.html</link>
<title>Tutorial on Single Packet Authorization with fwknop</title>
<dc:date>2012-10-08T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[
<a href="/fwknop/">
<img align="right" src="/images/chinesedoor5.jpg" width="180" height="120" title="Single Packet Authorization: The fwknop Approach" alt="Single Packet Authorization: The fwknop Approach" /></a>
One thing that has been requested a few times is a tutorial on how to use fwknop, so here it
is: "<a href="/fwknop/docs/fwknop-tutorial.html">Single Packet Authorization: A Comprehensive Guide to Strong Service Hardening with fwknop</a>".
This document attempts to cover most usages of fwknop to wrap an SPA layer around arbitrary services,
though some less used scenarios such as <a href="/fwknop/docs/fwknop-tutorial#4.11">SPA over Tor</a>
and <a href="/fwknop/docs/fwknop-tutorial#4.9">SPA packet spoofing</a> are covered as well.  Please
<a href="/contact.html">contact me</a> if you find any errors, or if you would like to see material
added on a particular fwknop use case.  The complete table of contents appears below:
<br/><br/>
<ul>
<li><a href="/fwknop/docs/fwknop-tutorial.html#1" class="toclrg">1. Quick Start</a></li>
    <ul>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#1.1">Configuring fwknopd to protect sshd</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#1.2">Default-drop firewall policy</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#1.3">Gaining access to sshd with the fwknop client</a></li>
    </ul>
<li><a href="/fwknop/docs/fwknop-tutorial.html#2" class="toclrg">2. Introduction</a></li>
    <ul>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#2.1">What is Port Knocking?</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#2.2">What is Single Packet Authorization?</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#2.3">What is fwknop?</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#2.4">fwknop license (GPL v2)</a></li>
    </ul>
<li><a href="/fwknop/docs/fwknop-tutorial.html#3" class="toclrg">3. Installing fwknop</a></li>
    <ul>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#3.1">Downloading the latest fwknop release</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#3.2">Supported Platforms</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#3.3">Notes on Specific Platforms</a></li>
        <ul>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#3.3.1">Linux Notes</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#3.3.2">FreeBSD Notes</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#3.3.3">Mac OS X Notes</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#3.3.4">OpenBSD Notes</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#3.3.5">iPhone Notes</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#3.3.6">Android Notes</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#3.3.7">Windows Notes</a></li>
        </ul>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#3.4">Installing from Sources</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#3.5">The fwknop Test Suite</a></li>
        <ul>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#3.5.1">Running the Test Suite</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#3.5.2">--diff Mode</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#3.5.3">valgrind Support</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#3.5.4">Anonymizing Test Suite Output</a></li>
        </ul>
    </ul>
<li><a href="/fwknop/docs/fwknop-tutorial.html#4" class="toclrg">4. fwknop Operations</a></li>
    <ul>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.1">Starting and Stopping the fwknopd daemon</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.2">SPA with Symmetric Keys (via Rijndael)</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.3">SPA with Asymmetric Keys (via GnuPG)</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.4">Hardening Multiple Services</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.5">Handling Multiple Users</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.6">Client Automation with the --get-key Option</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.7">SPA Across NAT Gateways</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.7.1">SPA Ghost Services</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.8">User Interfaces</a></li>
        <ul>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#4.8.1">iPhone Client</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#4.8.2">Android Client</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#4.8.3">Windows Morpheus UI</a></li>
            <li><a href="/fwknop/docs/fwknop-tutorial.html#4.8.4">Web Proxy</a></li>
        </ul>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.9">SPA Packet Spoofing</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.10">Stopping Replay Attacks</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#4.11">SPA Over Tor</a></li>
    </ul>
<li><a href="/fwknop/docs/fwknop-tutorial.html#5" class="toclrg">5. fwknop Design Goals</a></li>
    <ul>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#5.1">No Heavyweight Interpreted Languages</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#5.2">Support Embedded Devices</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#5.3">Don't Require Admin Access to Run the SPA Client</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#5.4">Don't Require the Manipulation of Raw Packet Headers</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#5.5">Don't trust the IP header</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#5.6">Support Server-Side NAT</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#5.7">Support Cloud Computing Environments</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#5.8">Support Multiple Firewalls</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#5.9">Minimize Library Dependencies</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#5.10">Support Both Symmetric and Asymmetric Ciphers</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#5.11">Leverage Compiler and OS Security Features</a></li>
    </ul>

<li><a href="/fwknop/docs/fwknop-tutorial.html#6" class="toclrg">6. fwknop Communications</a></li>
    <ul>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#6.1">SPA Packet Format</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#6.2">Raw SPA Packets</a></li>
    </ul>

<li><a href="/fwknop/docs/fwknop-tutorial.html#7" class="toclrg">7. fwknop Development</a></li>
    <ul>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#7.1">Programming Languages and Style</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#7.2">Source Control (git)</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#7.3">Older Perl Releases</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#7.4">Submitting Patches</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#7.5">Primary Developers</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#7.6">Mailing List</a></li>
    </ul>
<li><a href="/fwknop/docs/fwknop-tutorial.html#8" class="toclrg">8. References and Further Reading</a></li>
    <ul>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#8.1">Reference List</a></li>
        <li><a href="/fwknop/docs/fwknop-tutorial.html#8.2">fwknop and fwknopd --help Output</a></li>
    </ul>
</ul>


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/09/single-packet-authorization-the-fwknop-approach.html</link>
<title>Single Packet Authorization: The fwknop Approach</title>
<dc:date>2012-09-10T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[
<a href="/fwknop/">
<img align="right" src="/images/chinesedoor5.jpg" width="180" height="120" title="Single Packet Authorization: The fwknop Approach" alt="Single Packet Authorization: The fwknop Approach" /></a>
There are many different port knocking implementations out there, and a few that take things
to the next level with <a href="/fwknop/docs/SPA.html">Single Packet Authorization</a>.  All
PK/SPA implementations have three primary goals: <b>1)</b> the deployment of a default-drop
firewall policy for a service (such as SSHD) in order to protect against scans, potential
vulnerabilities, and brute force password guessing attempts, <b>2)</b> the passive monitoring
of specially constructed authentication information from the PK/SPA client, and <b>3)</b> the
dynamic reconfiguration of the firewall to allow temporary access to the protected service.
<br/><br/>
The PK/SPA server never acknowledges any data from the client, so it is infeasible
to scan not only for any properly implemented PK/SPA server, but also for any protected
service.  Effectively, services become invisible to the Internet - except for those that can
produce the necessary authentication information, or those that are in a privileged
position to sniff traffic between an authenticated PK/SPA client and the target service.
<br/><br/>
Users of firewalls find value in the idea that traffic to a service can be blocked from
all but a few pre-defined networks according to the firewall policy.  Few people question
whether this is valuable from a security perspective - firewalls generally enhance security
(the occasional firewall vulnerability not withstanding).  The PK/SPA strategy extends the
notion of filtering traffic for a set of services by adding a lightweight crypto layer
to allow temporary access from networks that cannot be anticipated when the firewall policy
is written.  This provides <b><i>concealment</i></b> by default, and the SPA strategy asserts that there
is value in this.  This can apply to all sorts of services from SSHD and OpenVPN
to mail protocols like POP and IMAP and even to HTTP.  Anyone scanning for services to
target will never see a service protected by SPA.
<br/><br/>
If the above describes unifying aspects of PK/SPA software, this is where the similarities
in PK/SPA software ends.
<br/><br/>
Below are the design choices that guide fwknop development.  Other PK/SPA software make
different design choices, and whether you prefer fwknop vs. another implementation depends
at least partially on whether you agree with the following:
<br/><br/>
<ul>
    <li><b>No heavyweight interpreted languages</b>:<br/>Many people don't want to install perl,
    python, or ruby on a firewall or network gateway device.  Such languages are large and
    complex, and are implemented by similarly complex binaries that are usually themselves
    written in a language like C.  Firewalls are frequently stripped down systems that are
    designed to just filter network traffic, provide administrative interfaces and sometimes
    VPN services, and not do much else.  Both the fwknop client and server are entirely
    written in C - there is no requirement for perl, python, or any other interpreted language.
    <br/><br/></li>

    <li><b>Support embedded devices</b>:<br/>
    A consequence of fwknop being developed in C is that it only uses minimal system resources
    and can therefore support embedded devices that don't have a lot of computing power or
    main memory.  For example, where the older perl version of fwknop could not run on Linksys
    routers supported by OpenWRT, these same routers can run the newer C version of fwknop.
    <br/><br/></li>

    <li><b>Don't require admin access to run the SPA client</b>:<br/>
    There are many computing environments where users don't have privileged accounts.  This
    should not present a barrier to using the SPA client.  In fwknop, SPA packets are (by
    default) sent over a regular UDP socket and therefore require no special
    privileges.
    <br/><br/></li>

    <li><b>Don't require the manipulation of raw packet headers</b>:<br/>
    There are some SPA implementations that communicate information within specially modified
    fields within IP or TCP headers.  Such manipulation requires that the user have the
    ability to acquire a raw socket from the OS, and this requires admin level privileges.
    In addition, depending on how the SPA client manipulates packet headers when building an
    SPA packet, other monitoring systems such as an IDS or a passive OS fingerprinter may
    produce event data that unnecessarily calls attention to the SPA communications.  This
    is not to say that that is impossible to detect SPA packets generated by fwknop - it is
    just that a monitoring system is more likely to flag communications that involve
    manipulated packet headers than to generate an event for packets produced by
    fwknop.  For example, intrusion detection systems track TCP connections, and spoofed TCP
    ACK's that are not part of a proper connection (assuming non-asymmetric routing) may
    potentially be flagged.  Also, manipulated TCP options fields that don't conform to OS
    defaults will cause an OS to appear to change under the observation of things like
    <a href="http://lcamtuf.coredump.cx/p0f3/">p0f</a>.  While sometimes this is an expected
    behavior such as if a VM is being run or a system is actually a NAT device with other
    systems behind it, there are plenty of deployment scenarios where this is not expected.
    Addressing this issue at length could be a separate blog post in itself.
    <br/><br/></li>

    <li><b>Don't trust the IP header</b>:<br/>
    Any SPA implementation that trusts the source IP address in the IP header of the SPA packet
    is vulnerable to a MITM attack.  An inline device that can intercept an SPA packet
    can hold the original packet and retransmit it but with the source IP changed to
    whatever the attacker wants.  If the SPA server relies on the source IP in the
    IP header, then it has no way to know that it isn't legitimate.  If an SPA
    implementation is going to go to the trouble of leveraging cryptography - certainly
    important since replay attacks among other problems can't be prevented without it - then
    the IP should be made part of an encrypted payload.  This is exactly what fwknop does with
    the <b>-a</b> or <b>-R</b> arguments on the fwknop command line.  An attacker
    can intercept an SPA packet produced by fwknop, change the source IP and retransmit, but
    SPA server will only allow access to the IP that was originally encrypted within the SPA
    payload.
    <br/><br/></li>

    <li><b>Support server-side NAT</b>:<br/>
    There are plenty of networks with a border firewall where a remote user actually wants
    access to a service that is running on an internal system and not on the firewall itself.
    Typical ways of accessing such a service involve running VPN software, but with an SPA
    implementation that can manipulate NAT rules on the border firewall it is possible to
    transparently grant SPA users access to internal services <i>through</i> the firewall.
    With fwknop, the capability to leverage
    <a href="/blog/2009/11/creating-ghost-services-with-single-packet-authorization.html">server-side NAT</a>
    has been built in for a long time.
    <br/><br/></li>

    <li><b>Support multiple firewalls</b>:<br/>
    Because fwknop does not rely on specialized logging infrastructure or link against
    libraries that are tied to one firewall architecture or another, it can easily support
    multiple firewalls just by executing the local firewall admin command line interface.
    It currently supports <a href="http://www.netfilter.org">iptables</a> on Linux,
    <a href="http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html">ipfw</a>
    on FreeBSD and Mac OS X, and <a href="http://www.openbsd.org/faq/pf/">pf</a> on OpenBSD.
    <br/><br/></li>

    <li><b>Minimize library dependencies</b>:<br/>
    Given the design decisions made by fwknop above, it is important to minimize library
    dependencies and to audit the source code.  Here are all library dependencies in the
    fwknopd daemon including GnuPG support (this is optional):
    <pre>
$ ldd ./server/.libs/fwknopd
    linux-vdso.so.1 =&gt;  (0x00007ffeebf820e0)
    libfko.so.0 =&gt; /usr/lib/libfko.so.0 (0x00007f1a6ae930e0)
    libpcap.so.0.8 =&gt; /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 (0x00007e1a6a85c0e0)
    libc.so.6 =&gt; /lib/x86_64-linux-gnu/libc.so.6 (0x00007e1a6a49e0a0)
    libgpgme.so.11 =&gt; /usr/lib/libgpgme.so.11 (0x00007f1aeaee800e)
    /lib64/ld-linux-x86-64.so.2 (0x00007e1a6aede0e0)
    libgpg-error.so.0 =&gt; /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x0000ef1a6a06e0e0)
</pre>
    The libfko library is developed by the fwknop project for SPA encryption, decryption,
    and validation.  libpcap is a standard C library that is leveraged by a lot of
    security projects including intrusion detection systems and more.   The gpgme libraries
    are only used if you want GnuPG support, and the remaining libraries are standard
    system libraries that typical Linux binaries need.  That's it.  One may certainly
    question the use of libpcap, and in defense of this choice note that: <b>1)</b>
    fwknopd by default does not put the sniffing interface into promiscuous mode, <b>2)</b>
    fwknopd by default only pays attention to UDP packets to port 62201, <b>3)</b> if you
    examine Metasploit you'll see that there only a few exploits for pcap-based software
    and they target what rides on top of libpcap vs. libpcap itself, and <b>4)</b> even
    if there is a vulnerability in libpcap, the exploit model is different than it is
    for normal server software that you can easily scan for, and being different in this
    game is good.
    <br/><br/></li>

    <li><b>Support both symmetric and asymmetric ciphers</b>:<br/>
    Some users prefer the security properties that asymmetric crypto systems have over those
    provided by symmetric algorithms like Rijndael, or vice versa.  fwknop supports both
    Rijndael and GnuPG for SPA encryption/decryption.  On another note,
    <a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=shortlog;h=refs/heads/hmac_support">HMAC-SHA256 support</a>
    is coming soon to fwknop.
    <br/><br/></li>
</ul>


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/09/software-release-fwknop-2.0.3.html</link>
<title>Software Release - fwknop-2.0.3</title>
<dc:date>2012-09-04T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/fwknop/download/">
<img align="right" src="/images/release.png" title="fwknop-2.0.3" alt="fwknop-2.0.3 released" /></a>
The fwknop-2.0.3 release of <a  href="/fwknop"><b>fwknop</b></a> is
available for <a  href="/fwknop/download/"><b>download</b></a>.  This
is an important release that tightens up the code in several areas based on
excellent research performed by Fernando Arnaboldi of <a href="http://www.ioactive.com/">IOActive</a>.
I wish to thank Fernando for this work, and also Erik Gomez of IOActive as well
for making this research possible.  Fernando's research turned up potential DoS and/or
code execution vulnerabilities in the fwknopd server for malicious authenticated
clients, insecure filesystem permissions handling, and more.  All of these issues
have been fixed in the 2.0.3 release.
<br/><br/>
Here is the complete fwknop-2.0.3 ChangeLog:
<br/><br/>
<ul>
<li>[server] Fernando Arnaboldi from IOActive found several DoS/code
execution vulnerabilities for malicious fwknop clients that manage to
get past the authentication stage (so a such a client must be in
possession of a valid access.conf encryption key).  These vulnerabilities
manifested themselves in the handling of malformed access requests, and
both the fwknopd server code along with libfko now perform stronger input
validation of access request data.  These vulnerabilities affect
pre-2.0.3 fwknop releases.</li>
<li>[server] Fernando Arnaboldi from IOActive found a condition in which
the server did not properly validate allow IP addresses from malicious
authenticated clients.  This has been fixed with stronger allow IP
validation.</li>
<li>[client+server] Fernando Arnaboldi from IOActive found that strict
filesystem permissions for various fwknop files are not verified.  Added
warnings whenever permissions are not strict enough, and ensured that
files created by the fwknop client and server are only set to user
read/write.</li>
<li>[client] Fernando Arnaboldi from IOActive found a local buffer overflow
in --last processing with a maliciously constructed ~/.fwknop.run file.
This has been fixed with proper validation of .fwknop.run arguments.</li>
<li>[server] Fernando Arnaboldi from IOActive found several conditions in
which the server did not properly throw out maliciously constructed
variables in the access.conf file.  This has been fixed along with new
fuzzing tests in the test suite.</li>
<li>[test suite] Added a new fuzzing capability to ensure proper server-side
input validation.  Fuzzing data is constructed with modified fwknop
client code that is designed to emulate malicious behavior.</li>
<li>Fixed RPM builds by including the $(DESTDIR) prefix for uninstall-local
and install-exec-hook stages in Makefile.am.</li>
</ul>

The fwknop-2.0.3 ChangeLog can also be found
<a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=ChangeLog;h=f321a59ac7e86ce19f65d5a8fc7cd5f5893402d2;hb=refs/tags/fwknop-2.0.3">here</a>
via the fwknop <a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=summary">gitweb</a> interface.


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/08/on-gnupg-encrypted-spa-cross-packet-entropy.html</link>
<title>On GnuPG Encrypted SPA Cross-Packet Entropy</title>
<dc:date>2012-08-19T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/fwknop/">
<img align="right" src="/images/random_dice.jpg" title="fwknop GnuPG SPA packet entropy" alt="fwknop GnuPG SPA packet entropy" width="200" height="150" /></a>
After writing about SPA <a href="/blog/2012/02/on-spa-cross-packet-ciphertext-entropy.html">cross-packet entropy</a>
using the Rijndael symmetric cipher and seeing good randomization across every byte position, I thought
it would be informative to perform the same analysis for SPA packets that are encrypted with GnuPG.
Prior to this analysis, I would have thought that GnuPG would produce similar results in that there
should not be specific byte positions that would exhibit low levels of entropy, but it turns out that
there are positions where measured entropy falls off significantly.  Further, even though entropy is
reduced at these positions, there is a good reason for this and does not indicate an issue with how
fwknop leverages GnuPG (or with GnuPG itself).
<br/><br/>
First, recall that for Rijndael, the set of SPA packets as profiled by the
<a href="http://www.cipherdyne.org/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=extras/spa-entropy/spa-entropy.pl;h=a5ebd7fddaba9bae7393227fb395422781de816d;hb=refs/heads/hmac_support">spa-entropy.pl</a> script along with the <b>ent</b> program produced the following graph that shows about 7.80 bits
of entropy per byte on average:
<img src="/images/1000_spa_cbc.gif" title="SPA entropy for CBC mode" alt="SPA entropy for CBC mode" />
Given this graph, it is apparent that Rijndael comes pretty close to producing data that looks
quite random across every byte position and there are no significant outliers.  Now, let us run
the spa-entropy.pl script in <b>--gpg</b> mode in order to instruct the fwknop client to generate
SPA packets that are encrypted with GnuPG:

<pre>
$ ./spa-entropy.pl -f 1000_pkts.data -r -c 1000 --base64-decode --gpg
[+] 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 ../../test/local_spa.key -B 1000_pkts.data -b -v --test --gpg-recipient-key 361BBAD4 --gpg-signer-key 6A3FAD56 --gpg-home-dir ../../test/conf/client-gpg 2&gt; /dev/null

[+] Read in 1000 SPA packets...
[+] Min entropy: 0.00 at byte: 1
[+] Max entropy: 7.85 at byte: 654
[+] Creating entropy.gif gnuplot graph...
</pre>

This results in the following gnuplot graph:

<img src="/images/1000_spa_gpg.gif" title="SPA entropy for GnuPG cipher" alt="SPA entropy for GnuPG cipher" />

Wow, it is immediately apparent that there is something quite different about the measured entropy
for GnuPG SPA packets.  There are three areas of interest: 1) the first four bytes, 2) two
bytes or so around byte 275, and 3) four bytes around byte 525.  Why does the entropy fall
off so drastically at these locations?  The first region is most likely an artifact of the
usage of the same GnuPG key across all SPA packets along with the fact that the fwknop client
only strips off the first two bytes if they match the string "hQ" in the base64 encoded SPA
data.  This string corresponds to the same values that the <b>/etc/magic</b> database
provides to the <b>file</b> command - it is the same across all GnuPG encrypted data regardless
of which keys are used.  But, the next four bytes aren't as predictable, and must vary from
key to key so the fwknop client can't use a simple strategy of removing these bytes before an
SPA packet is placed on the wire.  (The whole reason for removing the bytes in the first place
is to make it slightly more difficult to write a simplistic Snort signature for SPA packet
detection.)  The next two regions can be explained by the fact that the OpenPGP protocol
(see: <a href="http://tools.ietf.org/html/rfc4880">RFC 4880</a>) often results in messages that
are created with partial body lengths and corresponding length headers must be added into the
data.  Because SPA packets created by fwknop are usually nearly identical in size, these length
headers would be added around the same positions and have the same data - this results in the
entropy dips around bytes 275 and 525 across multiple SPA packets.
<br/><br/>
An interesting next step might be to run the same analysis on systems with poor entropy
sources.  On such a system, it would then be informative to have the fwknop client switch to
Dan Kaminsky's new <a href="http://dankaminsky.com/2012/08/15/dakarand/">dakarand</a> entropy
source that is based on clock drift and see
if things improve.


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/08/software-release-fwknop-2.0.2.html</link>
<title>Software Release - fwknop-2.0.2</title>
<dc:date>2012-08-18T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/fwknop/download/">
<img align="right" src="/images/release.png" title="fwknop-2.0.2" alt="fwknop-2.0.2 released" /></a>
The fwknop-2.0.2 release of <a  href="/fwknop"><b>fwknop</b></a> is
available for <a  href="/fwknop/download/"><b>download</b></a>.  This release
includes new support for SPA using GPG keys in automated environments, and this
particularly affects fwknopd server deployments on systems where the GnuPG engine
seems to require gpg-agent or pinentry for passphrase entry associated with GnuPG
keys.  In addition, a couple of important bug fixes were made to ensure replay
attack detection is properly done when SPA packet prefixes are added/removed (this
is done to increase the difficulty of using Snort or other IDS to detection SPA
packets on the wire).
<br/><br/>
Here is the complete fwknop-2.0.2 ChangeLog:
<br/><br/>

<ul>
<li>[server] For GPG mode, added a new access.conf variable
"GPG_ALLOW_NO_PW" to make it possible to leverage a server-side GPG key
pair that has no associated password.  This comes in handy when a system
requires the user to leverage gpg-agent / pinentry which can present a
problem in automated environments as required by the fwknopd server.
Now, it might seem like a problem to remove the passphrase from a GPG
key pair, but it's important to note that simply doing this is little
worse than storing the passphrase in the clear on disk anyway in the
access.conf file.  Further, this link helps provide additional detail:
<br/><br/>
<a href="http://www.gnupg.org/faq/GnuPG-FAQ.html#how-can-i-use-gnupg-in-an-automated-environment" >
http://www.gnupg.org/faq/GnuPG-FAQ.html#how-can-i-use-gnupg-in-an-automated-environment</a>
<br/><br/>
</li>
<li>[client] In IP resolution mode (-R) changed HTTP connection type to
'close' since there is no need for connection persistence, and indeed the
client expects to just get the IP and the connection to be closed.
Jonathan Schulz submitted a patch for this.</li>
<li>[client] Bug fix to ensure that all data is read via recv() from a
remote webserver IP resolution mode (-R).  Previously IP resolution
could fail if HTTP headers were transferred separately from the data
(for whatever reason).  Jonathan Schulz submitted a patch for this.</li>
<li>[client] Added backup check against a cipherdyne.com 'myip' cgi instance
in -R mode if the normal check against cipherdyne.org fails.</li>
<li>[server] Bug fix to implement FLUSH_IPT_AT_INIT and FLUSH_IPT_AT_EXIT
functionality.  These are enabled by default, and now iptables rules
added by fwknopd can be made persistant by setting these variables to
"N" in the fwknopd.conf file (this is not a recommended setting
however).</li>
<li>[server] Added FLUSH_IPFW_AT_INIT and FLUSH_IPFW_AT_EXIT for ipfw
firewalls to emulate the corresponding functionality that is implemented
for iptables firewalls.  This was suggested by Jonathan Schulz.</li>
<li>[server] Replay attack bug fix to ensure that an attacker cannot force a
replay attack by intercepting an SPA packet and the replaying it with the
base64 version of "Salted__" (for Rindael) or the "hQ" prefix (for
GnuPG).  This is an important fix.  The following comment was added into
the fwknopd code:
<br/><br/>
<pre>
/* Ignore any SPA packets that contain the Rijndael or GnuPG prefixes
&nbsp;* since an attacker might have tacked them on to a previously seen
&nbsp;* SPA packet in an attempt to get past the replay check.  And, we're
&nbsp;* no worse off since a legitimate SPA packet that happens to include
&nbsp;* a prefix after the outer one is stripped off won't decrypt properly
&nbsp;* anyway because libfko would not add a new one.
*/
</pre>
</li>
<li>[server] Fixed a memory leak bug in the replay attack detection code.
The leak was found with the test suite in --enable-valgrind mode, and
here is the valgrind trace that exposed it:
<br/><br/>
<pre>
44 bytes in 1 blocks are definitely lost in loss record 2 of 2
&nbsp;&nbsp;&nbsp;at 0x482BE68: malloc (in
&nbsp;&nbsp;&nbsp;/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
&nbsp;&nbsp;&nbsp;by 0x490EA50: strdup (strdup.c:43)
&nbsp;&nbsp;&nbsp;by 0x10CD69: incoming_spa (incoming_spa.c:162)
&nbsp;&nbsp;&nbsp;by 0x10E000: process_packet (process_packet.c:200)
&nbsp;&nbsp;&nbsp;by 0x4862E63: ??? (in /usr/lib/i386-linux-gnu/libpcap.so.1.1.1)
&nbsp;&nbsp;&nbsp;by 0x4865667: pcap_dispatch (in /usr/lib/i386-linux-gnu/libpcap.so.1.1.1)
&nbsp;&nbsp;&nbsp;by 0x10DABF: pcap_capture (pcap_capture.c:226)
&nbsp;&nbsp;&nbsp;by 0x10A798: main (fwknopd.c:299)
</pre>
</li>
<li>[test suite] Added GPG tests for keyrings that have no associated
passphrases.</li>
<li>[server] Implemented a new check to ensure that the iptables 'comment'
match exists to ensure the proper environment for fwknopd operations.
This check is controlled by the new ENABLE_IPT_COMMENT_CHECK variable,
and was suggested by Hank Leininger.</li>
<li>[server] 'make install' fix to ensure restrictive permissions on the
/etc/fwknop/ directory and /etc/fwknop/* files.  Also updated the 'make
install' step to not overwrite any existing config files in /etc/fwknop/
and instead install new copies from the source tree at
/etc/fwknop/fwknopd.conf.inst and /etc/fwknop/access.conf.inst</li>
</ul>

The complete fwknop-2.0.2 ChangeLog can be found
<a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=ChangeLog;h=1568a1aa4e5088a5b261431a5e0e3ed93d63d9aa;hb=6de386b93704fe11786f4696b2badba4bc15c66b">here</a>
via the fwknop <a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=summary">gitweb</a> interface.


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/07/hope-9-talk-recent-advances-in-single-packet-authorization.html</link>
<title>HOPE 9 Talk: Recent Advances in Single Packet Authorization</title>
<dc:date>2012-07-24T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="http://www.hopenumbernine.net">
<img align="right" src="/images/hope9.png" title="SPA talk slides from the HOPE 9 conference" alt="SPA talk slides from the HOPE 9 conference" /></a>
About a week ago at the <a href="http://www.hopenumbernine.net">HOPE Number Nine</a>
conference in NYC I gave a talk entitled "<b>Recent Advances in Single Packet Authorization</b>"
(<a href="/talks/HOPE_Recent_Advances_in_Single_Packet_Authorization.pdf">slides</a>).
In some respects this talk was a follow up to my
<a href="/blog/2008/07/the-last-hope-conference-port-knocking-and-spa-talk-wrap-up.html">talk on SPA</a>
and fwknop from the
<a href="http://www.thelasthope.org/">Last HOPE</a> conference in 2008.  Back then,
the work on the all-C implementation of fwknop had just begun and this work was
designed to address some of the questions that were brought up such as "have you
audited all of the code in the perl module dependencies?" and "does the fwknop client run
on the iPhone?".  With the fwknop-2.0 release, the client does run on the iPhone and
many other devices besides, and auditing huge code bases from dependent perl modules
is no longer necessary.
<br/><br/>
Beyond this, fwknop strives to make sophisticated usage of NAT for authenticated
connections, and this is realized with a use case whereby fwknop is used to protect
against the recent Windows RDP vulnerability
(<a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-0002">CVE-2012-0002</a>)
within Amazon Virtual Private Cloud (VPC) networks.  Of course, at this point the
vulnerability has been patched, but for a time it wasn't and this is where SPA comes
in.  One challenge for this is the fact that fwknopd does not directly support a
Windows firewall.  The solution is to deploy a virtual Linux instance on the VPC
network and then use either the normal SNAT/DNAT capabilities in fwknopd, or
use the new FORCE_NAT mode.  Either way, RDP connections can be made to internal
Windows systems <i>through</i> the Linux "jump host" after a proper SPA packet is
sent.  Further, only one Amazon Elastic IP is required in order for this to work -
the IP is bound to the Linux host and no externally routable IP is given to the
Windows host.  The Windows system only ever sees what appears to be a connection
from the Linux host even though it has really been NAT'd through from the external
Internet.  Below is a network diagram that illustrates this, and more detail can
be found in the <a href="/talks/HOPE_Recent_Advances_in_Single_Packet_Authorization.pdf">slides</a>.
<img height="500" width="550" src="/images/amazon_spa_rdp_architecture.jpg" />.

]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/07/software-release-fwknop-2.0.1.html</link>
<title>Software Release - fwknop-2.0.1</title>
<dc:date>2012-07-24T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/fwknop/download/">
<img align="right" src="/images/release.png" title="fwknop-2.0.1" alt="fwknop-2.0.1 released" /></a>
The fwknop-2.0.1 release is <a  href="/fwknop"><b>fwknop</b></a> is
available for <a  href="/fwknop/download/"><b>download</b></a>.  This is mainly
a bug fix release before the new
<a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=shortlog;h=refs/heads/hmac_support">HMAC-SHA256</a>
work is ready for general consumption.  A couple of the fixes are important for PF users on
OpenBSD and for people who use the same encryption key within multiple access stanzas.
<br/><br/>
Here is the complete fwknop-2.0.1 ChangeLog:
<br/><br/>
<ul>
<li>[server] Bug fix where the same encryption key used for two stanzas in
the access.conf file would result in access requests that matched the
second stanza to always be treated as a replay attack.  This has been
fixed for the fwknop-2.0.1 release, and was reported by Andy Rowland. Now
the fwknopd server computes the SHA256 digest of raw incoming payload
data before decryption, and compares this against all previous hashes.
Previous to this commit, fwknopd would add a new hash to the replay
digest list right after the first access.conf stanza match, so when SPA
packet data matched the second access.conf stanza a matching replay
digest would already be there.</li>
<li>[server] Updated PCAP_LOOP_SLEEP default to 1/10th of a second (in
microseconds).  This was supposed to be the default anyway, but C
Anthony Risinger reported a bug where fwknopd was consuming more
resources than necessary, and the cause was PCAP_LOOP_SLEEP set by
default to 1/100th of a second - this has been fixed.</li>
<li>[libfko] Added SPA message validation calls to fko decoding routines to
help ensure that SPA messages conform to expected values.</li>
<li>Bug fix for PF firewalls: updated the PF anchor check to not rely on
listing the PF policy - fwknopd now uses 'pfctl -s Anchor' instead.</li>
<li>[test suite] Added parsing of valgrind output to produce a listing of
functions that have been flagged - this assists in the development
process to ensure that fwknop is not leaking memory.</li>
<li>[test suite] Bug fix on Mac OS X systems to account for libfko.dylib path
instead of libfko.so.  This fixes the existence check for libfko.</li>
<li>[test suite] Added tests for --nat-local mode.</li>
<li>[client] Fixed several minor memory leaks caught by valgrind.</li>
<li>[libfko] Minor gcc warning fix: fko_decode.c:43:17: warning: variable
‘edata_size’ set but not used [-Wunused-but-set-variable].</li>
<li>Updated fwknopd init script for Debian systems (contributed by Franck
Joncourt).</li>
</ul>
The complete fwknop-2.0.1 ChangeLog can be found
<a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=ChangeLog.git;h=161aba44b186a08bed9e4210b3137b0908947301;hb=eda26f20692b905eb90eb63c062ffc730bed399f">here</a>
via the fwknop <a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=summary">gitweb</a> interface.


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/04/software-release-fwsnort-1.6.2.html</link>
<title>Software Release - fwsnort-1.6.2</title>
<dc:date>2012-04-28T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/fwsnort/download/">
<img align="right" src="/images/release.png" title="fwsnort-1.6.2" alt="fwsnort-1.6.2 released" /></a>
The 1.6.2 release of <a  href="/fwsnort"><b>fwsnort</b></a> is available for
<a  href="/fwsnort/download/"><b>download</b></a>.  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.
<br/><br/>
Here is the complete fwsnort-1.6.2
<a href="/cgi-bin/gitweb.cgi?p=fwsnort.git;a=blob;f=ChangeLog;h=e33498631edb15f296ce5c34b4d573826dba262f;hb=5d1d646c8806ab8af982a5c8f395e72248cd2e54">ChangeLog</a>:
<br/><br/>
<ul>
<li>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.</li>
<li>Replaced Net::IPv4Addr with the excellent NetAddr::IP module which has
comprehensive support for IPv6 address network parsing and comparisons.</li>
<li>Moved the fwsnort.sh script and associated files into the
/var/lib/fwsnort/ directory.  This was suggested by Peter Vrabec.</li>
<li>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.</li>
<li>Bug fix for 'qw(...) usage as parenthesis' warnings for perl &gt; 5.14</li>
<li>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.</li>
</ul>

]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/04/software-release-psad-2.2.html</link>
<title>Software Release - psad-2.2</title>
<dc:date>2012-04-21T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/psad/download/">
<img align="right" src="/images/release.png" title="psad-2.2" alt="psad-2.2 released" /></a>
After a long development cycle, the 2.2 release of <a  href="/psad"><b>psad</b></a> is
available for <a  href="/psad/download/"><b>download</b></a>.  This release adds
major new functionality for the detection of malicious traffic that is delivered over IPv6 by
parsing <b>ip6tables</b> logs.  A significant portion of this capability is enabled by the
excellent <a href="http://search.cpan.org/~miker/NetAddr-IP-4.059/IP.pm">NetAddr::IP</a> 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
<a href="/cgi-bin/gitweb.cgi?p=psad.git;a=shortlog;h=refs/heads/openbsd_integration">openbsd_integration</a>
branch.
<br/><br/>
Here is an excerpt of the psad-2.2 ChangeLog:
<br/><br/>
<ul>
<li>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:
<br/><br/>
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
<br/><br/>
Detection of malicious IPv6 traffic can be disabled via a new
ENABLE_IPV6_DETECTION config variable.</li>
<li>For ICMP6 traffic, added protocol validation for ICMP6 type/code
combinations.</li>
<li>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.</li>
<li>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).</li>
<li>Bug fix for 'qw(...) usage as parenthesis' warnings for perl &gt; 5.14</li>
<li>Bug fix that caused psad to emit the following:
<br/><br/>
Undefined subroutine &amp;main::LOG_DAEMON called at ./psad line 10071.
<br/><br/>
This problem was noticed by Robert and reported on the psad mailing list.</li>
<li>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:
<br/><br/>
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 ]
</li>
</ul>
The complete psad-2.2 ChangeLog can be found
<a href="/cgi-bin/gitweb.cgi?p=psad.git;a=blob;f=ChangeLog;h=abe9d76fa29bdb35ad1a15a7022810f313cf7534;hb=0afb375fbaae66775ac327d8c2ed38f64e663b8b">here</a>
via the psad <a href="/cgi-bin/gitweb.cgi?p=psad.git;a=summary">gitweb</a> interface.


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/03/cipherdyne.org-git-repositories-safe-after-github-hack.html</link>
<title>cipherdyne.org git Repositories Safe After github Hack</title>
<dc:date>2012-03-07T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/fwknop/">
<img align="right" src="/images/github_logo.png" title="github" alt="github" width="200" height="100" /></a>
After a <a href="http://www.extremetech.com/computing/120981-github-hacked-millions-of-projects-at-risk-of-being-modified-or-deleted">widely publicized</a>
hack of <a href="http://www.github.com">github</a> (now fixed), I thought it would be a good idea to ensure
that the <a href="/git">cipherdyne.org git repositories</a> 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 "<a href="http://blog.mhartl.com/2008/09/21/mass-assignment-in-rails-applications/">mass assignment</a>"
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".
<br/><br/>
Now, in order to add a backdoor into a code base on github, what would an attacker need to do?
<br/><br/>
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, <em>git add ...</em>, <em>git commit ...</em> - 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
<a href="http://book.git-scm.com/1_the_git_object_model.html">object model</a>, and a SHA1 collision such
that the bogus data is <em>also</em> working code would be "computationally difficult" to say the least
(<a href="http://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html">attacks against SHA1</a> 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 <em>.git/objects/pack/*.pack</em> file and then try to clone it to
see what happens:

<pre>
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
</pre>

The repository has essentially been corrupted and the clone operation fails.
<br/><br/>

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.
<br/><br/>

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 <em>git pull ... </em> 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 <em>git fetch</em> 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:
<br/><br/>
<ul>
<li>On my system where the private repositories live, create two directories <em>GH/</em> and <em>CD/</em>, and clone all
of the github repositories into the <em>GH</em> directory and all cipherdyne.org repository mirrors into the <em>CD</em>
directory. We'll assume that the private repositories live in a directory called <em>private/</em></li>
<li>For each repository pair in the <em>GH</em> and <em>CD</em> directories, diff the output of <em>git rev-list --all</em>.
There should be zero differences here.</li>
<li>If the step above checks out, then diff the <em>git rev-list --all</em> output across the
<em>GH/&lt;repo&gt;</em> and <em>private/&lt;repo&gt;</em> 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 <em>GH/&lt;repo&gt;</em> that is not in a <em>private/&lt;repo&gt;</em>.</li>
</ul>

Here are a few commands to accomplish the above (we'll assume that the <em>git clone --bare &lt;repo&gt;</em>
steps have already been done for brevity):

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

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:

<pre>
$ for r in fwknop psad gpgdir fwsnort IPTables-Parse IPTables-ChainMgr
&gt; do
&gt; echo "[+] Checking $r...";
&gt; diff -u &lt;(cd ~/private/$r.git &amp;&amp; git rev-list --all ) &lt;( cd ~/GH/$r.git &amp;&amp; git rev-list --all) | egrep "^\+" | grep -v @
&gt; 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...
</pre>

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:
<pre>
+fff688f5b4275152636d8959f67bbcd46839fbbb
</pre>

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.


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/02/on-spa-cross-packet-ciphertext-entropy.html</link>
<title>On SPA Cross-Packet Ciphertext Entropy</title>
<dc:date>2012-02-13T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/fwknop/">
<img align="right" src="/images/random_dice.jpg" title="fwknop SPA packet entropy" alt="fwknop SPA packet entropy" width="200" height="150" /></a>
With fwknop now re-written in C for the <a href="/blog/2012/01/software-release-fwknop-2.0.html">2.0 release</a>,
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 <i>might</i> 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.
<br/><br/>
Although this post has some similarities with an older blog entry
"<a href="/blog/2008/09/visualizing-spa-packet-randomness.html">Visualizing SPA Packet Randomness</a>",
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
<a href="http://en.wikipedia.org/wiki/Salt_%28cryptography%29">salt</a>
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.
<br/><br/>
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
"<a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=shortlog;h=refs/heads/crypto_update">crypto_update</a>"
branch has been created for this work.  The default AES encryption mode used by fwknop is cipher block chaining
(CBC) mode as defined
<a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=lib/fko.h;h=e694a718a8fd51b02572384e57428101903d592e;hb=71690a1de45b273789af4e26a01594e9d5150eff#l179">here</a>.
Within the <b>crypto_update</b> branch there is a new script
"<a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=extras/spa-entropy/spa-entropy.pl;h=a5ebd7fddaba9bae7393227fb395422781de816d;hb=71690a1de45b273789af4e26a01594e9d5150eff">spa-entropy.pl</a>"
that is designed to execute the fwknop client multiple times, collect the encrypted SPA packet data, use the
<a href="http://www.fourmilab.ch/random/">ent</a> 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.
<br/><br/>
As a motivating
<a href="http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation">example</a> 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:
<br/><br/>

<table>
<tr>
<td><img src="/images/tux.jpg" title="plaintext Tux" alt="plaintext Tux" /></td>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>AES ECB encryption -&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</b></td>
<td><img src="/images/tux_ecb.jpg" title="AES ECB encrypted Tux" alt="AES ECB encrypted Tux" /></td>
</tr>
</table>

<i><b>Encryption Fail.</b></i>
<br/><br/>
Now, let's take a look at SPA packet entropy with the <b>spa-entropy.pl</b> script.  For reference, fwknop
builds SPA packets according to the following data format before encryption:
<br/><br/>
<b>[random data: 16 bytes]:[username]:[timestamp]:[version]:[message type]:[access request]:[digest]</b>
<br/><br/>

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 <b>spa-entropy.pl</b> script:

<br/><br/>
<code>
$ ./spa-entropy.pl -f 1000_pkts.data -r -c 1000 --base64-decode<br/>
[+] Running fwknop client via the following command:<br/>
<br/>
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<br/>
<br/>
[+] Read in 1000 SPA packets...<br/>
[+] Min entropy: 7.75 at byte: 54<br/>
[+] Max entropy: 7.86 at byte: 115<br/>
[+] Creating entropy.gif gnuplot graph...<br/>
</code>
<br/><br/>

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.

<img src="/images/1000_spa_cbc.gif" title="SPA entropy for CBC mode" alt="SPA entropy for CBC mode" />

As an aside, here is
what <b>ent</b> reports against the local <b>/dev/urandom</b> entropy source on my Linux system, and it is
the "Entropy =" line that <b>spa-entropy.pl</b> parses for each SPA byte slice:

<br/><br/>
<code>
$ dd if=/dev/urandom count=1000 |ent<br/>
1000+0 records in<br/>
1000+0 records out<br/>
512000 bytes (512 kB) copied, 0.128497 s, 4.0 MB/s<br/>
Entropy = 7.999625 bits per byte.<br/>
<br/>
Optimum compression would reduce the size<br/>
of this 512000 byte file by 0 percent.<br/>
<br/>
Chi square distribution for 512000 samples is 265.77, and randomly<br/>
would exceed this value 50.00 percent of the times.<br/>
<br/>
Arithmetic mean value of data bytes is 127.5076 (127.5 = random).<br/>
Monte Carlo value for Pi is 3.138715386 (error 0.09 percent).<br/>
Serial correlation coefficient is -0.001293 (totally uncorrelated = 0.0).
</code>
<br/><br/>

Now, let's switch to ECB mode and see what happens (just run the <b>spa-entropy.pl</b> script
with '-e ecb'):

<img src="/images/1000_spa_ecb.gif" title="SPA entropy for ECB mode" alt="SPA entropy for ECB mode" />

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):

<br/><br/>
<code>
$ git diff lib/cipher_funcs.c<br/>
diff --git a/lib/cipher_funcs.c b/lib/cipher_funcs.c<br/>
index 0a0ce3b..32c8bd6 100644<br/>
--- a/lib/cipher_funcs.c<br/>
+++ b/lib/cipher_funcs.c<br/>
@@ -153,6 +153,8 @@ rij_salt_and_iv(RIJNDAEL_context *ctx, const char *pass, const unsigned char *da<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; get_random_data(ctx-&gt;salt, 8);<br/>
&nbsp;&nbsp;&nbsp;&nbsp; }<br/>
 <br/>
+&nbsp;&nbsp;&nbsp;&nbsp;memset(ctx-&gt;salt, 0x00, 8);<br/>
+<br/>
&nbsp;&nbsp;&nbsp;&nbsp; /* Now generate the key and initialization vector.<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  * (again it is the perl Crypt::CBC way, with a touch of<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  * fwknop).
</code>
<br/><br/>

Here is what <b>spa-entropy.pl</b> reports after recompiling fwknop with the patch above:

<img src="/images/1000_spa_ecb_zero_salt.gif" title="SPA entropy for ECB mode zero salt" alt="SPA entropy for ECB mode zero salt" />

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.
<br/><br/>

As a final contrasting case, let's leave the patch applied to force the salt to zero, but now
switch back to CBC mode:

<img src="/images/1000_spa_cbc_zero_salt.gif" title="SPA entropy for CBC mode zero salt" alt="SPA entropy for CBC mode zero salt" />

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.
<br/><br/>
Although <b>spa-entropy.pl</b> 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.

]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/01/bing-indexing-of-gitweb.cgi-links.html</link>
<title>Bing Indexing of gitweb.cgi Links</title>
<dc:date>2012-01-21T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="http://www.bing.com/">
<img align="right" src="/images/bing-logo.png" height="100" width="130" title="Bing indexing of gitweb.cgi links" alt="Bing indexing of gitweb.cgi links" /></a>
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
<a href="http://www.cipherdyne.org/cgi-bin/gitweb.cgi">gitweb</a>.
(Personally, I like the "<a href="http://atrey.karlin.mff.cuni.cz/~clock/twibright/links">links2</a>"
text-based browser rendering of gitweb pages - nice and clean.)
<br/><br/>
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:
<br/><br/>
<table class="ctable" cellspacing="1" cellpadding="1">
<tr><td>Hits</td><td>Percentage</td><td>User-Agent</td></tr>
<tr><td><b>505055</b></td><td>81.01%</td><td><b>Mozilla/5.0 (compatible; bingbot/2.0;)</b></td></tr>
<tr><td><b>50242</b></td><td>8.06%</td><td><b>msnbot/2.0b (+http://search.msn.com/msnbot.htm)._</b></td></tr>
<tr><td><b>25707</b></td><td>4.12%</td><td><b>Mozilla/5.0 (compatible; Ezooms/1.0; ezooms.bot@gmail.com)</b></td></tr>
<tr><td><b>6583</b></td><td>1.06%</td><td><b>Feedfetcher-Google; (+http://www.google.com/feedfetcher.html;)</b></td></tr>
<tr><td><b>4310</b></td><td>0.69%</td><td><b>Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)</b></td></tr>
<tr><td><b>1956</b></td><td>0.31%</td><td><b>Mozilla/5.0 (compatible; SISTRIX Crawler; http://crawler.sistrix.net/)</b></td></tr>
<tr><td><b>1905</b></td><td>0.31%</td><td><b>Mozilla/5.0 (compatible; Purebot/1.1; +http://www.puritysearch.net/)</b></td></tr>
<tr><td><b>1751</b></td><td>0.28%</td><td><b>Mozilla/5.0 (compatible; Yahoo! Slurp;)</b></td></tr>
<tr><td><b>1625</b></td><td>0.26%</td><td><b>Mozilla/5.0 (compatible; MJ12bot/v1.4.0;)</b></td></tr>
<tr><td><b>1451</b></td><td>0.23%</td><td><b>TwengaBot-Discover (http://www.twenga.fr/bot-discover.html)</b></td></tr>
</table>
<br/><br/>
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 <i>per day</i>,
and this figure is more than 20 times the third place bot.  Google is in
a distant forth place, even though Google used to
<a href="/blog/2009/09/google-indexing-of-trac-repositories.html">heavily index Trac repositories</a>.
<br/><br/>
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:
<img src="/images/gitweb_user_agents.gif" title="top 5 gitweb indexers" alt="top 5 gitweb indexers" />

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:
<img src="/images/gitweb_user_agents_logscale.gif" title="top 5 gitweb indexers logarithmic" alt="top 5 gitweb indexers logarithmic" />

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.
<br/><br/>
How does this compare with hits across other portions of cipherdyne.org?  Bing indexing is still
far and away the largest outlier:
<img src="/images/all_user_agents.gif" title="top 5 indexers of cipherdyne.org" alt="top 5 indexers of cipherdyne.org" />

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.
<br/><br/>
<b>Update 01/23</b>: 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 "<a href="/scripts/user_agent_stats_pl.tar.gz">user_agent_stats.pl</a>"
parses Apache logs and produces user-agent graphs with Gnuplot as shown in this post.  The second
"<a href="/scripts/uniq_hits_pl.tar.gz">uniq_hits.pl</a>" 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):
<br/><br/>
<code>
$ zcat ../logs/cipherdyne.org*.gz |grep "index.html" | ./user_agent_stats.pl -p index_hits<br/>
[+] Parsing Apache log data...<br/>
[+] Total agents: 1769 (abbreviated to: 174 agents)<br/>
[+] Executing gnuplot...<br/>
    Plot file:  index_hits.gif<br/>
    Agent stats: index_hits.agents
</code>
<br/><br/>


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2012/01/software-release-fwknop-2.0.html</link>
<title>Software Release - fwknop-2.0</title>
<dc:date>2012-01-02T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/fwknop/download/">
<img align="right" src="/images/release.png" title="fwknop-2.0" alt="fwknop-2.0 released" /></a>
After a long development cycle, <a  href="/fwknop"><b>fwknop-2.0</b></a> has
been <a href="/fwknop/download">released</a>.  This is the first production release of the
fully re-written C version of fwknop, and is the culmination of an effort to provide
<a href="/fwknop/docs/SPA.html">Single Packet Authorization</a> 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
<a href="https://lists.sourceforge.net/lists/listinfo/fwknop-discuss">mailing list</a>.
<br/><br/>
<b>Update 01/03</b>: 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.
<br/><br/>
<b>Update 01/07</b>: Damien Stuart has built
<a href="/fwknop/download/binaries.html">RPM files</a> for fwknop on RHEL5, RHEL6,
Fedora 15, 16, and 17 and for other architectures the Fedora koji build system can
produce.

]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2011/12/software-release-fwknop-2.0rc5.html</link>
<title>Software Release - fwknop-2.0rc5</title>
<dc:date>2011-12-11T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="/fwknop/download/">
<img align="right" src="/images/fwknop-iphone.jpg" height="275" width="147" title="fwknop-2.0rc5" alt="fwknop-2.0rc5 released" /></a>
The 2.0rc5 candidate release of <a  href="/fwknop"><b>fwknop</b></a> is available for
<a  href="/fwknop/download/"><b>download</b></a>.  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:
<br/><br/>
<b>iPhone fwknop client</b>:  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
<a href="http://www.cipherdyne.org/contact.html">contact me</a>.
<br/><br/>
<b>PF firewall support on OpenBSD</b>:  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 <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=pf">PF</a>
firewall on OpenBSD systems.  By interfacing with the <b>pfctl</b> 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 <i>pfctl -a &lt;anchor&gt; -f -</i> 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.
<br/><br/>
<b>Expiring SPA keys</b>:  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 <b>access.conf</b> 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.
<br/><br/>
<b>FORCE_NAT mode</b>:  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.
<br/><br/>
<b>lsof launcher</b>: 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.
<br/><br/>
Several other changes and small fixes have been made as well.  The fwknop test
suite supports running all tests through the excellent
<a href="http://www.valgrind.org/">valgrind</a> project, and this enabled
several memory handling issues to be found and corrected.
<br/><br/>
fwknop is released under the GPL version 2, and the complete fwknop-2.0rc5
ChangeLog can be found
<a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=ChangeLog-v2.0rc5;h=65f565b705c1a74ccd93deef24d68e738eb288d4;hb=7ac5319847b6cf75dc5d5cdb4cdd41b55ee711b3">here</a>
via the fwknop <a href="/cgi-bin/gitweb.cgi?p=fwknop.git;a=summary">gitweb</a> interface.


]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2011/10/webknock.org-single-packet-authorization-proxy.html</link>
<title>WebKnock.org Single Packet Authorization Proxy</title>
<dc:date>2011-10-10T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

Vasilis Mavroudis has developed a web proxy called <a href="https://webknock.org/">WebKnock.org</a>
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.
<br/><br/>
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 <a href="/fwknop/docs/gpghowto.html">gpg keys</a> 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.
<br/><br/>
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.
<br/><br/>
The service is free, and will hopefully be open-sourced at some point as well.  If there are
any issues, please either <a href="/contact.html">email me</a> or open a ticket on the fwknop
<a href="https://github.com/mrash/fwknop/issues">github interface</a>.  Here is a
screenshot of the current webknock.org site:
<a href="/images/webknock_screenshot.png"><img src="/images/webknock_screenshot.png" height="320" width="500" title="webknock.org SPA proxy" alt="webknock.org SPA proxy" /></a>

]]></description>
</item>

<item>
<link>http://www.cipherdyne.org/blog/2011/08/fwknop-in-the-openwrt-and-pentoo-linux-distributions.html</link>
<title>fwknop in the OpenWrt and Pentoo Linux Distributions</title>
<dc:date>2011-08-23T21:01:30-05:00</dc:date>
<dc:creator>Michael Rash</dc:creator>
<description><![CDATA[

<a href="https://openwrt.org/">
<img align="right" src="/images/openwrt-logo.png" height="51" width="200" title="fwknop in OpenWrt" alt="fwknop in OpenWrt" /></a>
The C version <a href="/fwknop">fwknop</a> has now made it into the <a href="https://openwrt.org">OpenWrt</a>
Linux distribution for embedded devices.  Jonathan Bennett made this possible
by contributing a <a href="http://www.cipherdyne.org/cgi-bin/gitweb.cgi?p=fwknop.git;a=commitdiff;h=e7d275ee312c618c3233a504c5aa54b72312f39a">Makefile</a>
for OpenWrt, and it was picked up the OpenWrt maintainers.  It is good to
see progress made towards the integration of
<a href="/fwknop/docs/SPA.html">Single Packet Authorization</a> into operating
systems that are designed to function as secure gateway devices between multiple
networks.
<br/><br/>
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:
<br/><br/>
<code>
$ git clone git://nbd.name/packages.git openwrt_packages.git<br/>
Initialized empty Git repository in /home/mbr/src/openwrt_packages.git/.git/<br/>
remote: Counting objects: 56118, done.<br/>
remote: Compressing objects: 100% (21342/21342), done.<br/>
remote: Total 56118 (delta 29694), reused 54875 (delta 29054)<br/>
Receiving objects: 100% (56118/56118), 11.85 MiB | 2.57 MiB/s, done.<br/>
Resolving deltas: 100% (29694/29694), done.<br/>
$ cd openwrt_packages.git<br/>
$ git ls-files |grep fwknop<br/>
net/fwknop/Makefile<br/>
$ git log net/fwknop/Makefile<br/>
commit 89475e5d6136833fa3b59c3d47c4f2be02718c7a<br/>
Author: florian &lt;florian@3c298f89-4303-0410-b956-a3cf2f4a3e73&gt;<br/>
Date:   Wed Aug 17 10:13:20 2011 +0000<br/>
<br/>
    [package] add fwknopd<br/>
<br/>
    Signed-off-by; Jonathan Bennett &lt;[email removed]&gt;<br/>
<br/>
    git-svn-id: svn://svn.openwrt.org/openwrt/packages@28030 3c298f89-4303-0410-b956-a3cf2f4a3e73<br/>
<br/>
</code>
<br/><br/>

In other news, both the perl and C versions of fwknop are also available in the
<a href="http://www.pentoo.ch/"><img src="/images/pentoo-logo.png" align="left" height="100" width="100">Pentoo</img></a> Linux
distribution thanks to <a href="https://www.pentoo.ch/pentoo/search?q=fwknop">ozmart and the Pentoo maintainers</a>.
Pentoo is a live-cd distribution that is focused on security and derived from
<a href="http://www.gentoo.org">Gentoo</a>.  ozmart wrote a description of the
use case for fwknop on Pentoo from a pentration testing perspective:
<br/><br/>
<i>
"...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.
<br/><br/>
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..."
</i>

]]></description>
</item>

<!-- end_stories -->

</channel>
</rss>
