Other articles

  1. ulogd2: the new userspace logging daemon for netfilter/iptables (part 3)

    Installation

    If you’ve followed the previous article, you now have a working ulogd2 installation.We will now explore the way data are stored in the database, and the default SQL schema provided with ulogd2.

    SQL schema, basics

    The SQL schema ? Not really, only the default one. Ulogd2 uses stored procedures and views to create an abstraction layer between the C code and the real storage of the data (the tables in the SQL database). The basics are the following:

    Inserting data using the “INSERT” keyword is fast, but requires the application to know the SQL schema. An update of the SQL part will need an update of the C code, which is not very handy. So instead of using:

    INSERT INTO tablename (field1,field2,...) VALUES (1,2,...);
    

    We will create a stored procedure (in this example, we use PostgreSQL PL/pgSQL syntax):

    CREATE OR REPLACE FUNCTION INSERT_PACKET_FULL(
                   IN value11 integer,
                   ...)
    RETURNS bigint AS $$
    DECLARE
           t_id bigint;
    DECLARE
                   t_id := INSERT INTO tablename (field1,field2,...) VALUES ($1,$2,...);
                   RETURN t_id;
    END
    $$ LANGUAGE plpgsql SECURITY INVOKER;
    

    Inserting data can now be done, using:

    SELECT INSERT_PACKET_FULL(1,2,3,...);
    

    So, we have succeeded into transforming a fast and single (and simple) query into …

    read more
  2. xtables-addons accepted in Debian

    debian-packages

    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 created 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 …
    read more
  3. Netfilter workshop 2008 in Paris

    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 !

    read more
  4. NFQueue bindings (2)

    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 ;)

    read more
  5. NFQueue bindings

    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:

    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 …
    read more
  6. Next-generation firewall

    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:

    wolfotrack

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

    read more
  7. ulogd2: the new userspace logging daemon for netfilter/iptables (part 2)

    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:

    git clone git://git.netfilter.org/ulogd2.git/
    

    Prerequisites

    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 …

    read more
  8. ulogd2: the new userspace logging daemon for netfilter/iptables (part 1)

    Ulogd (and also ulogd2) is a powerful and flexible logging system for Netfilter/Iptables, based on a plugin system. It allows, for example, to log packets in a SQL database, and have some interface to analyze it (see Nulog2)

    nulog

    Architecture

    Ulogd2 combines plugins to create a stack, where each plugin is chained to another. There are three types of plugins:

    • Source
    • Filter
    • Output

    A stack must have only one source, and one output (yet it can have several filters). It is possible to define several stacks in the configuration.

    Each plugin has a type (for ex, PGSQL), and must be instanciated (using a name chosen by the user). Each instance is a particular version of the plugin, defining parameters. This way, we will be able to output data in several formats using different stacks.

    For ex, the following stack :

    stack=log1:NFLOG,base1:BASE,ifi1:IFINDEX,print1:PRINTPKT,pgsql1:PGSQL
    

    defines a stack with the following properties:

    • input plugin is NFLOG, this means we’ll use the -j NFLOG target of iptables as source
    • filters are BASE, IFINDEX, and PRINTPKT (we’ll cover what they do later)
    • output plugin is of type PGSQL, so data will be logged to a …
    read more

Page 1 / 1