Le pare-feu sur un système Linux est contrôlé par le programme iptables (pour ipv4) et ip6tables (pour ipv6). Cette aide-mémoire couvre les façons les plus courantes d'utiliser iptables pour ceux qui souhaitent protéger leur système contre les pirates ou simplement comprendre la configuration.
Le signe # signifie que la commande est exécutée en tant que root. Ouvrez à l'avance une console avec les droits root - sudo -i sur les systèmes basés sur Debian ou su sur les autres.
1. Afficher l'état.
# iptables -L -n -v
Exemple de résultat de commande pour un pare-feu inactif :
Chaîne INPUT (politique ACCEPT 0 paquets, 0 octets) pkts octets cible prot opt in out source destination Chain FORWARD (politique ACCEPT 0 paquets, 0 octets) pkts octets cible prot opt in out source destination Chain OUTPUT (politique ACCEPT 0 paquets, 0 octets ) pkts octets cible prot opt in out source destination
Pour un pare-feu actif :
Chaîne INPUT (politique DROP 0 paquets, 0 octets) pkts octets cible prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 394 43586 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 état RELATED,ÉTABLI 93 17292 ACCEPTER tout -- br0 * 0.0.0.0/0 0.0.0.0/0 1 142 ACCEPTER tout -- lo * 0.0.0.0/0 0.0.0.0/0 Chaîne FORWARD (politique DROP 0 paquets, 0 octets) pkts octets cible prot opt in out source destination 0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0. 0.0/0 0.0 .0.0/0 état INVALIDE 0 0 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 drapeaux tcp : 0x06/0x02 TCPMSS clamp to PMTU 0 0 ACCEPT all -- * * 0.0.0.0/ 0 0.0.0.0 /0 state RELATED,ETABLISHED 0 0 wanin all -- vlan2 * 0.0.0.0/0 0.0.0.0/0 0 0 wanout all -- * vlan2 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (politique ACCEPTER 425 paquets, 113 Ko) pkts octets cible prot opt in out source destination Chaîne wanin (1 références) pkts octets cible prot opt in sortie source destination Chaîne wanout (1 références) pkts octets cible prot opt in hors source destination
Où:
-L : Afficher la liste des règles.
-v : Afficher des informations supplémentaires. Cette option affiche le nom de l'interface, les options et les masques TOS. Affiche également les suffixes « K », « M » ou « G ».
-n : affiche l'adresse IP et le port sous forme de chiffres (sans utiliser de serveurs DNS pour résoudre les noms. Cela accélérera l'affichage).
2. Affichez une liste de règles avec des numéros de ligne.
# iptables -n -L -v --numéros de ligne
Exemple de sortie :
Chaîne INPUT (politique DROP) num cible prot opt source destination 1 DROP all -- 0.0.0.0/0 0.0.0.0/0 état INVALIDE 2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 état RELATED,ESTABLISED 3 ACCEPTER tout -- 0.0.0.0/0 0.0.0.0/0 4 ACCEPTER tout -- 0.0.0.0/0 0.0.0.0/0 Chaîne FORWARD (politique DROP) num cible prot opt source destination 1 ACCEPTER tout -- 0.0 .0.0/0 0.0.0.0/0 2 DROP all -- 0.0.0.0/0 0.0.0.0/0 état INVALIDE 3 TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 indicateurs TCP : 0x06/0x02 TCPMSS fixé à PMTU 4 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 état RELATED,ETABLISHED 5 wanin all -- 0.0.0.0/0 0.0.0.0/0 6 wanout all -- 0.0.0.0/0 0.0.0.0/0 7 ACCEPT all - - 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (politique ACCEPT) num cible prot opt source destination Chain wanin (1 références) num target prot opt source destination Chain wanout (1 références) num cible prot opt source destination
Vous pouvez utiliser des numéros de ligne pour ajouter de nouvelles règles.
3. Affichez la chaîne de règles INPUT ou OUTPUT.
# iptables -L INPUT -n -v
# iptables -L OUTPUT -n -v --numéros de ligne
4. Arrêtez, démarrez, redémarrez le pare-feu.
Par les forces du système lui-même :
# service ufw arrêt
# démarrage du service ufw
Vous pouvez également utiliser les commandes iptables pour arrêter le pare-feu et supprimer toutes les règles :
#iptables -F
#iptables -X
# iptables -t nat -F
# iptables -t nat -X
# iptables -t mangle -F
# iptables -t mangle -X
# iptables -P ENTREE ACCEPTER
# iptables -P SORTIE ACCEPTER
# iptables -P ACCEPTER AVANT
Où:
-F : Vider toutes les règles.
-X : supprime la chaîne.
-t table_name : sélectionnez une table (nat ou mangle) et supprimez toutes les règles.
-P : Sélectionnez les actions par défaut (telles que DROP, REJECT ou ACCEPT).
5. Supprimez les règles de pare-feu.
Pour afficher le numéro de ligne avec les règles existantes :
# iptables -L OUTPUT -n --numéros de ligne
# iptables -L SORTIE -n --line-numbers | moins
# iptables -L SORTIE -n --line-numbers | grep 202.54.1.1
Obtenons une liste d'adresses IP. Regardez simplement le numéro à gauche et supprimez la ligne correspondante. Par exemple, pour le numéro 3 :
# iptables -D ENTRÉE 3
Ou recherchez l'adresse IP source (202.54.1.1) et supprimez-la de la règle :
# iptables -D INPUT -s 202.54.1.1 -j DROP
Où:
-D : Supprime une ou plusieurs règles de la chaîne.
6. Ajoutez une règle au pare-feu.
Pour ajouter une ou plusieurs règles à une chaîne, on affiche d'abord la liste à l'aide des numéros de ligne :
# iptables -L INPUT -n --numéros de ligne
Exemple de sortie :
Chaîne INPUT (politique DROP) num cible prot opt source destination 1 DROP all -- 202.54.1.1 0.0.0.0/0 2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 état NOUVEAU, ÉTABLI
Pour insérer une règle entre les lignes 1 et 2 :
# iptables -I INPUT 2 -s 202.54.1.2 -j DROP
Vérifions si la règle a été mise à jour :
# iptables -L INPUT -n --numéros de ligne
Le résultat sera comme ceci :
Chaîne INPUT (politique DROP) num cible prot opt source destination 1 DROP all -- 202.54.1.1 0.0.0.0/0 2 DROP all -- 202.54.1.2 0.0.0.0/0 3 ACCEPT all -- 0.0.0.0/0 0,0.0,0/0 état NOUVEAU, ÉTABLI
7. Enregistrez les règles de pare-feu.
Via la sauvegarde iptables :
# iptables-save > /etc/iptables.rules
8. Rétablir les règles.
Via la restauration iptables
# restauration-iptables
9. Définissez les politiques par défaut.
Pour réinitialiser tout le trafic :
# iptables -P INPUT DROP
# iptables -P CHUTE DE SORTIE
# iptables -P FORWARD DROP
# iptables -L -v -n
Après les commandes ci-dessus, aucun paquet ne quittera cet hôte.
#ping google.com
10. Bloquez uniquement les connexions entrantes.
Pour supprimer tous les paquets entrants que vous n'avez pas initiés, mais autoriser le trafic sortant :
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P SORTIE ACCEPTER
# iptables -A INPUT -m state --state NOUVEAU, ÉTABLI -j ACCEPT
# iptables -L -v -n
Les paquets sortants et ceux mémorisés au cours des sessions établies sont autorisés.
#ping google.com
11. Réinitialisez les adresses des réseaux isolés sur un réseau public.
# iptables -A INPUT -i eth1 -s 192.168.0.0/24 -j DROP
Liste des adresses IP pour les réseaux isolés :
10.0.0.0/8 -j (UNE)
172.16.0.0/12 (B)
192.168.0.0/16 (C)
224.0.0.0/4 (MULTICAST D)
240.0.0.0/5 (E)
127.0.0.0/8 (bouclage)
12. Bloquer une adresse IP spécifique.
Pour bloquer l'adresse d'un attaquant 1.2.3.4 :
# iptables -A INPUT -s 1.2.3.4 -j DROP
# iptables -A INPUT -s 192.168.0.0/24 -j DROP
13. Bloquez les demandes de port entrantes.
Pour bloquer toutes les requêtes entrantes sur le port 80 :
# iptables -A INPUT -p tcp --dport 80 -j DROP
# iptables -A INPUT -i eth1 -p tcp --dport 80 -j DROP
Pour bloquer la requête du port 80 provenant de l'adresse 1.2.3.4 :
# iptables -A INPUT -p tcp -s 1.2.3.4 --dport 80 -j DROP
# iptables -A INPUT -i eth1 -p tcp -s 192.168.1.0/24 --dport 80 -j DROP
14. Bloquez les requêtes vers l'adresse IP sortante.
Pour bloquer un domaine spécifique, recherchez son adresse :
# hôte -t un facebook.com
Conclusion : facebook.com a l'adresse 69.171.228.40
Trouvons le CIDR pour 69.171.228.40 :
#whois69.171.228.40 | grepCIDR
Conclusion:
CIDR : 69.171.224.0/19
Bloqueons l'accès au 69.171.224.0/19 :
# iptables -A SORTIE -p tcp -d 69.171.224.0/19 -j DROP
Vous pouvez également utiliser un domaine pour bloquer :
# iptables -A SORTIE -p tcp -d www.facebook.com -j DROP
# iptables -A SORTIE -p tcp -d facebook.com -j DROP
15. Enregistrez l'événement et réinitialisez.
Pour enregistrer le mouvement des paquets avant la réinitialisation, ajoutez une règle :
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j LOG --log-prefix "IP_SPOOF A : "
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP
Vérifions le journal (par défaut /var/log/messages) :
# tail -f /var/log/messages
# grep -i --color "IP SPOOF" /var/log/messages
16. Enregistrez l'événement et réinitialisez-le (avec une limite sur le nombre d'enregistrements).
Pour éviter de remplir la partition avec un journal volumineux, nous limiterons le nombre d'entrées en utilisant -m. Par exemple, pour enregistrer un maximum de 7 lignes toutes les 5 minutes :
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -m limit --limit 5/m --limit-burst 7 -j LOG --log-prefix "IP_SPOOF A : "
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP
16. Réinitialisez ou autorisez le trafic provenant de certaines adresses MAC.
# iptables -A INPUT -m mac --mac-source 00:0F:EA:91:04:08 -j DROP
## *autoriser uniquement le port TCP # 8080 à partir de l'adresse mac 00:0F:EA:91:04:07 * ##
# iptables -A INPUT -p tcp --destination-port 22 -m mac --mac-source 00:0F:EA:91:04:07 -j ACCEPTER
17. Autorisez ou refusez les requêtes ICMP Ping.
Pour désactiver le ping :
# iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
# iptables -A INPUT -i eth1 -p icmp --icmp-type echo-request -j DROP
Autoriser des réseaux/hôtes spécifiques :
# iptables -A INPUT -s 192.168.1.0/24 -p icmp --icmp-type echo-request -j ACCEPT
Autoriser seulement une partie des requêtes ICMP :
### ** suppose que les politiques entrantes par défaut sont définies sur DROP ** ###
# iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
# iptables -A INPUT -p icmp --icmp-type destination inaccessible -j ACCEPT
# iptables -A INPUT -p icmp --icmp-type temps dépassé -j ACCEPT
## ** permettez-nous de répondre à la demande ** ##
# iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
18. Ouvrez une gamme de ports.
# iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 7000:7010 -j ACCEPT
19. Ouvrez une plage d'adresses.
## autorise les connexions au port 80 (Apache) si l'adresse est comprise entre 192.168.1.100 et 192.168.1.200 ##
# iptables -A INPUT -p tcp --destination-port 80 -m iprange --src-range 192.168.1.100-192.168.1.200 -j ACCEPT
## exemple pour nat ##
# iptables -t nat -A POSTROUTING -j SNAT --to-source 192.168.1.20-192.168.1.25
20. Fermez ou ouvrez les ports standard.
Remplacez ACCEPT par DROP pour bloquer le port.
## Port TCP ssh 22 ##
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT
## cups (service d'impression) port udp/tcp 631 pour le réseau local ##
iptables -A INPUT -s 192.168.1.0/24 -p udp -m udp --dport 631 -j ACCEPTER
iptables -A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 631 -j ACCEPTER
## synchronisation de l'heure via NTP pour le réseau local (port udp 123) ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 123 -j ACCEPT
## port TCP 25 (smtp) ##
iptables -A INPUT -m state --state NEW -p tcp --dport 25 -j ACCEPT
# ports du serveur DNS ##
iptables -A INPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT
## http/https www port du serveur ##
iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
## port TCP 110 (pop3) ##
iptables -A INPUT -m state --state NEW -p tcp --dport 110 -j ACCEPT
## port TCP 143 (imap) ##
iptables -A INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT
## Serveur de fichiers Samba pour réseau local ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 137 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 138 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 445 -j ACCEPT
## serveur proxy pour le réseau local ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 3128 -j ACCEPT
## serveur mysql pour le réseau local ##
iptables -I INPUT -p tcp --dport 3306 -j ACCEPTER
21. Limitez le nombre de connexions parallèles au serveur pour une adresse.
Pour les restrictions, le module connlimit est utilisé. Pour autoriser seulement 3 connexions ssh par client :
# iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 3 -j REJECT
Définissez le nombre de requêtes HTTP sur 20 :
# iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j DROP
Où:
--connlimit-above 3 : Spécifie que la règle s'applique uniquement si le nombre de connexions dépasse 3.
--connlimit-mask 24 : Spécifie le masque de réseau.
Aide avec iptables.
Pour trouver de l'aide avec iptables, utilisez man :
$ homme iptables
Pour afficher l'aide sur des commandes et des objectifs spécifiques :
# iptables -j DROP -h
Vérification de la règle iptables.
Vérification des ports ouverts/fermés :
# netstat -tulpn
Nous vérifions l'ouverture/fermeture d'un port spécifique :
# netstat -tulpn | grep:80
Vérifions qu'iptables autorise la connexion au port 80 :
# iptables -L INPUT -v -n | grep 80
Sinon, ouvrons-le à tout le monde :
# iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
Vérifiez en utilisant Telnet
$ telnet ya.ru 80
Vous pouvez utiliser nmap pour vérifier :
$ nmap -sS -p 80 ya.ru
Iptables est un excellent outil entre les mains d'un administrateur. Si vous avez besoin de vous protéger facilement et simplement dans le bureau Ubuntu, sachez qu'il existe un module complémentaire de console pratique pour iptables appelé UFW, et pour cela, il existe un programme graphique GUFW. Le matériel vidéo vous aidera à rendre votre Ubuntu encore plus sécurisé.
Vous pouvez apprendre à configurer MikroTik dans un cours en ligne sur les équipements de ce fabricant. L'auteur du cours est un formateur certifié MikroTik. Vous pouvez en savoir plus à la fin de l'article.
L'article répond à la question de savoir à quel point il est dangereux de bloquer le trafic ICMP.
ICMP est une pomme de discorde
De nombreux administrateurs réseau estiment que le protocole ICMP (Internet Control Message Protocol) constitue un risque pour la sécurité et doit donc toujours être bloqué. Il est vrai que le protocole présente des problèmes de sécurité associés et que certaines requêtes doivent être bloquées. Mais ce n'est pas une raison. pour bloquer tout le trafic ICMP !
Le trafic ICMP a de nombreuses fonctions importantes ; Certains d’entre eux sont utiles pour le dépannage, tandis que d’autres sont nécessaires au bon fonctionnement du réseau. Vous trouverez ci-dessous quelques parties importantes du protocole ICMP que vous devez connaître. Vous devez réfléchir à la meilleure façon de les acheminer via votre réseau.
Demande d'écho et réponse d'écho
IPv4 – Demande d'écho (Type8, Code0) et réponse d'écho (Type0, Code0)
IPv6 – Demande d'écho (Type128, Code0) et réponse d'écho (Type129, Code0)
Nous savons tous bien que le ping est l’un des premiers outils de dépannage. Oui, si vous activez le traitement des paquets ICMP sur votre matériel, cela signifie que votre hôte est désormais détectable, mais le vôtre n'écoute-t-il pas déjà sur le port 80 et n'envoie-t-il pas des réponses aux demandes des clients ? Bien entendu, bloquez également ces demandes si vous souhaitez vraiment que votre DMZ soit à la périphérie du réseau. Mais en bloquant le trafic ICMP au sein de votre réseau, vous ne renforcerez pas votre sécurité ; au contraire, vous vous retrouverez avec un système avec un processus de dépannage inutilement complexe (« Veuillez vérifier si la passerelle répond aux requêtes du réseau ? », « Non, mais cela ne me dérange pas du tout, parce que je m'en fiche. » je ne dirai rien ! »).
N'oubliez pas que vous pouvez également autoriser les demandes à aller dans une certaine direction ; par exemple, configurez l'équipement pour que les requêtes Echo de votre réseau soient transmises à Internet et les réponses Echo d'Internet à votre réseau, mais pas l'inverse.
Fragmentation des paquets requise (IPv4) / Paquet trop volumineux (IPv6)
IPv4 – (Type3, Code4)
IPv6 – (Type2, Code0)
Ces composants du protocole ICMP sont très importants car ils constituent un composant important de Path MTU Discovery (PMTUD), qui fait partie intégrante du protocole TCP. Permet à deux hôtes d'ajuster la valeur TCP Maximum Segment Size (MSS) à une valeur qui correspond à la plus petite MTU le long du chemin de communication entre les deux destinations. Si sur le chemin des paquets se trouve un nœud avec une unité de transmission maximale plus petite que celle de l'expéditeur ou du destinataire, et qu'il n'a pas les moyens de détecter cette collision, alors le trafic sera discrètement rejeté. Et vous ne comprendrez pas ce qui se passe avec le canal de communication ; en d’autres termes, « de joyeux jours viendront pour vous ».
Ne fragmentez pas – ICMP ne passera pas !
La transmission de paquets IPv4 avec le bit Don't Fragment défini (la plupart d'entre eux !) ou de paquets IPv6 (rappelez-vous qu'il n'y a pas de fragmentation par les routeurs dans IPv6) qui sont trop volumineux pour être transmis via l'interface entraînera l'élimination du paquet par le routeur. et générez une réponse à la source de transmission avec les erreurs ICMP suivantes : Fragmentation requise ( Fragmentation requise), ou Colis trop volumineux ( Paquet aussi Grand). Si les réponses avec ces erreurs ne peuvent pas être renvoyées à l'expéditeur, alors il interprétera l'absence de réponses de confirmation concernant la livraison des paquets ACK ( Reconnaissance) du récepteur en tant que congestion/perte et source de retransmission des paquets qui seront également rejetés.
Il est difficile d'identifier la cause d'un tel problème et de le résoudre rapidement ; le processus de prise de contact TCP fonctionne correctement car il implique de petits paquets, mais dès qu'un transfert de données en masse se produit, la session de transfert se bloque car la source du transfert n'est pas connue. recevoir des messages d'erreur.
Explorer le chemin de livraison des paquets
La RFC 4821 a été conçue pour aider les participants au trafic réseau à contourner ce problème en utilisant la vérification du chemin des paquets. (Découverte du chemin MTU (PLPMTUD). La norme permet de détecter le maximum de données (Unité de transmission maximale (MTU), qui peut être transmis par le protocole en une seule itération, en augmentant progressivement la taille maximale du bloc de données utile (Taille maximale des segments (MSS), afin de trouver la taille maximale possible d'un paquet sans le fragmenter le long du chemin allant de l'émetteur au récepteur. Cette fonctionnalité réduit la dépendance à la réception rapide des réponses d'erreur via le protocole ICMP (Internet Control Message Protocol) et est disponible dans la plupart des piles de périphériques réseau et des systèmes d'exploitation clients. Malheureusement, elle n'est pas aussi efficace que l'obtention directe de données sur la taille maximale possible. des paquets transmis. Veuillez autoriser ces messages ICMP à revenir à la source de transmission, d'accord ?
Temps de transmission des paquets dépassé
IPv4 – (Type11, Code0)
IPv6 – (Type3, Code0)
Traceroute est un outil très utile pour dépanner les connexions réseau entre deux hôtes, détaillant chaque étape du parcours.
Envoie un paquet avec la durée de vie du paquet de données pour le protocole IP (Le temps de vivre (TTL)égal 1 pour que le premier routeur envoie un message d'erreur (y compris sa propre adresse IP) indiquant que le paquet a dépassé sa durée de vie. Ensuite, il envoie un paquet avec TTL 2 et ainsi de suite. Cette procédure est nécessaire pour détecter chaque nœud le long du chemin du paquet.
NPD et SLAAC (IPv6)
Sollicitation de routeur (RS) (Type133, Code0)
Annonce de routeur (RA) (Type134, Code0)
Sollicitation de voisin (NS) (Type135, Code0)
Annonce de voisin (NA) (Type136, Code0)
Redirection (Type137, Code0)
Alors qu'IPv4 utilisait le protocole de résolution d'adresse (ARP) pour mapper les couches 2 et 3 du modèle de réseau OSI, IPv6 utilise une approche différente sous la forme du protocole de découverte de voisin (NDP). NDP fournit de nombreuses fonctionnalités, notamment la découverte de routeurs, la découverte de préfixes, la résolution d'adresses, etc. En plus du NDP, StateLess Address AutoConfiguration (SLAAC) vous permet de configurer dynamiquement un hôte sur un réseau, similaire au concept du Dynamic Host Configuration Protocol (DHCP) (bien que DHCPv6 soit destiné à un contrôle plus granulaire).
Ces cinq types de messages ICMP ne doivent pas être bloqués au sein de votre réseau (en ignorant le périmètre extérieur) pour que le protocole de transfert de données IP fonctionne correctement.
Numérotation des types ICMP
Le protocole ICMP (Internet Control Message Protocol) contient de nombreux messages identifiés par le champ « type ».
| Taper | Nom | spécification |
|---|---|---|
| 0 | Réponse d'écho | |
| 1 | Non attribué | |
| 2 | Non attribué | |
| 3 | Destination indisponible | |
| 4 | Extinction de la source (obsolète) | |
| 5 | Réorienter | |
| 6 | Adresse hôte alternative (obsolète) | |
| 7 | Non attribué | |
| 8 | Écho | |
| 9 | Publicité du routeur | |
| 10 | Sollicitation de routeur | |
| 11 | Temps écoulé | |
| 12 | Problème de paramètre | |
| 13 | Horodatage | |
| 14 | Réponse d'horodatage | |
| 15 | Demande d'informations (obsolète) | |
| 16 | Réponse d'information (obsolète) | |
| 17 | Demande de masque d'adresse (obsolète) | |
| 18 | Réponse du masque d'adresse (obsolète) | |
| 19 | Réservé (pour la sécurité) | Solo |
| 20-29 | Réservé (pour l'expérience de robustesse) | ZSu |
| 30 | Traceroute (obsolète) | |
| 31 | Erreur de conversion de datagramme (obsolète) | |
| 32 | Redirection d'hôte mobile (obsolète) | David_Johnson |
| 33 | IPv6 Où es-tu (obsolète) | |
| 34 | IPv6 Je-suis-ici (obsolète) | |
| 35 | Demande d'inscription mobile (obsolète) | |
| 36 | Réponse d'inscription mobile (obsolète) | |
| 37 | Demande de nom de domaine (obsolète) | |
| 38 | Réponse du nom de domaine (obsolète) | |
| 39 | SAUTER (Obsolète) | |
| 40 | Photoris | |
| 41 | Messages ICMP utilisés par des protocoles de mobilité expérimentaux tels que Seamoby | |
| 42 | Demande d'écho étendue | |
| 43 | Réponse d'écho étendue | |
| 44-252 | Non attribué | |
| 253 | Expérience 1 de style RFC3692 | |
| 254 | Expérience 2 de style RFC3692 | |
| 255 | Réservé |
Quelques mots sur les limitations de vitesse
Bien que les messages ICMP comme ceux décrits dans cet article puissent être très utiles, n'oubliez pas que la génération de tous ces messages prend du temps CPU sur vos routeurs et génère du trafic. Pensez-vous vraiment que vous recevrez 1 000 pings par seconde à travers votre pare-feu dans une situation normale ? Est-ce que cela sera considéré comme un trafic normal ? Probablement pas. Limitez la bande passante réseau pour ces types de trafic ICMP comme bon vous semble ; cette étape peut vous aider à sécuriser votre réseau.
Lire, rechercher et comprendre
Considérant que discuter du sujet « bloquer ou ne pas bloquer » les paquets ICMP conduit toujours à de la confusion, des différends et des désaccords, je suggère de continuer à étudier ce sujet par vous-même. J'ai fourni de nombreux liens sur cette page ; je pense que pour une compréhension plus complète des enjeux, vous devriez passer du temps à les lire. Et faites des choix éclairés sur ce qui fonctionne le mieux pour votre réseau.
MikroTik : où cliquer pour que ça marche ?
Malgré tous ses avantages, les produits MikroTik présentent un inconvénient : il existe de nombreuses informations dispersées et pas toujours fiables sur sa configuration. Nous recommandons une source fiable en russe, où tout est collecté, logiquement et structuré - cours vidéo " Mise en place de l'équipement MikroTik" Le cours comprend 162 leçons vidéo, 45 travaux de laboratoire, des questions d'auto-test et des notes. Tous les matériaux restent avec vous indéfiniment. Vous pouvez regarder gratuitement le début du cours en laissant une demande sur la page du cours. L'auteur du cours est un formateur certifié MikroTik.
Un pare-feu constitue la première ligne de défense de tout serveur, et sa configuration appropriée détermine si un attaquant pourra progresser davantage dans ses tentatives de pénétration du système. Les firewares modernes offrent de nombreux mécanismes de sécurité grâce auxquels vous pouvez tenir 99 % des attaquants hors de portée. Et tout cela sans avoir besoin d’acheter des équipements coûteux et des logiciels commerciaux.
L'objectif principal de tous les pirates est d'accéder à l'interpréteur de commandes du serveur afin d'utiliser ses capacités à leur avantage. Le plus souvent, la pénétration dans le « saint des saints » s'effectue à l'aide de failles dans les services ou en devinant le mot de passe (force brute) de l'un d'entre eux (par exemple, ssh).
Analyse des ports
Pour identifier la présence de services vulnérables sur une machine, l'attaquant effectue une reconnaissance à l'aide d'un scanner de ports et de divers systèmes de détection de vulnérabilités. En règle générale, nmap est utilisé comme scanner de ports, capable d'analyser d'une douzaine de manières différentes et, dans certains cas, de détecter les versions et les services du système d'exploitation. Voici une liste de drapeaux nmap particulièrement populaires et couramment utilisés par les attaquants :
Indicateurs Nmap utilisés lors de l'analyse
- -sT - analyse TCP normale en ouvrant une connexion au port spécifié et en y mettant fin ;
- -sS - Scan SYN/ACK, la connexion est interrompue immédiatement après la réponse à la demande d'ouverture de la connexion ;
- -sU - analyse UDP ;
- -sF - analyse des paquets avec l'indicateur FIN défini ;
- -sX - analyse avec des paquets avec les indicateurs FIN, PSH et URG définis ;
- -sN - analyse les paquets sans définir d'indicateurs.
La méthode anti-scan est simple et connue de tout administrateur système. Elle consiste simplement à fermer tous les services qui ne doivent pas être visibles depuis le réseau externe. Par exemple, si la machine exécute les services ssh, samba et apache et que seul un serveur Web avec une page Web d'entreprise doit être visible du monde extérieur, alors le pare-feu peut être configuré comme ceci :
Configuration initiale d'iptables
outif="eth1"
iptables -F
iptables -i $outif -A INPUT \
-m piste de connexion\
--ctstate ÉTABLI, RELATED \
-j ACCEPTER
iptables -i $outif -A INPUT -p tcp \
--dport 80 -j ACCEPTER
iptables -i $outif -P INPUT DROP
iptables -i $outif -P SORTIE ACCEPTER
Configuration initiale d'IPFW
outif="rl0"
ipfw ajoute autoriser l'adresse IP de n'importe quel à n'importe quel \
via lo0
ipfw ajoute autoriser l'adresse IP de moi à n'importe quel \
via $outif
ipfw ajoute autoriser TCP de n'importe qui pour moi \
établi via $outif
ipfw ajoute autoriser TCP à partir de n'importe quel 80 \
à moi via $outif
ipfw ajoute un refus d'adresse IP de n'importe quel à n'importe quel \
via $outif
Configuration initiale du pf
outif="rl0"
mettre le saut sur lo0
bloquer tout
évanouir $outif de $outif \
à n'importe quel état de conservation
transmettre le proto $outif depuis n'importe quel \
vers $outif port 80
Les trois ensembles de règles font la même chose : elles permettent à tout trafic de passer par l'interface de bouclage, permettent d'accepter les paquets provenant de connexions déjà établies (afin que, par exemple, le navigateur puisse recevoir une réponse à une requête adressée à un serveur distant ), autorisez les appels vers le 80ème port, bloquant tous les autres et autorisant toutes les connexions vers l'extérieur. Veuillez noter que si dans les exemples iptables et ipfw nous définissons explicitement des règles pour permettre la réception de paquets provenant de connexions déjà établies, alors dans le cas de pf, il suffisait de spécifier « conserver l'état » dans l'ensemble de règles, autorisant toute connexion sortante.
En général, ce système de protection des services réseau contre l'analyse et les intrusions fonctionne très bien, mais nous pouvons aller plus loin et configurer le pare-feu de manière à ce que certains types d'analyse ne puissent pas être effectués du tout. Techniquement, nous ne pouvons pas faire cela pour les analyses régulières (indicateurs nmap "-sT", "-sS" et "-sU") simplement parce qu'il n'y a rien de criminel à ce sujet, mais les types d'analyse non standard comme "-sN" "-sF " et "-sX" génèrent des packages qui n'auraient pas pu être créés par des applications légitimes.
C’est pourquoi nous rejetons sans l’ombre d’un doute de tels liens.
Méthodes pour lutter contre les types exotiques de numérisation
# Désactiver l'analyse FIN
Linux> iptables -A INPUT –p tcp\
–m tcp\
--tcp-flags FIN,ACK FIN -j DROP
FreeBSD>
tcpflags fin non établi
# Désactiver le X-scan
Linux>
--tcp-flags FIN, SYN, RST, PSH, ACK, URG
FIN, SYN, RST, PSH, ACK, URG\
–j CHUTE
FreeBSD> ipfw ajoute le rejet de TCP de n'importe quel à n'importe quel \
tcpflags fin, syn, rst, psh, ack, urg
# Désactiver le N-scan
Linux> iptables -A INPUT –p tcp –m tcp\
--tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE –j DROP
FreeBSD> ipfw ajoute le rejet de TCP de n'importe quel à n'importe quel \
tcpflags !fin, !syn, !rst, !psh, !ack, !urg
Dans OpenBSD, toutes ces lignes peuvent être remplacées par une simple entrée au début
/etc/pf.conf :
frotter en tout
La directive scrub active un mécanisme de normalisation des paquets dans lequel les paquets fragmentés sont réunis et les paquets avec des combinaisons d'indicateurs invalides sont rejetés. En plus des types d'analyse exotiques, Scrub vous permet également de vous protéger contre les systèmes de détection d'intrusion trompeurs (envoi de paquets très fragmentés) et certains types d'attaques DoS.
Pour nous protéger contre les analyses SYN/ACK lancées à l'aide de l'indicateur nmap "-sS", nous pouvons utiliser la méthode passive d'empreinte digitale du système d'exploitation disponible dans les pare-feu pf et iptables/netfilter (depuis la version 1.4.6). Lors d'une analyse régulière (l'indicateur "-sT"), nmap utilise l'interface socket standard du système d'exploitation, donc une telle analyse n'est presque pas différente d'un flux de paquets réguliers (nous examinerons certaines de ses différences ci-dessous), cependant , lors de l'analyse SYN/ACK, nmap génère lui-même les paquets, ils disposent donc de certaines fonctionnalités qui révèlent leur source. La méthode de détection passive du système d'exploitation vous permet d'identifier ces paquets et de les supprimer à l'aide des règles de pare-feu standard :
OpenBSD> bloquer rapidement depuis n'importe quel système d'exploitation NMAP
Linux> iptables -I INPUT -p tcp -m osf --genre NMAP \
-j DROP
Le module osf du pare-feu iptables/netfilter utilise une base de données d'empreintes digitales compilée et mise à jour par les développeurs OpenBSD (/etc/pf.os), donc ces deux règles devraient produire les mêmes résultats. Il est également intéressant de noter qu'ils peuvent contrecarrer efficacement la fonction de détection du système d'exploitation de l'utilitaire nmap (l'indicateur "-O").
Nous sommes désormais protégés contre presque tous les types d'analyse, à l'exception du "-sT" standard et stupide. Que faire de lui ? C'est en fait simple. Le fait de l'analyse des ports est facile à remarquer en analysant simplement les journaux du pare-feu. Si, dans un court laps de temps, il y a eu de nombreuses connexions vers différents ports, cela signifie que nous avons été analysés. Il ne reste plus qu'à transférer cette idée dans les règles du pare-feu. Il existe une excellente recette pour iptables qui bloque tous ceux qui insistent trop pour frapper sur les ports qui ne fonctionnent pas :
Combattre le scan avec iptables
# Vérifiez les frappes sur les ports qui ne fonctionnent pas (10 par heure)
--secondes 3600 --hitcount 10 --rttl -j RETOUR
# Deuxième contrôle pour frapper sur les ports qui ne fonctionnent pas (2 par minute)
iptables -A INPUT -m récent --rcheck \
--secondes 60 --hitcount 2 --rttl -j RETOUR
# On met les adresses de ceux qui frappent sur la liste
iptables -A INPUT -m récent --set
# Supprimez les paquets de tous ceux qui dépassent la limite de
nombre de connexions
iptables -P INPUT -j DROP
En installant le package xtables-addons, qui contient les développements du projet patch-omatic, nous aurons accès au module PSD (Port Scan Detect), implémenté à l'image et à la ressemblance du démon scanlogd. Toutes les lignes précédentes peuvent être facilement remplacées par une règle simple :
# iptables -A INPUT -m psd -j DROP
Malheureusement, il n'y a rien de tel dans les filtres de paquets ipfw et pf, mais ce n'est pas un problème, car le démon PortSentry et scanlogd sont bien contrecarrés par l'analyse des ports.
Interdire les messages Icmp
Il est également recommandé d'interdire les messages ICMP susceptibles de révéler des informations supplémentaires sur l'hôte ou d'être utilisés pour effectuer diverses actions malveillantes (par exemple, modifier la table de routage). Vous trouverez ci-dessous un tableau répertoriant les types de messages ICMP possibles :
Types de messages ICMP
- 0 - réponse d'écho (réponse d'écho, ping)
- 3 - destination inaccessible (le destinataire est inaccessible)
- 4 - source quench (suppression de la source, veuillez envoyer les paquets plus lentement)
- 5 - rediriger
- 8 - demande d'écho (demande d'écho, ping)
- 9 - publicité du routeur
- 10 - sollicitation du routeur
- 11 - durée de vie dépassée (expiration de la durée de vie du paquet)
- 12 - En-tête IP défectueux (en-tête de paquet IP incorrect)
- 13 - demande d'horodatage (demande de valeur du compteur de temps)
- 14 - réponse d'horodatage (réponse à une demande de valeur du compteur horaire)
- 15 - demande d'informations
- 16 - réponse d'information (réponse à une demande d'information)
- 17 - demande de masque d'adresse (demande de masque réseau)
- 18 - réponse au masque d'adresse (réponse à la demande de masque réseau)
Comme vous pouvez le constater, la réponse à certains messages ICMP peut entraîner la divulgation de certaines informations sur l'hôte, tandis que d'autres peuvent entraîner une modification de la table de routage, ils doivent donc être désactivés.
Généralement, les messages ICMP 0, 3, 4, 11 et 12 sont autorisés à sortir vers le monde extérieur, tandis que seuls les messages 3, 8 et 12 sont acceptés en entrée. Voici comment cela est implémenté dans divers pare-feu :
Interdiction des messages ICMP dangereux
Linux> iptables -A INPUT -p icmp\
-icmp-type 3,8,12 -j ACCEPTER
Linux> iptables -A SORTIE -p icmp\
-icmp-type 0,3,4,11,12 -j ACCEPTER
FreeBSD> ipfw ajoute autoriser icmp \
de any à $outif dans \
via $outif icmptype 3,8,12
FreeBSD> ipfw ajoute autoriser icmp \
de $outif à n'importe quelle sortie \
via $outif icmptype 0,3,4,11,12
OpenBSD> passer le proto inet icmp \
de n'importe lequel à $outif \
type icmp (3, 8, 12) conserver l'état
OpenBSD> distribuer le proto inet icmp \
de $outif à n'importe quel \
type icmp (0, 3, 4, 11, 12)\
garder l'état
Si vous le souhaitez, vous pouvez bloquer tout le trafic ICMP, y compris les requêtes ping, mais cela peut affecter le bon fonctionnement du réseau.
Force brute
Après avoir recherché des informations sur les ports ouverts et le système d'exploitation, l'attaquant tente de pénétrer dans le système, ce qui peut consister à exploiter des failles dans les services ou à deviner des mots de passe. Un pare-feu ne nous aidera pas à empêcher le piratage des services, mais il est facile de ralentir le processus de forçage brutal des mots de passe. Pour ce faire, des fonctionnalités sont utilisées pour limiter le nombre de paquets arrivant sur une machine à partir d'une adresse IP. Voici comment procéder avec iptables :
Protection contre la force brute à l'aide d'iptables
# Chaîne de vérification des connexions
iptables -N brute_check
# Bloquer l'adresse si plus de 60 ans
secondes, il a initié plus de 2 connexions
--update --secondes 60\
--hitcount 3 -j DROP
# Sinon, autorisez la connexion et
ajouter l'adresse à la liste
iptables -A brute_check -m récent\
--set -j ACCEPTER
# Effacer la chaîne INPUT
iptables -F ENTRÉE
# Envoie brute_check à la chaîne
tous ceux qui essaient de se connecter à
22ème port
--ctstate NOUVEAU -p tcp \
--dport 22 -j brute_check
iptables -P BAISSE D'ENTRÉE
La même chose peut être faite en utilisant pf :
Protection contre la force brute utilisant pf
# Créer une table pour les forceurs brutaux
tableau
# Bloquez tous ceux qui y entrent
bloquer rapidement depuis
# Placer dans le tableau des bruteforcers tous ceux qui initient plus de deux connexions sur le port 22 par minute
transmettre $ext_if inet proto tcp à $outif \
le port 22 drapeaux S/SA conserve l'état \
(taux de connexion max-src-60/2, \overload
Le pare-feu ipfw n'a pas suffisamment de fonctionnalités pour contrer efficacement les forceurs brutaux, ses utilisateurs doivent donc utiliser des outils de niveau supérieur tels que des modules PAM spéciaux, des systèmes de détection d'intrusion et des programmes comme sshguard.
Usurpation
Le spoofing (usurpation de l'adresse source d'un paquet) peut être utilisé pour mener des attaques DoS ou contourner un pare-feu. Dans le premier cas, l'usurpation d'identité donne un énorme avantage à l'attaquant, car elle complique considérablement la réponse à l'attaque (les paquets arrivant avec des adresses d'expéditeur complètement différentes ne sont pas si faciles à classer et à bloquer) et retarde le processus de fermeture des nouvelles connexions (généralement la fausse adresse est inaccessible, la connexion n'est donc fermée qu'après l'expiration du délai d'attente). L'usurpation d'identité, réalisée pour contourner les systèmes de sécurité, est moins dangereuse et peut dans la plupart des cas être contrôlée.
Très souvent, lors du blocage des services réseau externes d'un hôte, les administrateurs système les laissent ouverts pour une certaine plage d'adresses (par exemple, pour se connecter depuis leur ordinateur personnel). Après avoir découvert l'une de ces adresses, un attaquant peut former un paquet en utilisant cette adresse comme adresse de retour, et ainsi « passer » à travers le pare-feu. Il peut ensuite deviner les numéros de séquence des paquets TCP et s'assurer que le service qui fait confiance à l'adresse de retour effectue l'action souhaitée. Il s'agit d'une attaque très difficile à mettre en œuvre, qui peut néanmoins être réalisée par un spécialiste compétent, et si nous parlons du protocole UDP, alors même un pirate informatique peut le faire.
Heureusement, il est facile de se protéger de ces attaques. Il suffit de ne pas ouvrir les ports des services non protégés vers le monde extérieur, et en cas de besoin urgent, d'utiliser les systèmes de sécurité des services eux-mêmes (par exemple, les certificats ssh) ou le mécanisme de « port knocking » (discuté à la fin de l'article).
La situation devient plus complexe lorsqu'il s'agit d'un pont réseau séparant un réseau interne et externe (ou deux réseaux locaux). Les relations de confiance au sein d’un réseau local sont monnaie courante. Les services sont accessibles à tous, pas d'authentification, de cryptage, etc. - juste un morceau savoureux pour un cambrioleur. Étant sur un réseau externe, il peut connaître le masque de réseau du réseau interne et générer des paquets avec une adresse de retour correspondante, ce qui permettra d'accéder à toutes les ressources locales. Il s’agit d’une situation vraiment dangereuse, mais elle peut être facilement évitée grâce à une configuration appropriée du pare-feu ou du système d’exploitation.
Pour cela, il suffit d'interdire le passage des paquets dont les adresses de retour correspondent à celles utilisées dans le réseau interne depuis l'interface externe :
Linux> iptables -A INPUT -i $outif \
-s 192.168.1.0/24 -j REFUSER
FreeBSD> ipfw ajoute un refus d'adresse IP à partir de \
192.168.1.0/24 vers n'importe quel via $outif
OpenBSD> bloquer $outif depuis \
192.168.1.0/24 vers n'importe quel
Comme mesure de sécurité alternative ou supplémentaire, vous pouvez (et même devez) utiliser les directives ipfw et pf spéciales et les paramètres du noyau Linux :
Linux> echo 1> /proc/sys/net/ipv4/conf/all/rp_filter
FreeBSD> ipfw ajoute un refus d'adresse IP de n'importe quel à n'importe quel non antispoof dans
OpenBSD> antispoof rapide pour $ext_if
Ces trois commandes produisent les mêmes résultats. Tous les paquets dont les adresses de retour correspondent au masque de réseau d'une autre interface sont rejetés.
Avantages d'IPTABLES
À la fin de l'article, nous examinerons plusieurs fonctionnalités intéressantes d'iptables/netfilter qui peuvent être utiles pour protéger votre serveur contre les intrusions. Commençons par un mécanisme de gestion du pare-feu à distance, appelé « port knocking ». Son essence est de forcer le pare-feu à effectuer certaines actions après s'être connecté à un port donné. Vous trouverez ci-dessous un exemple de règles qui ouvrent le port SSH pendant 10 secondes après avoir frappé le port 27520 :
iptables et frappe de port
# Chaîne de vérification des connexions au port protégé
iptables -N frapper
# Autoriser la connexion s'il y a eu un coup au cours de la dernière
10 secondes
iptables -A knock -m récent --rcheck --seconds 10\
-j ACCEPTER
# Effacer l'ENTRÉE
iptables -F ENTRÉE
# Autoriser tout ce qui concerne les connexions déjà établies
iptables -A INPUT -m conntrack\
--ctstate ÉTABLI, RELATED -j ACCEPTER
# Toutes les tentatives d'ouverture de connexion au port 22 sont envoyées
vérifier la chaîne de frappe
-p tcp --dport 22 -j frapper
# Ajoutez l'adresse de la personne qui frappe sur le port 27520 à la liste
iptables -A INPUT -m conntrack --ctstate NOUVEAU \
-p tcp --dport 27520 -m récent --set
# Lorsque vous frappez sur les ports voisins, supprimez l'adresse de la liste
iptables -A INPUT -m conntrack --ctstate NEW -p tcp \
-m multiport --dport 27519,27521 -m récent --remove
# Tout interdire
iptables -P BAISSE D'ENTRÉE
La troisième règle à partir de la fin ajoute l'adresse de la personne qui frappe à la liste. Si la même machine accède au port 22 dans les 10 secondes suivant le coup, la connexion sera établie. L’avant-dernière règle est la protection contre les « coups brutaux ». Si un attaquant tente d'accéder successivement à tous les ports dans l'espoir que l'un d'entre eux ouvrira le port 22, cette règle fonctionnera et son adresse sera supprimée de la liste immédiatement après l'avoir atteinte.
Le deuxième utilitaire iptables est distribué dans le package xtables-addons (patch-o-matic) et s'appelle TARPIT. Il s'agit d'une action (identique à ACCEPT ou DENY) qui « bloque » la connexion, empêchant l'attaquant de la fermer. Une connexion dont les paquets tombent dans TARPIT sera établie avec succès, mais la taille de la fenêtre sera nulle, donc la machine distante ne pourra pas envoyer de données, gaspillant ainsi ses ressources, et la connexion ne sera fermée qu'après un délai d'attente. TARPIT peut être utilisé en cas d’urgence pour se protéger contre le DoS :
# iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT
Ou pour tromper l'attaquant et lutter contre les scanners
ports (analyse TCP normale uniquement, "-sT") :
# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPTER
# iptables -A INPUT -p tcp -m tcp --dport 25 -j ACCEPTER
# iptables -A INPUT -p tcp -m tcp -j TARPIT
Ces règles créent l'apparence d'un système dans lequel tous les ports sont ouverts, mais si vous essayez de vous connecter à l'un d'entre eux (sauf 80 et 25), les connexions se bloqueront. Le même résultat, mais sans l'affaissement des connexions, peut être obtenu en utilisant l'action DELUDE, qui répond correctement à toutes les tentatives d'initiation de connexion, mais envoie un paquet RST en réponse à tous les autres paquets. Pour confondre davantage l'attaquant, vous pouvez utiliser l'action CHAOS, qui active aléatoirement l'une des deux actions décrites ci-dessus.
conclusions
Avec suffisamment de connaissances et une lecture réfléchie de la documentation, vous pouvez créer un bastion très solide dont il ne sera pas si facile de s'approcher. Les pare-feu modernes, et notamment pf et iptables, offrent de nombreuses protections contre les invités indésirables, que vous pouvez obtenir tout à fait gratuitement.
Liens
- sf.net/projects/sentrytools - PortSentry
- www.openwall.com/scanlogd-scanlogd
Lutter contre la fuite des ressources
Lorsque vous utilisez l'action TARPIT, assurez-vous d'ajouter la règle suivante à la configuration, sinon les connexions « affaissées » consommeront des ressources lorsqu'elles seront traitées par le sous-système conntrack :
# iptables -t raw -I PREROUTING -p tcp --dport 25 -j NOTRACK
Les utilisateurs sont souvent agacés par la lenteur d’Internet. Cela s'applique particulièrement à la grande armée de fans de jeux en ligne. Vous pouvez réduire les retards potentiels en désactivant la fonction ping.
Tu auras besoin de
- - PC avec système d'exploitation Windows installé ;
- - Accès Internet.
Instructions
Instructions
Continuons donc à nous occuper des ACL. Cette fois, nous avons étendu les ACL. Nous reprendrons la topologie de l'article précédent, j'espère que vous l'avez étudiée à fond. Si ce n'est pas le cas, je vous recommande fortement de le lire afin que les éléments contenus dans cet article soient plus compréhensibles.
Tout d’abord, je vais commencer par ce que sont les ACL étendues. Les ACL étendues vous permettent de spécifier le protocole, l'adresse de destination et les ports en plus de l'adresse source. Ainsi que des paramètres spéciaux d'un certain protocole. Il est préférable d’apprendre à partir d’exemples, alors créons une nouvelle tâche, compliquant la précédente. À propos, quelqu'un pourrait être intéressé par les problèmes de répartition du trafic par priorité après cela ; je recommande un bon article sur la classification et le marquage de la qualité de service, bien qu'en anglais. Bon, pour l'instant, revenons à notre tâche :
Tâche.
- Autorisez les demandes d'écho des hôtes du réseau 192.168.0.0/24 vers le serveur.
- Depuis le serveur – interdire les demandes d’écho vers le réseau interne.
- Autoriser l'accès WEB au serveur à partir du nœud 192.168.0.11.
- Autorisez l'accès FTP de l'hôte 192.168.0.13 au serveur.
Tâche complexe. Nous le résoudrons également de manière globale. Tout d’abord, je vais examiner la syntaxe d’utilisation d’une ACL étendue.
Options ACL étendues
<номер от 100 до 199> <действие permit, deny> <протокол> <источник> <порт> <назначение> <порт> <опции>
Les numéros de port ne sont bien entendu indiqués que pour les protocoles TCP/UDP. Il peut aussi y avoir des préfixes équip(numéro de port égal à celui spécifié), gt/lt(le numéro de port est supérieur/inférieur à celui spécifié), néq(le numéro de port n'est pas égal à celui spécifié), gamme(plage de ports).
Listes de contrôle d'accès nommées
D'ailleurs, les listes d'accès peuvent non seulement être numérotées, mais aussi nommées ! Peut-être que cette méthode vous semblera plus pratique. Cette fois, c’est exactement ce que nous ferons. Ces commandes sont exécutées dans le cadre d'une configuration globale et la syntaxe est :
Routeur (config) #ip access-list étendue<имя>
Alors, commençons à élaborer les règles.
- Autoriser les pings du réseau 192.168.0.0/24
au serveur. Donc, écho-les requêtes sont un protocole ICMP, nous sélectionnerons notre sous-réseau comme adresse source, l’adresse du serveur comme adresse de destination, le type de message – sur l’interface entrante écho, à la sortie - réponse d'écho. Router(config)#ip access-list extend INT_IN Router(config-ext-nacl)#permit icmp 192.168.0.0 0.0.0.255 host 10.0.0.100 echo Oups, quel est le problème avec le masque de sous-réseau ? Oui, c'est une astuce Liste de contrôle d'accès. soi-disant Carte générique-masque. Il est calculé comme le masque inverse du masque habituel. Ceux. 255.255.255.255
- Masque de sous-réseau. Dans notre cas, le sous-réseau 255.255.255.0
, après soustraction, ce qui reste est juste 0.0.0.255
.Je pense que cette règle n’a pas besoin d’explication ? Protocole IMP, adresse source – sous-réseau 192.168.0.0/24
, adresse de destination - hôte 10.0.0.100, type de message - écho(demande). D’ailleurs, il est facile de remarquer que hôte 10.0.0.100équivalent 10.0.0.100 0.0.0.0
.Nous appliquons cette règle à l’interface. Routeur (config)#int fa0/0
Router(config-if)#ip access-group INT_IN dans Eh bien, quelque chose comme ça. Maintenant, si vous vérifiez les pings, il est facile de voir que tout fonctionne bien. Ici cependant, une surprise nous attend, qui apparaîtra un peu plus tard. Je ne le révélerai pas encore. Qui l'a deviné - bravo ! - Depuis le serveur – nous interdisons toutes les demandes d’écho vers le réseau interne (192.168.0.0/24). Nous définissons une nouvelle liste nommée, INT_OUT, et l'attachons à l'interface la plus proche du serveur.
Routeur (config) #ip access-list étendu INT_OUT
Routeur (config-ext-nacl) #deny hôte icmp 10.0.0.100 192.168.0.0 0.0.0.255 écho
Routeur (config-ext-nacl)#exit
Routeur(config)#int fa0/1
Routeur (config-if) #ip access-group INT_OUT dans
Laissez-moi vous expliquer ce que nous avons fait. Création d'une liste d'accès étendue avec le nom INT_OUT, désactivant le protocole qu'elle contient IMP avec type écho de l'hôte 10.0.0.100 par sous-réseau 192.168.0.0/24 et appliqué à l'entrée de l'interface fa0/1, c'est à dire. le plus proche du serveur. Nous essayons d'envoyer pinger du serveur.
SERVEUR>ping 192.168.0.11
Ping 192.168.0.11 avec 32 octets de données :
Réponse de 10.0.0.1 : Hôte de destination inaccessible.
Réponse de 10.0.0.1 : Hôte de destination inaccessible.
Réponse de 10.0.0.1 : Hôte de destination inaccessible.
Statistiques ping pour 192.168.0.11 :
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte de 100 %)
Eh bien, cela semblait fonctionner comme il se doit. Pour ceux qui ne savent pas envoyer des pings, cliquez sur le nœud qui nous intéresse, par exemple un serveur. Allez dans l'onglet Bureau, là-bas Invite de commandes Et maintenant, la blague promise. Essayez d'envoyer un ping depuis l'hôte, comme au premier point. PC>ping 10.0.0.100
Ping 10.0.0.100 avec 32 octets de données :
La demande a expiré.
La demande a expiré.
La demande a expiré.
La demande a expiré.En voici un pour vous. Tout a fonctionné ! Pourquoi ça s'est arrêté ? C'est la surprise promise. J'explique quel est le problème. Oui, la première règle n’a pas disparu. Il permet d'envoyer une demande d'écho au nœud serveur. Mais où est l’autorisation de transmettre des réponses d’écho ? Il est parti! Nous envoyons une demande, mais nous ne pouvons pas accepter de réponse ! Pourquoi tout fonctionnait avant ? Nous n’avions pas d’ACL sur l’interface à l’époque. fa0/1. Et comme il n’y a pas d’ACL, alors tout est permis. Vous devrez créer une règle pour autoriser la réception des réponses icmp.
Ajouter à la liste INT_OUT
Ajoutons la même chose à la liste INT_IN.
Routeur (config-ext-nacl) #permit hôte icmp 10.0.0.100 192.168.0.0 0.0.0.255 réponse d'écho
Maintenant, ne vous plaignez pas. Tout va très bien !
- Nous autorisons l'accès WEB au serveur depuis le nœud *.11. Nous faisons de même ! Ici, cependant, vous devez en savoir un peu plus sur la façon dont les appels se produisent via les protocoles de couche 4 (TCP, UDP). Le port client est sélectionné arbitrairement > 1024, et le port serveur est sélectionné correspondant au service. Pour le WEB, il s'agit du port 80 (protocole http) Et le serveur WEB ? Par défaut, le service WEB est déjà installé sur le serveur, vous pouvez le voir dans les paramètres du nœud. Assurez-vous qu'il y a une coche. Et vous pouvez vous connecter au serveur en sélectionnant le raccourci « Navigateur Web » sur le « Bureau » de n'importe quel nœud. Bien entendu, il n’y aura plus d’accès désormais. Parce que nous avons des ACL sur les interfaces du routeur et qu’elles n’ont aucune règle d’autorisation d’accès. Eh bien, créons une liste d'accès INT_IN (qui se trouve sur l'interface fa0/0) ajoutez la règle : Router(config-ext-nacl)#permit tcp host 192.168.0.11 gt 1024 host 10.0.0.100 eq 80 Autrement dit, nous autorisons le protocole TCP de notre hôte (port arbitraire, > 1024) à l'adresse du serveur , port HTTP.
Et bien sûr, la règle inverse se trouve dans la liste INT_OUT (qui se trouve sur l'interface fa0/1):
Routeur (config-ext-nacl) #permit hôte TCP 10.0.0.100 eq 80 hôte 192.168.0.11 établi
Autrement dit, nous autorisons TCP du port 80 serveurs par hôte *.11 , et la connexion devrait déjà être établie ! Peut-être à la place établi indiquer la même chose GT1024, fonctionnera tout aussi bien. Mais le sens est un peu différent.
Répondez dans les commentaires, qu'est-ce qui serait plus sûr ?
- Nous autorisons l’accès FTP depuis un nœud *.13 au serveur. Ce n’est absolument rien de compliqué ! Voyons comment se produit l’interaction via le protocole FTP. À l'avenir, je prévois de consacrer toute une série d'articles au travail de différents protocoles, car cela est très utile pour créer des règles ACL (sniper) précises. Bon, pour l'instant : Actions serveur et client :+ Le client tente d'établir une connexion et envoie un paquet (qui contient une indication qu'il fonctionnera en mode passif) au port 21 du serveur depuis son port X (X > 1024, port libre) + Le serveur envoie une réponse et rapporte son numéro de port pour former un canal de données Y (Y > 1024) au port client X, extrait de l'en-tête du paquet TCP.+ Le client initie une communication pour transférer les données sur le port X+1 vers le port Y du serveur (extraites de l'en-tête de la transaction précédente). Quelque chose comme ça. Cela semble un peu compliqué, mais il vous suffit de le comprendre ! Ajoutez les règles à la liste INT_IN :
permettre l'hôte TCP 192.168.0.13 gt 1024 hôte 10.0.0.100 eq 21
autorisation TCP hôte 192.168.0.13 gt 1024 hôte 10.0.0.100 gt 1024Et ajoutez des règles à la liste INT_OUT :
autoriser l'hôte TCP 10.0.0.100 eq hôte FTP 192.168.0.13 gt 1024
autoriser l'hôte TCP 10.0.0.100 gt 1024, l'hôte 192.168.0.13 gt 1024Nous vérifions depuis la ligne de commande avec la commande FTP 10.0.0.100, où nous nous connectons en utilisant nos informations d'identification cisco:cisco(extrait des paramètres du serveur), entrez la commande ici dir et nous verrons que les données, ainsi que les commandes, sont transmises avec succès.
C'est à peu près tout ce qui concerne les listes d'accès étendues.
Alors, regardons nos règles :
Accès au routeur#sh
Liste d'accès IP étendue INT_IN
permis icmp 192.168.0.0 0.0.0.255 hôte 10.0.0.100 echo (17 correspondance(s))
autoriser l'hôte icmp 10.0.0.100 192.168.0.0 0.0.0.255 réponse d'écho
permis TCP hôte 192.168.0.11 gt 1024 hôte 10.0.0.100 eq www (36 correspondance(s))
permettre l'hôte TCP 192.168.0.13 gt 1024 hôte 10.0.0.100 eq ftp (40 correspondance(s))
permis TCP hôte 192.168.0.13 gt 1024 hôte 10.0.0.100 gt 1024 (4 correspondance(s))
Liste d'accès IP étendue INT_OUT
refuser l'hôte icmp 10.0.0.100 192.168.0.0 0.0.0.255 echo (4 correspondance(s))
permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply (4 correspondance(s))
permis TCP hôte 10.0.0.100 eq www hôte 192.168.0.11 établi (3 correspondance(s))
permettre l'hôte TCP 10.0.0.100 eq hôte FTP 192.168.0.13 gt 1024 (16 correspondance(s))
permis TCP hôte 10.0.0.100 gt 1024 hôte 192.168.0.13 gt 1024 (3 correspondance(s))
