Je te prie de m'excuser si je me suis mal exprimé, tant en français, anglais, ainsi qu'en informatique, comme je te prie de m'excusr si mes propos te déplaisent.
Nous ne faisons qu'échanger en termes civilisés des idées. C'est une discussion sans problème.
Destiné aux petites structures? non, pas seulement. on ne parle pas de FW Nokia à 6 interfaces, d'accord ni de PIX ou de routeurs Cisco blindés en bundle, on est d'accord, mais ipcop tient bien la charge, et BOT n'est pas nécessaire, un petit tour dans le /etc/rc.d/rc.firewall te permet de faire beaucoup, beaucoup de choses...
Pas vraiment de contradiction mais quelques observations.
1. Ipcop pour petites structures à mon sens, non pas pour des problèmes de tenues en charges, il suffit de mettre hardware en conséquence, mais surtout pour des raisons fonctionnels. De quoi s'agit t il ?
Ip ipcop ne gère pas via son interface :
- Les ip multiples sur red.
- Nat statique, dynamique ou 1:1.
- Load balancing.
- Redondance.
- Policy routing (routage en donction d'un protocole par exemple).
- Dmz Multiples
- Interfaces en pont
- Ip virtuelles
- Proxy arp
- Vlans
- Plus de 4 interfaces physiques ou logiques (et encore avec des rôles très précis)
- Nombre maxi de Syn/seconde et par règles
- Nombre d'entré par ip dans la table d'état
- Nombre maxi de connexion par client
- Les alias ou groupe (ip, proto, ...)
La liste n'est pas exhaustive. Voilà pourquoi dans une structure un peu étoffé ipcop ne suffit pas. Si ces fonctions couvrent les besoins alors tout va bien.
BOT n'est pas nécessaire. Il est juste indispensable. le trafic sortant est pratiquement aussi dangereux que le trafic entrant.
Il est indéniable que l'on peut faire beaucoup de chose dans /etc/rc.d/rc.firewall. Je l'ai fait mais là où je ne saisi plus la cohérence de votre propos :
mais là ils ont besoin de "voir".. çà les rassure si tu préfères...ils gardent à l'esprit qu'ils ont la main
Je le comprend parfaitement, mais en ce cas pourquoi modifier /etc/rc.d/rc.firewall à la main ? Que se passera t il lors d'une mise à jour ou d'un oubli dans la documentation ? Je ne conteste pas l'efficacité de la méthode mais sa cohérence avec le propos. Cela nous ramène directement à l'origine de ce fil.
A ce titre j'assure donc la maintenance et surveille donc les logs!
Tout les combien de temps ? Il faut 1mn 30 pour mettre en oeuvre l'exploit sur la dernière faille trouvé sur le FTP de microsoft. Avec le bon outil c'est vrai aussi pour des centaines de failles. Plutôt que de mettre un ids qui, si il n'est pas à jour laissera passer l'exploit, il est plus efficace de recourir à des firawalls applicatifs et ne pas laisser du Microsoft en face à face direct avec internet. Ce n'est d'ailleurs pas limité à Microsoft. La durée de vie d'un serveur Apache dans sa configuration par défaut est assez limité.
Si on évoque le problème des connexions SSL, que peut faire votre ids face à ce trafic ? Rien ! J'ai pourtant une admiration certaine pour un outil comme Snort mais il faut se rendre à l'évidence : il y a mieux à faire avant de l'utiliser.
Je ne suis pas d'accord quand tu dis qu'activer snort n'a pas grand sens sur ipcop. il y aurait portsentry, ce serait mieux, c'est systématiquement comme çà que j'installe mes fws, mais çà n'est pas le cas, et rajouter un IDS n'est pas idiot sur un système central qui gère la sécurité des réseaux.
Je persiste et je signe. Dans cette configuration l'ids est détectable et partant de là on peut l'éluder. Il ne reste plus beaucoup de son efficacité.
Il peut être utile de blacklister une ip source qui vient de faire un scan de port de 1 à 10 000 ... mais ce n'est pas l'agresseur que je crains le plus.
Dans les nuits de samedi à dimanche, ou entre vendredi 18h et lundi 9h, vous regardez combien de fois les logs des systèmes de vos clients ?
Maintenant vous menez votre barque comme vous le souhaitez. Je ne vous conteste rien sur ce point.