Nmap dit le contraire d'iptables

Bonjour, je viens de m’apercevoir d’un petit soucis

mon iptables j’ai une ligne

et en fin d’input j’ai une ligne

depuis le temps où je me connectais via mon proxy je remarquais bien, en passant par le proxy, la connection ssh fonctionne, sans passer par là à plus de ssh.

mais ce que je comprends pas c’est qu’avec un nmap j’obtiens un port ssh ouvert alors qu’il est plutôt censé être “filtré” non?

pareil en entrée j’autorise que ssh (filtré), http et https, mais le nmap me détecte le port smtp ouvert !! alors qu’en fait je ne l’ai ouvert qu’en OUTPUT
est ce que le fait que j’autorise le smtp en output et que j’autorise les connexions déjà établies ca me garde le smtp ouvert en input?
que s’est il passé avec le ssh?

voici mon script de parefeu

[quote]#!/bin/sh

#Remise à zéro des règles du parefeu
iptables -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

#Input
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -s MONIP --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport http -j ACCEPT
iptables -A INPUT -p tcp --dport https -j ACCEPT

iptables -P INPUT DROP

#Output
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport http -j ACCEPT
iptables -A OUTPUT -p tcp --dport https -j ACCEPT
#pas trop utile normalement car connexion http vers les serveurs de mise à jour
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
#iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -P OUTPUT DROP

#Forward
iptables -P FORWARD DROP

Récapitulatif

iptables -L -v[/quote]

Bon voilà quand j’ai fait un

la policy était à ACCEPT, alors j’ai relancé mon script et tout va bien tout est filtré maintenant.

Je soupçonne fail2ban d’être l’auteur de ce changement parce que je l’avais installé entre le lancement du script et le nmap.

[quote=“vger”]#!/bin/sh

#Remise à zéro des règles du parefeu
iptables -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT[/quote]
Très, très mauvais pare feu visiblement qui autorise TOUT (enfin presque).
La politique par defaut de ton script iptables est “ACCEPT”.

Les règles iptables sont appliqués dans l’ordre de ton fichier.
Si une règles est “valide”, les autres sont ignorées.
La chaîne FORWARD ne fonctionne pas par défaut sans modification d’un ou plusieurs fichiers système.

=> On vide les tables
=> On interdit tout ou partie
=> On autorise au “compte goutte”

[strike]et non
=> On vide les tables
=> On autorise tout[/strike]

Plus d’infos:
https://www.isalo.org/wiki.debian-fr/Securite

Bonsoir,

je te remercies mais en fait non. La policy définit en bas n’est absolument pas ignoré tu peux essayer sur un serveur de test.

J’ai désinstallé complètement fail2ban, j’ai lancé mon script mes policy sont à drop et le nmap renvois la quasi totalité des ports comme filtrés.

je réinstalle fail2ban et là pareille mes policy n’ont pas bougé et le nmap est identique.

alors question, comment ca se fait que mon parefeu est tombé “les policy du moins”? je me suis fait piraté?

edit : autant pour moi j’ai dû redémarrer le serveur entre temps … fausse alerte.

A oui excuse moi, je n’avais pas tout regardé. :075

Il serait plus “lisible” de faire directement:

[code]

Remise à zéro des règles du pare feu

iptables -F
iptables -X

Définition des politiques iptables par défaut

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP[/code]

Ah ok merci, IPTABLES -X c’est donc pour reset les policy?

[quote]#!/bin/sh

#Remise à zéro des règles du parefeu
iptables -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

#Input
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -s MONIP --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport http -j ACCEPT
iptables -A INPUT -p tcp --dport https -j ACCEPT

iptables -A INPUT -j DROP
…[/quote]
Ici aussi je fais du filtrage par défaut : J’accepte certains trucs et je dégage tout le reste.

Or, en exécutant ce genre de scripts à distance via SSH, il m’arrivait fréquemment de me couper moi-même l’accès.

Maintenant, en terminant les chaînes comme ci-dessus, je ne me préoccupe plus de cette histoire de “policy” et je ne me coupe plus moi-même la connexion.

/astuce à deux balles


AnonymousCoward

question nulle, Il faut un “-j” pour les policy?

t’en met un aussi pour la policy output?

[quote=“http://lea-linux.org/documentations/Iptables”]
-F --flush : Permet de vider toutes les règles d’une chaîne.
Exemple :

iptables -F INPUT

-X --delete-chain : Permet d’effacer une chaîne.
Exemple :

iptables -X LOG_DROP

-P --policy : Permet de spécifier au noyau la politique par défaut d’une chaîne DENY, ACCEPT, REJECT, DROP …
Exemple :

iptables -P INPUT DROP

[/quote]

Le “iptables -F” devrait donc vider toutes les règles.
Le “iptables -X” devrait donc effacer toutes les chaînes non définies par défaut si il y en a.
Il est inutile de passer la politique à “ACCEPT”, sauf si tu souhaites désactiver ton firewall.