Lea Linux - Contributions [fr]

Utilisateur:Amnesiak

2010-10-27T11:28:42Z

Amnesiak : /* Sites utiles */

Bienvenue sur ma page !

Si vous débutez dans la sécurité informatique, pensez à visiter les liens suivants :

* [http://www.uniformed.org Uniformed.org] publication d'article concernant la sécurité (site en anglais)
* [http://rootkit.com Rootkit.com] publication d'article concernant la sécurité (site en anglais)
* [http://openbsd.org OpenBSD.org] un très bon système d'exploitation dont le but principal est la sécurité (site en anglais)
* ... et la liste n'est pas exhaustive

== Liste d'artciles ==
===Magazines===

Ceci est une liste sélective et qualitative de magazines francophones sur la sécurité :

* MISC : http://www.miscmag.com
* Hackin9 : http://www.hakin9.org

===Liens vers certains articles disponibles en ligne===

* Très nombreux articles de Christophe Grenier publiés dans GNU/Linux Magazine France, MISC, Pirates Mag, HoneyNet : [http://www.cgsecurity.org/wiki/Articles http://www.cgsecurity.org/wiki/Articles].
* '''La méthode EBIOS''', par Nicolas Mayer et Jean-Philippe Humbert, MISC n°27 : [http://www.cases.public.lu/functions/search/resultHighlight/index.php?linkId=3&SID=f78a58d3444b9f672fc8f3fc76616c02 ici]

== Sites utiles ==
* OpenBSD France: des tutoriaux, une mailing list et un joli canal IRC : http://openbsd-france.org
* Groupe d'utilisateurs francophone des technologies Cisco : http://cisco.rezalfr.org

Tarpit avec iptables

2010-10-27T11:26:56Z

Amnesiak : /* Activer le module TARPIT dans le noyau */

[[Category:Sécurité]]

= tarpit avec iptables =
Par [[Utilisateur:amnesiak|Tony]]

Les tarpits (de l'anglais "tar", goudron, et "pit", une fosse) font partie des mécanismes de défense contre la propagation des vers, spams et autres. Le concept vient de [http://labrea.sourceforge.net/ LaBrea Tarpit] développé par Tom Liston.

==Principe d'utilisation des tarpits==

Les tarpits servent à ralentir les connexions des personnes qui se branchent dessus. Le but étant de garder la connexion active le plus longtemps possible du côté de l'attaquant. Dans un monde où les tarpits seraient généralisés, un attaquant devrait alors ruser et ne pourrait plus s'attaquer à une IP au hasard pour faire propager des vers par exemple (la problèmatique de générer une IP à attaquer aléatoirement devrait disparaître avec l'IP v6, en effet, l'espace d'adresse sera moins saturé donc il y aura beaucoup moins de chance que l'adresse soit une adresse utilisée).

Quand Tom Liston présente pour la première fois la notion de tarpits, il explique qu'il cherchait une parade au vers CodeRed. Il constata qu'en général quand on se voit attribuer un bloc d'adresses publiques, il est rare de tout utiliser. Donc il pensa que tout trafic vers ses IP publiques non attribuées ne pouvait être qu'un trafic illicite. Il commença alors à écrire un petit service qui écoutait sur le port 80 de ces machines (le port où CodeRed attaquait) et qui répondait au SYN par un SYN/ACK avec une valeur de MSS très petite, ce qui avait pour effet de ralentir le vers (il ne pouvait plus envoyer que des paquets de petite taille, de plus, le service n'écoutait plus la session ensuite).

Finalement, le principe de tarpit pouvait être généralisé à n'importe quel port TCP. Il est conseillé de l'utiliser que sur des ports où l'on est sûr d'avoir aucun trafic "légal". Par exemple, le port 113, où identd est lié, est utilisé par certains serveurs [[Fiches:Internet-fichexchat|IRC]] pour connaître le login de l'utilisateur. Si on "tarpitte" ce port, le serveur n'aura jamais sa réponse et l'utilisateur n'obtiendra jamais sa connexion. Au final, il faudra donc peser le pour et le contre de cette technique. Sur une IP qui n'est pas attribuée, on pourra "tarpiter" tous les ports sans problème, mais sur une IP attribuée, il faudra bien faire attention à ne pas être trop agressif dans les règles au risque de réduire connectivité du réseau.

==L'implémentation dans le noyau Linux et dans Netfilter==

==L'installation==

Sous Gentoo, il est possible d'activer les extensions d'iptables directement à partir de l'ebuild, on procéde de la manière suivante :
<div class="code">
USE="extensions" emerge iptables
</div>

Néanmoins, le noyau par défaut n'est pas patché avec les extensions, il faut donc les récuperer sur le FTP de Netfilter : http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/
Le mieux est d'y prendre la version la plus récente. Cette archive tar contient bien plus que l'extension tarpit. Il nous est alors offert deux choix pour activer le tarpit.

===Utiliser le script "run-me" patch-o-matic===

Une fois que vous avez récupéré l'archive des extensions sur le site de Netfilter, vous pouvez décompresser l'archive tar.
<div class="code">
# dans mon cas, j'avais la version du 16 janvier 2007
tar xvzf patch-o-matic-ng-20070116.tar.bz2
cd patch-o-matic-ng-20070116
</div>

Et là, il suffit simplement de lancer le script runme :
<div class="code">
./runme
</div>

Celui-ci vous pose quelques questions et rajoute finalement l'option TARPIT dans le noyau.

===Faire l'installation de l'extension tarpit à l'intérieur du noyau à la main===
Vous n'avez pas besoin de faire cette étape si vous avez déjà appliqué le patch avec la technique présentée au desssus.

Dans mon cas, je pouvais activer les extensions dans iptables sans avoir à patcher (c'était en natif dans mon système), donc je ne voulais pas avoir à recompiler iptables. De plus, je n'avais guère envie de rajouter toutes les extensions à mon noyau.

<span style="color:red;"> Attention, ce qui va suivre n'est pas la façon recommandée de procéder, cela marche chez l'auteur, mais ce n'est pas une méthode officielle suppportée.</span>

La procédure suivante est pour un noyau 2.6. Il ne tiendra qu'à vous de l'adapter si vous voulez tester avec une autre version du noyau.

Je copie d'abord le module tarpit dans le noyau.
<div class="code">
#ici, je suis à la racine de l'archive
#(il faut que /usr/src/linux corresponde au chemin des sources de votre noyau)
cp patchlets/TARPIT/linux-2.6/net/ipv4/netfilter/ipt_TARPIT.c /usr/src/linux/net/ipv4/netfilter
</div>

Et c'est là que c'est "sale", car on va ajouter les patch à la main sur les fichiers du noyau :
<div class="code">
cat patchlets/TARPIT/linux-2.6/net/ipv4/netfilter/Kconfig.ladd
<span style="color:blue;"><nowiki>config IP_NF_TARGET_TARPIT
tristate 'TARPIT target support'
depends on IP_NF_FILTER
help
Adds a TARPIT target to iptables, which captures and holds
incoming TCP connections using no local per-connection resources.
Connections are accepted, but immediately switched to the persist
state (0 byte window), in which the remote side stops sending data
and asks to continue every 60-240 seconds. Attempts to close the
connection are ignored, forcing the remote side to time out the
connection in 12-24 minutes.

This offers similar functionality to LaBrea
<http://www.hackbusters.net/LaBrea/> but doesn't require dedicated
hardware or IPs. Any TCP port that you would normally DROP or REJECT
can instead become a tarpit. </nowiki></span>
</div>

On voit là le contenu du patch, il suffit d'ouvrir le fichier '''/usr/src/linux/net/ipv4/netfilter/Kconfig''' avec votre éditeur préféré et de rajouter les lignes en bleu au dessus. Collez le en dessous de la première entrée de type '''config'''.

On ouvre ensuite '''/usr/src/linux/net/ipv4/netfilter/Makefile''' et on se place à la ligne contenant :
<div class="code">
obj-$(CONFIG_IP_NF_TARGET_REJECT) += ipt_REJECT.o
</div>

On rajoute en dessous la ligne :
<div class="code">
obj-$(CONFIG_IP_NF_TARGET_TARPIT) += ipt_TARPIT.o
</div>

Maintenant, tout est prêt, on va pouvoir activer le TARPIT dans les options du noyau.

===Activer le module TARPIT dans le noyau===

On lance le make xconfig ou le make menuconfig de notre noyau et on va dans les menus suivants :
<div class="code">
Networking ->
Networking options ->
Network packet filtering (replaces ipchains) ->
IP: Netfilter Configuration ->
TARPIT target support
</div>

Il est conseillé de le mettre en module (ne serait-ce que parce que l'on aura pas besoin de redémarrer le noyau pour pouvoir l'installer).

Ensuite :
<div class="code">
make && make modules_install
</div>

Vous pouvez faire un modprobe sur le module pour vérifier qu'il est bien installé.
<div class="code">
modprobe ipt_TARPIT
</div>

==La mise en place==

Il suffit de se servir d'iptables en créant des règles comme on le ferait normalement, mais en utilisant comme cible "TARPIT".
<div class="code">
# une petite règle pour ralentir les spammeurs
iptables -A INPUT -p tcp --dport smtp -j TARPIT
</div>

On peut convertir un ensemble de règle de ce type (attention, très agressif, tous les ports non explicitement autorisés vont utiliser un tarpit) :
<div class="code">
# ...
# ici plein de règles avec des ACCEPT
# ex: iptables -A INPUT -i mon_interface -p TCP -s ma_source --dport mon_port -j ACCEPT
# ...
iptables -A INPUT -p tcp -j DROP
</div>

en
<div class="code">
# ...
# les mêmes règles
# ...
iptables -A INPUT -p tcp -j TARPIT
</div>

On peut aussi être plus souple. Imaginons que nous souhaitons autoriser les accès SSH à une machine que par un groupe de machines défini de manière explicite. Tout accès non listé est alors non autorisé (le serveur SSH étant souvent attaqué par des "zombies" qui tentent la force brute pour trouver un compte valide). On aurait alors une règle de la forme :

<div class="code">
iptables -A INPUT -i ppp0 -p TCP -s hote1 --dport ssh -j ACCEPT
iptables -A INPUT -i ppp0 -p TCP -s hote2 --dport ssh -j ACCEPT
iptables -A INPUT -i ppp0 -p TCP -s hote3 --dport ssh -j ACCEPT
iptables -A INPUT -i ppp0 -p TCP --dport ssh -j TARPIT
</div>

<br/>
<br/>
'''<b>[[Reseau-index|@ Retour à la rubrique Réseau et sécurité]]</b>'''

{{Copy|2007, 2010|[[Utilisateur:amnesiak|Tony Cheneau]]|FDL}}

Tarpit avec iptables

2010-10-27T09:55:34Z

Amnesiak : Page créée avec « Category:Sécurité = tarpit avec iptables = Par Tony Les tarpits (de l'anglais "tar", goudron, et "pit", une fosse) font partie des mécanisme... »

[[Category:Sécurité]]

= tarpit avec iptables =
Par [[Utilisateur:amnesiak|Tony]]

Les tarpits (de l'anglais "tar", goudron, et "pit", une fosse) font partie des mécanismes de défense contre la propagation des vers, spams et autres. Le concept vient de [http://labrea.sourceforge.net/ LaBrea Tarpit] développé par Tom Liston.

==Principe d'utilisation des tarpits==

Les tarpits servent à ralentir les connexions des personnes qui se branchent dessus. Le but étant de garder la connexion active le plus longtemps possible du côté de l'attaquant. Dans un monde où les tarpits seraient généralisés, un attaquant devrait alors ruser et ne pourrait plus s'attaquer à une IP au hasard pour faire propager des vers par exemple (la problèmatique de générer une IP à attaquer aléatoirement devrait disparaître avec l'IP v6, en effet, l'espace d'adresse sera moins saturé donc il y aura beaucoup moins de chance que l'adresse soit une adresse utilisée).

Quand Tom Liston présente pour la première fois la notion de tarpits, il explique qu'il cherchait une parade au vers CodeRed. Il constata qu'en général quand on se voit attribuer un bloc d'adresses publiques, il est rare de tout utiliser. Donc il pensa que tout trafic vers ses IP publiques non attribuées ne pouvait être qu'un trafic illicite. Il commença alors à écrire un petit service qui écoutait sur le port 80 de ces machines (le port où CodeRed attaquait) et qui répondait au SYN par un SYN/ACK avec une valeur de MSS très petite, ce qui avait pour effet de ralentir le vers (il ne pouvait plus envoyer que des paquets de petite taille, de plus, le service n'écoutait plus la session ensuite).

Finalement, le principe de tarpit pouvait être généralisé à n'importe quel port TCP. Il est conseillé de l'utiliser que sur des ports où l'on est sûr d'avoir aucun trafic "légal". Par exemple, le port 113, où identd est lié, est utilisé par certains serveurs [[Fiches:Internet-fichexchat|IRC]] pour connaître le login de l'utilisateur. Si on "tarpitte" ce port, le serveur n'aura jamais sa réponse et l'utilisateur n'obtiendra jamais sa connexion. Au final, il faudra donc peser le pour et le contre de cette technique. Sur une IP qui n'est pas attribuée, on pourra "tarpiter" tous les ports sans problème, mais sur une IP attribuée, il faudra bien faire attention à ne pas être trop agressif dans les règles au risque de réduire connectivité du réseau.

==L'implémentation dans le noyau Linux et dans Netfilter==

==L'installation==

Sous Gentoo, il est possible d'activer les extensions d'iptables directement à partir de l'ebuild, on procéde de la manière suivante :
<div class="code">
USE="extensions" emerge iptables
</div>

Néanmoins, le noyau par défaut n'est pas patché avec les extensions, il faut donc les récuperer sur le FTP de Netfilter : http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/
Le mieux est d'y prendre la version la plus récente. Cette archive tar contient bien plus que l'extension tarpit. Il nous est alors offert deux choix pour activer le tarpit.

===Utiliser le script "run-me" patch-o-matic===

Une fois que vous avez récupéré l'archive des extensions sur le site de Netfilter, vous pouvez décompresser l'archive tar.
<div class="code">
# dans mon cas, j'avais la version du 16 janvier 2007
tar xvzf patch-o-matic-ng-20070116.tar.bz2
cd patch-o-matic-ng-20070116
</div>

Et là, il suffit simplement de lancer le script runme :
<div class="code">
./runme
</div>

Celui-ci vous pose quelques questions et rajoute finalement l'option TARPIT dans le noyau.

===Faire l'installation de l'extension tarpit à l'intérieur du noyau à la main===
Vous n'avez pas besoin de faire cette étape si vous avez déjà appliqué le patch avec la technique présentée au desssus.

Dans mon cas, je pouvais activer les extensions dans iptables sans avoir à patcher (c'était en natif dans mon système), donc je ne voulais pas avoir à recompiler iptables. De plus, je n'avais guère envie de rajouter toutes les extensions à mon noyau.

<span style="color:red;"> Attention, ce qui va suivre n'est pas la façon recommandée de procéder, cela marche chez l'auteur, mais ce n'est pas une méthode officielle suppportée.</span>

La procédure suivante est pour un noyau 2.6. Il ne tiendra qu'à vous de l'adapter si vous voulez tester avec une autre version du noyau.

Je copie d'abord le module tarpit dans le noyau.
<div class="code">
#ici, je suis à la racine de l'archive
#(il faut que /usr/src/linux corresponde au chemin des sources de votre noyau)
cp patchlets/TARPIT/linux-2.6/net/ipv4/netfilter/ipt_TARPIT.c /usr/src/linux/net/ipv4/netfilter
</div>

Et c'est là que c'est "sale", car on va ajouter les patch à la main sur les fichiers du noyau :
<div class="code">
cat patchlets/TARPIT/linux-2.6/net/ipv4/netfilter/Kconfig.ladd
<span style="color:blue;"><nowiki>config IP_NF_TARGET_TARPIT
tristate 'TARPIT target support'
depends on IP_NF_FILTER
help
Adds a TARPIT target to iptables, which captures and holds
incoming TCP connections using no local per-connection resources.
Connections are accepted, but immediately switched to the persist
state (0 byte window), in which the remote side stops sending data
and asks to continue every 60-240 seconds. Attempts to close the
connection are ignored, forcing the remote side to time out the
connection in 12-24 minutes.

This offers similar functionality to LaBrea
<http://www.hackbusters.net/LaBrea/> but doesn't require dedicated
hardware or IPs. Any TCP port that you would normally DROP or REJECT
can instead become a tarpit. </nowiki></span>
</div>

On voit là le contenu du patch, il suffit d'ouvrir le fichier '''/usr/src/linux/net/ipv4/netfilter/Kconfig''' avec votre éditeur préféré et de rajouter les lignes en bleu au dessus. Collez le en dessous de la première entrée de type '''config'''.

On ouvre ensuite '''/usr/src/linux/net/ipv4/netfilter/Makefile''' et on se place à la ligne contenant :
<div class="code">
obj-$(CONFIG_IP_NF_TARGET_REJECT) += ipt_REJECT.o
</div>

On rajoute en dessous la ligne :
<div class="code">
obj-$(CONFIG_IP_NF_TARGET_TARPIT) += ipt_TARPIT.o
</div>

Maintenant, tout est prêt, on va pouvoir activer le TARPIT dans les options du noyau.

===Activer le module TARPIT dans le noyau===

On lance le make xconfig ou le make menuconfig de notre noyau et on va dans les menus suivants :
<div class="code">
Networking ->
Networking options ->
Network packet filtering (replaces ipchains) ->
IP: Netfilter Configuration ->
TARPIT target support
</div>

Il est conseillé de le mettre en module (ne serait-ce que parce que l'on aura pas besoin de redémarré le noyau pour pouvoir l'installer).

Ensuite :
<div class="code">
make && make modules_install
</div>

Vous pouvez faire un modprobe sur le module pour vérifier qu'il est bien installé.
<div class="code">
modprobe ipt_TARPIT
</div>

==La mise en place==

Il suffit de se servir d'iptables en créant des règles comme on le ferait normalement, mais en utilisant comme cible "TARPIT".
<div class="code">
# une petite règle pour ralentir les spammeurs
iptables -A INPUT -p tcp --dport smtp -j TARPIT
</div>

On peut convertir un ensemble de règle de ce type (attention, très agressif, tous les ports non explicitement autorisés vont utiliser un tarpit) :
<div class="code">
# ...
# ici plein de règles avec des ACCEPT
# ex: iptables -A INPUT -i mon_interface -p TCP -s ma_source --dport mon_port -j ACCEPT
# ...
iptables -A INPUT -p tcp -j DROP
</div>

en
<div class="code">
# ...
# les mêmes règles
# ...
iptables -A INPUT -p tcp -j TARPIT
</div>

On peut aussi être plus souple. Imaginons que nous souhaitons autoriser les accès SSH à une machine que par un groupe de machines défini de manière explicite. Tout accès non listé est alors non autorisé (le serveur SSH étant souvent attaqué par des "zombies" qui tentent la force brute pour trouver un compte valide). On aurait alors une règle de la forme :

<div class="code">
iptables -A INPUT -i ppp0 -p TCP -s hote1 --dport ssh -j ACCEPT
iptables -A INPUT -i ppp0 -p TCP -s hote2 --dport ssh -j ACCEPT
iptables -A INPUT -i ppp0 -p TCP -s hote3 --dport ssh -j ACCEPT
iptables -A INPUT -i ppp0 -p TCP --dport ssh -j TARPIT
</div>

<br/>
<br/>
'''<b>[[Reseau-index|@ Retour à la rubrique Réseau et sécurité]]</b>'''

{{Copy|2007, 2010|[[Utilisateur:amnesiak|Tony Cheneau]]|FDL}}

VLAN Bridging ebtables

2010-10-26T15:24:56Z

Amnesiak : Page créée avec « Category:Sécurité = VLAN et Bridging = Par Jiel et Tony ==La topologie de notre réseau== Image:Topologie-vlan.png ... »

[[Category:Sécurité]]

= VLAN et Bridging =
Par [[Utilisateur:Jiel|Jiel]] et [[Utilisateur:amnesiak|Tony]]

==La topologie de notre réseau==

[[Image:Topologie-vlan.png]]

===Explication sur la topologie===

On a ici deux sous réseaux de machines ne gérant pas les VLAN TAG (ou du moins, on ne l'a pas activé). On les appelera ici ENSEIGNANTS et ETUDIANTS. Les machines de ces réseaux seront nommées alors ENS1, ENS2, ... et ETU1, ETU2, ...

On a un réseau hétérogène de machines et matériel (switchs, routeurs) gérant les VLAN TAG, appelons le LE MONDE.

La machine qui sert de noeuds entre tous ces réseaux sera appelée LE CENTRE.

LE CENTRE sera ici sous GNU/Linux, il devra être configuré pour gérer les VLAN (norme IEEE 802.1Q) et les ponts (la norme 802.1D Ethernet Bridging).

ENSEIGNANTS et ETUDIANTS peuvent communiquer avec LE MONDE. Ils sont alors associé à deux VLAN distincts. Ils sont chacun branché à deux ports physiques distincts de LE CENTRE. On verra plus tard, que l'on pourra choisir de les faire communiquer, ou non.

===Pourquoi vouloir procéder ainsi ?===
On peut apprécier le fait que d'un coté, on ait un réseau ENSEIGNANTS ou ETUDIANTS, où il n'y a pas les VLAN, et donc qui n'ont pas besoin de configuration matérielle ou logicielle spéciale, et de l'autre coté, LE MONDE, qui lui gère des VLAN. Le réseau LE MONDE bénéficie alors de tous les avantages de la technologie associé aux VLAN. Comme par exemple, la possibilité de connecter de manière logique deux réseaux physiques distincts ou d'éviter à avoir à doubler le matériel afin d'avoir plusieurs réseaux séparés dans les mêmes locaux.

Dans notre cas, on peut aussi voir ça comme la possibilité d'ajouter de manière transparente de nouvelles salles contenant des machines pour les enseignants ou les étudiants et les rajouter dans le même VLAN afin qu'ils puissent communiquer de manière transparente ensemble.

===Quel est le bénéfice réel pour la sécurité ?===

Comme vu précédemment, on peut séparer un réseau physique en plusieurs réseaux logiques. Cela permet entre autres de limiter l'impact de la propagation d'un vers ou les possibilités d'écoute sur un réseau. Un membre du réseau ETUDIANTS ne pourra pas sniffer les paquets du réseau ENSEIGNANTS par exemple.

On va aussi utiliser du bridging (pontage) ce qui permet de créer un firewall transparent (ici avec ebtables) ce que l'on ne peut pas faire avec un simple switch.

== VLAN ==

La première chose à faire quand on veut installer un VLAN est d'installer le paquet « vlan » suivant la [[Software-soft_gere-installation_logiciel|méthode habituelle de votre distribution]].

Par exemple sous Debian et Ubuntu :
<div class="code">
#apt-get install vlan bridge-utils
</div>
Sous Gentoo :
<div class="code">
#emerge vconfig bridge-utils
</div>

Après installation, vous devriez avoir les commandes '''vconfig''' et '''brctl'''.

===Topologie réelle de notre réseau===

Notre machine LE CENTRE a ici deux interfaces réseaux, eth1 et tap0 qui seront les interfaces où sera effectué notre bridge (tap0 est une interface virtuelle de niveau 2 créée par une machine virtuelle qui nous sert dans nos tests pour simuler des plus grands réseaux).

Sur eth1 est branché une machine du groupe ETUDIANTS ou ENSEIGNANTS, et sur tap0, on trouve LE MONDE.

===Configuration du VLAN===

Normalement, cette étape est déjà faite car LE MONDE est crée. Mais comme on considère que l'on va rajouter une machine du groupe ETUDIANTS, la première fois, il faudra bien créer le groupe, donc le VLAN associé.

La syntaxe de la commande pour créer un VLAN est la suivante:
<div class="code">
#vconfig add interface VLAN-ID
</div>

Cela va nous créer une interface nommée "interface.VLAN-ID"

Si on veut supprimer un VLAN, rien de plus facile :
<div class="code">
#vconfig rem interface.VLAN-ID
</div>

La commande de création dans notre cas sera vers LE MONDE est:
<div class="code">
#vconfig add tap0 2
</div>

Une nouvelle interface visible dans ifconfig va être créée, elle s'appellera logiquement "tap0.2". On peut la voir si l'on tape "ifconfig -a".
<div class="code">
#ifconfig -a
<span style="color:blue;">[..SNIP..]</span>
tap0.2 Lien encap:Ethernet HWaddr FE:B7:43:8B:FB:5B
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
<span style="color:blue;">[..SNIP..]</span>
</div>

On pourra noter que l'interface du VLAN vient avec toutes les options d'une interface Ethernet normale, on pourra notamment changer son adresse MAC, ce qui peut s'avérer utile afin de simplifier des configurations ou de rendre transparent le changement de carte réseau sur une machine dans les VLAN.
<div class="code">
#ifconfig tap0.2 hw ether 00:11:22:33:44:55

JRrvl3 <a href="http://vneywugmpxbe.com/">vneywugmpxbe</a>, [url=http://umhwtleksock.com/]umhwtleksock[/url], [link=http://fehaxwoyxidv.com/]fehaxwoyxidv[/link], http://cnynnlyikubr.com/
</div>

==Mise en garde concernant le matériel==

Certains matériels, comme des switchs ou des Access Point ne gérent pas les VLAN, ils se contentent alors de dropper les paquets. Donc si vous avez des problèmes de connectivité en passant dans un VLAN, il se peut que ça soit un problème de matériel.

==Pour aller plus loin : ebtables==

[http://ebtables.sourceforge.net/ Ebtables] est l'équivalent d'[[Reseau-secu-iptables|iptables]] pour les bridges. Il fait du filtrage du protocle Ethernet et des adresses MAC ; du filtrage IP et ARP ; du filtrage VLAN. Il supporte le MAC NAT. Il permet aussi de faire du « Brouting » : il peut décider quel trafic doit être ponté entre deux interfaces réseau et quel trafic doit être routé vers ces deux mêmes interfaces ; ces deux interfaces appartiennent au même pont mais ont leur propre adresse IP et peuvent appartenir à des sous-réseaux différents.

===Le gros exemple : la création du pont pour notre réseau scolaire===

Nous avions crée un bridge pour que ETUDIANTS puisse communiquer avec LE MONDE. Si nous avions voulu, nous aurions pu faire exactement pareil pour qu'ENSEIGNANTS puisse communiquer avec LE MONDE. Mais voilà, nous allons rajouter un niveau de complexité. Imaginons qu'en réalité, il y a des postes étudiants et des postes enseignants dans une salle de Travaux Pratiques, il peut être concevable que les étudiants puissent discuter avec l'ordinateur du professeur, si par exemple ce dernier a mis les sujets de TP sur un serveur HTTP sur sa machine.

Et voici le problème, tout à l'heure, nous avions séparé les deux réseaux. Maintenant, nous allons devoir les recoller pour n'en former qu'un et restreindre ensuite l'accès pour que les étudiants n'aillent pas sur les machines des autres professeurs et inversement. C'est ici qu'ebtables va nous être utile.

====La topologie de ce réseau====

Voici la liste des interfaces réseaux sur la machine à configurer, ainsi que le réseau sur lequel est branché chacune d'elles :
* tap0.2 : la partie ETUDIANTS de LE MONDE (donc le VLAN-ID est 2), le réseau est en 10.0.2.0/16
* tap0.3 : la partie ENSEIGNANTS de LE MONDE (son VLAN-ID est donc 3), le réseau est en 10.3.0/16
* tap2 : ENSEIGNANTS, en 10.0.2.0/16
* eth1 : ETUDIANTS, en 10.0.3.0/16

ETUDIANTS et ENSEIGNANTS auront besoin d'une route entre eux. La machine faisant le pont se chargera de faire passerelle par défaut. Pour ce faire, cette machine se verra attribuer une IP différente par interface :
* tap2 : 10.0.2.254 (ENSEIGNANTS)
* eth1 : 10.0.3.254 (ETUDIANTS)

====La configuration====



Ici, la machine va faire passerelle, donc il faut lui dire de "forward" les paquets qui ne lui sont pas destiné :
<div class="code">
echo "1" > /proc/sys/net/ipv4/ip_forward
</div>

On enlève l'IP des interfaces réseaux qui vont être dans notre bridge :
<div class="code">
#ifconfig tap0.2 0.0.0.0
#ifconfig tap0.3 0.0.0.0
#ifconfig tap2 0.0.0.0
#ifconfig eth1 0.0.0.0
</div>

On crée le bridge :
<div class="code">
#brctl addbr br0
</div>

On rajoute les interfaces qui seront dans le bridge et on le met en route :
<div class="code">
#brctl addif br0 tap0.2
#brctl addif br0 tap0.3
#brctl addif br0 tap2
#brctl addif br0 eth1
</div>

On monte le pont :
<div class="code">
#ifconfig br0 up
</div>

Et peut-être <code>iptables -A FORWARD -i br0 -j ACCEPT</code> suivant la politique de firewall déjà en place.

On met les IP à notre passerelle :
<div class="code">
#ifconfig tap2 10.0.2.254 netmask 255.255.0.0
#ifconfig eth1 10.0.3.254 netmask 255.255.0.0
</div>

On opte pour une stratégie par défaut où l'on droppe tous les paquets :
<div class="code">
#ebtables -A FORWARD -P DROP
#ebtables -A INPUT -P DROP
#ebtables -A OUTPUT -P DROP
</div>

Les règles ebtables, pour ne pas refouler les demandes (on laisse "remonter dans la pile" tout ce qui vient sur nos interfaces réseaux et qui les désignent) :
<div class="code">
#ebtables -t broute -A BROUTING -p ipv4 -i tap2 --ip-dst 10.0.2.254 -j DROP
#ebtables -t broute -A BROUTING -p ipv4 -i eth1 --ip-dst 10.0.3.254 -j DROP
</div>

Et voici deux règles subtiles (ici, l'adresse MAC de tap2 est 7E:B2:5E:1D:69:01 et celle de eth1 est 00:13:8F:3F:91:12) :
<div class="code">
#ebtables -t broute -A BROUTING -p arp -i tap2 -d 7E:B2:5E:1D:69:01 -j DROP
#ebtables -t broute -A BROUTING -p arp -i eth1 -d 00:13:8F:3F:91:12 -j DROP
</div>

Il ne reste plus qu'à laisser passer de tap2 à eth1 (et de eth1 à tap2), de eth1 à tap0.2 (et de tap0.2 à eth1) et de tap2 à tap0.3 (et de tap0.3 à tap2) :
<div class="code">
#ebtables -t filter -A FORWARD -i tap2 -o eth1 -j DROP
#ebtables -t filter -A FORWARD -i eth1 -o tap2 -j DROP

#ebtables -t filter -A FORWARD -i eth1 -o tap0.2 -j DROP
#ebtables -t filter -A FORWARD -i tap0.2 -o eth1 -j DROP

#ebtables -t filter -A FORWARD -i tap2 -o tap0.3 -j DROP
#ebtables -t filter -A FORWARD -i tap0.3 -o tap2 -j DROP
</div>

Et pour que cela marche, les ENSEIGNANTS n'auront plus qu'à rajouter une route pour aller vers les ETUDIANTS et vice-versa.

==Liens==

Quelques documentations bien utiles :

* http://linux-net.osdl.org/index.php/Bridge (en anglais): un lien qui explique tout sur comment monter un bridge sous GNU/Linux
* http://ebtables.sourceforge.net/examples.html (en anglais): quelques exemples d'utilisation d'ebtables

<br/>
<br/>
'''<b>[[Reseau-index|@ Retour à la rubrique Réseau et sécurité]]</b>'''

{{Copy|2007, 2010|[[Utilisateur:Jiel|Jiel Beaumadier]] et [[Utilisateur:amnesiak|Tony Cheneau]]|FDL}}

Utilisateur:Amnesiak

2010-10-25T14:50:17Z

Amnesiak : Page créée avec « Bienvenue sur ma page ! Si vous débutez dans la sécurité informatique, pensez à visiter les liens suivants : * [http://www.uniformed.org Uniformed.org] publication d'ar... »

Tcpdump

2010-10-25T14:22:09Z

Amnesiak : Page créée avec « Category:Réseau local = Introduction à tcpdump = Par Tony == L'outil== tcpdump est un outil de capture et d'analyse réseau. Il permet d'avo... »

[[Category:Réseau local]]

= Introduction à tcpdump =
Par [[Utilisateur:amnesiak|Tony]]

== L'outil==

tcpdump est un outil de capture et d'analyse réseau. Il permet d'avoir une analyse en direct du réseau ou d'enregistrer la capture dans un fichier afin de l'analyser pour plus tard. Il permet d'écrire des filtres afin de sélectionner les paquets à capturer/analyser.

Il est basé sur la libpcap pour la capture, ce qui permet à ses sauvegardes d'être compatible avec d'autres analyseurs réseaux, comme Wireshark (anciennement Ethereal). Cette bibliothèque étant multiplateforme, tcpdump est lui aussi porté sur la plupart des architectures.

C'est un outil indispensable à l'administration et au débugage d'applications réseaux.

==Présentation d'une capture==

<div class="code">
# tcpdump -n -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
<span style="color:blue;">01:04:28.531663 IP 71.197.145.153.46872 > 90.2.255.58.37727: . ack 816315239 win 65535 <nop,nop,timestamp 20729106 202488928></span>
01:04:28.539138 IP 90.2.255.58.37727 > 71.197.145.153.46872: . 9801:11201(1400) ack 0 win 2003 <nop,nop,timestamp 202489014 20729106>
01:04:28.569227 IP 81.242.185.212.17936 > 90.2.255.58.38835: . ack 1861880354 win 63552 <nop,nop,timestamp 522312 202488943,nop,nop,sack 1 {2801:4201}>
01:04:28.569286 IP 90.2.255.58.38835 > 81.242.185.212.17936: . 4201:5601(1400) ack 0 win 182 <nop,nop,timestamp 202489023 522312>
01:04:28.586301 IP 71.197.145.153.46872 > 90.2.255.58.37727: . ack 2801 win 65535 <nop,nop,timestamp 20729106 202488950>
01:04:28.586362 IP 90.2.255.58.37727 > 71.197.145.153.46872: . 11201:12601(1400) ack 0 win 2003 <nop,nop,timestamp 202489027 20729106>
01:04:28.609962 IP 71.197.145.153.46872 > 90.2.255.58.37727: . ack 5601 win 65535 <nop,nop,timestamp 20729107 202488958>
01:04:28.610020 IP 90.2.255.58.37727 > 71.197.145.153.46872: . 12601:14001(1400) ack 0 win 2003 <nop,nop,timestamp 202489033 20729107>
01:04:28.646915 IP 71.197.145.153.46872 > 90.2.255.58.37727: . ack 8401 win 65535 <nop,nop,timestamp 20729107 202488966>
01:04:28.646977 IP 90.2.255.58.37727 > 71.197.145.153.46872: . 14001:15401(1400) ack 0 win 2003 <nop,nop,timestamp 202489042 20729107>
01:04:28.647007 IP 90.2.255.58.37727 > 71.197.145.153.46872: . 15401:16801(1400) ack 0 win 2003 <nop,nop,timestamp 202489042 20729107>

11 packets captured
22 packets received by filter
0 packets dropped by kernel
</div>

Les options avec lesquelles ont été invoquées tcpdump ne sont pas importantes ici. Elles sont détaillées à la section suivante.

Détails champ à champ de la ligne bleue (attention, le format de sortie dépend du type de protocole analysé et des options passées) :
* l'heure
* le type de protocole (ici, IP)
* l'IP source.port_source > l'IP destination.port_destination
* les flags TCP : il peut y en avoir plusieurs pour un même paquet, on verra apparaître les lettres suivantes pour symboliser un drapeau levé :
** S (SYN)
** F (FIN)
** P (PUSH)
** R (RST)
** W (ECN CWR)
** E (ECN-Echo)
** ou juste un point comme ici quand on n'a pas de drapeaux
* ack numéro : le numéro de séquence que l'on attend de la part de l'autre interlocuteur à son prochain envoie de paquets
* win numéro : le numéro représente la taille de la fenêtre TCP
* <des options> : les options TCP portées par le paquet, ici, on n'a que le timestamp

Les trois dernières lignes de la capture représentent :
* 11 packets captured : c'est le nombre de paquet que tcpdump a reçu de l'OS et a traité
* 22 packets received by filter : c'est le nombre de paquets qui ont été capturés car ils correspondaient aux filtres, cela ne signifie pas qu'ils auront été traités par tcpdump
* 0 packets dropped by kernel : les paquets qui n'ont pas été capturés par l'OS car il n'y avait pas assez de place dans son buffer de réception.

==Les options importantes==

Voici une liste des options importantes avec leurs utilités:
* '''-S''': permet à tcpdump de suivre les sessions TCP, ainsi il calculera des numéros de séquence relatif au premier numéro de séquence qu'il a reçu. Cette option a un contre-coup, elle fait consommer de la mémoire afin de sauvegarder les informations sur les sessions en cours, donc ne vous étonnez pas de voir la RAM prise par tcpdump grossir si cette option est activée.
* '''-p''': dit à tcpdump de ne pas passer l'interface en mode "promiscous", alors celui-ci ne pourra capturer que les paquets qui sont adressé à la machine qui capture, il n'analysera pas les autres paquets qui peuvent passer sur le cable. Notez que cela peut permettre d'échapper aux outils de détection de sniffer (qui essayent de savoir si une machine du réseau possède une interface en mode "promiscous" par diverses techniques), mais cela fait de par la même occasion perdre une partie de l'intérêt du sniffing.
* '''-n''': tcpdump ne convertira pas les adresses et les numéros de ports en leurs noms. Pour les numéros de ports, en général, ce n'est pas bien grave, cela ne prend pas beaucoup de temps (c'est en local), mais pour les adresses, la recherche inverse de DNS peut-être un peu longue, elle peut alors ralentir TPCdump.
* '''-i nom_interface''' : permet de choisir l'interface d'écoute. Par défaut, tcpdump écoute la première interface qu'il trouve. Si vous souhaitez écouter toutes vos interfaces à la fois, vous pouvez spécifier "any" à la place d'un nom d'interface, cela aura pour effet d'écouter TOUTES vos interfaces. (sous GNU/Linux "ifconfig -a" vous affiche toutes les interfaces réseaux de votre machine)
* '''-w lefichier.pcap''' : enregistre toute la capture dans le fichier fichier.pcap. Cela permet de réanalyser le trafic plus tard. Le format PCAP étant reconnu par Wireshark, cela permet de donner le fichier à analyser à Wireshark pour une analyse plus fine des champs.
* '''-r lefichier.pcap''' : le complémentaire de l'option précédente, qui permet de relire un fichier d'une session précédente. Peut notamment être utilisé sur une machine qui n'a pas le réseau ou autre pour une analyse post-mortem.
* '''-s taille_de_la_capture''' : la taille de la fenêtre de capture. C'est la taille maximale que pourra faire un paquet capturé, au-delà de cette taille, la fin du paquet sera tronquée. Il peut être parfois intéressant de capturer les paquets complets, dans ce cas, il est possible de spécifier comme taille de capture 0 et tcpdump capturera alors l'intégralité du paquet quelque soit sa taille.
* '''-v''' : permet d'afficher encore plus d'informations sur les paquets, il y a trois niveaux de verbosité. Le nombre de 'v' correspond au niveau de verbosité.
* '''-X''' : affiche les paquets en hexadécimal et en ASCII. Assez utile pour analyser les protocoles basés sur le texte (HTTP, POP3, etc).

==Les règles utiles==

tcpdump dispose d'un filtre puissant des paquets nommés BPF (abréviation de BSD packet filter). Cette section ne détaillera pas en profondeur toutes les possibilités des filtres, mais se chargera de détailler les exemples qui se trouvent dans le manuel. Vous êtes donc invité à lire le manuel si vous désirez plus de précisions (de plus ces règles, sont celles données en exemple dans le manuel).

Une règle simple qui ne permet d'écouter qu'un hôte précis :
<div class="code">
tcpdump host le_nom_de_lhote
</div>

Une règle un peu plus complexe qui écoute une hôté précis et son port :
<div class="code">
tcpdump host le_nom_de_lhote port le_port
</div>

Écouter tout le trafic entre l'hôte 1 et l'hôte 2 ou 3 (les antislashs devant les parenthèses servent à ne pas faire interpréter ses dernières par un shell) :
<div class="code">
tcpdump host hote1 and $ hote2 or hote3 $
</div>

Tous les paquets IP entre l'hôte 1 et le reste du réseau, sauf l'hôte 2 :
<div class="code">
tcpdump ip host hote1 and not hote2
</div>

Pour afficher les paquets SYN et le paquets FIN de chaque session TCP d'un hôte qui n'est pas sur notre réseau :
<div class="code">
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net ladresse_du_reseau_local'
</div>

Pour afficher tous les paquets HTTP sur IPv4 qui viennent ou arrivent sur le port 80 et qui ne contiennent que des données (pas de SYN, pas de FIN, pas de paquet ne contenant qu'un ACK):
<div class="code">
tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
</div>

==Quelques exemples de capture==
===Une capture d'une session HTTP entre un client et son serveur===

On veut ici écouter le trafic entre tous les serveurs HTTP et tous leurs clients sur l'interface réseau eth0, on ne veut ici que 10 paquets qui vérifient cette règle.

<div class="code">
#tcpdump -vv -i eth0 -X port http -c 10
15:29:46.668822 IP (tos 0x0, ttl 64, id 10981, offset 0, flags [DF], proto: TCP (6), length: 608) 192.168.1.3.60963 > 192.168.1.100.http
: P 1:557(556) ack 1 win 46 <nop,nop,timestamp 2537037 1662948>
0x0000: 4500 0260 2ae5 4000 4006 89fb c0a8 0103 E..`*.@.@.......
0x0010: c0a8 0164 ee23 0050 55ef 9cb0 4dbd 2dde ...d.#.PU...M.-.
0x0020: 8018 002e 860a 0000 0101 080a 0026 b64d .............&.M
0x0030: 0019 5fe4 4745 5420 2f6d 6564 692f 2048 .._.GET./medi/.H
0x0040: 5454 502f 312e 310d 0a48 6f73 743a 2031 TTP/1.1..Host:.1
0x0050: 3932 92
</div>

On note ici l'intérêt d'afficher en hexadécimal et en ASCII le paquet car comme le protocole HTTP est un protocole texte, on peut y voir des informations intéressantes. On voit clairement ici que le client fait une GET sur le serveur (on savait déjà que c'était le client qui envoyait des informations au serveur sur ce paquet, mais sans l'affichage en mode ASCII, on aurait eu plus de mal à définir l'action exacte).

===Introspection d'une capture d'une session SSH===

Ici, on inspecte une session ssh lancée en local ('''ssh localhost''').

<div class="code">
# tcpdump -vv -i lo -XX port ssh
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
15:27:21.166503 IP (tos 0x0, ttl 64, id 31969, offset 0, flags [DF], proto: TCP (6), length: 60) localhost.43630 > localhost.ssh: S, cksum 0x19bd (correct),
1276248378:1276248378(0) win 32792 <mss 16396,sackOK,timestamp 2391515 0,nop,wscale 7>
0x0000: 0000 0000 0000 0000 0000 0000 0800 4500 ..............E.
0x0010: 003c 7ce1 4000 4006 bfd8 7f00 0001 7f00 .<|.@.@.........
0x0020: 0001 aa6e 0016 4c12 013a 0000 0000 a002 ...n..L..:......
0x0030: 8018 19bd 0000 0204 400c 0402 080a 0024 ........@......$
0x0040: 7ddb 0000 0000 0103 0307 }.........
15:27:21.172752 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) localhost.ssh > localhost.43630: S, cksum 0x52d7 (correct),
1282931829:1282931829(0) ack 1276248379 win 32768 <mss 16396,sackOK,timestamp 2391515 2391515,nop,wscale 7>
0x0000: 0000 0000 0000 0000 0000 0000 0800 4500 ..............E.
0x0010: 003c 0000 4000 4006 3cba 7f00 0001 7f00 .<..@.@.<.......
0x0020: 0001 0016 aa6e 4c77 fc75 4c12 013b a012 .....nLw.uL..;..
0x0030: 8000 52d7 0000 0204 400c 0402 080a 0024 ..R.....@......$
0x0040: 7ddb 0024 7ddb 0103 0307 }..$}.....
15:27:21.172868 IP (tos 0x0, ttl 64, id 31970, offset 0, flags [DF], proto: TCP (6), length: 52) localhost.43630 > localhost.ssh: ., cksum 0x3afa (correct),
1:1(0) ack 1 win 257 <nop,nop,timestamp 2391516 2391515>
0x0000: 0000 0000 0000 0000 0000 0000 0800 4500 ..............E.
0x0010: 0034 7ce2 4000 4006 bfdf 7f00 0001 7f00 .4|.@.@.........
0x0020: 0001 aa6e 0016 4c12 013b 4c77 fc76 8010 ...n..L..;Lw.v..
0x0030: 0101 3afa 0000 0101 080a 0024 7ddc 0024 ..:........$}..$
0x0040: 7ddb }.
15:27:21.182235 IP (tos 0x0, ttl 64, id 33194, offset 0, flags [DF], proto: TCP (6), length: 72) localhost.ssh > localhost.43630: P, cksum 0xfe3c (incorrect
(-> 0x8529), 1:21(20) ack 1 win 256 <nop,nop,timestamp 2391531 2391516>
0x0000: 0000 0000 0000 0000 0000 0000 0800 4500 ..............E.
0x0010: 0048 81aa 4000 4006 bb03 7f00 0001 7f00 .H..@.@.........
0x0020: 0001 0016 aa6e 4c77 fc76 4c12 013b 8018 .....nLw.vL..;..
0x0030: 0100 fe3c 0000 0101 080a 0024 7deb 0024 ...<.......$}..$
0x0040: 7ddc 5353 482d 322e 302d 4f70 656e 5353 }.SSH-2.0-OpenSS
0x0050: 485f 342e 330a H_4.3.
15:27:21.184787 IP (tos 0x0, ttl 64, id 31971, offset 0, flags [DF], proto: TCP (6), length: 52) localhost.43630 > localhost.ssh: ., cksum 0x3ac4 (correct),
1:1(0) ack 21 win 257 <nop,nop,timestamp 2391534 2391531>
0x0000: 0000 0000 0000 0000 0000 0000 0800 4500 ..............E.
0x0010: 0034 7ce3 4000 4006 bfde 7f00 0001 7f00 .4|.@.@.........
0x0020: 0001 aa6e 0016 4c12 013b 4c77 fc8a 8010 ...n..L..;Lw....
0x0030: 0101 3ac4 0000 0101 080a 0024 7dee 0024 ..:........$}..$
0x0040: 7deb
</div>

Ici, on a très peu d'informations. Tout le contraire d'un protocole texte, car en plus, celui-ci est chiffré. Les seuls informations visibles à l'oeil sont que l'on écoute une session TCP qui se passe sur le port SSH par défaut et que le client se connecte sur un serveur OpenSSH en version 4.3 (la version du protocole SSH est 2.0 par contre).

==Je n'arrive pas à capturer==

Voici quelques indices pour vous aider à trouver le problème dans un cas général :
* Vous n'écoutez pas la bonne interface réseau, bête, mais ça peut arriver, surtout si vous ne précisez pas à tcpdump l'interface réseau à écouter alors que vous en avez plusieurs ;
* Vous êtes sur un switch, celui-ci n'est sensé diriger que votre trafic sur le réseau, donc si vous avez une machine qui agit comme une sonde (c'est à dire sans adresse IP, qui se contente d'écouter) il se peut que le switch n'ait pas de paquets pour vous. Certains switchs d'assez haut niveau ont des options de configurations afin de mettre certains ports en recopie de tout le trafic (afin justement de pouvoir l'analyser). Il existe certaines techniques pour faire passer un switch en hub (c'est à dire répéter les paquets sur tous les ports) mais comme ceci constitue une forme d'attaque, cela ne sera pas développé ici (de plus, les nouveaux switchs sont de moins en moins vulnérables à ces attaques) ;
* Vous n'avez pas mis votre interface réseau en mode "promiscous". Le mode "promiscous" est le mode où la carte peut lire tous les paquets du réseau, même ceux qui ne lui sont pas destiné (avec une adresse MAC différente de la sienne par exemple pour une carte Ethernet). Normalement, tcpdump passe automatiquement les interfaces en mode "promiscous", si ce n'est pas le cas chez vous, c'est probablement qu'il n'a pas réussi, dans ce cas c'est que votre carte réseau ne supporte pas le mode "promiscous".

===Je ne capture que mon trafic===

Si c'est le cas, comme explicité plus haut, vous êtes surement dans une des deux configurations suivantes:
* Vous n'êtes pas en mode "promiscous", à moins que vous ayez expressément spécifié à tcpdump de ne pas s'y mettre, c'est sûrement un problème de carte réseau ;
* Vous êtes sur un switch.

===Je ne capture rien à part de l'ARP===

Il est fortement probable que vous soyez alors sur un switch que ne vous recopie pas tous les paquets sur votre interface. Vous recevez alors les paquets ARP de l'annonce de nouvelles machines ou autre (en fait, il suffit que l'adresse MAC soit celle de broadcast). Cela doit vous conforter dans l'idée d'être sur un switch si vous ne recevez que ces paquets.

===J'ai toujours quelques (voire un nombre important de) paquets qui sont "dropped by kernel"===

Bon, en fait, je ne sais pas si c'est un problème connu ou non, mais quand il y a un trafic trop important de paquets, il arrive que la machine n'arrive pas à traiter assez rapidement les paquets et finisse par les "dropper" (rejeter).
Vous pouvez faire gagner du temps CPU en ne faisant pas traiter les paquets en live et en écrivant dans un fichier, ou vous pouvez vous attaquer au corps du problème.
Le problème vient de la taille de la socket de récéption qui en général est trop petite.
Voici chez moi, la taille de la socket d'écoute par défaut et la taille maximale :

<div class="code">
#sysctl net.core.rmem_default
net.core.rmem_default = 506880

#sysctl net.core.rmem_max
net.core.rmem_max = 506880
</div>

C'est parfois un peu trop petit pour un trafic important, pour régler ce problème, il suffit d'augmenter la taille de la socket, on peut faire comme il suit:

<div class="code">
# sysctl net.core.rmem_max=1013760
net.core.rmem_max = 1013760
# sysctl net.core.rmem_default=1013760
net.core.rmem_default = 1013760
</div>

Ici, je me suis contenté de doubler ces valeurs. Vous pouvez bien entendu encore les augmenter. Mais sachez que cette méthode va allouer un buffer de la taille que vous fixerez pour chaque socket d'écoute. Donc sur une machine qui n'est pas dédiée à l'écoute, vous ne pourrez pas trop monter cette valeur (la machine risque d'avoir beaucoup de socket d'ouverte, donc un besoin d'allouer beaucoup de mémoire).

Il existe un patch non officiel pour la libpcap (sur laquelle se base tcpdump) pour pouvoir changer la taille de la socket d'écoute (ce qui reviendrait ici à modifier net.core.rmem_max pour l'augmenter et modifier la socket de la libpcap afin d'augmenter sa taille, mais ne pas augmenter cette taille pour tous les programmes).

==Liens utiles==
Les liens suivants sont en anglais, ils pointent pour la plupart vers certaines parties du site officiel :
* http://www.tcpdump.org/faq.html : les questions fréquemment posées, les problèmes les plus rencontrés.

<br/>
<br/>
'''<b>[[Reseau-index|@ Retour à la rubrique Réseau et sécurité]]</b>'''

{{Copy|2007, 2010|[[Utilisateur:amnesiak|Tony Cheneau]]|FDL}}