cipherdyne.org

25 Jul, 2010

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

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

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

There will be a few release candidates of fwknop-2.0.0 to ensure proper operation on a variety of platforms, and the emphasis will be on stability and ironing out any bugs. Also, fwknop-2.0.0 will initially support iptables firewalls on the servers side, with ipfw support coming soon after. There is one nice feature in fwknop-2.0.0rc1 that deserves a mention - the fwknop client now supports the notion of a ~/.fwknoprc file that allows a set of stanzas to be defined for remote SPA servers and customize the command line arguments used to access each one. Here is an example stanza: # Example for a destination server of 192.168.1.20 to open access to
# SSH for an IP that is resolved externally
#
[myssh]
SPA_SERVER 192.168.1.20
ACCESS tcp/22
ALLOW_IP resolve
SPA_SERVER_PORT 50023
Now, with the fwknop client, we reference this stanza with the -n command line argument like so: $ fwknop -n myssh -vvv
Resolved external IP (via http://www.cipherdyne.org/cgi-bin/myip) as: 123.1.2.3
Enter encryption password:

FKO Field Values:
=================

Random Value: 8308719569638051
Username: mbr
Timestamp: 1280030806
FKO Version: 1.9.12
Message Type: 1
Message String: 123.1.2.3,tcp/22
Nat Access: <NULL>
Server Auth: <NULL>
Client Timeout: 0
Digest Type: 3

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

SPA Data Digest: WcUEVesZDIY+CKRKYTck8zMW7HG0S7RcqmXVIMC4L58

Final Packed/Encrypted/Encoded Data:

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

Generating SPA packet:
protocol: udp
port: 50023
send_spa_packet: bytes sent: 182 On the fwknopd server side, we see the following printed to the terminal in --foreground mode as the SPA packet is received and an iptables ACCEPT rule is added for SSH access and then removed after 30 seconds. Using Digest Cache: '/usr/var/run/fwknop/digest.cache' (entry count = 93)
PCAP filter is: udp port 50023
Starting fwknopd main event loop.


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

SPA Decode (res=0):
SPA Field Values:
=================
Random Value: 8308719569638051
Username: mbr
Timestamp: 1280030806
FKO Version: 1.9.12
Message Type: 1
Message String: 123.1.2.3,tcp/22
Nat Access: <NULL>
Server Auth: <NULL>
Client Timeout: 0
Digest Type: 3
Encoded Data: 8308719569638051:bWJy:1280030806:1.9.12:1:OTYuMjQ0LjE3MS4yNTMsdGNwLzIy
SPA Data Digest: WcUEVesZDIY+CKRKYTck8zMW7HG0S7RcqmXVIMC4L58

Added Rule to FWKNOP_INPUT for 123.1.2.3, tcp/22 expires at 1280030886
RES=0, CMD_BUF: /sbin/iptables -t filter -L FWKNOP_INPUT --line-numbers -n 2>&1
RULES LIST: Chain FWKNOP_INPUT (1 references)
num target prot opt source destination
1 ACCEPT tcp -- 123.1.2.3 0.0.0.0/0 tcp dpt:22 /* _exp_1280030886 */

Removed rule 1 from FWKNOP_INPUT with expire time of 1280030886.


14 July, 2010

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

• (Dan A. Dickey) Added the ability to use the "ip" command from the iproute2 tools to acquire IP addresses from local interfaces. Dan's description is as follows: "...A main reason for doing this is in the case of multi-homed hosts. ifconfig sets these up on an interface using aliases, iproute2 does not. So, for a multi-homed interface (eth0 with multiple addresses), ifconfig -a only shows the first one configured and not the rest. ip addr shows all of the configured addresses...".
• Added ENABLE_WHOIS_FORCE_ASCII to replace any non-ascii characters in whois data (which is common with whois lookups against Chinese IP addresses for example) with the string "NA". This option is disabled by default, but can be useful if errors like the following are seen upon receiving an email alert from psad:
  
  <<< 554 5.6.1 Eight bit data not allowed
  554 5.0.0 Service unavailable
  
  
• Updated psad to issue whois lookups against IP addresses that are not directly connected to the local system. This is useful for example when an internal system is scanning an external destination system, and the scan is logged in the FORWARD chain. Issuing whois lookups on the internal system (frequently on RFC 1918 address space) is not usually very useful, but issuing the whois lookup against the destination system gives much more interesting data. This feature can be disabled with the new ENABLE_WHOIS_FORCE_SRC_IP variable.

07 Jan, 2010

The 1.1 release of fwsnort is ready for download. This is a significant release that adds support for ip6tables so that SNORT ® inspection logic can be applied to IPv6 traffic within the Linux kernel. This release also includes a new feature that allows fwsnort to build perl commands interfaced with netcat that generate packet data that matches Snort rules (for those that that can be faithfully translated - see the --include-perl-triggers command line argument and associated comments within the fwsnort.sh file).

Here is the complete fwsnort-1.1 ChangeLog:

• Added the ability to build an fwsnort policy that utilizes ip6tables instead of iptables. This allows fwsnort filtering and altering capabilities to apply to IPv6 traffic instead of just IPv4 traffic. To enable ip6tables usage, use the "-6" or "--ip6tables" command line arguments.
• Added the --include-perl-triggers command line argument so that translated Snort rules can easily be tested. This argument instructs fwsnort to include 'perl -e print ... ' commands as comments in the /etc/fwsnort/fwsnort.sh script, and these commands can be combined with netcat to send payloads across the wire that match Snort rules.
• Updated fwsnort to create logs in the /var/log/fwsnort/ directory instead of directly in the /var/log/ directory. The path is controlled by a new variable 'LOG_FILE' in the /etc/fwsnort/fwsnort.conf file.
• Added several variables in /etc/fwsnort/fwsnort.conf to control paths to everything from the config file to the snort rules path. Coupled with this is the ability to create variables within path components and fwsnort will expand them (e.g. 'CONF_DIR /etc/fwsnort; CONF_FILE $CONF_DIR/fwsnort.conf').
• Added --Last-cmd arg so that it is easy to rebuild the fwsnort.sh script with the same command line args as the previous execution.

Snort is a registered trademark of Sourcefire, Inc.

05 January, 2010

Russ McRee of holisticinfosec.org has written the January Toolsmith issue from the ISSA Journal about fwknop and the ability to create ghost services with Single Packet Authorization. In his Toolsmith paper, Russ emphasizes the possibility of using the ghost services concept to bypass strict outbound network filtering rules on a local network in order to access an external service that is bound to a port that is filtered by the local firewall. That is, the service is made accessible by having the SPA packet created by the fwknop client request that the remote fwknopd server create iptables DNAT rules to forward connections to a port that the local network actually allows out to the port where the service is bound. Russ uses this concept to access a file that is piped through a netcat listener on TCP port 6543, but do it from the heavily filtered network over TCP port 110 (normally associated with pop3).

Here is a link to the Toolsmith PDF entitled "Single Packet Authorization: The Ghost in the Machine".

29 Nov, 2009

Most usages of Single Packet Authorization focus on gaining access to a service such as sshd that is behind a default-drop packet filter. The point being that anyone who is scanning for the service cannot even tell that it is listening - let alone target it with an exploit or an attempt to brute force a password. This is fine, but given that firewalls such as iptables offer well designed NAT capabilities, can a more interesting access model be developed for SPA? How about accessing sshd through a port where another service (such as Apache on port 80) is already bound? Because iptables operates on packets within kernel space, NAT functions apply before there is any conflict with a user space application such as Apache. This makes it possible to create "ghost" services where a port switches for a short period of time to whatever service is requested within an SPA packet (e.g. sshd), but everyone else always just sees the service that is normally bound there (e.g. Apache on port 80).

To illustrate this concept, let's use fwknop from the spaclient system below to access sshd on the spaserver system, but request the access be granted through port 80. Further, on the spaserver system, let's verify that Apache is running and from the perspective of any scanner out on the Internet this is the only service that is accessible. That is, sshd and all other services are firewalled off by iptables. We'll assume that the spaclient system has IP 1.1.1.1, the spaserver system has IP 2.2.2.2, and the scanner system has IP 3.3.3.3.

First, let's scan the spaserver system from the scanner system and verify that only port 80 is accessible: [scanner]# nmap -P0 -n -sV 2.2.2.2

Starting Nmap 5.00 ( http://nmap.org ) at 2009-11-29 15:14 EST
Interesting ports on 2.2.2.2:
Not shown: 999 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.8 ((Ubuntu) mod_python/3.3.1 Python/2.5.2)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 90.94 seconds Good. Now, from the spaclient system, let's fire up fwknop and request access to sshd on the spaserver system. But instead of just gaining access to port 22, we'll request access to port 22 via port 80 - the fwknopd daemon will build the appropriate DNAT iptables rules to make this work: [spaclient]$ fwknop -A tcp/22 --NAT-access 2.2.2.2:80 --NAT-local -a 1.1.1.1 -D 2.2.2.2

[+] Starting fwknop client (SPA mode)...
[+] 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: 3829970026924871
Username: mbr
Timestamp: 1259526613
Version: 1.9.12
Type: 5 (Local NAT access mode)
Access: 0.0.0.0,tcp/22
NAT access: 2.2.2.2,80
SHA256 digest: Om/GsIVQIRyAp6UWyqjXVqlEQhxz+lVsQhCl1rFBfuI

[+] Sending 182 byte message to 2.2.2.2 over udp/62201...
Requesting NAT access to tcp/22 on 2.2.2.2 via port 80
With the receipt of the SPA packet, the fwknopd daemon has reconfigured iptables to allow an ssh connection through port 80 from the spaclient IP 1.1.1.1 (note the "-p 80" argument on the ssh command line): [spaclient]$ ssh -p 80 -l mbr 2.2.2.2
mbr@2.2.2.2's password:
[spaserver]$ If we can the spaserver again from the scanner system, we still only see Apache: [scanner]# nmap -P0 -n -sV 2.2.2.2

Starting Nmap 5.00 ( http://nmap.org ) at 2009-11-29 15:29 EST
Interesting ports on 2.2.2.2:
Not shown: 999 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.8 ((Ubuntu) mod_python/3.3.1 Python/2.5.2)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 89.22 seconds So, the IP 1.1.1.1 has access to sshd, but all the scanner can ever see is 'Apache httpd 2.2.8'.

A legitimate question at this point is 'why is this useful?'. Well, I have been on networks before where local access controls only allowed outbound DNS, HTTP and HTTPS traffic, so this technique allows ssh connections to be made in a manner that is consistent with these access controls. (This assumes that HTTP connections are not made through a proxy, and that the fwknopd daemon is configured to sniff SPA packets over port 53.) Further, to anyone who is able to sniff traffic, it can be hard to figure out what is really going on in terms of SPA packets and associated follow-on connections. This is especially true when other tricks such as port randomization are also applied.

I demonstrated the service ghosting technique at DojoCon a few weeks ago, and the video of this is available here (towards the end of the video).

24 Nov, 2009

At the upcoming SANS Incident Detection Summit on December 9th and 10th I will be participating in two panel discussions. The first is entitled "Enterprise Network Detection Tools and Tactics" and is described by Richard Bejtlich (who has organized the whole conference) as a venue where "speakers with large-scale experience will share their tools and tactics for identifying suspicious and malicious activity". The second, "Detection Using Logs", focuses on the usage of platform, operating system, and application logs to detect intrusions, and Security Information Management and log aggregation and search systems will be discussed.

If you are going to be at the conference, please say hello!

10 Sep, 2009

UDPATE: The talk slides can be downloaded here and a video of the talk is available too.

On Friday November 6th I will be giving a talk on Single Packet Authorization with fwknop at the upcoming DojoCon conference at Capitol College in Laurel, MD. This talk will focus on some recent developments in the world of fwknop development and the resulting enhancements to SPA capabilities. Topics to be emphasized include:

• The new libfko C implementation and what it means for SPA deployments.
• Interface monitoring for administrative control changes and increasing packet counts. This adds an extra dimension of reliability for fwknopd server operations.
• HTTP proxy support, as well as the development of an SSL web gateway for sending SPA packets on behalf of client systems that cannot construct SPA packets themselves.
• Development efforts for future fwknop features (such as additional client integration, and deployments on embedded Linux distributions).