Yves Rutschle wrote:
On Mon, Dec 31, 2007 at 12:24:29PM +0100, Pascal Hambourg wrote:C'est contraire aux Ecritures. Il est dit dans RFC 1918 - Address Allocation for Private Internets, verset 5 :l'autre façon, un peu risquée, et d'ajouter les entrées privées sur le dns officiel, mais bon, "tout le monde" saura quelles IPs internes correspondent à tes serveurs, ce qui n'est pas super topQuel problème ça pose?Je comprend qu'il ne faut pas le faire, je ne comprend pas pourquoi c'est un problème de sécurité ("risqué").
disons que s'il n'y a pas un vrai besoin de donner une information, il n'y a aucune raison de la donner. sinon, on peut aussi publier son /etc/passwd et dire que l'attaquant a besoin du mot de passe.
Je ne dis pas qu'il faut tout faire pour cacher les IPs internes (elles sont generalement dans les entêtes mail, et la, c'est pas simple de les cacher sans casser de la vaisselle), mais faire savoir à tout un chacun que 192.168.1.2 est un serveur web, que le .3 est un serveur media, le .4 un serveur ftp, le .5 un samba, ... etc, c'est pas très prudent.
si on est sûr de son firewall et de ses règles de filtrage, soit. mais il faut bien revoir le fonctionnement de la NAT (les règles d'accès s'appliquent-elles avant ou après NAT?, ... etc) et de la gestion de sessions sur son firewall avant (Il ne faut pas oublier qu'il y a encore des implémentations qui ne sont pas si "stateful" que ça. beaucoup de solutions commerciales sacrifient l'inspection TCP "approfondie" au profit des performances. Il reste alors posssible, même si c'est difficile, de rentrer par la où on voulait que ça sorte...).
Bien sûr, il faut tout faire pour que son réseau soit robuste, même avec des informations divulguées, mais bon, comme on dit chez les martiaux, "la meilleure défense, c'est de courir"... (sauf si on aime la bagarre, et dans le cas qui nous concerne, si on aime les logs à la crème).
... j'allais oublier: Bonne année à tout le monde...