From Security Weekly Wiki
Jump to navigationJump to search


Security Weekly - Episode 221 "early Thanksgiving Special" - for Tuesday November 23d, 2010.

Episode Media


Guest Interview: Xavier Mertens

Xavier is a Belgian security professional specializing in monitoring and reporting (data collection, correlation, incidents analysis) and audits. He also has a keen interest in assessments, pen-testing, and DLP.

In his own words:

IT enthusiast (my first computer was a Sinclair ZX-81!) since I'm young. I worked for ISP's during the "golden years" (when Internet emerged). When it became a real business (ISP's were forced to make $$$), I smoothly switched to security which is my job today. Besides my job, I maintain my blog, I'm a BruCON volunteer (network & infrastructure) and try to attend as much conferences as possible (not always easy!) and frustrated by the lack of time to learn... About "security", I don't like products. Security must be based on "solutions".

You can follow Xavier via his blog

  1. How did you get your start in information security?
  2. Tell us about your unholy love for OSSEC
  3. Let's go over some of your recent blog posts on

Tech Segment: Single Packet Authorization by Sebastien "FireSt0rM" Jeanquier

Single Packet Authorization (SPA) is in the family of 'Firewall Authentication' mechanisms which includes the older concept of Port Knocking. Whereas Port Knocking relied on sending large number of SYN packets to transfer information, SPA does it in a single encrypted packet, making it more robust and stealthy.

There are many reasons to use SPA. Two examples are protecting against authentication brute force/dictionary attacks (see my SSH log below), and protecting services against 0day exploits.

Nov 10 21:20:21 sshd[1688]: Invalid user stud from
Nov 10 21:21:25 sshd[1715]: Invalid user guest from
Nov 10 21:21:28 sshd[1717]: Invalid user test from
Nov 10 21:21:33 sshd[1719]: Invalid user oracle from

The first thing we do with SPA is to define our default-drop firewall. The bash script below can be used to do that.

[server]~$ vim set_iptables.sh

$IPTABLES -F -t nat
$IPTABLES -A INPUT -i ! lo -j LOG --log-prefix "DROP "
$IPTABLES -A FORWARD -i ! lo -j LOG --log-prefix "DROP "
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "iptables policy enabled"
[server]~$ sudo sh ./firewall.sh
[server]~$ sudo iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --             state RELATED,ESTABLISHED 
LOG        all  --             LOG flags 0 level 4 prefix `DROP ' 
DROP       all  --             

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --             state RELATED,ESTABLISHED 
LOG        all  --             LOG flags 0 level 4 prefix `DROP ' 
DROP       all  --             

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Note that the firewall policy now default to dropping all packets, except those for established connections.

So now that we have our default-drop firewall, we need an SPA daemon to handle access requests and create firewall rules. There are currently three good implementations of SPA:

All of these are good in different ways, but fwknop currently offers more advanced functionality and firewall support. It is available in Perl, but has also been ported to C, allowing us to run it on embedded platforms such as OpenWRT (which makes it really useful).

A basic fwknop SPA packet has the following format:

Random data:    8410047232910152
Username:       admin
Timestamp:      1290247803
Version:        1.9.12
Type:           1   (access mode)
SHA256 digest:  f8Nr3C9SRRRKNKYdycbzIe+FWm4wgUfG9oeTT/SX+AU

Fwknop has a large number of options that allow you to control the way it behaves. Most of these can be found in: /usr/local/etc/fwknop/fwknopd.conf. The options in this file are described in depth, but some options of interest include:

  • SPA packet age limit can be defined by ENABLE_SPA_PACKET_AGING and MAX_SPA_PACKET_AGE (note that client and server times will need to be fairly synchronized)
  • Replay-protection thanks to checksum (hash) tracking, controlled by ENABLE_DIGEST_PERSISTENCE
  • Access requests to other hosts on the network (apart from the SPA device itself) can be enabled using ENABLE_IPT_FORWARDING

Individual user access privileges are configured in the access.conf file: /usr/local/etc/fwknop/access.conf. Here is a sample access block that allows the user to request access to port 22 for 20 seconds:

SOURCE: ANY; # can specify IP ranges
REQUIRE_USERNAME: admin; # requiring a username is recommended as it makes dictionary/brute force attacks more difficult
KEY: s3Cur#as$w0rd; # strength is important
OPEN_PORTS: tcp/22;
ENABLE_CMD_EXEC: N; # default is N
FW_ACCESS_TIMEOUT: 20; # default is 30 seconds

By default fwknop uses AES to do SPA encryption. GPG can be used instead to provide encryption AND authenticity. Parameters for enabling this can be found in access.conf. Full tutorial here: http://cipherdyne.com/fwknop/docs/gpghowto.html


  • Client:
  • Server:
  • Service: tcp/22 (SSH)
[client]~$ fwknop -D -s -A tcp/22

(-s = allow access to source IP of SPA packet. -A = access request)

This sends a single AES-encrypted access request over UDP (or ICMP/TCP) to the server. The server receives and decrypts the packet, recalculates the hash to verify integrity, compares timestamp to maximum age limit (if enabled), and compares requested access to defined access list. If access request is valid, then a firewall rule is added allowing access to the requested IP/port, for a limited amount of time. Client makes connection, after which firewall rule expires, but client connection stays open due to the connection-tracking rules.

Here's a demo of fwknop in action: http://www.youtube.com/watch?v=QVpgDCsqr0U

Questions/more info: irc.freenode.net #cipherdyne

Sebastien's Single Packet Authorization info.

Stories For Discussion

  1. Topic: Paul is excited about the installation of his new Alix+pfSense firewall. Installation went excellent, bandwidth seems better, rule creation is a snap, and CPU/memory utilization is very low.
  2. Scanning for Default & Easily Guessable Creds with Nessus - [Paul] - I had fun with this one. I managed to sift through a Nessus policy and tune it for only finding default or common passwords. I think this is a great one for pen testers (I show how to use NASL from command line) and one to run on a schedule within an organization. Look, you should be able to run this alert every day, and it should never find anything, if it does, that's bad, really bad.
  3. Topic: Jailbreaking my iPad - [Paul] - Wow, what a process! First off, its kinda scary. I don't want to brick my iPad. Also, I used these instructions from "redmondpie".
  4. Do we have to talk about the TSA? - [Paul] - Okay, so here's my take: Rule #1: I tell this to my son all the time, "You can only touch your own penis". Its a pretty simple rule, and in general carries on throughout the rest of your life, of course your career or sexual preference may change that, but that totally okay. This rule works well for my two-year-old, why can't the TSA follow the same rules? Do they need to touch your junk in order to make the airport secure? No. I will say this again, take Isreal for example, great security, no penis touching. The other thing is that the general public, at least some, don't seem to care that the TSA is taking nude photos of them. What they don't realize is that these photos will leak, and then the world will see your junk. Or maybe the world gets to the nude photos of celebs, and not the ones with someone else's body and Angelina Jolie's face, not that I look at those, ever.
  5. Topic: Paul lost some family pictures, lessons learned. Human nature sucks sometimes.
  6. Caught!- strandjs- Stealing secrets from Ford? Dude, you are doing it wrong.
  7. Network Card Rootkit - strandjs - Sorry man. Arrigo beat you to the punch. Still excellent work none-the-less.

Other Stories of Interest

List of beer victims