Je pense avoir stabilise la configuration de mon
firewall/routeur/gateway/... et j'aurais aime avoir un avis dessus, si
vous voyez de grossieres erreurs dedans par exemple (si vous avez le temps).
# Flush existing tables
iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -t nat -F; iptables -t mangle -F
# Accept all from localhost
iptables -A INPUT -s 127.0.0.1 -j ACCEPT
# Accept all from local networks
iptables -A INPUT -s 192.168.0.0/24 -d 192.168.0.2 -j ACCEPT
iptables -A INPUT -s 192.168.100.0/24 -d 192.168.0.2 -j ACCEPT
iptables -A INPUT -s 192.168.0.0/24 -d 192.168.100.1 -j ACCEPT
iptables -A INPUT -s 192.168.100.0/24 -d 192.168.100.1 -j ACCEPT
#Services that we block
iptables -A INPUT -p tcp --dport 135 -j REJECT --reject-with
icmp-admin-prohibited
iptables -A INPUT -p tcp --dport 139 -j REJECT --reject-with
icmp-admin-prohibited
iptables -A INPUT -p tcp --dport 445 -j REJECT --reject-with
icmp-admin-prohibited
iptables -A INPUT -p tcp --dport 1433 -j REJECT --reject-with
icmp-admin-prohibited
# Accept all input that we have initiated
iptables -A INPUT -p tcp -d 192.168.0.2 -m state --state
ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p udp -d 192.168.0.2 -m state --state
ESTABLISHED,RELATED -j ACCEPT
# Do masquerading for WLAN
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth1 -j SNAT --to
192.168.0.2
#
# Public services
#
# FTP
#Not used (passive ftp):iptables -A INPUT -p tcp --dport 20 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
# SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# SMTP
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
# DNS - no more external service
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
# HTTP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# POP - no more external service
iptables -A INPUT -p tcp --dport 110 -j ACCEPT
# identd - auth
iptables -A INPUT -p tcp --dport 111 -j ACCEPT
iptables -A INPUT -p udp --dport 111 -j ACCEPT
# HTTPS
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# CVS
iptables -A INPUT -p tcp --dport 2401 -j ACCEPT
# ICMP
iptables -A INPUT -p icmp -j ACCEPT
Merci par avance,
--
Cordialement,
---
Ludo
----
http://www.ubik-products.com
Je pense avoir stabilise la configuration de mon firewall/routeur/gateway/... et j'aurais aime avoir un avis dessus, si vous voyez de grossieres erreurs dedans par exemple (si vous avez le temps). Peut etre manque t il les informations suivantes:
le LAN est 192.168.0.0 le WLAN est 192.168.100.0
le serveur sur lequel sont installees ces regles est un serveur web de developpement. (d'ou les ports)
le serveur a pour adresse 192.168.0.2 (eth1) et 192.168.100.1 (eth0 :-( )
la passerelle est en 192.168.0.254 (freebox)
les "clients" (mes autres ordinateurs) sont repartis sur le LAN et le WLAN, j'utilise NFS pour le partage de fichier, il n'y a pas de samba.
D'un autre cote je comprendrais parfaitement que les lecteurs de cette liste ait autre chose a faire qu'a s'exprimer sur mes regles en particulier, vous devez deja en voir toute la journee.
Je pense avoir stabilise la configuration de mon
firewall/routeur/gateway/... et j'aurais aime avoir un avis dessus, si
vous voyez de grossieres erreurs dedans par exemple (si vous avez le
temps).
Peut etre manque t il les informations suivantes:
le LAN est 192.168.0.0
le WLAN est 192.168.100.0
le serveur sur lequel sont installees ces regles est un serveur web de
developpement. (d'ou les ports)
le serveur a pour adresse 192.168.0.2 (eth1) et 192.168.100.1 (eth0 :-( )
la passerelle est en 192.168.0.254 (freebox)
les "clients" (mes autres ordinateurs) sont repartis sur le LAN et le
WLAN, j'utilise NFS pour le partage de fichier, il n'y a pas de samba.
D'un autre cote je comprendrais parfaitement que les lecteurs de cette
liste ait autre chose a faire qu'a s'exprimer sur mes regles en
particulier, vous devez deja en voir toute la journee.
Je pense avoir stabilise la configuration de mon firewall/routeur/gateway/... et j'aurais aime avoir un avis dessus, si vous voyez de grossieres erreurs dedans par exemple (si vous avez le temps). Peut etre manque t il les informations suivantes:
le LAN est 192.168.0.0 le WLAN est 192.168.100.0
le serveur sur lequel sont installees ces regles est un serveur web de developpement. (d'ou les ports)
le serveur a pour adresse 192.168.0.2 (eth1) et 192.168.100.1 (eth0 :-( )
la passerelle est en 192.168.0.254 (freebox)
les "clients" (mes autres ordinateurs) sont repartis sur le LAN et le WLAN, j'utilise NFS pour le partage de fichier, il n'y a pas de samba.
D'un autre cote je comprendrais parfaitement que les lecteurs de cette liste ait autre chose a faire qu'a s'exprimer sur mes regles en particulier, vous devez deja en voir toute la journee.
Bonjour, Bon, puisque personne ne répond, je vais essayer de le faire.
Bonsoir,
Je pense avoir stabilise la configuration de mon firewall/routeur/gateway/... et j'aurais aime avoir un avis dessus, si vous voyez de grossieres erreurs dedans par exemple (si vous avez le temps).
Je mettrais tout en DROP, c'est plus chiant à développer après mais c'est plus propre.
iptables -t nat -F; iptables -t mangle -F
pourquoi la table mangle puisque tu l'utilises pas ? Il faut aussi : iptables -X -t nat
# Accept all from localhost iptables -A INPUT -s 127.0.0.1 -j ACCEPT # Accept all from local networks iptables -A INPUT -s 192.168.0.0/24 -d 192.168.0.2 -j ACCEPT iptables -A INPUT -s 192.168.100.0/24 -d 192.168.0.2 -j ACCEPT iptables -A INPUT -s 192.168.0.0/24 -d 192.168.100.1 -j ACCEPT iptables -A INPUT -s 192.168.100.0/24 -d 192.168.100.1 -j ACCEPT
Il vaut mieux développer au max : rajoute les interfaces (-i eth0 par exemple)
#Services that we block iptables -A INPUT -p tcp --dport 135 -j REJECT --reject-with icmp-admin-prohibited iptables -A INPUT -p tcp --dport 139 -j REJECT --reject-with icmp-admin-prohibited iptables -A INPUT -p tcp --dport 445 -j REJECT --reject-with icmp-admin-prohibited iptables -A INPUT -p tcp --dport 1433 -j REJECT --reject-with icmp-admin-prohibited # Accept all input that we have initiated iptables -A INPUT -p tcp -d 192.168.0.2 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p udp -d 192.168.0.2 -m state --state ESTABLISHED,RELATED -j ACCEPT
Je trouve ça un peu trop cool. Rajoute les interfaces. Je suppose le RELATED relatif au FTP, dans ce cas-là, rajoute les ports pour l'état passif et actif : iptables -A INPUT -p tcp -i eth1 --sport 20 --dport 1024:65535 -m state etc ... iptables -A OUTPUT -p tcp -o eth1 --sport 1024:65535 --dport 1024:65535 etc ...
# Do masquerading for WLAN iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth1 -j SNAT --to 192.168.0.2 # # Public services # # FTP #Not used (passive ftp):iptables -A INPUT -p tcp --dport 20 -j ACCEPT iptables -A INPUT -p tcp --dport 21 -j ACCEPT # SSH iptables -A INPUT -p tcp --dport 22 -j ACCEPT # SMTP iptables -A INPUT -p tcp --dport 25 -j ACCEPT # DNS - no more external service iptables -A INPUT -p tcp --dport 53 -j ACCEPT iptables -A INPUT -p udp --dport 53 -j ACCEPT # HTTP iptables -A INPUT -p tcp --dport 80 -j ACCEPT # POP - no more external service iptables -A INPUT -p tcp --dport 110 -j ACCEPT # identd - auth iptables -A INPUT -p tcp --dport 111 -j ACCEPT iptables -A INPUT -p udp --dport 111 -j ACCEPT # HTTPS iptables -A INPUT -p tcp --dport 443 -j ACCEPT # CVS iptables -A INPUT -p tcp --dport 2401 -j ACCEPT # ICMP iptables -A INPUT -p icmp -j ACCEPT
Merci par avance,
Pareil, rajoute les interfaces pour être plus clair.
Un ch'ti traitement sur les flags des paquets serait bien aussi (syn etc...)
Voilà, en espérant ne pas avoir dit de bêtises.
Samuel.
Bonjour,
Bon, puisque personne ne répond, je vais essayer de le faire.
Bonsoir,
Je pense avoir stabilise la configuration de mon
firewall/routeur/gateway/... et j'aurais aime avoir un avis dessus, si
vous voyez de grossieres erreurs dedans par exemple (si vous avez le
temps).
Je mettrais tout en DROP, c'est plus chiant à développer après mais
c'est plus propre.
iptables -t nat -F; iptables -t mangle -F
pourquoi la table mangle puisque tu l'utilises pas ?
Il faut aussi :
iptables -X -t nat
# Accept all from localhost
iptables -A INPUT -s 127.0.0.1 -j ACCEPT
# Accept all from local networks
iptables -A INPUT -s 192.168.0.0/24 -d 192.168.0.2 -j ACCEPT
iptables -A INPUT -s 192.168.100.0/24 -d 192.168.0.2 -j ACCEPT
iptables -A INPUT -s 192.168.0.0/24 -d 192.168.100.1 -j ACCEPT
iptables -A INPUT -s 192.168.100.0/24 -d 192.168.100.1 -j ACCEPT
Il vaut mieux développer au max : rajoute les interfaces (-i eth0 par
exemple)
#Services that we block
iptables -A INPUT -p tcp --dport 135 -j REJECT --reject-with
icmp-admin-prohibited
iptables -A INPUT -p tcp --dport 139 -j REJECT --reject-with
icmp-admin-prohibited
iptables -A INPUT -p tcp --dport 445 -j REJECT --reject-with
icmp-admin-prohibited
iptables -A INPUT -p tcp --dport 1433 -j REJECT --reject-with
icmp-admin-prohibited
# Accept all input that we have initiated
iptables -A INPUT -p tcp -d 192.168.0.2 -m state --state
ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p udp -d 192.168.0.2 -m state --state
ESTABLISHED,RELATED -j ACCEPT
Je trouve ça un peu trop cool.
Rajoute les interfaces.
Je suppose le RELATED relatif au FTP, dans ce cas-là, rajoute les ports
pour l'état passif et actif :
iptables -A INPUT -p tcp -i eth1 --sport 20 --dport 1024:65535 -m state
etc ...
iptables -A OUTPUT -p tcp -o eth1 --sport 1024:65535 --dport 1024:65535
etc ...
# Do masquerading for WLAN
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth1 -j SNAT --to
192.168.0.2
#
# Public services
#
# FTP
#Not used (passive ftp):iptables -A INPUT -p tcp --dport 20 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
# SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# SMTP
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
# DNS - no more external service
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
# HTTP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# POP - no more external service
iptables -A INPUT -p tcp --dport 110 -j ACCEPT
# identd - auth
iptables -A INPUT -p tcp --dport 111 -j ACCEPT
iptables -A INPUT -p udp --dport 111 -j ACCEPT
# HTTPS
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# CVS
iptables -A INPUT -p tcp --dport 2401 -j ACCEPT
# ICMP
iptables -A INPUT -p icmp -j ACCEPT
Merci par avance,
Pareil, rajoute les interfaces pour être plus clair.
Un ch'ti traitement sur les flags des paquets serait bien aussi (syn etc...)
Bonjour, Bon, puisque personne ne répond, je vais essayer de le faire.
Bonsoir,
Je pense avoir stabilise la configuration de mon firewall/routeur/gateway/... et j'aurais aime avoir un avis dessus, si vous voyez de grossieres erreurs dedans par exemple (si vous avez le temps).
Je mettrais tout en DROP, c'est plus chiant à développer après mais c'est plus propre.
iptables -t nat -F; iptables -t mangle -F
pourquoi la table mangle puisque tu l'utilises pas ? Il faut aussi : iptables -X -t nat
# Accept all from localhost iptables -A INPUT -s 127.0.0.1 -j ACCEPT # Accept all from local networks iptables -A INPUT -s 192.168.0.0/24 -d 192.168.0.2 -j ACCEPT iptables -A INPUT -s 192.168.100.0/24 -d 192.168.0.2 -j ACCEPT iptables -A INPUT -s 192.168.0.0/24 -d 192.168.100.1 -j ACCEPT iptables -A INPUT -s 192.168.100.0/24 -d 192.168.100.1 -j ACCEPT
Il vaut mieux développer au max : rajoute les interfaces (-i eth0 par exemple)
#Services that we block iptables -A INPUT -p tcp --dport 135 -j REJECT --reject-with icmp-admin-prohibited iptables -A INPUT -p tcp --dport 139 -j REJECT --reject-with icmp-admin-prohibited iptables -A INPUT -p tcp --dport 445 -j REJECT --reject-with icmp-admin-prohibited iptables -A INPUT -p tcp --dport 1433 -j REJECT --reject-with icmp-admin-prohibited # Accept all input that we have initiated iptables -A INPUT -p tcp -d 192.168.0.2 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p udp -d 192.168.0.2 -m state --state ESTABLISHED,RELATED -j ACCEPT
Je trouve ça un peu trop cool. Rajoute les interfaces. Je suppose le RELATED relatif au FTP, dans ce cas-là, rajoute les ports pour l'état passif et actif : iptables -A INPUT -p tcp -i eth1 --sport 20 --dport 1024:65535 -m state etc ... iptables -A OUTPUT -p tcp -o eth1 --sport 1024:65535 --dport 1024:65535 etc ...
# Do masquerading for WLAN iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth1 -j SNAT --to 192.168.0.2 # # Public services # # FTP #Not used (passive ftp):iptables -A INPUT -p tcp --dport 20 -j ACCEPT iptables -A INPUT -p tcp --dport 21 -j ACCEPT # SSH iptables -A INPUT -p tcp --dport 22 -j ACCEPT # SMTP iptables -A INPUT -p tcp --dport 25 -j ACCEPT # DNS - no more external service iptables -A INPUT -p tcp --dport 53 -j ACCEPT iptables -A INPUT -p udp --dport 53 -j ACCEPT # HTTP iptables -A INPUT -p tcp --dport 80 -j ACCEPT # POP - no more external service iptables -A INPUT -p tcp --dport 110 -j ACCEPT # identd - auth iptables -A INPUT -p tcp --dport 111 -j ACCEPT iptables -A INPUT -p udp --dport 111 -j ACCEPT # HTTPS iptables -A INPUT -p tcp --dport 443 -j ACCEPT # CVS iptables -A INPUT -p tcp --dport 2401 -j ACCEPT # ICMP iptables -A INPUT -p icmp -j ACCEPT
Merci par avance,
Pareil, rajoute les interfaces pour être plus clair.
Un ch'ti traitement sur les flags des paquets serait bien aussi (syn etc...)
Voilà, en espérant ne pas avoir dit de bêtises.
Samuel.
Kevin Denis
Le 28-04-2005, Ludovic Maitre a écrit :
Bonsoir,
Je pense avoir stabilise la configuration de mon firewall/routeur/gateway/... et j'aurais aime avoir un avis dessus, si vous voyez de grossieres erreurs dedans par exemple (si vous avez le temps).
A eviter, amha. Avec cette regle, ton fw peut initier n'importe quelle connection vers l'exterieur. Des qu'un pirate mettra un pied sur ta machine, il pourra sortir ou il veut.
iptables -P FORWARD ACCEPT
Pas forcement genial non plus. Si une de tes machines du LAN est zombifiee, elle pourra sortir sur tout l'internet (meme si de plus en plus de vers/saloperies utilisent le port 80 en dest)
iptables -t nat -F; iptables -t mangle -F # Accept all from localhost iptables -A INPUT -s 127.0.0.1 -j ACCEPT # Accept all from local networks
"all" ca me parait gros quand meme. est ce que ton LAN a vocation a se connecter sur n'importe quel port de ta passerelle?
iptables -A INPUT -s 192.168.0.0/24 -d 192.168.0.2 -j ACCEPT iptables -A INPUT -s 192.168.100.0/24 -d 192.168.0.2 -j ACCEPT iptables -A INPUT -s 192.168.0.0/24 -d 192.168.100.1 -j ACCEPT iptables -A INPUT -s 192.168.100.0/24 -d 192.168.100.1 -j ACCEPT
Un truc qui me surprend, c'est qu'il n'est nulle part fait mention de tes interfaces d'entree et de sortie.
#Services that we block iptables -A INPUT -p tcp --dport 135 -j REJECT --reject-with icmp-admin-prohibited
ce n'est pas "deprecated" cet icmp?
iptables -A INPUT -p tcp --dport 139 -j REJECT --reject-with icmp-admin-prohibited iptables -A INPUT -p tcp --dport 445 -j REJECT --reject-with icmp-admin-prohibited iptables -A INPUT -p tcp --dport 1433 -j REJECT --reject-with icmp-admin-prohibited # Accept all input that we have initiated iptables -A INPUT -p tcp -d 192.168.0.2 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p udp -d 192.168.0.2 -m state --state ESTABLISHED,RELATED -j ACCEPT
Vu que d'une part, tu autorises tout en INPUT de ton LAN, et que d'autre part rien n'est interdit en sortie, ces deux regles ne servent a rien.
# Do masquerading for WLAN iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth1 -j SNAT --to 192.168.0.2
ce n'est pas du masquerading, c'est du NAT
# # Public services # # FTP #Not used (passive ftp):iptables -A INPUT -p tcp --dport 20 -j ACCEPT iptables -A INPUT -p tcp --dport 21 -j ACCEPT # SSH iptables -A INPUT -p tcp --dport 22 -j ACCEPT # SMTP iptables -A INPUT -p tcp --dport 25 -j ACCEPT # DNS - no more external service iptables -A INPUT -p tcp --dport 53 -j ACCEPT iptables -A INPUT -p udp --dport 53 -j ACCEPT # HTTP iptables -A INPUT -p tcp --dport 80 -j ACCEPT # POP - no more external service iptables -A INPUT -p tcp --dport 110 -j ACCEPT # identd - auth iptables -A INPUT -p tcp --dport 111 -j ACCEPT iptables -A INPUT -p udp --dport 111 -j ACCEPT # HTTPS iptables -A INPUT -p tcp --dport 443 -j ACCEPT # CVS iptables -A INPUT -p tcp --dport 2401 -j ACCEPT
Veux tu vraiment donner acces a tous ces services a tout l'internet?
# ICMP iptables -A INPUT -p icmp -j ACCEPT
Ca, ok.
-- Kevin
Le 28-04-2005, Ludovic Maitre <ludovic.maitre@free.fr> a écrit :
Bonsoir,
Je pense avoir stabilise la configuration de mon
firewall/routeur/gateway/... et j'aurais aime avoir un avis dessus, si
vous voyez de grossieres erreurs dedans par exemple (si vous avez le temps).
A eviter, amha. Avec cette regle, ton fw peut initier n'importe quelle
connection vers l'exterieur.
Des qu'un pirate mettra un pied sur ta machine, il pourra sortir ou
il veut.
iptables -P FORWARD ACCEPT
Pas forcement genial non plus. Si une de tes machines du LAN est
zombifiee, elle pourra sortir sur tout l'internet (meme si de
plus en plus de vers/saloperies utilisent le port 80 en dest)
iptables -t nat -F; iptables -t mangle -F
# Accept all from localhost
iptables -A INPUT -s 127.0.0.1 -j ACCEPT
# Accept all from local networks
"all" ca me parait gros quand meme. est ce que ton LAN a vocation
a se connecter sur n'importe quel port de ta passerelle?
iptables -A INPUT -s 192.168.0.0/24 -d 192.168.0.2 -j ACCEPT
iptables -A INPUT -s 192.168.100.0/24 -d 192.168.0.2 -j ACCEPT
iptables -A INPUT -s 192.168.0.0/24 -d 192.168.100.1 -j ACCEPT
iptables -A INPUT -s 192.168.100.0/24 -d 192.168.100.1 -j ACCEPT
Un truc qui me surprend, c'est qu'il n'est nulle part fait mention
de tes interfaces d'entree et de sortie.
#Services that we block
iptables -A INPUT -p tcp --dport 135 -j REJECT --reject-with
icmp-admin-prohibited
ce n'est pas "deprecated" cet icmp?
iptables -A INPUT -p tcp --dport 139 -j REJECT --reject-with
icmp-admin-prohibited
iptables -A INPUT -p tcp --dport 445 -j REJECT --reject-with
icmp-admin-prohibited
iptables -A INPUT -p tcp --dport 1433 -j REJECT --reject-with
icmp-admin-prohibited
# Accept all input that we have initiated
iptables -A INPUT -p tcp -d 192.168.0.2 -m state --state
ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p udp -d 192.168.0.2 -m state --state
ESTABLISHED,RELATED -j ACCEPT
Vu que d'une part, tu autorises tout en INPUT de ton LAN, et que d'autre
part rien n'est interdit en sortie, ces deux regles ne servent a rien.
# Do masquerading for WLAN
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth1 -j SNAT --to
192.168.0.2
ce n'est pas du masquerading, c'est du NAT
#
# Public services
#
# FTP
#Not used (passive ftp):iptables -A INPUT -p tcp --dport 20 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
# SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# SMTP
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
# DNS - no more external service
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
# HTTP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# POP - no more external service
iptables -A INPUT -p tcp --dport 110 -j ACCEPT
# identd - auth
iptables -A INPUT -p tcp --dport 111 -j ACCEPT
iptables -A INPUT -p udp --dport 111 -j ACCEPT
# HTTPS
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# CVS
iptables -A INPUT -p tcp --dport 2401 -j ACCEPT
Veux tu vraiment donner acces a tous ces services a tout l'internet?
Je pense avoir stabilise la configuration de mon firewall/routeur/gateway/... et j'aurais aime avoir un avis dessus, si vous voyez de grossieres erreurs dedans par exemple (si vous avez le temps).
A eviter, amha. Avec cette regle, ton fw peut initier n'importe quelle connection vers l'exterieur. Des qu'un pirate mettra un pied sur ta machine, il pourra sortir ou il veut.
iptables -P FORWARD ACCEPT
Pas forcement genial non plus. Si une de tes machines du LAN est zombifiee, elle pourra sortir sur tout l'internet (meme si de plus en plus de vers/saloperies utilisent le port 80 en dest)
iptables -t nat -F; iptables -t mangle -F # Accept all from localhost iptables -A INPUT -s 127.0.0.1 -j ACCEPT # Accept all from local networks
"all" ca me parait gros quand meme. est ce que ton LAN a vocation a se connecter sur n'importe quel port de ta passerelle?
iptables -A INPUT -s 192.168.0.0/24 -d 192.168.0.2 -j ACCEPT iptables -A INPUT -s 192.168.100.0/24 -d 192.168.0.2 -j ACCEPT iptables -A INPUT -s 192.168.0.0/24 -d 192.168.100.1 -j ACCEPT iptables -A INPUT -s 192.168.100.0/24 -d 192.168.100.1 -j ACCEPT
Un truc qui me surprend, c'est qu'il n'est nulle part fait mention de tes interfaces d'entree et de sortie.
#Services that we block iptables -A INPUT -p tcp --dport 135 -j REJECT --reject-with icmp-admin-prohibited
ce n'est pas "deprecated" cet icmp?
iptables -A INPUT -p tcp --dport 139 -j REJECT --reject-with icmp-admin-prohibited iptables -A INPUT -p tcp --dport 445 -j REJECT --reject-with icmp-admin-prohibited iptables -A INPUT -p tcp --dport 1433 -j REJECT --reject-with icmp-admin-prohibited # Accept all input that we have initiated iptables -A INPUT -p tcp -d 192.168.0.2 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p udp -d 192.168.0.2 -m state --state ESTABLISHED,RELATED -j ACCEPT
Vu que d'une part, tu autorises tout en INPUT de ton LAN, et que d'autre part rien n'est interdit en sortie, ces deux regles ne servent a rien.
# Do masquerading for WLAN iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth1 -j SNAT --to 192.168.0.2
ce n'est pas du masquerading, c'est du NAT
# # Public services # # FTP #Not used (passive ftp):iptables -A INPUT -p tcp --dport 20 -j ACCEPT iptables -A INPUT -p tcp --dport 21 -j ACCEPT # SSH iptables -A INPUT -p tcp --dport 22 -j ACCEPT # SMTP iptables -A INPUT -p tcp --dport 25 -j ACCEPT # DNS - no more external service iptables -A INPUT -p tcp --dport 53 -j ACCEPT iptables -A INPUT -p udp --dport 53 -j ACCEPT # HTTP iptables -A INPUT -p tcp --dport 80 -j ACCEPT # POP - no more external service iptables -A INPUT -p tcp --dport 110 -j ACCEPT # identd - auth iptables -A INPUT -p tcp --dport 111 -j ACCEPT iptables -A INPUT -p udp --dport 111 -j ACCEPT # HTTPS iptables -A INPUT -p tcp --dport 443 -j ACCEPT # CVS iptables -A INPUT -p tcp --dport 2401 -j ACCEPT
Veux tu vraiment donner acces a tous ces services a tout l'internet?
# ICMP iptables -A INPUT -p icmp -j ACCEPT
Ca, ok.
-- Kevin
David Bizeul
# DNS - no more external service iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
# DNS - no more external service
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
"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 - publications traitant d'EDNS0 ====================================================================== J'avais bien un exemple de requête DNS où la réponse passait en TCP, mais il n'est apparemment plus d'actualité :-(
Nicob
On Fri, 29 Apr 2005 07:56:07 +0000, David Bizeul wrote:
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
Pour la 50.000ième fois :
DNS n'utilise *pas* TCP uniquement pour le transfert de zone !
Copier/coller d'un vieux post sur fr.comp.securite :
====================================================================== Sur le passage en TCP pour une requête DNS :
"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
- publications traitant d'EDNS0
======================================================================
J'avais bien un exemple de requête DNS où la réponse passait en TCP,
mais il n'est apparemment plus d'actualité :-(
"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 - publications traitant d'EDNS0 ====================================================================== J'avais bien un exemple de requête DNS où la réponse passait en TCP, mais il n'est apparemment plus d'actualité :-(
Nicob
Ludovic Maitre
Bonjour,
Et merci pour ta contribution,
David Bizeul wrote:
# DNS - no more external service iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
J'ai deux vues dans mon bind9 : une pour les machines externes (vide actuellement) et une interne. La zone interne sert a: - contourner les problemes de double nat de la Freebox en routeur, - avoir un nommage pour le reseau local - avoir du cache [j'analyze frequemment mes sites webs et fait donc pas mal de resolution DNS]).
La vue pour les machines externes sera peut etre mises en service un jour, c'est pour ca que j'ai laisse ouvert, et a priori rien n'est envoye pour les clients exterieurs (c'est teste).
Je suppose qu'on peut limiter les transferts a d'autres serveurs, en tout etat de cause j'ai deja vu de "demandes" de ce type dans mes logchecks mais elles avaient ete rejetees par mon systeme si j'ai bien suivi.
A priori (mais je ne suis pas expert DNS) ma zone publique contient justement les donnees publiques, c'est a dire uniquement une petite partie des postes de mon reseau avec leur adresse publique et peut etre consultee de l'exterieur non ? Je ne vois pas le probleme si le tranfert de zone ne porte que sur la zone publique mais detrompe moi ? (la zone locale n'est pas declaree dans la vue pour exterieur)
Mais le fait est que je pourrais fermer ce port pour l'exterieur dans la mesure ou la zone publique est geree chez zoneedit.com.
J'etudie les autres points qui m'ont ete soumis mais il est dur de repondre en etant concis. La plupart des points m'apparaissent justifies et seront regles je pense des que j'aurais acheve la dichotomie entre le serveur de travail (cvs, web,...) et le serveur reseau (gateway, routeur, 6bone node [en devenir]). Je monte un second serveur sur une vieille Alpha500/FreeBSD qui devrait a l'avenir me permettre de separer ces deux taches (et de vous soumettre des regles ecrites pour Packet Filter et ALTQ cette fois :-)
Enfin, je me suis pris plus de scans qu'a l'habitude cette nuit et a priori rien n'a cede :-) (je vais quand mettre s/key sur les acces ssh ASAP ;-). (merci de me dire si l'un de lecteurs a un acces root chez moi!)
Merci donc pour vos reponses bien utiles et pertinentes, souhaitant pouvoir etre utile a mon tour un jour, -- Cordialement, --- Ludo ---- http://www.ubik-products.com
Bonjour,
Et merci pour ta contribution,
David Bizeul wrote:
# DNS - no more external service
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
J'ai deux vues dans mon bind9 : une pour les machines externes (vide
actuellement) et une interne. La zone interne sert a:
- contourner les problemes de double nat de la Freebox en routeur,
- avoir un nommage pour le reseau local
- avoir du cache [j'analyze frequemment mes sites webs et fait donc pas
mal de resolution DNS]).
La vue pour les machines externes sera peut etre mises en service un
jour, c'est pour ca que j'ai laisse ouvert, et a priori rien n'est
envoye pour les clients exterieurs (c'est teste).
Je suppose qu'on peut limiter les transferts a d'autres serveurs, en
tout etat de cause j'ai deja vu de "demandes" de ce type dans mes
logchecks mais elles avaient ete rejetees par mon systeme si j'ai bien
suivi.
A priori (mais je ne suis pas expert DNS) ma zone publique contient
justement les donnees publiques, c'est a dire uniquement une petite
partie des postes de mon reseau avec leur adresse publique et peut etre
consultee de l'exterieur non ? Je ne vois pas le probleme si le tranfert
de zone ne porte que sur la zone publique mais detrompe moi ? (la zone
locale n'est pas declaree dans la vue pour exterieur)
Mais le fait est que je pourrais fermer ce port pour l'exterieur dans la
mesure ou la zone publique est geree chez zoneedit.com.
J'etudie les autres points qui m'ont ete soumis mais il est dur de
repondre en etant concis. La plupart des points m'apparaissent justifies
et seront regles je pense des que j'aurais acheve la dichotomie entre le
serveur de travail (cvs, web,...) et le serveur reseau (gateway,
routeur, 6bone node [en devenir]). Je monte un second serveur sur une
vieille Alpha500/FreeBSD qui devrait a l'avenir me permettre de separer
ces deux taches (et de vous soumettre des regles ecrites pour Packet
Filter et ALTQ cette fois :-)
Enfin, je me suis pris plus de scans qu'a l'habitude cette nuit et a
priori rien n'a cede :-) (je vais quand mettre s/key sur les acces ssh
ASAP ;-). (merci de me dire si l'un de lecteurs a un acces root chez moi!)
Merci donc pour vos reponses bien utiles et pertinentes, souhaitant
pouvoir etre utile a mon tour un jour,
--
Cordialement,
---
Ludo
----
http://www.ubik-products.com
# DNS - no more external service iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
J'ai deux vues dans mon bind9 : une pour les machines externes (vide actuellement) et une interne. La zone interne sert a: - contourner les problemes de double nat de la Freebox en routeur, - avoir un nommage pour le reseau local - avoir du cache [j'analyze frequemment mes sites webs et fait donc pas mal de resolution DNS]).
La vue pour les machines externes sera peut etre mises en service un jour, c'est pour ca que j'ai laisse ouvert, et a priori rien n'est envoye pour les clients exterieurs (c'est teste).
Je suppose qu'on peut limiter les transferts a d'autres serveurs, en tout etat de cause j'ai deja vu de "demandes" de ce type dans mes logchecks mais elles avaient ete rejetees par mon systeme si j'ai bien suivi.
A priori (mais je ne suis pas expert DNS) ma zone publique contient justement les donnees publiques, c'est a dire uniquement une petite partie des postes de mon reseau avec leur adresse publique et peut etre consultee de l'exterieur non ? Je ne vois pas le probleme si le tranfert de zone ne porte que sur la zone publique mais detrompe moi ? (la zone locale n'est pas declaree dans la vue pour exterieur)
Mais le fait est que je pourrais fermer ce port pour l'exterieur dans la mesure ou la zone publique est geree chez zoneedit.com.
J'etudie les autres points qui m'ont ete soumis mais il est dur de repondre en etant concis. La plupart des points m'apparaissent justifies et seront regles je pense des que j'aurais acheve la dichotomie entre le serveur de travail (cvs, web,...) et le serveur reseau (gateway, routeur, 6bone node [en devenir]). Je monte un second serveur sur une vieille Alpha500/FreeBSD qui devrait a l'avenir me permettre de separer ces deux taches (et de vous soumettre des regles ecrites pour Packet Filter et ALTQ cette fois :-)
Enfin, je me suis pris plus de scans qu'a l'habitude cette nuit et a priori rien n'a cede :-) (je vais quand mettre s/key sur les acces ssh ASAP ;-). (merci de me dire si l'un de lecteurs a un acces root chez moi!)
Merci donc pour vos reponses bien utiles et pertinentes, souhaitant pouvoir etre utile a mon tour un jour, -- Cordialement, --- Ludo ---- http://www.ubik-products.com
Patrick Mevzek
# DNS - no more external service iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
1) en quoi est-ce un mal d'autoriser le transfert des zones ? 2) mais surtout, TCP/53 n'est pas utilisé que pour un AXFR, mais aussi pour une interrogation normale dont la réponse ne tient pas en UDP.
Bref, filtrer TCP/53 c'est mal. C'est d'ailleurs une erreur classique, comme filtrer tous les ICMP.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
# DNS - no more external service
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
1) en quoi est-ce un mal d'autoriser le transfert des zones ?
2) mais surtout, TCP/53 n'est pas utilisé que pour un AXFR, mais aussi pour une
interrogation normale dont la réponse ne tient pas en UDP.
Bref, filtrer TCP/53 c'est mal.
C'est d'ailleurs une erreur classique, comme filtrer tous les ICMP.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
# DNS - no more external service iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
1) en quoi est-ce un mal d'autoriser le transfert des zones ? 2) mais surtout, TCP/53 n'est pas utilisé que pour un AXFR, mais aussi pour une interrogation normale dont la réponse ne tient pas en UDP.
Bref, filtrer TCP/53 c'est mal. C'est d'ailleurs une erreur classique, comme filtrer tous les ICMP.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pascal
Salut,
# DNS - no more external service iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
TCP ne sert pas que pour le transfert de zone mais aussi pour toute requête/réponse trop grande pour tenir dans un datagramme UDP. C'est vrai qu'en pratique, ça concerne surtout le transfert de zone.
De toute façon, il serait plus logique que l'autorisation de transfert de zone ne soit pas gérée au niveau du firewall mais au niveau de la configuration du service DNS lui-même, zone par zone et hôte par hôte (exemple : seuls les serveurs DNS esclaves pour une zone ont le droit de demander un transfert de cette zone).
-- Pascal Les changements du patch-o-matic-ng Netfilter au jour le jour : http://www.plouf.fr.eu.org/bazar/netfilter/pom/pom-ng-change-parsed.txt
Salut,
# DNS - no more external service
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
TCP ne sert pas que pour le transfert de zone mais aussi pour toute
requête/réponse trop grande pour tenir dans un datagramme UDP. C'est vrai
qu'en pratique, ça concerne surtout le transfert de zone.
De toute façon, il serait plus logique que l'autorisation de transfert de
zone ne soit pas gérée au niveau du firewall mais au niveau de la
configuration du service DNS lui-même, zone par zone et hôte par hôte
(exemple : seuls les serveurs DNS esclaves pour une zone ont le droit de
demander un transfert de cette zone).
--
Pascal
Les changements du patch-o-matic-ng Netfilter au jour le jour :
http://www.plouf.fr.eu.org/bazar/netfilter/pom/pom-ng-change-parsed.txt
# DNS - no more external service iptables -A INPUT -p tcp --dport 53 -j ACCEPT
Tu es bien sûr de vouloir autoriser le transfert de tes zones ?
TCP ne sert pas que pour le transfert de zone mais aussi pour toute requête/réponse trop grande pour tenir dans un datagramme UDP. C'est vrai qu'en pratique, ça concerne surtout le transfert de zone.
De toute façon, il serait plus logique que l'autorisation de transfert de zone ne soit pas gérée au niveau du firewall mais au niveau de la configuration du service DNS lui-même, zone par zone et hôte par hôte (exemple : seuls les serveurs DNS esclaves pour une zone ont le droit de demander un transfert de cette zone).
-- Pascal Les changements du patch-o-matic-ng Netfilter au jour le jour : http://www.plouf.fr.eu.org/bazar/netfilter/pom/pom-ng-change-parsed.txt
Michel Arboi
On Fri Apr 29 2005 at 15:14, Nicob wrote:
Pour la 50.000ième fois :
Ah, toi aussi ? :)
J'avais bien un exemple de requête DNS où la réponse passait en TCP, mais il n'est apparemment plus d'actualité :-(
Suffit de demander : $ host test.arboi.fr.eu.org ;; Truncated, retrying in TCP mode. test.arboi.fr.eu.org has address 127.0.1.5 test.arboi.fr.eu.org has address 127.0.1.6 test.arboi.fr.eu.org has address 127.0.1.7 [snip] test.arboi.fr.eu.org has address 127.0.1.3 test.arboi.fr.eu.org has address 127.0.1.4 $
PS : prière de ne pas abuser, je n'ai pas une bande passante illimitée.
J'avais bien un exemple de requête DNS où la réponse passait en TCP,
mais il n'est apparemment plus d'actualité :-(
Suffit de demander :
$ host test.arboi.fr.eu.org
;; Truncated, retrying in TCP mode.
test.arboi.fr.eu.org has address 127.0.1.5
test.arboi.fr.eu.org has address 127.0.1.6
test.arboi.fr.eu.org has address 127.0.1.7
[snip]
test.arboi.fr.eu.org has address 127.0.1.3
test.arboi.fr.eu.org has address 127.0.1.4
$
PS : prière de ne pas abuser, je n'ai pas une bande passante
illimitée.
J'avais bien un exemple de requête DNS où la réponse passait en TCP, mais il n'est apparemment plus d'actualité :-(
Suffit de demander : $ host test.arboi.fr.eu.org ;; Truncated, retrying in TCP mode. test.arboi.fr.eu.org has address 127.0.1.5 test.arboi.fr.eu.org has address 127.0.1.6 test.arboi.fr.eu.org has address 127.0.1.7 [snip] test.arboi.fr.eu.org has address 127.0.1.3 test.arboi.fr.eu.org has address 127.0.1.4 $
PS : prière de ne pas abuser, je n'ai pas une bande passante illimitée.
On Fri, 29 Apr 2005 14:35:58 +0000, Patrick Mevzek wrote:
en quoi est-ce un mal d'autoriser le transfert des zones ?
Parceque toute fuite d'information sur laquelle on peut agir doit être limitée. Tu ne sais jamais ce qui sera utile/inutile pour un adversaire et donc, dans le doute, tu ne donnes pas les infos.
C'est comme pour un pare-feu : d'abord on interdit tout, puis on autorise au cas par cas, selon les besoins.
Nicob
On Fri, 29 Apr 2005 14:35:58 +0000, Patrick Mevzek wrote:
en quoi est-ce un mal d'autoriser le transfert des zones ?
Parceque toute fuite d'information sur laquelle on peut agir doit être
limitée. Tu ne sais jamais ce qui sera utile/inutile pour un adversaire
et donc, dans le doute, tu ne donnes pas les infos.
C'est comme pour un pare-feu : d'abord on interdit tout, puis on autorise
au cas par cas, selon les besoins.
On Fri, 29 Apr 2005 14:35:58 +0000, Patrick Mevzek wrote:
en quoi est-ce un mal d'autoriser le transfert des zones ?
Parceque toute fuite d'information sur laquelle on peut agir doit être limitée. Tu ne sais jamais ce qui sera utile/inutile pour un adversaire et donc, dans le doute, tu ne donnes pas les infos.
C'est comme pour un pare-feu : d'abord on interdit tout, puis on autorise au cas par cas, selon les besoins.
