Pourquoi ne pas bloquer ICMP?
Je pense que ma configuration iptables est presque terminée sur mon système CentOS 5.3. Voici mon script ...
# Establish a clean slate
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F # Flush all rules
iptables -X # Delete all chains
# Disable routing. Drop packets if they reach the end of the chain.
iptables -P FORWARD DROP
# Drop all packets with a bad state
iptables -A INPUT -m state --state INVALID -j DROP
# Accept any packets that have something to do with ones we've sent on outbound
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Accept any packets coming or going on localhost (this can be very important)
iptables -A INPUT -i lo -j ACCEPT
# Accept ICMP
iptables -A INPUT -p icmp -j ACCEPT
# Allow ssh
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Allow httpd
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Allow SSL
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Block all other traffic
iptables -A INPUT -j DROP
Pour le contexte, cette machine est un hôte d'application Web Virtual Private Server.
Dans une question précédente , Lee B a dit que je devrais "verrouiller ICMP un peu plus". Pourquoi ne pas simplement le bloquer complètement? Que se passerait-il si je faisais ça (quelle mauvaise chose arriverait)?
Si je n'ai pas besoin de bloquer ICMP, comment pourrais-je le verrouiller davantage?
ICMP est bien plus que "traceroute" et "ping". Il est utilisé pour les commentaires lorsque vous exécutez un serveur DNS (port inaccessible) qui, dans un serveur DNS moderne, peut réellement aider à sélectionner une machine différente pour interroger plus rapidement.
ICMP est également, comme cela a été mentionné ci-dessus, utilisé pour la découverte de MTU de chemin. Il y a de fortes chances que votre système d'exploitation définit "DF" (ne pas fragmenter) sur les paquets TCP qu'il envoie. Il s'attend à récupérer un paquet ICMP "fragmentation requise" si quelque chose le long du chemin ne parvient pas à être géré Si vous bloquez tous les ICMP, votre machine devra utiliser d'autres mécanismes de secours, qui utilisent essentiellement un délai d'attente pour détecter un "trou noir" PMTU et ne seront jamais optimisés correctement.
De plus, vous devez vous demander pourquoi vous souhaitez bloquer ICMP. Qu'essayez-vous précisément d'empêcher ici? Il est assez clair que vous ne comprenez pas à quoi sert ICMP, ce qui est plutôt courant. Je serais extrêmement prudent en bloquant quelque chose que vous ne comprenez pas complètement.
Pour le rendre encore plus difficile à apprendre à ce sujet, de nombreux livres sur les pare-feu courants disent "bloquer ICMP" - il est clair que leurs auteurs n'ont jamais lu un RFC ou n'ont pas dû résoudre les problèmes entourant de tels conseils. C'est un mauvais conseil de bloquer tous les ICMP.
Maintenant, la limitation du taux peut également nuire. Si votre machine est occupée, ou même si ce n'est pas le cas, vous pouvez obtenir une bonne quantité de trafic ICMP. Mon serveur Web reçoit probablement environ 10 à 100 paquets ICMP par minute, dont la plupart est une découverte PMTU. Même si quelqu'un a choisi d'attaquer mon serveur avec des paquets ICMP d'un certain type, ce n'est vraiment pas si grave. Si votre machine accepte même une seule TCP (ssh, http, mail, etc.), il y a de fortes chances que ce soit un vecteur d'attaque plus grand que l'ICMP mal compris ne le sera jamais.
ICMP est utilisé pour une gamme de fonctions de diagnostic (par exemple ping, traceroute) et de contrôle de réseau (par exemple découverte PMTU). Le blocage aveugle de l'ICMP provoque d'autres brûlures d'estomac chez toutes les personnes, et à moins que vous sachiez exactement ce que vous faites, vous devriez le laisser tranquille.
Je n'ai jamais compris pourquoi les gens cadencent ICMP, comme dit ci-dessus, cela ne cause que des maux de tête à vous-même et aux autres. Vous pouvez déterminer si un hôte fonctionne assez facilement et tant qu'il est suffisamment limité pour ne pas être utilisé comme DOS, je n'ai jamais entendu de raisons impérieuses de le bloquer. (Si quelqu'un peut trouver une raison, veuillez poster)
vous pouvez simplement essayer de limiter icmp de cette façon, il ne peut pas être utilisé comme une attaque DOS. mais il y a beaucoup trop d'outils de dépannage comme ping, mtr (j'oublie l'équivalent de windows), traceroute (tracert), qui utilisent icmp. les abandonner est tout simplement stupide. C'est un bon moyen de vérifier si votre instance est active même si vous ne pouvez pas telnet sur aucun port.
--limit 10/secondVoici un autre point de vue, dans l'esprit de ce que la théorie de la sécurité suggérerait. D'autres affiches ont raison de dire que les pratiques en matière de sécurité sont souvent trop zélées, mais il y a une bonne base pour la plupart.
La théorie de la sécurité est généralement que vous activez uniquement ce dont vous avez besoin. D'autres choses (qui pourraient être utiles - par exemple, des réponses ping) peuvent être utilisées par un attaquant pour étendre votre système, ou éventuellement comme vecteur d'attaque pour une vulnérabilité encore à découvrir.
Donc, en regardant les types de messages ICMP, de quoi avez-vous besoin pour un fonctionnement normal et correct de votre système?
- écho réponse (ping) - pas tellement
- destination inaccessible - beaucoup d'informations utiles ici. Désactivez-le et vous interromprez l'accès à votre serveur pour certains clients.
- source quench - obsolète depuis 1995, et apparemment supprimé des implémentations de Host depuis (au plus tard) 2005. tools.ietf.org/html/rfc6633#section-1.
- rediriger - certainement pas
- publicité et sollicitation de routeur - pas besoin si vous configurez statiquement vos itinéraires, et pourrait être utilisé pour DoS. Je le bloquerais sauf si vous savez que vous en avez besoin, et si vous en avez besoin, codez peut-être une règle pour accepter les informations provenant uniquement des routeurs connus possibles.
- ttl dépassé - pas seulement pour traceroute, vous indique que votre trafic n'atteint pas sa destination
...etc. Si vous voulez vraiment comprendre cela, allez en apprendre davantage sur les différents types ICMP et à quoi ils servent. article wikipedia est un bon point de départ.
En pratique, le vraiment moche est la redirection; si vous voulez juste faire quelque chose de rapide et d'utile, bloquez-le et laissez le reste.
J'ajouterais que le suivi des connexions IPtables permettra les paquets ICMP de retour appropriés pour les connexions actives. Donc, si vous exécutez conntrack, vous devriez pouvoir bloquer la plupart des messages entrants ICMP, tant que vous acceptez les paquets RELATED (avant de bloquer ICMP dans votre ensemble de règles).
C'est un outil de diagnostic utile pour résoudre les problèmes de connectivité réseau.
Il vous permet également d'utiliser des connexions ailleurs sur Internet qui utilisent des MTU plus petits que ceux de votre réseau. Si vous essayez d'envoyer un paquet quelque part qui est trop volumineux et ne peut pas être fragmenté, le périphérique supprime le paquet et renvoie un paquet nécessaire à la fragmentation ICMP à l'expéditeur. Si vous supprimez tous les paquets ICMP, vous les perdez et des choses étranges se produisent sur votre réseau.
La vraie question est "pourquoi bloquer ICMP?" Que gagnez-vous? Ayez simplement de bonnes règles de filtrage à votre frontière et devant vos actifs de valeur.
ping est un bel outil de diagnostic, vous souhaiterez vraiment l'avoir un jour. J'utilise ces derniers:
-A icmp_packets -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT
vous pouvez également le limiter.
De nos jours, même limiter les paquets ICMP côté serveur peut créer des maux de tête lors des attaques DDoS. Les attaques sont principalement effectuées en envoyant d'énormes demandes ICMP à un serveur et si le serveur essaie de répondre à chacun d'entre eux, devinez ce qui se passe?
L'essentiel, c'est que nous avons un serveur TeamSpeak qui reçoit de mauvais paquets chaque jour, il y a eu quelques jours en deux mois où nous avons eu un peu de "temps libre". Ce que nous avions fait est complètement désactivé/bloqué les réponses ICMP, nous n'avons pas de serveurs DNS sur le serveur, pas de serveurs NTP, pas de serveurs de messagerie, pas de serveurs FTP, seulement deux Apache et teamspeak. Tous les ports qui est inutile pour les services sont désactivés. Nous prévoyons de bloquer même le ssh et de ne laisser que deux ports ouverts. Aujourd'hui, il y a 21k (!) interdictions permanentes.
La situation est que les attaquants utilisent principalement des tunnels ICMP et quelques lignes de journal vraiment intéressantes ont été discutées avec les administrateurs de serveur et ils ont dit qu'ils avaient des requêtes ICMP de serveur, donc les attaquants l'ont utilisé pour tunneler l'attaque à travers eux et nous attaquer. Ça a l'air bizarre mais c'est vrai.
Si vous n'avez pas besoin de diagnostics de votre serveur et si vous êtes en mesure de bloquer complètement les requêtes ou de les filtrer pour supprimer des fenêtres énormes par exemple, faites-le. Je vous suggère également de bloquer complètement: la Chine, la Corée, la Thaïlande, la Turquie car la majorité des adresses IP vient de là. J'avais des listes entières de ces pays, mais presque chaque jour en vient de nouveaux.
Je dis ce que je fais, si vous n'êtes pas d'accord - ne le faites pas. Aussi simple que cela. Bonne chance
Au minimum, vous devez autoriser les types d'ICMP 3 (destination inaccessible), 4 (extinction de la source) et 11 (dépassement du temps). Tous ces types sont utilisés pour traiter les problèmes de réseau et ne doivent pas être filtrés.
iptables -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
(Le type d'extinction de source est actuellement obsolète, mais cela ne fera pas de mal de le laisser ouvert)