Iptable : Avis sur ma config

Le
pasdepublicite
Bonjour à tous,

Je suis en train d'installer un serveur http/mail chez moi, le serveur n'a
qu'une interface : eth0 sur 192.168.1.0/24.
L'accès à internet se fait via un routeur qui se charge de la NAT, j'ai
mis au point le fichier de config suivant, qu'en pensez vous ?

Le fichier n'a pas encore pu être testé, il est possible que des erreurs
de syntaxe soient présentes.

# But :
# - Laisser entrer/sortir les ICMP interessants
# - Laisser sortir uniquement le dns, smtp, https et http
# - Laisser entrer depuis n'importe ou : http, smtp
# - Laisser entrer uniquement depuis le LAN : pop3, ssh

# Initialisation des chaines
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

# Initialisation des compteurs
iptables -Z INPUT
iptables -Z OUTPUT
iptables -Z FORWARD

# Gestion des logs
iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG --log-prefix '[IPTABLES DROP] : '
iptables -A LOG_DROP -j DROP

iptables -N LOG_ACCEPT
iptables -A LOG_ACCEPT -j LOG --log-prefix '[IPTABLES ACCEPT] : '
iptables -A LOG_ACCEPT -j ACCEPT

# Les comportements par defaut
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Autoriser la boucle locale
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# On accepte le http et le smtp depuis n'importe ou
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j LOG_ACCEPT
iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j LOG_ACCEPT

# On accepte le pop3 et le ssh depuis le reseau local
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 110 -m state --state
NEW -j LOG_ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 22 -m state --state NEW
-j LOG_ACCEPT

# On accepte le dns, smtp, https et http sortant
iptables -A OUTPUT -udp --dport 53 -j ACCEPT
iptables -A OUTPUT -tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -tcp --dport 25 -m state --state NEW -j LOG_ACCEPT
iptables -A OUTPUT -tcp --dport 443 -m state --state NEW -j LOG_ACCEPT
iptables -A OUTPUT -tcp --dport 80 -m state --state NEW -j LOG_ACCEPT

# On ne loggue pas les connexions déja etablies
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# On accepte certains types ICMP en entrée et sortie
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type source-quench -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type source-quench -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type parameter-problem -j ACCEPT


# On loggue les rejets
iptables -A INPUT -j LOG_DROP
iptables -A OUTPUT -j LOG_DROP
iptables -A FORWARD -j LOG_DROP


Merci, Thomas


--
Posté via http://www.webatou.net/
Usenet dans votre navigateur !
Complaints-To: abuse@webatou.net
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
VANHULLEBUS Yvan
Le #574862
(Karmelitre) writes:

Bonjour à tous,

Je suis en train d'installer un serveur http/mail chez moi, le serveur
n'a qu'une interface : eth0 sur 192.168.1.0/24.
L'accès à internet se fait via un routeur qui se charge de la NAT,
j'ai mis au point le fichier de config suivant, qu'en pensez vous ?

Le fichier n'a pas encore pu être testé, il est possible que des
erreurs de syntaxe soient présentes.


Ai pas verifie les erreurs de syntaxe.....


# But :
# - Laisser entrer/sortir les ICMP interessants
# - Laisser sortir uniquement le dns, smtp, https et http
# - Laisser entrer depuis n'importe ou : http, smtp # - Laisser
entrer uniquement depuis le LAN : pop3, ssh

# Initialisation des chaines
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD


Si je suis pointilleux, je dirais que les -P devraient etre faits
juste apres les -F, voire meme avant !


Et si je suis encore un peu plus pointilleux, je dirais qu'il vaudrait
aussi mieux s'assurer que les autres tables (NAT, MANGLE) sont bien
vides....



[....]
# On accepte le http et le smtp depuis n'importe ou
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j LOG_ACCEPT
iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j LOG_ACCEPT


Deja, pour rappel, le state NEW ne FAIT PAS de validations sur les
flags TCP, donc il faut le faire explicitement ( --syn).

Remarque valable aussi pour la suite.....

[....]
# On accepte le pop3 et le ssh depuis le reseau local
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 110 -m state
--state NEW -j LOG_ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 22 -m state --state
NEW -j LOG_ACCEPT


Pour info, vu l'architecture, on ne peut pas avoir la garantie que
l'adresse source n'a pas ete spoofee, il faut donc faire confiance au
routeur devant pour ce genre de choses.....


# On accepte le dns, smtp, https et http sortant
iptables -A OUTPUT -udp --dport 53 -j ACCEPT
iptables -A OUTPUT -tcp --dport 53 -j ACCEPT


Soit le serveur est effectivement succeptible de faire des transferts
de zones (et je serais curieux de savoir pourquoi...), auquel cas ca
sera surement une bonne idee de faire un -m state, soit il n'est pas
succeptible de le faire, et ca ne sert a rien de l'autoriser....

[....]

# On ne loggue pas les connexions déja etablies
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


La encore, le fait qu'un paquet matche l'etat ESTABLISHED n'est pas
necessairement un gage de test "complet" du paquet, essentiellement
pour les paquets TCP....


# On accepte certains types ICMP en entrée et sortie
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type source-quench -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type source-quench -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type parameter-problem -j ACCEPT


Euh, il faudrait eventuellement verifier que c'est bien le cas pour
tous, mais normalement, les paquets ICMPs de ces types seront marques
de l'etat RELATED, donc n'ont pas besoin de regles specifiques (en
plus, du coup, on n'autorise bien que les paquets ICMPs correspondant
a une connexion autorisee....



# On loggue les rejets
iptables -A INPUT -j LOG_DROP
iptables -A OUTPUT -j LOG_DROP
iptables -A FORWARD -j LOG_DROP


Mis a part le fait que ca risque de charger pas mal les logs, c'est
une bonne chose....



A +

VANHU.

pasdepublicite
Le #574687
VANHULLEBUS Yvan wrote:

Si je suis pointilleux, je dirais que les -P devraient etre faits
juste apres les -F, voire meme avant !


Ok, c'est pour eviter de laisser tout passer entre l'initialisation et le
passage de la police par defaut ?

Et si je suis encore un peu plus pointilleux, je dirais qu'il vaudrait
aussi mieux s'assurer que les autres tables (NAT, MANGLE) sont bien
vides....


Ok

Deja, pour rappel, le state NEW ne FAIT PAS de validations sur les
flags TCP, donc il faut le faire explicitement ( --syn).


J'avoue ne pas avoir bien compris à quoi cela sert, ca force iptable à
verifier que les flags TCP sont corrects ? Comme je ne maitrise pas ces
flags, je suis un peu dans le flou.

Pour info, vu l'architecture, on ne peut pas avoir la garantie que
l'adresse source n'a pas ete spoofee, il faut donc faire confiance au
routeur devant pour ce genre de choses.....


Le routeur est un Linksys WRT54G qui utilise iptables, je vais essayer
d'aller voir sa config.

Soit le serveur est effectivement succeptible de faire des transferts
de zones (et je serais curieux de savoir pourquoi...), auquel cas ca
sera surement une bonne idee de faire un -m state, soit il n'est pas
succeptible de le faire, et ca ne sert a rien de l'autoriser....


Si on ne fait pas de transfert de zone, il n'y a que l'udp qui est utilisé
?

La encore, le fait qu'un paquet matche l'etat ESTABLISHED n'est pas
necessairement un gage de test "complet" du paquet, essentiellement
pour les paquets TCP....


Ce qui implique ?

Euh, il faudrait eventuellement verifier que c'est bien le cas pour
tous, mais normalement, les paquets ICMPs de ces types seront marques
de l'etat RELATED, donc n'ont pas besoin de regles specifiques (en
plus, du coup, on n'autorise bien que les paquets ICMPs correspondant
a une connexion autorisee....


Vu que les connexions autorisées sont relatives à des services
applicatifs, comment les paquets ICMP peuvent ils correspondre à une
connexion autorisée ?


Merci, Thomas



--
Posté via http://www.webatou.net/
Usenet dans votre navigateur !
Complaints-To:

tchelaviek
Le #574522
Je suis en train d'installer un serveur http/mail chez moi, le serveur
n'a qu'une interface : eth0 sur 192.168.1.0/24.
L'accès à internet se fait via un routeur qui se charge de la NAT, j'ai
mis au point le fichier de config suivant, qu'en pensez vous ?


Rien. A la moindre faille sur ton serveur http/mail, tes règles peuvent
sauter, même si elles sont bien faites. Mets ton serveur en DMZ.

--
tchelaviek

Pierre LALET
Le #574361
Karmelitre wrote:
Soit le serveur est effectivement succeptible de faire des transferts
de zones (et je serais curieux de savoir pourquoi...), auquel cas ca
sera surement une bonne idee de faire un -m state, soit il n'est pas
succeptible de le faire, et ca ne sert a rien de l'autoriser....


Si on ne fait pas de transfert de zone, il n'y a que l'udp qui est
utilisé ?


Non. C'est une idée très répandue, mais fausse. En effet, le
fonctionnement de DNS est le suivant (sauf erreur de ma part) : la
question est posée en UDP, et le serveur demande au client de reposer sa
question en utilisant TCP si la taille du message UDP de la réponse
dépasse les 512 octets.

Le plus souvent, cela n'arrive que sur des transferts de zone, mais ce
n'est ni nécessaire, ni suffisant.

Pierre

--
Pierre LALET -- http://pierre.droids-corp.org/
Droids Corporation -- http://www.droids-corp.org/
French Honeynet Project -- http://www.frenchhoneynet.org/
Sebek *BSD -- http://honeynet.droids-corp.org/


VANHULLEBUS Yvan
Le #574161
(Karmelitre) writes:

VANHULLEBUS Yvan wrote:

Si je suis pointilleux, je dirais que les -P devraient etre faits
juste apres les -F, voire meme avant !


Ok, c'est pour eviter de laisser tout passer entre l'initialisation et
le passage de la police par defaut ?


Yep.

Nous sommes bien d'accord sur le fait que ca ne va pas etre un
intervalle de temps enorme, mais j'ai bien precise que j'etais
pointilleux :-)


Deja, pour rappel, le state NEW ne FAIT PAS de validations sur les
flags TCP, donc il faut le faire explicitement ( --syn).


J'avoue ne pas avoir bien compris à quoi cela sert, ca force iptable à
verifier que les flags TCP sont corrects ? Comme je ne maitrise pas
ces flags, je suis un peu dans le flou.


Une connexion Tcp doit commencer par un paquet SYN, auquel on va
repondre un paquet SYN+Ack, auquel on va repondre par un paquet ACK.

Et par la suite, plus aucun paquet de la connexion ne devra avoir le
flag SYN.

Et il se trouve que certaines techniques de scan jouent un peu avec
ces flags pour essayer d'etre furtives (enfin, maintenant, ca commence
a etre connu....), et que de toutes facons, on est sur un forum de
securite informatique, donc le bon conseil ne peut etre que "laisser
passer uniquement ce qui est rigoureusement necessaire et
rigoureusement conforme".


Pour info, vu l'architecture, on ne peut pas avoir la garantie que
l'adresse source n'a pas ete spoofee, il faut donc faire confiance au
routeur devant pour ce genre de choses.....


Le routeur est un Linksys WRT54G qui utilise iptables, je vais essayer
d'aller voir sa config.


Comme dit dans un autre post, l'architecture est de toutes facons
"faible", puisqu'un service public est disponible sur la machine.

L'ideal serait effectivement de mettre ce serveur dans une zone
dediee, et de confier a un autre firewall la tache de bloquer le
traffic non necessaire de ce serveur vers le reste du LAN.....


[DNS]
Si on ne fait pas de transfert de zone, il n'y a que l'udp qui est
utilisé ?


En super raccourci, oui.

En fait, une requete DNS est faite en UDP, et soit la reponse rentre
dans un datagramme UDP, soit la reponse est "recommence ta requete en
TCP, mon gars".

En pratique, on peut raisonnablement considerer qu'il n'y a a peu pres
que les transferts de zones qui necessitent de passer en TCP....


La encore, le fait qu'un paquet matche l'etat ESTABLISHED n'est pas
necessairement un gage de test "complet" du paquet, essentiellement
pour les paquets TCP....


Ce qui implique ?


Que si mon vieux cerveau ne me fait pas trop defaut, le fait qu'un
paquet soit ESTABLISHED ne garantit pas (par exemple) qu'il n'a pas le
bit SYN d'actif....

Il faudrait regarder de plus pres dans la doc/dans le source ce qui
est checke et ce qui ne l'est pas.... Quelqu'un peut donner une
precision fiable a ce sujet ?


[ICMP]
Vu que les connexions autorisées sont relatives à des services
applicatifs, comment les paquets ICMP peuvent ils correspondre à une
connexion autorisée ?


????

Reprenons un exemple simple:

La machine emet un paquet vers une adresse IP quelconque, paquet qui
est autorise par le filtrage et qui cree un etat.

Quelquepart plus loin, on emet un "host unreachable", par exemple, par
rapport a ce paquet.

Bah le ICMP "host unreachable" sera reconnu par le filtrage comme
etant relatif au paquet du dessus, qui a ete autorise et qui a cree un
etat.


Ou alors j'ai rien compris a la question ?



A +

VANHU.


Eric Razny
Le #574159
VANHULLEBUS Yvan wrote:

[snap]
[DNS]
[Re-snap]

En fait, une requete DNS est faite en UDP, et soit la reponse rentre
dans un datagramme UDP, soit la reponse est "recommence ta requete en
TCP, mon gars".

En pratique, on peut raisonnablement considerer qu'il n'y a a peu pres
que les transferts de zones qui necessitent de passer en TCP....


Je suis moins d'accord sur ce point (ou plutôt sur le "on peut se passer du
TCP") que ça semble suggérer.

Effectivement il y a très peu de risque que le problème survienne. Mais si
c'est le cas (et comme entre-temps tout le monde sera passé en mode :
DNS=OK) ça risque de rendre dingue le gars qui va avoir à s'en charger, s'il
a la malheur de partir de l'hypothèse que ça ne peut pas venir de là.

Accessoirement un p'tit serveur DNS qui fait la requête lui même (on
redirige tout flux sortant en 53 UDP/TCP sur lui) ça évite aussi les
problème de p2p et autres qui ont un port pour faire mumuse! Même idée du
proxy pour tous les protocoles utilisés si c'est jouable (ça bouffe quand
même des ressources ces petites bêtes :) )

Si besoin est il suffit de mettre plein de MX pour un domaine et voir ce que
ça donne...

Eric


--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.

tchelaviek
Le #573932
L'ideal serait effectivement de mettre ce serveur dans une zone
dediee, et de confier a un autre firewall la tache de bloquer le
traffic non necessaire de ce serveur vers le reste du LAN.....


...et vers l'Internet, s'il te plaît. Ce serait dommage de retrouver
l'adresse du Monsieur dans les logs de ton IDS. ;)

--
tchel

Nicob
Le #573470
On Thu, 29 Apr 2004 08:45:41 +0000, VANHULLEBUS Yvan wrote:

En fait, une requete DNS est faite en UDP, et soit la reponse rentre dans
un datagramme UDP, soit la reponse est "recommence ta requete en TCP, mon
gars".


Sur le passage en TCP pour une requête DNS :

http://www.acmebw.com/askmrdns/archive.php?category&questionb9

"The resolver code will retry a query if it receives a response with
the TC (truncated) bit set. That means the server found there wasn't
enough room in the UDP response packet payload to fit all the required
records (additional data records don't count). The "gold" standard is
512 bytes of payload. This is because the maximum guaranteed
unfragmentable IP packet size has historically been 576 bytes. Minus
headers leaves a little more than 512 bytes of payload."

Sur la limite de 512 octets : section 4.1.4 de la RFC 1035 + diverses
publications sur EDNS0

En pratique, on peut raisonnablement considerer qu'il n'y a a peu pres que
les transferts de zones qui necessitent de passer en TCP....


Exemple : http://www.digipills.com/minilienok/?QYkGKD74em


Nicob

Karmelitre
Le #573221
VANHULLEBUS Yvan wrote:

Une connexion Tcp doit commencer par un paquet SYN, auquel on va
repondre un paquet SYN+Ack, auquel on va repondre par un paquet ACK.

Et par la suite, plus aucun paquet de la connexion ne devra avoir le
flag SYN.

Et il se trouve que certaines techniques de scan jouent un peu avec
ces flags pour essayer d'etre furtives (enfin, maintenant, ca commence
a etre connu....), et que de toutes facons, on est sur un forum de
securite informatique, donc le bon conseil ne peut etre que "laisser
passer uniquement ce qui est rigoureusement necessaire et
rigoureusement conforme".


Si j'ai bien compris, pour etre "sur" qu'il s'agit bien d'une nouvelle
connexion, il faut rajouter le --syn ?

Comme dit dans un autre post, l'architecture est de toutes facons
"faible", puisqu'un service public est disponible sur la machine.


Je ne suis pas tout a fait d'accord, vous ne connaissez pas les autres
machines du reseau, en l'occurence il s'agit d'un portable équipé lui aussi
d'un firewall.



Vu que les connexions autorisées sont relatives à des services
applicatifs, comment les paquets ICMP peuvent ils correspondre à une
connexion autorisée ?




Ou alors j'ai rien compris a la question ?


En fait, je ne savais pas q'une connexion tcp pouvait declencger des paquts
ICMP.

Merci.

--
Thomas Recloux a.k.a Karmelitre
trecloux (chez) w3sys (point) net
http://www.w3sys.net/trecloux


Publicité
Poster une réponse
Anonyme