Bonjour,

je cherche à sécuriser un serveur OVH. Pour le moment j'ai des règles simples:

#!/bin/sh 
 
# Réinitialise les règles
sudo iptables -t filter -F 
sudo iptables -t filter -X 
 
# Bloque tout le trafic
sudo iptables -t filter -P INPUT DROP 
sudo iptables -t filter -P FORWARD DROP 
sudo iptables -t filter -P OUTPUT DROP 
 
# Autorise les connexions déjà établies et localhost
sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
sudo iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
sudo iptables -t filter -A INPUT -i lo -j ACCEPT 
sudo iptables -t filter -A OUTPUT -o lo -j ACCEPT 
 
# ICMP (Ping)
sudo iptables -t filter -A INPUT -p icmp -j ACCEPT 
sudo iptables -t filter -A OUTPUT -p icmp -j ACCEPT 

etc...

etc => ouvrir en input / output en fonction de besoins sur http / ftp / ssh / mail etc.

Mais maintenant je bloque sur ce que je peux ajouter pour le protéger plus. Je pensais ajouter:

iptables -A INPUT -p tcp ! --syn -m state --state NEW,INVALID -j DROP

iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
# flood input
iptables -A INPUT -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A INPUT -p udp -m limit --limit 1/second -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT

# paquet corrompus
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP

mais dois-je les ajouter sur FORWARD (sachant que j'ai un docker mais je ne souhaite pas accèder aux contenair depuis l'extérieur) ? Et connaissez-vous d'autres règles pour améliorer la sécurité ? Sachant que j'ai déjà un fail2ban + portsentry (atcp + audp) ?

Edit: pour information j'ai les mêmes règles sur ip6tables mais nous ne le voyons pas.

-
Edité par K@zymir 18 mars 2020 à 21:43:36

Bonjour,

En terme de sécurité, j'ai tendance à penser que si je ne comprends pas une chose, je ne le fais pas. Parce que dans le cas contraire, c'est le meilleure moyen pour avoir l'effet opposé. De plus, il faut définir contre quoi/qui tu veux te protéger. Tout est relatif à ça en terme de sécurité.

Tes règles "d'anti-flood" c'est une belle faille dans la sécurité et dans la disponibilité de ton serveur.

Déjà, si elles sont placées après toutes les règles qui acceptent les communications entrantes pour les services souhaités, ces règles ne seront jamais atteintes pour ces services. Elles accepteront donc tout le reste à raison de 5 paquets par seconde.

Maintenant, que ce passe-t-il si ces règles sont placées en 1ères:

Et bien tu t'exposeras encore plus au flood  (attaque de type DoS), vu qu'il suffira d'envoyer plus de 5 paquets par seconde pour que tout le reste soit DROP par la règle par exemple (trivial). Sans parler que du coup, tu acceptes tout sans condition pour ces proto

Bref, à enlever (utilise pour ICMP à la limite).

Ta dernière règle de chaine est un DROP, et par défaut tu DROP, c'est redondant. Cette règle doit être dans les première de la chaîne.

Plutôt que de chercher un maximum de chose à mettre sur internet pour assurer la sécu de ton serveur, cherche plutôt à comprendre ce que font ton serveur (les services qu'il propose), iptables, fail2ban, portsentry et comment ils le font. Ainsi, tu peux déterminer ce dont tu as besoin et ce dont tu n'as pas besoin et t'orienter vers la solution adaptée. La quantité n'est pas gage de qualité.

Par ailleurs, OVH propose déjà des solutions de sécurité en amont de ton serveur (dont un pare-feu), il serait bien de voir aussi ce qu'OVH fait déjà pour toi.

Enfin, et ce n'est qu'un  question de préférence, j'utilise nftables à la place d'iptables car la syntaxe est beaucoup plus lisible. Tu n'es pas obligé d'écrire des script bash, tu peux directement écrire dans un format lisible par la commande iptables-apply qui est d'ailleurs bien mieux adaptée pour la config d'un serveur distant.

Et non, tu n'as rien à ajouter dans FORWARD dans ce cas.

-
Edité par KoaTao 20 mars 2020 à 11:25:38

OK merci pour les informations je vais supprimer ces règles dans un premier temps sauf icmp que je vais déplacer au début.

KoaTao a écrit:

Maintenant, que ce passe-t-il si ces règles sont placées en 1ères:

Et bien tu t'exposeras encore plus au flood  (attaque de type DoS), vu qu'il suffira d'envoyer plus de 5 paquets par seconde pour que tout le reste soit DROP par la règle par exemple (trivial). Sans parler que du coup, tu acceptes tout sans condition pour ces proto

je veux bien une explication stp.

Merci.

-
Edité par K@zymir 20 mars 2020 à 17:40:38

Avec Nefilter, le module limit s'utilise avec deux paramètre: une durée et un nombre de paquet sur cette durée (appelé burst). Par défaut, le burst est de 5. Tu définis donc pour une durée donnée le nombre de paquets* qui passent. Une fois que cette limite est atteinte, tout le reste est drop.

*paquets, ou segments, ou datagrammes

Tu peux voir cette valeur par défaut pour le burst en faisant iptables  -L avec les règles que tu nous as donnée par exemple.

Pour ta règle contre le flood en TCP, d'après le man:

[!] --syn
    Only match TCP packets with the SYN bit set and the ACK,RST and FIN bits cleared. Such packets are used to request TCP connection initiation; for example, blocking such packets coming in an interface will prevent incoming TCP connections, but outgoing TCP connections will be unaffected. It is equivalent to --tcp-flags SYN,RST,ACK,FIN SYN. If the "!" flag precedes the "--syn", the sense of the option is inverted. 

Elle accepte donc tous les segments TCP qui initie une connexion`à raison de 5 par seconde. Et une fois la connexion initialisée, les segments qui font partie de cette même connexion seront acceptés par la règle avec --state ESTABLISHED, RELATED.

Pourquoi est-ce trivial? Parce qu'il est très simple de spoof des paquets IP et qu'il existe des outils très simple à utiliser pour ce genre de manipulation.

Je suppose que ces règles (placées à la fin de la chaîne) sont là pour que portsentry puisse détecter un scan, mais il vaudrait mieux dans ce cas désigner spécifiquement les ports concernés par cette règle (ie les ports surveillés par PortSentry). Tout en gardant à l'esprit que si quelqu'un veut vraiment découvrir les services en écoute, il y arrivera. PortSentry va surtout rendre cette tâche bien plus longue et compliquée pour un éventuel attaquant (ce qui est largement suffisant vu que dans 99,99% des cas ce sont des bots qui scannent et tentent de bruteforce en fonction des services découverts).

Maintenant, tu peux me dire que dans la config actuelle, tu t'en fiches que ces paquets soient acceptés car aucun service ne devrait être en écoute en TCP sur des ports que tu n'as pas explicitement ouverts. Mais un(e) oubli/erreur est vite arrivé(e), donc, pour moi, c'est un risque inutile.

-
Edité par KoaTao 21 mars 2020 à 10:02:50

Salut,

je n'ai pas fait de linux depuis longtemps mais j'ai un soucis avec ta configuration. Je laisse KoaTao répondre mais:

• portsentry ne protège que IPv4 et donc il est possible de faire un scan port en IPv6. (Tu peux le supprimer selon moi)
• dans ta configuration tu ne protèges que IPv4 et sur IPv6 c'est un peu open bar.

iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT

iptables -N tcp-filter
iptables -A tcp-filter -j RETURN
iptables -A INPUT -j tcp-filter

iptables -N udp-filter
iptables -A udp-filter -j RETURN
iptables -A INPUT -j udp-filter

iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -i lo -j ACCEPT

j'ajoute mes règles ACCEPT dans le bon filtre après. Et fail2ban s'occupe de l'analyse des logs pour banir si besoin. Si tu fermes l'ensembles des port il n'y a plus besoin de portsentry je trouve.

Je n'ajouterai rien contre la protection DDoS (et je laisse OVH gérer). Ou un max connexion par IP = 100 par exemple mais tu restes vulnérable au spoofing... Et là je ne sais pas comment tu peux t'en protéger.