Quelques IDS sont capablent de répondre aux attaquent qu'ils détectent. Ces actions sont souvent destinées à empêcher de prochaines attaques et/ou à obtenir des informations supplémentaires sur l'attaquant. Malheuresement, un attaquant intelligent peut abuser de ces caractéristiques.
Une action typique consiste à empêcher la machine de l'attaquant de rentrer à nouveau dans le réseau en recongifurant la liste des accès d'un firewall, ou autre chose de semblable. Ceci peut éventuellement mener à une vulnérabilité à un déni de service12 si l'attaque que nous avons détecté est spoofable (c'est le cas du port scan), on obtiendrait une liste d'adresses interdites très importante on interdirait des connexions venant de nombreux systèmes n'ayant aucun rapport avec cette attaque, par exemple des clients ne pourraient plus accèder au site de leur fournisseur. Il est probable q'une attaque non spoofable conduise probablement moins à ce genre de problème. C'est pour cette raison que les adresses IP sont parfois partagées entre diffèrentes personnes; c'est le cas des ISP13 et d'autres services semblables.
Cette approche apporte des problèmes au niveau de l'implémentation : les listes d'accès des firewalls, les tables de routage, etc... ont tous une taille limitée. Aussi, même avant que la limite ne soit dépassée, il en découle une forte utilisation du CPU. Si un IDS ne prète pas attention à ces limites, il risque de mener à un déni de service sur le réseau entier (si c'est un firewall qui en est affecté). Par exemple si l'attaquant effectue un port scan spoofé avec les adresses de toutes les machines du réseau de ce fait aucune d'entre elles ne pourra accèder au serveur, elles seront bloquées par le firewall.
Je penses qu'il n'existe que très peu de cas où une prise de décision est réellement justifiée. Les port scans n'en font pas parties.
Une autre action classique consiste à se connecter sur la machine de l'attaquant afin de collecter plus d'informations à son sujet. Pour les attaque spoofables, nous ne pouvons nous permettre de nous connecter sur une machine d'une tierce-personne. Il vaut mieux ne pas agir face à ces attaques, dont les port scans font parties.
Par contre pour les attaques non spoofables, il peut être intéressant d'implémenter ces fonctionnalités mais avec d'infimes précautions. Nous devons faire attention de ne pas utiliser trop de ressources, y compris la bande passante (limiter le nombre de requêtes, limiter la taille des données), le temps CPU, et la mémoire. Évidemment, il se peut qu'un attaquant puisse arrêter ces requêtes, mais on ne peut rien faire dans ce cas précis.
Voir ftp://ftp.win.tue.nl/pub/security/murphy.ps.gz pour un exemple des problèmes invoqués. Cet article de WIESTE VENEMA détail les vulnérabilités similaires dans les anciennes version de son wrapper TCP.
Pour ces raisons, scanlogd ne fait rien d'autre que d'enregistrer les port scans. Vous prendrez vous les mêmes les actions en conscéquence. Vous pouvez tout d'abord consulter les fichiers de logs, que vous ne regardez pas habituellement, pour déceler une activité anormale proche de la date du port scan détecté, pour plus d'information vous pouvez consulter les docments appropriés du CERT disponible sur ftp://info.cert.org/pub/tech_tips/.