Bonjour,
Je viens d'écrire un script 'iptables' que j'ai placé dans
/etc/rc.d/init.d/.
Ce script est le suivant:
. /etc/rc.d/init.d/functions
# Suppression de toutes les chaines pre-definies de la table FILTER
iptables -t filter -F
# Suppression de toutes les chaines utilisateur de la table FILTER
iptables -t filter -X
# Par defaut, toute les paquets sont detruits
iptables -t filter -P INPUT DROP
iptables -t filter -P OUTPUT DROP
iptables -t filter -P FORWARD DROP
# Autorise l'interface loopback a dialoguer avec elle-meme
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
#Connexion a internet (dns, http, ...). Les reponses ne sont envoyees
#seulement lorsque je les demande
iptables -t filter -A OUTPUT -o ppp0 -p all -m state --state ! INVALID
-j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p all -m state --state
RELATED,ESTABLISHED -j ACCEPT
Que pensez-vous de ce script ? Permet-il de bien sécurisé l'ordinateur ?
Que dois-je rajouter pour loguer tout ce qui est refusé ?
Comment appliquer ce script après une modification sans avoir à
redémarrer l'ordinateur ?
Merci à tous de vos réponses !
Cordialement.
Guilhem.
[edit] Je ne vois pas très bien la différence entre
/etc/init.d/rc.d/iptables et /etc/sysconfig/iptables...
Je viens d'écrire un script 'iptables' que j'ai placé dans /etc/rc.d/init.d/. Ce script est le suivant:
. /etc/rc.d/init.d/functions
# Suppression de toutes les chaines pre-definies de la table FILTER iptables -t filter -F
C'est plutôt "suppression de toutes les règles de la table filter".
[...]
#Connexion a internet (dns, http, ...). Les reponses ne sont envoyees #seulement lorsque je les demande iptables -t filter -A OUTPUT -o ppp0 -p all -m state --state ! INVALID -j ACCEPT iptables -t filter -A INPUT -i ppp0 -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
Que pensez-vous de ce script ? Permet-il de bien sécurisé l'ordinateur ?
Le "! INVALID" dans OUTPUT est risqué avec les noyaux 2.4 un peu vieux (risque de bloquer des ICMP sortants liés aux connexions existantes et improprement vus comme INVALID au lieu de RELATED avec les noyaux antérieurs à 2.4.29).
Le fait de DROPper silencieusement les paquets NEW entrants n'est pas une bonne idée du point de vue du respect du protocole. Un REJECT (blocage avec émission d'un message d'erreur à la source du paquet) serait préférable :
iptables -A INPUT -m state --state NEW -j REJECT
Que dois-je rajouter pour loguer tout ce qui est refusé ?
iptables -A INPUT -j LOG iptables -A OUTPUT -j LOG
après les règles ACCEPT. Mais ne viens pas te plaindre si ça finit par provoquer un déni de service de ta machine par remplissage de /var ;-)
Comment appliquer ce script après une modification sans avoir à redémarrer l'ordinateur ?
Il suffit de l'exécuter à partir du shell, tout simplement :
$ /etc/rc.d/init.d/<nom du script>
Salut,
Je viens d'écrire un script 'iptables' que j'ai placé dans
/etc/rc.d/init.d/.
Ce script est le suivant:
. /etc/rc.d/init.d/functions
# Suppression de toutes les chaines pre-definies de la table FILTER
iptables -t filter -F
C'est plutôt "suppression de toutes les règles de la table filter".
[...]
#Connexion a internet (dns, http, ...). Les reponses ne sont envoyees
#seulement lorsque je les demande
iptables -t filter -A OUTPUT -o ppp0 -p all -m state --state ! INVALID
-j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p all -m state --state
RELATED,ESTABLISHED -j ACCEPT
Que pensez-vous de ce script ? Permet-il de bien sécurisé l'ordinateur ?
Le "! INVALID" dans OUTPUT est risqué avec les noyaux 2.4 un peu vieux
(risque de bloquer des ICMP sortants liés aux connexions existantes et
improprement vus comme INVALID au lieu de RELATED avec les noyaux
antérieurs à 2.4.29).
Le fait de DROPper silencieusement les paquets NEW entrants n'est pas
une bonne idée du point de vue du respect du protocole. Un REJECT
(blocage avec émission d'un message d'erreur à la source du paquet)
serait préférable :
iptables -A INPUT -m state --state NEW -j REJECT
Que dois-je rajouter pour loguer tout ce qui est refusé ?
iptables -A INPUT -j LOG
iptables -A OUTPUT -j LOG
après les règles ACCEPT. Mais ne viens pas te plaindre si ça finit par
provoquer un déni de service de ta machine par remplissage de /var ;-)
Comment appliquer ce script après une modification sans avoir à
redémarrer l'ordinateur ?
Il suffit de l'exécuter à partir du shell, tout simplement :
Je viens d'écrire un script 'iptables' que j'ai placé dans /etc/rc.d/init.d/. Ce script est le suivant:
. /etc/rc.d/init.d/functions
# Suppression de toutes les chaines pre-definies de la table FILTER iptables -t filter -F
C'est plutôt "suppression de toutes les règles de la table filter".
[...]
#Connexion a internet (dns, http, ...). Les reponses ne sont envoyees #seulement lorsque je les demande iptables -t filter -A OUTPUT -o ppp0 -p all -m state --state ! INVALID -j ACCEPT iptables -t filter -A INPUT -i ppp0 -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
Que pensez-vous de ce script ? Permet-il de bien sécurisé l'ordinateur ?
Le "! INVALID" dans OUTPUT est risqué avec les noyaux 2.4 un peu vieux (risque de bloquer des ICMP sortants liés aux connexions existantes et improprement vus comme INVALID au lieu de RELATED avec les noyaux antérieurs à 2.4.29).
Le fait de DROPper silencieusement les paquets NEW entrants n'est pas une bonne idée du point de vue du respect du protocole. Un REJECT (blocage avec émission d'un message d'erreur à la source du paquet) serait préférable :
iptables -A INPUT -m state --state NEW -j REJECT
Que dois-je rajouter pour loguer tout ce qui est refusé ?
iptables -A INPUT -j LOG iptables -A OUTPUT -j LOG
après les règles ACCEPT. Mais ne viens pas te plaindre si ça finit par provoquer un déni de service de ta machine par remplissage de /var ;-)
Comment appliquer ce script après une modification sans avoir à redémarrer l'ordinateur ?
Il suffit de l'exécuter à partir du shell, tout simplement :
$ /etc/rc.d/init.d/<nom du script>
Guilhem
Que dois-je rajouter pour loguer tout ce qui est refusé ? iptables -A INPUT -j LOG
iptables -A OUTPUT -j LOG après les règles ACCEPT. Mais ne viens pas te plaindre si ça finit par provoquer un déni de service de ta machine par remplissage de /var ;-) iptables -A INPUT -m limit --limit 3/second --limit-burst 5 -i ! lo -j LOG
iptables -A INPUT -i ! lo -j DROP ????
Que dois-je rajouter pour loguer tout ce qui est refusé ?
iptables -A INPUT -j LOG
iptables -A OUTPUT -j LOG
après les règles ACCEPT. Mais ne viens pas te plaindre si ça finit par
provoquer un déni de service de ta machine par remplissage de /var ;-)
iptables -A INPUT -m limit --limit 3/second --limit-burst 5 -i ! lo -j LOG
Que dois-je rajouter pour loguer tout ce qui est refusé ? iptables -A INPUT -j LOG
iptables -A OUTPUT -j LOG après les règles ACCEPT. Mais ne viens pas te plaindre si ça finit par provoquer un déni de service de ta machine par remplissage de /var ;-) iptables -A INPUT -m limit --limit 3/second --limit-burst 5 -i ! lo -j LOG
iptables -A INPUT -i ! lo -j DROP ????
R12y
après les règles ACCEPT. Mais ne viens pas te plaindre si ça finit par provoquer un déni de service de ta machine par remplissage de /var ;-)
iptables -A INPUT -m limit --limit 3/second --limit-burst 5 -i ! lo -j LOG iptables -A INPUT -i ! lo -j DROP
Oui ça peut se voir comme ça. Mais c'est encore incomplet:
- il faut aussi préciser le loglevel (si tu mets debug, alors les logs iront dans /var/log/debug)
- tu peux aussi ne pas seulement logger tout, mais il me semble qu'un port scan est detectable, tout comme un ping flood, et d'autres types d'attaques... (tu peux utiliser log-prefix pour dissocier les types d'attaques)
après les règles ACCEPT. Mais ne viens pas te plaindre si ça finit par
provoquer un déni de service de ta machine par remplissage de /var ;-)
iptables -A INPUT -m limit --limit 3/second --limit-burst 5 -i ! lo -j
LOG iptables -A INPUT -i ! lo -j DROP
Oui ça peut se voir comme ça.
Mais c'est encore incomplet:
- il faut aussi préciser le loglevel (si tu
mets debug, alors les logs iront dans /var/log/debug)
- tu peux aussi ne pas seulement logger tout, mais il me semble qu'un port
scan est detectable, tout comme un ping flood, et d'autres types
d'attaques... (tu peux utiliser log-prefix pour dissocier les types
d'attaques)
après les règles ACCEPT. Mais ne viens pas te plaindre si ça finit par provoquer un déni de service de ta machine par remplissage de /var ;-)
iptables -A INPUT -m limit --limit 3/second --limit-burst 5 -i ! lo -j LOG iptables -A INPUT -i ! lo -j DROP
Oui ça peut se voir comme ça. Mais c'est encore incomplet:
- il faut aussi préciser le loglevel (si tu mets debug, alors les logs iront dans /var/log/debug)
- tu peux aussi ne pas seulement logger tout, mais il me semble qu'un port scan est detectable, tout comme un ping flood, et d'autres types d'attaques... (tu peux utiliser log-prefix pour dissocier les types d'attaques)
