je suis arrivé au bout de mes tests concernant portsentry en le mettant en place selon le tuto.
Malheureusement, mes tests sont un peu décevants :
d’une part sur la machine attaquante, lors du premier scan, je reçois quand même certains voire tous les ports ouverts, de la machine “protégée”. Pas lors des scans suivants.
d’autre part, la machine attaquante n’est pas forcément inscrite dans les règles iptables après la première attaque.
J’ai exploré l’option stealth (stcp et sudp) plutôt que a (atcp et audp) mais sans changement.
Enfin, je précise que ces tests ont été fait sur le réseau local.
en fait, c’était un peu ridicule d’attendre d’être “défendu” contre un “attaquant” qui ne s’est pas encore dévoilé ! Portsentry ne bannit que des adresses qui auront tenté un scan et donc, nécessairement obtenu des résultats.
Les petites différences que j’observe sont probablement dues à la manière dont nmap scanne (les ports dans l’ordre 1, 2, etc. … ou bien de manière aléatoire), des ports légitimement ouverts et du temps de réaction de portsentry.
Ce que je ne comprends pas maintenant, c’est pourquoi on prend 3 contre mesures : route reject, hosts.deny et iptables. Iptables ne suffirait-il pas tout seul ?
En premier, je cherche à protéger ma machine (autohébergement) des intrusions. Iptables et fail2ban sont opérationnels et, j’espère, convenablement configurés, et en tous cas conformément aux tutos que je trouve ici.
Portsentry est donc une troisième mesure, qui me semble utile.
En second, j’ai grandi dans le plaisir d’apprendre et de comprendre. J’explore donc les différents paramètres, possibilités, je teste et j’en tire des conclusions pour ma configuration.
[quote=“legaub”]En premier, je cherche à protéger ma machine (autohébergement) des intrusions. Iptables et fail2ban sont opérationnels et, j’espère, convenablement configurés, et en tous cas conformément aux tutos que je trouve ici.
Portsentry est donc une troisième mesure, qui me semble utile.[/quote]
Je pense que tu as bien compris que :
Iptables est une protection static réseau, donc une fois configuré la protection ne varie pas.
Fail2ban est une protection dynamique applicative, donc scan les logs des applications pour détecter des attaques
PortsEntry est protection dynamique réseau, donc cherche des pattern d’attaque sur les ports d’entré de la machine
En toute logique il manque une protection static applicative mais cela se configure au niveau de chaque application.
Peut être que les règles appliquées par PortsEntry ne sont pas assez restrictives à ton goût. De toute manière il faut bien que l’attaquant fasse diverses actions sur ta machine pour se faire repérer.
je ne crois pas que je l’avais compris aussi clairement que tu l’exprimes. Tu as précisé le vocabulaire qui me manquait, merci.
Si j’ai bien compris, la protection static applicative, je l’ai mise en place, par exemple, en restreignant les adresses d’accès dans les fichiers de config apache.
[quote]cherche des pattern d’attaque sur les ports d’entrée de la machine[/quote]Je ne connais pas cette notion de “pattern” d’attaque. Chaque attaquant possède donc ses propres ports “fétiches” qu’il teste prioritairement ? Il faudrait les repérer, puis renseigner portsentry.conf ? Pour le coup, c’est un peu fastidieux.
[quote]Peut être que les règles appliquées par PortsEntry ne sont pas assez restrictives[/quote]En fait, c’est plutôt le contraire : pourquoi une règle iptables ne suffit-elle pas ?
Dans tous les cas, merci encore pour ce post très éclairant.
je ne crois pas que je l’avais compris aussi clairement que tu l’exprimes. Tu as précisé le vocabulaire qui me manquait, merci.
Si j’ai bien compris, la protection static applicative, je l’ai mise en place, par exemple, en restreignant les adresses d’accès dans les fichiers de config apache.
[/quote]
Exactement, mais ça fonctionne aussi avec la configuration de ton serveur SSH, FTP ou tout autre.
[quote=“legaub”]
En fait je pense que PortsEntry fonctionne par schéma d’attaque. Il repère les comportement douteux. Par exemple un scan de tout les ports par ordre croissant. Il devrait le détecter rapidement et bannir l’IP, ce qui empêche l’attaquant de finir ce qu’il espérait. Un scan plus évolué testerait les ports par ordre aléatoire. Là PortsEntry le détectera aussi et le bloquera de la même manière car il s’appercoit que cette IP demande beaucoup de chose en peu de temps.
Bon c’est le jeu du chat et de la sourie il y a toujours une attaque pour percer une défense.
Ce que je veux te dire c’est que PortsEntry doit laisser passer quelques tentatives de l’attaquant pour le repérer et le stopper.
PortsEntry s’appuie sur Iptable pour bloquer l’attaquant, et a moins que tu ne connaiises tout les IP des attaquant passé, présent et futur il faut bien un «agent» qui les ajoutes au fur et a mesure.
Quand tu dit :
Ça me parait être le fonctionnement normal, il laisse passer la première tentative car il n’a aucun moyen de savoir que c’est frauduleux mais bloque le reste ensuite. D’ailleurs quel est ton outil de scan ?
Pour ça par contre je n’ai pas d’explication :
[quote=“legaub”]
Dans tous les cas, merci encore pour ce post très éclairant.[/quote]
De rien
[quote]Ce que je veux te dire c’est que PortsEntry doit laisser passer quelques tentatives de l’attaquant pour le repérer et le stopper.[/quote][quote]Ça me parait être le fonctionnement normal, il laisse passer la première tentative car il n’a aucun moyen de savoir que c’est frauduleux mais bloque le reste ensuite.[/quote]Je suis d’accord, je l’ai compris dans un second temps
[quote]PortsEntry s’appuie sur Iptable pour bloquer l’attaquant[/quote]Là, j’ai opté pour un moyen terme avec KILL_RUN_CMD_FIRST = “1” qui appliquera la règles iptables avant les autres mesures.[quote]D’ailleurs quel est ton outil de scan ?[/quote]J’utilise sans réfléchir la commande nmap du tutonmap -v -PN -p 0-2000,60000 192.168.n.28mais je teste sur une unique machine … je m’attaque moi-même et ça ne me paraît pas très rigoureux !
D’ailleurs, après nettoyage (hosts.deny, route et iptables) et reconfiguration, unservice portsentry restartpuis une attaque ne provoque plus de détection, je suis obligé de redémarrer
Oui le fait que tu boucle sur ta machine n’est pas le mieux, monte une VM pour faire l’attaquant en prenant soin de lui donner une IP propre.
Pour nmap fait attention a ne pas utiliser une option qui «camoufle» le scan, c’est un outil puissant et pas forcement facile à maitriser.
Bon je voie que tu es sur la bonne voie alors
C’est quoi le gain de bannir ce genre de profil ?
Est-ce qu’un scan est fait forcement par des méchants ?
Est-ce qu’un scan est nuisible pour ton infrastructure ?
Quel est le risque d’un scan ?
Donc tu ne ferme jamais ta maison ni ta voiture, ton portable n’a pas de code PIN et quand tu fait quelque chose de répréhensible tu le fait devant témoin …
Vraiment n’importe quoi ta remarque
Je ne vais pas discuter avec toi car on sais tous que tu es omniscient
[quote]
Donc tu ne ferme jamais ta maison ni ta voiture, ton portable n’a pas de code PIN et quand tu fait quelque chose de répréhensible tu le fait devant témoin … [/quote]
Non.
C’est le comportement de Linux :
[quote=“haleth”]
C’est le comportement de Linux : si aucun processus n’est en écoute sur ce port, alors le paquet n’est pas utile et est supprimé.[/quote]
Mettre deux cadenas sur une serrure n’est pas vraiment utile … plutôt encombrant.
