Y veut pas me la tuer cette ligne
debian-sarge:/home/ricardo1# iptables -D INPUT -j ACCEPT
iptables: Bad rule (does a matching rule exist in that chain?)
debian-sarge:/home/ricardo1#
Y veut pas me la tuer cette ligne
debian-sarge:/home/ricardo1# iptables -D INPUT -j ACCEPT
iptables: Bad rule (does a matching rule exist in that chain?)
debian-sarge:/home/ricardo1#
essayes en rajoutant ‘-p all’
essayé à ts les endroits mais rien.
Je cherche ds help mais je n’ai pas encore trouvé.
ce qui me semblerait le plus plosible, serait d’ajouter un N° de ligne mais lequel, de quelle façon et où ?
Bon,
iptables -L --line-numbers
pour lister et normalement, ca doit être la regle 1 que tu enlèves alors avec:
iptables -L 1
essayé encore à ttes les sauces mais rien.
-D et -L sont incompatibles mais m^ en enlevant le -D, pas mieux ?
c’était si simple, pourtant.
Encore deux ou trois questions demain et je pense que je vais ouvrir un fil ds “trucs …” où j’expliquerai tt de A à Z pour les ‘nuls’ genre de titre : installer IPTABLES quand on est “nul” avec un sous-titre : interdit aux geeks mais je ne sais pas comment s’écrit ce mot et ce qu’il veut dire exactement
Je te ferai d’abord corriger avant de poster.
J’ai réussi a virer une regles avec cette commandes
iptables -D INPUT 3
3 correspond au drop de l’icmp (chez moi)
essaye
oui, c’est ce que j’ai écrit plus haut. moi j’ai viré la ‘1’ car c’est elle qui ne me plaisait pas mais j’ai un doute sur son utilité.
Je n’avais pas vu j’etais en train de poster
Pour la une c’est surement la regles sur le loopback celle ci autorise un trafic libre sur 127.0.0.1 normalement elle est correcte enfin je pense
exact et ça m’a d’ailleurs foutu la m…
Je suis sur une autre distrib maintenant pour pouvoir réparer car impossible de charger complètement sans cette ligne.
Je vais la rechercher ds le fil et l’a replacer.
Ricardo, je suis désolé de t’avoir enduit d’erreur avec ce -L au lieu du -D
Te absolvo !
Pour ta peine, mon fils, tu me réciteras la signification de
’tcp’ et 'udp’
avantages / inconvénients
Je suppose que ‘all’ veut dire les deux ?
bon:
TCP=Transmission Control Protocol, est une partie du protocole IP qui fonctionne en mode connecté, c’est à dire que tous les echanges sont confirmés par le recepteur à l’emetteur, qui sait ainsi s’il doit renvoyer un paquet ou pas, par exemple.
fr.wikipedia.org/wiki/Transmissi … l_Protocol
applications bien connues qui fonctionnent en tant que serveur et sont en attente de connexions utilisent généralement ces types de ports. Exemples: FTP (21), Telnet (23), SMTP (25) et HTTP (80).
UDP=User Datagram Protocol, et une autre partie qui fonctionne en mode “sans verification”, c’est à dire que l’emetteur se moque de savoir si le recepteur à bien recu les paquets, il diffuse tout ce qu’il a a diffuser, c’est tout.
fr.wikipedia.org/wiki/User_Datagram_Protocol
Exemples d’utilisation : le programme traceroute, le DNS, TFTP, les jeux en réseau (exemple : jeux de tir subjectifs) et le streaming.
Pour résumer, quand tu veux ouvrir un port, tu essayes d’abord en TCP, sinon en UDP, sinon avec all…
Ok, enregistré.
Je l’indiquerai ds mon “tuto pour les nuls”
A part ça, j’ai réparé ma bourde d’hier soir où j’avais éjecté loopback et bien sûr, je ne pouvais plus charger ma distrib.
Je suis passé par l’autre distrib, j’ai monté la première et j’ai “mouvé” les scripts ds /home/ricardo/attente/.
J’ai pu ainsi recharger la distrib qui se révoltait, j’ai “remouvé” ds l’autre sens et j’ai rajouté le loopback.
Je pense qu’il devait y avoir une méthode plus simple mais je n’ai pas trouvé.
Est-il possible de passer une commande par la console sur une distrib montée sur une autre ? ‘chroot’ ?, autre façon ?
chroot
te permet d’executer ton shell en considerant comme la racine de ton disque (ce qu’il y a au dessus n’existe plus).
Bon, il y a d’autres subtilités si tu as à travailler sur les devices, et je suis un peu à la bourre, mais l’essentiel, c’est ca.
Ce pauvre Ricardo, et en plus il se fait “enduire” …
Bonsoir,
Désolé si je relance un sujet peut etre terminé, mais je dois dire que moi aussi j’ai un peu de mal avec iptables.
Je vous propose mon petit script (largement copier d’un ti livre o’reilly), si vous pouviez me dire si de telles regles sont intelligement pensée ou si je me suis lamentablement trompé
#!/bin/sh
# Start/stop/restart/status firewall:
rouge="\033[01;31m"
blanc="\033[0m"
vert="\033[1;01;32m"
jaune="\E[1;01;33m"
WHITELIST=/usr/local/etc/liste_blanche.txt
BLACKLIST=/usr/local/etc/liste_noire.txt
ALLOWED="80"
WHITE_ALLOWED="22"
firewall_start() {
log_begin_msg "${vert}Démarrage du firewall${blanc}" 0
iptables -t filter -F
iptables -t nat -F
iptables -t mangle -F
iptables -t raw -F
log_end_msg 0
#Regle de base
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
# Pas de filtrage sur l'interface de "loopback"
iptables -t filter -A INPUT -i lo -j ACCEPT
# J'accepte les packets entrants relatifs à des connexions déjà établies
iptables -t filter -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#
# Commencer par parcourir $WHITELIST, en acceptant le traficvers les ports
# $WHITE_ALLOWED qu'elle contient.
#
log_begin_msg "${jaune}Lecture de la Whitelist${blanc}" 1
for x in `grep -v ^# $WHITELIST | awk '{print $1}'`; do
log_begin_msg "Autorisation accordée à $x..." 2
for wport in $WHITE_ALLOWED; do
log_begin_msg "Pour le port $wport" 3
iptables -A INPUT -t filter -s $x -p tcp --dport $wport -j ACCEPT
log_end_msg 0
done
done
#
# Ensuite parcourir $BLACKLIST, en écartant tout le trafic provenant
# des hôtes et des réseaux qu'elle contient
#
log_begin_msg "${jaune}Lecture de la BlackList${blanc}" 1
for x in `grep -v ^# $BLACKLIST | awk '{print $1}'`; do
log_begin_msg "Blocage de $x..." 2
iptables -A INPUT -t filter -s $x -j DROP
log_end_msg 0
done
#
# A présent, les ports autorisés : qu'accepterons-nous des hôtes
# n'apparaissant pas sur la liste noire ?
#
log_begin_msg "${jaune}Liste des ports autorisés${blanc}" 1
for port in $ALLOWED; do
log_begin_msg "Acceptation du port $port..." 2
iptables -A INPUT -t filter -p tcp --dport $port -j ACCEPT
log_end_msg 0
done
#
# Regle contre les attaque par Déni de service
#
#
log_begin_msg "${jaune}Regle de detection des attaques par déni de service${blanc}" 1
iptables -t nat -N syn-flood
log_end_msg 0
log_begin_msg "${jaune}Regle de limite de 12 connexions par seconde (rafale à 24)${blanc}" 1
iptables -t nat -A syn-flood -m limit --limit 12/s --limit-burst 24 -j RETURN
log_end_msg 0
log_begin_msg "${jaune}Regle de contrôle d'attaque par déni de service(DoS)${blanc}" 1
iptables -t nat -A PREROUTING -i $EXT_IFACE -d $DEST_IP -p tcp --syn -j syn-flood
log_end_msg 0
#
# Pour finir, à moins d'un contre ordre ci-dessus, rejeter les connexions
# entrantes à l'initiative de l'exterieur
#
log_begin_msg "${jaune}Rejet des autres connexions entrantes${blanc}" 1
iptables -A INPUT -t filter -p tcp --syn -j DROP
log_end_msg 0
iptables -t filter -A INPUT -p all -j ULOG --ulog-prefix=DefaultDrop
}
firewall_stop() {
log_begin_msg "${rouge}Firewall désactivé.${blanc}"
iptables -F
iptables -X
#iptables -P INPUT ACCEPT
#iptables -P FORWARD ACCEPT
#iptables -P OUTPUT ACCEPT
iptables -t nat -F
iptables -t nat -X
#iptables -t nat -P PREROUTING ACCEPT
#iptables -t nat -P POSTROUTING ACCEPT
#iptables -t nat -P OUTPUT ACCEPT
iptables -t mangle -F
iptables -t mangle -X
#iptables -t mangle -P PREROUTING ACCEPT
#iptables -t mangle -P OUTPUT ACCEPT
log_end_msg 0
}
firewall_restart() {
log_begin_msg "${jaune}Redémarrage du Firewall${blanc}"
sleep 1
firewall_stop
sleep 2
firewall_start
}
case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac
J’avoue qu’il n’est pas encore top au point, mais pour le moment les r-gles qui y sont je les comprend
Juste pour info mon serveur n’a qu’une interface réseau donc je veux juste faire un bon firewall, il n’y aura pas de port forwarding ou de chose de ce genre.
J’ai lu quelques petite chose sur ce post que je vais rajouter.
Bonne fin de soirée à vous
Edit du 24 janvier 2006 :
Voila j’ai ajouté quelques reglès trouvées dans ce post, j’espère que ca va un peu renforcé la securité de mon serveur, car j’avoue quand même que j’ai beaucoup de mal avec iptable et les regles, pour le moment c’est plus j’apprend moins je conprend, mais bon faut que j’en apprenne plus sur le reseau lol.
Edit du 28 janvier 2006 :
J’ai rajouter au script un table WHITE_ALLOWED qui me permet d’autoriser une liste de port pour les ip de la white_list, comme cela dans le tableau ALLOWED je n’utilise que les port qui permette à tous le monde de venir sur le serveur (ici le port 80). N’esitez pas a faire vos commentaire
Bonjour à tous,
Je remonte ce fil car il est rempli de choses fort intéressantes pour ceux qui, comme moi, essayent de comprendre le fonctionnement d’ iptables.
Deux petites remarques
[ul]
[li]Au sujet du post précédent de tarlak deux règles DROP me semblent redondantes:
[code]# BLACKLIST
iptables -A INPUT -t filter -s $x -j DROP
iptables -A INPUT -t filter -p tcp --syn -j DROP [/code]
Puisque la POLICY par défaut DROPe tous les INPUT sur la table filter (ah, qu’elle est donc belle la langue française sur les forums informatiques!) il est donc inutile de les DROPer une nouvelle fois. Sauf si on veut interrompre là l’analyse d’un paquet IP pour gagner du temps d’exécution. Sur ce dernier point j’ai des doutes, ne sachant pas comment fonctionne netfilter.
Me trompe-je?
[/li]
[li]Dans la politique de prudence, préconisée plus haut, qui consiste à tout fermer pour n’ouvrir que ce qui est strictement nécessaire, je me suis longtemps interrogé sur la manière de logger tout ce qui est DROPé dans les POLICY par défaut. Ceci pour faire la chasse aux faux positifs dans une phase de débogage.
Les règles comme:
# Règles par défault
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
…n’acceptent pas le target LOG. Il fallait donc trouver une autre solution. En fait, ce qui m’a bloqué, c’est une simple erreur de perception. On met toujours la règle de POLICY par défaut avant toutes les autres mais, en fait, elle ne s’exécute qu’à la toute fin d’une chaîne. Si un paquet IP passe toutes les règles ACCEPT d’une chaîne sans être accepté (aucune concordance), il tombera sur la POLICY par défaut qui le DROPera.
Pour journaliser tous les paquets IP rejetés, il suffit de rajouter, après la dernière règle d’une chaîne, une règle comme:
Comme seuls les paquets non-autorisés arrivent jusque là, il sont automatiquement journalisés.
C’est sans doute trivial pour la plupart d’entre-vous mais j’ai dû chercher un moment pour y arriver.[/li][/ul]