cipherdyne.org

Michael Rash, Security Researcher



Software Releases    [Summary View]

« Previous | Next »

Software Release - fwknop-1.9.6

software release fwknop-1.9.6 The 1.9.6 release of fwknop is ready for download. This release was made at The Last HOPE conference over the weekend in NYC, and introduces several new features that make SPA traffic more difficult to detect on a network even when an IDS is watching. Previous to the 1.9.6 version of fwknop, it was possible to write Snort rules to detect SPA traffic by looking for invariant artifacts from base-64 encoding and also from encryption operations (both Rijndael and GnuPG). These artifacts are now stripped out by the fwknop client before being transmitted on the wire, and the result is that SPA packets are now more highly randomized. This implies that SPA packets generated by the 1.9.6 release are not compatible with older fwknop deployments by default, but the client does offer command line arguments to maintain compatibility if necessary.

Here is an excerpt from the ChangeLog:

  • SPA packets are base64-encoded by the fwknop client, and this encoding pads data with '=' chars until the total length of the encoded data is a multiple of four. This characteristic can be used within a Snort rule to assist in the detection of SPA communications. The 1.9.6 release of fwknop strips out these padding characters before the client sends an SPA packet, and the fwknopd server adds them back in (to form a multiple of four) before base64 decoding the packet data. This reduces the level of identifying information in SPA packets and therefore makes it more difficult to detect the usage of SPA for service access. For reference, a Snort rule that would detect SPA packets via the trailing '=' chars (previous to this release) would be:

    alert udp any any -> any 62201 (msg:"fwknop SPA traffic"; dsize:>150; pcre:"/==$/"; sid:20080001; rev:1;)

  • According to the 'file' command (via it's 'magic') database, files that are encrypted with GnuPG begin with 0x8502, and this is true for SPA packets generated by fwknop (previous to this release). In fwknop-1.9.6, the "hQ" prefix is removed by the fwknop client and added back in by the fwknopd server if it doesn't exist. This measure is another effort to make SPA packets more difficult to detect on the wire, such as with the following Snort rule:

    alert udp any any -> any 62201 (msg:"fwknop GnuPG encrypted SPA traffic"; content:"hQ"; depth:2; dsize:>1000; sid:20080003; rev:1;)

  • Updated the fwknop client to randomize the UDP source port for default SPA packet generation. There is also a new command line argument --Source-port <port> to allow the user to manually set the source port on the fwknop client command line. A lot more attention is given now to source ports after the Dan Kaminsky DNS caching exploit, and it turns out that even on Linux that the kernel did not randomize UDP source ports until the 2.6.24 kernel. Of course, any userspace process is free to request a random port itself, but if a userspace application did not build this in then it would be up to the kernel to assign a source port. In the case of Linux, here are two links that show the change to the kernel code as well as the ChangeLog entry for UDP source port randomization:

    Kernel commit

    ChangeLog-2.6.24

Software Release - gootrude-0.2

Gootrude queries Yahoo Gootrude-0.2 is available for download. This release changes the default search engine from Google to Yahoo because it appears that Yahoo's Terms of Service do not prohibit automated queries (although I'm not a lawyer). Gootrude retains the ability to query Google at your own risk if you so desire. As long as you use Gootrude as designed to collect search engine results only once per day with a limited number of search terms (say, 20 or less), it is unlikely to provoke a negative reaction from search engines. Over time, support for many additional search engines will be added to Gootrude so that search results can be trended from all sorts of different data sources.

Also, this post should really have announced Gootrude as a "search results trender" instead of a "search trender". The goal of the project is made clear in the README, and here is the complete ChangeLog, for the Gootrude-0.2 release:

  • Added support for querying Yahoo for search results and made this the default because Google's TOS does not technially allow automated queries. However, Gootrude continues to support querying Google for search results, and responsible use of Gootrude once per day with a limited set of search terms should most likely not be a cause for concern for Google. A new syntax of the searchterms.conf file allows search terms to express which search engine should be queried on an individual basis according to the following syntax (note the middle element): [Linux "highspeed firewalls"] [yahoo:count] [Linux_highspeed_firewalls.dat]
  • Changed the default USER_AGENT variable to "Gootrude <version>".
  • Added a percentage-based offset for the plot minimum and maximum ranges on the y-axis (with a default of 10% controlled by two new variables MIN_PERCENT_DIFF and MAX_PERCENT_DIFF). This value can also be set by the search terms themselves via an additional config element as follows (for a 20% offset instead for example): [yrange:20%/20%]
  • Increased SEARCH_TERM_DELAY to two seconds to be nicer to search engines.

Three software releases - psad, fwknop, gpgdir

Three software releases The following releases of the Cipherdyne security projects are now available: psad-2.1.3, fwknop-1.9.5, and gpgdir-1.9.1. The motivation for a group release stems from the need to make similar changes to the fwknop and gpgdir projects to update to version 2.11 of the Class::MethodMaker perl module from CPAN - a dependency of GnuPG::Interface. This version fixes a build error under recent versions of perl (such as perl-5.10.0) which are distributed on systems like Fedora 9. Also, for both fwknop and gpgdir, thanks to a suggestion made by Jean-Denis Girard on the fwknop mailing list, the default locale has been set to "C" via the LC_ALL environmental variable so that GnuPG output can be properly interpreted even on systems where a different locale is used. The locale can be manually set or not used at all with two new command line arguments --locale <str> and --no-locale respectively. On another note, Kevin Hilton has written an excellent how-to for fwknop on Ubuntu systems.

For psad, it was time to make a new release after it became necessary to update the whois client so that IP addresses such as 116.125.35.98 (which was scanning a psad user) could be properly identified with whois records. In addition, psad was updated to parse syslog files directly for iptables log messages instead of requiring reconfiguration of the syslog daemon to write kern.info messages to the /var/lib/psad/psadfifo named pipe. This simplifies the proper installation of psad, and is now a default setting. Although there is a slight performance penalty since psad now parses all messages that are written to the /var/log/messages file (this is the default path), it should not be noticeable on most systems. Further, the old behavior of using the named pipe can be restored via the ENABLE_SYSLOG_FILE variable in the /etc/psad/psad.conf file.

Finally, Franck Joncourt has made excellent progress in developing Debian packages for the IPTables::ChainMgr and IPTables::Parse modules, and he is also close to a Debian package for the fwknop project.

The complete change logs for these new releases can be found as follows: psad-2.1.3, fwknop-1.9.5, and gpgdir-1.9.1

Single Packet Authorization with Port Randomization

Single Packet Authorization with Port Randomization After two months of development, the 1.9.4 release of fwknop is available for download. This release introduces new functionality that has implications for hardening both fwknop SPA communications and the follow-on connections that client programs make (such as SSH). Specifically, the 1.9.4 release adds two port randomization options to 1) send the SPA packet over a random port between 10,000 and 65,535 (requires updating the default PCAP_FILTER variable on the fwknopd server side), and 2) select a random port that is used as the destination port in a NAT operation on the fwknopd server system. These two options can be used individually or together, and are enabled with two new command line options, --rand-port and --NAT-rand-port respectively, to the fwknop client (see examples below).

The inspiration for adding this functionality came from a post to the "Documentation, Tips & Tricks". Gentoo forum, and I have credited John Brendler with the idea. In response to John's post, I would like to mention however that all Port Knocking / Single Packet Authorization implementations suffer from "piggy-back exploits", including those that select random ports for SPA communications or for NAT operations against follow-on sessions. A "piggy-back exploit" is where an attacker takes advantage of the fact that a firewall rule inserted by a PK/SPA system accepts a connection from an IP address to a destination port specified by the SPA packet(s). So, if the attacker can spoof packets from this source IP, or if the attacker happens to be on the same internal network as the SPA client (and hence sends connections out through the same NAT device), then the firewall rule will accept these packets just as though they originated from the legitimate SPA client system. If an attacker is in a privileged position and can sniff the legitimate session as it is initiated, then one can envision an automated attack that spoofs packets from the same source IP and directs them at the same service. Further, such an "attack" can be made just by watching outgoing connections without paying any attention whatsoever to whether or not a set of SPA packets are sent first - it doesn't matter if the real connection is made to a random translated port on the SPA system; the attacker can see this port in the real connection itself.

Now, should you be concerned about such a piggy-back attack? Not really. First, if the attacker is not going through the same NAT device as the real connection, then any response to a spoofed packet will go back to the spoofed source - not back to the attacker. So, for TCP connections, unless the attacker can effectively perform a sequence prediction attack an existing connection (and even then that is of little use against an encrypted application layer protocol such as SSH), this is not very effective. Second, even if an attacker is behind the same NAT device as the SPA client, just being able to access the targeted service over TCP/IP does not imply an automatic vulnerability; SPA is an additive measure to whatever existing security mechanisms are already in place (barring a vulnerability in libpcap itself in the SPA server for example). Third, there are an awful lot of networks out there to which an attacker will not have such privileged access, and therefore not be in a position able to sniff anything useful. Forth, fwknop minimizes the opportunity for an attacker to conduct a piggy-back attack by maintaining a small window of time (30 seconds by default) for any new firewall rules after receiving a valid SPA packet. By using a connection tracking mechanism built into iptables or ipfw, any connection established during the accept window is allowed to remain open but all attempts to create a new connection must first preceeded with a new SPA packet in order to gain access.

Finally, although port randomization is an enhancement, fwknop has had the ability for a long time to allow the user to select the destination port for SPA packets with the --Server-port argument as well as the destination port for a NAT'd connection to an internal system. Hence, fwknop SPA packets are not always sent over udp/62201. But, I agree that it is useful to add the port randomization features that John Brendler suggested, and this is why I've implemented them in fwknop. Randomizing the SPA destination port along with the destination port of the follow-on connection makes traffic analysis more difficult.

Now, let us see the new --rand-port and --NAT-rand-port options in a practical example. We'll assume that the fwknopd server is at hostname spaserver with IP 11.1.1.1, and the fwknop client runs on the spaclient system with IP 12.2.2.2. We ultimately want to gain access to SSHD on the spaserver system, and we assume that iptables is configured in a default-drop stance for all attempts to communicate with SSHD. Also, there is no requirement to necessarily attempt to gain access only to an SSHD instance running on an internal server via a forwarded port - the iptables PREROUTING chain can forward a port to a local socket as well (based on a routing calculation for the destination IP), and on the fwknop client command line we use the --NAT-local argument for this.

Because the --rand-port option sends the SPA packet over a random destination port, we first need to set the PCAP_FILTER variable as follows in the /etc/fwknop/fwknop.conf file: [spaserver]# vi /etc/fwknop/fwknop.conf
PCAP_FILTER udp dst portrange 10000-65535;

[spaserver]# /etc/init.d/fwknop restart
[+] knopwatchd is running (pid: 17584), stopping daemon
[+] knoptm is running (pid: 17582), stopping daemon
[+] fwknopd is running (pid: 17580), stopping daemon
Starting the fwknop daemons.
With the fwknopd server up and running, we now use the fwknop client to gain access to SSHD on the spaserver system via a randomly selected NAT'd port (and we show that SSHD is never accessible over the standard TCP port 22 even from the spaclient system):
[spaclient]$ nmap -sT -n -P0 -p 22 11.1.1.1

Starting Nmap 4.20 ( http://insecure.org ) at 2008-06-02 01:48 EDT
Interesting ports on 11.1.1.1:
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap finished: 1 IP address (1 host up) scanned in 12.017 seconds

[spaclient]$  fwknop -A tcp/22 --NAT-local --NAT-rand-port \
--rand-port -R -D 11.1.1.1

[+] Starting fwknop client (SPA mode)...
[+] Requesting NAT access for randomized port: 16791
    Resolving external IP via: http://www.whatismyip.org/
    Got external address: 12.2.2.2

[+] Enter an encryption key. This key must match a key in the file
    /etc/fwknop/access.conf on the remote system.

Encryption Key:

[+] Building encrypted Single Packet Authorization (SPA) message...
[+] Packet fields:

        Random data:    4846125760033285
        Username:       mbr
        Timestamp:      1212386108
        Version:        1.9.4
        Type:           5 (Local NAT access mode)
        Access:         12.2.2.2,tcp/22
        NAT access:     11.1.1.1,16791
        SHA256 digest:  ZyWG+nRGYMfWFssJuOy7bhGmJHpHia6T1igaNnVVhqI

[+] Sending 206 byte message to 11.1.1.1 over udp/52949...
    Requesting NAT access to tcp/22 on 11.1.1.1 via port 16791

[spaclient]$  ssh -p 16791 mbr@11.1.1.1
mbr@11.1.1.1's password:
[spaserver]$
The above output shows that the client system indeed has access to the spaserver system via TCP port 16791, which is forwarded to the local SSH daemon. In the /var/log/messages file, fwknopd has written the following messages to syslog: [spaserver]# tail /var/log/messages
Jun 2 01:54:16 spaserver fwknopd: received valid Rijndael encrypted packet from: 12.2.2.2, remote user: mbr, client version: 1.9.4 (SOURCE line num: 151)
Jun 2 01:54:17 spaserver fwknopd: add FWKNOP_PREROUTING 12.2.2.2 -> 11.1.1.1(tcp/16791 to 22) DNAT rule 30 sec
Jun 2 01:54:17 spaserver fwknopd: add FWKNOP_INPUT 12.2.2.2 -> 0.0.0.0/0(tcp/22) ACCEPT rule 30 sec
Jun 2 01:54:58 spaserver fwknop(knoptm): removed iptables FWKNOP_PREROUTING DNAT rule for 12.2.2.2 -> 11.1.1.1(tcp/22), 30 sec timeout exceeded
Jun 2 01:55:11 spaserver fwknop(knoptm): removed iptables FWKNOP_INPUT ACCEPT rule for 12.2.2.2 -> 0.0.0.0/0(tcp/22), 30 sec timeout exceeded
In closing, here is an abbreviated version (the randomization options are not duplicated here) of the fwknop-1.9.4 ChangeLog:

  • Added the ability to specify the port that SPA packets are sent over with the fwknop client by using the syntax "<host|IP>:<port>". So, for example, to have the client send an SPA packet to 11.1.1.1 over UDP port 12345 (instead of the default of 62201), one could use the following command:

    $ fwknop -A tcp/22 -R -D 11.1.1.1:12345

  • Bugfix to add a check for "keep-state" in ipfw policies in addition to the existing "check-state" check (noticed by Sebastien Jeanquier).
  • Updated the install.pl script to try to determine the OS type as early as possible during the install process.
  • Added the MIN_SPA_PKT_LEN variable with 160 (bytes) as the default. This allows fwknopd to ignore packets that are not at least this many bytes (including packet headers) before any decryption attempt is made.
  • Added --time-offset-plus and --time-offset-minus args to the fwknop client command line. This allows the time stamp within an SPA packet to be influenced without setting the system clock (which normal users cannot usually do). This is useful for when the client and server systems have clocks that are out of sync.
  • Bugfix on Ubuntu systems to make sure that the fwknop init script is installed with a priority of 99 instead of 20 - this puts fwknop as late as possible within the boot sequence so that the system is ready to run fwknop.
  • Bugfix to not open ports that are not specifically requested in an SPA packet even if those ports are listed in the OPEN_PORTS variable in the access.conf file.
  • Updated to version 5.47 of the Digest::SHA module.
  • Updated to version 0.7 of the IPTables::ChainMgr module (includes perldoc documentation).
  • Updated to version 0.6 of the IPTables::Parse module (includes perldoc documentation).
  • Added NAT, port randomization, and and time offset option discussions to fwknop(8) man page.

Software Release - gpgdir-1.9

gpgdir-1.9 released The 1.9 release of gpgdir is ready for download. This release introduces minor fixes to change the --Obfuscate file format and adds process locking against multiple instances of gpgdir from operating against the same directory.

On a side note, Ben Martin wrote an article on gpgdir entitled "Protecting directory trees with gpgdir" for linux.com. Ben emphasizes using the gpgdir --Wipe option to securely delete files from the filesystem after they are encrypted with GnuPG, and I agree with this. In addition, there is nothing that prevents gpgdir from being used in conjunction with an encrypted filesystem such as Cryptmount to achieve additional protections for directory structures (which gpgdir does not alter).

Here is the complete ChangeLog: for the 1.9 release:
  • Changed --Obfuscate-filenames format to not include the gpgdir PID. This allows directories to be encrypted/decrypted under -O multiple times without creating new filenames (which would pollute encrypted directories under rsync to other systems). The new -O encrypted filename format is just "gpgdir_<num>.gpg".
  • Added PID locking against directories so that multiple gpgdir processes cannot operate against the same top-level directory simultaneously. This is useful for users that typically operate with multiple shells and might launch gpgdir from any of them.

fwknop Windows UI Update

Sean Greven has released the next version of his fwknop UI for Windows systems. This release is compatible with all fwknop daemons that are configured to accept SPA packets that have been encrypted with the Rijndael symmetric cipher. The executable can be downloaded here, and the source code is also available here. Finally, here is a screenshot to illustrate generating an SPA packet from Windows 2000 running under VMware on an Ubuntu 7.10 system. The fwknopd daemon is running in --debug mode in the terminal on the right, and you can see the addition of an iptables ACCEPT rule to allow access to SSHD:

fwknop Window UI update

Port Forwarding via Single Packet Authorization

Digg How to Safely Connect to Your Closed Internal Systems via SPA and NAT Port Forwarding via Single Packet Authorization Most port knocking or Single Packet Authorization implementations offer the ability to passively authenticate clients for access only to a locally running server (such as SSHD). That is, the daemon that monitors a firewall log or that sniffs the wire for port knock sequences or SPA packets can only reconfigure a local firewall to allow the client to access a local socket. This is usually accomplished by allowing the client to connect to the server port by putting an ACCEPT rule in the INPUT chain for iptables firewalls, or adding a pass rule for ipfw firewalls for the client source IP address. For local servers, this works well enough, but suppose that you ultimately want to access an SSH daemon that is running on an internal system? If the SPA software is deployed on a Linux gateway that is protecting a non-routable internal network and has a routable external IP address, it is inconvenient to first have to login to the gateway and then login to the internal system.
       Since the 1.9.2 release, fwknop has supported the creation of inbound port forwarding rules for iptables firewalls via the DNAT target in the PREROUTING chain after receiving a valid SPA packet. This allows direct access to internal systems on non-routable address space from the open Internet. Here is an example - suppose that you are running fwknop on Linux gateway system that is protecting an internal network 192.168.10.0/24 and has an external routable address of 11.1.1.1. Now, suppose that you are on travel somewhere (so your source IP address is not predictable), and you would like to access an SSH server that is running on the internal system 192.168.10.23. Finally, because fwknop is deployed, iptables is configured in a default-DROP stance against all attempts to connect with any SSH daemon; nmap cannot even tell that there is any SSH server listening. Access is granted only after a valid SPA packet is passively sniffed by the fwknopd daemon.

With inbound NAT support configured in fwknop (the config is mentioned below), here is an illustration of fwknop usage in order to gain direct access to SSHD on the 192.168.10.23 from an external network (note that the -R argument instructs the fwknop client to automatically resolve the current IP address - 12.2.2.2 in this case):
[externalhost]$ fwknop -A tcp/22 --Forward-access 192.168.10.23,5001 \
-R -D 11.1.1.1

[+] Starting fwknop client (SPA mode)...
    Resolving external IP via: http://www.whatismyip.org/
    Got external address: 12.2.2.2

[+] Enter an encryption key. This key must match a key in the file
    /etc/fwknop/access.conf on the remote system.

Encryption Key:

[+] Building encrypted Single Packet Authorization (SPA) message...
[+] Packet fields:

        Random data:    6862733471944039
        Username:       root
        Timestamp:      1207404612
        Version:        1.9.3
        Type:           2 (FORWARD access mode)
        Access:         12.2.2.2,tcp/22
        Forward access: 192.168.10.23,5001
        SHA256 digest:  hE4zGafLtQiQiFrep+cSq/wVO7SQhwh65hmLr+ehtrw

[+] Sending 206 byte message to 11.1.1.1 over udp/62201...
Now, port 5001 on the external IP address is forwarded through to the SSH server on the internal 192.168.10.23 system, but only for the client IP 12.2.2.2: [externalhost]$ ssh -p 5001 mbr@11.1.1.1
Password:
[internalhost]$
Graphically, this scenario is illustrated by the following picture. The dotted lines represent the SPA packet from the fwknop client (which only needs to be sniffed by the fwknopd daemon running on the Linux gateway), and the solid arrows represent the SSH connection from the external client through to the internal SSH server.

DNAT SPA access to internal SPA server
On the Linux gateway system that is running the fwknop daemon, executing the following command illustrates the additions to the iptables policy to allow the SSH connection to be forwarded to the internal system. These firewall rules are automatically deleted after a 30 second timeout (this is tunable), but any existing SSH connection remains open through the use of the iptables connection tracking capability.
[gateway]# fwknopd --fw-list
[+] Listing rules in fwknop chains...
Chain FWKNOP_INPUT (1 references)
 pkts bytes target prot opt in out source   destination

Chain FWKNOP_FORWARD (1 references)
 pkts bytes target prot opt in out source     destination
   19  2740 ACCEPT tcp  --  *  *   12.2.2.2   0.0.0.0/0    tcp dpt:22

Chain FWKNOP_PREROUTING (1 references)
 pkts bytes target prot opt in out source     destination
    1    60 DNAT   tcp  --  *  *   12.2.2.2   0.0.0.0/0    tcp \
dpt:5001 to:192.168.10.23:22
Finally, the /etc/fwknop/access.conf is configured like so to facilitate this example, and the ENABLE_IPT_FORWARDING variable is also enabled in the /etc/fwknop/fwknop.conf file: SOURCE: ANY;
OPEN_PORTS: tcp/22;
PERMIT_CLIENT_PORTS: N;
ENABLE_FORWARD_ACCESS: Y;
FW_ACCESS_TIMEOUT: 30;
KEY: aesdemokey;
In addition to explaining the inbound NAT support offered by fwknop, this blog post also announces the 1.9.3 release of fwknop. Here is the complete ChangeLog:
  • Added MASQUERADE and SNAT support to complement inbound DNAT connections for SPA packets that request --Forward-access to internal systems. This functionality is only enabled when both ENABLE_IPT_FORWARDING and ENABLE_IPT_SNAT are set, and is configured by two new variables IPT_MASQUERADE_ACCESS and IPT_SNAT_ACCESS which define the iptables interface to creating SNAT rules. The SNAT supplements of DNAT rules are not usually necessary because internal systems usually have a route back out to the Internet, but this feature accommodates those systems that do not have such a route. By default, the MASQUERADE target is used if ENABLE_IPT_SNAT is enabled because this means that the external IP does not have to be manually defined. However, the external IP can be defined by the SNAT_TRANSLATE_IP variable.
  • Added hex_dump() feature for fwknop client so that raw encrypted SPA packet data can be displayed in --verbose mode.
  • When ENABLE_IPT_FORWARDING is set, added a check for the value of the /proc/sys/net/ipv4/ip_forward file to ensure that the local system allows packets to be forwarded. Unless ENABLE_PROC_IP_FORWARD is disabled, then fwknopd will automatically set the ip_forward file to "1" if it is set to "0" (again, only if ENABLE_IPT_FORWARDING is enabled).
  • Minor bugfix to remove sys_log() call in legacy port knocking mode.
  • Minor bugfix to expand both the Id and Revision tags via the svn:keywords directive.

Software Release - gpgdir-1.8

Software Release - gpgdir-1.8 The 1.8 release of gpgdir is ready for download. This is a minor feature enhancement release, and here is the Here is the complete ChangeLog:
  • Updated the test suite to validate the gpgdir --Obfuscate-filenames mode to ensure that files are encrypted as "gpgdir_<pid>_<num>.gpg".
  • Minor bug fix to remove the .gpgdir_map_file in --Obfuscate-filenames mode after a successful decryption cycle.
  • Updated to version 0.36 of CPAN GnuPG::Interface module.

Software Release - psad-2.1.2

Software Release - psad-2.1.2 The 2.1.2 release of psad is ready for download. This is a minor bugfix release to improve support for Linux distributions that report a timestamp in syslog messages just before any iptables log prefix. Here is an example of such syslog messages reported in "psad --Status output (sent to the psad mailing list by Erik Heidt):
[+] iptables log prefix counters:
      "[ 5370.901768] Default_Drop________": 1
      "[ 9411.899552] Default_Drop________": 1
      "[ 7560.529042] Default_Drop________": 1
      "[ 6454.263813] Default_Drop________": 1
      "[ 7038.635371] Default_Drop________": 1
      "[ 5648.026038] Default_Drop________": 1
      "[ 1207.663709] Default_Drop________": 1
      "[  394.423573] Default_Drop________": 1
      "[  186.740237] Default_Drop________": 1
      "[ 9405.138521] Default_Drop________": 1
      "[ 5364.208693] Default_Drop________": 1
      "[ 7297.121141] Default_Drop________": 1
The bug caused the timestamp portion of the syslog messages to be included within the iptables log prefix strings, and because timestamps are nearly unique, this forced even the same iptables log prefix to also be treated as unique.
Here is the complete ChangeLog:
  • Bugfix to not include kernel timestamps in iptables log prefixes that contain spaces like "[ 65.026008] DROP" (bug reported by Erik Heidt).
  • Bugfix to skip non-resolved IP addresses (bug reported by Albert Whale)
  • Better p0f output in --debug mode to display when a passive OS fingerprint cannot be calculated based on iptables log messages that include tcp options (i.e., with --log-tcp-options when building a LOG rule on the iptables command line).

fwknop-1.9.2 Release at SOURCE Boston

fwknop-1.9.2 Release at SOURCE Boston Today at the SOURCE Boston computer security conference I will give a talk entitled "Advanced Linux Firewalls" in which I will present many of the themes I discuss in my book published late last year by No Starch Press. This talk will also launch the 1.9.2 release of fwknop, and present several new features such as client-derived access timeouts, the ability to select any of several digest algorithms (SHA-256, SHA-1, or MD5) for replay attack detection, the removal of the Salted__ prefix in SPA packets encrypted with Rijndael, and blacklist IP exclusions for incoming SPA packets. Many of these features were implemented by the SPAPICT team as well as several other contributors, and I wish to thank all who participated in the fwknop development process.

      You can download fwknop-1.9.2 here, and for those interested in the changes in the fwknop-1.9.2 release, here is the complete ChangeLog:
  • Crypt::CBC adds the string "Salted__" to the beginning of the encrypted text (at least for how fwknop interfaces with Crypt::CBC), so the fwknop client was updated to delete the encoded version of this string "U2FsdGVkX1" before sending a Rijndael-encrypted SPA packet on the wire. The fwknopd server will add this string back in before decrypting. This makes it harder to write an IDS signature that looks for fwknop traffic; e.g. look for the default prefix string "U2FsdGVkX1" over UDP port 62201, which would work for fwknop clients < 1.9.2 (as long as the port number is not changed with --Server-port).
  • Added more granular source IP and allowed IP tests so that access to particular internal IP addresses can be excluded in --Forward-access mode. A new keyword "INTERNAL_NET_ACCESS" is now parsed from the access.conf file in order to implemented these restrictions.
  • (SPAPICT Group) Added BLACKLIST functionality to allow source IP addresses to easily be excluded from the authentication process.
  • (Grant Ferley) Submitted patch to handle SIGCHLD in IPTables::ChainMgr.
  • (Grant Ferley) Submitted patch to handle Linux "cooked" interfaces for packet capture (e.g. PPPoE interfaces).
  • (SPAPICT Group) Applied modified version of the client-defined access timeout patches submitted by the PICT SPA Group. There are two new message types to facilitate client timeouts; one for normal access mode, and the other for the FORWARD access mode. In the access.conf file, there is also a new variable "PERMIT_CLIENT_TIMEOUT" to allow each SOURCE stanza to allow client-defined timeouts or not.
  • (SPAPICT Group) Submitted patches to include support for the SHA1 digest algorithm for SPA packet replay attack detection. I modified these patches for maximum configurability (see the --digest-alg argument on the fwknop command line), and the ability to use the SHA256 algorithm as well. The default path to the /var/log/fwknop/md5sums file has been changed to /var/log/fwknop/digest.cache, and the default digest algorithm is now SHA256 (but this is tunable via the DIGEST_TYPE variable in the fwknop.conf file).
  • Added the Digest::SHA perl module in support of the SHA1 and SHA256 digest algorithms for replay attack detection and SPA message integrity.
  • Added full packet hex dumps (including packet headers) to fwknopd in --debug --verbose mode. This is to help diagnose packet sniffing issues over the loopback interface on Mac OS X (first reported by Sebastien Jeanquier).
  • (Test suite) Bugfix to ensure that the FWKNOP_DIR variable is set to the local output/ directory in several of the test config files in the test/conf/ directory.
  • (Test suite) Added several tests for configurable digest algorithms in support for the SHA256, SHA1, and MD5 digest changes made by the SPAPICT Group.
  • Updated the fwknop client to always call encode_base64() with the string to encode along with a second null-string argument to force all encoded data to not include line breaks.
  • Bugfix in install.pl to not test for the iptable command on non-Linux systems, and to not test for the ipfw command on systems that are Linux.
  • (Test suite) Updated to include the /proc/config.gz file so that the kernel config can be reviewed (not all Netfilter hooks are necessarily compiled in).
« Previous | Next »