Re: Script Iptables pour serveur web Apache2 MySQL ProFTPD avec Port Knocking pour SSH
Le 25/09/2019 à 14:14, G2PC a écrit : # 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. Hum. Bon, je te crois, je commente donc cette règle, le temps d'avoir plus d'informations sur raw et les règles conseillées. Est ce que le masque avec le SYN (que j'ai retiré) " FIN,SYN,RST,ACK SYN " est plus cohérente que " FIN,RST,ACK SYN " ? Bien sûr. C'est de l'algèbre booléenne de base. La seconde liste de --tcp-flags doit être incluse dans la première liste. "FIN,RST,ACK SYN" signifie "conserver les valeurs des drapeaux FIN, RST et ACK et mettre à 0 les autres (dont SYN), puis renvoyer vrai si dans le résultat SYN=1 (ce qui est impossible) et tous les autres à 0". Comme dit, avec le SYN en deuxième position, les accès sont coupés une fois que je place la règle *filter L'état UNTRACKED doit interférer soit avec le filtrage en entrée, soit avec le filtrage en sortie. Si un paquet SYN a été classé UNTRACKED, alors les paquets suivants de la poignée de main (SYN+ACK sortant et ACK entrant) sont classés par défaut dans l'état INVALID. # 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. Tu parles de mon commentaire concernant la règle OUTPUT qui n'a pas de sens, dès lors ? Je parle de la phrase ci-dessus que j'ai laissée. -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. Je ne sais pas comment appréhender ce retour. Le -j CT --notrack est dans la ligne qui a été désactivée dans la table *raw A suivre. Tu pourrais accepter les paquets SYN+ACK sortants ayant un des ports source concernés par le SYNPROXY. # Autoriser les connexions DNS. -A INPUT -p tcp --dport 53 -j ACCEPT La machine fait serveur DNS pour l'extérieur ? Je ne pense pas ? C'est à dire, est ce qu'elle transmet des informations vers un autre service extérieur ? C'est-à-dire qu'elle répond à des requêtes DNS. Hormis les pages web, non, donc, si je t'entend bien, je peux supprimer les règles DNS ? Il vaut mieux ne pas supprimer les règles qui acceptent les requêtes DNS en sortie. Qu'est-ce que la connexion fstp ? Oups ! sFTP Ça utilise SSH, donc rien à voir avec le protocole FTP. -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 fait beaucoup de paquets à loguer ? Ça loguerait tous les paquets sortants des connexions de commande et de données FTP, soit grosso modo un paquet par commande FTP et un paquet par bloc de 1400 octets de données de fichier téléchargé ou de contenu de répertoire lu. Je ne vois pas l'intérêt, loguer le premier paquet suffit. Le client me dit ceci, on observe que j'arrive bien à me connecter la première fois, puis, sur un second compte il n'arrive pas à récupérer le contenu du dossier. Je me reconnecte au second compte, et, il arrive alors a récupérer le contenu du dossier. Vraiment étrange. Statut : Connexion à 139.99.173.195:21... Statut : Connexion établie, attente du message d'accueil... Statut : Initialisation de TLS... Statut : Vérification du certificat... Statut : Connexion TLS établie. Note : si tu utilises TLS avec FTP, alors le module de suivi de connection nf_conntrack mentionné dans mon message précédent est aveugle et inutile. Statut : Récupération du contenu du dossier... Commande : PWD Réponse : 257 "/" est le répertoire courant Commande : TYPE I Réponse : 200 Type paramétré à I Commande : PASV Réponse : 227 Entering Passive Mode (139,99,173,195,202,139). Commande : LIST Erreur : Connection interrompue après 20 secondes d'inactivité Il faudrait vérifier le port source utilisé par le client pour la connexion de données servant au listage. Attention : si le client est derrière un dispositif NAT (routeur, box), ce dernier peut modifier le port source à la volée. Regarde dans les logs générés par iptables. -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
Re: Script Iptables pour serveur web Apache2 MySQL ProFTPD avec Port Knocking pour SSH
>> >> 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 ? Alors la, bonne question ! J'ai vu passer ce mot clé " conntrack, quelques fois ses derniers jours, mais, je ne crois pas avoir fait quoi que ce soit à ce niveau. Je vais chercher. Merci. >> *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. Comme dit, pour raw, j'ai enlevé ce filtrage sur SYN, car, j'ai un conflit avec *filter à ce moment la, et, je ne peux plus naviguer sur les pages, ni me connecter via SSH avec ma règle Port Knocking. J'ai repris une règle présentée dans un tutoriel, et, je l'ai laissée ainsi, en retirant SYN. Idem, j'ai peu d'informations sur raw et sur ses paquets a supprimer depuis raw. >> # 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. Hum. Bon, je te crois, je commente donc cette règle, le temps d'avoir plus d'informations sur raw et les règles conseillées. Est ce que le masque avec le SYN (que j'ai retiré) " FIN,SYN,RST,ACK SYN " est plus cohérente que " FIN,RST,ACK SYN " ? Comme dit, avec le SYN en deuxième position, les accès sont coupés une fois que je place la règle *filter, par contre, le site est fonctionnel si je ne met QUE les restrictions dans la table *raw , de ce fait, je pense à un effet de bord entre mes règles raw et filter. >> # 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. Ok je prend note, j'ajoute ce commentaire au dessus de la ligne commentée. >> # 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. Tu parles de mon commentaire concernant la règle OUTPUT qui n'a pas de sens, dès lors ? > # 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 OK, je décommente donc la règle OUTPUT pour le loopback. Merci. > > 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. Je ne sais pas comment appréhender ce retour. Le -j CT --notrack est dans la ligne qui a été désactivée dans la table *raw A suivre. > >> >> # Autoriser les services web. >> >> #
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
Script Iptables pour serveur web Apache2 MySQL ProFTPD avec Port Knocking pour SSH
Merci à tous pour vos précédents retours concernant ICMP. J'ai pu avancer, à mon niveau, avec les quelques règles Iptables suivantes. Situation : Serveur VPS OVH - Apache2 MariaDB ProFTPd - Pas de serveur de mail à proprement parler ( Un peu de Exim4 ici et de mutt / mailx par la. ) J'ai tenté de prendre en considérations vos précédents retours, mais, j'ai parfois fait l'impasse, par manque de temps ou de compréhension. Voilà le récapitulatif complet, pour ce que j'ai pu en apprendre et comprendre -> pour le moment <- Vos retours sont les bienvenus pour continuer à améliorer ce script. La bonne nouvelle, c'est que ce script semble fonctionner ! Mes pages web sont délivrées, je peux me connecter à SSH via Port Knocking ! Cela répond à mes premières attentes ! Par contre, il s'y cache peut être des effets de bord, et, certainement, des optimisations à mener. 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. Plus d'informations dans la partie *filter, ou j'ai indiqué la plage de ports que j'ai du ouvrir pour permettre à FileZilla de fonctionner globalement, en utilisant une connexion passive. Je n'en dis pas plus, bonne lecture, et, bonnes critiques ! Règle personnalisée pour configurer Iptables raw # Créer le fichier iptables-firewall-raw.rules et ajouter les règles suivantes. # sudo nano iptables-firewall-raw.rules # Début de la règle raw. *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 ! ## Ce blocage semble apparaître quand j'active les règles de la table raw et filter. ## -A PREROUTING -p tcp -m multiport --dports 22,80,443 -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack # 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 # Donc, ici, j'ai eu un blocage web et de ma connexion SSH, quand je laissais la valeur SYN, puis, que j'ajoutais la règle *filter. # Est ce du à un conflit de règle, entre raw et filter ? # J'ai supprimé la valeur SYN, et, maintenant, les pages web et la connexion SSH semble fonctionner correctement, même après l'ajout de la règle *filter. # Maîtrise de charge. # Regrouper les adresses IP sources par bloc de 256 sous réseaux en /24 et n’autoriser qu'un nombre maximum de demandes de connexions SYN par seconde pour chaque sous réseau. # Utiliser le module hashlimit. Permet de mettre un plafond de connexion par seconde vers le serveur par groupe de 256 IP. -A PREROUTING -p tcp -m tcp --syn -m multiport --dports 22,80,443 -m hashlimit --hashlimit-above 200/sec --hashlimit-burst 1000 --hashlimit-mode srcip --hashlimit-name syn --hashlimit-htable-size 2097152 --hashlimit-srcmask 24 -j DROP # Fin de la règle. COMMIT # Importer le script dans Iptables. # sudo iptables-restore < iptables-firewall-raw.rules # Vérifier que les règles aient bien été ajoutées dans la table raw : # sudo iptables -t raw -L Règle personnalisée pour configurer Iptables mangle # Créer le fichier iptables-firewall-mangle.rules et ajouter les règles suivantes. # sudo nano iptables-firewall-mangle.rules # Début de la règle mangle. *mangle # Bloquer la fragmentation TCP : -A PREROUTING -f -j DROP # Paquet avec SYN et FIN à la fois : -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP # Paquet avec SYN et RST à la fois -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP # Paquet avec FIN et RST à la fois -A PREROUTING -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j DROP # Paquet avec FIN mais sans ACK -A PREROUTING -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP # Paquet avec URG mais sans ACK -A PREROUTING -p tcp -m tcp --tcp-flags ACK,URG URG -j DROP # Paquet avec PSH mais sans ACK -A PREROUTING -p tcp -m tcp --tcp-flags PSH,ACK PSH -j DROP # Paquet avec tous les flags à 1 <=> XMAS scan dans Nmap -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP # Paquet avec tous les flags à 0 <=> Null scan dans Nmap -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP # Paquet avec FIN,PSH, et URG mais sans SYN, RST ou ACK -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP # Paquet avec FIN,SYN,PSH,URG mais sans ACK ou RST -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j DROP # Paquet avec
