@Daniel
Je ne veux pas dénigrer ton travail, c'est une super contribs pour la grande majorité des utilisateurs de SME Server mais dans ta réponse, il y a des points qui me "titillent" un peu :
1) Les cibles ne sont pas disponibles chez CentOS et alors?
2) La volatilité des configurations de Fail2ban, de IpTables, c'est à dire?
3) Blacklist, message d'erreur et problème d'incohérence au niveau de la configuration du serveur?
1)C'est ce qui me gène le plus dans ta réponse, c'est de dire que comme c'est pas dispo alors il ne faut pas triturer ta contrib !
Tout d'abord je ne vois pas ce qui empêche d'installer un iptables à partir des sources mais d'accord en production les RPMs c'est mieux. La cible "tarpit" en question est disponible dans les sources de iptables depuis un bon moment !
L'iptables installé avec une SME Server, n'est pas utilisable dans mon cas, pour l'utilisation que je fais de certaines machines (recherche académique et expérimentation de solution de sécurité open source):
# rpm -qa | grep -i iptables
iptables-1.3.5-9.2.el5_8
Ca pique les yeux ! Cet iptables date de ....janvier 2006 (8 ans). Il y en a eu des corrections de bogues depuis janvier 2006 et des évolutions du Kernel !
On en est à iptables 1.4.21 (
http://www.netfilter.org), je ne l'ai pas encore testé ni même nftables mais pour moi ne pas mettre à jour son iptables c'est quasi criminel.
Surtout qu'apres une installation d'un kernel récent et optimisé à partir des sources (
https://www.kernel.org/) ou un de ceux mis à dispo par la team ELRepo (
http://elrepo.org), on peut mettre à jour iptables facilement:
cd /usr/local/src
wget
http://www.netfilter.org/projects/iptables/files/iptables-1.4.20.tar.bz2 http://www.netfilter.org/projects/iptables/files/iptables-1.4.20.tar.bz2.siggpg --verify iptables-1.4.20.tar.bz2.sig
tar xvjf iptables-1.4.20.tar.bz2
rm -f iptables
ln -sv iptables-1.4.20 iptables
cd iptables
./configure --prefix=/usr \
--exec-prefix= \
--bindir=/usr/bin \
--libdir=/lib64 \
--with-xtlibdir=/lib64/xtables \
--with-pkgconfigdir=/usr/lib64/pkgconfig \
--enable-libipq \
--enable-devel \
--with-ksource=/usr/src/kernels/$(uname -r)-x86_64
make
Débrancher la machine du WAN
rpm -e --nodeps iptables.x86_64
make install
Relancer le "parefeu" de la SME Server
/sbin/e-smith/expand-template /etc/rc.d/init.d/masq
service masq restart
iptables -V
iptables -v -L -n
iptables -j TARPIT -h
iptables -m ipp2p -h
iptables -m layer7 -h
iptables -j ULOG -h
iptables -j LOG -h
Rebrancher au Wan avec un iptables tout neuf. (bon il faut corriger le script /etc/rc.d/init.d/masq qui génère des erreurs en fonction du paramétrage du serveur, on en reparlera à la sortie de la SME10)
Je sais que tu sais faire, l'exemple je le mets juste pour signaler que ce n'est pas impossible à faire
Je penses que tu le sais mais ne pas mettre à jour un maillon aussi essentielle que Iptables pour un serveur c'est pas terrible et en tout cas c'est pas parce que ce n'est pas packagé ou disponible dans un dépôt qu'il ne faut pas le faire d'autant plus que des spec sont eux disponibles pour créer les rpms.
Si on dépasse l'aspect anecdotique de la mise à jour d'iptables, je reconnais que je ne vois pas bien l'intérêt de la blacklist en lien avec la db.
2) La blacklist de Fail2ban, autrement dit le fait que Fail2ban sache quelles Ip il a déjà blacklisté lorsqu'il redémarre, va disparaître comme par magie.
Bizarre parce que sans ta contribs ça marche trés bien et donc avec ta contribs ça continue à fonctionner correctement. Je vais pas rentrer dans le détail du fonctionnement de Fail2ban et du script "/etc/rc.d/init.d/masq" mais là franchement je ne vois pas où tu es allé chercher ça. C'est vrai que le fait de mettre en db sur une SME Server ça ne peut pas faire de mal mais Fail2ban se débrouille trés bien sans la db. Je ne vois pas le lien que tu fais entre la configuration de Fail2ban et celle de l'iptables de SME.
Peux tu m'éclairer sur ce point?
J'ai fait le test en gardant de ta contribs juste les parties concernant le fail2ban.conf et les parties du jail.conf concernant les services à protéger. Les choix que tu fais de configuration sont de toute manière à adapter au besoin de l'admin notamment concernant :
-ignoreip (il faut corriger un bug lorsqu'on ajoute une IP, je t'en reparlerai plus tard)
-backend (la config de la contrib fait planter Fail2ban en cas de mauvais choix/définition de jail)
Fail2ban continue à faire son job même si parfois il a du mal avec la rotation des logs.
Je suis conscient que pour réaliser cette contrib tu as fait des choix au niveau de son code pour en simplifier la configuration en lien avec la db de la SME. Cependant si on prend comme hypothèse que la plupart des attaques que l'on voit passer ont pour origine des IP issues du cloud d'amazon, de pool d'IP de serveurs virtualisés ou d'universités Nord-coréennes, blacklister ces IP n'a pas d'utilité sur le court ou moyen terme. Il vaut mieux privilégier la vitesse de réaction de la machine quitte à utiliser la jail [recidive] pour bannir plus longuement une IP, la mettre en base de donnée voire l'ajouter au script qui génére le host.deny
Surcharger Iptables avec toute une liste d'IP que l'on sait être utilisées que pour faire des attaques ça n'a pas de sens à mon avis.
La vitesse n'est pas un avantage fonctionnel dérisoire quand une machine doit réagir à une attaque. C'est même une caractéristique essentielle de sa capacité à pouvoir se défendre efficacement en fonction des types d'attaque.
Dans le cas des scans de serveur Web ou SMTP, "droper" les IP est moins efficace pour le réseau que de les "tarpiter" car les machines attaquantes vont voir que les ports se sont fermés et vont aller attaquer une autre cible alors que si les ports semblent restés ouverts elles vont "s'acharner" mais la machine cible elle ne verra pas ses performances impactées.
Le fait de fermer les ports donne aussi des informations sur le type de défense mise en place et donc un attaquant chevronné pourrait tenter de la contourner.
Pour mes recherches, je fais aussi tourner différents outils de type honeypot dont un portsentry patché par mes soins sur une SME server avec du "Tarpitage" pour garder les connexions ouvertes.
Le résultat des tests en liant Portsentry, Fail2ban et Tarpit, c'est un ralentissement certain de la vitesse d'attaque de la machine lançant le scan. Dans le cas de nmap, si on simule l'ouverture dynamique de tous les ports, nmap ne sait plus donner de résultats vraiment exploitables. Clairement pour améliorer l'hygiène du réseau élargie la cible tarpit d'iptables permettrait de faire diminuer non pas la quantité d'attaque mais leur vitesse, les rendant ainsi beaucoup moins efficace.
3) Je n'ai pas constaté ce que tu décris concernant des problèmes d'incohérence notamment lors de re-démarrage du service Fail2ban si l'ordre de ré-démarrage est respecté.
C'est à dire en relançant Fail2ban à chaque fois que le script du parefeu est re-généré. Si Fail2ban n'est pas relancé c'est peut-être possible, je vais faire des tests.
En revanche le panel "accès à distance" ne concerne que trés peu de ports et de services (VPN/SSH/FTP), les problèmes d'incohérence devrait être facile à corriger sans limiter la possibilité d'utilisation des actions native de Fail2ban, non?
Ta contrib m'interesse pour savoir si oui ou non elle permet de défendre efficacement une machine, mais si pour l'utiliser il faut exclure les mises à jour du Kernel, de Iptables, les xtables-addons ou les actions fournies par Fail2ban voire l'adaptation des "actionbans" au besoin spécifique de l'admin, c'est un peu embêtant. On va se priver de toutes les correction de bugs et d'outils renforçant cette même sécurité. La puissance de Fail2ban comme parser de log, c'est justement sa capacité à être adapter au besoin, non?
13 Replies
4829 Views