Ip6tables configuration

Support Debian
#1

Bonjour !

Je configurais ip6tables, après avoir configuré iptables avec succès.

ip6tables -F
ip6tables -X
ip6tables -t nat -F
ip6tables -t nat -X
ip6tables -t mangle -F
ip6tables -t mangle -X
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP 
 
# Autorise les connexions déjà établies et localhost                
ip6tables -A INPUT -m state --state ESTABLISHED -j ACCEPT       
ip6tables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT  
ip6tables -A INPUT -i lo -j ACCEPT                          
#ip6tables -A OUTPUT -o lo -j ACCEPT
 
 
#TOR
ip6tables -A OUTPUT -p tcp -m tcp --dport 9050 -j ACCEPT
 
# ICMP (Ping)                                       
   ip6tables -A INPUT -p icmpv6 -j ACCEPT						
    ip6tables -A OUTPUT -p icmpv6 -j ACCEPT
 
# DNS                                           
ip6tables -A OUTPUT -p tcp --dport 53 -j ACCEPT                 
ip6tables -A OUTPUT -p udp --dport 53 -j ACCEPT                     
 
# HTTP                                          
ip6tables -A OUTPUT -p tcp --dport 80 -j ACCEPT             
 
 
#HTTPS
ip6tables -A OUTPUT -p tcp --dport 443 -j ACCEPT                        
 
 
# Mail SMTP 
 ip6tables -A INPUT -p tcp --dport 587 -j ACCEPT
ip6tables -A OUTPUT -p tcp --dport 587 -j ACCEPT
 
#Transmission
ip6tables -A INPUT -p udp --dport 51413 -j ACCEPT
ip6tables -A OUTPUT -p udp --sport 51413 -j ACCEPT
 
 
# NTP (horloge du serveur) 
ip6tables -A OUTPUT -p udp --dport 123 -j ACCEPT    
 
# On log les paquets en entrée.
ip6tables -A INPUT -j LOG
 
 
exit 0

Tout fonctionne… Sauf SMTP. Et je ne comprend juste pas pourquoi ! Pourtant, msmtp n’utilise pas d’autres ports que 25 ou 465 ou 587… Avec le traffic autorisé sur les 3 je ne comprend pas ce qui ne va pas. Des idées ?

EDIT : smtp refonctionne. Next question : peut-on faire mieux ? est-ce optimal ? “sécurisé” ?

Merci d’avance !

#2

As tu vérifié que le smtp fonctionnait sans pare feu ?
[edit: Je veux dire, as tu testé si le smtp fonctionnait en ipv6, avant même le parefeu ?]

#3

Sauf erreur de ma part, si smtp fonctionne avec ip6tables tout en accept, et ne fonctionne pas avec ip6tables tout en drop, c’est qu’il est bien impacté par les règles ipv6, et par conséquent l’utilise, non ?

Mon FAI autorise ipv4 et ipv6.

iptable en acceptant 25 : smtp fonctionne
iptables en refusant 25 : smtp ne fonctionne pas.
iptables et ip6tables acceptant 25 : smtp ne fonctionne pas.

#4

Bonjour,

Je pose la question autrement.
Est-ce que ça fonctionne en ipv6 en n’ayant AUCUNE règle ip6tables ?

Comment effectues-tu les tests ?

#5

Oui ! Avant même que je touche à ip6tables, qu’à iptables, tout fonctionnait. Idem quand je remet tout ip6tables à accept.

Je test règle par règle. Puis iptables -F puis -X etc. Long mais intéressant ahah.

Puis pour iptables, petit script qui fonctionne aujourd’hui avec le nombre minimal de lignes nécessaires.

#6

La question de @sk4hrr a du sens: est ce que tu as essayé d’émuler une session sur le port 25 de l’ipv6 pour voir ce qui bloque ?
Le tool suivant le fait: https://network-tools.webwiz.net/email-test.htm

#7

Je n’ai pas encore joué avec Postfix en IPV6 mais d’après une brèves recherches il semble que les distributions GNU/Linux ne sont pas systématiquement fourni avec le support IPV6 :

http://www.postfix.org/IPV6_README.html

Supported Platforms

Postfix version 2.2 supports IPv4 and IPv6 on the following platforms:

    AIX 5.1+
    Darwin 7.3+
    FreeBSD 4+
    Linux 2.4+
    NetBSD 1.5+
    OpenBSD 2+
    Solaris 8+
    Tru64Unix V5.1+ 

On other platforms Postfix will simply use IPv4 as it has always done.

See below for tips how to port Postfix IPv6 support to other environments.

Le fait que Postfix permettent l’envoi de mail depuis un serveur configuré avec une double stack IPV4/IPV6 ne garantis pas que l’envoi soit fonctionnel en IPV6, le test le plus simple serait de couper l’IPV4 et sans iptables/IP6tables faire un tests de fonctionnement de l’envoi de mail.

#8

J’ai trouvé la solution !

En fait, je suis un boulet. Je commence à en avoir, des scripts ip6tables, et celui que j’appliquais tentait des filtres types :

ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT`

ip6tables -A OUTPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT

En acceptant tout icmpv6, ça fonctionne !

Seul soucis, ce n’est pas un peu problématique de laisser tout icmpv6 en accept ? je ne ferai pas mieux de filtrer comme si dessus ?

mais en ce cas, que manque-t-il, je ne vois vraiment pas ?

#9

J’ai trouvé la réponse à ma question.

En revanche, pour revenir à la configuration en elle-même : est-elle optimale, “sécurisée” ? Peut-on faire mieux ?

#10

Je me permet un petit up.

Voyez vous des améliorations pour mon script ?

On m’a récemment fait remarquer que je pouvais encore l’optimiser, et surtout que la méthode de placer le script dans `/etc/network/if-pre-up.d/iptables n’était pas optimale. Comment s’assurer que les règles soient appliquées avant même la connexion au réseau via le network manager ? Dans init.d ? Autre ?

Merci d’avance, et merci encore pour vos réponses.

#11

Oui, tu pourrais mettre ton script en statique dés le boot, vu qu’aucune de tes règles ne dépend d’une interface autre que lo.
Mais ça marche en pre-up, donc avant que ton interface que tu léves avec le nm soit configurée, donc ça ne changerait rien de le mettre encore plus tôt, je ne vois pas en quoi ça serait plus optimal.

#12

Merci !

Donc placer mon script dans if-pre up convient ? On m’a fait remarquer qu’il ne serait pas appliqué avant la connection au réseau, avant les premiers paquet.

#13

C’est clair:

#14

Oui. Je crois qu’on m’a bien embrouillé. On m’a fait remarquer que c’était le network manager de gnome qui gérais ma connexion, et que if-pre-up.d ne convenait pas.

Du coup, je me suis dit, mince, cette solution ne s’applique qu’avec une connexion manuelle avec ifop etc., pas avec le network-manager-gnome.

#15

Sinon il reste la solution de joué avec systemd et des unit.service placé avant la target network :

https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

Un exemple trouvé rapidement :

https://www.linuxquestions.org/questions/linux-server-73/converting-iptables-sysinit-script-to-systemd-4175592934/

#16

Merci !

J’ai fait pas mal de recherches entre temps et j’ai trouvé plusieurs solutions :

  1. créer un /usr/lib/systemd/system/iptables.service contenant :
    [Unit]
    Description=iptables firewall service
    Before=network.target

[Service]
Type=oneshot
ExecStart=/home/nevermore/iptables start
RemainAfterExit=true
ExecStop=/home/nevermore/iptables stop
StandardOutput=journal

[Install]
WantedBy=multi-user.target

  1. script dans /etc/init.d

  2. if-pre-up malgré tout

  3. variante de if-pre-up : dans /etc/network/interfaces, après wlo1 : pre-up iptables-restore < /etc/iptables_rules (règles le problème des applications multiples)

Selon vous, quelle(s) option(s) sembles les plus appropriés ?

Mais je crois que je me prend la tête pour rien : d’après le man d’interface.
Il semblerait donc qu’avec if-pre-up tout soit bien appliqué avant même la configuration de l’interface.

Aussi, on m’a fait remarquer “et ton nat et mangle ?”. On est bien d’accord que sur une machine non routeur, je laisse tout à accept. le fait qu’une vérification m’indique des paquets en nat, c’est normal et pas un problème niveau sécurité ?

#17

Bah on en sait rien, sans savoir comment tu vois des paquets en nat, en fait.

ACCEPT est trés suffisant par défaut sur ces deux tables.
Tu peux un peu jouer sur le mangle, regarde sur:


dans la section “Règles anti « bordel d’internet »”

#18

On vient de me faire remarquer que :

"Oui, if pre-up va lancer ton script avant la connexion au réseau, si celle-ci est configurée via interface, pas si elle est configurée par le network-manager de gnome.

#19

Si, car même si effectivement network-manager court circuite ifupdown et ne déclenche aucun script pour les interfaces non déclarées dans /etc/network/interfaces, il y a au moins l’interface lo qui est gèrée par ifupdown et qui déclenche automatiquement les scripts if-*up.d .