Problème iptables, accès extérieur ssh

Support Debian
#1

Bonsoir à tous

Je fais appel à vous car je penche sur ce problème depuis quelques temps et malgré la lecture de beaucoup de sites et/ou tuto et je ne comprend toujours pas certains petit détails.

Tout d’abord je suis sur Debian noyau 2.6.26-2-686, j’ai déjà installé squid ainsi que squidguard pour tester le module de filtrage dont je suis d’ailleurs parfaitement satisfait.

C’est à partir d’ici que viens les quelques soucis, puisque je me suis penché sur iptables, afin de sécuriser correctement le serveur, la configuration réseau de ce dernier est la suivante (en entreprise mais pas sur le vrai réseau local, c’est une configuration de test) :

  • eth0 interface lan adresse 192.168.10.102 netmask 255.255.255.0 tout ça connecté sur un petit switch.
  • eth1 interface externe adresse 192.168.201.4 netmask 255.255.255.248 gw 192.168.201.1 connectée sur une box speedtouch qui est le routeur internet, le serveur sort donc grâce a eth1.

Voici une copie de mon script iptables tel quel en ce moment :
etc/firewall-start

On vide la table FILTRE

iptables -F
iptables -t nat -F

#On vire tout par défaut dans la table FILTRE
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

#On met les tables NAT et MANGLE par defaut sur 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 INPUT ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
iptables -t mangle -P FORWARD ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT

#On active la translation d’adresse
#noyau
echo 1 > /proc/sys/net/ipv4/ip_forward

##################################################

Traffic vers le proxy-firewall

##################################################

on autorise les ping

#iptables -A OUTPUT -p icmp -j ACCEPT
#iptables -A INPUT -p icmp -j ACCEPT

on autorise les requêtes DNS

iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --sport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT

#on autorise le ssh (interface eth0 et eth1)
iptables -A INPUT -p tcp --dport 21000 -i eth0 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 21000 -o eth0 -j ACCEPT
iptables -A INPUT -p tcp --dport 21000 -i eth1 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 21000 -o eth1 -j ACCEPT

#http, https, ftp
iptables -A OUTPUT -p tcp -m multiport --dport 80,443,20,21 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --sport 80,443,20,21 -j ACCEPT

#On autorise le lan a se connecter a Webmin
iptables -A OUTPUT -p tcp --sport 10000 -o eth0 -j ACCEPT
iptables -A INPUT -p tcp --dport 10000 -i eth0 -j ACCEPT

#on autorise les clients à se connecter au proxy
iptables -A OUTPUT -p tcp --sport 8080 -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

###################################################

Traffic vers internet

#On ajoute nos règles pour autoriser le trafic vers internet
##################################################

#DNS
iptables -A FORWARD -p tcp --dport 53 -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -j ACCEPT

#ping
iptables -A FORWARD -p icmp -j ACCEPT

#On accetpte les relation déja établies ou en relation avec celles déjà établies depuis le net
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

###################################################

Traffic depuis internet

#On ajoute nos règles pour autoriser le trafic depuis internet
##################################################

iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG
–log-prefix '[IPTABLES DROP] : '
iptables -A LOG_DROP -j DROP

Il y a surement déjà des erreurs, n’hésitez d’ailleurs pas à les mettre en avant ! Je voudrais maintenant pourvoir accéder à ce serveur depuis l’extérieur, depuis l’adresse 80.***.***.*** qui est l’adresse du routeur @ fixe au passage). J’ai donc penché sur les redirections des requêtes, ici mon serveur ssh écoute sur l’adresse 192.168.10.102:21000 (j’ai préféré changer de port), il faut donc rediriger les requêtes provenant d’internet vers l’adresse 192.168.10.102:21000 en local (si j’ai bien compris).

Ce que je ne comprend pas : J’ai vu sur beaucoup de site expliquant la configuration d’iptables que l’interface externe possédait directement une @ip publique, or moi j’ai une privée mais qui me permet de sortir sur internet. J’ai aussi vu le terme “ppp0”, après m’être renseigné un peu dessus, j’ai du mal a comprendre son utilisation. Du coup je n’arrive pas trop à m’y retrouver au niveau des règles iptables pour arriver à attaquer le serveur ssh de l’extérieur.

Je précise que ssh fonctionne parfaitement en local sur le port 21000 ainsi que webmin (qui ne restera pas très longtemps, juste pour tester iptables).

Voila j’espère avoir été assez clair et vous remercie d’avance de vos réponses !

#2

Bonjour

Un tuto bien fait sur la config du parefeu linux : olivieraj.free.fr/fr/linux/information/firewall/

Ce que je pense être pas bon, ou à affiner :

Tu peux améliorer l’initialisation de tes tables en testant si elles sont chargées avant de les initialiser, avec quelque chose comme çà :

# test et initialisation de la table FILTER
if grep -q filter /proc/net/ip_tables_names
then
      iptables -t filter -P INPUT DROP      
      iptables -t filter -P OUTPUT ACCEPT      
      iptables -t filter -P FORWARD ACCEPT

      iptables -t filter -F # Supression de toutes les règles existantes
      iptables -t filter -X # Supression de toutes les chaines existantes
fi

Que tu répètes pour chaque table, sans oublier la table RAW.

Il vaut mieux purger les règles et chaines après avoir défini les règles par défaut pour éviter un trou momentané pendant lequel le parefeu est vulnérable.

Tu as oublié d’initialiser les règles pour l’interface de rebouclage :

iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

Il y a une erreur sur ta 3ème ligne, enfin c’est pas vraiment une erreur, c’est plus que ca ne correspond pas avec le commentaire, et ca fait doublon avec une autre règle plus bas :

# On vide la table FILTRE
iptables -F
iptables -t nat -F  << la tu vides les règles de la table nat, pas de filter

mais bon, si tu fais comme dis dans les 2 premiers points, ca sera corrigé.

Tu devrais utiliser le suivi des connexion, plutôt que d’essayer de gérer le trafic entrant en réponse au requêtes sortantes avec les ports sources. c’est plus fiable et ca allège le nombre de commande puisque tu ne t’occupes plus des paquets “réponses” entrants (comme tu le fait pour les paquets FORWARD en somme) :

iptables -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT

Tu as plein de règles “OUTPUT” qui ne te sont pas utiles vu la politique par défaut (que t’as définie au début) qui laisse déjà tout passer en sortie.
Idem pour les règles FORWARD

Pour les connexions ftp, utilise le module nf_conntrack_ftp

modprobe ip_conntrack_ftp

Dans ton cas, c’est normal, ton serveur est relié à un routeur, qui lui même à 2 interfaces : une interface avec l’ip privée côté LAN, sur laquelle est connecté ton serveur, et une avec l’ip publique. C’est lui (le routeur speedtouch) qui fait la translation d’adresse LAN <–> WAN.
En gros, t’aurais l’ip publique directement sur eth1 si cette dernière était reliée à un modem simple par exemple.

ppp est un protocole d’accès point à point, pas utile je pense, dans ton problème (quelques explications ici : commentcamarche.net/contents … t/ppp.php3)

Comment as tu fait ta redirection sur le routeur speedtouch exactement ?
Comment as tu testé :
1 - en te positionnant réellement à l’extérieur du LAN ?
2 - depuis le LAN, mais en attaquant l’ip publique ?
Dans le cas 1 -, ben ca devrait marcher, sauf si tu t’es pris les pieds dans le tapis en configurant la redirection sur le routeur.
Dans le cas 2 -, c’est normal que ca ne fonctionne pas, il faut rajouter des règles sur le parefeu pour que ca marche (mais bon, ca n’a aucun intêret de se compliquer la vie si ca marche en local avec l’ip LAN, et de l’extérieur avec l’ip pulique)

#3

Ce n’est pas le seul endroit du script où le commentaire ne correspond pas avec les règles qui suivent (“On vire tout par défaut dans la table FILTRE”, “On active la translation d’adresse”). C’est à se demander si son auteur comprend ce qu’il a écrit.

Tu as bien indentifié les incohérences, mais je trouve hasardeux de proposer des corrections sans connaître le cahier des charges. Exemple : incohérence entre la politique par défaut ACCEPT d’une chaîne et des règles ACCEPT dans cette chaîne, qui font manifestement doublon. Le but est-il de tout accepter, (dans ce cas on vire les règles), ou de tout bloquer sauf explicitement accepté (dans ce cas on met la politique par défaut à DROP) ?

Seulement sur cette adresse ? Par défaut sshd écoute sur toutes les adresses locales, y compris 192.168.201.4.

Un petit mot concernant la configuration du modem-routeur : as-tu bien ajouté une route vers 192.168.10.0/255.255.255.0 (ou /24 en notation CIDR) via 192.168.201.4 ?

#4

Ce n’est pas le seul endroit du script où le commentaire ne correspond pas avec les règles qui suivent (“On vire tout par défaut dans la table FILTRE”, “On active la translation d’adresse”). C’est à se demander si son auteur comprend ce qu’il a écrit.

Tu as bien indentifié les incohérences, mais je trouve hasardeux de proposer des corrections sans connaître le cahier des charges. Exemple : incohérence entre la politique par défaut ACCEPT d’une chaîne et des règles ACCEPT dans cette chaîne, qui font manifestement doublon. Le but est-il de tout accepter, (dans ce cas on vire les règles), ou de tout bloquer sauf explicitement accepté (dans ce cas on met la politique par défaut à DROP) ?
[/quote]
Tu as raison, cependant, je partais du principe qu’il savait ce qu’il voulait faire conceptuellement, en ayant quelques difficultés syntaxiques pour mettre les règles en place, en pratique.
Sinon, après on n’est plus dans l’aide, mais un audit de sécurité :005
Mais bon, c’est sur que c’est ce qu’il faudrait faire…

#5

Merci pour les explications, certains points sont maintenant un peu plus clairs.

Avant toute chose et je m’en excuse, pour les règles suivantes :

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

Les trois doivent être à DROP, j’avais fait une modif de test et n’avait pas édité mon script ou je le sauvegarde. La politique que je souhaite mettre en place est donc de tout bloquer sauf ce qui est explicitement accepté (qui est je pense la plus sécurisante ?)

Ensuite certains commentaires comme celui de l’activation de la translation d’adresse n’est évidemment pas le bon puisqu’il concernait une règle que j’ai viré et idem que paragraphe d’avant, pas mis à jour le script sauvegardé. Donc même si je suis pas un expert en la matière je reste quand même conscient de ce qui est mis en place !

Effectivement, il manquait une redirection sur le routeur que j’ai corrigé toute à l’heure, avec évidemment une grosse amélioration ! J’ai maintenant mon accès ssh extérieur possible, mais en ajoutant la règle suivante dans le script iptables :

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 22 -j DNAT --to-destination 192.168.10.102:22 (Je suis repassé en 22)
Au final cette règle renvoie donc toutes les requêtes arrivant d’eth1 et à destination du port 22 à l’adresse 192.168.10.102 sur le port 22 ?

Au niveau du modem-routeur ce que j’ai ajouté :

[b]Interface Type Adresse externe Adresse interne

Internet NAPT @ippublique 192.168.201.4[/b]

Au niveau optimisation ça doit pas être vraiment au point, n’hésitez pas.

Ouaip seulement, ça pose un quelquonque soucis ?

[quote=“dric64”]Tu as plein de règles “OUTPUT” qui ne te sont pas utiles vu la politique par défaut (que t’as définie au début) qui laisse déjà tout passer en sortie. Idem pour les règles FORWARD
[/quote]

Du coup étant donné que mes politiques défaut sont sur DROP, ces règles deviennent utiles on est d’accord ?

Pour améliorer l’initialisation des tables je m’en occupe tout à l’heure merci, au final je positionne donc ça juste après avoir défini les politiques par défaut ?

#6

Voila, ça ira en ce qui concerne l’audit :smiley:

#7

Du coup étant donné que mes politiques défaut sont sur DROP, ces règles deviennent utiles on est d’accord ?
[/quote]
Oui on est d’accord

[quote=“Stuart”]
Pour améliorer l’initialisation des tables je m’en occupe tout à l’heure merci, au final je positionne donc ça juste après avoir défini les politiques par défaut ?[/quote]

Ben, comme dans l’exemple que je t’ai mis, pour chaque table.

#8

[quote=“Stuart”]iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 22 -j DNAT --to-destination 192.168.10.102:22
Au final cette règle renvoie donc toutes les requêtes arrivant d’eth1 et à destination du port 22 à l’adresse 192.168.10.102 sur le port 22 ? [/quote]
Oui, en TCP (suffisant puisque SSH n’utilise que TCP).

Tu peux le constater toi-même : ça complique, puisqu’il te faut mettre en place deux redirections de port en cascade (“double NAT”), une première sur le modem-routeur et une seconde sur le serveur. Il y avait des alternatives pour éviter la seconde redirection de port sur le serveur :

  • Laisser sshd écouter aussi sur 192.168.201.4 (ou sur toutes les adresses locales, comme par défaut). Il y a une raison particulière à cette restriction ?

  • Déclarer sur le modem-routeur une route vers 192.168.10.0/24 et faire la redirection de port vers 192.168.10.102 directement sur celui-ci qui est joignable grâce à la route déclarée. L’autre avantage de cette solution est qu’il peut éviter de devoir faire du MASQUERADE/SNAT sur le serveur pour l’accès à l’extérieur depuis les machines du LAN alors que le modem-routeur le fait déjà (“double NAT” en sortie). Là encore, il vaut mieux éviter le double NAT en sortie comme en entrée. Moins il y a de NAT, mieux on se porte.

EDIT : pour la (ré)initialisation des tables, n’utiliser le test de la table déjà chargée “à la Dric64” que pour les tables qu’on n’utilise pas. Pour les tables qu’on va utiliser, l’initialisation doit être inconditionnelle.