gratifiant > linux.debian.user.french

G2PC (24/09/2019, 23h50)
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 / mailxpar
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é correctementle
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 plagede
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 latable 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 connexionsSYN 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 FIN,SYN,RST,ACK,URG à 1 mais pas PSH
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP

# Spoofing d'adresses IP source.
# Peu probable pour un serveur avec uniquement une IP publique sur Internet.
# DROP tout ce qui arrive d?un réseau privé/réservé :
-A PREROUTING -s 224.0.0.0/8 -j DROP
-A PREROUTING -s 169.254.0.0/16 -j DROP
-A PREROUTING -s 172.16.0.0/12 -j DROP
-A PREROUTING -s 192.0.2.0/24 -j DROP
-A PREROUTING -s 192.168.0.0/16 -j DROP
-A PREROUTING -s 10.0.0.0/8 -j DROP
-A PREROUTING -s 0.0.0.0/8 -j DROP
-A PREROUTING -s 240.0.0.0/5 -j DROP
-A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP

# 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

# Fin de la règle.
COMMIT

# Importer le script dans Iptables.
# sudo iptables-restore < iptables-firewall-mangle.rules

# Vérifier que les règles aient bien été ajoutées dans la table mangle :
# sudo iptables -t mangle -L

Règle personnalisée pour configurer Iptables filter avec le Port
Knocking

# Créer le fichier iptables-firewall-filter.rules et ajouter les règles suivantes.
# sudo nano iptables-firewall-filter.rules

####
# Début de la règle iptables *filter.
####
# Récapitulatif d'après le tutoriel :
*filter

# Créer trois chaînes pour la journalisation :
-N LOG_ACCEPT
-A LOG_ACCEPT -j LOG --log-prefix "INPUT:ACCEPT:" --log-level 2
-A LOG_ACCEPT -j ACCEPT
-N LOG_REJECT
-A LOG_REJECT -j LOG --log-prefix "INPUT:REJECT: " --log-level 4
-A LOG_REJECT -j REJECT
-N LOG_DROP
-A LOG_DROP -j LOG --log-prefix "INPUT:DROP: " --log-level 4
-A LOG_DROP -j DROP
# Effectuer toutes les actions en une seule fois en passant (-j) à vos chaînes personnalisées au lieu des valeurs par défaut LOG / ACCEPT / REJECT / DROP.
# iptables -A <your_chain_here> <your_conditions_here> -j LOG_ACCEPT
# iptables -A <your_chain_here> <your_conditions_here> -j LOG_REJECT
# iptables -A <your_chain_here> <your_conditions_here> -j LOG_DROP

####
# Liste blanche
####
# Les protections "flood" pourraient entraîner un ban de l'adresse IP via fail2ban.
# Ajouter son adresse IP en liste blanche. Je test le script avant de passer en liste blanche.
# -A INPUT -s Addresse-IP-en-liste-blanche -j ACCEPT

####
# 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 OUTPUTnon autorisés.
# Je ne sais pas si il est nécessaire d'autoriser le loopback vers l'extérieur, voir à trouver un exemple.
# 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

####
# Ne pas couper la connexion actuelle qui est utilisée pour configurer le serveur.
####
# Fermer tous les ports entrants avec IPtables revient a fermer le port SSH et notre accès administrateur actuel !
# Il faut impérativement autoriser les connexions déjà établies avant de fermer les ports !
# Permettre à une connexion ouverte de recevoir du trafic en entrée.
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Permettre à une connexion ouverte d'émettre du trafic en sortie.
# -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m conntrack ! --ctstate INVALID -j ACCEPT

####
# Bloquer tous les ports par défaut pour toutes les connexions entrantes et sortantes.
####
# Les connexions entrantes seront bloquées par défaut.
-P INPUT DROP
# Les connexions destinées à être forwardées seront bloquées par défaut.
-P FORWARD DROP
# Les connexions sortantes seront bloquées par défaut.
-P OUTPUT DROP
# REJECT les paquets est plus propre mais DROP est plus sécurisé !
# Avec DROP, un paquet non solicité qui n'est pas accepté est effacé. Le client attendra de son côté une réponse en vain jusqu'au timeout.
# Avec REJECT, un paquet non solicité qui n'est pas accepté va être suivi d'un message d'erreur pour le client.
# En cas d'envoi de paquets à répétition sur un mauvais port, le serveur ne traitera pas les requêtes avec DROP, alors qu'avecREJECT le serveur prendra le temps de répondre.

####
# Autoriser le port SSH par défaut.
####
# Cette règle est à conserver sauf en cas de configuration du Port Knocking.
###-A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
###-A OUTPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
# Autoriser SSH entrant uniquement à partir d'un réseau spécifique, par exemple, 192.168.100.x.
### -A INPUT -p tcp -s 192.168.100.0/24 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
### -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
### -A OUTPUT -p tcp -d 192.168.100.0/24 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

####
# Début du Port Knocking
####
# Créer les chaînes qui seront utilisées lors de la demande de connexion par frappe de ports.
# Ajouter alors l'ensemble des règles qui doivent s'appliquer.
-N KNOCKING
-N GATE1
-N GATE2
-N GATE3
-N PASSED

####
# DROP les paquets entrants contenant des fragments.
####
# Une attaque par fragments aboutit à la panique des serveurs Linux causant une perte de données.
-A INPUT -f -j LOG_DROP

####
# DROP les connexions dans un état invalide et empêche les paquets ACK d?établir des connexions au serveur.
####
-A INPUT -m state --state INVALID -j LOG_DROP

####
# Autoriser uniquement les paquets TCP SYN.
####
# DROP les connexions TCP entrantes qui ne sont pas des paquets SYN.
-A INPUT -p tcp ! --syn -m state --state NEW -j LOG_DROP
# Faire suivre à SYNPROXY les paquets TCP à destination des ports 22,80 ou 443 avec le flag SYN non suivi (UNTRACKED ou INVALID).
# SYNPROXY répond le SYN-ACK à l'émeteur du SYN et crée une connexion à l'état ESTABLISHED dans conntrack seulement si l'émetteur retourne un ACK valide.
# Les paquets avec un tcp-cookie invalides sont dropés, mais pas ceux avec des flags non-standard, il faudra les filtrer par ailleurs.
-A INPUT -p tcp -m multiport --dports 22,80,443 -m tcp -m state --state INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 146
0
# La règles SYNPROXY doit être suivi de celle-ci pour rejeter les paquets restant en état INVALID.
-A INPUT -p tcp -m multiport --dports 22,80,443 -m tcp -m state --state INVALID -j LOG_DROP

####
# Autoriser les services web.
####
# Autoriser les connexions DNS.
-A INPUT -p tcp --dport 53 -j ACCEPT
-A OUTPUT -p tcp --dport 53 -j ACCEPT
-A INPUT -p udp --sport 53 -j ACCEPT
-A OUTPUT -p udp --dport 53 -j ACCEPT
#
# Autoriser les connexions au serveur FTP sur le port 21. (Le FTP semble régulièrement fonctionner, mais, pas toujours, pourtant, j'ai bien ouvert les ports passifs avec Iptables et configuré les ports passifs dans ProFTPd. Étrange O.o )
# Une connexion FTP passive est préférable, depuis le client FileZilla Edition/Paramètres/Connexion/FTP/ décocher :
# Autoriser un retour sur un autre mode de transfert en cas d'échec
# 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 !
#-A OUTPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
-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 --stateESTABLISHED -j LOG_ACCEPT
#-A INPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT
-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
#
# Autoriser les connexions un serveur de mail SMTP, POP3, IMAP.
# Combiner plusieurs ports dans la même règle avec multiport.
# Mail SMTP:25
# Mail POP3:110
# Mail IMAP:143
# Mail IMAP:993
# Mail POP3S:995
-A INPUT -p tcp -m multiport --dports 25,110,143,993,995 -m state --stateNEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 25,110,143,993,995 -m state --state ESTABLISHED -j LOG_ACCEPT
#
# 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

####
# Optimiser le serveur.
####
########
# Blacklister le scann de ports.
########
# Un attaquant qui cherche à découvrir les services ouverts survotre serveur va tenter d'établir une connexion TCP sur tous les ports.
# Il attendra la réponse du serveur pour détecter les ports ouverts.
# Une première technique consiste à limiter le nombre de paquets typique d'un scan.
# A faire :
# On peut également DROP les paquets indésirables avec les règles mangle.
# Les règles présentes dans mangle forcent l'attaquant à faire un 3WHS dans les règles pour voir ce qui se passe la ou c?est ouvert.
# La policy DROP en INPUT jettera tout le reste.
# On peut alors utiliser par exemple un mécanisme de ports piégés qui ne sont pas utilisés sur la machine.
# On blackliste un certain temps les machines qui vont tenter de se connecter aux ports piégés.
-A INPUT -m recent --rcheck --seconds 86400 --name portscan --mask 255.255.255.255 --rsource -j LOG_DROP
-A INPUT -m recent --remove --name portscan --mask 255.255.255.255 --rsource
-A INPUT -p tcp -m multiport --dports 445,1433,3389,10000 -m recent --set--name portscan --mask 255.255.255.255 --rsource -j LOG_DROP
# ATTENTION !
# Un attaquant qui s'en rendrait compte pourrait forger des paquets TCP vers un de ces ports mais avec de fausses adresses IP.
# Le projet Scapy permet de forger des paquets TCP :
# Le serveur se mettrait à blacklister tout internet pour 24h si l'attaquant décidait de parcourir la plage IPv4 complète.
# Cette règle fonctionne bien sur un petit serveur mais il n'est pasconseillé de la mettre en production pour une grande entreprise.

########
# 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

########
# Faire face au flood.
########
-A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
-A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
-A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT

# Limiter à 1 demandes de connexion par seconde pour une IP sur le protocole SSH.
-A INPUT -p tcp --syn --dport ssh -m connlimit --connlimit-above 1 -j LOG_DROP
# Autoriser uniquement 3 connexions en SSH sur un intervalle de 60 secondes (1 minute).
-A INPUT -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j LOG_DROP

# Prévenir les attaques de Deni de Service (DoS).
# Limiter le nombre de connexions entrantes par minute sur le port 80 et 443 à 75 et définir une rafale limite de 120.
# La limite / minute sera appliquée lorsque le nombre total de connexions aura atteint le niveau limite de rafale.
-A INPUT -p tcp --dport 80 -m limit --limit 75/minute --limit-burst 120 -j ACCEPT
-A INPUT -p tcp --dport 443 -m limit --limit 75/minute --limit-burst 120 -j ACCEPT

########
# Bloquer ICMP pour interdire les réponses du serveur suite à une requête PING.
########
# Déjà bloqué par défaut du fait de la politique de DROP au début.
# -A INPUT -p icmp --icmp-type echo-request -j DROP
# -A OUTPUT -p icmp --icmp-type echo-reply -j DROP
# Autoriser le serveur a lancer une requête PING de l'intérieurvers un serveur externe :
-A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
-A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

# Autoriser ICMP pour OVH et le monitoring :
# Autoriser le monitoring du serveur par OVH pour avertir OVH en cas de panne.
# Adresses à autoriser d'après la documentation OVH :
# Mise en application :
# Autoriser les adresses suivantes de OVH a PING :
# ping.ovh.net, proxy.p19.ovh.net, proxy.rbx.ovh.net, proxy.ovh.net, proxy-rbx2.ovh.net, proxy.sbg.ovh.net, proxy.bhs.ovh.net
#
# Il est conseillé de laisser cache.ovh.net pour permettre à OVH d'intervenir sur le serveur.
# Si vous fermez le port 22 pour les techniciens ils ne pourront pas intervenir.
-A INPUT -p tcp --dport 22 --source cache.ovh.net -j ACCEPT
-A INPUT -p icmp --source proxy.ovh.net -j ACCEPT
-A INPUT -p icmp --source proxy.p19.ovh.net -j ACCEPT
-A INPUT -p icmp --source proxy.rbx.ovh.net -j ACCEPT
-A INPUT -p icmp --source proxy.sbg.ovh.net -j ACCEPT
-A INPUT -p icmp --source proxy.bhs.ovh.net -j ACCEPT
-A INPUT -p icmp --source ping.ovh.net -j ACCEPT
# Start Monitoring
-A INPUT -p icmp --source 151.80.231.244 -j ACCEPT
-A INPUT -p icmp --source 151.80.231.245 -j ACCEPT
-A INPUT -p icmp --source 151.80.231.246 -j ACCEPT
-A INPUT -p icmp --source 151.80.231.247 -j ACCEPT
-A INPUT -p icmp --source 37.187.231.251 -j ACCEPT
# End Monitoring
-A INPUT -p icmp --source a2.ovh.net -j ACCEPT
-A INPUT -p icmp --source 92.222.184.0/24 -j ACCEPT
-A INPUT -p icmp --source 92.222.185.0/24 -j ACCEPT
-A INPUT -p icmp --source 92.222.186.0/24 -j ACCEPT
-A INPUT -p icmp --source 167.114.37.0/24 -j ACCEPT
-A INPUT -p tcp --source 192.168.0.0/16 -j ACCEPT
-A INPUT -p udp --source 192.168.0.0/16 -j ACCEPT
#
# L'adresse IP de votre serveur, 139.99.173.195 pour visionduweb, doit laisser passer :
# 139.99.173.249 si vous êtes sur un serveur HG.
# 139.99.173.250 pour le serveur SLA.
# 139.99.173.251 pour le serveur MRTG pour pouvoir bénéficier de RTM.
#
# Uniquement pour un serveur HG :
# -A INPUT -p icmp --source 139.99.173.249 -j ACCEPT
# -A OUTPUT -p udp --dport 6100:6200 -j ACCEPT # OVH RTM
#
# Serveur SLA et MRTG : ( En fait je ne sais pas si mon VPS utilise SLA et MRTG )
-A INPUT -p icmp --source 139.99.173.250 -j ACCEPT
-A INPUT -p icmp --source 139.99.173.251 -j ACCEPT
#
# A suivre !
# Vérifier les paquets ICMP bloqués depuis le fichier de journalisation /var/log/messages :
# grep -i 'ICMP_IN Blocked' /var/log/messages| tail -5| awk '{print $1,$2,$3,$5,$6,$7,$8,$9,$12,$13,$19,$20}'; date
# Vérifier les informations des adresses IP bloquées pour s'assurer que ce n'est pas un service de OVH :
# Utiliser par exemple la lacommande suivante :
# curl ipinfo.io/92.222.185.1

# La politique par défaut étant à DROP, les règles suivantes sont t'elles réellement nécessaires ?
# DROP des paquets XMAS :
-A INPUT -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j LOG_DROP
-A INPUT -p tcp --tcp-flags ALL ALL -j LOG_DROP
# DROP des paquets NULL :
-A INPUT -p tcp --tcp-flags ALL NONE -j LOG_DROP
-A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j LOG_DROP
# DROP silencieusement les paquets broadcastés.
-A INPUT -m pkttype --pkt-type broadcast -j LOG_DROP

####
# Transfèrer le trafic non traité précédemment vers la chaîne KNOCKING pour réaliser la logique de frappe de ports.
####
# Les règles suivantes vont gérer l'autorisation ou le refus deconnexion au port de SSH.
-A INPUT -j KNOCKING

# Configurer la première porte GATE1
-A GATE1 -p tcp --dport 1111 -m recent --name AUTH1 --set -j LOG_DROP
-A GATE1 -j LOG_DROP

# Configurer la deuxième porte GATE2
-A GATE2 -m recent --name AUTH1 --remove
-A GATE2 -p tcp --dport 2222 -m recent --name AUTH2 --set -j LOG_DROP
-A GATE2 -j GATE1

# Configurer la troisième porte GATE3
-A GATE3 -m recent --name AUTH2 --remove
-A GATE3 -p tcp --dport 3333 -m recent --name AUTH3 --set -j LOG_DROP
-A GATE3 -j GATE1

# Configurer la chaîne PASSED
-A PASSED -m recent --name AUTH3 --remove
-A PASSED -p tcp --dport 22 -j ACCEPT
-A PASSED -j GATE1

# Configurer la chaîne KNOCKING
-A KNOCKING -m recent --rcheck --seconds 30 --name AUTH3 -j PASSED
-A KNOCKING -m recent --rcheck --seconds 10 --name AUTH2 -j GATE3
-A KNOCKING -m recent --rcheck --seconds 10 --name AUTH1 -j GATE2
-A KNOCKING -j GATE1
####
# Fin de la règle pour le Port Knocking.
####

####
# Fin de la règle *filter
####
COMMIT

# Importer le script dans Iptables.
# sudo iptables-restore < iptables-firewall-filter.rules

# Vérifier que les règles aient bien été ajoutées dans la table *filter :
# sudo iptables -t filter -L

Source :
Pascal Hambourg (25/09/2019, 12h10)
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.
Pascal Hambourg (25/09/2019, 16h00)
Le 25/09/2019 à 14:14, G2PC a écrit :
> 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.

> 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 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.

> Pas si sur de bien comprendre, car, j'ai pu lire sur certains tutoriels
> qu'il faut au contraire ouvrir la plage de port via Iptables.
> Si je commente la règle -A INPUT -p tcp --sport 49152:65534 --dport
> 49152:65534 -m state --state ESTABLISHED,RELATED,NEW -j LOG_ACCEPT


Il n'est pas question de supprimer la règle mais de la rendre plus
permissive en supprimant la condition sur le port source.

> Dès lors, il me faut remonter les restrictions du serveur, avant
> l'ouverture des services ?


A toi de décider comment tu veux organiser tes règles en sachant
qu'ACCEPT et DROP sont des cibles terminales qui interrompent la lecture
des règles suivantes de la chaîne.

> Quand tu dis qu'il est situé à un emplacement stratégique du réseau, tu
> parles de sa capacité à forger des paquets TCP ?


Non. N'importe qui peut faire ça. Je parle d'un emplacement qui lui
permet de recevoir les paquets de réponse, donc sur le chemin de retour
des paquets vers le propriétaire légitime de l'adresse forgée.

> Poser des ports piégés est limité, c'est ce que tu confirmes ?


Non, ce n'est pas ce que j'ai voulu dire. Je n'ai répondu que sur le
point des adresses forgées.

> Si il (
> l'attaquant ) ne reçoit pas de réponse, et, qu'il se fait bloquer 24h,
> c'est plutôt efficace alors, non ?


Le but d'un scan de ports est normalement de recevoir des réponses
donnant des informations sur les ports ouverts et fermés. Si on fait un
scan de port avec une adresse forgée sans pouvoir recevoir les réponses
même sans filtrage, ça ne sert à rien.
Discussions similaires