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
On Fri, 29 Apr 2005 14:35:58 +0000, Ludovic Maitre wrote:
Je ne vois pas le probleme si le tranfert de zone ne porte que sur la zone publique mais detrompe moi ?
L'information qui est censée être publique est :
Pour tel nom de machine (s'il existe) => donner l'IP correspondante
L'information que tu proposes si l'AXFR est autorisé est :
Pour le domaine en question => donner le nom et l'IP de toutes les entrées
Tu vois la différence ? ;-)
Si le transfert de zone n'est pas autorisé, un attaquant pourra toujours utiliser une attaque par dictionnaire + une attaque par brute-force + des recherches Google + des fuites d'infos dans les bannières (SMTP, POP3, HTTPs attaqué en HTTP, ...) pour composer sa liste de machines, mais rien n'en garantira l'exhaustivité.
De plus, même si tous les noms pointent vers la même machine (comme dans ton cas) et que l'AXFR ne permet donc pas de découvrir de nouvelles machines, le fait de posséder chacun des noms permet tout de même (et ce n'est pas rien !) de garantir que l'on va pouvoir attaquer chacun des VirtualHosts.
De toute façon, ton hébergeur DNS autorise déjà les transferts de zone :-( et il est donc facile de récupérer les 13 enregistrements existants. Et le fait que ce soit désactivé sur ta machine ne diminue pas la fuite d'infos.
Note 1 : ton Bind indique gentiment sa version à qui la demande. Note 2 : tu es sûr que le portmapper (TCP/111) est indispensable ?
Nicob
On Fri, 29 Apr 2005 14:35:58 +0000, Ludovic Maitre wrote:
Je ne vois pas le probleme si le tranfert de zone ne
porte que sur la zone publique mais detrompe moi ?
L'information qui est censée être publique est :
Pour tel nom de machine (s'il existe)
=> donner l'IP correspondante
L'information que tu proposes si l'AXFR est autorisé est :
Pour le domaine en question
=> donner le nom et l'IP de toutes les entrées
Tu vois la différence ?
;-)
Si le transfert de zone n'est pas autorisé, un attaquant pourra
toujours utiliser une attaque par dictionnaire + une attaque par
brute-force + des recherches Google + des fuites d'infos dans les
bannières (SMTP, POP3, HTTPs attaqué en HTTP, ...) pour composer sa
liste de machines, mais rien n'en garantira l'exhaustivité.
De plus, même si tous les noms pointent vers la même machine (comme dans
ton cas) et que l'AXFR ne permet donc pas de découvrir de nouvelles
machines, le fait de posséder chacun des noms permet tout de même (et
ce n'est pas rien !) de garantir que l'on va pouvoir attaquer chacun des
VirtualHosts.
De toute façon, ton hébergeur DNS autorise déjà les transferts de
zone :-( et il est donc facile de récupérer les 13 enregistrements
existants. Et le fait que ce soit désactivé sur ta machine ne diminue
pas la fuite d'infos.
Note 1 : ton Bind indique gentiment sa version à qui la demande.
Note 2 : tu es sûr que le portmapper (TCP/111) est indispensable ?
On Fri, 29 Apr 2005 14:35:58 +0000, Ludovic Maitre wrote:
Je ne vois pas le probleme si le tranfert de zone ne porte que sur la zone publique mais detrompe moi ?
L'information qui est censée être publique est :
Pour tel nom de machine (s'il existe) => donner l'IP correspondante
L'information que tu proposes si l'AXFR est autorisé est :
Pour le domaine en question => donner le nom et l'IP de toutes les entrées
Tu vois la différence ? ;-)
Si le transfert de zone n'est pas autorisé, un attaquant pourra toujours utiliser une attaque par dictionnaire + une attaque par brute-force + des recherches Google + des fuites d'infos dans les bannières (SMTP, POP3, HTTPs attaqué en HTTP, ...) pour composer sa liste de machines, mais rien n'en garantira l'exhaustivité.
De plus, même si tous les noms pointent vers la même machine (comme dans ton cas) et que l'AXFR ne permet donc pas de découvrir de nouvelles machines, le fait de posséder chacun des noms permet tout de même (et ce n'est pas rien !) de garantir que l'on va pouvoir attaquer chacun des VirtualHosts.
De toute façon, ton hébergeur DNS autorise déjà les transferts de zone :-( et il est donc facile de récupérer les 13 enregistrements existants. Et le fait que ce soit désactivé sur ta machine ne diminue pas la fuite d'infos.
Note 1 : ton Bind indique gentiment sa version à qui la demande. Note 2 : tu es sûr que le portmapper (TCP/111) est indispensable ?
Nicob
Patrick Mevzek
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.
Certes, mais on peut par divers moyen accéder souvent à la même chose: 1) en essayant les noms classiques 2) en essayant en reverse toute la classe C concernée, pour commencer 3) éplucher les Received email, les NNTP-Posting-Host, etc...
D'accord ce n'est pas la même chose, et d'accord sur le fond (moi aussi j'interdis par défaut les AXFR), mais c'était juste pour signaler qu'il ne fallait pas se dire qu'on peut mettre un nom dans les DNS, refuser les AXFR et être sûr que jamais personne ne va tomber dessus.
Sans compter vérifier est-ce que les secondaires autorisent ou non les AXFR (ils sont peut-être gérés par une autre entité avec une autre politique). Oui, en théorie ils ne devraient pas. Mais en pratique, on voit de tout dans la nature...
-- 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>
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.
Certes, mais on peut par divers moyen accéder souvent à la même chose:
1) en essayant les noms classiques
2) en essayant en reverse toute la classe C concernée, pour commencer
3) éplucher les Received email, les NNTP-Posting-Host, etc...
D'accord ce n'est pas la même chose, et d'accord sur le fond (moi aussi
j'interdis par défaut les AXFR), mais c'était juste pour signaler qu'il
ne fallait pas se dire qu'on peut mettre un nom dans les DNS, refuser les
AXFR et être sûr que jamais personne ne va tomber dessus.
Sans compter vérifier est-ce que les secondaires autorisent ou non les
AXFR (ils sont peut-être gérés par une autre entité avec une autre
politique). Oui, en théorie ils ne devraient pas. Mais en pratique, on
voit de tout dans la nature...
--
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>
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.
Certes, mais on peut par divers moyen accéder souvent à la même chose: 1) en essayant les noms classiques 2) en essayant en reverse toute la classe C concernée, pour commencer 3) éplucher les Received email, les NNTP-Posting-Host, etc...
D'accord ce n'est pas la même chose, et d'accord sur le fond (moi aussi j'interdis par défaut les AXFR), mais c'était juste pour signaler qu'il ne fallait pas se dire qu'on peut mettre un nom dans les DNS, refuser les AXFR et être sûr que jamais personne ne va tomber dessus.
Sans compter vérifier est-ce que les secondaires autorisent ou non les AXFR (ils sont peut-être gérés par une autre entité avec une autre politique). Oui, en théorie ils ne devraient pas. Mais en pratique, on voit de tout dans la nature...
-- 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>
