Iptables - Debian Lenny [ RESOLU ]

[pu2zl3]

Bonjour,

J'ai une Lenny (sur reseau local derriere freebox en routeur) avec dessus : Postfix qui ne sert qu'à faire de l'envoi depuis mon local, Openssh et Apache qui fait tourner un site sur 80.

Dès que j'applique le script suivant je n'accède plus à aucun service (sans l'exécuter tout marche...) :

Code: Tout sélectionner

#  Interdire toute connexion entrante

iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP

echo - Interdire toute connexion entrante : OK



#  Interdire toute connexion sortante

iptables -t filter -P OUTPUT DROP

echo - Interdire toute connexion sortante : OK



#  Vider tables actuelles

iptables -t filter -F
iptables -t filter -X

echo - Vidage : OK



#Ne pas casser les connexions etablies

iptables -A INPUT -m state --state RELATED,ESTABLISHED
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED

echo - Ne pas casser les conexions etablies : OK



#Autoriser HTTP, SMTP et SSH

iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 2727 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT



echo - HTTP, SMTP, DNS et SSH Autorises : OK

#Autorisation Ping et Loopback

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

echo - ping et loopback autorises : OK



# Autorisation srv locaux Apache, Postfix et SSH

iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 2727 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 25 -s 192.168.0.0/24 -j ACCEPT

echo - SRV Locaux Apache, Postfix et SSH autorises : OK



#Secu SSH

iptables -t filter -A INPUT -p tcp --dport 2727 -m recent --rcheck --seconds 60 --hitcount 2 --name SSH -j LOG --log-prefix "SSH REJECT"
iptables -t filter -A INPUT -p tcp --dport 2727 -m recent --update --seconds 60 --hitcount 2 --name SSH -j DROP
iptables -t filter -A INPUT -p tcp --dport 2727 -m state --state NEW -m recent   --set   --name SSH -j ACCEPT

echo - Secu SSH : OK



# RQ DNS

iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

echo - RQ DNS : OK

Si je désactive la secu pour la chaîne OUTPUT tout refonctionne sauf les requêtes DNS de la machine en question vers l'extérieur.

Voila, si quelqu'un peu m'aider =)

Par rapport à la chaîne OUTPUT c'est juste que j'aimerai comprendre...
Pour les requêtes DNS vers l'extérieur c'est un besoin... sans ça je n'envoie pas de mails...

Merci

[Franck78]

Salut,

Code: Tout sélectionner

Dès que j'applique le script suivant je n'accède plus à aucun service (sans l'exécuter tout marche...)


en voyant que tu attaques lowlevel, on attendrait une explication plus claire de ce qui est bloqué....

Laisse passer 53 sur tcp ET udp

et ajoute une regle de log qui agit en final pour dire "xyz source dest proto : pas de règle"
C'est pratique pour débugguer

Code: Tout sélectionner

## Log le packet non traité
$IPTABLES -A OUTPUT -m limit --limit $LOG_FLOOD -j LOG --log-prefix "FW,no output rule:"


inutile puisque tu ne navigues pas à partir du debian. Sinon il manque https !

Code: Tout sélectionner

iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 2727 -j ACCEPT


ne sert à rien, tu as déjà accepté 2727 avant

Code: Tout sélectionner

#Secu SSH

iptables -t filter -A INPUT -p tcp --dport 2727 -m recent --rcheck --seconds 60 --hitcount 2 --name SSH -j LOG --log-prefix "SSH REJECT"
iptables -t filter -A INPUT -p tcp --dport 2727 -m recent --update --seconds 60 --hitcount 2 --name SSH -j DROP
iptables -t filter -A INPUT -p tcp --dport 2727 -m state --state NEW -m recent   --set   --name SSH -j ACCEPT


[pu2zl3]

Salut,

Merci pour ton intéret et ta rapidité

J'ai autorisé aussi le 53 en tcp (INPUT), même chose : pas de réponse quand je ping xnomdedomaine.com

Pour le LOG en OUTPUT, c'est pas que je suis fainéant mais comme je le disais à la fin de l'autre poste c'est pas une priorité (juste une curiosité)...
Pour l'instant la sécu sur la chaîne OUTPUT est désactivée (lignes commentées ds le script)...

Voila :/

PS : Comme tu me le demandais qu'en même; Quand j'active la secu sur cette chaîne, "rien ne marche" CAD que je n'ai plus accès à la machine sur aucun port. Merci pour la remarque par rapport à SSH ;p

[Franck78]

Code: Tout sélectionner

iptables -t filter -P OUTPUT DROP

alors si tout OUTPUT est décommenté, mais pas rédémarré, forcément la machine ne répondra jamais....car il faut ACCEPT


Il faut comprendre une chose : on peut réfléchir sur le script que tu nous livres. Si en paralèlle tu es sur autre chose (et c'est le cas), on a peu de chance d'arriver quelquepart.

[pu2zl3]

Commenté, je voulais dire que tout ce qui concerne OUTPUT (y compris, bien evidemment la règle que tu cites) est Commenté !!!

dsl, msg précédent édité

[Franck78]

ou comment partir en vrille en trois post.

Au départ on a un joli script a priori buggé
Un test assez vague problèmatique

Une réponse demandant 53 sur tcp ET udp
et demandant des précisions sur le test

Et la réponse à coté !

DONC on reprend tout si tu veux avancer
1)précise les paramètres de chaque test (depuis/vers quelles machines par exemple, la commande employée)
2)précise ce qui change entre avant ca marche après ca marche pas, et particulèrement le script utilisé
3)lance tcpdump sur une console de ta debian pour suivre l'activité sur carte réseau
4)ajoute des logs si tu as envie de débugguer ton truc

[pu2zl3]

Donc nous parlons du problème DNS.

Lorsque la sécu sur la chaîne INPUT du script est activée et celle de la chaine OUTPUT du même script est désactivée.

DNS en udp ET TCP sont maintenant tous deux autorisés.

Même problème.


1 - TCPDUMP ne me montre rien lorsque sur une autre fenêtre du shell je lance un ping sur un nom de domaine (qui ne répond pas).
2 - J'ai essayer d'ajouter la règle proposée pour avoir des logs sur les connexions OUTPUT en la modifiant pour les connexions INPUT. Iptable n'en veut pas : "bad rate -j"

[Franck78]

$LOG_FLOOD, prenons ça pour un petit piège. C'est une variable de MON script qui bien entendu n'existe pas chez toi. Une règle fondamentale est de comprendre ce que l'on fait et manifestement tu copies/colles les yeux fermés. C'est pas bien.
Note aussi qu'il existe la même règle pour INPUT et FORWARD

Maintenant si tu veux bien détailler ton test.

[Franck78]

1 - TCPDUMP ne me montre rien lorsque sur une autre fenêtre du shell je lance un ping sur un nom de domaine (qui ne répond pas).

bon manisfestement il ne veut rien dire l'ami.

Alors ping teste la connectivité avec une machine.
Ping un domaine, ca ne veut rien dire.
On peut par contre interroger un serveur dns (dig).

Tu piges pourquoi on te demande des détails ? Tu interroges un serveur (on ne sait pas lequel), qui peut ne pas exister, avec lequel tu n'a pas vérifier la connectivité, pour vérifier une autre machine dont on ne sait rien et en particulier si elle répond au ping.
Et ta conclusion est le dns ne fonctionne pas. C'est peut être évident de ton coté. Pas ici.

On devine (suppose) que tu testes depuis la debian. Alors comme tcpdump (dont on suppose qu'il écoute la bonne interface car tu as vérifié sans nous le dire 'quand ca marche') n'affiche rien, c'est que rien n'est autorisé à sortir (OUTPUT -j drop).

[pu2zl3]

Il ne peut y avoir de blocage en sortie puisque la chaine OUTPUT ne contient aucune règle.

(depuis la debian) Le ping vers une ip répond, vers un nom de domaine (valide...), il ne répond pas (un dig ne marche pas non plus: connection time out, not reachable).

Mon problème (quand la secu, les regles concernant la chaine INPUT, du script est activée) :

La resolution de nom (à partir de la debian) ne fonctionne pas.

Ma reflexion : vue que rien n'est bloqué en sortie c'est que c'est sur le chemin du retour qu'il y a un probleme ?!
Je ne parle ici que d'un probleme de résolution de nom depuis la debian. Depuis une autre machine vers la debian, les accès vers mes services fonctionnent (web, ssh, smtp).


Merci de votre aide

iptables -L donne :

Code: Tout sélectionner

Chain INPUT (policy DROP)
target     prot opt source               destination
           all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www
ACCEPT     tcp  --  192.168.0.0/24       anywhere            tcp dpt:smtp
ACCEPT     tcp  --   anywhere             anywhere           tcp dpt:2727
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:webmin
ACCEPT     udp  --  anywhere             anywhere            udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:domain
LOG        tcp  --  anywhere             anywhere            tcp dpt:2727 recent: CHECK seconds: 60 hit_count: 2 name: SSH side: source LOG level warning prefix `SSH REJECT'
DROP       tcp  --  anywhere             anywhere            tcp dpt:2727 recent: UPDATE seconds: 60 hit_count: 2 name: SSH side: source
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:2727 state NEW recent: SET name: SSH side: source

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination



Une remarque : Si j'enleve :

iptables -t filter -A INPUT -p tcp --dport 2727 -j ACCEPT

Je n'ai plus accès a la machine depuis l'exterieur (ssh)

Pourtant,

iptables -t filter -A INPUT -p tcp --dport 2727 -m state --state NEW -m recent --set --name SSH -j ACCEPT

est tjrs présent ...

[Franck78]

(depuis la debian) Le ping vers une ip répond, vers un nom de domaine (valide...), il ne répond pas (un dig ne marche pas non plus: connection time out, not reachable).

c'est du chinois Tant que tu seras incapable d'écrire un truc comme

je met en place ce script iptable

Code: Tout sélectionner

....
...et pas un autre ou il faut enlever ci et ajouter ça...
...


j'ai un serveur named(dns) IP 10.0.0.100 opérationel. Quand je l'interroge avec dig depuis ma debian, j'obtient ce message systématiquement (après un certain délai).

Code: Tout sélectionner

ntkiller2:/ # dig @10.0.0.100 titi

; <<>> DiG 9.6.1-P3 <<>> @10.0.0.100 titi
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached


Avant lancement du script iptables, dig répond imédiatement

Code: Tout sélectionner

ntkiller2:/# dig @10.0.0.100 titi

; <<>> DiG 9.6.1-P3 <<>> @10.0.0.100 titi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63922
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;titi.            IN   A

;; Query time: 0 msec
;; SERVER: 10.0.0.100#53(10.0.0.100)
;; WHEN: Tue Jun  7 20:09:43 2011
;; MSG SIZE  rcvd: 22


tcpdump sur la debian me montre bien les paquets (port 53) à destination de 10.0.0.100 mais jamais le retour !

Tu remarqueras que je ne tire pas de conclusion. J'expose.

[jdh]

Ce qui est étonnant dans ce script, c'est qu'il n'est pas fait mention de l'interface "lo" (d'adresse 127.0.0.1) !
Et pourtant, elle est nécessaire ... (enfin AMHA)

Par exemple, quand on accède au service ssh de la machine (ip du lan), le service tente de résoudre l'adresse ip qui tente d'accéder.
Cela se fait par "lo" avant d'être "ethX", me semble-t-il.


Ce script est, par ailleurs, très éloigné de ce que j'ai pu écrire, il y a 10-12 ans.
Par exemple, la tradition est d'initialiser les chaines (-F, -X) puis les policy, et pas l'inverse !

Il y a 10 ans, j'ai trouvé Shorewall (Shoreline ?), et je n'ai plus JAMAIS écrit de script iptables.
Parce c'est tellement plus simple de remplir 5 fichiers, et il est vraiment difficile de faire une erreur ... si on sait ce qu'on veut.
Quand on voit comment sont construites les chaines (iptables -vn -L), on comprend qu'il ne sert plus à rien d'écrire soi-même un script.

Il y a un moment où il faut passer à un plan B. Et Shorewall est incontestablement une bonne solution ...

NB : Par exemple, commencer à aller sur le site Shorewall, mais aussi rechercher ici ce qui a été écrit

[Franck78]

@jdh, si c'est cette ligne pour 'lo'

Code: Tout sélectionner

ACCEPT     all  --  anywhere             anywhere

avec un iptables -L -v -n , c'est plus clair!

par contre celle la est bizarre : pas de target !

Code: Tout sélectionner

           all  --  anywhere             anywhere            state RELATED,ESTABLISHED


d'ici à ce qu'il n'est pas chargé les modules ip_tables*...

enfin bref, il a résolu son truc tout seul et n'ose pas expliquer son erreur