Bonjour,
 
voilà, j'ai un petit problème avec portsentry et shorewall. Je souhaite monter un serveur ouaibe sur ma mandrake 9.0. Or, pour tenter de sécuriser au mieux la machine, j'utilise shorewall pour configurer le firewall et je souhaite aussi faire tourner portsentry pour me protéger des petits malins adeptes du nmap à gogo.
 
 
Premier problème: j'ai du installer le rpm de la version 1.1 de portsentry, car pour la version 2.0b1, g pas trouvé de rpm. Or le problème que j'ai avec les source de la 2.0b1 c'est que quand je fais make, j'ai des erreurs !
Bon, passons ...
 
 
J'ai donc testé portsentry en faisant scanner ma machine depuis différents services de portscanning comme www.grc.com.
 

• Quand shorewall est désactivé ("shorewall stop" puis "shorewall clear" ), portsentry détecte les scans mais ne permet pas de les stopper. Un scan permet donc de détecter lesquels de mes ports sont ouverts ou fermé. Ce n'est que si je fais refaire un scan depuis le même hote que ma machine disparait (tous les ports sont "furtifs" ). Les log de portsentry confirment que l'hote a été repéré comme initiateur d'un scan et je peux vérifier qu'une règle a été ajoutée à iptables. Le problème est que je croyais que portsentry devait permettre de bloquer les scans en cours en réagissant immédiatement et pas seulement au scan suivant.

• Quand Shorewall est activé, portsentry ne semble plus fonctionner. Plusieurs scans successifs dévoilent toujours les mêmes résultats (tous les ports "furtifs" sauf le port 80 ouvert, ce qui est normal vu ma config firewall). Aucun hote n'apparait dans les logs de portsentry.

 
Il y a aussi quelque chose d'étrange avec shorewall, même avec la policy "DROP net fw" et avec le fichier rules vide, mes port 113 et 135 ne sont pas furtifs, ils apparaissent fermés lors d'un scan. Il faut que j'ajoute des règles explicites au fichier rules pour que ces ports soient furtifs.
 
 
Voilà pour l'exposé de mes problèmes. Si vous avez des explications ou des solutions pour un ou plusieurs des problèmes rencontrés ci-dessus, je vous remercie de bien vouloir m'en faire part.

donc ce que tu veux c'est bannir directement les IP au 1er port scanné avec portsentry ?
 
c'est un peu "idiot" au 1er scan, tu auras des soucis, vaut mieux bannir au 2ème scan détecté... ce que je veux dire, on va prendre un exemple, c'est que si tu as spécifié les ports 21, 25, 53, il faut mieux bannir au 2ème scan, c'est à dire que la personne aura un résultat "bloqué" sur le 21, puis arrivé sur le 25 son scan est encore bloqué, ou même son IP bannie en l'ajoutant en DROP dans le firewall ce qui lui fait un timeout "rhooo ! bah tiens il s'est déconnecté le môssieur !", mais en fait non, c'est juste que pour lui tu n'existes plus sur le net étant donné que toutes ses requètes vers ton IP sont refusées
 
tiens, voici la conf que j'avais un moment quand je l'utilisais (j'ai viré quelques commentaires pour que ça prenne moins de place) :
 

 
en espérant que ça va t'aider
 
 
edit : j'ai oublié de dire, quand tu as tes ports fermé "CLOSED" donc en DROP dans iptables, il est impossible que portsentry puisse se mapper sur le port, si tu regardes tes logs, tu verras qu'il prévient comme quoi il ne peut pas surveiller le port donné et marque aussi que le monitoring sur ce port est donc coupé
 
ben vi, ça sert à rien de surveiller un port fermé et donc indétectable en stealth mode

Petite idée concernant le 2ème problème
tu souhaites, lorsque le firewall est actif que portsentry fonctionne ... c'est ça ?
 
si j'ai bien compris alors :
Portsentry ouvre des ports particuliers et attend des connections sur ceux-ci qu'il considère comme du scan
 
as-tu pensé à ouvrir ces ports sur ton FW ?
sinon comment Portsentry peut-il fonctionner ...
 
si c'est bien la solution, j'en suis ravi  
sinon dis-le ce problème m'intéresse

Merci BMOTheKiller et Grizly,
effectivement il faut que le firewall laisse l'accès aux ports écoutés par portsentry. J'ai rajouté une règle ACCEPT pour les ports TCP et UDP que je souhaite faire surveiller par portsentry. Ces ports sont des ports inutilisés sur ma machine (donc fermés) mais susceptibles d'être scannés par un cracker. J'ai configuré portsentry en mode stealth (mode simple pas advanced) pour qu'il surveille ces ports. Dans ce mode, portsentry n'a pas besoin d'ouvrir les ports pour détecter du traffic, ce qui permet de les laisser fermés (seuls les ports 80 et 443 sont ouverts sur ma machine pour le serveur Apache). Quand un scan est détecté, la réaction de portsentry est de faire un "shorewall drop $TARGET$", ce qui fait que tous le traffic provenant de l'hote initiateur du scan est ignoré. De cette manière je fais disparaitre ma machine (y compris mon serveur Apache) aux yeux d'un hote potentiellement dangereux.
 
Par contre j'ai fait tester ma machine par plusieurs services de portscanning (grc, security metrics, PC flank ...) et j'ai toujours le même problème : Au premier scan, tout est visible sur ma machine, portsentry détecte le scan (vu le log) mais le scanner repère quels ports sont ouverts et quels ports sont fermés. Ce n'est que si je fais refaire un scan par le même service que ma machine semble avoir disparu. Pourtant j'ai mis SCAN_TRIGGER="1" dans la config de portsentry, ce qui voudrait dire que portsentry doit réagir dès le deuxième port scanné, pas au deuxième scan complet (si je mets SCAN_TRIGGER="0" ça ne change rien). Je vais essayer de scanner moi même ma machine avec nmap depuis une autre machine pour voir la réaction.

c'est normal (il me semble) ton problème, c'est qu'en fait les 1ers tests ne sont pas efectués en stealth mode, donc portsentry ne se sent pas concerné, par contre quand le test est effectué en mode caché, là portsentry réagit puisque configuré tel quel...
 
ce que tu peux faire, c'est ouvrir quelques ports pas dangereux du genre :
 
TCP/UDP 2, 3, 4, 6, 8, 10...
 
tu n'auras rien à l'écoute dessus, mais tu peux les ajouter dans portsentry pour qu'il les mappe, ensuite tu le mets en mode normal (non stealth) et là le petit joueur qui se lance avec nmap en scan tcp ou udp se fera jarter directement... pour certains problèmes avec des clients ftp par exemple (si tu mets un serveur ftp), il vaut mieux mettre scan trigger à 2 car sinon tu fermes directement la route à une personne non-indésirable (j'ai eu le cas il y a un moment, et donc bah la personne s'est retrouvée scotchée dans le firewall)
 
par contre tu es sûr d'amasser à la pelle des scanneurs, tous les jours en myenne je purgeais les drop, c'est fou quand même...