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
# 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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
VANHULLEBUS Yvan
(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
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@please.fr (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
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....
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
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
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:
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: abuse@webatou.net
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
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
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.
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
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/
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/
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
(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.
pasdepublicite@please.fr (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.
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
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.
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.
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
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
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. ;)
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
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".
"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
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".
"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
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".
"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
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
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
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
