Scanlogd

Support Debian
#1

Salut à tous,

J’ai installé sur ma Etch le paquet scanlogd
openwall.com/scanlogd/
qui sert à logguer les scans de port.

Le paquet est installé sans soucis:

romain@malibu:/var/log$ sudo dpkg -l scanlogd Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii scanlogd 2.2.5-2 A portscan detecting tool romain@malibu:/var/log$

Le daemon tourne:

romain@malibu:/var/log$ ps -aux | grep scanlogd Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html scanlogd 18684 0.0 0.2 1788 260 ? Ss Mar19 0:00 /usr/sbin/scanlogd romain 20938 0.0 0.5 3280 636 pts/0 S+ 09:11 0:00 grep scanlogd romain@malibu:/var/log$

Pourtant aucun log n’est produit:

romain@malibu:/var/log$ sudo grep scan syslog romain@malibu:/var/log$
Une idée ?

Merci

#2

bonjour,
ben je me dis que tant qu’il n’y a pas de scan, il n’y a pas de logs probablement.
Assures toi d’abord de l’emplacement du fichier de log (regardes dans le fichier de conf de scanlogd) et vois si tu le trouves dans /var/log …
Sinon, balance ton adresse IP (si dynamic, et externe, celle du routeur si derrière un routeur), et je te fais un pti scan pour voir si scanlogd logue celà … :smiley:

#3

fais un dpkg -L pour voir quel fichier de conf correspond.
Parfois aussi, il y a un piti fichier dans /etc/default, avec un flag qui empêche le service de démarrer (pour éviter que ça démarre sans config).
Par ailleurs, il faut parfois “toucher” un fichier de log utilisé par une appli (quand elle n’utilise pas le logger) pour qu’elle puis y déverser ses traces.
Mais essayes déjà de voir comment c’est configuré, et regardes les messages quand tu restarte le démon (/etc/init.d/scanlogd restart).
En bref, donnes nous des éléments de configuration ou de logs, parceque comme ça :unamused:

#4

Voici la liste des fichiers du paquet:

root@malibu:/var/log# dpkg -L scanlogd /. /usr /usr/sbin /usr/sbin/scanlogd /usr/share /usr/share/doc /usr/share/doc/scanlogd /usr/share/doc/scanlogd/copyright /usr/share/doc/scanlogd/P53-13.gz /usr/share/doc/scanlogd/changelog.Debian.gz /usr/share/man /usr/share/man/man8 /usr/share/man/man8/scanlogd.8.gz /var /var/run /var/run/scanlogd /etc /etc/init.d /etc/init.d/scanlogd root@malibu:/var/log#

Le man révèle que:

Dans mon syslog.conf, j’ai:

Mais:

root@malibu:/var/log# grep scan daemon.log root@malibu:/var/log#
Enfin, un redémarrage de scanlogd n’est pas très bavard:

Mar 20 11:17:02 malibu /USR/SBIN/CRON[20996]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Mar 20 11:21:27 malibu exiting on signal 15 Mar 20 11:21:28 malibu syslogd 1.4.1#18: restart.

#5

Il n’y aurait pas de fichier de conf alors ?
mais je te répète que peut-être, il n’y a écriture de logs qu’en cas de scan.
Peut-être que tu devrais lire : /usr/share/man/man8/scanlogd.8.gz
Pour cela, tu ouvres un onglet du navigateur, tu entres :
file:///usr/share/man/man8/scanlogd.8.gz et à l’invite “ouvrir avec le gestionnaire d’archive”, tu fais ok, tu extrais, tu modifie l’url en enlevant le .gz, et peut-être que ça t’expliquera le pourquoi du comment.
Sinon, tu te fais scanner, et tu relances ton grep …

#6

Salut,

bon je reviens avec quelques éléments de réponse.
La passerelle est scanné, cela ne fait aucun doute.
Il y a un an, il y avait à la place de cette passerelle un PC Window$.
Le parefeu passait son temps à prevenir des scans.

J’ai fait un test de scan en local, depuis la passerelle avec nmap. (nmap 127.0.0.1)
Une alerte est loggué dans /var/log/daemon.log

J’ai refait un test depuis un poste Window$ du LAN avec superScan.
Aucune alerte levée.

J’ai refait un test depuis le même poste mais booté sous Ubuntu, et avec nmap.(nmap 192.168.0.1)
Cette fois une alerte.

Il semble donc que le script ne soit sensible qu’à la méthode nmap des scans.

Du coup je vais me tourner vers PortSentry qui semble plus abouti.

A voir…

#7

Retour d’expérience:
PortSentry est bien MAIS il crée des faux positifs avec ChkRootkit.

Typiquement, voici une alerte levée par ChkRootKit:

Or après controle, ces ports sont bels et biens fermés.

Donc je pense que je vais partir vers un SNORT.
C’est lourd mais c’est le seul restant…

#8

Salut à tous,

Je reprends ce post longtemps après pour faire un petit retour.

Après avoir essayé de nombreux outils, j’ai finalement installé PSAD pour faire la détection des scans de ports.

PSAD existe en package sous Debian.

Contrairement à d’autres outils, PSAD ne fonctionne pas comme un sniffer mais il fait de la corrélation de logs du parefeu.
Il faut donc au préalable modifier les règles du parefeu pour qu’elles loguent tous les paquets reçus sur des ports filtrés.
Puis, à partir de la corrélation des logs produits, PSAD parvient à détecter le scans de ports, identifier le système qui a fait le scan, et même parfois, identifier l’exploit qui est utilisé.

Cet outil est très bien eexpliqué dans ce bouquin:
Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort
amazon.fr/Linux-Firewalls-De … 85&sr=8-10