Snort Inline

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
41
Mois de parution
avril 2009
Spécialité(s)


Résumé

La détection d'intrusion réseau (NIDS) permet de vous alerter dans le cas d'une attaque. Une attaque peut très bien être une injection de code SQL sur un formulaire web, un parcours de répertoires pour remonter sur le fichier de mot de passe dans le cas d'un système mal configuré ou encore un scan de ports. Grâce à l'utilisation des bibliothèques que Netfilter fournit, Snort peut bloquer une attaque et fonctionner en mode IPS, c'est-à-dire la bloquer (Prevention). Nous allons voir, dans cet article, les principes de la détection d'intrusion réseau, puis mettre en œuvre une passerelle capable de bloquer les attaques arrivant sur votre réseau interne.


Body

1. Introduction

Les menaces à destination d'un réseau interne sont de plus en plus présentes à cause de la démocratisation d'internet, donc d'applications riches, donc de vecteurs d'attaques amplifiés et le tout automatisé par des vers ou virus. Malheureusement, ces attaques deviennent extrêmement complexes, à tel point qu'il n'est pas possible pour un être humain normalement constitué d'ingurgiter la masse d'information vue la rapidité de diffusion des vulnérabilités et des attaques.

Heureusement, il existe un logiciel libre qui est capable de mettre en relation le flux réseau avec des signatures, de la même façon qu'un anti-virus va mettre en relation des signatures avec des binaires statiques. Ce logiciel s'appelle Snort et est disponible sur le site http://www.snort.org.

Mais attention, ne téléchargez pas cette version, car nous allons utiliser une variante qui s'appelle Snort Inline et qui est un projet à part entière, et a son propre site : http://snort-inline.sourceforge.net (là, vous pouvez télécharger).

Nous allons prendre les sources, version snort_inline-2.6.1.5.

Snort est découpé en 3 parties principales, comme le sera cet article. La première partie est celle de la capture du flux réseau :

- Capture : Alors que le Snort classique se base sur la libpcap, qui est la bibliothèque qui fût développée pour écrire le sniffeur tcpdump, Snort inline utilise la libnetfilter queue.

- Signatures : Il existe plusieurs milliers de signatures qui fonctionnent à plusieurs niveaux. Nous allons en voir quelques-unes pour comprendre comment en écrire, mais aussi comment elles peuvent se configurer dans le snort_inline.conf.

- Alerte : Ce qui est remonté à l'administrateur lorsqu'une attaque est détectée. Nous allons voir que des alertes nous sont remontées dans des cas où il n'y a pas forcément d'attaque. Cela s'appelle les « faux positifs ».

 

nids

 

Nous allons mettre en place Snort Inline en mode pont, c'est-à-dire que la machine n'aura pas d'adresse IP.

Pour couper court à une guerre de religion récurrente sur la détection d'intrusions, la machine sera placée derrière le pare-feu, car seuls les paquets qui arrivent sur notre réseau nous intéressent. Il est insensé de mettre la machine devant le pare-feu, car internet regorge d'activités malveillantes (vers, scans, etc.) qui ne vous concerne pas forcément. Cela augmente votre charge de travail inutilement, car vous devrez filtrer les faux positifs de vraies attaques, et ,au final, vous n'utiliserez pas l'outil. Le seul cas où c'est intéressant de le faire est pour le fun, pour constater en vrai ces activités malveillantes (et encore, difficile d'être mort de rire avec ça ! Ahahahah !).

Le but de cet article étant de pouvoir mettre en pratique sur votre réseau une installation de Snort Inline, nous irons à l'essentiel.

2. Installation

Nous prenons une Debian Lenny comme distribution de référence. Snort Inline peut se compiler sous toutes les grandes distributions sans problème. Il suffira d'adapter les packages par rapport à ce qui est disponible.

Dans un premier temps, il faut récupérer les sources, puis décompresser.

% wget http://ovh.dl.sourceforge.net/sourceforge/snort-inline/snort_inline-2.6.1.5.tar.gz

% tar xf snort_inline-2.6.1.5.tar.gz

% cd snort_inline-2.6.1.5

On a besoin des bibliothèques de Netfilter et de la libpcap pour la capture :

% apt-get install libnetfilter-queue-dev libpcap0.8-dev

Comme Snort dépend de la libpcre (Perl Compatible Regular Expression) pour permettre l'emploi d'expressions régulières pour la recherche de motifs, on l'installe aussi :

% apt-get install libpcre3-dev

Enfin, Snort utilise la libdumbnet pour le premier décodage des paquets :

% apt-get install libdumbnet-dev

On récupère le patch qui va bien chez l'ami Pierre (parce que, sous Debian, on utilise dumbnet et pas dnet, qui n'a rien à voir) :

% wget http://www.wzdftpd.net/downloads/dumbnet.diff

% patch -p1 < dumbnet.diff

Puis, on lance la régénération du configure.in avec le patch dumbnet, puis le script configure qui va bien (support nfnetlink, utilisation de dumbnet et support des pthreads), pour enfin compiler, puis installer :

% ./autojunk.sh

% ./configure --enable-nfnetlink --with-dumbnet --enable-inline-init-failopen

% make

# make install

On copie la configuration :

# mkdir /etc/snort_inline

# cp -r etc/* /etc/snort_inline

Quand Snort et sa configuration sont installés, malheureusement tout ne fonctionne pas comme prévu. Plutôt que de vous faire croire que nous sommes dans le monde des Pokémons comme n'hésitent pas à le faire certaines personnes machiavéliques et dont je tairais le nom, nous allons voir étape par étape comment comprendre l'erreur et la régler.

La capture se faisant via Netfilter, il faut positionner une règle lui disant d'aller envoyer les paquets à nfqueue. Dans notre cas, nous faisons une installation sur une passerelle, tout passe par FORWARD :

# iptables -I FORWARD -j NFQUEUE

ip_tables: (C) 2000-2006 Netfilter Core Team

Du coup, nous pouvons démarrer Snort avec sa configuration par défaut :

# snort_inline -c /etc/snort_inline/snort_inline.conf

...

ERROR: OpenAlertFiles() => fopen() alert file /var/log/snort/snort_inline-full: No such file or directory

Fatal Error, Quitting..

Le répertoire /var/log/snort n'existant pas, on le crée :

# mkdir /var/log/snort

On relance :

# snort_inline -c /etc/snort_inline/snort_inline.conf

...

ERROR: Unable to open rules file: /etc/snort_inline/drop-rules/classification.config or /etc/snort_inline//etc/snort_inline/drop-rules/classification.config

Fatal Error, Quitting..

Ceci est dû au fichier classification.config qui n'existe pas dans le répertoire voulu. On va d'abord configurer la variable RULE_PATH (ligne 48) :

var RULE_PATH /etc/snort_inline

Enfin, il ne nous reste plus qu'à commenter toutes les lignes incluant des signatures à partir de la ligne 666 dans le fichier snort_inline.conf.

Par défaut, les signatures ne sont pas installées. Il existe un projet communautaire de signatures Snort du nom d'Emerging threats, qui distribue ses signatures via le site web http://www.emergingthreats.net/.

Nous allons récupérer toutes les signatures dans un seul fichier, téléchargeable à l'adresse :

http://www.emergingthreats.net/rules/emerging-all.rules

# wget http://www.emergingthreats.net/rules/emerging-all.rules

# mv emerging-all.rules /etc/snort_inline/

À la fin du fichier snort_inline.conf, on rajoute la ligne pour inclure ce fichier de signatures :

include $RULE_PATH/emerging-all.rules

Et là, quand on lance Snort, on peut enfin voir un message qui fait plaisir :

Initializing Network Interface eth0

Decoding Ethernet on interface eth0

Ne vous inquiétez pas, il ne décode pas depuis eth0, mais depuis NFQUEUE. L'astuce consiste à traduire ce qui vient de Netfilter en PCAP, afin de toucher le moins possible au code de Snort.

Pour tester, vous pouvez lancer un nmap et regarder /var/log/snort/alerts l'alerte arriver :

[**] [122:1:0] (portscan) TCP Portscan [**]

Si vous ne voyez rien, faites bien attention à l’endroit où vous capturez avec Netfilter. Dans le pire des cas, essayez de rajouter la règle de capture sur la chaîne INPUT :

# iptables -I INPUT -j NFQUEUE

Cependant, faites attention de ne surtout pas vous couper l'accès à la machine ! Dans le même ordre d'idée, il vaut mieux ne pas filtrer les flux sur l'interface loopback.

Évidemment, il reste encore des réglages à faire, que nous allons développer un peu plus loin. Mais, vous avez déjà une installation fonctionnelle vous permettant de tester.

3. La détection d'intrusion réseau

Maintenant que le paquet est arrivé, il y a toute une série d'opérations que Snort va faire afin d'empêcher une intrusion sur votre réseau.

3.1 La fragmentation des paquets

Si un paquet trop grand est émis sur le réseau (plus grand que le paramètre MTU), il va être fragmenté en plusieurs paquets, et envoyé en plusieurs morceaux. Cependant, le réassemblage ne se fera pas de la même façon suivant la pile du système d'exploitation sur lequel le NIDS fonctionne comparé au système cible. C'est-à-dire que le motif d'une attaque peut se retrouver dans plusieurs paquets qui ne se réassembleront pas pareil (en jouant sur l'overlapping), et ainsi l'attaquant contournera Snort.

 

fragmentation-attack

 

Le problème avec la fragmentation provient du fait que lorsque la RFC sur IP a été transformée en code, certaines parties n'étaient pas suffisamment détaillées. Cela a eu pour résultat d'avoir les systèmes d'exploitation implémentant de manière différente certains mécanismes permettant d'ailleurs à p0f ou à nmap de déduire le système d'exploitation uniquement avec quelques tests actifs ou passifs sur la pile.

Il faut bien comprendre que le système de détection d'intrusion n'est pas le système d'exploitation cible et que certains outils comme Fragroute (http://monkey.org/~dugsong/fragroute/) exploitent ces faiblesses.

Il y a plusieurs manière d'empêcher ce problème : Snort, à travers son préprocesseurs frag3, permet de créer des pseudo-paquets qui sont entièrement réassemblés à la manière du système d'exploitation cible configuré.

Une autre méthode consiste à empêcher complètement l'overlapping, car il n'est pas normal d'en avoir sur son réseau.

3.2 Le décodage

Une fois que nous sommes sûrs de récupérer les paquets réassemblés et que l'on arrive à capturer tous les flux réseau, il nous reste une étape importante : le décodage.

Il s'agit d'arriver à empêcher un attaquant de faire de l'évasion de signatures en exploitant les faiblesses des applications.

Par exemple, si nous prenons une signature faisant de la reconnaissance d'attaque en se basant sur une URL web, la signature contiendra le motif dans l'option uricontent comme ceci :

uricontent:"/cmd.php?"

Dans le cas où la machine ciblée par l'attaque n'utilise pas le serveur web Apache mais IIS, le signe backslash « \ » pourra être utilisé à la place de slash « / » et, du coup, la signature pourra être contournée simplement parce que le contenu des paquets ne correspondra pas à la signature.

Cela s'applique aussi à l'UTF-8, où les signatures sont en général écrites dans le jeu de caractères ISO-8859-1 et, du coup, la correspondance ne se fera pas... sauf par l'application ciblée et pouvant elle décoder ces caractères et du coup subir l'attaque.

En langage Snort, les décodeurs sont appelés préprocesseurs et sont activables directement depuis la configuration. Ils ont aussi un sens d'activation logique, qui suit ce qui est défini dans cette configuration.

Il y a aussi un sens selon lequel ils doivent être activés. Regardons de plus près 3 préprocesseurs :

 

Nom

Lignes de code

Description

Frag3

4479

Réassembleur de flux, détection d'attaques concernant la fragmentation...

Stream5

11292

Suivi de connexion (tcp, udp et icmp), envoi d'alertes sur des attaques ciblant des anomalies sur les protocoles qu'il suit...

http_inspect

3497

Normalisation des URI, création du buffer uricontent pour récupérer depuis les signatures uniquement la requête. Envoi d'alertes ciblant http...

Le nombre de lignes de codes est donné à titre indicatif pour que vous compreniez la complexité de ces différents modules (et donc de leurs vulnérabilités potentielles ;)).

Le sens d'activation de ces différents décodeurs est important, tout simplement parce qu'il y a une chaîne de dépendances : on activera d'abord frag3, puis stream5 et enfin http_inspect. Il n'est pas possible de faire correctement de la récupération d'URI si le flux n'a pas tout d'abord été réassemblé, puisque nous sommes dans l'état où nous recevons le PUSH | ACK dans le sens client->serveur.

Comme dit un peu plus haut, les décodeurs se configurent directement depuis le fichier de configuration de Snort Inline.

3.3 La recherche de motifs

Rechercher une chaîne de caractères n'est pas si simple. Il existe un tas d'algorithmes qui sont en général utilisés par les applications type éditeur de texte. Linux possède aussi une API de recherche de texte (TextSearch API) et, d'ailleurs, Netfilter peut manipuler des paquets réseau par rapport aux motifs qu'ils contiennent.

Il peut être utile sur une machine limitée de changer l'algorithme que Snort utilise. Par exemple, dans le fichier de configuration, on peut activer le mode de recherche utilisant le moins de mémoire possible en ajoutant la ligne :

config detection: search-method lowmem

Par défaut, Snort utilisera l'algorithme Aho-Corasick NFA (L'algo Aho-Corasick standard ayant pour complexité O(|X|+ n)). Mais, il est possible d'en changer. Voici la liste des choix possibles :

 

Nom

Description

Mémoire consommée

Performances

ac

Aho-Corasick complet

élevée

Le meilleur de tous

ac-std

Aho-Corasick Standard

moyenne

élevées

ac-bnfa

Aho-Corasick NFA

faible

élevées

acs

Aho-Corasick Sparse

faible

moyennes

ac-banded

Aho-Corasick Banded

faible

moyennes

ac-sparsebands

Aho-Corasick Sparse-Banded

faible

élevées

lowmem

Utilisation faible de la mémoire

faible

faibles

Beaucoup de choix algorithmiques sont là tout simplement parce que, Snort étant un logiciel libre, c'est tout naturellement que les chercheurs en détection d'intrusion l'ont modifié et y ont contribué dans le cadre de leurs publications.

Dans une signature, cette recherche de motifs se fait à travers l'option content. Mais, Snort permet aussi de faire de la recherche de motifs grâce aux fameuses Perl Compatible Regular Expressions (PCRE), qui s'utilisent via l'option pcre.

Du coup, vient la question : « Comment Snort gère la recherche de texte entre les algorithmes standards et ceux de PCRE ? ».

Tout d'abord, faire des expressions rationnelles sur des paquets réseau est extrêmement coûteux en performances.

La recherche de motifs se fait dans le fichier fpcreate.c et Snort cherche d'abord à récupérer les motifs les plus longs dans les signatures (fonction fpAddLongestContent()). Le trafic passe ensuite dans une phase de préqualification appelée « MPSE ». Ici, les signatures sont testées de manière séquentielle.

Tant que le trafic n'a pas passé cette phase de MPSE, l'option pcre est ignorée. Une fois que la phase est passée, il ne reste que très peu de signatures à tester (généralement une ou deux) et on peut donc appliquer directement l'algorithme DFA ou NFA que PCRE appliquera.

Si les recherches de motifs efficaces vous passionnent, il vous faut alors un site passionnant sur ce sujet, et je ne peux que vous recommander d'aller plus loin grâce au travail formidable sur ce sujet de Thierry Lecroq (http://www-igm.univ-mlv.fr/~lecroq/).

3.4 Les alertes

Lorsque votre Snort tourne, il ne faut en général pas longtemps pour que vous ayez des alertes (et si ce n'est pas le cas, Nessus est votre ami).

Les alertes sont stockées dans un fichier plat, qui, sur beaucoup de configurations, est /var/log/snort/alerts, mais qui, pour le cas de la version de Snort que nous utilisons, est configuré par défaut pour aller dans output alert_full: snort_inline-full.

Dans le snort_inline.conf, tout est configuré par les directives output et deux modes sont activés :

output alert_full: snort_inline-full                                            

output alert_fast: snort_inline-fast

Le mode full enregistrera toutes les en-têtes des paquets, tandis que fast imprimera tout sur une seule ligne au moyen de quelques suppressions d'informations.

On retrouve ces fichiers dans /var/log/snort/.

Si on regarde les alertes générées, on retrouvera deux types d'alertes.

Les alertes de signatures :

[**] [1:2466:7] NETBIOS SMB-DS IPC$ unicode share access [**]

[Classification: Generic Protocol Command Decode] [Priority: 3]

02/01-08:42:08.819519 88.189.196.218:60398 -> 88.191.82.101:445

TCP TTL:59 TOS:0x0 ID:35278 IpLen:20 DgmLen:136 DF

***AP*** Seq: 0xECB71446 Ack: 0xD014FF37 Win: 0xFA90 TcpLen: 20

et les alertes des préprocesseurs :

[**] [122:1:0] (portscan) TCP Portscan [**]

[Priority: 3]

11/29-20:08:44.417053 80.93.212.186 -> 88.191.82.101

PROTO:255 TTL:0 TOS:0x0 ID:0 IpLen:20 DgmLen:163 DF

La différence entre les deux est que dans le cas de l'alerte par signature, si l'on estime que l'alerte est un faux positif, il suffit de repérer le Snort ID de la signature (sur la première ligne, c'est le deuxième nombre entre crochets ; dans notre cas, c'est le numéro 2466) et d'aller éditer les signatures pour rajouter un # devant la ligne de l'alerte.

Dans le deuxième cas, lorsqu'il s'agit d'une alerte de préprocesseur, on voit son nom apparaître sur la première ligne entre parenthèses, avant la description de l'attaque. Il s'agit ici du module de détection de scan de ports portscan.

Cependant, il faut faire très attention avant d'enlever les signatures que vous estimez ne pas être une attaque : il ne faut pas que ça joue contre vous et que, du coup, vous manquiez de réelles attaques. Il vaut mieux améliorer la signature et envoyer vos modifications au projet Emerging threats.

Ce qui peut être compliqué, c'est que, dans certains cas, la signature concerne bien une attaque, mais que, dans votre cas bien précis, ce ne soit qu'un mode de fonctionnement du réseau de votre entreprise (oui, toi qui me lis et qui transmets par tes applications le contenu de tes documents par URL et qui reçoit les alertes parce que l'URL est > 1024 caractères, je pense à toi !).

Si on regarde la signature de notre première alerte, nous avons ceci :

winiepot:~# grep -n sid:2466 /etc/snort/rules/*

/etc/snort/rules/netbios.rules:28:alert tcp $EXTERNAL_NET any -> $HOME_NET 445 (msg:"NETBIOS SMB-DS IPC$ unicode share access"; flow:established,to_server; content:"|00|"; depth:1; content:"|FF|SMBu"; within:5; distance:3; byte_test:1,&,128,6,relative; pcre:"/^.{27}/R"; byte_jump:2,7,little,relative; content:"I|00|P|00|C|00 24 00 00 00|"; distance:2; nocase; flowbits:set,smb.tree.connect.ipc; classtype:protocol-command-decode; sid:2466; rev:7;)

La complexité de la règle nous montre qu'il y a vraiment peu de chances pour que ce soit un positif.

Pour tous vous dire, il s'agit de la machine principale du chapitre honeynet Français, et un Nepenthes tourne dessus pour simuler des vulnérabilités Windows et récupérer ainsi des virus et vérifier le niveau de détection de ClamAV, ainsi que des évolutions des virus. Il est donc normal qu'il y ait ce type d'alertes.

En ce qui concerne la suppression de faux positifs sur les préprocesseurs, cela devient un peu plus compliqué. Il faut en général se renseigner dans la documentation sur le type d'alertes générées par le préprocesseur, et, dans le cas où nous sommes sûrs d'avoir un faux positif, le désactiver dans la configuration de Snort. Par exemple, sur smtp, la configuration est :

preprocessor smtp: \

  ports { 25 } \

  inspection_type stateful \

  normalize cmds \

  normalize_cmds { EXPN VRFY RCPT } \

  alt_max_command_line_len 260 { MAIL } \

  alt_max_command_line_len 300 { RCPT } \

  alt_max_command_line_len 500 { HELP HELO ETRN } \

  alt_max_command_line_len 255 { EXPN VRFY }

Chaque ligne est une option que l'on peut supprimer ou modifier en fonction de notre environnement : si jamais votre entreprise a un nom de domaine tellement long et des noms d'utilisateurs tellement longs aussi, vous aurez tout à gagner à modifier la valeur de alt_max_command_line_len 300 { RCPT }, sous peine d'avoir une alerte pour chaque courriel reçu.

Certes, ce cas-là est un peu extrême, mais songer d'abord à paramétrer les préprocesseurs correspondant aux alertes que vous recevez, afin d'écarter au maximum les faux positifs.

4. Les signatures

Si l'on regarde d'un peu plus près les signatures, elles ont un format bien spécifique. Prenons une signature pour l'exemple :

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET WEB Cacti SQL Injection Vulnerability tree.php leaf_id UPDATE"; flow:established,to_server; uricontent:"tree.php?"; nocase; uricontent:"leaf_id="; nocase; uricontent:"UPDATE"; nocase; pcre:"/.+UPDATE.+SET/Ui"; classtype:web-application-attack; reference:cve,CVE-2008-0785; reference:bugtraq,27749; sid:2007897; rev:2;)

Il s'agit ici de détecter une injection SQL sur l'application Cacti.

Une signature est divisée en deux grandes sections :

- l’en-tête : alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS

- l’option : (msg:... et tout le reste

L'en-tête décrit à partir de quel moment il faut aller plus loin dans l'introspection du paquet. Par exemple, ici, on cherche une vulnérabilité qui sera exploitée sur le protocole tcp depuis le réseau externe ($EXTERNAL_NET), depuis n'importe quel port (le premier any) vers (->) les serveurs HTTP ($HTTP_SERVERS) écoutant sur les ports classiques HTTP ($HTTP_PORTS).

Ensuite, nous regardons le sens des flux. Il faut qu'il soit connecté au sens TCP du terme. En général, c'est quand on a les flags PUSH et ACK (flow:established,to_server;). Il faut que l'URL contienne tree.php?, leaf_id=, UPDATE et UPDATE avec SET plus loin (que l'on recherche en Aho-Corasick). Le nocase veut simplement dire que l'on cherche ce motif quelle que soit la casse.

Enfin, il ne nous reste plus qu'à classifier et mettre des informations. Il s'agit d'une attaque sur une application web, possédant un CVE et un numéro de bugtraq (vous permettant de retrouver un éventuel exploit pour tester vos applications).

Le rev:2 nous montre qu'il y a eu deux révisions sur la règle.

Vous pouvez bien sûr vous inspirer d'autres signatures pour faire les vôtres, et participer au projet Emerging threats pour envoyer vos signatures.

Une fonctionnalité du mode Inline est de pouvoir supprimer les attaques, et cela ne peut se faire que grâce à la fonction drop, que l'on met à la place de alert en tout début de règle. Ainsi, Netfilter fera le choix de bloquer le paquet non plus sur des simples états, destinations où sources, mais sur de véritables intrusions qui n'atteindront même pas les machines cibles.

5. Pour aller plus loin

Maintenant que vous savez utiliser Snort et comprenez quelques-uns des rouages de la détection d'intrusion, je ne peux que vous recommander d'aller un petit peu plus loin avec la sélection des paquets et la gestion des alertes.

Pour la sélection des paquets, puisque Netfilter permet de faire de la sélection basée sur l'API TextSearch du noyau Linux, nous n’allons envoyer dans la NFQUEUE que les paquets qui auront été choisis parce que leur texte est disponible directement dans les signatures de Snort.

Le projet FWSnort (http://cipherdyne.org/fwsnort/) permet de traduire les signatures de Snort en règles Netfilter avec cette sélection de paquet. Malheureusement, il n'est pas possible d'avoir toutes les signatures par ce biais, mais c'est cependant très pratique quand on laisse le noyau faire la recherche de motifs à la place de Snort.

En ce qui concerne la gestion des d'alertes, il existe le projet Prelude IDS (http://www.prelude-ids.org) qui permet de normaliser les alertes que Snort envoie au format IDMEF (Intrusion Detection Message Exchange Format). Snort peut ainsi profiter de l'interface graphique Prewikka, et coupler ses informations à d'autres logiciels de détection d'intrusions comme OSSEC, voire d'autres Snort à différents endroits du réseau afin d'agréger les alertes et aussi de pouvoir les corréler et récupérer des alertes plus pertinentes.

6. Conclusion

Snort peut se mettre en place assez facilement, et rapidement détecter des intrusions comme des comportements sur votre réseau. D'autant plus qu'en mode Inline Snort peut bénéficier de tous les avantages de Netfilter. Cependant, il ne faut pas négliger l'affinage des règles pour arriver petit à petit à un système qui vous remonte des alertes de façon assez fiable.

 



Article rédigé par

Par le(s) même(s) auteur(s)

Duke Nukem 3D : un outil valgrind adapté à la lecture d’appels systèmes

Magazine
Marque
GNU/Linux Magazine
Numéro
206
Mois de parution
juillet 2017
Spécialité(s)
Résumé

On ne présente plus ni Duke Nukem 3D, ni Valgrind. Les deux outils sont très complémentaires : d’un côté, nous avons un émulateur de processeur RISC qui permet de faire une abstraction des instructions d’origine, d’un autre vous avez un jeu d’arcade qui permet de supporter de longues heures passées sur le premier ! Alors, pourquoi ne pas être dans l’honnêteté intellectuelle la plus complète et fusionner les deux outils afin de rendre le debugging great again ?

Détection d’attaques avec Splunk

Magazine
Marque
MISC
Numéro
89
Mois de parution
janvier 2017
Spécialité(s)
Résumé

Cet article a pour but de vous présenter comment un système d’analyse de données machine tel que Splunk peut être utile pour réagir efficacement à une attaque en cours. Nous prenons l’exemple pour lequel Brian Krebs a servi de preuve de concept pour le botnet Mirai avant que ce dernier attaque les serveurs DNS de Dyn empêchant l’accès à des sites connus tels que GitHub, Twitter, Netflix ou encore Airbnb.

Les derniers articles Premiums

Les derniers articles Premium

Quarkus : applications Java pour conteneurs

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous