Episode221

From Security Weekly Wiki
Jump to navigationJump to search



Sponsors & Announcements

"And now from the dark corners of the Internet, where the exploits run wild, packets get sniffed, and the beer flows steady its PaulDotCom Security Weekly!"

"Sponsored by Tenable network security. Tenable is a developer of enterprise vulnerability, compliance and log management software, but most notably the creators of Nessus, the worlds best vulnerability scanner. Tenable's Security Center extends the power of Nessus through reporting, remediation workflow, IDS event correlation and much more. Tenable – Unified Security Monitoring!"

"Core Security Technologies, helping you penetrate your network. Now version 10.5 full of Jive! Rock out with your 'sploit out! Listen to this podcast and qualify to receive a 10% discount on Core Impact, the worlds best penetration testing tool."

"Cenzic, create a Hailstorm for your web applications! Sign up for a free trial of the Hailstorm software or scan remotely with their new online service to keep you web applications in check."

"And Trustwave's SpiderLabs - providing advanced information security services to planet Earth. Visit them online at trustwave.com/spiderlabs!"


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


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 61.140.128.199
Nov 10 21:21:25 sshd[1715]: Invalid user guest from 61.140.128.199
Nov 10 21:21:28 sshd[1717]: Invalid user test from 61.140.128.199
Nov 10 21:21:33 sshd[1719]: Invalid user oracle from 61.140.128.199

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

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

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

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)
Access:         0.0.0.0,tcp/22
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

Example:

  • Client: 192.168.0.2
  • Server: 192.168.0.5
  • Service: tcp/22 (SSH)
[client]~$ fwknop -D 192.168.0.5 -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

Other Stories of Interest

List of beer victims