Conseils pour une configuration sécurisée d'iptables pour se défendre contre les attaques. (côté client!)

Question

Propres exemples:

############### # KERNEL PARAMETER CONFIGURATION # PREVENT YOU SYSTEM FROM ANSWERING ICMP ECHO REQUESTS echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all # DROP ICMP ECHO-REQUEST MESSAGES SENT TO BROADCAST OR MULTICAST ADDRESSES echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # DONT ACCEPT ICMP REDIRECT MESSAGES echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects # DONT SEND ICMP REDIRECT MESSAGES echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects # DROP SOURCE ROUTED PACKETS echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route # ENABLE TCP SYN COOKIE PROTECTION FROM SYN FLOODS echo 1 > /proc/sys/net/ipv4/tcp_syncookies # ENABLE SOURCE ADDRESS SPOOFING PROTECTION echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter # LOG PACKETS WITH IMPOSSIBLE ADDRESSES (DUE TO WRONG ROUTES) ON YOUR NETWORK echo 1 > /proc/sys/net/ipv4/conf/all/log_martians # DISABLE IPV4 FORWARDING echo 0 > /proc/sys/net/ipv4/ip_forward ############### # INPUT # DROP INVALID $IPTABLES -A INPUT -m state --state INVALID -j DROP # ALLOW ONLY ESTABLISHED, RELATED $IPTABLES -A INPUT -p tcp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -p udp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT # DROP INVALID SYN PACKETS $IPTABLES -A INPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP $IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP $IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP # MAKE SURE NEW INCOMING TCP CONNECTIONS ARE SYN PACKETS; OTHERWISE WE NEED TO DROP THEM $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP # DROP PACKETS WITH INCOMING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS $IPTABLES -A INPUT -f -j DROP # DROP INCOMING MALFORMED XMAS PACKETS $IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j DROP # DROP INCOMING MALFORMED NULL PACKETS $IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP ############### # OUTPUT # DROP INVALID $IPTABLES -A OUTPUT -m state --state INVALID -j DROP # DROP INVALID SYN PACKETS $IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP $IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP $IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP # MAKE SURE NEW OUTGOING TCP CONNECTIONS ARE SYN PACKETS; OTHERWISE WE NEED TO DROP THEM $IPTABLES -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP # DROP PACKETS WITH OUTGOING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS $IPTABLES -A OUTPUT -f -j DROP # DROP OUTGOING MALFORMED XMAS PACKETS $IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ALL -j DROP # DROP OUTGOING MALFORMED NULL PACKETS $IPTABLES -A OUTPUT -p tcp --tcp-flags ALL NONE -j DROP

Pouvons-nous rassembler d'autres idées liées à iptables pour protéger les clients contre les attaques? Par exemple: un PC de bureau Ubuntu 11.04 "se défendre contre les attaques" ~ règles aimables.

Je vous remercie!

p.s .: bien sûr:

$IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT DROP

p.s.2: à la fois sur IPv4 et IPv6!

p.s.3: Je n'ai pas besoin de règles comme: autoriser uniquement UDP et TCP sur le port 53 sortant, je veux juste des règles de "défense" par exemple: scan de port, attaques, etc.

p.s.4: Le PC est derrière un routeur/NAT ou connecté "directement à Internet".

pepe · Accepted Answer

Je me rends compte qu'il existe des opinions différentes, mais l'une des principales attitudes des personnes qui connaissent vraiment la mise en réseau et la sécurité est que la plupart de ces règles iptables/sysctl sont redondantes, sinon dommageables pour vous et le réseau. Certains vous critiqueront agressivement pour avoir rompu avec un comportement standard sans raison. Quelques exemples:

Le comportement TCP/IP standard consiste à REJETER afin que l'homologue obtienne un indice sur ce qui se passe. Peut-être que quelqu'un vient de taper une URL incorrecte ou que votre administrateur compte les hôtes ou que quelqu'un veut se connecter à votre serveur de jeu mais a tapé le mauvais port. Avec DROP, ils n'obtiennent que des délais d'attente obscurs et ennuyeux.
Il n'est pas nécessaire de supprimer les paquets invalides ou mal formés, toutes ces attaques datent d'une décennie. Les développeurs du noyau Linux sont beaucoup plus à jour que vous concernant le type de paquets valides et ceux qui ne le sont pas. "Qu'en est-il des défauts futurs", pourraient prétendre certains. Eh bien, comment savez-vous que la faille future sera dans le gestionnaire TCP et non dans iptables TCP parser?)
La plupart des paramètres sysctl sont par défaut. Si ce n'est pas le cas, il y a généralement une raison. Par exemple, pourquoi désactiver l'envoi de redirections? Je trouve très utile d'être informé par un pair que mon routage est mauvais, même si je ne réagirais jamais ("accept_redirects", default = 0) automatiquement.
Avec vos log_martians et autres règles de journalisation, j'espère que vous avez également un quota sur/var/log, ou ce sera très amusant de remplir votre disque à distance, tuant généralement vos services/applications. En outre, vous devez utiliser une limite de débit pour la journalisation, sinon quelqu'un pourrait remplir le quota pour vous empêcher de voir les tentatives de force brute du mot de passe SSH dans auth.log ou autre. Lisez-vous réellement ces journaux sur un bureau? Je recommande logcheck.
Vous semblez bloquer ICMP. Outre le problème DHCP mentionné, cela empêche également la découverte de PMTU. Sans PMTUD, vous obtiendrez un comportement étrange lorsque vous utilisez le système dans des endroits avec une connexion DSL ou d'autres paramètres réseau. Certains paquets seront simplement supprimés et personne ne vous expliquera pourquoi.
Le filtrage des paquets sortants est un peu obscur. Tu ne te fais pas confiance? Vous ne devez généralement exécuter aucun programme auquel vous ne pouvez pas faire confiance. Les systèmes d'exploitation des produits de base sont pour la plupart incapables d'isoler ces programmes de l'écoute ou même de manipuler les données d'autres programmes (par exemple, les attaques de synchronisation du cache)
Vous avez besoin de NOUVEAUX paquets pour avoir SYN. Cela se cassera si une connexion TCP se poursuit après que l'état respectif dans iptables a déjà expiré. Je ne sais pas quels sont les délais par défaut, mais un gars de netfilter l'a averti.

Alors, quand un bureau devrait-il avoir un pare-feu?

S'il y a une attaque spécifique dans l'actualité à laquelle votre système d'exploitation ou vos serveurs actuels sont vulnérables, et l'une des solutions rapides recommandées est une règle de pare-feu.
Vous devez exécuter certains services qui ne permettent pas une configuration sécurisée. La plupart le font, et le reste est mieux remplacé par des alternatives sécurisées.
Vous disposez de réseaux plus complexes avec plusieurs machines virtuelles et/ou interfaces sur votre bureau.

Le premier et avant tout outil pour la sécurité de votre réseau est la mise à jour du système. Deuxièmement, il y a netstat et nmap, que vous devez utiliser pour trouver et confirmer les services que vous exécutez. Ensuite, désactivez simplement ceux dont vous n'avez pas besoin ou limitez-les à 127.0.0.1.

Bonus si vous lisez jusqu'ici: les paquets sont ÉTABLISSÉS, ASSOCIÉS ou NOUVEAUX, tout ce que vous laissez tomber. Vous supprimez également NEW sauf si seul SYN est défini. Depuis ESTABLISHED, RELATED semble vérifier les indicateurs, cela rend toutes les règles --tcp-flags et également la règle -f redondantes. Idem pour OUTPUT, mais comme aucun paquet n'est ACCEPTÉ pour OUTPUT de toute façon, cela n'a probablement pas d'importance.

Ori · Answer

Je serais prudent en faisant ces parties du même ensemble de règles pour les appareils à l'intérieur d'un réseau de confiance et ceux d'une DMZ. En utilisant les règles que vous avez définies ici, vous n'allez pas répondre à un serveur DHCP demandant (écho ICMP) si votre IP est utilisée. Cela pourrait conduire à une situation d'adresse en double.

Je créerais deux ensembles de règles différents à appliquer à chaque scénario, quelque chose comme ce qui est répertorié ci-dessus est une bonne base de référence pour une machine DMZ, mais crée des défis sur un LAN typique.

Je recommanderais également d'ajouter la journalisation aux martiens, les gouttes sortantes, les connexions abandonnées entrantes, etc. Cela peut être crucial pour le dépannage et peut être des données plus utiles à manger pour votre SIEM.

Hendrik Brummermann · Answer

Pour un PC client, connecté directement à Internet via ppp, le jeu de règles suivant est un bon début:

iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset iptables -A INPUT -p udp -j REJECT ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT ip6tables -A INPUT -p tcp -j REJECT --reject-with tcp-reset ip6tables -A INPUT -j REJECT

Il permet tout sur l'interface locale interne.
Il autorise tout paquet qui est une réponse pour un paquet que vous envoyez. Cela inclut les paquets dans une connexion TCP, réponses aux paquets UDP tels que les petites requêtes DNS. Pour l'ancien protocole FTP non chiffré, cela inclut la connexion de données, en supposant que ip_conntrack_ftp est chargé
Rejeter toutes les tentatives d'ouverture d'une connexion TCP de l'extérieur
Rejetez tous les paquets udp initiaux (sans réponse).

Vous pouvez également utiliser -j DROP dans les deux dernières règles. Pour une discussion sur ce sujet, voir Rejeter les paquets IP avec une erreur ICMP, ou simplement les supprimer?

Ori · Answer

Donc, pour développer votre question, voici ce que j'ai fait (et j'utiliserai vos exemples avec des notes, car les miens sont à peu près dépourvus de commentaires ayant été transmis à net fliter depuis la mort d'IPCHAINS il y a toutes ces années.)

Cela pourrait fonctionner pour un système interne, mais vous passerez souvent du temps à configurer vos iptables pour de nouvelles applications non prises en compte. J'ai également supprimé ma règle SSH, mais c'est une règle assez standard que vous verrez (et dans de nombreuses configurations, la seule que vous verrez pour autoriser la saisie.)

############### # VARIABLE DEFINITIONS IPTABLES=/sbin/iptables #Your DHCP Server for input of ICMP packets DHCPSERVER=127.0.0.1 PUBIF=eth0 # KERNEL PARAMETER CONFIGURATION # # DROP ICMP ECHO-REQUEST MESSAGES SENT TO BROADCAST OR MULTICAST ADDRESSES echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # # DONT ACCEPT ICMP REDIRECT MESSAGES echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects # # DONT SEND ICMP REDIRECT MESSAGES echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects # # DROP SOURCE ROUTED PACKETS echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route # # ENABLE TCP SYN COOKIE PROTECTION FROM SYN FLOODS echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # ENABLE SOURCE ADDRESS SPOOFING PROTECTION echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter # LOG PACKETS WITH IMPOSSIBLE ADDRESSES (DUE TO WRONG ROUTES) ON YOUR NETWORK echo 1 > /proc/sys/net/ipv4/conf/all/log_martians # DISABLE IPV4 FORWARDING echo 0 > /proc/sys/net/ipv4/ip_forward ############### $IPTABLES -F ############### # LOGDROPPER $IPTABLES -N LOGNDROP > /dev/null 2> /dev/null $IPTABLES -F LOGNDROP $IPTABLES -A LOGNDROP -j LOG --log-prefix "LOGNDROP: " $IPTABLES -A LOGNDROP -j DROP ############### # LO allowance $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A OUTPUT -o lo -j ACCEPT ############### # Only bring what you need to survive $IPTABLES -A INPUT -p icmp -s $DHCPSERVER -j ACCEPT $IPTABLES -A INPUT -i $PUBIF -s $DHCPSERVER -p tcp --sport 68 --dport 67 -j ACCEPT $IPTABLES -A INPUT -i $PUBIF -s $DHCPSERVER -p udp --sport 68 --dport 67 -j ACCEPT ############### # INPUT # # DROP INVALID $IPTABLES -A INPUT -m state --state INVALID -j LOGNDROP # ALLOW ONLY ESTABLISHED, RELATED $IPTABLES -A INPUT -p tcp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -p udp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT # DROP INVALID SYN PACKETS $IPTABLES -A INPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j LOGNDROP $IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOGNDROP $IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j LOGNDROP # MAKE SURE NEW INCOMING TCP CONNECTIONS ARE SYN PACKETS; OTHERWISE WE NEED TO DROP THEM $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOGNDROP # DROP PACKETS WITH INCOMING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS $IPTABLES -A INPUT -f -j LOGNDROP # DROP INCOMING MALFORMED XMAS PACKETS $IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j LOGNDROP # DROP INCOMING MALFORMED NULL PACKETS $IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j LOGNDROP ############### # OUTPUT # DROP INVALID $IPTABLES -A OUTPUT -m state --state INVALID -j LOGNDROP # DROP INVALID SYN PACKETS $IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j LOGNDROP $IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOGNDROP $IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,RST SYN,RST -j LOGNDROP # DROP PACKETS WITH OUTGOING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS $IPTABLES -A OUTPUT -f -j LOGNDROP # DROP OUTGOING MALFORMED XMAS PACKETS $IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ALL -j LOGNDROP # DROP OUTGOING MALFORMED NULL PACKETS $IPTABLES -A OUTPUT -p tcp --tcp-flags ALL NONE -j LOGNDROP $IPTABLES -P OUTPUT ACCEPT $IPTABLES -A INPUT -j LOGNDROP $IPTABLES -A FORWARD -j LOGNDROP

Si votre réseau est bruyant ou si vous avez beaucoup de choses en cours, cela remplira rapidement votre volume de journal. Mais je suis paranoïaque, et j'arrête aussi les côtelettes des gens s'ils créent des configurations qui sont inutilement bruyantes.