Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 26/08/2012, à 01:09

AlbertLacourt

[RESOLU] Le cauchemar iptables

Bonjour à tous,

Orgueilleux que j'étais, j'ai cru pouvoir me lancer dans le paramétrage d'iptable sans trop de difficultés, avec l'aide du tutoriel du site. Grosse erreur, et la dure réalité se rappelle à moi depuis déjà deux jours : pas moyen d'accéder au moindre site web du moment que j'active iptable.
Internet marche très bien quand je désactive complètement iptable.

Je suis sous Precise, et je précise que que j'utilise le wifi (interface wlan0 et non pas eth0), je ne sais pas si ça peut jouer un rôle.
Et donc j'ai écrit un script de configuration :

#!/bin/bash
#

# On vide les chaines 
iptables -F
iptables -X 

# On ferme les chaines

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Autorise les reponses
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Sortie web
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT

J'ai réduit au minimum pour que ça soit clair.
Ma question est donc : pourquoi cela ne suffit-il pas pour accéder à internet, pour des sites http classiques ? Il me semblait que la requête pouvait sortir en 80, et revenir puisque on autorise les réponses... Ou est l'échelon d'autorisation que j'ai raté ?
Un grand merci d'avance ! smile

Dernière modification par AlbertLacourt (Le 27/08/2012, à 01:13)

Hors ligne

#2 Le 26/08/2012, à 01:32

Pacifick_FR42

Re : [RESOLU] Le cauchemar iptables

Activer le firewall, c'est pas super utile (ta box fait office de firewall)
Il y a gufw qui permet "d’alléger" la manipulation de iptable wink

Dernière modification par Pacifick_FR42 (Le 26/08/2012, à 01:32)

Hors ligne

#3 Le 26/08/2012, à 01:43

mydjey

Re : [RESOLU] Le cauchemar iptables

Il me semblait que la requête pouvait sortir en 80, et revenir puisque on autorise les réponses...

La requête ne sort pas par le port 80, elle sort du navigateur par un port aléatoire (pas tout à fait sûr de cette dernière affirmation si un spécialiste passe par là...).
Le port 80 c'est le port du serveur sur lequel va se connecter le navigateur.
En général on laisse tout les ports en sortie ouvert.

Hors ligne

#4 Le 26/08/2012, à 03:26

Yann

Re : [RESOLU] Le cauchemar iptables

Je tente un coup dans le vide smile
Ta configuration me semble correcte - mais sans t'autoriser à faire des requêtes DNS, tu penses que ca va marcher? wink

Dernière modification par Yann (Le 26/08/2012, à 03:27)


Et pourtant moi, jsuis pas du genre délicat,
Dans un coin de la musse, j'ai posé mon matelas
- Paulo Anarkao

Hors ligne

#5 Le 26/08/2012, à 05:22

xavier4811

Re : [RESOLU] Le cauchemar iptables

Bonsoir,

AlbertLacourt a écrit :

#!/bin/bash
#

# On vide les chaines
iptables -F
iptables -X

# On ferme les chaines

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP


## autoriser la boucle locale
iptables -t filter -A OUTPUT -o lo -p all -j ACCEPT
iptables -t filter -A INPUT -i lo -p all -j ACCEPT

# Autorise les reponses
iptables -A OUTPUT -p all -m state ! --state INVALID -j ACCEPT
iptables -A INPUT -p all -m state --state RELATED,ESTABLISHED,UNTRACKED -j ACCEPT

# Sortie web ## inutile
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT

EDIT ---------------
Pour te simplifier la vie et le débogage des règles iptables, utilise les logs, voir mieux ulog.
Ouvrir le 80 en sortie ne sert a rien, c'est le port de destination du serveur, pas celui de sortie du client.
Exemple de paquets droppé a destination d'un serveur web a partir d'un client non autorisé :

Aug 26 05:37:39 zeus DROP_IN :  IN=br1 OUT= MAC=54:04:a6:82:20:f0:c4:17:fe:20:ea:b0:08:00  SRC=192.168.1.208 DST=192.168.1.250 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=18701 DF PROTO=TCP SPT=37669 DPT=80 SEQ=4002070922 ACK=0 WINDOW=14600 SYN URGP=0 
Aug 26 05:37:42 zeus DROP_IN :  IN=br1 OUT= MAC=54:04:a6:82:20:f0:c4:17:fe:20:ea:b0:08:00  SRC=192.168.1.208 DST=192.168.1.250 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=18703 DF PROTO=TCP SPT=37669 DPT=80 SEQ=4002070922 ACK=0 WINDOW=14600 SYN URGP=0 

Dernière modification par xavier4811 (Le 26/08/2012, à 05:42)

Hors ligne

#6 Le 26/08/2012, à 12:45

AlbertLacourt

Re : [RESOLU] Le cauchemar iptables

Ça marche !!! Vous êtes trop forts, et linux est beau !!! big_smile Mille merci !

Je n'y toucherai pas de sitôt pour ne pas perdre cela, mais juste pour comprendre, quand tu écris :

 -m state ! --state INVALID 

C'est pour dire que tu acceptes tous les paquets non invalides ? C'est le rôle du point d'exclamation de faire la négation ?

Et à quoi sert le

 -t filter 

? C'est une précision par rapport aux tables nat et autres que l'on pourrait vouloir gérer ?

En  fait, je n'ai pas besoin de me préoccuper des différents ports et tout parce que je suis un simple client, mais si j'étais un serveur, il faudrait que j'autorise spécifiquement des ports, c'est cela ?

Hors ligne

#7 Le 26/08/2012, à 13:00

pires57

Re : [RESOLU] Le cauchemar iptables

-t filter

c'est la page par défaut si l'option

-t 

n'es pas spécifié.
Tu pourras en savoir plus sur Iptable avec un simple

man iptable

Pour le point d'exclamation, il sert a faire la négation en programmation.


Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

Hors ligne

#8 Le 26/08/2012, à 13:03

mydjey

Re : [RESOLU] Le cauchemar iptables

En  fait, je n'ai pas besoin de me préoccuper des différents ports et tout parce que je suis un simple client, mais si j'étais un serveur, il faudrait que j'autorise spécifiquement des ports, c'est cela ?

C'est à peu prêt ça. Quand tu es client c'est toi qui initie la connexion (connexion sortantes de ton pc) donc pas de risque de sécurité. Par contre dans le cas d'un serveur, il attend que quelqu'un se connecte à lui, il est donc obligé d'avoir des ports ouverts (80 pour le http) sinon personne ne pourrait le joindre.
Vu que tu n'es pas serveur tu n'as pas à t'inquiéter des ports ouverts en entrée, il suffit de tous les fermer.

/me étale ses maigres compétences en réseau. cool

Hors ligne

#9 Le 26/08/2012, à 13:06

Yann

Re : [RESOLU] Le cauchemar iptables

Halte là, je suis pas d'accord smile
Effectivement Xavier, il lui manquait l'autorisation de la boucle locale. Cependant tu ouvres avec ta commande tous les ports en sortie - et apparement ce n'est pas ce qu'il voulait.  Cette commande:

iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT

Me parait tout a fait correcte. Avec une policy OUTPUT a DROP, cela voudrait dire qu'il refuse tout en sortie, à part les paquets qui vont vers le port 80 - c'est à dire les requêtes HTTP.
Je vote donc pour:

    #!/bin/bash

    # On vide les chaines
    iptables -F
    iptables -X

    # On définit la policy par défaut a DROP
    iptables -P INPUT DROP
    iptables -P OUTPUT DROP
    iptables -P FORWARD DROP

    ## On autorise la boucle locale
    iptables -t filter -A OUTPUT -o lo -p all -j ACCEPT
    iptables -t filter -A INPUT -i lo -p all -j ACCEPT

    # On droppe tout ce qui est invalide
    IPTABLES -A INPUT -m state --state INVALID -j DROP
    IPTABLES -A OUTPUT -m state --state INVALID -j DROP

    # Autorise les reponses de connexions déjà initiées
    iptables -A OUTPUT -p all --m state --state RELATED,ESTABLISHED,UNTRACKED  -j ACCEPT
    iptables -A INPUT -p all -m state --state RELATED,ESTABLISHED,UNTRACKED -j ACCEPT

    # On autorise les requetes HTTP & DNS uniquement - Je rajoute le - state NEW, il est pourtant facultatif ici vu qu'on autorise déjà les ESTABLISHED auparavant, mais pour que tu comprennes bien ce qu'on fait.
    iptables -A OUTPUT -m state --state NEW  -p tcp --dports 53,80 -j ACCEPT

Et pourtant moi, jsuis pas du genre délicat,
Dans un coin de la musse, j'ai posé mon matelas
- Paulo Anarkao

Hors ligne

#10 Le 26/08/2012, à 13:18

Yann

Re : [RESOLU] Le cauchemar iptables

Comme dit mydjey: techniquement il a raison, mon script fait uniquement ce qu'il me semblait que tu voulais faire - mais il est vrai qu'il est assez rare de bloquer les ports en sortie. En général, on autorise tous les ports en sortie. Dans ce cas, xavier4811 aurait raison.
Il peut être intéressant dans de rares cas (par exemple pour un firewall d'entreprise) de filtrer également les ports en sortie. Cela risque de te poser plus problèmes qu'autre chose sinon - la configuration que je t'ai envoyée va t'empêcher de faire du FTP, du SSH, du torrents, du skype, du msn/jabber, et j'en passe.... tout dépend de ce que tu voulais faire smile


Et pourtant moi, jsuis pas du genre délicat,
Dans un coin de la musse, j'ai posé mon matelas
- Paulo Anarkao

Hors ligne

#11 Le 26/08/2012, à 13:20

xavier4811

Re : [RESOLU] Le cauchemar iptables

AlbertLacourt a écrit :
 -m state ! --state INVALID 

C'est pour dire que tu acceptes tous les paquets non invalides ? C'est le rôle du point d'exclamation de faire la négation ?

Exact, c'est égal a

-m state --state NEW,RELATED,ESTABLISHED,UNTRACKED

mais en plus court

AlbertLacourt a écrit :

Et à quoi sert le

 -t filter 

? C'est une précision par rapport aux tables nat et autres que l'on pourrait vouloir gérer ?

Un oubli, inutile. Par défaut, c'est la table filter qui est utilisée donc on peut s'en passer. J'ai pris l'habitude de le préciser dans les scripts pour bien différencier des autres tables.
Je l'ai d'ailleurs supprimé pour raccourcir sur les 2 suivantes.

AlbertLacourt a écrit :

En  fait, je n'ai pas besoin de me préoccuper des différents ports et tout parce que je suis un simple client, mais si j'étais un serveur, il faudrait que j'autorise spécifiquement des ports, c'est cela ?

Oui, en cas de serveur local il faudrait ouvrir les ports correspondants.

Yann a écrit :

Avec une policy OUTPUT a DROP, cela voudrait dire qu'il refuse tout en sortie, à part les paquets qui vont vers le port 80 - c'est à dire les requêtes HTTP.

C'est plus restrictif mais pas in-envisageable c'est sur. Dans ce cas je réitère mon conseil de logger soit built-in dans le syslog soit avec ulog. Au cas ou Albert voudrait aussi envoyer &  recevoir des mails, faire des transferts ftp, naviguer sur des sites sécurisés ...
Juste le 80 ça me parait un peu juste et sans logs, impossible de savoir ce qui est bloqué et dans quel sens.

Une de mes références pour netfilter, y 'en a d'autres bien sur.

Hors ligne

#12 Le 27/08/2012, à 01:35

AlbertLacourt

Re : [RESOLU] Le cauchemar iptables

Alors, après un certain nombre de test :
@ Yann : effectivement, initialement, je pensais bien ouvrir seulement le port OUTPUT 80, et à la rigueur seulement quelques autres, mais malheureusement, même en rajoutant la boucle locale, ça ne marchait pas... Mais après avoir lu vos explications sur les ports de sortie, je me suis dit que je pouvais bien laisser ces ports OUTPUT ouverts. Merci beaucoup !
J'ai installé et parmètré ulog (dans la douleur, encore ^^), mais je n'ai pas eu le temps d'analyser pourquoi avec le seul port 80 OUTPUT était trop restrictif pour aller sur internet
@ xavier4811 : merci pour toutes les infos, je vais continuer de me pencher sur ulog, et en particulier sur la toute nouvelle dernière version 2.0 (disponible sur le site http://netfilter.org/index.html, qui je crois pas celle qu'on a dans les paquets "de base")

Hors ligne

#13 Le 27/08/2012, à 07:46

Yann

Re : [RESOLU] Le cauchemar iptables

Albert > Effectivement si tu n'ouvres que le port 80 ca ne marchera pas, il faut que tu ouvres le 53 pour le DNS (en UDP et non en TCP d'ailleurs, je m'étais planté) - sinon ton navigateur n'arrivera pas à résoudre les noms de domaine.
Good luck!


Et pourtant moi, jsuis pas du genre délicat,
Dans un coin de la musse, j'ai posé mon matelas
- Paulo Anarkao

Hors ligne