L’idée de panthere consiste à s’adapter à une tentative d’intrusion: il ne filtre rien mais «logue» tout (je pense), si une IP fait un certain nombre de tentatives sur un port SSH, il bannit l’IP pendant 24h. C’est une approche souple qui permet de faire toute fois un déni de service assez vite, il est très facile de faire des débuts de connexions avec des IP sources fausses (avec hping par exemple), il faudrait voir si ces connexions sont comptées ou pas. Si oui, on peut facilement faire déborder les tables d’iptables et mettre la machine dans un état second.
[quote=“fran.b”] iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 90 --hitcount 3 -j DROP
bloque le port ssh si il y a eu 3 connexions dans les 90 dernières secondes.
http://www.linux-france.org/prj/inetdoc/guides/iptables-tutorial/explicitmatches.html#recentmatch
Avec ftp, compte tenu des apt-get qui peuvent faire 5-6 connexions dans ce laps de temps, et de navigateurs qui ouvrent plusieurs connexions en même temps, j’ai porté ce nombre à 12.[/quote]
Tu as aussi opter pour le match recent comme je l’avais mentionné lors de mon premier post.
Ensuite, le match limit a été mentionné ainsi que le match iprange. Ce que j’essaye de dire ce n’est pas que son script est bien ou mal c’est que l’alternative au match recent employant limit et iprange ne fait pas du tout la même chose et par conséquent est beaucoup moins efficace et moins souple.
En fait Panthere c’est assez interessant comme pbm et effectivement, à mon avis, on doit pouvoir mettre ta machine à genoux:
Sur la machine serveur je met
iptables -I INPUT -p tcp -s 192.168.1.230 --dport 22 -j LOGdonc je logue les connexions venant de 192.168.1.230 (pour éviter de saturer les logs, j’ai limité les logs à cette adresse. De ma machine (d’IP 192.168.1.249 donc distincte de 192.168.1.230), je fais
Je vois apparaître dans les logs
et ceci 100 fois. Il est donc très facile si tu fais un système fondé sur ces logs de le faire saturer. Le module recent ne compte que les connexions établies donc n’est pas sujet à cet inconvénient.
En fait, la question est comment tu récupères les IPs à bannir? (A moins que je n’ai pas compris ton système).
Et bien filtrer tout afin de n’accepter aucune connexion inconnue, mal formée ou non autorisée, en logguant les paquets rejetées et droppés dans une certaine mesure revient à faire la même chose en plus sécurisé. Les logs sont analysés par un programme tiers qui a pour objectif de détecter les intrusions, et d’ajouter des règles pour adapter le firewall à cette situation.
Je ne vois pas dans quelle mesure, un firewall peut se permettre d’accpeter des connexions, et donc d’allouer des ressources pour elles sans même savoir si elles sont valides. Et ensuite, traiter ces connexions qui ont été logguées afin d’y mettre fin, ou de les laisser transiter. Cela signifie que l’on a accès à tous les services de la machine dans un premier temps, jusqu’à ce que l’on soit considéré comme n’ayant aucun droit (si l’on est détecté). Ensuite quant aux logs, je ne sais pas quelle place il octroie vu que j’ai mal aux yeux en lisant le script. Logguer tout recquiers une redirection vers une fifo de taille fixe et pas un fichier de log afin de ne pas faire tomber son serveur au moindre scan de la machine. La grande question pour moi est :
Comment faire pour rejeter des connexions frauduleuses, si l’on est pas capable de toutes les identifiées ? On les laissent passer alors !
[quote=“fran.b”]En fait Panthere c’est assez interessant comme pbm et effectivement, à mon avis, on doit pouvoir mettre ta machine à genoux:
Sur la machine serveur je met
iptables -I INPUT -p tcp -s 192.168.1.230 --dport 22 -j LOGdonc je logue les connexions venant de 192.168.1.230 (pour éviter de saturer les logs, j’ai limité les logs à cette adresse. De ma machine (d’IP 192.168.1.249 donc distincte de 192.168.1.230), je fais
Je vois apparaître dans les logs
[/quote]
C’est la que vient le fait de logguer en utilisant le match limit (idem que d’utiliser la target REJECT tout le temps ; des solutions ont été proposé par l’utilisation du match random) afin de ne pas épuiser la place disponible. Beaucoup de monde loggue tout, et en scannant leur machine c’est une écatombe car c’est le firewall qui la fait tomber. Pour ma part, j’avais laissé une règle de log que j’utilisais pour faire mes tests, et le lendemain matin, mon serveur était sur les rotules : 8000 mails, plus d’espace disque, certains services coupés …
Fran.b a écrit:
Je ne veux pas rentrer dans le débat mais ce point est faux. Une connexion = (IP-source+port,IP-destination+port).
Un serveur (i.e un programme bien précis) écoute sur un port précis et un port en écoute ne sert qu'une application: Le port est donc fixé et des défauts (modifiables) sont donnés (cf fichier /etc/services)tu as je supose louper une petie partie,qui disait
S’il s’agit d’un nouvelle connections qui veux savoir sur qu’elle port elle peut ce connecter si un port est déjà occuper elle ne pourra pas. par contre on peux <> que tel port correspond a tel application. mai rien n’empêche d’avoir plusieurs application qui veule une réponse sur le même port le port 80, mai pas en même temps <<1 seul par port>
thialme a écrit
A toi d’ajuter le temp et a toi d’ajuster la plage d’ip
Plus la plage est grande plus le risque est grand et pour ma part le serveur a une ip fix de même pour le client ce qui m’arrange bien.
Et pour ma par un zouave qui fait + de 30 connections dans la journée est trop a mon gout je ferme la connections. c’est a dire avec un ban sur l’ip du zouave, et je laisse le port ouvert. l’ip est bannie durant 24/h car elle change a peut près dans ces heure la (enfin je croit) s’il elle n’est pas fixe.
et non pas fermer le port et laisser l’ip recommencer sure un autre port. simple efficace. par contre si on a pas une ip fix je pense que la solution de fran.b est mieux.
Fran.b a demander
un petit indice 
lsof -i -Psinon un petit exemple en console (adapter a vos besoin)
tail -f '/var/log/ulog/syslogemu.log' | grep DPT=138 -m3 |cut -d"=" -f5 | cut -d"D" -f1
ou si on veux juste le nombre de foit ou l'ip c'est connecter
tail -f '/var/log/ulog/syslogemu.log' | grep DPT=138 -m3 |cut -d"=" -f5 | cut -d"D" -f1|wc -ldonc la je vise le port 138 avec un maximum de 3 sortie , ensuite on filtre pour avoire l’ip. voire juste le nombre de ligne
pour la suite ben si plus de 3 par ip on ferme l’ip,
On a plus d’entrée pour cette ip, donc aprait c’est plus loguer
donc on peux aussi loguer en script, fixer une limite, et comme l’ipt est bannie on peut effacer les variable ce qui fait qu’on ne peut pas faire planter la machine
Pas si on ferme la connections avant!
mais sur un serveur Web, un proxy peut se connecter plusieurs centaines de fois. Sur mes serveurs cela arrive fréquemment. (Ainsi, le 2 septembre, une IP a fait 229 connexions, les 10 plus gros du mois sont à plus de 200 connexions en 24heures, la moyenne étant de 6-7 connexions en gros).
Là, OK tu auras les connexions actives mais tu rates sans doute les essais de connexions en ssh (plus furtif) à moins que tu passes ton temps à faire cette commande.
C’est ce que je pensais. Donc là tu es sensible à l’attaque en deni de service que j’ai décrite. Essayes là.
[quote]
Pas si on ferme la connections avant![/quote]
Malin, comment le faire sans soit bannir l’adrersse source (qui est fausse et qui peut être une de tes machines), soit couper le serveur.
Ton idée est bonne mais il faut revoir la capture des IPs. Par ailleurs tu as une mauvaise idée de ce que fait un serveur.
[quote=“fran.b”] iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 90 --hitcount 3 -j DROP
bloque le port ssh si il y a eu 3 connexions dans les 90 dernières secondes.
http://www.linux-france.org/prj/inetdoc/guides/iptables-tutorial/explicitmatches.html#recentmatch
Avec ftp, compte tenu des apt-get qui peuvent faire 5-6 connexions dans ce laps de temps, et de navigateurs qui ouvrent plusieurs connexions en même temps, j’ai porté ce nombre à 12.[/quote]
je m’excuse d’être bête ou d’avoir sauté une explication mais je viens d’essayer ces règles et la machine distante ne se fait pas droper
alors 2 possibilités : étant donné que je me loggue en ssh sur la machine distante qui se loggue chez moi, quand celle-ci fait un ssh root@mon.ip les paquets ne sont pas classés en NEW
quand la personne en question fait ses tentatives, dès la deuxième, les paquets ne sont plus classés en NEW étant donné qu’il y a déjà eu envoi de paquets des 2 cotés
sinon, petite question, je ne devrais pas me créer une petite liste à la main avec
iptables -A INPUT -m recent --name examplelistle tout dans une chaine utilisateur et travailler dedant ?
Je ne vais pas continuer et me fatiquer à répondre pour débattre sur quelque chose qui n’est pas clair. Donne moi un exemple précis avec tes règles et on verra ensuite, car pour le moment j’ai de plus en plus l’impression que l’on ne discute pas de la même chose. Dans mon firewall, l’utilisation du match limit et iprange pour la limitation d’accès à un service est à proscrire car trop statique. Ton exemple ?
[quote=“antalgeek”][quote=“fran.b”] iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 90 --hitcount 3 -j DROP
[/quote]
je m’excuse d’être bête ou d’avoir sauté une explication mais je viens d’essayer ces règles et la machine distante ne se fait pas droper
alors 2 possibilités : étant donné que je me loggue en ssh sur la machine distante qui se loggue chez moi, quand celle-ci fait un ssh root@mon.ip les paquets ne sont pas classés en NEW
quand la personne en question fait ses tentatives, dès la deuxième, les paquets ne sont plus classés en NEW étant donné qu’il y a déjà eu envoi de paquets des 2 cotés
[/quote]
Les règles ci dessus autorisent 2 nouvelles connexions (NEW) SSH toutes les 90s. Ensuite, elles fonctionneront si elles sont correctement placées dans ton script, et qu’il y a une gestion des connexions ESTABLISHED ailleurs. Vérifie que la première règle récupère bien des paquets avec la commande iptables -L -v -n. Si le compteur est nulle alors les règles sont mal placées, autrement on verra :p!
Pour ce qui est des états NEW … regarde dans la section T&A, le thread sur iptables. J’ai normalement expliqué cela. Autrement, dans les howtos, tu y trouveras la solution. Si tu ne comprends pas, envoie un mp.
[quote]
sinon, petite question, je ne devrais pas me créer une petite liste à la main avec
iptables -A INPUT -m recent --name examplelistle tout dans une chaine utilisateur et travailler dedant ?[/quote]
C’est préférable de fixer un nom pour la liste quand on en utilise plusieurs. Cela marchera mieux.
[quote=“antalgeek”][
je m’excuse d’être bête ou d’avoir sauté une explication mais je viens d’essayer ces règles et la machine distante ne se fait pas droper[/quote]
francois@totoche:~$ ssh serveur
Linux serveur 2.4.19-Tripatouille-F.B #1 mar jui 20 08:31:09 CEST 2004 i686 unknown
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
No mail.
francois@serveur:~$ logout
Connection to serveur closed.
francois@totoche:~$ ssh serveur
Linux serveur 2.4.19-Tripatouille-F.B #1 mar jui 20 08:31:09 CEST 2004 i686 unknown
[..]
francois@serveur:~$ logout
Connection to serveur closed.
francois@totoche:~$ ssh serveur
Linux serveur 2.4.19-Tripatouille-F.B #1 mar jui 20 08:31:09 CEST 2004 i686 unknown
[..]
francois@serveur:~$ logout
Connection to serveur closed.
francois@totoche:~$ ssh serveur
et là plus rien
Attention, cela interdit les nouvelles connexions, pas les connexions existantes: Un session ssh existante venant de la dite machine continue de fonctionner (heureusement d’ailleurs). Un essai de mot de passe = une connexion, ce sont les nouvelles connexions qu’il faut empêcher.
[quote]
alors 2 possibilités : étant donné que je me loggue en ssh sur la machine distante qui se loggue chez moi, quand celle-ci fait un ssh root@mon.ip les paquets ne sont pas classés en NEW
quand la personne en question fait ses tentatives, dès la deuxième, les paquets ne sont plus classés en NEW étant donné qu’il y a déjà eu envoi de paquets des 2 cotés
sinon, petite question, je ne devrais pas me créer une petite liste à la main avec
iptables -A INPUT -m recent --name examplelistle tout dans une chaine utilisateur et travailler dedant ?[/quote]
Refais bien l’essai, tu peux voir l’état de la table dans
/proc/net/ipt_recent/DEFAULT
~$ grep 192.168.1.249 /proc/net/ipt_recent/DEFAULT
src=192.168.1.249 ttl: 64 last_seen: 188776089 oldest_pkt: 0 last_pkts: 181378794, 181934971, 182224692, 182597461, 182687310, 182687940, 182696743, 183133090, 188737713, 188738110, 188738466, 188738805, 188739104, 188739704, 188740904, 188743304, 188748103, 188764629, 188771679, 188776089
nc -z -vv -w 2 192.168.0.1 22 22 22 22 22C’est plus facile! Ok je sors, mais juste un dernier point après je vous laisse tous tranquilles.
Pour éviter le time out des connexions, il faut penser à utiliser la target REJECT (conformément au protocole TCP) plutôt que la target DROP. Ensuite, pour limiter l’utilisation de la target REJECT, il y a plusieurs solutions, mais on sort du cadre :p!
C’est juste parceque cela m’énerve les connexions droppées. On est quand même sensé avertir l’utilisateur que le service n’est pas disponible. On lance une connexion ssh chez quelqu’un et on ne sait même pas si son serveur est down, ou si on est considéré comme un malfaiteur. Un firewall doit respecter les protocoles dans la mesure du possible.
[quote=“thialme”]
nc -z -vv -w 2 192.168.0.1 22 22 22 22 22C’est plus facile!
[/quote] exact…
[quote]
Ok je sors, mais juste un dernier point après je vous laisse tous tranquilles.
Pour éviter le time out des connexions, il faut penser à utiliser la target REJECT (conformément au protocole TCP) plutôt que la target DROP. Ensuite, pour limiter l’utilisation de la target REJECT, il y a plusieurs solutions, mais on sort du cadre :p!
C’est juste parceque cela m’énerve les connexions droppées. On est quand même sensé avertir l’utilisateur que le service n’est pas disponible. On lance une connexion ssh chez quelqu’un et on ne sait même pas si son serveur est down, ou si on est considéré comme un malfaiteur. Un firewall doit respecter les protocoles dans la mesure du possible.[/quote]
As tu une référence en Français sur ces points précis. Je suis assez de ton avis là dessus mais le but pour ssh est de ralentir le plus possible un script. Un reject le fera passer immédiatement à la cible suivante, un drop le fait poireauter…
Si tu as une référence, ce serait bien de la mettre dans le T&A d’ailleurs.
(Dans les trucs crispants, tu as également le drop des pings, ça m’énerve aussi…)
yeah man ! 
marche bien !
il me fallait juste être un peu rigoureux…et relire aussi les différentes doc ainsi que refaire un tour dans T&A
travailler propre en bref
si vous en êtes d’accord je vais placer ce fil en résolu, à moins que vous ayez encore des choses à y placer
En fait on arrive également à leurrer le module recent: Comment rendre avaugle une machine
Simultation:
De 192.168.1.249 je fais
Puis je me connecte sur la machine 192.168.1.248, elle est incapable de se connecter au serveur ssh pendant 3mn. Donc en balyant toutes les IPs de 1 à 254 et en envoyant 5 paquets:
for i in `seq 1 254` ; do hping --fast -c 10 -S -p 22 -a 192.168.1.$i serveur ; doneon arrive à isoler un serveur du LAN de l’extérieur mais il faut répéter l’oprétion continuellement. 8 minutes sont nécessaires pour faire le tour, il est donc nécessaire de lancer plusieurs hping en parallèle pour faire tenir la boucle sur 3 minutes.
C’est assez amusant, je me bloque de cette manière l’accès à mon serveur sans pouvoir rien faire. Par ailleurs je remplis la table ipt_recent. Donc il est aussi possible de mettre à genoux un serveur protégé par recent en saturant la table par la commande
Cette commande remplit la table /proc/net/ipt_recent/DEFAULT à une vitesse V. Je n’ai pas envie de planter mon serveur (qui sert en production) mais je serais curieux de voir ce que donne cette commande, si effectivement elle plante le serveur.
Thialme, tu essayes??
[quote=“fran.b”]
As tu une référence en Français sur ces points précis. Je suis assez de ton avis là dessus mais le but pour ssh est de ralentir le plus possible un script. Un reject le fera passer immédiatement à la cible suivante, un drop le fait poireauter…
Si tu as une référence, ce serait bien de la mettre dans le T&A d’ailleurs.
(Dans les trucs crispants, tu as également le drop des pings, ça m’énerve aussi…)[/quote]
Oui le ping aussi c’est énervant, on est obligé de faire du telnet sur un service que l’on sait fonctionner sur la machine distante.
Pour ma part, je limite les REJECT de la manière suivante, sachant que tous les paquets que je veux droppés sont envoyés vers la chaine utilisateur reject_all.
# Create user-defined chains needed to sort rejected packets
iptables -N reject_all
iptables -N reject_tcp
iptables -N reject_udp
iptables -N reject_icmp
# Redirect packets according to the protocol used and log it
#iptables -A reject_all -j LOG --log-prefix "DROP" --log-level warning
iptables -A reject_all -p tcp -j reject_tcp
iptables -A reject_all -p udp -j reject_udp
iptables -A reject_all -p icmp -j reject_icmp
iptables -A reject_all -j DROP
# Set a reject rule for each protocol.
# The limit directive allow bursts of five packets, by default. Then the amount of packets
# in the following rules should be a multiple of 5, unless you specify --limit-burst
iptables -A reject_tcp -p tcp -m limit --limit 5/sec -j REJECT --reject-with tcp-reset
iptables -A reject_udp -m limit --limit 5/sec -j REJECT --reject-with icmp-port-unreachable
iptables -A reject_icmp -m limit --limit 5/sec -j REJECT --reject-with icmp-proto-unreachableet pour mes règles ftp et ssh cela fonctionne de la façon suivante :
# Enable people to connect to my FTP server (1 hit / 300s)
# As a matter of fact, this allows 3 connection attempts (login/password)
iptables -A wan_in_new -p tcp --dport 21 -m recent --set --name ftp_hits_list
iptables -A wan_in_new -p tcp --dport 21 -m recent --rcheck --seconds 300 --hitcount 2 --name ftp_hits_list -j reject_all
# Port 21 a verrouiller, ainsi que 2000-2020 (SSL avec ftp_conntrack ne fonctionne pas)
iptables -A wan_in_new -p tcp --dport 21 -j ACCEPT
iptables -A wan_in_new -p tcp --dport 2000:2020 -j ACCEPT
# ============================= #
# Deal with port knocking #
# ============================= #
# Should be replaced by SPA
# Manage all chains for the different stages of the port knocking
iptables -F ssh_phase2 2>/dev/null
iptables -F ssh_phase3 2>/dev/null
iptables -X ssh_phase2 2>/dev/null
iptables -X ssh_phase3 2>/dev/null
iptables -N ssh_phase2
iptables -N ssh_phase3
# 2 - Deal with the second stage :
# - Create the entry for the second stage
# - Remove this entry from the first stage
iptables -A ssh_phase2 -m recent --set --name list_knock_2
iptables -A ssh_phase2 -m recent --remove --name list_knock_1
# 3 - Deal with the third stage
# - Add the entry to list_ssh
# - Remove this entry from the second stage
iptables -A ssh_phase3 -m recent --set --name list_ssh
iptables -A ssh_phase3 -m recent --remove --name list_knock_2
# 4 - Define all stages for the knock sequence
# - stage 1 : touch 18556/tcp
# - stage 2 : touch 14820/tcp
# - stage 3 : touch 17032/tcp
iptables -A wan_in_new -p tcp --dport 18556 -m recent --set --name list_knock_1
iptables -A wan_in_new -p tcp --dport 14820 -m recent --rcheck --seconds 1 --name list_knock_1 -j ssh_phase2
iptables -A wan_in_new -p tcp --dport 17032 -m recent --rcheck --seconds 1 --name list_knock_2 -j ssh_phase3
iptables -A wan_in_new -p tcp --dport 22 -m recent --rcheck --seconds 5 --name list_ssh -j ACCEPTLe port knocking peut paraitre intéressant et efficace mais reste contriagnant, et déjouable.
L’autre alternative est fwknop, plus sécurisée.
Ensuite viens une méthode qui n’est pas à piquer des hannetons. Le principe consiste principalement à utiliser random pour fournir des résultats absurdes au client.
C’est en anglais :
target chaos
Et la personne travaille actuellement dessus. Je ne l’ai pas vu disponible pour le moment. En tout cas cela me semble intéressant comme approche.
C’est cela que tu cherchais ?
[quote=“fran.b”]
Thialme, tu essayes??[/quote]
Je vais tester.
encore quelques questions neuneu car je suis presque aussi bete que les types qui m’attaquent
je me suis loggé sur ma machine au boulot pour faire des essais et puis j’ai lancé un script qui passe son temps à lancer des nouvelles connexions ssh chez moi
etant donné que j’ai mis le décompte à 10, au bout de 10 tentatives la machine distante s’est fait jeter, normal
la question : comment faire pour autoriser de nouveau la machine distante à tenter sa chance
je m’en suis sorti en ajoutant une règle autorisant les connexions depuis cette machine dans ma chaine utilisateur mais je ne vais peut-être faire ca pour tous les potes qui veulent se logguer chez moi ou qui font des tests
est-ce que je peux remettre ca à zéro en virant le fichier /proc/net/ipt_recent/DEFAULT ?
le tout sachant que je ne veux pas le faire sur timeout ou en auto mais à la main
edit : a peut-être trouvé ne serait-ce pas avec un -m recent --remove ?
La seule parade que je vois à quelque chose de ce genre est de mettre en place des règles dynamiques pour bannir une ip qui a été détectée comme dangereuse. Ainsi, elle serait automatiquement droppées sans pouvoir contribuer à la saturation de la table recent.
C’est ce que fait fail2ban en fait, je crois, j’ai jamais utilisé.
J’ai pas encore commencé à jouer avec la mise en place de règle dynamique, mais j’ai cela sous le coude avec le livre LinuxFirewalls écrit par l’auteur de fwknop (le lien que j’ai donné)
Bon cela fait plus de 20 minutes avec deux scripts en // et tjs en vie. Je ne pense pas que le serveur va êre mis down mais bon on attends jusqu’à ce que cela coince ou que j’aille au lit. Actuellement c’est mon post client qui est en train de rendre l’âme :p!.
[quote=“antalgeek”]
la question : comment faire pour autoriser de nouveau la machine distante à tenter sa chance
je m’en suis sorti en ajoutant une règle autorisant les connexions depuis cette machine dans ma chaine utilisateur mais je ne vais peut-être faire ca pour tous les potes qui veulent se logguer chez moi ou qui font des tests
est-ce que je peux remettre ca à zéro en virant le fichier /proc/net/ipt_recent/DEFAULT ?
le tout sachant que je ne veux pas le faire sur timeout ou en auto mais à la main
edit : a peut-être trouvé ne serait-ce pas avec un -m recent --remove ?[/quote]
Je dirais que si.