7h3ram/flowinspectUn outil d'inspection réseau
Un outil d'inspection du trafic réseau
Il utilise libnids (via ses bindings Python de Jon Oberheide : pynids) pour défragmenter les paquets IP et réassembler les paquets TCP (l'UDP est inspecté paquet par paquet) afin de générer des flux réseau. Ces flux sont ensuite inspectés en utilisant l'un des quatre modes d'inspection :
Les correspondances regex sont effectuées en utilisant la bibliothèque re2 et ses bindings Python, pyre2, qui supporte PCRE, la casse insensible, l'inversion et les correspondances multilignes, etc. Il offre des gains de performance énormes par rapport au module re intégré de Python (qui est utilisé comme solution de repli si re2 n'est pas installé).
Les fonctionnalités de correspondance floue de chaînes sont réalisées via le module fuzzywuzzy. Il permet d'effectuer à la fois une correspondance exacte et relative de chaînes. Un seuil de correspondance par défaut de 75 est utilisé par défaut et peut être modifié via la ligne de commande.
Libemu et ses bindings Python, pylibemu, sont utilisés pour la détection de shellcode. Les heuristiques GetPC utilisées par libemu fournissent un ratio de détection décent. Il y a quelques cas où libemu échoue simplement mais pour la plupart des cas d'utilisation, il est suffisant.
Yara est un outil d'identification et de classification de logiciels malveillants basé sur des signatures. Ses bindings yara-python fournissent une API pour utiliser des fichiers de signature existants/personnalisés sur un tampon d'entrée qui, dans ce cas, est un flux réseau.
L'inspection peut être demandée pour n'importe laquelle des directions CTS/STC/ANY ou leurs combinaisons. Les tampons d'inspection sont remplis au fur et à mesure que le trafic réseau arrive et ainsi les correspondances CTS (CTS ou ANY) se produisent en premier. Si plus d'un mode d'inspection est demandé, les flux sont inspectés dans l'ordre suivant : regex, fuzzy, libemu et enfin yara. Pour TCP, si l'un des modes d'inspection réussit, le flux correspondant ne sera pas inspecté davantage. Il s'agit d'une approche optimiste et elle est activée par défaut. Cependant, si pour un certain cas d'utilisation un flux TCP doit être inspecté plusieurs fois, cela peut être demandé explicitement via la ligne de commande.
L'inspection peut être complètement désactivée si nécessaire via l'option de ligne de commande linemode. Ce mode est vraiment utile et lorsqu'il est combiné avec un outmode approprié, il permet de jeter un coup d'œil à la communication réseau telle quelle pendant qu'elle se déroule sur le fil. Linemode est automatiquement activé comme solution de repli si aucun mode d'inspection n'est fourni via la ligne de commande.
Pour UDP, les correspondances se font paquet par paquet et ainsi les paquets suivants seront testés même après qu'une correspondance a déjà été trouvée sur un flux UDP. Puisque seuls les paquets suivants et leur contenu sont inspectés, cela garantit que les données déjà correspondues lors des cycles d'inspection précédents ne sont pas inspectées à nouveau.
La portée des correspondances peut être limitée via des expressions BPF, des modificateurs de contenu de type offset-depth à la Snort, ou via des options de ligne de commande de limite d'inspection de paquets/flux. Pour TCP, les flux correspondants peuvent également être tués si nécessaire. Les flux peuvent également être enregistrés dans des fichiers en plus d'être affichés sur stdout. Quelques modes de sortie utiles (quite, meta, hex, print, raw) aident à une analyse plus poussée. Le mode de sortie meta est particulièrement utile car il montre des détails vraiment importants spécifiques à la correspondance, comme la taille totale du contenu correspondant, le décalage du début d'une correspondance dans le flux réseau, les identifiants de paquets qu'une correspondance couvre, la direction du paquet sur lequel une correspondance a eu lieu, etc.
La génération de pcap pour les flux correspondants est également prise en charge. Si activée, elle viderait tous les paquets depuis le début jusqu'à la fin du flux. Les flux TCP correspondants sont vidés dès qu'une fermeture/réinitialisation est vue et pour les flux où nous ne voyons pas de fermeture/réinitialisation, ils sont vidés avant la sortie de l'outil. Pour UDP, comme il n'y a pas d'information d'état de fermeture/réinitialisation disponible, ils sont vidés uniquement lorsque l'outil se termine. Cela garantit que tous les paquets, même ceux qui arrivent après la correspondance, sont capturés dans le pcap du flux. Sauf pour l'en-tête global pcap personnalisé, l'en-tête pcap par paquet et l'en-tête Ethernet II L2 (qui n'est pas vu par flowinspect), tout ce qui précède reste tel quel dans les captures de paquets vidées.
AIDE: -----```c ______ _ __ / / /_ _ () _________ ___ / / / // / __ \ | /| / / / __ / / __ / _ / / __/ / __/ / // / |/ |/ / / / / ( ) // / / // / // //_/|/|/// /// ._/_/___/_/ //
flowinspect v0.2 - A network inspection tool Ankur Tyagi (7h3rAm [at] gmail [dot] com)
usage: flowinspect.py [-h] (-p --pcap | -d --device) [-c --cregex] [-s --sregex] [-a --aregex] [-i] [-m] [-G --cfuzz] [-H --sfuzz] [-I --afuzz] [-r fuzzminthreshold] [-C --cdfa] [-S --sdfa] [-A --adfa] [-l] [-X --dfaexpr] [-g [graphdir]] [-P --cyararules] [-Q --syararules] [-R --ayararules] [-M] [-y] [-Y --emuprofileoutsize] [-O --offset] [-D --depth] [-T --maxinspstreams] [-U --maxinsppackets] [-t --maxdispstreams] [-u --maxdisppackets] [-b --maxdispbytes] [-w [logdir]] [-o {quite,meta,hex,print,raw}] [-f --bpf] [-v] [-V] [-e] [-k] [-j] [-Z] [-n] [-L]
optional arguments: -h, --help show this help message and exit -p --pcap input pcap file -d --device listening device
RegEx per Direction: -c --cregex regex to match against CTS data -s --sregex regex to match against STC data -a --aregex regex to match against ANY data
RegEx Options: -i ignore case -m disable multiline match
Fuzzy Patterns per Direction: -G --cfuzz string to fuzzy match against CTS data -H --sfuzz string to fuzzy match against STC data -I --afuzz string to fuzzy match against ANY data
Fuzzy Options: -r fuzzminthreshold threshold for fuzzy match (1-100) - default 75
DFAs per Direction ('m[0-9][1-9]='): -C --cdfa DFA expression to match against CTS data -S --sdfa DFA expression to match against STC data -A --adfa DFA expression to match against ANY data
DFA Options: -l switch default boolean operator to 'or' -X --dfaexpr expression to test chain members -g [graphdir] generate DFA transitions graph
Yara Rules per Direction: -P --cyararules Yara rules to match on CTS data -Q --syararules Yara rules to match on STC data -R --ayararules Yara rules to match on ANY data
