Port bloqué par ip tables mais alerte SNORT quand meme
Port bloqué par ip tables mais alerte SNORT quand meme - réseaux et sécurité - Linux et OS Alternatifs
Marsh Posté le 07-12-2007 à 10:24:32
Oulah malheureux ! Par défaut quand tu flush les iptables, les règles se mettent tous en ACCEPT. Après un "iptables -F ", il faut faire un "iptables -A INPUT -j DROP". Là, tes ports sont tous accessibles du numéro 1 au 65000.
Message édité par czh le 07-12-2007 à 10:25:50
Marsh Posté le 07-12-2007 à 10:27:10
-P est fait pour les politiques par défaut...
---------------
Relax. Take a deep breath !
Marsh Posté le 07-12-2007 à 22:25:08
bon ben meme avec les DROP par defaut, j'ai toujours les meme alerte
Marsh Posté le 08-12-2007 à 08:25:25
Même remarque que o'gure, je ne vois pas, dans ce que tu montres, où, par défaut, tu droppes les paquets ...
Au mieux, dans les lignes que tu as mises en commentaires (et encore, tu les as mises au début, alors qu'il faut les mettre tout à la fin ... ), tu loggues des paquets ...
As tu rajouté, en début de script, des lignes du style ? :
iptables -P INPUT DROP |
Pour la politique par defaut en OUTPUT, c'est à adapter au mieux de tes règles/niveau de sécurité souhaité, soit ACCEPT (le + "laxiste" ), soit DROP (le + "dur" mais il faut écrire les règles OUTPUT qui vont bien, sinon bcp de services ne fonctionneront pas bien).
Message édité par Zzozo le 08-12-2007 à 13:45:33
---------------
« Ce qui ne vous tue pas vous rend plus fort » F. Nietzsche | « Vise_ la Lune. Si tu rates, au pire, t'es dans la merde » Un poète disparu dans le cercle
Marsh Posté le 08-12-2007 à 11:59:52
| Zzozo a écrit : ... soit DROP (le + "laxiste" ), soit ACCEPT (le + "dur" ... |
l'inverse non ?? DROP = le + dur, ACCEPT = le + laxiste 
Marsh Posté le 08-12-2007 à 13:45:05
"Ouais, le matin c'est le mal ©" 
---------------
« Ce qui ne vous tue pas vous rend plus fort » F. Nietzsche | « Vise_ la Lune. Si tu rates, au pire, t'es dans la merde » Un poète disparu dans le cercle
Marsh Posté le 08-12-2007 à 15:56:46
ca dépend tu si tu mets un ! très dur dans la règle, le DROP devient laxiste
| Spoiler : Tentative de rattrapage de coincoin |
---------------
Relax. Take a deep breath !
Marsh Posté le 10-12-2007 à 10:18:51
je remets mon fichier iptables corrigé
#!/bin/bash |
ça m'intrigue
Message édité par dreamkiller le 10-12-2007 à 10:22:48
Marsh Posté le 10-12-2007 à 13:34:16
osef de ton fichier, on veut ton iptables -L --line-numbers
Sinon ce genre de truc:
-m state --state NEW -j ACCEPT
c'est complètement inutile.
Gaffe avec tes règles DNS, le DNS c'est aussi TCP
tes logs te montrent des rejets sur ce fameux port ?
Marsh Posté le 10-12-2007 à 14:20:55
j'ai pas loggé les rejet sa produit une qunatité assez affreuse de log vais le faire sur une courte periode afin d'y retrouvé mes petits sinon pourquoi le -m state --state NEW -j ACCEPT est inutile?
|
bon J'ai reussi a trouver les logs des DROP
|
Message édité par dreamkiller le 10-12-2007 à 22:12:39
Sujets relatifs:
- ouvrir un port depuis l'interieur
- Ouverture d'un port sous RED HAT
- Détecter les scans de port
- Ankh 2 : Un port Linux si 250 pré-commandes
- Configuration dual port sur RHEL 4 update 4
- [RESOLU]SNORT: mise à jour des règles
- syslog sur port non-privilégié
- IPtables Redirection du port 80 d'un poste ver un site
- Alerte mail quand hdd > X % ?
- [macPro] reboot bloqué apres install de bootcamp
Marsh Posté le 07-12-2007 à 10:01:29
Bonjour,
j'ai un petit soucis (enfin plutôt un truc que je comprend mal).
Voila j'ai cette alerte récurrente dans snort/acidbase
#12-(1-236) [nessus] [cve] [icat] [bugtraq] [local] [snort] MS-SQL version overflow attempt 2007-12-07 01:24:37 218.6.128.186:1824 192.168.0.254:1434 UDP
#13-(1-237) [url] [nessus] [cve] [icat] [bugtraq] [bugtraq] [local] [snort] MS-SQL Worm propagation attempt 2007-12-07 01:31:54 218.64.237.219:1452 192.168.0.254:1434 UDP
#14-(1-238) [nessus] [cve] [icat] [bugtraq] [local] [snort] MS-SQL version overflow attempt 2007-12-07 01:31:54 218.64.237.219:1452 192.168.0.254:1434 UDP
Pourtant le port 1434 n'est pas ouvert dans mon iptables:
#vidage des tables de filtrage
iptables -F
iptables -X
#drop par defaut
#iptables -A INPUT -j LOG --log-prefix="[IN_PKTS_DROP]==> "
#iptables -A FORWARD -j LOG --log-prefix="[FO_PKTS_DROP]==> "
#iptables -A OUTPUT -j LOG --log-prefix="[OU_PKTS_DROP]==> "
#traffic local localhost authoris<C3><A9>
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
#Authoris<C3><A9> ping
iptables -A INPUT -p icmp -i eth0 --icmp-type echo-reply -j ACCEPT
iptables -A OUTPUT -p icmp -o eth0 --icmp-type echo-request -j ACCEPT
#Authorisation DNS
#iptables -A INPUT -p udp -i eth0 --sport 53 --dport 1024: -m state --state RELATED,ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -p udp -o eth0 --sport 1024: --dport 53 -m state --state ! INVALID -j ACCEPT
iptables -A OUTPUT -p udp -o eth0 --dport 53 -m state --state NEW -j ACCEPT
iptables -A INPUT -p udp -i eth0 --dport 53 -m state --state NEW -j ACCEPT
#Authorisation SSH
iptables -A INPUT -p tcp -i eth0 --dport ssh -m state --state NEW -j ACCEPT
#Authorisation Apache port 80
iptables -A INPUT -p tcp -i eth0 --dport 80 -m state --state NEW -j ACCEPT
#Authorisation Apache SSL port 443
iptables -A INPUT -p tcp -i eth0 --dport 443 -m state --state NEW -j ACCEPT
#Authorisation traffic web sortant pour mise a jour
iptables -A OUTPUT -p tcp -o eth0 --dport 80 -m state --state NEW -j ACCEPT
#FTP
modprobe ip_conntrack_ftp
iptables -A INPUT -i eth0 -p tcp --dport 21 -m state --state NEW -j ACCEPT
#Autorisation pour les connection deja etabli
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
J'avoue ne pas comprendre comment c'est possible (hormis une erreur dans mon iptables mais les scan en ligne que j'ai fait n'ont pas trouvé le port 1434 ouvert)
Quelqu'un peut il éclairer ma lanterne