salut à tous,
Comment faire pour interdire l’accès à tous les protocoles
pour une ip (par exemple celle d’un hacker)
lorsqu’un scan de ports est détecté par le pare-feu
et ensuite envoyer une alerte administrative ?
voila un fil que je vais suivre… 
tiens après une petite recherche sur gogole j’ai trouvé ça : http://hlbr.sourceforge.net/index-fr.html
ca pourra peut-etre te servir.
tiens nous au courant 
Merci, il y a aussi un tutorial d’installation en video sur le site.
Je regarde ça.
EDIT : HLBR est très facile à installer mais pour le configurer c une autre histoire.
Je n’ai pas réussi à le faire démarrer.
Je continue mes recherches…
Bonsoir,
je pense qu’on doit pouvoir faire ça avec swatch
j’ai pas persevéré justement parce qu’il me semble pas trop facil à configurer … j’ai bifurqué sur syslog-ng, qui je le sens, va me plaire …
Maintenant, à dire que ce dernier est une solution, je ne le sais pas encore, mais claro que es un puissant tool !
En fait, il faut un daemon qui match les logs à la recherche de mots clé, style login=failed, et qui quand il le trouve lance un script qui écrit dans iptables une règles de drop pour l’ip source … à voir.
j’ai un prob avec ça :
j’ai appliqué le tuto de ricardo sur la config d’iptable
mais quand j’installe la mule, apres , ben pas de problème, donc tout est ouvert?
[quote=“usinagaz”]Bonsoir,
je pense qu’on doit pouvoir faire ça avec swatch
j’ai pas persevéré justement parce qu’il me semble pas trop facil à configurer … j’ai bifurqué sur syslog-ng, qui je le sens, va me plaire …
Maintenant, à dire que ce dernier est une solution, je ne le sais pas encore, mais claro que es un puissant tool !
En fait, il faut un daemon qui match les logs à la recherche de mots clé, style login=failed, et qui quand il le trouve lance un script qui écrit dans iptables une règles de drop pour l’ip source … à voir.[/quote]
ça peut être intéressant à tester mais le tuto est pour Gentoo.
Quelqu’un là déjà tester sous Sarge ou Etch ?
Ou alors quelqu’un a-t-il déjà adapter le tutorial pour Debian ?
dexmon, tu as réussi a installer LHBR ?
Il tourne sur le serveur et aparament fonctionne bien…, j’ai pas tous compris dans la config, mais d’apret les logs sa fonctionne…
[quote=“diod”]j’ai un prob avec ça :
j’ai appliqué le tuto de ricardo sur la config d’iptable
mais quand j’installe la mule, apres , ben pas de problème, donc tout est ouvert?[/quote]Que donne iptables-save ?
Le tuto de ricardo est explicatif. Les réglages qu’il donne sont spécifiques et doivent être adaptés à chaque cas. Il ne faut pas le prendre nécessaire ment au pied de la lettre.
[quote=“dexmon”]salut à tous,
Comment faire pour interdire l’accès à tous les protocoles
pour une ip (par exemple celle d’un hacker)
lorsqu’un scan de ports est détecté par le pare-feu
et ensuite envoyer une alerte administrative ?[/quote]qu’appelles tu “lorsqu’un scan de ports est détecté par le pare-feu” ? qu’est ce que tu considères comme déclenchant ?
je suppose lorsqu’un trop grand nombre de requêtes venant d’une même IP sont adressées au serveur dans un laps de temps donné (50 requetes en moins de 5 secondes ou un truc du genre…)
un truc du genre du “-m hashlimit” d’iptables ?
man iptables dit:
[code] hashlimit
This patch adds a new match called ’hashlimit’. The idea is to have something like ’limit’, but
either per destination-ip or per (destip,destport) tuple.
It gives you the ability to express
’1000 packets per second for every host in 192.168.0.0/16’
’100 packets per second for every service of 192.168.1.1’
with a single iptables rule.
--hashlimit rate
A rate just like the limit match
--hashlimit-burst num
Burst value, just like limit match
--hashlimit-mode destip | destip-destport
Limit per IP or per port
--hashlimit-name foo
The name for the /proc/net/ipt_hashlimit/foo entry
--hashlimit-htable-size num
The number of buckets of the hash table
--hashlimit-htable-max num
Maximum entries in the hash
--hashlimit-htable-expire num
After how many miliseconds do hash entries expire
--hashlimit-htable-gcinterval num
How many miliseconds between garbage collection intervals[/code]
PS: Salut à toi, pardon 
salut Matt 
Bonjour,
le truc déclenchant, ça pourrait être une ligne de log écrite par un daemon comme psad, swatch, qui consulte les logs en temps réel, trouve l’occurence, et lance un exec qui drop l’ip dans iptables.
Swatch est un paquet debian, donc il devrait pas y avoir de soucis, quand j’aurai terminé de configurer syslog-ng (qui peut aussi faire ça peut-être), je regarde comment faire pour swatch. Syslog-ng est un peu une amélioration de syslogd, c’est pourquoi je l’ai mis en priorité, on peut entrer les logs dans une database de mysql, et les consulter via l’interface php, sur localhost, ce qui est trés interessant, et on peut trier les logs de façon pointue (à affiner pas à pas évidemment).
[quote=“barbak”]salut Matt
[/quote]Nan, je parlais à dexmon. Toi tu dis pas plus bonjour que moi. Usinagaz avait dit bonsoir. 
rah lui éh 
Bonjour,
avant de me lancer dans un petit script pour ajouter à la volée des règles iptables, j’ai besoin de clarifier deux-trois trucs … 
D’abord, je reçois assez régulièrement des logs du kernel de ce style :
Etant donné que dans firestarter je ne drop pas le DPT 1080, comment ça se fait que lui ne me signale pas qu’il rejette ces paquets ? (normalement, il devrait se mettre à rouge, montrant qu’il vient de refuser une connection).
Autre exemple, pareil : [quote]
Oct 31 12:51:24 debian kernel: Inbound IN=eth0 OUT= MAC=00:0b:6a:7a:c4:98:00:15:56:11:c8:59:08:00 SRC=221.156.137.64 DST=192.168.1.100 LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=26268 DF PROTO=TCP SPT=1458 DPT=4899 WINDOW=64240 RES=0x00 SYN URGP=0 [/quote]
Donc, le DPT 4899 est aussi fermé, il n’est pas dropé, et pourtant firestarter ne me signale rien ? 
En plus, on a ici deux IP sources différentes pour une même adresse MAC, qui est bien l’adresse MAC de l’ip source non ? comment ça se fait ?
[quote=“usinagaz”]Bonjour,
avant de me lancer dans un petit script pour ajouter à la volée des règles iptables, j’ai besoin de clarifier deux-trois trucs … 
D’abord, je reçois assez régulièrement des logs du kernel de ce style :
Etant donné que dans firestarter je ne drop pas le DPT 1080, comment ça se fait que lui ne me signale pas qu’il rejette ces paquets ? (normalement, il devrait se mettre à rouge, montrant qu’il vient de refuser une connection).
Autre exemple, pareil : [quote]
Oct 31 12:51:24 debian kernel: Inbound IN=eth0 OUT= MAC=00:0b:6a:7a:c4:98:00:15:56:11:c8:59:08:00 SRC=221.156.137.64 DST=192.168.1.100 LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=26268 DF PROTO=TCP SPT=1458 DPT=4899 WINDOW=64240 RES=0x00 SYN URGP=0 [/quote]
Donc, le DPT 4899 est aussi fermé, il n’est pas dropé, et pourtant firestarter ne me signale rien ? 
[/quote]
Y a SYN qui s’affiche donc c’est une tentative d’ouverture de connexion et non pas un paquet appartenant à une connexion déja établie (par toi). Ensuite il faut voir du coté de tes regles iptables, je ne suis pas un expert, je laisse la place aux autres. Ta defaut policy est bien drop?
[quote]
En plus, on a ici deux IP sources différentes pour une même adresse MAC, qui est bien l’adresse MAC de l’ip source non ? comment ça se fait ?[/quote]
Ca c’est normal.
Exemple: Tu as 2 machines A et B et 1 routeur C.
A veut envoyer un paquet à B. (Il se rend compte que l’adresse de B n’est pas dans sous réseau) il envoie donc son paquet à C, sa passerelle par défaut.
La tronche du paquet est alors:
MAC SOURCE=MAC(A)
MAC DEST=MAC©
IP SOURCE=IP(A)
IP DEST=IP(B)
Donc dans ton cas, tu aura l’adresse MAC source de ton routeur dans les logs. Si tu n’as qu’une machine alors tu aura aussi comme MAC destination la mac de ta machine.
Zut !
Tu veux dire que c’est l’adresse MAC de ma livebox qui est affichée là ? c’est pas graignos ?
ma defaut policy … heu … avant c’était [size=150]ça[/size], quand firestarter me signalait plein de tentative de connection qu’il rejettait.
Maintenant, concernant mangle, filter, et nat, c’est :
[quote]
*mangle
REROUTING ACCEPT [4002:2140616]
:INPUT ACCEPT [4002:2140616]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4275:1400548]
OSTROUTING ACCEPT [4275:1400548]
…
*nat
REROUTING ACCEPT [89:20680]
OSTROUTING ACCEPT [434:19549]
:OUTPUT ACCEPT [434:19549]
…
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:INBOUND - [0:0]
:LOG_FILTER - [0:0]
:LSI - [0:0]
:LSO - [0:0]
:OUTBOUND - [0:0][/quote]
Et pourtant, il me semble pas avoir touché quoique ce soit de ce côté là, et c’est plus du tout les mêmes valeurs entre crochets …
je capte pas … c’est bien *filter, la default policy dont tu parles Boris ?