Les scans
Cela se produit quand une même machine "teste" tous les ports d'une machine, ou alors un même port sur toutes les machines du réseau, essayant de trouver une entrée.
Evidemment, cela est en général assez visible et un parcourt des logs Cisco permet de les repérer, même si les paquets sont intercalés entre d'autres normaux.
Voir Logsurfer : exemple d'utilisation.
--------------------------------------------------------------------------------
Le SYN flooding
Le principe est assez simple : une machine A envoie à une machine Y un paquet SYN semblant venir d'une machine X non accessible -éteinte ou inexistante-. La machine Y envoie donc le second paquet pour l'ouverture de la connection et attend la réponse de la machine X, qui ne viendra jamais.
Ainsi, la machine Y aura une connection monopolisée pendant un certain laps de temps. Si la machine A envoie de nombreux paquets SYN, la machine Y peut devenir saturée et ne plus accepter de nouvelles connections.
Cette attaque fait donc partie des attaques du type refus de service, puisque la machine cible devient indisponible et refuse ainsi un service à d'autres utilisateurs.
Pour détecter cela, la facon la plus simple serait de repérer un nombre important de paquets SYN non suivi d'une connection, mais il faudrait ètre dans le mode detail d'Argus (lourd). On pourrait aussi chercher une série anormale de URH (unreachable host) dans les logs Argus. Seulement, il apparait que cela ne caractérise pas une attaque, cela étant répandu. Il faudrait alors plutôt chercher des RST (reset) ou TIM (time exceeded) en nombres, séparés de seulement quelques instants.
--------------------------------------------------------------------------------
Le vol de session (TCP hijacking)
Cette attaque a tendance à remplacer le sniffing ou le crackage de password. En effet, pas besoin de perdre du temps pour cela, puisqu'on peut s'approprier la session d'un autre !
De plus, elle permet de contourner des méthodes de sécurisation comme le One Time Password.
Il faut au départ une connection établie entre deux machines X (cliente) et Y (serveur), par exemple un Telnet. Les échanges de paquets se font à l'aide des numéros de séquence et d'acquittement pour assurer le bon ordre et les acceptations.
Ainsi, si la machine A envoie à Y au bon moment un paquet de données semblant venir de X avec les numéros de séquence et d'acquittement corrects, la machine Y mettra son numéro d'acquittement à jour et les données venant de X ne seront plus jamais acceptées.
La machine A aura donc tout le loisir d'envoyer ses données, le plus souvent néfastes...
Une manière de détecter cela à partir des logs Argus, est d'essayer de repérer des paquets RST (reset) et EST CON (established connected) allant à la même machine dans le même moment depuis notre réseau, ce qui indiquerait que la connection est à la fois établie et incorrecte. Il faudrait alors être dans le mode detail d'Argus pour percevoir les paquets EST CON (established connected), mais cela alourdirait sans doute considérablement les logs déjà encombrants et je ne suis pas certain qu'il s'agit d'une bonne trace.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Mar 12 Fév - 11:08