Je viens de mettre en ligne un serveur perso. J'ai déjà mis en place quelques règles de filtrages IPtables sur ce dernier (avec policy à DROP tout de même) mais je ne suis pas satisfait de ma configuration.
J'ai découvert sur Internet diverses attaques dont j'ignorais l'existence et je souhaiterais m'en prémunir.
Déjà pour commencer ma machine est connecté dernière une box ADSL mais se trouve dans une DMZ (tout le traffic est redirigé vers l'IP du serveur).
Ce serveur sert à la fois de: serveur web, serveur FTP, serveur SSH et bientôt SVN.
Par ailleurs je précise que le gestionnaire de package est pacman (distrib ArchLinux) et qu'il semble établir des connexions FTP pour récupérer les majs.
Ma machine est configurée avec les SYN_cookies, autrement dit je suis plus ou moins protégé contre les TCP-syn flood. Mais en lisant la documentation de netfilter.org j'ai découvert que lors de l'utilisation des syn_cookies il était impossible de filtrer les paquets ACK et que par conséquent nous étions vulnérables à des attaques avec des paquets ACK (en effet un hacker peut chercher a forcer le code qui permet d'établir dans la pile TCP la connexion car avec les syn_cookies la connexion est établie à partir du moment ou le code correct est envoyé dans un paquet ACK après SYN et SYN-ACK).
Du coup comment faire pour se protéger de ces attaques de type brute-force?
Par ailleurs sur un autre site j'ai trouvé la règle suivante pour s'assurer que les connexions TCP entrantes sont bien de type NEW:
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
J'ai un peu du mal à saisir car lorsqu'on reçoit un paquet SYN la connexion n'est pas encore déclarée dans le système donc forcément elle sera en état INVALID et non pas en etat NEW. Du coup je ne comprends pas la règle ci-dessus et son utilité. Voici la page: http://www.cyberciti.biz/tips/linux-ipt ... ttack.html
Sachant également que sur cette page il y a une règle pour les paquets TCP NULL, mais avec --tcp-flages ALL NONE. Ne serait ce pas plutôt tous les flags à NONE?
Maintenant venons-en à la configuration que j'envisage:
chaine INPUT (dans l'ordre): Policy DROP
- acceptation des connexions venant de localhost (-i lo -j ACCEPT)
- acceptation des connexions dejà établies (-p tcp -m state ESTABLISHED,RELATED -j ACCEPT)
- test anti-flood (-j FLOOD). FLOOD est une chaine que j'ai déclaré, j'y viens juste après
- règle acceptation des connexions TCP vers port 22 (SSH)
- règles d'acceptation des connexions TCP vers port ftp et ftp-data
- acceptation des connexions vers le port 80 (HTTP)
- future règle pour le SVN.
chaine FLOOD (chargée de filtrer les demandes trop insistantes): Policy RETURN
- limitation du nombre de connexion vers SSH à 2/min et par IP (-p tcp --dport 22 -m state --state NEW -recent --update --seconds 60 --hitcount 2 -j DROP)
- Autre règle mais limitation à 4 à destination du port 21.
- blocage des connexions qui disent etre localhost sur le port relié au net (-p tcp -i eth0 -s 127.0.0.0/8 -j DROP)
- blocage des XMAS ( -p tcp --tcp-flags ALL ALL -j DROP)
- blocage des NULL ( -p tcp --tcp-flags ALL NONE -j DROP)
Comme vous le voyez par défaut cette chaine retournera vers INPUT si il n'y a aucune correspondance. Le seul role de cette chaine est de limiter le nombre de connexions et rejeter les paquets incohérents.
Mais cependant je ne suis pas vraiment sur des règles XMAS et NULL.
Et par ailleurs je suis toujours vulnérables au TCP flood avec des ACK (vu que j'utilise les syn_cookies).
Pour les connexions sortantes j'autorise les connexions ESTABLISHED,RELATED, tout ce qui provient du port 80, du port 22, et des ports FTP (FTP passif avec ip range déclaré).
Mais je doit aussi déclarer des règles de connexions vers des FTP et port 80 (pour les majs système avec PACMAN). Du coup je me dis que je me rend vulnérable car un rootkit sur la machine pourrait se connecter à un serveur web, ou envoyer des données vers un FTP. Et la non plus je ne sais pas comment sécuriser.
Si il y a des professionnels du réseau parmi vous, ça serait un plaisir de recevoir vos conseils et retour d'expérience.
Je vous remercie
Aurélien
