Pages : 1
#1 Le 09/02/2008, à 09:42
- binrval
Peur avec les IPtables
Bonjour,
C'est la première fois que je pose une question sur ce forum, aussi je dis bonjour à tous. Je viens de m'équiper d'une Dedibox (usage serveur), que j'ai équipé avec Ubuntu sur les conseils d'un ami. Je travaille également, chez moi, avec une Mandriva sur un poste bureautique.
Je configure actuellement le poste serveur Ubuntu, et je m'attaque à la protection des entrées par les iptables. Je suis le tutoriel Netfilter & Iptables. Je travaille en ligne de commande par une connexion SSH.
Ce que j'ai peur, c'est, par cet exercice, de me couper... ma connexion SSH ! Auquel cas je risquerais d'être complètement coincé.
Dans le tutorial, il y a bien une étape Autoriser le trafic entrant d'une connexion déjà établie, mais je ne connais pas très bien le jargon, et je doute de ce qu'est ce connexion déjà établie. Est ce justement ça ?... Le texte de la ligne de commande me parait assez abscons, et j'ai quelque mal à être sûr, et comme je serai sacrément dans la m**** si jamais je me trompe, je pose la question :-)
Cordialement.
#2 Le 09/02/2008, à 10:07
- Michel38
Re : Peur avec les IPtables
Bonjour,
Pourquoi n'utilises-tu pas firestarter qui est un environnement graphique pour régler les iptables ?
LM18.3 - Kernel: 4.4.0-53-generic i686 (32 bit gcc: 5.4.0) - Cinnamon 3.4.6 (Gtk 3.18.9-1ubuntu3.3)
System: CLEVO (portable)
CPU : Dual core Intel Core i5-3230M
Card : Intel 3rd Gen Core processor Graphics Controller
Hors ligne
#3 Le 09/02/2008, à 10:11
- Thamior
Re : Peur avec les IPtables
Salut,
pas de panique ! Quelques précaution à prendre et il n' y aura pas de raison de s'inquiéter
Lorsque tu établies des règles iptables sur ta dedibox, tu travailles normalement avec un fichier texte dans lequelle tu ajoutes tes règles au fur et à mesure.
* Il est important, avant d'avoir validé l'intégralité de tes règles, de ne pas mettre ce fichier en démarrage auto au boot du serveur (rc-update). Car, justement en cas de pépin (erreur, blocage du ssh), il te restera l'option du reboot "hard" via la console de gestion dedibox.
* Pour les connexions déjà établies, c'est fait pour et çà doit ressembler à çà :
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
++
Hors ligne
#4 Le 09/02/2008, à 10:37
- binrval
Re : Peur avec les IPtables
Bonjour,
Pourquoi n'utilises-tu pas firestarter qui est un environnement graphique pour régler les iptables ?
Parce que je n'en ai pas, je travaille uniquement en ligne de commande par ssh.
Merci à Thamior, je vais essayer.
#5 Le 09/02/2008, à 16:05
- binrval
Re : Peur avec les IPtables
Rebonjour,
Cela a bien avancé, apparemment sans pépin.
J'en arrive à la section Appliquer les règles au démarrage dans le tutorial.
Il dit : Le reste du fichier doit contenir les commandes iptables que vous avez générées. et je ne comprends pas ça. Faut-il que je recopie dans ce fichier les commandes que je viens d'écrire dans le shell ?
De plus, d'après ce que me dit Tamior, il serait préférable que je ne fasse tout simplement pas cette opération ; est-ce que je comprends bien ?
Enfin, question subsidiaire : comment est-ce que je fais pour vérifier que tout cela a été efficace ??
Merci.
#6 Le 09/02/2008, à 16:28
- Thamior
Re : Peur avec les IPtables
De plus, d'après ce que me dit Tamior, il serait préférable que je ne fasse tout simplement pas cette opération ; est-ce que je comprends bien ?
je n'ai pas vraiment dis çà ...
j'ai juste précisé qu'il fallait être OK dans ses règles iptables avant de les faire appliquer au démarrage du serveur
Dans ton cas, les règles que tu souhaites mettre en place (celles que tu as maintenant testées) doivent être écrite dans un fichier (firewall par exemple) que tu copies sous /etc/init.d.
Ensuite, eh bien il faut le faire prendre en compte automatiquement au démarrage avec la commande update-rc.d
ex :
# update-rc.d firewall defaults
Evidemment, cette commande est personnalisable. RTFM
Je pose ici un extrait de mon fichier "firewall" pour te donner une idée :
#!/bin/sh
#
# Regles netfilter
#
## Variables
ipt="/sbin/iptables"
net="eth0"
## Arret de Fail2ban
/etc/init.d/fail2ban stop
sleep 3
echo "Arret du service Fail2ban : [OK]"
### Script
## Nettoyage des tables
$ipt -F
$ipt -X
# Loguer les INPUT
#$ipt -A INPUT -j LOG
## Interdire connexions entrantes
$ipt -P INPUT DROP
$ipt -P FORWARD DROP
## Interdire connexions sortantes
$ipt -P OUTPUT DROP
## Autoriser la boucle locale
$ipt -A INPUT -i lo -j ACCEPT
$ipt -A OUTPUT -o lo -j ACCEPT
etc....
++
Hors ligne
#7 Le 10/02/2008, à 17:42
- binrval
Re : Peur avec les IPtables
J'ai accompli grà¢ce à vous ce dimanche de véritables exploits : j'ai configuré mes iptables et j'ai rebooté ma dedibox !
Me reste plus qu'à savoir comment faire pour être sur que mon serveur est bien protégé et être sûr qu'il a bien rebooté... d'autres questions, d'autres aventures...
Merci !
#8 Le 24/04/2008, à 12:40
- Piwaï[INSA]
Re : Peur avec les IPtables
Tiens, je déterre ce post pour une petite question à Thamior :
Pourquoi est-ce que tu arrête fail2ban au démarrage de la machine ???
Je suis un peu novice la dedans, je viens de l'installer, et te voir le désactiver avant de mettre les règles iptables m'inquiète.. dois-je faire de même ?
http://www.piwai.info
Découvrez 2H4U (Too Hard For You) : http://www.sourceforge.net/projects/toohardforyou
et OpenGF : http://www.sourceforge.net/projects/opengf
Hors ligne
#9 Le 24/04/2008, à 19:09
- Thamior
Re : Peur avec les IPtables
Salut,
en fait, j'ai précisé que je postais un "extrait" de mon script, Fail2Ban est démarré à la fin de l'ensemble de mes règles iptables.
Pour éviter toute confusion, je le poste en entier :
#!/bin/sh
#
# Regles netfilter
#
## Variables
ipt="/sbin/iptables"
net="eth0"
## Arret de Fail2ban
/etc/init.d/fail2ban stop
sleep 3
echo "Arret du service Fail2ban : [OK]"
### Script
## Nettoyage des tables
$ipt -F
$ipt -X
# Loguer les INPUT
#$ipt -A INPUT -j LOG
## Interdire connexions entrantes
$ipt -P INPUT DROP
$ipt -P FORWARD DROP
## Interdire connexions sortantes
$ipt -P OUTPUT DROP
## Autoriser la boucle locale
$ipt -A INPUT -i lo -j ACCEPT
$ipt -A OUTPUT -o lo -j ACCEPT
## Autoriser tout traffic des connexions internet deja établiees
$ipt -A INPUT -i $net -m state --state ESTABLISHED,RELATED -j ACCEPT
$ipt -A OUTPUT -o $net -m state --state ESTABLISHED,RELATED -j ACCEPT
## Autoriser les requetes DNS, HTTP, NTP , ICMP en sortie (pour les mises a jour)
$ipt -A OUTPUT -o $net -p tcp --dport 80 -j ACCEPT
$ipt -A OUTPUT -o $net -p udp --dport 53 -j ACCEPT
$ipt -A OUTPUT -o $net -p udp --dport 123 -j ACCEPT
$ipt -A OUTPUT -o $net -p tcp --dport 21 -j ACCEPT
$ipt -A OUTPUT -o $net -p icmp --icmp-type echo-request -j ACCEPT
$ipt -A OUTPUT -o $net -p tcp --dport 25 -j ACCEPT
## Autoriser les réponses de ping
$ipt -A INPUT -i $net -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
## Autoriser les entrees DNS
$ipt -A INPUT -i $net -p udp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
$ipt -A INPUT -i $net -p tcp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
## Autoriser les requetes snmp pour monitoring
#$ipt -A INPUT -i $net -p tcp -s 88.191.254.0/24 --dport 161 -j ACCEPT
#$ipt -A INPUT -i $net -p udp -s 88.191.254.0/24 --dport 161 -j ACCEPT
## Autoriser les entrees SSH
$ipt -A INPUT -i $net -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
## Autoriser les entrees APACHE
$ipt -A INPUT -i $net -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
## Autoriser les entrees APACHE SSL
$ipt -A INPUT -i $net -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
## Autoriser les entrees et sorties FTP
modprobe ip_conntrack_ftp
$ipt -A INPUT -i $net -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
#ftp actif
$ipt -A OUTPUT -o $net -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
$ipt -A INPUT -i $net -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT
## Autoriser les entrees IMAP et SMTP
$ipt -A INPUT -i $net -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
$ipt -A INPUT -i $net -p tcp --dport 995 -m state --state NEW,ESTABLISHED -j ACCEPT
$ipt -A INPUT -i $net -p tcp --dport 993 -m state --state NEW,ESTABLISHED -j ACCEPT
## Fin du script et demarrage de Fail2ban
sleep 2
/etc/init.d/fail2ban start
echo "Demarrage su service Fail2ban : [OK]"
Un script iptables est en quelque sorte personnel et personnalisable. Chacun a sa manière de faire...
Sur d'autres systèmes, j'utilise plutôt ce genre de script (meilleur à mon gout) :
#!/bin/sh
ruleset_dir=/etc/iptables
case "$1" in
start)
/sbin/iptables-restore < $ruleset_dir/active
echo "Démarrage du service NetFilter: [OK]"
;;
stop)
/sbin/iptables-restore < $ruleset_dir/inactive
echo "Arrêt du service NetFilter: [OK]"
;;
force-reload|restart)
$0 stop
sleep 1
$0 start
;;
save)
cp $ruleset_dir/active $ruleset_dir/active-$(date +%Y%m%d_%H%M)
echo "Copie de sauvegarde des anciennes règles: [OK]"
/sbin/iptables-save > $ruleset_dir/active
echo "Sauvegarde des modifications des règles: [OK]"
;;
*)
echo "Usage: /etc/init.d/iptables {start|stop|restart|force-reload}"
exit 1
esac
exit 0
Cette fois-ci, mes règles sont à l'intérieur de 2 fichiers (active & inactive), l'un laissant tout passer et l'autre filtrant ce que je souhaite filtrer.
Par contre, la syntaxe est différente et moins évidente..
Exemple du fichier "active"
# Generated by iptables-save v1.3.6 on Fri Mar 7 14:37:03 2008
*nat
:PREROUTING ACCEPT [2514:237945]
:POSTROUTING ACCEPT [2:1448]
:OUTPUT ACCEPT [5:380]
-A PREROUTING -s 212.27.38.253 -i eth0 -p udp -m udp --dport 1024:65535 -j DNAT --to-destination 192.168.20.200
-A PREROUTING -i eth0 -p tcp -m tcp --dport 17478 -j DNAT --to-destination 192.168.20.200
-A PREROUTING -i eth0 -p tcp -m tcp --dport 17479 -j DNAT --to-destination 192.168.20.200
-A PREROUTING -i eth0 -p udp -m udp --dport 19581 -j DNAT --to-destination 192.168.20.200
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri Mar 7 14:37:03 2008
# Generated by iptables-save v1.3.6 on Fri Mar 7 14:37:03 2008
*filter
:INPUT DROP [636:117431]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i vmnet1 -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -j ACCEPT
-A FORWARD -i vmnet1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o vmnet1 -j ACCEPT
-A FORWARD -i vmnet1 -o eth1 -j ACCEPT
-A FORWARD -i eth1 -o vmnet1 -j ACCEPT
-A FORWARD -s 212.27.38.253 -d 192.168.20.200 -i eth0 -p udp -m udp --dport 1024:65535 -j ACCEPT
-A FORWARD -d 192.168.20.200 -i eth0 -p tcp -m tcp --dport 17478 -j ACCEPT
-A FORWARD -d 192.168.20.200 -i eth0 -p tcp -m tcp --dport 17479 -j ACCEPT
-A FORWARD -d 192.168.20.200 -i eth0 -p udp -m udp --dport 19581 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth0 -m state --state ! INVALID -j ACCEPT
-A OUTPUT -o eth1 -j ACCEPT
-A OUTPUT -o vmnet1 -j ACCEPT
COMMIT
# Completed on Fri Mar 7 14:37:03 2008
Voilà, si questions, n'hésitez pas.
J'ai fait un petit topo sur netfilter ici
Hors ligne
#10 Le 24/04/2008, à 19:31
- Piwaï[INSA]
Re : Peur avec les IPtables
Merci ! Ces différents exemples de règles vont m'être bien pratiques pour penser à tout .
Le script avec start, stop et restart, c'est cool ça permet d'avoir un fonctionnement identique aux autres scripts de init.d.
En fait, j'ai bien compris ce que tu as fait, mais je ne comprend pas pourquoi. Pourquoi est-ce que tu arrêtes fail2ban, pour le redémarrer à la fin du script ? Alors qu'il s'agit d'un script de démarrage, donc fail2ban vient juste d'être lancé. Idem avec les règles iptables, qui normalement sont vierges au démarrage. Est-ce pour pouvoir lancer ton script à n'importe quel moment ?
Dernière modification par Piwaï[INSA] (Le 24/04/2008, à 19:32)
http://www.piwai.info
Découvrez 2H4U (Too Hard For You) : http://www.sourceforge.net/projects/toohardforyou
et OpenGF : http://www.sourceforge.net/projects/opengf
Hors ligne
#11 Le 25/04/2008, à 07:38
- Thamior
Re : Peur avec les IPtables
Est-ce pour pouvoir lancer ton script à n'importe quel moment ?
Tout à fait
Mes serveurs ne redémarrent jamais, ou alors indépendamment de ma volonté ^^.
Le vidage des règles iptables et fail2ban peut mettre utile lorsque je modifie mes règles et que je relance mon script (suite à nouvelle application ou nouveau service).
Hors ligne
Pages : 1