Iptables rejette tout ce qu'il devrait accepter

Tout le monde, bonjour!

J'essaie de configurer mon firewall de serveur en utilisant iptables (je dois avouer que la dernière fois que j'ai utilisé iptables était il ya un an), mais iptables agit contrairement à ce que je demande.

Voici mon script de test:

#!/bin/sh IPT="/sbin/iptables" echo -n "Loading iptables rules..." # Flush old rules $IPT --flush $IPT --delete-chain # Allow incoming and outgoing for loopback interfaces $IPT -A INPUT -i lo -j ACCEPT $IPT -A OUTPUT -o lo -j ACCEPT # Allow incoming traffic for HTTP(S), SSH and SMTP $IPT -A INPUT -p tcp --dport 80 -i eth0 -j ACCEPT $IPT -A INPUT -p tcp --dport 443 -i eth0 -j ACCEPT $IPT -A INPUT -p tcp --dport 22 -j ACCEPT $IPT -A INPUT -p tcp --dport 25 -i eth0 -j ACCEPT # Allow ICMP requests $IPT -A INPUT -p icmp -i eth0 -j ACCEPT $IPT -A OUTPUT -p icmp -o eth0 -j ACCEPT # Allow outgoing traffic for SMTP, DNS, NTP, PgSQL, SolR, and SSH $IPT -A OUTPUT -p tcp --dport 25 -o eth0 -j ACCEPT $IPT -A OUTPUT -p tcp --dport 53 -o eth0 -j ACCEPT $IPT -A OUTPUT -p udp --dport 53 -o eth0 -j ACCEPT $IPT -A OUTPUT -p udp --dport 123 -o eth0 -j ACCEPT $IPT -A OUTPUT -p tcp --dport 5433 -o eth0.2654 -j ACCEPT $IPT -A OUTPUT -p udp --dport 5433 -o eth0.2654 -j ACCEPT $IPT -A OUTPUT -p tcp --dport 8983 -o eth0.2654 -j ACCEPT $IPT -A OUTPUT -p udp --dport 8983 -o eth0.2654 -j ACCEPT $IPT -A OUTPUT -p tcp --dport 22 -o eth0 -j ACCEPT $IPT -A OUTPUT -p tcp --dport 22 -o eth0.2654 -j ACCEPT # Deny web server user outgoing connections $IPT -A OUTPUT -o eth0 -m owner --uid-owner www-data -j DROP # Drop everything else $IPT -A INPUT -j DROP $IPT -A OUTPUT -j DROP $IPT -A FORWARD -j DROP echo "rules loaded." # Print rules as understood, then flush to avoid lockout sleep 10 $IPT -L # Flush old rules $IPT --flush $IPT --delete-chain 

Avec ce script, le serveur ne se répercute plus sur aucune requête, mais ping (ICMP) puis, après 10 secondes, imprime le texte suivant et sort:

 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 100 5920 ACCEPT all -- lo any anywhere anywhere 0 0 ACCEPT tcp -- eth0 any anywhere anywhere tcp dpt:www 0 0 ACCEPT tcp -- eth0 any anywhere anywhere tcp dpt:https 1 52 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh 0 0 ACCEPT tcp -- eth0 any anywhere anywhere tcp dpt:smtp 0 0 ACCEPT icmp -- eth0 any anywhere anywhere 0 0 DROP all -- any any anywhere anywhere Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- any any anywhere anywhere Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 100 5920 ACCEPT all -- any lo anywhere anywhere 0 0 ACCEPT icmp -- any eth0 anywhere anywhere 0 0 ACCEPT tcp -- any eth0 anywhere anywhere tcp dpt:smtp 0 0 ACCEPT tcp -- any eth0 anywhere anywhere tcp dpt:domain 0 0 ACCEPT udp -- any eth0 anywhere anywhere udp dpt:domain 0 0 ACCEPT udp -- any eth0 anywhere anywhere udp dpt:ntp 0 0 ACCEPT tcp -- any eth0.2654 anywhere anywhere tcp dpt:5433 0 0 ACCEPT udp -- any eth0.2654 anywhere anywhere udp dpt:5433 0 0 ACCEPT tcp -- any eth0.2654 anywhere anywhere tcp dpt:8983 0 0 ACCEPT udp -- any eth0.2654 anywhere anywhere udp dpt:8983 0 0 ACCEPT tcp -- any eth0 anywhere anywhere tcp dpt:ssh 0 0 ACCEPT tcp -- any eth0.2654 anywhere anywhere tcp dpt:ssh 0 0 DROP all -- any eth0 anywhere anywhere owner UID match www-data 14 2061 DROP all -- any any anywhere anywhere 

Premier élément perturbateur, j'ai remarqué que les premières règles INPUT et OUTPUT ACCEPTENT tous les paquets alors que je n'ai pas demandé à le faire. De plus, j'ai essayé de définir la politique d'INPUT et OUTPUT sur DROP (en utilisant $IPT -P INPUT DROP et $IPT -P OUTPUT DROP ), mais cela s'est définitivement bloqué, même après le délai de dix secondes, et le serveur alors Répond uniquement à ICMP, ce qui me force à redémarrer dur le serveur. Même effet si j'ai défini les paramètres de stratégie au début du script.

Je soupçonne que mon erreur est évidente pour les utilisateurs ordinaires d'iptables, mais j'ai cherché la solution depuis des heures et, comme toujours dans ce genre de situations, la réponse ne sera évidente pour moi que lorsque quelqu'un le signalera. S'il vous plait, faites-vous du mieux pour m'aider?

eth0.2654 est un VLAN utilisé pour les communications avec notre serveur PgSQL. En ce qui concerne les réponses HTTP, j'ai eu l'impression qu'ils utilisaient la connexion que le client a ouverte, ce qui est autorisé par ma règle. Étais-je faux?

En ce qui concerne les réponses HTTP, j'ai eu l'impression qu'ils utilisaient la connexion que le client a ouverte, ce qui est autorisé par ma règle. Étais-je faux?

Oui, vous avez eu tort. Il est très probable que vous souhaitez accepter une connexion établie ou liée aux connexions entrantes. Ainsi, tout ce qui est accepté dans la règle de saisie peut être répondu. Avec un pare-feu sans état, il faudrait ouvrir explicitement le port source. Étant donné que IPtables est doté, vous n'avez pas besoin de le faire. Il suivra l'état des connexions pour vous et autorisera automatiquement les connexions sortantes comme vous le pensez, mais seulement si vous lui dites de le faire. La règle pour cela est iptables -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT . Mettez cela en haut de votre liste de sortie. Si vous voulez être particulièrement agressif, vous pouvez lier cette règle à des ports spécifiques.

Si vous deviez regarder cela de manière apatride, vous devriez vous rappeler d'où viennent les paquets. Votre serveur est actuellement configuré pour vous permettre de SSH vers une autre machine. Comme vous ne permettez aucun trafic qui possède le port 22 comme source, votre serveur ne peut pas répondre aux connexions entrantes. Encore une fois, la règle "ÉTABLI, RELATIVE" résout cela pour permettre au trafic de répondre aux connexions entrantes, ce qui permettrait au trafic provenant du port 22, mais contrairement à l'ouverture 22 sur un pare-feu sans état, cette configuration n'autorisera pas de nouvelles connexions à partir de là.

Votre approche est mauvaise. Vous autorisez toutes les connexions d'entrée, puis vous les arrêtez à la sortie. Cela n'empêchera pas les attaques DDoS. La bonne façon est d'arrêter les connexions d'entrée et d'autoriser la sortie.

En lisant votre code, j'ai essayé de refaire. Voici comment je pense qu'il devrait regarder:

 #!/bin/sh IPT=/usr/sbin/iptables echo "Clear firewall rules..." $IPT -F $IPT -Z $IPT -t nat -F $IPT -t nat -Z $IPT -t mangle -F $IPT -t mangle -Z $IPT -X echo "Setting firewall policy..." $IPT -P INPUT DROP # Deny all incoming connections $IPT -P OUTPUT ACCEPT # Allow all outgoing connections $IPT -P FORWARD DROP # Deny all forwaring echo "Allow connections from: lo, eth0, eth0.2654" $IPT -I INPUT -i lo -j ACCEPT $IPT -I INPUT -i eth0 -j ACCEPT echo "Allow icmp requests from eth0" $IPT -A INPUT -p icmp -i eth0 -j ACCEPT echo "Allow traffic for HTTP(S), SSH, SMTP, DNS, NTP, PgSQL, SolR" $IPT -A INPUT -p tcp --dport 22 -j ACCEPT $IPT -A INPUT -p tcp --dport 25 -i eth0 -j ACCEPT $IPT -A INPUT -p tcp --dport 53 -i eth0 -j ACCEPT $IPT -A INPUT -p udp --dport 53 -i eth0 -j ACCEPT $IPT -A INPUT -p tcp --dport 80 -i eth0 -j ACCEPT $IPT -A INPUT -p udp --dport 123 -i eth0 -j ACCEPT $IPT -A INPUT -p tcp --dport 443 -i eth0 -j ACCEPT $IPT -A INPUT -p tcp --dport 5433 -i eth0.2654 -j ACCEPT $IPT -A INPUT -p udp --dport 5433 -i eth0.2654 -j ACCEPT $IPT -A INPUT -p tcp --dport 8983 -i eth0.2654 -j ACCEPT $IPT -A INPUT -p udp --dport 8983 -i eth0.2654 -j ACCEPT echo "Deny web server user outgoing connections; eth0" $IPT -A INPUT -o eth0 -m owner --uid-owner www-data -j DROP echo "Drop everything." $IPT -A INPUT -s 0/0 -j DROP echo "Firewall loaded." sleep 20 $IPT -nvL echo "Clear firewall rules..." $IPT -F $IPT -Z $IPT -t nat -F $IPT -t nat -Z $IPT -t mangle -F $IPT -t mangle -Z $IPT -X 

Je n'ai pas testé, alors gardez cela à l'esprit. Je ne sais pas si "-i eth0.2654" fonctionnerait sur des interfaces virtuelles.

Si vous voulez – essayez-le et faites-le moi savoir si cela fonctionne ou non.