To put an end to a teaser.

Along with Laurent and Victor, we've written a Netfilter connection tracking manipulation tool based on the fabulous Wolfenstein 3d game.

You need only two dependencies: SDL library and libnetfilter_conntrack.

Description from the release notes:

Tears were flowing from our bellowed
Administrators out there.

Connection tracking is not always easy,
hence Wolfotrack, the conntrack killer that
aims to reduce the firewall use difficulty
that many people complained about for years.
This software makes this time gone! We are now
enhancing netfilter at the user level.

The idea is simple: with statefull firewall such as Netfilter, the Linux kernel firewall, connection states are kept in memory and allow you to use this simple rule to only allow answers to a previously initiated connection:
# iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Because of the great work put by Netfilter core team into nfnetlink, and especially with the nfnetlink_conntrack socket, it is made trivial to grab the information Netfilter has with any connection state.

For example this code registers the callback function that is then used to set the players connection:
void ct_list_create(void)
{
        int ret;
        u_int8_t family = AF_INET;

        h = nfct_open(CONNTRACK, 0);
        if (!h) {
                perror("nfct_open error: Oh my god! this is terrible! you cannot kill conntracks out from Netfilter!!");
                return;
        }
        nfct_callback_register(h, NFCT_T_ALL, ct_cb, NULL);
        ret = nfct_query(h, NFCT_Q_DUMP, &family);
        if ( ret == -1 ) {
                exit(EXIT_FAILURE);
        }
}

The, the callback prototype is:
int ct_cb(enum nf_conntrack_msg_type type,
                struct nf_conntrack *ct,
                void *data)

And to set the source/destination ip and port out from the nf_conntrack structure:
        if (nfct_get_attr_u8(ct, ATTR_ORIG_L3PROTO) == AF_INET) {
                ip_src = nfct_get_attr_u32(ct, ATTR_ORIG_IPV4_SRC);
                saddr = strdup(inet_ntoa(ip_src));
                ip_dst = nfct_get_attr_u32(ct, ATTR_ORIG_IPV4_DST);
                daddr = strdup(inet_ntoa(ip_dst));
                port_src = nfct_get_attr_u16(ct, ATTR_ORIG_PORT_SRC);
                sport = strdup(port_ntoa(port_src));
                port_dst = nfct_get_attr_u16(ct, ATTR_ORIG_PORT_DST);
                dport = strdup(port_ntoa(port_dst));
        }

Finally, when you kill the actor, we run the following function:
void ct_remove_from_id(int id)
{
        if (ct_list_get(id))
                nfct_query(h, NFCT_Q_DESTROY, ct_list_get(id)->ct);
}

And that's all for the netfilter code (modulo a few tricks to set a connection tracking to a non-dead actor, ..). And here begins the Carmack magic...

I have a high respect for this guy, he started great games that I enjoyed playing in my childhood and I am still amazed by this:
i  = 0x5f3759df - ( i >> 1 );

Yes, this is the famous magic constant to calculate the square root of a number with NO loop of any sort.

Putting the hands in the code, there was no PrintXY, so we wrote the function:
void US_PrintXY(char *str, word X, word Y)
{
    char c, *se, *s, *sz = strdup(str);
    word w, h;
    s = sz;
   
    while (*s)
    {
        se = s;
        while ((c = *se) && (c != '\n'))
            se++;
        *se = '\0';

        USL_MeasureString(s,&w,&h);
        px = X;
        py = Y;
        USL_DrawString(s);

        s = se;
        if (c)
        {
            *se = c;
            s++;

            X = WindowX;
            Y += h;
        }
        else
            X += w;
    }
   
    px = X;
    py = Y;
   
    free(sz);
}

and in wl_draw.c, to draw the text about connection trackings, we need to have the actor in our visual spot:
        if (*visspot
        || (*(visspot-1) && !*(tilespot-1))
        || (*(visspot+1) && !*(tilespot+1))
        || (*(visspot-65) && !*(tilespot-65))
        || (*(visspot-64) && !*(tilespot-64))
        || (*(visspot-63) && !*(tilespot-63))
        || (*(visspot+65) && !*(tilespot+65))
        || (*(visspot+64) && !*(tilespot+64))
        || (*(visspot+63) && !*(tilespot+63)))

and there while browsing the linked list of every object, we need to know if this actor is not dead, so we added this function:
int ActorDead(objtype *obj)
{
        int retval = 0;

        switch(obj->state) {
                case s_grddie4:
                        retval = 1;
                        break;
                default:
                        retval = 0;
        }
        return retval;
}

and then, in the code we use it:
if ( ( obj->obclass == guardobj ) && ( ! ActorDead(obj)) ) {

ok, shame on me, we put the connection tracking only to guards. But if you want to improve the code, this is what you must patch.

And then, if we get an appropriate connection tracking object, we run:
source = malloc(strlen(entry->saddr) +
                strlen(":") +
                strlen(entry->sport) + 1);
target = malloc(strlen(entry->daddr) +
                strlen(":") +
                strlen(entry->dport) + 1);
sprintf(source, "%s:%s", ct_list_get(obj->id)->saddr, ct_list_get(obj->id)->sport );
sprintf(target, "%s:%s", ct_list_get(obj->id)->daddr, ct_list_get(obj->id)->dport );

SETFONTCOLOR(68, BKGDCOLOR);
US_PrintXY(source, 30, 20);
US_PrintXY(target, 30, 30);
SETFONTCOLOR(TEXTCOLOR,BKGDCOLOR);

free(source);
free(target);

Then, we go into the function KillActor (objtype *ob) and if the object is a guard, we run the killing function:
ct_remove_from_id(ob->id);

And this is it! So in summary:

• That was fun to do
• The Wolf3d source code is crystal clear: I have never looked for hours where this or that function was. I am really amazed by the work done by the ID software team back in the early '90. Everything is very logical and I am not involved in video games in any way, so there is a lot of things I don't know
• We need people to improve now. Please go to the Wolfotrack project page and download, send patches etc..

And congrats to Laurent and Victor, that was fun working in team on this kind of project

Monday

...is software release day

Do NOT miss the Netfilter users mailing list

Once upon a time, administrators struggled to manage their firewall. That time will be in a few years, just like what happened to the city of Paris: Paris is considered to be the world's most romanticand seizable city. And the same thing will happen to firewall: they will finally be usable for normal administrators.

Stay tuned!

The paper I co-wrote with Pierre is now available:

Abstract. This paper describes how correlation can be used to reduce false positives, discover new attacks and fight the evasion of intrusion detection systems. Events from different sources, network-based, host-based and others, are used to increase the accuracy of alerts and attacks understanding. A complete solution based on the Prelude IDS framework and the Intrusion Detection Message Exchange Format (IDMEF) standard is proposed, using Voice over IP (VoIP) as an example. Taking advantage of existing products in a hierarchical manner renders more efficient the extraction of relevant security issues. We also propose an algorithm to use correlation results to lower the amount of work needed on sensors, to concentrate on higher-level attack detection.

Key words: IDS, Hybrid IDS, IDMEF, Prelude, Correlation, Management, Assessment, Visualization

Following recent vulnerabilities in the CUPS server, I created two signatures alerting you if your server is vulnerable on the two following CVE:

• CVE-2008-0047: Heap-based buffer overflow in the cgiCompileSearch function in CUPS 1.3.5, and other versions including the version bundled with Apple Mac OS X 10.5.2, when printer sharing is enabled, allows remote attackers to execute arbitrary code via crafted search expressions.
• CVE-2008-0882: Double free vulnerability in the process_browse_data function in CUPS 1.3.5 allows remote attackers to cause a denial of service (daemon crash) and possibly execute arbitrary code via crafted UDP Browse packets to the cupsd port (631/udp), related to an unspecified manipulation of a remote printer. NOTE: some of these details are obtained from third party information.

These signatures are:

alert tcp any 631 -> any any (msg:"PVR - CUPS Heap-based buffer overflow in the cgiCompileSearch function"; flags:PA; flow:established; content:"Server: CUPS/1.3.5"; reference:cve,2008-0047; sid:200804021; rev:2;)
alert udp any 631 -> any any (msg:"PVR - CUPS Double free vulnerability in the process_browse_data function"; flags:PA; flow:established; content:"Server: CUPS/1.3.5"; reference:cve,2008-0882; sid:200804031; rev:1;)

And are of course available from the snort Passive Vulnerability Rulesets from the Signatures.NU project:

svn co http://svn.signatures.nu/snort/pvr/unstable pvr

I recently released GvGen 0.9, a python class that generates dot. I added a smart mode that you can activate on your instance:

>>> graph = gvgen.GvGen()
>>> graph.smart_mode = 1

Then, when you perform multiple links such as:

>>> graph.newLink(ip1, target)
>>> graph.newLink(ip1, target)
>>> graph.newLink(ip1, target)

The link line size and arrow will be biger, such as:

Or, if you have both direction links

>>> graph.newLink(ip1, target)
>>> graph.newLink(target, ip1)

You will obtain:

Download the tarball now!

Want to try the authenticating firewall without to bother installing anything, get the NuFW liveCD now.

Bittorrent: http://live.nufw.org/dl/nufwlive-1.0.iso.torrent
LiveCD URL: http://live.nufw.org/



This live CD allows you to run a complete firewall that you can administrate graphically with NuFace. You set up users using the KDE system user creation tool and then you authenticate your workstations either with the Linux client nutcpc or nuapplet2 (apt-get install) and/or your windows machines with Nuwinc.

And you can of course backup all of this to restore your firewall after a liveCD restart.

Being a liveCD, you can make a gateway firewall that is read-only and enjoy real security.

Je me suis acheté une nouvelle flute :

Devinez laquelle est la nouvelle

It has been a bit more than a year that I started working on visualization for data mining. I strongly believe, that we are just humans, and having a good visualization system for your security events is not just a sexy toy. It is a real advantage for extracting relevant technical information from events overflow.

When I started with brouette, my little Prelude IDS pool event checker toy, I already had the spirit, but I did not really know what it could be, how it would grow etc..

After a few months, to play with the Ruby Language, I wrote "Ruined", the Ruby Iptables NEtwork Displayer. Actually, it was something that I previously wrote in bash (fw2foo), which is a nice script if you want to know how to deal with data structures in bash, callbacks etc.

After what, to ease the development of tools such as Ruined, I started GvGlue, to output dot language data for graphviz after quite some fight with bindings such as pydot and others to generate stuff such as a cluster into an other.

I wanted to learn either Python or Ruby at that time, I did not know which one I could take, so I wrote GvGlue in Python. And, well, sure GvGlue had a very nice API, but to code was terribly not something you wanted to see... unless you want to twist your nerves:

            try:
                for runner in self.data:
                    if runner.find("%d [label=" % subgraphid) != -1:
                        i = self.data.index(runner)
                        mystr = runner[:len(runner)-1] + ",%s=\"%s\"" % (propertyname, value) + "];"
                        self.data.pop(i)
                        if not getstr:
                            self.data.insert(i, mystr)


But at this time, crazy folks like haypo already started to use it to write awesome applications.


Because of Ruined limitations, and because GvGlue code scared me away, I rewrote it under the sexy name "GvGen". And it's been a long time GvGen became more interesting than GvGlue: keeping the KISS spirit and do not reinvent the wheel. Just output dot language. Allowing people to use dot, neato or other graphviz stuff.

GvGen is now part of graphviz ressources.

Last May, I went to Rennes for SSTIC event, which is a computer security symposium. And I saw the presentation Phil made about rtgraph3d.

I got quite excited: this brings a very interesting dimension to the way we can interpret events.

He actually used a hacked version of rtgraph3d along with scapy, to produce ipv6world for his presentation on the IPv6 mistakes and their famous routing headers type 0.

So I wrote a little patch to import graphviz dot language data using the pydot parser (which is quite good here). And now you can simply import those data into rtgraph3d.

I have some other patch I must finalize to bring the graphviz features (colors etc..) into rtgraph3d.

Now let's come back to Prelude stuff and IDMEF: Pierre wrote easy Prelude bindings for both perl and python into the libprelude.

So I decided to take his work to graph using the parallel axes representation and I took the following IDMEF values to write a graph:

• alert.source(0).node.address(0).address
• alert.target(0).node.address(0).address
• alert.assessment.impact.severity
• alert.classification.text

and a timeline to see the attack progression over 24 hours.

And that allows me to produce graphs like this:

And at the same time, I started to write Svp, a Sniffer that Visualize stuff written in Python.

The goal it to show on a parallel axes representation useful information to recognize patterns, such as a port scan.

En lisant un article sur la détection des intrusions réseau aujourd'hui je suis tombé sur quelque chose qui a faillit me faire prendre une crise cardiaque.

Après avoir un peu gémi puis un peu grogné, je me suis dit qu'il serait bon d'écrire sur l'organisation d'un système de détection d'intrusions vis-à-vis des différentes couches du modèle OSI.

Regardons de plus près l'image choquante. Elle est rayée en rouge volontairement pour ne pas que vous puissiez la retenir facilement en mémoire et qu'à cause de cet article, finalement vous soyez plus confus qu'avant de l'avoir lu :

Qu'est-ce que l'on voit exactement ?

Que la détection d'intrusion réseau n'agit qu'à partir du niveau réseau jusqu'au niveau applicatif. Ce qui est terrible là dedans, c'est que l'on oublie que la plupart des outils de détection d'intrusion de France et de Chatuzange-le-Goubet utilisent la libpcap comme base pour la capture des données lui permettant ensuite de faire la relation avec les signatures pour en déduire des alertes. De Snort a Bro en passant par Sancp et bien d'autres encore...
L'image est donc incorrecte, et sa version juste et modifiée est :


C'est bien, maintenant vous avez la vérité, mais le sujet de ce billet est de présenter l'interaction des IDS avec les différentes couches et enfoncer le clou parce qu'un peu de rafraichissement de mémoire ne fait jamais de mal.

Liaison de données

Comme expliqué précédemment, c'est au niveau de cette couche que la libpcap fonctionne. Pour preuve, il vous arrive toujours de voir les paquets arriver lorsque vous mettez un place des règles de firewall. Les trames Ethernet arrivent, sont généralement d'une taille fixée à un maximum de 1500 octets et contiennent l'adresse MAC des cartes physiques qui délivrent les données.
La libpcap copie les données (ce qui peut être un problème de performance, mais la un certain patch peut vous aider; ainsi qu'un problème d'évasion d'IDS, mais là on dépasse du cadre de ce billet, je reviendrai un jour là dessus), applique ensuite son filtre BPF pour le délivrer à l'application qui utilise les fonctions magiques.

Réseau

On peut très bien récupérer les informations concernant les paquets réseau par un autre biais que via la libpcap ou mmap() en utilisant ce que le noyau (je prend Linux comme référence) peut proposer à ce niveau.
Je pense en particulier à Netfilter, qui a l'avantage de permettre à des modules d'utiliser ses hooks mis à différents points de la couche réseau, et qui en plus offre deux fonctionnalités plaisantes :

• LOG/ULOG : Afin d'envoyer les paquets mis dans cette cible dans un journal système (LOG) ou en vue d'une application utilisateur (ULOG)
• NFQUEUE : Qui renvoie les paquets en espace utilisateur pour les applications qui sont connectées sur la socket nflink en vue de définir un verdict

La seconde technique est ultime. C'est ce qu'utilise d'ailleurs Snort Inline pour offrir à Snort un mode de fonctionnement en IPS (Intrusion Prevention System). C'est aussi une technique utilisée par Nufw, un firewall authentifiant. Cela permet au NIDS de prendre directement au niveau du firewall de la décision à appliquer sur un paquet en fonction de si il correspond à un motif d'intrusion ou non.

Transport

Ici rien de vraiment sexy, en géneral la capture se fait au niveau au (des?) dessous.

Session, Présentation

Une fois la capture effectuée, c'est à ce niveau que l'on voit apparaitre ce que certains appellent des dissecteurs, d'autres des préprocesseurs... Il s'agit en fait de décoder des protocoles comme RPC, et se choper au passages des problèmes intéressants. L'avantage est de pouvoir décoder les protocoles en profondeur pour en faire une analyse plus poussée qu'une simple recherche de motifs sur la charge utile.

Application

À ce niveau, on parle des logs générés par les différentes applications qui sont ensuite analysés par les programmes comme Prelude LML ou encore Ossec. On récupère ces informations en utilisant des technologies comme FAM, Gamin ou en faisant soi-même la vérification sur la modification des fichiers.


En espérant avoir apporté un peu de clarté dans tout ceci, n'hésitez pas à me soumettre vos documents choquants en vue d'une analyse