( Pollux's blog )

Captive portals almost always work by validating the IP address of the client, and often the MAC address. This creates a wrong feeling of security, because it is quite easy to bypass. Let's explain the most common problem: spoofing.

Installing a captive portal

I have chosen to install Alcasar, which claims to be a highly secure solution developed by the French Ministry of Defense.

First surprise, it's a shell script ! In fact, it's not really an application, only an installer for a few packages, with some configuration. Installation went pretty bad:

• the installer only works for a specific version of Mandriva (2007), which is quite old, and buggy on my hardware
• most things are hardcoded: the installer exploded without errors because my network is not ending by a 0 (10.0.0.129/25)
• my third network card is not even used by the script ! Too bad for the DMZ

After 4 or 5 retries, and modifications in the script, I finally got a working server.

First tests

After a reboot, everything seems to work. Got an address using DHCP, I try to connect to Google .. ok, the captive portal appears and asks for a login. With the administration interface, I create a user, login, then tries to redirect me to the site, good. Except that the connection is never done ! After searching everywhere, I decide to use ssh to debug the problem on the server. After a few strace commands, I found that squid is trying to connect to the wrong host ! Yet another bug in the installer ...

After fixing a few more bugs, I finally succeed to use the captive portal.

Administration interface

The administration interface is nothing more than a user editor (it use its own user database), and a few statistic tools like AWStats and Firewall Eyes. Ouch, a log analyzer ! This means you won't be able to make complicated searches, and I have serious doubts about the ability to parse big log files.

The captive portal software itself is Chillispot, which is quite good but appears to be unmaintained (no release since 2 years).

The log analysis tools are very poor, not to say rudimentary. There is no easy way to find which user was connected on a host at a specific date, you have to dig yourself through several poor interfaces, connecting to the server and using grep is much more efficient !

Rules

Yet another surprise, there is no way to create rules to specify which protocols are authorized. I was supposing that only HTTP and HTTPS were allowed, but in fact when you are logged everything is open. No tools are provided, so you have to know iptables well :)

Confidentiality

Alcasar generates a self-signed certificate and uses HTTPS connections for login. This has to be treated seriously, because the certificate is self-signed, so it will be quite easy to generate another self-signed certificate with the same parameters to make a man-in-the-middle attack: most people will only look at the certificate and then validate it without questions ....

Strict security ?

Alcasar is developed by serious guys, and claims to comply with the French laws. It also claims that it allows to authenticate users and identify them strictly, and that these information could be used by the police. Scary.

I decided to run a very simple test, to check if Alcasar would be resistant to IP or MAC spoofing. I connected 2 laptops on the network, and login on one of them. The following steps are very easy: On the laptop not connected:

• start wireshark, and listen passively to get the IP and mac address of the host In a few seconds, I got them

• change my IP and MAC addresses

In fact, you do not have to run the first and third commands: only change the MAC address and launch the DHCP client. You'll get the same IP address as the real host, and the gateway will be configured.

• connect to a site:

Here you are ! In one command, you are connected !

Note: it is illegal to bypass a security protection. The commands here are provided for educational purposes only, do not use them or you could be prosecuted. However, the commands explained here are so easy a child could use them, so you have to know them and to defend.

Am I caught ?

Alcasar haven't seen the intrusion :) In fact, the problem is worse: I am logged with the identify of the other user, meaning that my actions will be logged with his name ! As there are no iptables rules by default, I was able to connect to an SSH server outside without problems.

Conclusion

Alcasar is only a set of scripts and configuration files based on other software. As for other captive portals, it is vulnerable to very simple attacks. The situation would not be as bad if Alcasar was not trying to present itself as a strict security solution. I would really be scared if my company was using a captive portal to handle internet access, because it gives a false feeling of security, can be bypassed very easily, and because of that, its logs cannot be used as legal stuff : no serious judge would take into account a solution which can be bypassed in a few seconds.

Captive portals like Alcasar provides a weak protection against attacks. If you want strict authentication of users, and protection against IP or ARP spoofing, use NuFW, it's free (as free beer) and free (GPL).

Xtables-addons is a is a project developped by Jan Engelhardt to replace the old patch-o-matic repository for the Linux kernel and iptables. Instead of patching the kernel source, extensions are built as modules and thus allow extending kernels without recompilation.

I have create a Debian package, split in two parts: xtables-addons-source (the sources of the kernel modules), and xtables-addons-common (common files: shared libraries, man pages, binaries).

To install xtables-addons on Debian (sid only, but the package works on Lenny after a rebuild), run the following commands:

apt-get install module-assistant xtables-addons-source
module-assistant prepare
module-assistant auto-install xtables-addons-source

It will automatically install the headers for your kernel, build the modules, create a local package, and install it. What's interesting is that, unlike before (using p-o-m or kernel patches), there is no need to reboot.

It adds new targets for iptables:

• CHAOS: randomly use REJECT, DELUDE or TARPIT targets. This will fool network scanners by returning random results
• DELUDE: always reply to a SYN by a SYN-ACK. This will fool TCP half-open discovery
• DHCPADDR: replace a MAC address from and to a VMware host
• IPMARK: mark a packet, based on its IP address
• LOGMARK: log packet and mark to syslog
• SYSRQ: trigger a sysreq over the network (sending a saK over the network looks like a real funny idea ;)
• TARPIT: try to slow down (or DoS) remote host by capturing the session and holding it for a long time, using a 0-bytes TCP window. Run that on port 25 if you have no mail server to slow down spammers ;)

There's also a list of new matches modules for iptables:

• condition: match on boolean value stored in /proc/net/nf_condition/name
• dhcpaddr: match the DHCP Client Host address in a DHCP message
• fuzzy: match a rate limit based on a fuzzy logic controller
• geoip: match a packet by its source or destination country
• ipp2p: match (certain) p2p protocols
• portscan: try to match port scanners based on packet contents
• quota2: named counters

It also provides a version of ipset, a framework to manager sets of IP addresses in iptables rules efficiently.

No news here, this post is mostly a note for myself, to remember some commands for git:

Creating a repository to be shared between several hosts (with an existing project)

On the server:

mkdir project.git
cd project.git
git --bare init

On the remote host:

cd project
git init
git remote add origin ssh://server/var/git/project
git config branch.master.remote origin
git config branch.master.merge refs/heads/master

Now you can make the first commit:

git add .
git commit -m "First commit"
git push

Fix a mistake in a previous commit

1. Save your work so far.
2. Stash your changes away for now: git stash
3. Now your working copy is clean at the state of your last commit.
4. Make the fixes. (If you just want to change the log, skip this step.)
5. Commit the changes in “amend” mode: git commit all amend
6. Your editor will come up asking for a log message (by default, the old log message). Save and quit the editor when you’re happy with it.
7. The new changes are added on to the old commit. See for yourself with git log and git diff HEAD^
8. Re-apply your stashed changes: git stash apply
9. Continue happily with your life.

I'm a happy git user, it really rocks.

These talks are probably online since a while, but as most of them are really interesting, have a look at CanSecWest 2008 conference materials:

• Marty Roesch - Sourcefire: Snort 3.0
• Rich Cannings - Google: Cross-Site Scripting Vulnerabilities in Flash Authoring Tools
• Jan "starbug" Krissler & Karsten Nohl - CCC: Proprietary RFID Systems
• Mark Dowd & John McDonald - IBM ISS: Media Frenzy: Finding Bugs in Windows Media Software
• Rob Hensing - Microsoft: Targeted Attacks and Microsoft Office Malware
• Oded Horovitz - VMWare: Virtually Secure
• Frédéric Raynal - Sogeti/Cap-Gemini: Malicious Cryptography
• Thierry Zoller and Sergio Alvarez - n.runs: The Death of AV Defense in Depth? Revisiting Anti-Virus Software
• Sun Bing: VMWare Issues
• Sebastien Tricaud and Pierre Chifflier - INL: Intrusion Detection Systems Correlation: a Weapon of Mass Investigation
• Dan Hubbard and Stephan Chenette - WebSense: Web Wreck-utation
• Marcel Holtmann - Intel: Secure programming with gcc and glibc
• olleB - toolcrypt.org: Mobitex network security
• Michael Eddington - Leviathan: Peach Fuzzing
• Charlie Miller - Independent Security Evaluators: Fuzz by Number
• Frank Marcus & Mikko Varpiola - Wurldtech / Codenomicon: Fuzzing WTF? What Fuzzing Was, Is And Never Will Be.
• Kowsik Guruswamy - Mu: Vulnerabilities Die Hard
• Dan Grifin - JW Secure: Hacking Windows Vista
• Philippe Lagadec - NATO/NC3A: ExeFilter: a new open-source framework for active content filtering
• Eric Hacker - BT INS: VetNetSec: Security testing for Extremists
• Andres Riancho - Cybsec: w3af: A framework to own the web
• Scott K. Larson - Stroz Friedberg: A Unique Behavioral Science Approach to Threats, Extortion and Internal Computer Investigations

Globally, there were many talks on fuzzers, some interesting work on cold boot attacks, a confirmation that anti-virus are also vulnerable, and a very nice presentation from the CCC guys on how to "dissassemble" an RFID chip :) I also liked the last presentation, which was not really about security stuff, but more about how a software could help determining the character and the pathologies of a guy, from his writings. Scary !

One bad point, though: commercial presentations with no real contents. VMWare folks, for ex., coming to say "hey, we have the best security API, we can monitor stuff from the VMX server" etc., that's cool. But when someone asks to see the code, or how to use the API, the answer was "well, eeeh. We can't show you, but it's cool, believe us".

Congrats, and thanks, to Dragos for keeping this conference high-quality over years.

The next edition of the Netfilter Workshop will take place in Paris, France, from September 29th to October 3th, 2008.

The first day is open to everyone, and the program is now online.

There will be many interesting presentations, and I will give a presentation of nfqueue-bindings and the weatherwall, a firewall based on the weather of the location of the destination of the packets, and ulogd2 along with Eric.

Entry is free but a registration is asked. Please fill in the registration form.

See you there !

The Prelude Correlator is now packaged in Debian.

From the description of the package:

Prelude is a general-purpose hybrid intrusion detection system.
.
This package provides the Prelude Correlator, which is a powerful
correlation engine using Lua to write correlation rules.
.
The features currently include:
 * Rapid identification of important security events, enabling the analyst to
   assign task priorities
 * Alert correlation originally from heterogeneous sensors deployed on the
   whole infrastructure
 * Real-time analysis of events received by the Prelude Manager

You can contribute ! If you use the correlation engine, please share your correlation rules.

Related links:

• Technical documentation
• Download Prelude Correlator
• Lua official site

Since recent versions, entropy generation is very slooooooow on Linux (mainly because the entropy generation algorithm has been changed for security). This can be really painful when generating certificates, for ex. for Prelude. Reading /dev/random only gives a few bytes per second !

If you're lucky, you will have a hardware random generator (RNG). However this is generally not the case, so how to speed up random generation ?

One solution is to take random data from another source and then inject if to the kernel random pool. You have to be careful though, because if you read data from /dev/null it will be fast, but you will have problems !

Install rng-tools, which reads data from a configurable input source (hardware RNG, or, in our case, /dev/urandom). Before injecting data to the kernel, rng-tools test data with the FIPS 140-2 test, and then add it.

Warning: if you want to generate, for ex, certificates for Prelude, you must fully install and configure rng-tools before installing Prelude !

apt-get install rng-tools
vi /etc/default/rng-tools

Change the values, for ex:

HRNGDEVICE=/dev/urandom
RNGDOPTIONS="-W 80% -t 20"

The second line tells rng-tools to fill 80% of the kernel random pool (default is 50%) every 20 seconds maximum (default is 60). You may want to adjust these not to be too aggressive, or your "tainted" random data will completely replace real random data. See man rngd for more information.

/etc/init.d/rng-tools start

Caution: if you want 100%-sure random data, then stick to the default random generator, or use other libraries

The code for nfqueue-bindings is now almost ready, I have made some progress since last week:

* you can now modify packets in live, and send the new packet with the verdict
* new functions are wrapped, and the creation of the queue can be done in one function
* more examples

I have presented a special script for SSTIC, using the weather to decide if a packet should be accepted or dropped :) While the utility of the module still has to be proven, it is a good example of how easy it is to use the new bindings.

The slides can be found online here, and contains some code examples (with some funny things ;). They are in french, but they should be quite easy to understand.

Random ideas:

* The Netfilter workshop will be held in Paris from 30 September to 3 October 2008.
* Eric has presented nf3d, a nice tool to view netfilter logs (from ulogd2) in 3D.

Gamers will recognize a nice try to convert network logs into Guitar Hero tracks ;)

* Some people have weird habits at SSTIC !

I am currently working (amongst other projects ..) on nfqueue-bindings, set of high-level modules for several languages (Python and Perl, for the moment), for libnetfilter_queue.

The goal is to provide a library to gain access to packets queued by the kernel packet filter. For more details, see nfqueue-bindings project site.

Current state

Actually, you can

* access the module in Perl or Python
* create a queue connected to netfilter
* register a callback
* access the contents of the packet. As I do not want to do what was already done many times, I use some other libraries to decode the packet: 
 * NetPacket::IP for Perl
 * dpkg for Python.
 * If you know some other libraries, please let me know.
* set the verdict (decision) to ACCEPT or DROP for the packet

I have written some scripts to show what can be done in a few lines of code. The current examples are:

* example Perl script
* example Python script
* Packet dumper, in pcap format (use scapy)
* HTTP request checker
* A surprise I will present in a lightning talk at SSTIC :)

I will make a release as soon as the code is stable (and can be installed).

Examples

Create and bind the queue (Perl)

use nfqueue;

use NetPacket::IP qw(IP_PROTO_TCP);
use NetPacket::TCP;

my $q;

sub cb
{
...
}

$q = new nfqueue::queue();
$q->open();
$q->bind();
$q->set_callback(\&cb);

$q->try_run();

Create and bind the queue (Python)

import nfqueue
from dpkt import ip

q = None

def cb(dummy, payload):
  ...

q = nfqueue.queue()
q.open()
q.bind()
q.set_callback(cb)
q.create_queue(0)

q.try_run()

Decode packet (Perl)

Now all we have to do is to use the callback !

my $ip_obj = NetPacket::IP->decode($payload->get_data());
print("$ip_obj->{src_ip} => $ip_obj->{dest_ip} $ip_obj->{proto}\n");

if($ip_obj->{proto} == IP_PROTO_TCP) {
  my $tcp_obj = NetPacket::TCP->decode($ip_obj->{data});
  	print "TCP src_port: $tcp_obj->{src_port}\n";

Decode packet (Python)

data = payload.get_data()
pkt = ip.IP(data)
print "proto:", pkt.p
print "source: %s" % inet_ntoa(pkt.src)
print "dest: %s" % inet_ntoa(pkt.dst)
if pkt.p == ip.IP_PROTO_TCP:
  print "  sport: %s" % pkt.tcp.sport
  print "  dport: %s" % pkt.tcp.dport

Set verdict

Perl:

$payload->set_verdict($nfqueue::NF_DROP);

Python:

payload.set_verdict(nfqueue.NF_DROP)

Links

* libnetfilter_queue
* nfqueue-bindings project site
* nfqueue-bindings source (git browser)
* Get source: git clone http://git.inl.fr/git/nfqueue-bindings.git

(See part 1)

Remember: you must compile with -02 if you want the checks to be effective

DEB_BUILD_HARDENING_FORTIFY (gcc/g++ -D_FORTIFY_SOURCE=2)

The idea behind FORTIFY_SOURCE is relatively simple: there are cases where the compiler can know the size of a buffer (if it's a fixed sized buffer on the stack, as in the example, or if the buffer just came from a malloc() function call). With a known buffer size, functions that operate on the buffer can make sure the buffer will not overflow.

Example:

void foo(char *string)
{
	char buf[20];
	strcpy(buf, string);
}

Execution will fail:

[home ~/harden] ./bad $(perl -e 'print "A"x100')
zsh: segmentation fault  ./bad $(perl -e 'print "A"x100')

When compiling with -D_FORTIFY_SOURCE=2, gcc will add some checks to detect the overflow and terminate the program:

[home ~/harden] DEB_BUILD_HARDENING=1 make
[home ~/harden] ./bad $(perl -e 'print "A"x100')

*** buffer overflow detected ***: ./bad terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x37)[0x2ba8d18fb787]
/lib/libc.so.6[0x2ba8d18f9e70]
./bad(main+0x26)[0x555555554856]
/lib/libc.so.6(__libc_start_main+0xf4)[0x2ba8d18411c4]
./bad[0x555555554789]
======= Memory map:  ========
2ba8d1607000-2ba8d1622000 r-xp 00000000 03:01 468316                     /lib/ld-2.7.so
2ba8d1622000-2ba8d1625000 rw-p 2ba8d1622000 00:00 0 
2ba8d1821000-2ba8d1823000 rw-p 0001a000 03:01 468316                     /lib/ld-2.7.so
2ba8d1823000-2ba8d1961000 r-xp 00000000 03:01 471074                     /lib/libc-2.7.so
2ba8d1961000-2ba8d1b61000 ---p 0013e000 03:01 471074                     /lib/libc-2.7.so
2ba8d1b61000-2ba8d1b64000 r--p 0013e000 03:01 471074                     /lib/libc-2.7.so
2ba8d1b64000-2ba8d1b66000 rw-p 00141000 03:01 471074                     /lib/libc-2.7.so
2ba8d1b66000-2ba8d1b6c000 rw-p 2ba8d1b66000 00:00 0 
2ba8d1b6c000-2ba8d1b82000 r-xp 00000000 03:01 1045795                    /lib/libgcc_s.so.1
2ba8d1b82000-2ba8d1d82000 ---p 00016000 03:01 1045795                    /lib/libgcc_s.so.1
2ba8d1d82000-2ba8d1d83000 rw-p 00016000 03:01 1045795                    /lib/libgcc_s.so.1
555555554000-555555555000 r-xp 00000000 03:07 1225                       /home/pollux/harden/bad
555555754000-555555755000 r--p 00000000 03:07 1225                       /home/pollux/harden/bad
555555755000-555555756000 rw-p 00001000 03:07 1225                       /home/pollux/harden/bad
555555756000-555555777000 rw-p 555555756000 00:00 0                      [heap]
7fffd948e000-7fffd94a3000 rw-p 7ffffffea000 00:00 0                      [stack]
7fffd95fe000-7fffd9600000 r-xp 7fffd95fe000 00:00 0                      [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
zsh: abort      ./bad $(perl -e 'print "A"x100')

The difference is that there is no segmentation fault, because the program was properly terminated, so no exploit possible. A backtrace is also printed to help.

It is possible to detect if a program is using such checks by using objdump:

[home ~/harden] objdump -d bad | grep call |grep _chk
 84b:   e8 c0 fe ff ff          callq  710 <__stack_chk_fail@plt>

If there is one line or more, FORTIFY_SOURCE is active. However if the output is empty, FORTIFY_SOURCE either might not be enabled, or the program code is such that FORTIFY_SOURCE is not applicable (for example: secure code that has no static buffers and always checks buffer sizes, and thus FORTIFY_SOURCE cannot identify any potentially dangerous operations in the program).

A firewall has to find the difference between good and bad packets, and for this, nothing is better than humans ! (french people could add this is the same difference as for good and bad hunters).

So the next generation firewall will be:

• better than stateful
• better than layer 7 analysis
• compliant with encrypted traffic
• able to detect malware, suspicious traffic, virus, etc.

Preview screenshot:

Source code should be released on monday, on the Netfilter mailing lists. Stay tuned !

Since recent versions (>= 4.0, maybe before), gcc (and ld) has some nice security features. Debian has created a wrapper for the toolchain, to make the use of these features easy.

To install the wrapper, run:

apt-get install hardening-wrapper

To enable the hardening features, you have to export the environment variable:

export DEB_BUILD_HARDENING=1

The features include additional checks for printf-like functions, stack protector, using address-space layout randomization (ASLR), marking ELF-sections as read-only after loading when possible, etc.

Please note that you must compile with -02 if you want the checks to be effective

DEB_BUILD_HARDENING_FORMAT (gcc/g++ -Wformat -Wformat-security)

Ask gcc to make additional checks on format strings, to prevent attacks.

The following code, for ex:

printf(buf);

will result in a warning:

[home ~/harden] DEB_BUILD_HARDENING=1 make
gcc     bad.c   -o bad
bad.c: In function ‘main’:
bad.c:10: warning: format not a string literal and no format arguments

Why is this code vulnerable ? Because the buffer (buf) could contain format characters like %s, and the printf function will interpret these characters to pop arguments from the stack, and can result in the execution of arbitrary code.

Solution:

• Replace previous code by

printf("%s",buf);

• Remember this is also true for other functions like syslog()
• Tell gcc to help ! You can mark your own printf-like functions using gcc attributes, for ex:

void out_log(int level,const char *fmt,...)
#ifdef __GNUC__
  __attribute__((__format__(printf,2,3)))
#endif
;

DEB_BUILD_HARDENING_RELRO (ld -z relro)

When loading a program (which is handled by ld-linux.so), many ELF sections are written and so marked as read-write. However, most of them could be turned read-only after. This options tells the linker to mark as much sections as possible read-only.

[home ~/harden] objdump -x bad | grep RELRO
[home ~/harden] DEB_BUILD_HARDENING=1 make
[home ~/harden] objdump -x bad | grep RELRO
  RELRO off    0x0000000000000df0 vaddr 0x0000000000200df0 paddr 0x0000000000200df0 align 2**

Links

• Format string attacks (Wikipedia)
• Debian wiki page on source hardening

This article explains how to build, install and configure ulogd 2 for use with netfilter/iptables. It explains how to use plugins to store logs in databases (MySQL and PostgreSQL), use plugins to filter data, and gives some iptables rules to log packets.

Get the sources

You can use the official repository:

svn co https://svn.netfilter.org/netfilter/branches/ulog/ulogd2 ulogd2

You can also use our work repository (Regit and I) which contains the same files, with some additional patches here:

git clone http://home.regit.org/~regit/git/ulogd2.git ulogd2

Prerequisites

• libnfnetlink (>= 0.30) http://www.netfilter.org/projects/libnfnetlink/index.html
• libnetfilter_log
• mysql-dev
• postgresql-dev

Build

Use the standard autotools method for configure, build and install:

./autogen.sh
./configure --prefix=/path/to/prefix
make
sudo make install

Configuration

Edit ulogd.conf

1. enable plugins

You will have to choose the input and output plugins according to your setup. NFLOG is present in recent kernels (and iptables installation), and should be preferred if possible.

• Input plugin: ULOG or NFLOG
• Output: MySQL or PostgreSQL

You have to enable the corresponding in the configuration before you can use them:

plugin="/path/to/prefix/lib/ulogd/ulogd_inppkt_ULOG.so"
plugin="/path/to/prefix/lib/ulogd/ulogd_output_MYSQL.so"

See "Stack configuration" later.

2. buid the stack

For MySQL, we will use a very simple plugin stack. As MySQL is quite inefficient in storing IP addresses (and has no standard type for it), we will log the IP addresses in binary format using the IP2BIN plugin. You won't be able to run SQL commands directly, but GUI tools (like Nulog can decode them.

stack=log1:ULOG,base1:BASE,ip2bin1:IP2BIN,mysql1:MYSQL

For PostgreSQL, the stack is similar, except that we choose to log IP addresses using the standard inet type.

stack=log1:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,pgsql1:PGSQL

3. configure input plugin

[log1]
# netlink multicast group (the same as the iptables --ulog-nlgroup param)
nlgroup=1

4. configure output plugin

[mysql1]
db="ulog2"
host="localhost"
user="ulog2"
table="ulog"
pass="password"
procedure="INSERT_PACKET_FULL"

The configuration is the same as usual and should be easy, except maybe for the last parameter: it is the name of a procedure which will be used to insert data.

For PostgreSQL, you can use the following:

[pgsql1]
db="ulog2"
host="localhost"
user="ulog2"
table="ulog"
pass="ulog2"
procedure="INSERT_PACKET_FULL"

The configuration is the same, assuming you are running on the default port and have configured PostgreSQL, and can connect.

Stack configuration

Each module is a plugin which is dynamically loaded during ulogd start. A module has:

• Input keys: It defined the entry which are needed (mandatory or not) by the module to be able to work (ie output other keys)
• Output keys: The module outputs key->value association with key in the output list.

Each key has a type and may have a default value.

To have a working stack, you will need to provide an input module and filter which will be able to modify the initial set of key->value provided by the input module in a set of key->value which will contain all the input keys which are mandatory for the output plugin.

Information about a given module can be obtained through the info command of ulogd:

# /opt/ulogd2/sbin/ulogd --info /opt/ulogd2/lib/ulogd/ulogd_filter_IP2STR.so
Name: IP2STR
Input keys:
       Key: oob.family (unsigned int 8)
       Key: oob.protocol (unsigned int 16)
       Key: ip.saddr (IP addr)
       Key: ip.daddr (IP addr)
       [...]
Output keys:
       Key: ip.saddr.str (string)
       Key: ip.daddr.str (string)
       [...]

From this output, we see that the IP2STR module output IP in string format and take in input IP in rw format and some additional information (oob.family and oob.protocol).

Input plugins

• ULOG: get packet select via the iptables target ULOG
• NFLOG: get packet from NFLOG target which is the successor of ULOG
• NFCT: get flow information from Netfilter connection tracking via libnetfilter_conntrack

Output plugins

• LOGEMU: log packet/flow into a file
• OPRINT: log packet/flow to a file in multiline format
• SYSLOG: log packet/flow to syslog system
• MYSQL: log packet/flow to a MySQL database
• PGSQL: log packet/flow to a PGSQL server
• SQLITE3: log packet to a SQLITE3 file
• PCAP: log packet to a Pcap file
• IPFIX: log flow via IP Flow Information Export
• NACCT: log flow to a nacct compatible format (accounting)

Create database schema

PostgreSQL

1. create user and database

# su - postgres
$ createuser -P ulog2
$ createdb -O ulog2 ulog2

2. add support for plpgsql language (for procedures)

$ createlang plpgsql ulog2

3. insert schema

$ psql -U ulog2 -h localhost ulog2 -f doc/pgsql-ulogd2.sql

MySQL

1. create user and database

# mysql -uroot mysql
> CREATE DATABASE ulog2;
> GRANT ALL PRIVILEGES TO 'ulog2'@'localhost' IDENTIFIED BY 'password';

2. insert schema

$ mysql -uulo2 -ppassword ulog2 < doc/mysql-ulogd2.sql

Start ulogd2

As root, start the process:

/path/to/prefix/sbin/ulogd

If an error happens, it will only print:

Fatal error, check logfile.

Edit /var/log/ulogd.log (be careful, you will have to scroll many lines, so be sure not to use tail).

Wed Mar 26 22:19:54 2008 <7> ulogd.c:698 cannot find key `timestamp' in stack
Wed Mar 26 22:19:54 2008 <1> ulogd.c:807 destroying stack

Add iptables rules

iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ULOG

Check the result

mysql> select count(*) from ulog2;
+--+
| count(*) |
+--+
|        5 |
+--+
1 row in set (0.00 sec)

So now, we are logging to the database. Next time, we will detail the SQL schema: how to get information, how to insert data, tables, view, procedures, etc.

References

• http://software.inl.fr/trac/wiki/ulogd2/user
• ulogd 2 articles, part 1

The Black Hat Europe 2008 Media Archives are now online. I wasn't there, but the archives contains some interesting materials:

• Spam-Evolution
• LDAP Injection & Blind LDAP Injection (see my post)
• New Viral Threats of PDF Language
• 0-Day Patch -Exposing Vendors (In)Security Performance
• Client-side Security
• Attacking Anti-Virus (there was a presentation on the same subject at CanSecWest and Hack.lu)
• Investigating Individuals and Organizations Using Open Source Intelligence
• DTRACE: The Reverse Engineer's Unexpected Swiss Army Knife
• ...

Related links:

• Hack.lu presentations
• USENIX Proceedings online
• Defcon Media Archives