Re: Script Iptables pour serveur web Apache2 MySQL ProFTPD avec Port Knocking pour SSH
Le 24/09/2019 à 23:46, G2PC a écrit :
Par exemple, pour ProFTPD, il me semble avoir configuré correctement le
service, mais, le client FileZilla ne semble pas réussir à se connecter
lors de toutes ses tentatives.
Actuellement, j'arrive régulièrement à me connecter au client FTP, mais,
pas à 100%.
Je précise, ce n'est pas la connexion qui semble bloquer
occasionnellement, mais, la lecture des dossiers une fois connecté,
d'après ce que je lis sur FileZilla.
Donc les connexions de données avec les ports de destination dynamiques.
Est-ce que tu as chargé le module de suivi de connexion FTP
nf_conntrack_ftp ?
Si oui, est-ce que tu as réglé l'option nf_conntrack_helper du module
nf_conntrack à 1 puisque je ne vois pas de règle avec CT --helper pour
affecter explicitement le helper ftp aux connexions de commande FTP ?
*raw
# Anti DDOS.
# Les paquets TCP avec le flag SYN à destination des ports 22,80 ou 443 ne seront pas suivi par le connexion tracker et donc traités plus rapidement.
## Les pages ne chargent plus avec cette règle de décommentée tout comme la connexion SSH devient impossible !
En temps normal, ce n'est pas seulement le paquet SYN mais tous les
paquets suivants (entrants et sortants) qu'il faut exclure du suivi de
connexion et accepter. Par contre j'ai vu que tu utilises SYNPROXY qui
interagit avec le suivi de connexion, mais je ne connais pas bien.
# J'enlève la valeur SYN et l'accès web et terminal fonctionne correctement.
-A PREROUTING -p tcp -m multiport --dports 22,80,443 -m tcp --tcp-flags FIN,RST,ACK SYN -j CT --notrack
Cette règle n'a aucune chance de s'appliquer puisque la combinaison
masque/drapeaux est impossible. Tu testes un drapeau qui n'est pas dans
le masque, ça ne peut pas marcher.
# On pourrait interdire le ping avec icmp directement en PREROUTING.
# Pour le moment je vais l'interdire par défaut depuis *filter et autoriser le ping aux services OVH.
# -A PREROUTING -p icmp -j DROP
Erreur fréquente : ICMP, ce n'est pas seulement le ping mais aussi des
messages d'erreur qu'il vaut mieux ne pas bloquer si on veut que les
communications marchent bien.
# Pas de filtrage sur l'interface de loopback.
####
# Le serveur ne doit pas avoir de soucis à communiquer avec lui-même au niveau des services internes.
# Accepter toutes les connexions de la machine locale pour permettre aux services de communiquer entre eux.
-A INPUT -i lo -j ACCEPT
# Par la suite, la règle par défaut va DROP sur tous les OUTPUT non autorisés.
# Je ne sais pas si il est nécessaire d'autoriser le loopback vers l'extérieur, voir à trouver un exemple.
Cette phrase n'a aucun sens puisque le trafic envoyé sur l'interface de
loopback ne va pas vers l'extérieur mais revient.
# L'absence d'autorisation en sortie peut t'elle interférer avec certains services attendant une communication en sortie de loopback ?
# -A OUTPUT -o lo -j ACCEPT
Evidemment ça interfère. Tout paquet envoyé sur l'interface de loopback
passe successivement par les chaînes OUTPUT, POSTROUTING, PREROUTING et
INPUT et doit être accepté dans toutes pour arriver à destination.
-A OUTPUT -m conntrack ! --ctstate INVALID -j ACCEPT
Typiquement, le paquet de réponse SYN/ACK à un paquet SYN dans l'état
UNTRACKED (à cause de -j CT --notrack) serait classé par défaut dans
l'état INVALID. Je ne connais pas l'interaction éventuelle avec SYNPROXY.
####
# Autoriser les services web.
####
# Autoriser les connexions DNS.
-A INPUT -p tcp --dport 53 -j ACCEPT
La machine fait serveur DNS pour l'extérieur ?
-A INPUT -p udp --sport 53 -j ACCEPT
Cette règle est une faille de sécurité en plus d'être inutile.
# Configurer le FTP et le pare-feu pour utiliser la plage de ports passifs entre 49152-65534 proposée par IANA.
# Noter que la connexion de semble pas s'établir à chaque fois et qu'il est nécessaire de retenter la connexion.
# Noter que la connexion fstp n'est pas configurée actuellement. A faire !
Qu'est-ce que la connexion fstp ?
-A OUTPUT -p tcp --sport 21 -m state --state ESTABLISHED -j LOG_ACCEPT
-A OUTPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED -j LOG_ACCEPT
Inutiles puisque ces paquets ont déjà été acceptés par la règle
générique qui autorise les connexions déjà établies.
De toute façon, serait-il vraiment nécessaire de loguer ces paquets ?
-A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j LOG_ACCEPT
-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,RELATED,NEW -j LOG_ACCEPT
Côté serveur, tu ne maîtrises pas la plage de ports du client.
Restreindre les ports source du client à la même plage que celle du
serveur est abusif.
# Autoriser les connexions au serveur web Apache2.
-A INPUT -p tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
-A OUTPUT -p tcp --dport 443 -j ACCEPT
Maintenant que ces paquets sont acceptées, toutes les règles suivantes
censées les limiter ne s'appliqueront pas.
# ATTENTION !
# Un attaquant qui s'en rendrait compte pourrait forger des paquets TCP vers un de ces ports mais avec de fausses adresses IP.
Et il ne recevrait pas les réponses sauf s'il est situé à un emplacement
stratégique du réseau sur le chemin des paquets, donc intérêt limité en
pratique.
########
# Limiter le nombre de connexions simultanées établies à partir d'une adresse IP unique sur un port donné.
########
-A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 4 -j LOG_REJECT
-A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 4 -j LOG_REJECT
-A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above 15 -j LOG_REJECT
Sans effet pour les ports 80 et 443 comme indiqué plus haut.
Reply to: