Re: Exemple d'utilisation d'une IPSet de type hash:net,iface dans iptables [RESOLU]
En effet: si on a une IPSet de type hash:ip,port, il faut utiliser dans la règle iptables, deux flags comme src,dst qui s'interprètent comme suit: src,dst signifie qu'il faut prendre le premier paramètre (ici une adresse IP) en utilisant la Source et le deuxième paramètre (ici un numéro de port) en utilisant la Destination. il s'agit bien d'un ET entre les deux conditions. Je n'ai pas essayé avec une liste de type hash:net,iface car après réflexion, je préfère n'utiliser que des adresses IP, dans mes règles IPTables mais j'imagine qu'une séquence src,src devrait faire l'affaire (si l'IPSet est construite en cohérence). Merci beaucoup, Jean-Michel, pour ton aide. Le mar. 28 nov. 2023 à 02:31, Jean-Michel OLTRA a écrit : > > > Bonjour, > > > Le lundi 27 novembre 2023, Olivier a écrit... > > > > ipset create Foo hash:net,iface > > ipset add Foo 192.168.1.0/24,eth1.101 > > > > iptables -A FORWARD -m set match-set Foo src,XXX > > > > Par quoi remplacer XXX si on veut que la règle s'applique si le paquet > > provient du réseau 192.168.1.0/24 ET/OU de l'interface eth1.101 ? > > As tu essayé src,src ? J'avais des sets bitmap:ip,mac qui fonctionnaient > comme ça. Mais dans ce cas je crois bien que c'est un ET et pas OU. > > -- > jm >
Re: Exemple d'utilisation d'une IPSet de type hash:net,iface dans iptables
Bonjour, Le lundi 27 novembre 2023, Olivier a écrit... > ipset create Foo hash:net,iface > ipset add Foo 192.168.1.0/24,eth1.101 > > iptables -A FORWARD -m set match-set Foo src,XXX > > Par quoi remplacer XXX si on veut que la règle s'applique si le paquet > provient du réseau 192.168.1.0/24 ET/OU de l'interface eth1.101 ? As tu essayé src,src ? J'avais des sets bitmap:ip,mac qui fonctionnaient comme ça. Mais dans ce cas je crois bien que c'est un ET et pas OU. -- jm
Re: Exemple d'utilisation d'une IPSet de type hash:net,iface dans iptables
idem avec une une IPSet de type hash:ip,port Le lun. 27 nov. 2023 à 16:19, Olivier a écrit : > > Hello, > > Comment utiliser (sur Bullseye) une IPSet de type hash:net,iface dans > une règle iptables ? > Avez-vous un exemple ? > > ipset create Foo hash:net,iface > ipset add Foo 192.168.1.0/24,eth1.101 > > iptables -A FORWARD -m set match-set Foo src,XXX > > Par quoi remplacer XXX si on veut que la règle s'applique si le paquet > provient du réseau 192.168.1.0/24 ET/OU de l'interface eth1.101 ? > > La doc mentionne la possibilité d'avoir jusqu'à 6 flags de type src, > dst mais je n'ai pas vu d'exemple de flag correspondant au nom de > l'interface d'entrée. > > Slts
Exemple d'utilisation d'une IPSet de type hash:net,iface dans iptables
Hello, Comment utiliser (sur Bullseye) une IPSet de type hash:net,iface dans une règle iptables ? Avez-vous un exemple ? ipset create Foo hash:net,iface ipset add Foo 192.168.1.0/24,eth1.101 iptables -A FORWARD -m set match-set Foo src,XXX Par quoi remplacer XXX si on veut que la règle s'applique si le paquet provient du réseau 192.168.1.0/24 ET/OU de l'interface eth1.101 ? La doc mentionne la possibilité d'avoir jusqu'à 6 flags de type src, dst mais je n'ai pas vu d'exemple de flag correspondant au nom de l'interface d'entrée. Slts
Re: Trou dans un firewall (iptables nftable)
NoSpam a écrit : > > Le 03/07/2023 à 15:12, BERTRAND Joël a écrit : >> NoSpam a écrit : >>> Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table >>> nat et filter >> D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ? > Tout comme iptables et tcpdump, les paquets sont capturés dès leur > arrivée. sngrep sait lire du pcap. Si tu regardes les trames INVITE tu > ne devrais voir aucune réponse de ton asterisk Effectivement, il n'y a aucune réponse. Merci pour tout, JB
Re: Trou dans un firewall (iptables nftable)
Le 03/07/2023 à 15:12, BERTRAND Joël a écrit : NoSpam a écrit : Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table nat et filter D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ? Tout comme iptables et tcpdump, les paquets sont capturés dès leur arrivée. sngrep sait lire du pcap. Si tu regardes les trames INVITE tu ne devrais voir aucune réponse de ton asterisk
Re: Trou dans un firewall (iptables nftable)
NoSpam a écrit : > Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table > nat et filter D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ? JB
Re: Trou dans un firewall (iptables nftable)
Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table nat et filter Le 03/07/2023 à 15:00, BERTRAND Joël a écrit : Thomas Trupel a écrit : C'est un comportement normal à mes yeux. L'ajout d'une règle avec la target TRACE devrait te confirmer que les paquets sont bloqués par le firewall. J'obtiens ceci : 2023-07-03T14:37:45.868470+02:00 rayleigh kernel: [705875.038988] TRACE: raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868494+02:00 rayleigh kernel: [705875.039009] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868497+02:00 rayleigh kernel: [705875.039019] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868498+02:00 rayleigh kernel: [705875.039035] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795018+02:00 rayleigh kernel: [706686.983258] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795021+02:00 rayleigh kernel: [706686.983268] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795022+02:00 rayleigh kernel: [706686.983282] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:56:40.474426+02:00 rayleigh kernel: [707009.669233] TRACE: raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474447+02:00 rayleigh kernel: [707009.669262] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474452+02:00 rayleigh kernel: [707009.669274] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474454+02:00 rayleigh kernel: [707009.669289] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) Où voit-on que ces paquets sont bloqués ? Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
Thomas Trupel a écrit : > C'est un comportement normal à mes yeux. > > L'ajout d'une règle avec la target TRACE devrait te confirmer que les > paquets sont bloqués par le firewall. J'obtiens ceci : 2023-07-03T14:37:45.868470+02:00 rayleigh kernel: [705875.038988] TRACE: raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868494+02:00 rayleigh kernel: [705875.039009] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868497+02:00 rayleigh kernel: [705875.039019] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868498+02:00 rayleigh kernel: [705875.039035] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795018+02:00 rayleigh kernel: [706686.983258] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795021+02:00 rayleigh kernel: [706686.983268] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795022+02:00 rayleigh kernel: [706686.983282] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:56:40.474426+02:00 rayleigh kernel: [707009.669233] TRACE: raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474447+02:00 rayleigh kernel: [707009.669262] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474452+02:00 rayleigh kernel: [707009.669274] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474454+02:00 rayleigh kernel: [707009.669289] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) Où voit-on que ces paquets sont bloqués ? Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
Thomas Trupel a écrit : > C'est un comportement normal à mes yeux. > > L'ajout d'une règle avec la target TRACE devrait te confirmer que les > paquets sont bloqués par le firewall. Dans le cas de SIP, ils sont tout de même récupérés par sngrep : [ ] 359 INVITE 100@1.1.1.1 100@1.1.1.1 1 64.31.63.27:5166 192.168.15.18:5060 CALL SETUP donc pas si bloqués que cela ;-) Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
C'est un comportement normal à mes yeux. L'ajout d'une règle avec la target TRACE devrait te confirmer que les paquets sont bloqués par le firewall. |Cordialement, Thomas| On 7/3/23 14:14, BERTRAND Joël wrote: C'est même pire que ça ! Si je fais un nmap depuis l'extérieur sur le serveur en question, j'obtiens bien : legendre# nmap 192.168.15.18 Starting Nmap 7.93 (https://nmap.org ) at 2023-07-03 14:09 CEST Nmap scan report for 192.168.15.18 Host is up (0.00078s latency). Not shown: 987 filtered tcp ports (no-response) PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 443/tcp open https 465/tcp closed smtps 587/tcp open submission 993/tcp open imaps 995/tcp open pop3s 2401/tcp closed cvspserver 4443/tcp closed pharos 5222/tcp open xmpp-client 9418/tcp open git MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.01 seconds legendre# ce qui semble correspondre aux ports effectivement ouverts. Mais un tcpdump sur l'interface publique de la machine testée voit bien passer tous les paquets (pas seulement ceux correspondant ax ports ouverts). Idem en UDP : legendre# nmap -sU 192.168.15.18 Starting Nmap 7.93 (https://nmap.org ) at 2023-07-03 14:11 CEST Nmap scan report for 192.168.15.18 Host is up (0.00053s latency). Not shown: 997 open|filtered udp ports (no-response) PORT STATE SERVICE 53/udpopen domain 123/udp open ntp 1/udp closed ndmp MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.81 seconds legendre# Lorsque j'utilisais iptables-legacy, je n'ai jamais observé cela. Par ailleurs, ça n'explique pas que des paquets à destination d'un port fermé aboutissent bien à mon serveur asterisk... Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
C'est même pire que ça ! Si je fais un nmap depuis l'extérieur sur le serveur en question, j'obtiens bien : legendre# nmap 192.168.15.18 Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-03 14:09 CEST Nmap scan report for 192.168.15.18 Host is up (0.00078s latency). Not shown: 987 filtered tcp ports (no-response) PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 443/tcp open https 465/tcp closed smtps 587/tcp open submission 993/tcp open imaps 995/tcp open pop3s 2401/tcp closed cvspserver 4443/tcp closed pharos 5222/tcp open xmpp-client 9418/tcp open git MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.01 seconds legendre# ce qui semble correspondre aux ports effectivement ouverts. Mais un tcpdump sur l'interface publique de la machine testée voit bien passer tous les paquets (pas seulement ceux correspondant ax ports ouverts). Idem en UDP : legendre# nmap -sU 192.168.15.18 Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-03 14:11 CEST Nmap scan report for 192.168.15.18 Host is up (0.00053s latency). Not shown: 997 open|filtered udp ports (no-response) PORT STATE SERVICE 53/udpopen domain 123/udp open ntp 1/udp closed ndmp MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.81 seconds legendre# Lorsque j'utilisais iptables-legacy, je n'ai jamais observé cela. Par ailleurs, ça n'explique pas que des paquets à destination d'un port fermé aboutissent bien à mon serveur asterisk... Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
Bonjour Joël, As-tu essayé d'approfondir l'analyse avec la target TRACE ? |iptables -t raw -A PREROUTING -p udp --dport 5060 -j TRACE Par ailleurs, tcpdump semble indiquer que le serveur reçoit un paquet sur le port TCP/5060 et non UDP/5060. Cordialement, Thomas | On 7/3/23 12:41, BERTRAND Joël wrote: Bonjour à tous, Je suis en train de configurer (péniblement) un serveur asterisk qui est dans un DMZ. Tout le flux entrant sur l'IP publique est naté vers ce serveur, protégé par un firewall iptables et fail2ban. Il s'agit d'iptables et non d'iptables-legacy. Cette machine est connectée à deux réseaux : wan0 d'un côté et lan0 de l'autre. Ce qui m'inquiète : Root rayleigh:[/etc/asterisk] > tcpdump -i wan0 -p port 5060 ... 12:26:54.145136 IP patient.census.internet-measurement.com.38253 > rayleigh.systella.fr.sip: Flags [S], seq 3922597779, win 14600, options [mss 1440], length 0 Là, je ne saisis pas puisque j'ai dans le fichier /var/lib/iptables/active : *filter :INPUT DROP [28:3300] :FORWARD DROP [0:0] :OUTPUT DROP [27:3120] [0:0] -A INPUT -i lo -j ACCEPT [0:0] -A INPUT -i lan0 -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssh -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport smtp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport domain -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport domain -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport http -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport ntp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport https -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssmtp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport submission -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport imaps -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport pop3s -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport openvpn -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport openvpn -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport cvspserver -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport jabber-client -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport git -j ACCEPT [0:0] -A INPUT -i wan0 -p icmp -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport 1 -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport 4443 -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp -s 37.97.65.0/24 -j ACCEPT [0:0] -A INPUT -i wan0 -s ns6-axfr.gandi.net -j ACCEPT [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A INPUT -m state --state INVALID -j DROP [0:0] -A OUTPUT -o lo -j ACCEPT [0:0] -A OUTPUT -o lan0 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ftp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ssh -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport telnet -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport smtp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport whois -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport domain -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport domain -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport gopher -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport nntp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport ntp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp-trap -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp-trap -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport https -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport rtsp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3s -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport openvpn -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1195 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport cvspserver -j ACCEPT [1:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport 3128 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport mysql -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport subversion -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport postgresql -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http-alt -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport git -j ACCEPT [0:0] -A OUTPUT -o wan0 -p icmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp -d 37.97.65.186 --dport 5070 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp -d 37.97.65.0/24 -j ACCEPT [0:0] -A OUTPUT -o wan0 -d ns6-axfr.gandi.net -j ACCEPT [0:0] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A OUTPUT -m state --state INVALID -j DROP La table mangle est utilisée pour la QoS. Comment se fait-il qu'un paquet sur l
Trou dans un firewall (iptables nftable)
Bonjour à tous, Je suis en train de configurer (péniblement) un serveur asterisk qui est dans un DMZ. Tout le flux entrant sur l'IP publique est naté vers ce serveur, protégé par un firewall iptables et fail2ban. Il s'agit d'iptables et non d'iptables-legacy. Cette machine est connectée à deux réseaux : wan0 d'un côté et lan0 de l'autre. Ce qui m'inquiète : Root rayleigh:[/etc/asterisk] > tcpdump -i wan0 -p port 5060 ... 12:26:54.145136 IP patient.census.internet-measurement.com.38253 > rayleigh.systella.fr.sip: Flags [S], seq 3922597779, win 14600, options [mss 1440], length 0 Là, je ne saisis pas puisque j'ai dans le fichier /var/lib/iptables/active : *filter :INPUT DROP [28:3300] :FORWARD DROP [0:0] :OUTPUT DROP [27:3120] [0:0] -A INPUT -i lo -j ACCEPT [0:0] -A INPUT -i lan0 -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssh -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport smtp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport domain -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport domain -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport http -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport ntp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport https -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssmtp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport submission -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport imaps -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport pop3s -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport openvpn -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport openvpn -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport cvspserver -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport jabber-client -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport git -j ACCEPT [0:0] -A INPUT -i wan0 -p icmp -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport 1 -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport 4443 -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp -s 37.97.65.0/24 -j ACCEPT [0:0] -A INPUT -i wan0 -s ns6-axfr.gandi.net -j ACCEPT [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A INPUT -m state --state INVALID -j DROP [0:0] -A OUTPUT -o lo -j ACCEPT [0:0] -A OUTPUT -o lan0 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ftp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ssh -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport telnet -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport smtp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport whois -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport domain -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport domain -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport gopher -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport nntp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport ntp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp-trap -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp-trap -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport https -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport rtsp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3s -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport openvpn -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1195 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport cvspserver -j ACCEPT [1:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport 3128 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport mysql -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport subversion -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport postgresql -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http-alt -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport git -j ACCEPT [0:0] -A OUTPUT -o wan0 -p icmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp -d 37.97.65.186 --dport 5070 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp -d 37.97.65.0/24 -j ACCEPT [0:0] -A OUTPUT -o wan0 -d ns6-axfr.gandi.net -j ACCEPT [0:0] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A OUTPUT -m state --state INVALID -j DROP La table mangle est utilisée pour la QoS. Comment se fait-il qu'un paquet sur le port 5060/UDP puisse être envoyé à mon serveur sans qu'il ne soit jeté ? Il n'y a pas de conntrack-sip chargé... Bien cordialement, JKB
Re: iptables vs iptables-legacy
Le 28/06/2023 à 13:05, Michel Verdier a écrit : Le 28 juin 2023 didier gaumet a écrit : [...] mais de ce que j'avais cru comprendre, il y a des frontends (tables xtables ou tables nft) à des backends (netfilter ou nft). Le backend nft serait une version révisée du backend netfilter, par la même équipe, en s'appuyant sur certaines parties de l'ancien backend netfilter. Si on cherche dans /boot/config*, on trouve des chaînes CONFIG_NETFILTER* et CONFIG_NFT. netfilter c'est le framework de filtrage du kernel, et il est toujours d'actualité. Il supporte nf_tables et/ou xtables (donc ip_tables). nft c'est l'outil userspace pour parmétrer nf_tables. Merci d'avoir clarifié... vu que j'avais compris de travers :-) Donc oui, je croyais -à tort- que la composante nftables en espace noyau était était une évolution de netfilter, s'appuyant dessus mais le remplaçant, alors que, non, comme tu le soulignes, nftables c'est simplement le remplaçant de xtables. pour ceux, comme moi, pour qui un petit schéma bien visuel et coloré favorise une compréhension autrement un peu faible, il y a ça sur Wikipedia ;-) https://upload.wikimedia.org/wikipedia/commons/d/dd/Netfilter-components.svg
Re: iptables vs iptables-legacy
Bonjour, Si j'en crois /usr/share/doc/iptables/README.Debian , il convient de ne pas mélanger sur un même système iptables-nft et iptables-legacy sous peine d'avoir un comportement imprévisible :-( "man iptables-legacy" et man "iprables-nft" fournissent des informations sur les différences entre les 2 outils Bonne lecture , même si ça ne répond pas directement à la question ;-) Cordialement Jacques Le 27/06/2023 à 18:46, BERTRAND Joël a écrit : Bonsoir à tous, J'ai toujours écrit mes firewalls à la main. Aujourd'hui, un script charge au démarrage le contenu de /var/lib/iptables/active au travers de iptables (nf_tables). Or iptables-legacy est toujours disponible. J'avoue avoir un peu de mal à comprendre le lien entre les deux filtres. Root rayleigh:[~] > iptables-legacy -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Root rayleigh:[~] > Root rayleigh:[~] > iptables -L # Warning: iptables-legacy tables present, use iptables-legacy to see them Chain INPUT (policy DROP) target prot opt source destination f2b-recidive tcp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ... Chain f2b-recidive (1 references) target prot opt source destination REJECT all -- subnet.crackbox.io anywhere reject-with icmp-port-unreachable REJECT all -- 193.56.29.178anywhere reject-with icmp-port-unreachable REJECT all -- 147.78.103.120 anywhere reject-with icmp-port-unreachable RETURN all -- anywhere anywhere Root rayleigh:[~] > D'après iptables-legacy, tout est ouvert. D'après iptables, tout est fermé sauf ce qui est explicitement ouvert. La question est simple. Si je change la règle par défaut iptables-legacy -DINPUT DROP, plus rien ne fonctionne. Les deux systèmes sont-ils en série ? Un paquet traverse-t-il d'abord un système de filtre puis l'autre en séquence ? Je n'ai pas trouvé l'information (je dois chercher au mauvais endroit)... Bien cordialement, JB
Re: iptables vs iptables-legacy
Le 28 juin 2023 BERTRAND Joël a écrit : > Je suis un peu flemmard sur les bords. Lorsque j'ai un serveur connecté > à plusieurs réseaux et des VPN avec un firewall de plusieurs centaines > de lignes qui est éprouvé, je ne m'amuse pas à le changer pour le fun et > la beauté du geste. Par ailleurs, la syntaxe iptables fonctionne > toujours pour les nftables (raison pour laquelle on se retrouve avec > iptables-legacy et iptables). Il n'y a donc aucune raison valable à ce > que les deux mécanismes cohabitent. À l'extrême limite, ce genre de > chose est une bidouille interne au noyau et cela devrait être > transparent du point de vue de l'utilisateur. Je ne sais pas comment sont gérées les utilisations conjointes de nf_tables et ip_tables. Mais les 2 sont parcourues, le problème est qu'on ne sait pas vraiment dans quel ordre. Entre autre je crois qu'il y a des chaines supplémentaires en nf_tables et les priorités ne doivent sans doute pas refléter la même chose. C'est sûr qu'il y a un risque à migrer de iptables à nftables mais c'est assez rapide à faire : nftables permet de synthétiser pas mal de choses. Et le gain de nftables en clarté des règles et aussi de rapidité (du moins en utilisant les nouveautés de nftables) est assez important.
Re: iptables vs iptables-legacy
Le 28 juin 2023 didier gaumet a écrit : > Le 28/06/2023 à 08:32, Michel Verdier a écrit : > >> Plutôt qu'une doc redhat (un comble sur cette liste) il faut utiliser la >> source : >> https://wiki.nftables.org/wiki-nftables/index.php/What_is_nftables%3F > > La plupart du temps, tu as raison, c'est mieux de directement se renseigner > sur le site de l'éditeur du logiciel concerné > > Ceci dit, sans polémique aucune, parfois les docs ou les wiki d'autres distros > sont plus détaillées, précises, à jour, etc... que ceux de Debian :-) Archwiki ou ubuntu je veux bien, mais redhat c'est assez souvent en décalage par rapport à debian. Là en l'occurence c'est la bible nftables. > mais de ce que j'avais cru comprendre, il y a des frontends (tables xtables > ou tables nft) à des backends (netfilter ou nft). > Le backend nft serait une version révisée du backend netfilter, par la même > équipe, en s'appuyant sur certaines parties de l'ancien backend netfilter. Si > on cherche dans /boot/config*, on trouve des chaînes CONFIG_NETFILTER* et > CONFIG_NFT. netfilter c'est le framework de filtrage du kernel, et il est toujours d'actualité. Il supporte nf_tables et/ou xtables (donc ip_tables). nft c'est l'outil userspace pour parmétrer nf_tables.
Re: iptables vs iptables-legacy
Le 28/06/2023 à 08:32, Michel Verdier a écrit : Plutôt qu'une doc redhat (un comble sur cette liste) il faut utiliser la source : https://wiki.nftables.org/wiki-nftables/index.php/What_is_nftables%3F La plupart du temps, tu as raison, c'est mieux de directement se renseigner sur le site de l'éditeur du logiciel concerné Ceci dit, sans polémique aucune, parfois les docs ou les wiki d'autres distros sont plus détaillées, précises, à jour, etc... que ceux de Debian :-) Donc dans xtables le x c'est pour ip/ip6/... nftables c'est ça qu'il faut utiliser de nos jours. Et les xtables et nftables ce sont les outils pour utiliser netfilter. Les paquets ne passent que par netfilter. [...] Je suis une vraie truffe en réseaux et en sécurité (donc, à la croisée des chemins, en pare-feux), mais de ce que j'avais cru comprendre, il y a des frontends (tables xtables ou tables nft) à des backends (netfilter ou nft). Le backend nft serait une version révisée du backend netfilter, par la même équipe, en s'appuyant sur certaines parties de l'ancien backend netfilter. Si on cherche dans /boot/config*, on trouve des chaînes CONFIG_NETFILTER* et CONFIG_NFT. Et si tout passait par netfilter, il n'y aurait pas de distingo entre iptables-legacy et iptables-nft vu que ce serait la même chose (des tables iptables attaquant un backend netfilter) Enfin, j'ai peut-être rien pigé, hein :-)
Re: iptables vs iptables-legacy
Michel Verdier a écrit : > Et d'ailleurs pourquoi mixer les outils ? Pourquoi ? Mais parce que fail2ban dans sa configuration par défaut s'est mis à utiliser nftables alors qu'il est tout à fait possible d'utiliser un firewall iptables (xtables) par ailleurs. J'ai d'ailleurs modifié ces scripts pour remplacer iptables par iptables-legacy parce qu'un temps, Debian ne fournissait pas un iptables capable de travailler sur les nftables. Je suis un peu flemmard sur les bords. Lorsque j'ai un serveur connecté à plusieurs réseaux et des VPN avec un firewall de plusieurs centaines de lignes qui est éprouvé, je ne m'amuse pas à le changer pour le fun et la beauté du geste. Par ailleurs, la syntaxe iptables fonctionne toujours pour les nftables (raison pour laquelle on se retrouve avec iptables-legacy et iptables). Il n'y a donc aucune raison valable à ce que les deux mécanismes cohabitent. À l'extrême limite, ce genre de chose est une bidouille interne au noyau et cela devrait être transparent du point de vue de l'utilisateur. JB
Re: iptables vs iptables-legacy
Le 27 juin 2023 BERTRAND Joël a écrit : > NoSpam a écrit : >> Bonsoir >> >> https://developers.redhat.com/blog/2020/08/18/iptables-the-two-variants-and-their-relationship-with-nftables#using_iptables_nft > > Merci. > > Mais ça ne répond pas trop à ma question sauf s'il faut comprendre > entre les lignes que les paquets passent d'abord par les xtables avant > de passer par les nftables. Plutôt qu'une doc redhat (un comble sur cette liste) il faut utiliser la source : https://wiki.nftables.org/wiki-nftables/index.php/What_is_nftables%3F Donc dans xtables le x c'est pour ip/ip6/... nftables c'est ça qu'il faut utiliser de nos jours. Et les xtables et nftables ce sont les outils pour utiliser netfilter. Les paquets ne passent que par netfilter. Et il vaut mieux ne pas mixer les outils : https://unix.stackexchange.com/questions/687857/what-is-the-relationship-or-difference-among-iptables-xtables-iptables-nft-xt Et d'ailleurs pourquoi mixer les outils ?
Re: iptables vs iptables-legacy
C' est ce que j' ai compris -- Daniel Huhardeaux Le 27 juin 2023 à 20:52, à 20:52, "BERTRAND Joël" a écrit: >NoSpam a écrit : >> Bonsoir >> >> >https://developers.redhat.com/blog/2020/08/18/iptables-the-two-variants-and-their-relationship-with-nftables#using_iptables_nft > > Merci. > > Mais ça ne répond pas trop à ma question sauf s'il faut comprendre >entre les lignes que les paquets passent d'abord par les xtables avant >de passer par les nftables.
Re: iptables vs iptables-legacy
NoSpam a écrit : > Bonsoir > > https://developers.redhat.com/blog/2020/08/18/iptables-the-two-variants-and-their-relationship-with-nftables#using_iptables_nft Merci. Mais ça ne répond pas trop à ma question sauf s'il faut comprendre entre les lignes que les paquets passent d'abord par les xtables avant de passer par les nftables.
Re: iptables vs iptables-legacy
Bonsoir https://developers.redhat.com/blog/2020/08/18/iptables-the-two-variants-and-their-relationship-with-nftables#using_iptables_nft peut aider à comprendre. Perso j'ai basculer sur nftables. Le 27/06/2023 à 18:46, BERTRAND Joël a écrit : Bonsoir à tous, J'ai toujours écrit mes firewalls à la main. Aujourd'hui, un script charge au démarrage le contenu de /var/lib/iptables/active au travers de iptables (nf_tables). Or iptables-legacy est toujours disponible. J'avoue avoir un peu de mal à comprendre le lien entre les deux filtres. Root rayleigh:[~] > iptables-legacy -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Root rayleigh:[~] > Root rayleigh:[~] > iptables -L # Warning: iptables-legacy tables present, use iptables-legacy to see them Chain INPUT (policy DROP) target prot opt source destination f2b-recidive tcp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ... Chain f2b-recidive (1 references) target prot opt source destination REJECT all -- subnet.crackbox.io anywhere reject-with icmp-port-unreachable REJECT all -- 193.56.29.178anywhere reject-with icmp-port-unreachable REJECT all -- 147.78.103.120 anywhere reject-with icmp-port-unreachable RETURN all -- anywhere anywhere Root rayleigh:[~] > D'après iptables-legacy, tout est ouvert. D'après iptables, tout est fermé sauf ce qui est explicitement ouvert. La question est simple. Si je change la règle par défaut iptables-legacy -DINPUT DROP, plus rien ne fonctionne. Les deux systèmes sont-ils en série ? Un paquet traverse-t-il d'abord un système de filtre puis l'autre en séquence ? Je n'ai pas trouvé l'information (je dois chercher au mauvais endroit)... Bien cordialement, JB
iptables vs iptables-legacy
Bonsoir à tous, J'ai toujours écrit mes firewalls à la main. Aujourd'hui, un script charge au démarrage le contenu de /var/lib/iptables/active au travers de iptables (nf_tables). Or iptables-legacy est toujours disponible. J'avoue avoir un peu de mal à comprendre le lien entre les deux filtres. Root rayleigh:[~] > iptables-legacy -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Root rayleigh:[~] > Root rayleigh:[~] > iptables -L # Warning: iptables-legacy tables present, use iptables-legacy to see them Chain INPUT (policy DROP) target prot opt source destination f2b-recidive tcp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ... Chain f2b-recidive (1 references) target prot opt source destination REJECT all -- subnet.crackbox.io anywhere reject-with icmp-port-unreachable REJECT all -- 193.56.29.178anywhere reject-with icmp-port-unreachable REJECT all -- 147.78.103.120 anywhere reject-with icmp-port-unreachable RETURN all -- anywhere anywhere Root rayleigh:[~] > D'après iptables-legacy, tout est ouvert. D'après iptables, tout est fermé sauf ce qui est explicitement ouvert. La question est simple. Si je change la règle par défaut iptables-legacy -DINPUT DROP, plus rien ne fonctionne. Les deux systèmes sont-ils en série ? Un paquet traverse-t-il d'abord un système de filtre puis l'autre en séquence ? Je n'ai pas trouvé l'information (je dois chercher au mauvais endroit)... Bien cordialement, JB
Re: Re : Re: Formation iptables / netfilter
Bonsoir, iptables-translate permet de générer les règles au format iptables https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables Le 23/11/2022 à 19:51, Hugues Larrive a écrit : --- Original Message --- Le mercredi 23 novembre 2022 à 18:58, Frederic Zulian a écrit : Les 2 PDF de préparation sont succincts, mais très clair. Si la présentation pouvait être mis en ligne cela serait un véritable +. Parce que tout le monde n'habite pas l'Île-de-France :-( Je suis également intéressé mais trop loin (600 Km). Il est vrai que la documentation sur nftables est encore rare sur le web malgré 8 ans d'existence ce qui nuit grandement à l'abandon de la couche de compatibilité iptables. Donc la mise en ligne d'une présentation en français sur le sujet serait évidemment bienvenue. Hugues LARRIVE Frédéric ZULIAN Le mer. 23 nov. 2022 à 14:57, ajh-valmer a écrit : Une information d'un atelier iptables / netfilter le samedi 3 décembre, en île de France proche Paris par une association du Libre : http://www.agendadulibre.org/events/26305 On Wednesday 23 November 2022 13:32:26 NoSpam wrote : Pour information, iptables a été abandonné au profit de nftables Encore de ta part un mail erroné, tu ne lis pas le texte, Voici ce qui est écrit sur la présentation de la formation : "Nftables, ayant pour ambition de remplacer Iptables, est aussi censé remplacer certaines parties de Netfilter, tout en les conservant et en les réutilisant". Si l'atelier est indiqué "iptables / netfilter", c'est parce que des personnes ne connaissent pas encore Nftables, le remplaçant d'iptables.
Re : Re: Formation iptables / netfilter
--- Original Message --- Le mercredi 23 novembre 2022 à 18:58, Frederic Zulian a écrit : > Les 2 PDF de préparation sont succincts, mais très clair. Si la présentation > pouvait être mis en ligne > cela serait un véritable +. > > Parce que tout le monde n'habite pas l'Île-de-France :-( > Je suis également intéressé mais trop loin (600 Km). Il est vrai que la documentation sur nftables est encore rare sur le web malgré 8 ans d'existence ce qui nuit grandement à l'abandon de la couche de compatibilité iptables. Donc la mise en ligne d'une présentation en français sur le sujet serait évidemment bienvenue. Hugues LARRIVE > Frédéric ZULIAN > > Le mer. 23 nov. 2022 à 14:57, ajh-valmer a écrit : > > > > > Une information d'un atelier iptables / netfilter le samedi 3 décembre, > > > > en île de France proche Paris par une association du Libre : > > > > http://www.agendadulibre.org/events/26305 > > > > On Wednesday 23 November 2022 13:32:26 NoSpam wrote : > > > Pour information, iptables a été abandonné au profit de nftables > > > > Encore de ta part un mail erroné, tu ne lis pas le texte, > > > > Voici ce qui est écrit sur la présentation de la formation : > > "Nftables, ayant pour ambition de remplacer Iptables, est aussi censé > > remplacer > > certaines parties de Netfilter, tout en les conservant et en les > > réutilisant". > > > > Si l'atelier est indiqué "iptables / netfilter", > > c'est parce que des personnes ne connaissent pas encore Nftables, > > le remplaçant d'iptables. publickey - hlarrive@pm.me - 0xE9429B87.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Formation iptables / netfilter
Les 2 PDF de préparation sont succincts, mais très clair. Si la présentation pouvait être mis en ligne cela serait un véritable +. Parce que tout le monde n'habite pas l'Île-de-France :-( Frédéric ZULIAN Le mer. 23 nov. 2022 à 14:57, ajh-valmer a écrit : > > > Une information d'un atelier iptables / netfilter le samedi 3 décembre, > > > en île de France proche Paris par une association du Libre : > > > http://www.agendadulibre.org/events/26305 > > On Wednesday 23 November 2022 13:32:26 NoSpam wrote : > > Pour information, iptables a été abandonné au profit de nftables > > Encore de ta part un mail erroné, tu ne lis pas le texte, > > Voici ce qui est écrit sur la présentation de la formation : > "Nftables, ayant pour ambition de remplacer Iptables, est aussi censé > remplacer > certaines parties de Netfilter, tout en les conservant et en les > réutilisant". > > Si l'atelier est indiqué "iptables / netfilter", > c'est parce que des personnes ne connaissent pas encore Nftables, > le remplaçant d'iptables. > >
Re: Formation iptables / netfilter
> > Une information d'un atelier iptables / netfilter le samedi 3 décembre, > > en île de France proche Paris par une association du Libre : > > http://www.agendadulibre.org/events/26305 On Wednesday 23 November 2022 13:32:26 NoSpam wrote : > Pour information, iptables a été abandonné au profit de nftables Encore de ta part un mail erroné, tu ne lis pas le texte, Voici ce qui est écrit sur la présentation de la formation : "Nftables, ayant pour ambition de remplacer Iptables, est aussi censé remplacer certaines parties de Netfilter, tout en les conservant et en les réutilisant". Si l'atelier est indiqué "iptables / netfilter", c'est parce que des personnes ne connaissent pas encore Nftables, le remplaçant d'iptables.
Re: Formation iptables / netfilter
Bonjour Le 23/11/2022 à 11:14, ajh-valmer a écrit : Hello, Une information d'un atelier iptables / netfilter le samedi 3 décembre, en île de France proche Paris par une association du Libre : http://www.agendadulibre.org/events/26305 Pour information, iptables a été abandonné au profit de nftables
Formation iptables / netfilter
Hello, Une information d'un atelier iptables / netfilter le samedi 3 décembre, en île de France proche Paris par une association du Libre : http://www.agendadulibre.org/events/26305 Bonne journée.
Re: Firewall iptables qui ne bloque pas le port 53
- Mail original - > De: "JUPIN Alain" > À: "Liste Debian" > Envoyé: Jeudi 21 Avril 2022 09:26:49 > Objet: Firewall iptables qui ne bloque pas le port 53 > Bonjour, > Je vous soumet un petit problème ... sur une install Debian 11, j'ai > installé pi-hole (pour bloquer les pubs) > Pihole fonctionne, mais (il y a toujours un mais), je cherche a > bloquer son usage que pour quelques IP (vu qu'il est sur une IP > publique). > Voici donc les règles de mon firewall > # Politique par defaut > iptables -t filter -P INPUT DROP > iptables -t filter -P FORWARD DROP > iptables -t filter -P OUTPUT ACCEPT > ip6tables -t filter -P INPUT DROP > ip6tables -t filter -P FORWARD DROP > ip6tables -t filter -P OUTPUT ACCEPT > # Autoriser le Loopback > iptables -t filter -A INPUT -i lo -j ACCEPT > iptables -t filter -A OUTPUT -o lo -j ACCEPT > ip6tables -t filter -A INPUT -i lo -j ACCEPT > ip6tables -t filter -A OUTPUT -o lo -j ACCEPT > ### > # INBOUND TRAFIC # > ### > # On accepte les paquets déjà établis > iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > # PING (ICMP) > iptables -A INPUT -p icmp -j ACCEPT > ip6tables -A INPUT -p ipv6-icmp -j ACCEPT > # SSH > iptables -A INPUT -p tcp --dport 22 -j ACCEPT > ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT > # DNS > iptables -A INPUT -p tcp -s monIPv4 --dport 53 -j ACCEPT > iptables -A INPUT -p udp -s monIPv4 --dport 53 -j ACCEPT > ip6tables -A INPUT -p tcp -s monIPv6 --dport 53 -j ACCEPT > ip6tables -A INPUT -p udp -s monIPv6 --dport 53 -j ACCEPT > # HTTP(S) > iptables -A INPUT -p tcp --dport 80 -j ACCEPT > ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT > iptables -A INPUT -p tcp --dport 443 -j ACCEPT > ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT > # On bloque tout le reste > iptables -A INPUT -p tcp -j DROP > ip6tables -A INPUT -p tcp -j DROP > iptables -A INPUT -p udp -j DROP > ip6tables -A INPUT -p udp -j DROP > Le problème est que même activé, le port 53 n'est pas "bloqué" et > tout le monde peut accéder à mon pi-hole ! > J'ai ajouté les 4 dernière lignes, mais sans effet ! > Bref, je dois bien passer a coté de quelques choses mais je ne vois > pas quoi ! > Merci d'avance pour votre aide. > -- > Alain JUPIN Bonjour Alain, Pour ton problème de port DNS, je t'invite à simplement consulter les pages sur le site du sieur Bortzmeyer et tu trouveras ton bonheur... Et je n'ai pas compris la raison pour laquelle tu souhaites bloquer ce port, la seule chose intelligente serait de rediriger le trafic tcp 53 sur la partie udp 53 et de consulter la doc pour DNSSEC Merci pour ton aimable attention Bien à toi Bernard
Firewall iptables qui ne bloque pas le port 53
Bonjour, Je vous soumet un petit problème ... sur une install Debian 11, j'ai installé pi-hole (pour bloquer les pubs) Pihole fonctionne, mais (il y a toujours un mais), je cherche a bloquer son usage que pour quelques IP (vu qu'il est sur une IP publique). Voici donc les règles de mon firewall # Politique par defaut iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP iptables -t filter -P OUTPUT ACCEPT ip6tables -t filter -P INPUT DROP ip6tables -t filter -P FORWARD DROP ip6tables -t filter -P OUTPUT ACCEPT # Autoriser le Loopback iptables -t filter -A INPUT -i lo -j ACCEPT iptables -t filter -A OUTPUT -o lo -j ACCEPT ip6tables -t filter -A INPUT -i lo -j ACCEPT ip6tables -t filter -A OUTPUT -o lo -j ACCEPT ### # INBOUND TRAFIC # ### # On accepte les paquets déjà établis iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # PING (ICMP) iptables -A INPUT -p icmp -j ACCEPT ip6tables -A INPUT -p ipv6-icmp -j ACCEPT # SSH iptables -A INPUT -p tcp --dport 22 -j ACCEPT ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT # DNS iptables -A INPUT -p tcp -s monIPv4 --dport 53 -j ACCEPT iptables -A INPUT -p udp -s monIPv4 --dport 53 -j ACCEPT ip6tables -A INPUT -p tcp -s monIPv6 --dport 53 -j ACCEPT ip6tables -A INPUT -p udp -s monIPv6 --dport 53 -j ACCEPT # HTTP(S) iptables -A INPUT -p tcp --dport 80 -j ACCEPT ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT # On bloque tout le reste iptables -A INPUT -p tcp -j DROP ip6tables -A INPUT -p tcp -j DROP iptables -A INPUT -p udp -j DROP ip6tables -A INPUT -p udp -j DROP Le problème est que même activé, le port 53 n'est pas "bloqué" et tout le monde peut accéder à mon pi-hole ! J'ai ajouté les 4 dernière lignes, mais sans effet ! Bref, je dois bien passer a coté de quelques choses mais je ne vois pas quoi ! Merci d'avance pour votre aide. -- Alain JUPIN
Re: [HS] iptables et fork tail syslog
Bonsoir, Ceci semble fonctionner : #!/bin/bash export DISPLAY=':0' /usr/bin/gnome-terminal -- tail -f /var/log/syslog En l'exécutant dans un script en crontab, j'ai bien eu nouveau terminal affichant le résultat du tail. Charles. Le 05/05/2021 à 10:55, David Martin a écrit : Bonjour, Je cherche le moyen de lancer un truc du genre à la fin de mon script iptables, mais ça ne veux pas. gnome-terminal -e 'tail -f /var/log/syslog' & L'un de vous à une idée ou une autre solution pour ouvrir un terminal après le passage des règles ? -- david martin
Re: [HS] iptables et fork tail syslog
>Avec tmux je fais un truc dans le genre pour mettre a jour les aliases
> >postfix:
>
> ># split with 10 lines
> >test -n "$TMUX_PANE" && tmux split-window -l 10 ssh "root@${SERV}" tail
> -f /var/log/messages /var/log/maillog
> ># update postfix aliases
> >ssh "root@${SERV}" "postalias $FILE && echo DONE"
>
> >Si ca t'inspire :)
>
> >amicalement
> >patrick
>
> Merci patrick
Mais non ;-)
Je vais chercher.
--
david martin
Re: [HS] iptables et fork tail syslog
L'intérêt est de lancer un terminal après et non avant, et d'avoir un terminal qui s'ouvre sur mon tail ! Que ce soit pour des logs applicatifs ou iptables c'est l'idée. Le mer. 5 mai 2021 à 12:05, Bernard Schoenacker a écrit : > > - Mail original - > > > De: "David Martin" > > À: "debian-user-french@lists.debian.org French" > > > > Envoyé: Mercredi 5 Mai 2021 10:55:36 > > Objet: [HS] iptables et fork tail syslog > > > Bonjour, > > > Je cherche le moyen de lancer un truc du genre à la fin de mon script > > iptables, mais ça ne veux pas. > > > gnome-terminal -e 'tail -f /var/log/syslog' & > > > L'un de vous à une idée ou une autre solution pour ouvrir un terminal > > après le passage des règles ? > > > -- > > > david martin > > Bonjour David, > > je n'(ai pas du tout compris la raison de vouloir lancer > une instruction en même temps que "xterm", de plus je ne > conseille pas du tout d'employer l'extension -f dans tail > avec un fichier journal qui se rempli d'une façon > dynamique, la meilleure solution consiste à lancer cette > instruction : > > tail -10 /var/log/syslog |tee extraction-fichier-syslog-$(date+%c) |most > > > merci et bonne journée > > @+ > Bernard > -- david martin
Re: [HS] iptables et fork tail syslog
Le 05 May 2021 a 12:05:45 +0200, Bernard Schoenacker a écrit :
Bonjour David,
>
> > Bonjour,
>
> > Je cherche le moyen de lancer un truc du genre à la fin de mon script
> > iptables, mais ça ne veux pas.
>
> > gnome-terminal -e 'tail -f /var/log/syslog' &
Avec tmux je fais un truc dans le genre pour mettre a jour les aliases
postfix:
# split with 10 lines
test -n "$TMUX_PANE" && tmux split-window -l 10 ssh "root@${SERV}" tail -f
/var/log/messages /var/log/maillog
# update postfix aliases
ssh "root@${SERV}" "postalias $FILE && echo DONE"
Si ca t'inspire :)
amicalement
patrick
Re: [HS] iptables et fork tail syslog
- Mail original - > De: "David Martin" > À: "debian-user-french@lists.debian.org French" > > Envoyé: Mercredi 5 Mai 2021 10:55:36 > Objet: [HS] iptables et fork tail syslog > Bonjour, > Je cherche le moyen de lancer un truc du genre à la fin de mon script > iptables, mais ça ne veux pas. > gnome-terminal -e 'tail -f /var/log/syslog' & > L'un de vous à une idée ou une autre solution pour ouvrir un terminal > après le passage des règles ? > -- > david martin Bonjour David, je n'(ai pas du tout compris la raison de vouloir lancer une instruction en même temps que "xterm", de plus je ne conseille pas du tout d'employer l'extension -f dans tail avec un fichier journal qui se rempli d'une façon dynamique, la meilleure solution consiste à lancer cette instruction : tail -10 /var/log/syslog |tee extraction-fichier-syslog-$(date+%c) |most merci et bonne journée @+ Bernard
Re: [HS] iptables et fork tail syslog
Bonjour, Le 05/05/2021 à 10:55, David Martin a écrit : > Bonjour, > > Je cherche le moyen de lancer un truc du genre à la fin de mon script > iptables, mais ça ne veux pas. > > gnome-terminal -e 'tail -f /var/log/syslog' & > > L'un de vous à une idée ou une autre solution pour ouvrir un terminal > après le passage des règles ? > -- > david martin Peut-être lancer le script iptables dans le terminal à partir d'un alias qui ajoute à la fin la commande que vous souhaitez lancer : alias commandeiptable='commande_qui_lance_le_script_iptables && tail -f ~/var/log/syslog &' ou un script qui lance le premier script puis la commande tail ? Amicalement, jipege
[HS] iptables et fork tail syslog
Bonjour, Je cherche le moyen de lancer un truc du genre à la fin de mon script iptables, mais ça ne veux pas. gnome-terminal -e 'tail -f /var/log/syslog' & L'un de vous à une idée ou une autre solution pour ouvrir un terminal après le passage des règles ? -- david martin
Re: iptables ou nftables ?
Merci à tous pour les réponses. La réécriture avec nftables m'obligera à repenser mes règles iptables, au fond ce n'est pas plus mal. François
Re: iptables ou nftables ?
>> Comment appréhender la phrase : " Iptables n'est plus qu'une façade ? " >> Je dois crépir ou décrépir mes configurations Iptables ? > Depuis Debian Buster, iptables (+ip6tables+arptables+ebtables) utilise > nftables comme back-end. > C'est le module kernel nftables qui est utilisé pour filtrer ton trafic. > Même si tu utilises iptables. > Cf. https://wiki.debian.org/nftables > > Dans un futur plus ou moins proche, iptables disparaîtra. > > Pour info, iptables et nftables sont tout les deux développés et maintenus > par le projet netfilter (cf. https://www.netfilter.org/). > > Et pour ceux que ça intéresse, la page du wiki indique un lien pour > transformer ses règles iptables vers nftables. > > Il existe aussi un outil en ligne de commande que je n'ai jamais utilisé qui > s'appelle iptables-translate. > > Je rappelle que je ne suis pas un spécialiste. > > Merci de vérifier ces infos et de ne pas les prendre pour argent comptant. Merci de tes explications, je comprend mieux. J'en ai profité pour mettre à jour ma section Nfstables. https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Iptables_vs_nftables
Re: iptables ou nftables ?
Sun, 7 Jun 2020 14:23:20 +0200 G2PC écrivait : > > > nftables est le nouveau standard de contrôle du trafic réseau. > > Sur une Debian Testing, iptables n'est plus qu'une façade pour nftables. > > C'est le cas depuis Debian Buster (stable actuelle). > > Comment appréhender la phrase : " Iptables n'est plus qu'une façade ? " > Je dois crépir ou décrépir mes configurations Iptables ? Depuis Debian Buster, iptables (+ip6tables+arptables+ebtables) utilise nftables comme back-end. C'est le module kernel nftables qui est utilisé pour filtrer ton trafic. Même si tu utilises iptables. Cf. https://wiki.debian.org/nftables Dans un futur plus ou moins proche, iptables disparaîtra. Pour info, iptables et nftables sont tout les deux développés et maintenus par le projet netfilter (cf. https://www.netfilter.org/). Et pour ceux que ça intéresse, la page du wiki indique un lien pour transformer ses règles iptables vers nftables. Il existe aussi un outil en ligne de commande que je n'ai jamais utilisé qui s'appelle iptables-translate. Je rappelle que je ne suis pas un spécialiste. Merci de vérifier ces infos et de ne pas les prendre pour argent comptant. Jean-Marc https://6jf.be/keys/ED863AD1.txt https://6jf.be/keys/ED0B8558.txt pgpeKw6WYc216.pgp Description: PGP signature
Re: iptables ou nftables ?
> nftables est le nouveau standard de contrôle du traffic réseau. > Sur une Debian Testing, iptables n'est plus qu'une façade pour nftables. > C'est le cas depuis Debian Buster (stable actuelle). Comment appréhender la phrase : " Iptables n'est plus qu'une façade ? " Je dois crépir ou décrépir mes configurations Iptables ?
Re: iptables ou nftables ?
Wed, 27 May 2020 18:00:41 +0200 Francois Meyer écrivait : > Bonjour à tous > > Je vois que iptables est "remplacé" par nftables. > > C'est pour un portable de travail sous testing. Mon ancien avait > iptables et toutes les règles qui me vont bien. > > Je n'ai pas tellement envie d'apprendre une nouvelle syntaxe. Ne > ferais-je pas mieux d'installer iptables et de reprendre les mêmes > règles ? ou nftables est-il vraiment préférable ? > > Bonne fin de journée Je viens de parcourir la page https://wiki.debian.org/nftables Et elle indique que l'utilisation de iptables pour de nouvelles install' est découragé. De plus, il existe un outil pour aider au passage à nftables : https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables Jean-Marc https://6jf.be/keys/ED863AD1.txt https://6jf.be/keys/ED0B8558.txt pgpeVO6cHUt4D.pgp Description: PGP signature
Re: iptables ou nftables ?
Wed, 27 May 2020 18:00:41 +0200 Francois Meyer écrivait : > Bonjour à tous Bonjour François, > Je vois que iptables est "remplacé" par nftables. Je vois que ta quetion est restée sans réponse. > C'est pour un portable de travail sous testing. Mon ancien avait > iptables et toutes les règles qui me vont bien. > > Je n'ai pas tellement envie d'apprendre une nouvelle syntaxe. Ne > ferais-je pas mieux d'installer iptables et de reprendre les mêmes > règles ? ou nftables est-il vraiment préférable ? Je ne suis pas du tout un spécialiste mais je vais essayé d'apporter ma contrib' à tes interrogations. nftables est le nouveau standard de contrôle du traffic réseau. Sur une Debian Testing, iptables n'est plus qu'une façade pour nftables. C'est le cas depuis Debian Buster (stable actuelle). Cf. https://wiki.debian.org/nftables De plus, nftables est assez simple à mettre en oeuvre. Perso, je me suis basé sur ces quelques pages de doc pour installer ce qui va bien pour une station de travail : /usr/share/doc/nftables/examples/workstation.nft Malheureusement, ce setting assez basique bloque certains trafics comme le mDNS/SD-DNS. Un exemple plus complet a été repris depuis le wiki de Arch Linux : https://wiki.archlinux.org/index.php/Nftables > Bonne fin de journée Bonne journée à toi aussi. Jean-Marc https://6jf.be/keys/ED863AD1.txt https://6jf.be/keys/ED0B8558.txt P.S. évite de répondre à un mail pour lancer une nouvelle discussion sinon ton mail sera lié à la discussion précédente (cf. https://lists.debian.org/debian-user-french/2020/05/threads.html) pgpV7oKIrO2Wl.pgp Description: PGP signature
Recherche de fainéant pour recommander Iptables / Netfilter au SILL
Recherche de fainéant pour recommander Iptables / Netfilter au SILL ( Fainéant / Référent ) J'ai testé le dépôt du SILL hier, pour une recherche sur Iptables / Firewall / pare-feu, car je cherchais un outil d'analyse de log, et, je n'ai rien trouvé. J'ai constaté que une seule réponse est retournée. J'ai envoyé un mail pour demander si il était possible de rajouter Iptables, et, suite à la réponse du SILL, j'ai ouvert une issue sur le Github du SILL. Seulement, il faut être un fainéant officiel, pour être reconnu, et, être en droit d'être référent d'un logiciel libre proposé. Moi, étant un fainéant chômeur et handicapé, je n'ai pas la liberté pour être référent. Vous pouvez passer le mot aux fainéants. https://github.com/DISIC/sill/issues/114 Merci.
iptables ou nftables ?
Bonjour à tous Je vois que iptables est "remplacé" par nftables. C'est pour un portable de travail sous testing. Mon ancien avait iptables et toutes les règles qui me vont bien. Je n'ai pas tellement envie d'apprendre une nouvelle syntaxe. Ne ferais-je pas mieux d'installer iptables et de reprendre les mêmes règles ? ou nftables est-il vraiment préférable ? Bonne fin de journée
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 10/10/2019 à 19:58, G2PC a écrit : Voilà, cette partie a été traitée. J'ai également remplacé : -A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT par -A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,NEW -j ACCEPT Donc tu as supprimé RELATED de la liste des états autorisés. J'espère que c'est cohérent. C'est cohérent si tu n'utilises pas le suivi de connexion FTP pour ces connexions de données passives. Si tu l'utilises, le premier paquet de ces connexions sera classé dans l'état RELATED et ne pourra être accepté par cette règle. Il faudra donc une autre règle spécifique pour accepter ce premier paquet, sinon la connexion échouera.
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Voilà, cette partie a été traitée. J'ai également remplacé : -A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT par -A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,NEW -j ACCEPT J'espère que c'est cohérent. Le script actuel : https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_pour_configurer_Iptables_filter Merci. > > Si on parle d'une machine exposée sur Internet comme ton VPS OVH, tu > n'as pas besoin du multicast. Cette techno n'a jamais pris sur > Internet. Si tu reçois du multicast sur l'interface, c'est du bruit de > fond local correspondant à des protocoles d'annonces de services mals > configurés sur les VPS voisins ou des besoins spécifiques à OVH (FHRP > par exemple). > > L'IGMP est un protocole permettant à une machine de s'abonner à un > flux multicast routé. Donc si pas de multicast sur Internet, pas > besoin d'IGMP > > Pour reprendre les propos de Pascal et Daniel, comme tu n'en pas pas > besoin, autant le bloquer mais sans pour autant créer des règles > dédiées. Personnellement, je trouve qu'un DROP par défaut de tout en > fin de chaîne (ou en action par défaut) va très bien et évite de > surcharger inutilement les règles. > > Pour l'IPv6, le jour où tu le déploieras, en effet, comme l'a rappelé > Pascal, il faut faire attention à bien autoriser le protocole NDP qui > reprend, entre autre, le rôle d'ARP en IPv4 et qui s'appuie sur de > l'ICMPv6. Autant en IPv4 tu ne peux pas bloquer l'ARP avec iptables, > autant en IPv6 c'est assez facile de se couper les pattes en bloquant > NDP ou plutôt en oubliant de l'autoriser > NDP repose sur des paquets ICMPv6 échangés localement en multicast > certes, mais surtout des paquets ICMPv6 particuliers. > Personnellement, je n'autorise pas le multicast sur mes règles > ip6tables mais uniquement les paquets ICMPv6 dont les caractéristiques > concordent précisément avec les paquets attendus (adresses fe80::, HL > = 255, types & codes qui vont bien, etc...). > > Enfin, petit point si je puis me permettre : > > # Permettre à une connexion ouverte de recevoir du trafic en entrée. > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT > > Personnellement, j'aurais fait comme cela : > -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT > > -A INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT > > Autoriser RELATED sans restriction est une mauvaise habitude de > beaucoup de docs en ligne et la source de problèmes de sécurité > importants même si depuis la version 4.7 du kernel les helpers ne sont > plus activés par défaut pour éviter ce problème. En revanche, c'est > mieux de le laisser autoriser pour l'ICMP. > > De plus, il faudra activer le helper FTP pour ton serveur FTP. Une doc > ici sur le sujet : > https://gist.github.com/azlux/6a70bd38bb7c525ab26efe7e3a7ea8ac. Cela > te permettra en plus de fermer le port TCP/20
Re: Script Iptables pour serveur web Apache2 MySQL ProFTPD avec Port Knocking pour SSH
Le 25/09/2019 à 14:14, G2PC a écrit : # J'enlève la valeur SYN et l'accès web et terminal fonctionne correctement. -A PREROUTING -p tcp -m multiport --dports 22,80,443 -m tcp --tcp-flags FIN,RST,ACK SYN -j CT --notrack Cette règle n'a aucune chance de s'appliquer puisque la combinaison masque/drapeaux est impossible. Tu testes un drapeau qui n'est pas dans le masque, ça ne peut pas marcher. Hum. Bon, je te crois, je commente donc cette règle, le temps d'avoir plus d'informations sur raw et les règles conseillées. Est ce que le masque avec le SYN (que j'ai retiré) " FIN,SYN,RST,ACK SYN " est plus cohérente que " FIN,RST,ACK SYN " ? Bien sûr. C'est de l'algèbre booléenne de base. La seconde liste de --tcp-flags doit être incluse dans la première liste. "FIN,RST,ACK SYN" signifie "conserver les valeurs des drapeaux FIN, RST et ACK et mettre à 0 les autres (dont SYN), puis renvoyer vrai si dans le résultat SYN=1 (ce qui est impossible) et tous les autres à 0". Comme dit, avec le SYN en deuxième position, les accès sont coupés une fois que je place la règle *filter L'état UNTRACKED doit interférer soit avec le filtrage en entrée, soit avec le filtrage en sortie. Si un paquet SYN a été classé UNTRACKED, alors les paquets suivants de la poignée de main (SYN+ACK sortant et ACK entrant) sont classés par défaut dans l'état INVALID. # Je ne sais pas si il est nécessaire d'autoriser le loopback vers l'extérieur, voir à trouver un exemple. Cette phrase n'a aucun sens puisque le trafic envoyé sur l'interface de loopback ne va pas vers l'extérieur mais revient. Tu parles de mon commentaire concernant la règle OUTPUT qui n'a pas de sens, dès lors ? Je parle de la phrase ci-dessus que j'ai laissée. -A OUTPUT -m conntrack ! --ctstate INVALID -j ACCEPT Typiquement, le paquet de réponse SYN/ACK à un paquet SYN dans l'état UNTRACKED (à cause de -j CT --notrack) serait classé par défaut dans l'état INVALID. Je ne connais pas l'interaction éventuelle avec SYNPROXY. Je ne sais pas comment appréhender ce retour. Le -j CT --notrack est dans la ligne qui a été désactivée dans la table *raw A suivre. Tu pourrais accepter les paquets SYN+ACK sortants ayant un des ports source concernés par le SYNPROXY. # Autoriser les connexions DNS. -A INPUT -p tcp --dport 53 -j ACCEPT La machine fait serveur DNS pour l'extérieur ? Je ne pense pas ? C'est à dire, est ce qu'elle transmet des informations vers un autre service extérieur ? C'est-à-dire qu'elle répond à des requêtes DNS. Hormis les pages web, non, donc, si je t'entend bien, je peux supprimer les règles DNS ? Il vaut mieux ne pas supprimer les règles qui acceptent les requêtes DNS en sortie. Qu'est-ce que la connexion fstp ? Oups ! sFTP Ça utilise SSH, donc rien à voir avec le protocole FTP. -A OUTPUT -p tcp --sport 21 -m state --state ESTABLISHED -j LOG_ACCEPT -A OUTPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED -j LOG_ACCEPT Inutiles puisque ces paquets ont déjà été acceptés par la règle générique qui autorise les connexions déjà établies. De toute façon, serait-il vraiment nécessaire de loguer ces paquets ? ça fait beaucoup de paquets à loguer ? Ça loguerait tous les paquets sortants des connexions de commande et de données FTP, soit grosso modo un paquet par commande FTP et un paquet par bloc de 1400 octets de données de fichier téléchargé ou de contenu de répertoire lu. Je ne vois pas l'intérêt, loguer le premier paquet suffit. Le client me dit ceci, on observe que j'arrive bien à me connecter la première fois, puis, sur un second compte il n'arrive pas à récupérer le contenu du dossier. Je me reconnecte au second compte, et, il arrive alors a récupérer le contenu du dossier. Vraiment étrange. Statut : Connexion à 139.99.173.195:21... Statut : Connexion établie, attente du message d'accueil... Statut : Initialisation de TLS... Statut : Vérification du certificat... Statut : Connexion TLS établie. Note : si tu utilises TLS avec FTP, alors le module de suivi de connection nf_conntrack mentionné dans mon message précédent est aveugle et inutile. Statut : Récupération du contenu du dossier... Commande : PWD Réponse : 257 "/" est le répertoire courant Commande : TYPE I Réponse : 200 Type paramétré à I Commande : PASV Réponse : 227 Entering Passive Mode (139,99,173,195,202,139). Commande : LIST Erreur : Connection interrompue après 20 secondes d'inactivité Il faudrait vérifier le port source utilisé par le client pour la connexion de données servant au listage. Attention : si le client est derrière un dispositif NAT (routeur, box), ce dernier peut modifier le port source à la volée. Regarde dans les logs générés par iptables. -A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j LOG_ACCEPT -A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISH
Re: Script Iptables pour serveur web Apache2 MySQL ProFTPD avec Port Knocking pour SSH
K à un paquet SYN dans l'état > UNTRACKED (à cause de -j CT --notrack) serait classé par défaut dans > l'état INVALID. Je ne connais pas l'interaction éventuelle avec SYNPROXY. Je ne sais pas comment appréhender ce retour. Le -j CT --notrack est dans la ligne qui a été désactivée dans la table *raw A suivre. > >> >> # Autoriser les services web. >> >> # Autoriser les connexions DNS. >> -A INPUT -p tcp --dport 53 -j ACCEPT > > La machine fait serveur DNS pour l'extérieur ? Je ne pense pas ? C'est à dire, est ce qu'elle transmet des informations vers un autre service extérieur ? Hormis les pages web, non, donc, si je t'entend bien, je peux supprimer les règles DNS ? >> -A INPUT -p udp --sport 53 -j ACCEPT > > Cette règle est une faille de sécurité en plus d'être inutile. Ok, je supprime : -A INPUT -p udp --sport 53 -j ACCEPT Si je comprend ton message précédent, je peux commenter toutes les règles concernant le serveur DNS ? >> # Configurer le FTP et le pare-feu pour utiliser la plage de ports >> passifs entre 49152-65534 proposée par IANA. >> # Noter que la connexion de semble pas s'établir à chaque fois et >> qu'il est nécessaire de retenter la connexion. >> # Noter que la connexion fstp n'est pas configurée actuellement. A >> faire ! > > Qu'est-ce que la connexion fstp ? Oups ! sFTP > >> -A OUTPUT -p tcp --sport 21 -m state --state ESTABLISHED -j LOG_ACCEPT >> -A OUTPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state >> --state ESTABLISHED -j LOG_ACCEPT > > Inutiles puisque ces paquets ont déjà été acceptés par la règle > générique qui autorise les connexions déjà établies. > De toute façon, serait-il vraiment nécessaire de loguer ces paquets ? ça fait beaucoup de paquets à loguer ? Dans mon idée, seul le FTP est censé passer par la, mais, je me trompe peut être ? J'ai commenté les deux règles en OUTPUT, j'arrive toujours à me connecter au FTP, c'est très bien. Le client me dit ceci, on observe que j'arrive bien à me connecter la première fois, puis, sur un second compte il n'arrive pas à récupérer le contenu du dossier. Je me reconnecte au second compte, et, il arrive alors a récupérer le contenu du dossier. Vraiment étrange. Statut : Connexion à 139.99.173.195:21... Statut : Connexion établie, attente du message d'accueil... Statut : Initialisation de TLS... Statut : Vérification du certificat... Statut : Connexion TLS établie. Statut : Connecté Statut : Récupération du contenu du dossier... Statut : Contenu du dossier "/" affiché avec succès Statut : Récupération du contenu du dossier "/"... Statut : Contenu du dossier "/" affiché avec succès Statut : Déconnecté du serveur Statut : Connexion à 139.99.173.195:21... Statut : Connexion établie, attente du message d'accueil... Statut : Initialisation de TLS... Statut : Vérification du certificat... Statut : Connexion TLS établie. Statut : Connecté Statut : Récupération du contenu du dossier... Commande : PWD Réponse : 257 "/" est le répertoire courant Commande : TYPE I Réponse : 200 Type paramétré à I Commande : PASV Réponse : 227 Entering Passive Mode (139,99,173,195,202,139). Commande : LIST Erreur : Connection interrompue après 20 secondes d'inactivité Erreur : Impossible de récupérer le contenu du dossier Statut : Déconnecté du serveur >> -A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j >> LOG_ACCEPT >> -A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state >> --state ESTABLISHED,RELATED,NEW -j LOG_ACCEPT > > Côté serveur, tu ne maîtrises pas la plage de ports du client. > Restreindre les ports source du client à la même plage que celle du > serveur est abusif. Pas si sur de bien comprendre, car, j'ai pu lire sur certains tutoriels qu'il faut au contraire ouvrir la plage de port via Iptables. Si je commente la règle -A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,RELATED,NEW -j LOG_ACCEPT , Alors, je n'arrive plus à me connecter au serveur FTP via FileZilla :/ Quoi que ? c'est la récupération du contenu du dossier qui ne se fait pas ! Statut : Connexion à 139.99.173.195:21... Statut : Connexion établie, attente du message d'accueil... Statut : Initialisation de TLS... Statut : Vérification du certificat... Statut : Connexion TLS établie. Statut : Le serveur ne supporte pas les caractères non-ASCII. Statut : Connecté Statut : Récupération du contenu du dossier "/"... Commande : CWD / Réponse : 250 Commande CWD exécutée avec succès Commande : TYPE I Réponse : 200 Type paramétré à I Commande : PASV Réponse : 227 Entering Passive Mode (139,99,173,195,193,218). Commande : LIST Erreur : Connection interrompue après 20 secondes d'in
Re: Script Iptables pour serveur web Apache2 MySQL ProFTPD avec Port Knocking pour SSH
Le 24/09/2019 à 23:46, G2PC a écrit : Par exemple, pour ProFTPD, il me semble avoir configuré correctement le service, mais, le client FileZilla ne semble pas réussir à se connecter lors de toutes ses tentatives. Actuellement, j'arrive régulièrement à me connecter au client FTP, mais, pas à 100%. Je précise, ce n'est pas la connexion qui semble bloquer occasionnellement, mais, la lecture des dossiers une fois connecté, d'après ce que je lis sur FileZilla. Donc les connexions de données avec les ports de destination dynamiques. Est-ce que tu as chargé le module de suivi de connexion FTP nf_conntrack_ftp ? Si oui, est-ce que tu as réglé l'option nf_conntrack_helper du module nf_conntrack à 1 puisque je ne vois pas de règle avec CT --helper pour affecter explicitement le helper ftp aux connexions de commande FTP ? *raw # Anti DDOS. # Les paquets TCP avec le flag SYN à destination des ports 22,80 ou 443 ne seront pas suivi par le connexion tracker et donc traités plus rapidement. ## Les pages ne chargent plus avec cette règle de décommentée tout comme la connexion SSH devient impossible ! En temps normal, ce n'est pas seulement le paquet SYN mais tous les paquets suivants (entrants et sortants) qu'il faut exclure du suivi de connexion et accepter. Par contre j'ai vu que tu utilises SYNPROXY qui interagit avec le suivi de connexion, mais je ne connais pas bien. # J'enlève la valeur SYN et l'accès web et terminal fonctionne correctement. -A PREROUTING -p tcp -m multiport --dports 22,80,443 -m tcp --tcp-flags FIN,RST,ACK SYN -j CT --notrack Cette règle n'a aucune chance de s'appliquer puisque la combinaison masque/drapeaux est impossible. Tu testes un drapeau qui n'est pas dans le masque, ça ne peut pas marcher. # On pourrait interdire le ping avec icmp directement en PREROUTING. # Pour le moment je vais l'interdire par défaut depuis *filter et autoriser le ping aux services OVH. # -A PREROUTING -p icmp -j DROP Erreur fréquente : ICMP, ce n'est pas seulement le ping mais aussi des messages d'erreur qu'il vaut mieux ne pas bloquer si on veut que les communications marchent bien. # Pas de filtrage sur l'interface de loopback. # Le serveur ne doit pas avoir de soucis à communiquer avec lui-même au niveau des services internes. # Accepter toutes les connexions de la machine locale pour permettre aux services de communiquer entre eux. -A INPUT -i lo -j ACCEPT # Par la suite, la règle par défaut va DROP sur tous les OUTPUT non autorisés. # Je ne sais pas si il est nécessaire d'autoriser le loopback vers l'extérieur, voir à trouver un exemple. Cette phrase n'a aucun sens puisque le trafic envoyé sur l'interface de loopback ne va pas vers l'extérieur mais revient. # L'absence d'autorisation en sortie peut t'elle interférer avec certains services attendant une communication en sortie de loopback ? # -A OUTPUT -o lo -j ACCEPT Evidemment ça interfère. Tout paquet envoyé sur l'interface de loopback passe successivement par les chaînes OUTPUT, POSTROUTING, PREROUTING et INPUT et doit être accepté dans toutes pour arriver à destination. -A OUTPUT -m conntrack ! --ctstate INVALID -j ACCEPT Typiquement, le paquet de réponse SYN/ACK à un paquet SYN dans l'état UNTRACKED (à cause de -j CT --notrack) serait classé par défaut dans l'état INVALID. Je ne connais pas l'interaction éventuelle avec SYNPROXY. # Autoriser les services web. # Autoriser les connexions DNS. -A INPUT -p tcp --dport 53 -j ACCEPT La machine fait serveur DNS pour l'extérieur ? -A INPUT -p udp --sport 53 -j ACCEPT Cette règle est une faille de sécurité en plus d'être inutile. # Configurer le FTP et le pare-feu pour utiliser la plage de ports passifs entre 49152-65534 proposée par IANA. # Noter que la connexion de semble pas s'établir à chaque fois et qu'il est nécessaire de retenter la connexion. # Noter que la connexion fstp n'est pas configurée actuellement. A faire ! Qu'est-ce que la connexion fstp ? -A OUTPUT -p tcp --sport 21 -m state --state ESTABLISHED -j LOG_ACCEPT -A OUTPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED -j LOG_ACCEPT Inutiles puisque ces paquets ont déjà été acceptés par la règle générique qui autorise les connexions déjà établies. De toute façon, serait-il vraiment nécessaire de loguer ces paquets ? -A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j LOG_ACCEPT -A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,RELATED,NEW -j LOG_ACCEPT Côté serveur, tu ne maîtrises pas la plage de ports du client. Restreindre les ports source du client à la même plage que celle du serveur est abusif. # Autoriser les connexions au serveur web Apache2. -A INPUT -p tcp --dport 80 -j ACCEPT -A OUTPUT -p tcp --dport 80 -j ACCEPT -A INPUT -p tcp --dport 443 -j ACCEPT -A OUTPUT -p tcp --dport 443 -j ACCEPT Maintenant que ces paquets sont acceptées, toutes les règles suivantes
Script Iptables pour serveur web Apache2 MySQL ProFTPD avec Port Knocking pour SSH
Merci à tous pour vos précédents retours concernant ICMP. J'ai pu avancer, à mon niveau, avec les quelques règles Iptables suivantes. Situation : Serveur VPS OVH - Apache2 MariaDB ProFTPd - Pas de serveur de mail à proprement parler ( Un peu de Exim4 ici et de mutt / mailx par la. ) J'ai tenté de prendre en considérations vos précédents retours, mais, j'ai parfois fait l'impasse, par manque de temps ou de compréhension. Voilà le récapitulatif complet, pour ce que j'ai pu en apprendre et comprendre -> pour le moment <- Vos retours sont les bienvenus pour continuer à améliorer ce script. La bonne nouvelle, c'est que ce script semble fonctionner ! Mes pages web sont délivrées, je peux me connecter à SSH via Port Knocking ! Cela répond à mes premières attentes ! Par contre, il s'y cache peut être des effets de bord, et, certainement, des optimisations à mener. Par exemple, pour ProFTPD, il me semble avoir configuré correctement le service, mais, le client FileZilla ne semble pas réussir à se connecter lors de toutes ses tentatives. Actuellement, j'arrive régulièrement à me connecter au client FTP, mais, pas à 100%. Je précise, ce n'est pas la connexion qui semble bloquer occasionnellement, mais, la lecture des dossiers une fois connecté, d'après ce que je lis sur FileZilla. Plus d'informations dans la partie *filter, ou j'ai indiqué la plage de ports que j'ai du ouvrir pour permettre à FileZilla de fonctionner globalement, en utilisant une connexion passive. Je n'en dis pas plus, bonne lecture, et, bonnes critiques ! Règle personnalisée pour configurer Iptables raw # Créer le fichier iptables-firewall-raw.rules et ajouter les règles suivantes. # sudo nano iptables-firewall-raw.rules # Début de la règle raw. *raw # Anti DDOS. # Les paquets TCP avec le flag SYN à destination des ports 22,80 ou 443 ne seront pas suivi par le connexion tracker et donc traités plus rapidement. ## Les pages ne chargent plus avec cette règle de décommentée tout comme la connexion SSH devient impossible ! ## Ce blocage semble apparaître quand j'active les règles de la table raw et filter. ## -A PREROUTING -p tcp -m multiport --dports 22,80,443 -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack # J'enlève la valeur SYN et l'accès web et terminal fonctionne correctement. -A PREROUTING -p tcp -m multiport --dports 22,80,443 -m tcp --tcp-flags FIN,RST,ACK SYN -j CT --notrack # Donc, ici, j'ai eu un blocage web et de ma connexion SSH, quand je laissais la valeur SYN, puis, que j'ajoutais la règle *filter. # Est ce du à un conflit de règle, entre raw et filter ? # J'ai supprimé la valeur SYN, et, maintenant, les pages web et la connexion SSH semble fonctionner correctement, même après l'ajout de la règle *filter. # Maîtrise de charge. # Regrouper les adresses IP sources par bloc de 256 sous réseaux en /24 et n’autoriser qu'un nombre maximum de demandes de connexions SYN par seconde pour chaque sous réseau. # Utiliser le module hashlimit. Permet de mettre un plafond de connexion par seconde vers le serveur par groupe de 256 IP. -A PREROUTING -p tcp -m tcp --syn -m multiport --dports 22,80,443 -m hashlimit --hashlimit-above 200/sec --hashlimit-burst 1000 --hashlimit-mode srcip --hashlimit-name syn --hashlimit-htable-size 2097152 --hashlimit-srcmask 24 -j DROP # Fin de la règle. COMMIT # Importer le script dans Iptables. # sudo iptables-restore < iptables-firewall-raw.rules # Vérifier que les règles aient bien été ajoutées dans la table raw : # sudo iptables -t raw -L Règle personnalisée pour configurer Iptables mangle # Créer le fichier iptables-firewall-mangle.rules et ajouter les règles suivantes. # sudo nano iptables-firewall-mangle.rules # Début de la règle mangle. *mangle # Bloquer la fragmentation TCP : -A PREROUTING -f -j DROP # Paquet avec SYN et FIN à la fois : -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP # Paquet avec SYN et RST à la fois -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP # Paquet avec FIN et RST à la fois -A PREROUTING -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j DROP # Paquet avec FIN mais sans ACK -A PREROUTING -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP # Paquet avec URG mais sans ACK -A PREROUTING -p tcp -m tcp --tcp-flags ACK,URG URG -j DROP # Paquet avec PSH mais sans ACK -A PREROUTING -p tcp -m tcp --tcp-flags PSH,ACK PSH -j DROP # Paquet avec tous les flags à 1 <=> XMAS scan dans Nmap -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP # Paquet avec tous les flags à 0 <=> Null scan dans Nmap -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP # Paquet avec FIN,PSH, et URG mais sans SYN, RST ou ACK -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP # Paquet avec FIN,SYN,PSH,URG mais sans ACK ou RST -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j D
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 24/09/2019 à 18:36, Daniel Caillibaud a écrit : Le 24/09/19 à 17:27, Daniel Huhardeaux a écrit : Modifier le port de connexion de services connus comme ssh + identification par clé suffit pour ne pas avoir à rajouter une couche. En quoi changer le port améliorerait la sécurité ? Modifie le port ssh et tu verras la diminution drastique des tentatives (iptables log les connexions vers mes ports exotiques). Personnellement, en dehors des ports réputés figés, aucun service ne tourne sur les ports traditionnels. C'est peut-être du "sentiment de sécurité" mais ça ne sécurise rien du tout (et à priori plutôt l'inverse, un faux sentiment de sécurité est pas très bon, ça peut conduire à qq négligences). Une connexion avec clé me parait sécurisé. Ne serait ce qu'un sentiment ? ;) Le scan de ports c'est tout le temps et ça se voit pas dans les logs, un port déplacé ne protège de rien du tout (ok, pour le ssh ça peut limiter les messages dans le auth.log, mais y'a d'autres moyens pour ça ;-)). Les "méchants" ne s'embêtent pas ou peu à scanner: ils ont assez de boulot avec les ports traditionnels. J'utilise au bureau une UTM qui hebdomadairement remonte les statistiques. Ex pour la semaine passée: Les 10 principaux services abandonnés Nombre total de paquets abandonnés : 102 578 Principal Nom du service Protocole Service Paquets % 1 TELNET TCP 23 5 8695.72 % 2 T9C0 ICMP t9c03 6893.60 % 3 MICROSOFT-DS TCP 445 2 3202.26 % 4 SSHTCP 22 1 4021.37 % 5 T11C1 ICMP t11c1 1 0961.07 % 6 HTTP TCP 80 1 0231.00 % 7 PERSONAL-AGENT TCP 998 0.97 % 8 SIPUDP 5060887 0.86 % 9 HTTP-ALT TCP 8080882 0.86 % 10DOMAIN UDP 53 815 0.79 % Et pour moi le port 22 du ssh est un port "figé", comme le 80/443 pour le web, le 53 pour le dns, 25/487 pour le mail… et c'est valable pour tous les ports ouverts sur mes ip publiques. Je ne vois rien de cela dans mes logs Que le 80,443,53,25,487 (liste non exhaustive) soient ouverts me parait normal. C'est ce que j'ai appelé les ports figés. Je comprends qu'on mette un service "privé" sur une ip publique par commodité, mais dans ce cas faut assumer et gérer sa sécurité, le mettre sur un port exotique ne l'améliorera pas. Je ne parlai pas de service "privé", je parle de service "publique" que l'on peut déplacer. Et j'assume. Ce débat a déjà eu lieu et revient périodiquement. À chacun selon son niveau/besoin/"sentiment"/... de traiter -- Daniel
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 24/09/19 à 17:27, Daniel Huhardeaux a écrit : > Modifier le port de connexion de services connus comme ssh + > identification par clé suffit pour ne pas avoir à rajouter une couche. En quoi changer le port améliorerait la sécurité ? > Personnellement, en dehors des ports réputés figés, aucun service ne > tourne sur les ports traditionnels. C'est peut-être du "sentiment de sécurité" mais ça ne sécurise rien du tout (et à priori plutôt l'inverse, un faux sentiment de sécurité est pas très bon, ça peut conduire à qq négligences). Le scan de ports c'est tout le temps et ça se voit pas dans les logs, un port déplacé ne protège de rien du tout (ok, pour le ssh ça peut limiter les messages dans le auth.log, mais y'a d'autres moyens pour ça ;-)). Et pour moi le port 22 du ssh est un port "figé", comme le 80/443 pour le web, le 53 pour le dns, 25/487 pour le mail… et c'est valable pour tous les ports ouverts sur mes ip publiques. Je comprends qu'on mette un service "privé" sur une ip publique par commodité, mais dans ce cas faut assumer et gérer sa sécurité, le mettre sur un port exotique ne l'améliorera pas. -- Daniel - Aujourd'hui, c'est la chasse à l'ours. Où cours-tu le lapin? Tu ne risques rien! - Eh, t'es con! J'ai pas mes papiers! Coluche
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 24/09/2019 à 12:26, Olivier a écrit :
Le sam. 21 sept. 2019 à 21:42, Daniel Huhardeaux <mailto:no-s...@tootai.net>> a écrit :
Oublie le port knocking.
Daniel
Simple curiosité:
Pourquoi oublier le port knocking ?
Je ne l'ai jamais utilisé mais ça m'avait l'air assez utile
Modifier le port de connexion de services connus comme ssh +
identification par clé suffit pour ne pas avoir à rajouter une couche.
Personnellement, en dehors des ports réputés figés, aucun service ne
tourne sur les ports traditionnels.
Le sam. 21 sept. 2019 à 21:42, Daniel Huhardeaux <mailto:no-s...@tootai.net>> a écrit :
Le 21/09/2019 à 20:18, G2PC a écrit :
> Merci de ce retour, je vais faire des recherches complémentaires,
car,
> même si ta réponse est bien formulée, je décroche un peu.
> Fondamentalement, je veux bien te croire, mais, il va falloir que je
> vérifie, comment faire pour l'activer, et, pour vérifier son
activation.
>
>
> De mon côté, j'ai rajouté le Port Knocking par Iptables, que j'ai
placé
> tout à la fin de mon script, juste au dessus de COMMIT.
> Ça a l'air fonctionnel, mais, j'ai l'impression que ça manque de
> réactivité, et, je me demande si je n'ai pas des règles qui
pourraient
> entrer en conflit, comprendre, se répéter inutilement.
>
> Le script Iptables :
>
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_pour_configurer_Iptables_filter
>
> Le script Port Knocking :
>
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Mise_en_place_du_Port_Knocking
>
>
> J'aimerais bien pouvoir gagner un peu de souplesse, au moment du Port
> Knocking, car, j'ai l'impression que ça pédale dans la choucroute.
> Peut être un problème de perf de serveur, un VPS 1Go, ce serait déjà
> trop light vu que j'ai quelques virtualhosts dessus.
>
> Quoi qu'il en soit, j'ai tenté de me connecter directement en
SSH, et,
> le port knocking semble bien faire le boulot, la connexion n'est pas
> établie.
> Par contre, si je décommente les 2 lignes autorisant le port SSH dans
> mon script principale, le script du Port Knocking ne semble pas
arriver
> à m'ouvrir le port 22.
> J'ai donc une autorisation de SSH port 22 en input et output
depuis mon
> script principale, tout comme j'ai, tout à la fin de ce script
> principale, le script Port Knocking, qui me réautorise le port 22
si les
> frappes aboutissent.
> Je ne suis pas sur que ce soit normal, d'avoir à autoriser le
port SSH,
> puis, à le réauthoriser avec le port knocking.
> Il me semble que le port knocking devrait suffir à gérer
l'ouverture et
> la fermeture du port SSH.
>
> Il faut que je revérifie.
Oublie le port knocking. Change le port d'écoute ssh et tout ira bien.
Si tu veux tout de même encore plus te protéger installe fail2ban.
Encore mieux: ouvre un VPN entre toi et ton serveur.
>
> Le 21/09/2019 à 13:46, Pascal Hambourg a écrit :
>> Le 21/09/2019 à 12:39, G2PC a écrit :
>>>
>>> # Mon serveur ne retrouve pas les deux lignes de configuration
>>> suivantes, que je commente. A SUIVRE !
>>> # sysctl: cannot stat
/proc/sys/net/netfilter/nf_conntrack_tcp_loose:
>>> Aucun fichier ou dossier de ce type
>>> # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max:
Aucun
>>> fichier ou dossier de ce type
>>
>> Ces sysctls n'existent que si le module nf_conntrack_ipv4 ou
>> nf_conntrack_ipv6 est chargé, ce qui est fait automatiquement à la
>> création de la première règle utilisant le suivi de connexion
(state,
>> conntrack, connmark...) ou au chargement de la table nat.
>>
>> Pour pouvoir les initialiser via /etc/sysctl{,.d/*}.conf, il faut
>> charger un de ces modules via /etc/modules{,-load.d/*.conf}.
>>
>
--
Daniel
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 24/09/19 à 12:26, Olivier a écrit : > Pourquoi oublier le port knocking ? Je ne sais pas ce que Daniel (Huhardeaux) voulait dire, mais je suppose qu'il déconseillait ça car ça ne fait que compliquer la configuration ssh (donc amha ça fragilise, plus c'est simple et moins il y a de risque d'erreur de conf qui ouvre une brèche) sans apporter de sécurité supplémentaire. Et amha c'est pareil pour le changement de port. Le plus efficace reste de limiter la connexion ssh aux clés, et de laisser se casser les dents tous ceux qui essaient des mot de passe. J'en vois passer des tonnes, mais c'est pas laisser qq connexions ouvertes sans y répondre qui charge la machine (installer fail2ban a en revanche un coût, faut analyser les logs et ajouter des règles iptables, c'est négligeable mais supérieur à ne rien faire, donc sans intérêt si les ban iptables ne sont pas utilisés pour reporter aux services abuse concernés). -- Daniel À force d'aller au fond des choses, on y reste. Jean Cocteau
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le sam. 21 sept. 2019 à 21:42, Daniel Huhardeaux a
écrit :
>
> Oublie le port knocking.
> Daniel
>
> Simple curiosité:
Pourquoi oublier le port knocking ?
Je ne l'ai jamais utilisé mais ça m'avait l'air assez utile
Le sam. 21 sept. 2019 à 21:42, Daniel Huhardeaux a
écrit :
> Le 21/09/2019 à 20:18, G2PC a écrit :
> > Merci de ce retour, je vais faire des recherches complémentaires, car,
> > même si ta réponse est bien formulée, je décroche un peu.
> > Fondamentalement, je veux bien te croire, mais, il va falloir que je
> > vérifie, comment faire pour l'activer, et, pour vérifier son activation.
> >
> >
> > De mon côté, j'ai rajouté le Port Knocking par Iptables, que j'ai placé
> > tout à la fin de mon script, juste au dessus de COMMIT.
> > Ça a l'air fonctionnel, mais, j'ai l'impression que ça manque de
> > réactivité, et, je me demande si je n'ai pas des règles qui pourraient
> > entrer en conflit, comprendre, se répéter inutilement.
> >
> > Le script Iptables :
> >
> https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_pour_configurer_Iptables_filter
> >
> > Le script Port Knocking :
> >
> https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Mise_en_place_du_Port_Knocking
> >
> >
> > J'aimerais bien pouvoir gagner un peu de souplesse, au moment du Port
> > Knocking, car, j'ai l'impression que ça pédale dans la choucroute.
> > Peut être un problème de perf de serveur, un VPS 1Go, ce serait déjà
> > trop light vu que j'ai quelques virtualhosts dessus.
> >
> > Quoi qu'il en soit, j'ai tenté de me connecter directement en SSH, et,
> > le port knocking semble bien faire le boulot, la connexion n'est pas
> > établie.
> > Par contre, si je décommente les 2 lignes autorisant le port SSH dans
> > mon script principale, le script du Port Knocking ne semble pas arriver
> > à m'ouvrir le port 22.
> > J'ai donc une autorisation de SSH port 22 en input et output depuis mon
> > script principale, tout comme j'ai, tout à la fin de ce script
> > principale, le script Port Knocking, qui me réautorise le port 22 si les
> > frappes aboutissent.
> > Je ne suis pas sur que ce soit normal, d'avoir à autoriser le port SSH,
> > puis, à le réauthoriser avec le port knocking.
> > Il me semble que le port knocking devrait suffir à gérer l'ouverture et
> > la fermeture du port SSH.
> >
> > Il faut que je revérifie.
>
> Oublie le port knocking. Change le port d'écoute ssh et tout ira bien.
> Si tu veux tout de même encore plus te protéger installe fail2ban.
> Encore mieux: ouvre un VPN entre toi et ton serveur.
>
> >
> > Le 21/09/2019 à 13:46, Pascal Hambourg a écrit :
> >> Le 21/09/2019 à 12:39, G2PC a écrit :
> >>>
> >>> # Mon serveur ne retrouve pas les deux lignes de configuration
> >>> suivantes, que je commente. A SUIVRE !
> >>> # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_tcp_loose:
> >>> Aucun fichier ou dossier de ce type
> >>> # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: Aucun
> >>> fichier ou dossier de ce type
> >>
> >> Ces sysctls n'existent que si le module nf_conntrack_ipv4 ou
> >> nf_conntrack_ipv6 est chargé, ce qui est fait automatiquement à la
> >> création de la première règle utilisant le suivi de connexion (state,
> >> conntrack, connmark...) ou au chargement de la table nat.
> >>
> >> Pour pouvoir les initialiser via /etc/sysctl{,.d/*}.conf, il faut
> >> charger un de ces modules via /etc/modules{,-load.d/*.conf}.
> >>
> >
>
> --
> Daniel
>
>
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 18/09/2019 à 22:48, Jean-Michel a écrit : Personnellement, je trouve qu'un DROP par défaut de tout en fin de chaîne (ou en action par défaut) va très bien et évite de surcharger inutilement les règles. Une règle DROP en fin de chaîne n'est pas commode si on veut pouvoir ajouter des règles ACCEPT à la volée. Je préfère régler la politique par défaut à DROP. Pour l'IPv6, le jour où tu le déploieras, en effet, comme l'a rappelé Pascal, il faut faire attention à bien autoriser le protocole NDP qui reprend, entre autre, le rôle d'ARP en IPv4 et qui s'appuie sur de l'ICMPv6. Autant en IPv4 tu ne peux pas bloquer l'ARP avec iptables, Mais on peut assez souvent oublier d'autoriser le trafic DHCP. Par chance (?), les clients DHCP comme dhclient injectent et capturent les paquets directement sur l'interface réseau sans passer par la couche IP, ce qui court-circuite iptables. autant en IPv6 c'est assez facile de se couper les pattes en bloquant NDP ou plutôt en oubliant de l'autoriser NDP repose sur des paquets ICMPv6 échangés localement en multicast certes, mais surtout des paquets ICMPv6 particuliers. Personnellement, je n'autorise pas le multicast sur mes règles ip6tables mais uniquement les paquets ICMPv6 dont les caractéristiques concordent précisément avec les paquets attendus (adresses fe80::, HL = 255, types & codes qui vont bien, etc...). Attention, les paquets NDP peuvent contenir des adresses non link-local. Autoriser RELATED sans restriction est une mauvaise habitude de beaucoup de docs en ligne et la source de problèmes de sécurité importants même si depuis la version 4.7 du kernel les helpers ne sont plus activés par défaut pour éviter ce problème. Pour moi ce sont deux problèmes distincts. Certes un helper peut être abusé donc l'activer uniquement sur les connexions qui en ont besoin renforce la sécurité, mais cela n'empêche pas d'en abuser lorsqu'il est activé. Par exemple un paquet dans l'état RELATED lié au helper ftp (initiant une connexion de données FTP) ne devrait être accepté que si ses caractéristiques intrinsèques (ports source et destination, éventuellement adresses IP source et destination) sont conformes au trafic attendu : - dans le cas d'une connexion active, port source 20 et port destination dans la plage de ports actifs autorisée pour le client ; - dans le cas d'une connexion passive, port source > 1023 et port destination dans la plage de ports passifs définie dans la configuration du serveur FTP. En revanche, c'est mieux de le laisser autoriser pour l'ICMP. Si on est préoccupé à ce point par la sécurité, alors on ne devrait même pas accepter tous les types ICMP dans l'état RELATED. Par exemple le type "source quench" a été reconnu comme dangereux (déni de service) et officiellement abandonné, et le type "redirect" peut être exploité pour détourner du trafic. Pour ma part je n'autorise que les types d'erreur "destination unreachable", "time exceeded" et "parameter problem". De plus, il faudra activer le helper FTP pour ton serveur FTP. Une doc ici sur le sujet : https://gist.github.com/azlux/6a70bd38bb7c525ab26efe7e3a7ea8ac. Cela te permettra en plus de fermer le port TCP/20 On n'a jamais eu besoin d'ouvrir le port TCP 20 pour FTP. C'est uniquement un port source de connexions sortantes.
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
J'ai bien compris que le Port Knocking n'est pas réellement de la sécurité mais surtout de l'obfuscation. J'ai voulu le mettre en place tout de même. Oui pour fail2ban, il est en place mais je dois renforcer les règles. Le 21/09/2019 à 21:42, Daniel Huhardeaux a écrit : > Oublie le port knocking. Change le port d'écoute ssh et tout ira bien. > Si tu veux tout de même encore plus te protéger installe fail2ban. > Encore mieux: ouvre un VPN entre toi et ton serveur.
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 21/09/2019 à 20:18, G2PC a écrit :
Merci de ce retour, je vais faire des recherches complémentaires, car,
même si ta réponse est bien formulée, je décroche un peu.
Fondamentalement, je veux bien te croire, mais, il va falloir que je
vérifie, comment faire pour l'activer, et, pour vérifier son activation.
De mon côté, j'ai rajouté le Port Knocking par Iptables, que j'ai placé
tout à la fin de mon script, juste au dessus de COMMIT.
Ça a l'air fonctionnel, mais, j'ai l'impression que ça manque de
réactivité, et, je me demande si je n'ai pas des règles qui pourraient
entrer en conflit, comprendre, se répéter inutilement.
Le script Iptables :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_pour_configurer_Iptables_filter
Le script Port Knocking :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Mise_en_place_du_Port_Knocking
J'aimerais bien pouvoir gagner un peu de souplesse, au moment du Port
Knocking, car, j'ai l'impression que ça pédale dans la choucroute.
Peut être un problème de perf de serveur, un VPS 1Go, ce serait déjà
trop light vu que j'ai quelques virtualhosts dessus.
Quoi qu'il en soit, j'ai tenté de me connecter directement en SSH, et,
le port knocking semble bien faire le boulot, la connexion n'est pas
établie.
Par contre, si je décommente les 2 lignes autorisant le port SSH dans
mon script principale, le script du Port Knocking ne semble pas arriver
à m'ouvrir le port 22.
J'ai donc une autorisation de SSH port 22 en input et output depuis mon
script principale, tout comme j'ai, tout à la fin de ce script
principale, le script Port Knocking, qui me réautorise le port 22 si les
frappes aboutissent.
Je ne suis pas sur que ce soit normal, d'avoir à autoriser le port SSH,
puis, à le réauthoriser avec le port knocking.
Il me semble que le port knocking devrait suffir à gérer l'ouverture et
la fermeture du port SSH.
Il faut que je revérifie.
Oublie le port knocking. Change le port d'écoute ssh et tout ira bien.
Si tu veux tout de même encore plus te protéger installe fail2ban.
Encore mieux: ouvre un VPN entre toi et ton serveur.
Le 21/09/2019 à 13:46, Pascal Hambourg a écrit :
Le 21/09/2019 à 12:39, G2PC a écrit :
# Mon serveur ne retrouve pas les deux lignes de configuration
suivantes, que je commente. A SUIVRE !
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_tcp_loose:
Aucun fichier ou dossier de ce type
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: Aucun
fichier ou dossier de ce type
Ces sysctls n'existent que si le module nf_conntrack_ipv4 ou
nf_conntrack_ipv6 est chargé, ce qui est fait automatiquement à la
création de la première règle utilisant le suivi de connexion (state,
conntrack, connmark...) ou au chargement de la table nat.
Pour pouvoir les initialiser via /etc/sysctl{,.d/*}.conf, il faut
charger un de ces modules via /etc/modules{,-load.d/*.conf}.
--
Daniel
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Merci de ce retour, je vais faire des recherches complémentaires, car,
même si ta réponse est bien formulée, je décroche un peu.
Fondamentalement, je veux bien te croire, mais, il va falloir que je
vérifie, comment faire pour l'activer, et, pour vérifier son activation.
De mon côté, j'ai rajouté le Port Knocking par Iptables, que j'ai placé
tout à la fin de mon script, juste au dessus de COMMIT.
Ça a l'air fonctionnel, mais, j'ai l'impression que ça manque de
réactivité, et, je me demande si je n'ai pas des règles qui pourraient
entrer en conflit, comprendre, se répéter inutilement.
Le script Iptables :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_pour_configurer_Iptables_filter
Le script Port Knocking :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Mise_en_place_du_Port_Knocking
J'aimerais bien pouvoir gagner un peu de souplesse, au moment du Port
Knocking, car, j'ai l'impression que ça pédale dans la choucroute.
Peut être un problème de perf de serveur, un VPS 1Go, ce serait déjà
trop light vu que j'ai quelques virtualhosts dessus.
Quoi qu'il en soit, j'ai tenté de me connecter directement en SSH, et,
le port knocking semble bien faire le boulot, la connexion n'est pas
établie.
Par contre, si je décommente les 2 lignes autorisant le port SSH dans
mon script principale, le script du Port Knocking ne semble pas arriver
à m'ouvrir le port 22.
J'ai donc une autorisation de SSH port 22 en input et output depuis mon
script principale, tout comme j'ai, tout à la fin de ce script
principale, le script Port Knocking, qui me réautorise le port 22 si les
frappes aboutissent.
Je ne suis pas sur que ce soit normal, d'avoir à autoriser le port SSH,
puis, à le réauthoriser avec le port knocking.
Il me semble que le port knocking devrait suffir à gérer l'ouverture et
la fermeture du port SSH.
Il faut que je revérifie.
Le 21/09/2019 à 13:46, Pascal Hambourg a écrit :
> Le 21/09/2019 à 12:39, G2PC a écrit :
>>
>> # Mon serveur ne retrouve pas les deux lignes de configuration
>> suivantes, que je commente. A SUIVRE !
>> # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_tcp_loose:
>> Aucun fichier ou dossier de ce type
>> # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: Aucun
>> fichier ou dossier de ce type
>
> Ces sysctls n'existent que si le module nf_conntrack_ipv4 ou
> nf_conntrack_ipv6 est chargé, ce qui est fait automatiquement à la
> création de la première règle utilisant le suivi de connexion (state,
> conntrack, connmark...) ou au chargement de la table nat.
>
> Pour pouvoir les initialiser via /etc/sysctl{,.d/*}.conf, il faut
> charger un de ces modules via /etc/modules{,-load.d/*.conf}.
>
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 21/09/2019 à 12:39, G2PC a écrit :
# Mon serveur ne retrouve pas les deux lignes de configuration suivantes, que
je commente. A SUIVRE !
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_tcp_loose: Aucun
fichier ou dossier de ce type
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: Aucun fichier
ou dossier de ce type
Ces sysctls n'existent que si le module nf_conntrack_ipv4 ou
nf_conntrack_ipv6 est chargé, ce qui est fait automatiquement à la
création de la première règle utilisant le suivi de connexion (state,
conntrack, connmark...) ou au chargement de la table nat.
Pour pouvoir les initialiser via /etc/sysctl{,.d/*}.conf, il faut
charger un de ces modules via /etc/modules{,-load.d/*.conf}.
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Ok, j'en prend note, même si je n'ai pas encore ce besoin. Configurer le noyau du système pour mettre en place certaines règles de protection <https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Configurer_le_noyau_du_syst.C3.A8me_pour_mettre_en_place_certaines_r.C3.A8gles_de_protection> J'ai lu que je pouvais configurer le noyau du système, ce que j'ai fais ainsi, par contre, j'ai une erreur sur : netfilter/nf_conntrack_tcp_loose: Aucun fichier ou dossier de ce type # Mon serveur ne retrouve pas les deux lignes de configuration suivantes, que je commente. A SUIVRE ! # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_tcp_loose: Aucun fichier ou dossier de ce type # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: Aucun fichier ou dossier de ce type Source : https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Configurer_le_noyau_du_syst.C3.A8me_pour_mettre_en_place_certaines_r.C3.A8gles_de_protection Pour le reste, j'ai pu avancer en mettant en place le script suivant, en prenant en compte au possible, vos recommandations. Pour le moment, et, ça se passe bien, toujours accès au serveur, et, j'ai bien DROP partout par défaut. J'ai pu entrevoir également les tables raw et mangle, pour lesquelles j'ai ajouté quelques lignes de configuration. Source : https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Configurer_Iptables_sur_un_serveur_distant Le 21/09/2019 à 12:14, Daniel Huhardeaux a écrit : > Le 20/09/2019 à 18:57, G2PC a écrit : >> Quel est le rôle de : >> # This server is a GW for Intranet >> $IPTABLES -t nat -A POSTROUTING -j MASQUERADE >> >> Le 18/09/2019 à 18:50, Daniel Huhardeaux a écrit : >>> # This server is a GW for Intranet >>> $IPTABLES -t nat -A POSTROUTING -j MASQUERADE >> > > Si ce serveur fait routeur et est passerelle pour le réseau alors les > machines du lan continueront à accéder à Internet et/ou à tout autre > réseau derrière cette passerelle lorsque les règles du pare-feu sont > désactivées.
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 20/09/2019 à 18:57, G2PC a écrit : Quel est le rôle de : # This server is a GW for Intranet $IPTABLES -t nat -A POSTROUTING -j MASQUERADE Le 18/09/2019 à 18:50, Daniel Huhardeaux a écrit : # This server is a GW for Intranet $IPTABLES -t nat -A POSTROUTING -j MASQUERADE Si ce serveur fait routeur et est passerelle pour le réseau alors les machines du lan continueront à accéder à Internet et/ou à tout autre réseau derrière cette passerelle lorsque les règles du pare-feu sont désactivées. -- Daniel
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Quel est le rôle de : # This server is a GW for Intranet $IPTABLES -t nat -A POSTROUTING -j MASQUERADE Le 18/09/2019 à 18:50, Daniel Huhardeaux a écrit : > # This server is a GW for Intranet > $IPTABLES -t nat -A POSTROUTING -j MASQUERADE
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 18/09/2019 à 18:12, G2PC a écrit : Ok super, je vais faire comme tu le proposes. Enregistrer le fichier regles-iptables-inactives doit permettre de revenir rapidement en arrière en cas de blocage, je suppose. Plus simple, faire un script comme # Flush all $IPTABLES -F $IPTABLES -X $IPTABLES -t nat -F $IPTABLES -t nat -X $IPTABLES -t mangle -F $IPTABLES -t mangle -X # Accept all by default $IPTABLES -P INPUT ACCEPT $IPTABLES -P OUTPUT ACCEPT $IPTABLES -P FORWARDACCEPT $IPTABLES -t nat-P OUTPUT ACCEPT $IPTABLES -t mangle -P INPUTACCEPT $IPTABLES -t mangle -P OUTPUT ACCEPT # This server is a GW for Intranet $IPTABLES -t nat-A POSTROUTING -j MASQUERADE et le tour est joué Ok pour * filter que je vais commenter. Par contre, sur certains tutoriels, je lisais qu'il était conseillé d'appliquer les règles suivantes à la fin du script. Est ce qu'on ne risque pas d'être déconnecté du serveur distant, immédiatement après la lecture des 3 premières lignes ? -P INPUT DROP -P FORWARD DROP -P OUTPUT DROP Non, sauf si ton script plante en cours d'exécution. Une bonne hygiène est de régler ton script FW en étant devant la console, ou alors à distance *SANS* activer le script au démarrage de la machine. Une session ssh (ou tout autre service) déjà ouverte ne sera pas interrompue si le script fonctionne bien. Le 18/09/2019 à 18:05, Daniel Huhardeaux a écrit : Le 18/09/2019 à 17:41, G2PC a écrit : Très bien je prend note, j'appliquerais après avoir flush : sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT Non ! Les flush, puis: sudo iptables -A INPUT ACCEPT sudo iptables -A FORWARD ACCEPT sudo iptables -A OUTPUT ACCEPT $IPTABLES-save > /path/vers/le/fichier/iptablesInactif sudo iptables -P INPUT DROP sudo iptables -P FORWARD DROP sudo iptables -P OUTPUT DROP Mais vu que déjà tu t'emmêles les pédales ;) et ne veux pas sauvegarder les règles inactives, laisse tomber: fais les flush puis les DROP Si * filter est implicite, je n'ai donc pas à l'ajouter dans mon script , on est bien d'accord sur ce point ? Oui, voir le man iptables.
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Ok super, je vais faire comme tu le proposes. Enregistrer le fichier regles-iptables-inactives doit permettre de revenir rapidement en arrière en cas de blocage, je suppose. Ok pour * filter que je vais commenter. Par contre, sur certains tutoriels, je lisais qu'il était conseillé d'appliquer les règles suivantes à la fin du script. Est ce qu'on ne risque pas d'être déconnecté du serveur distant, immédiatement après la lecture des 3 premières lignes ? -P INPUT DROP -P FORWARD DROP -P OUTPUT DROP Le 18/09/2019 à 18:05, Daniel Huhardeaux a écrit : > Le 18/09/2019 à 17:41, G2PC a écrit : >> Très bien je prend note, j'appliquerais après avoir flush : >> >> sudo iptables -P INPUT ACCEPT >> sudo iptables -P FORWARD ACCEPT >> sudo iptables -P OUTPUT ACCEPT > > Non ! > > Les flush, puis: > > sudo iptables -A INPUT ACCEPT > sudo iptables -A FORWARD ACCEPT > sudo iptables -A OUTPUT ACCEPT > > $IPTABLES-save > /path/vers/le/fichier/iptablesInactif > > sudo iptables -P INPUT DROP > sudo iptables -P FORWARD DROP > sudo iptables -P OUTPUT DROP > > Mais vu que déjà tu t'emmêles les pédales ;) et ne veux pas > sauvegarder les règles inactives, laisse tomber: fais les flush puis > les DROP > >> Si * filter est implicite, je n'ai donc pas à l'ajouter dans mon script >> , on est bien d'accord sur ce point ? > > Oui, voir le man iptables.
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 18/09/2019 à 17:41, G2PC a écrit : Très bien je prend note, j'appliquerais après avoir flush : sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT Non ! Les flush, puis: sudo iptables -A INPUT ACCEPT sudo iptables -A FORWARD ACCEPT sudo iptables -A OUTPUT ACCEPT $IPTABLES-save > /path/vers/le/fichier/iptablesInactif sudo iptables -P INPUT DROP sudo iptables -P FORWARD DROP sudo iptables -P OUTPUT DROP Mais vu que déjà tu t'emmêles les pédales ;) et ne veux pas sauvegarder les règles inactives, laisse tomber: fais les flush puis les DROP Si * filter est implicite, je n'ai donc pas à l'ajouter dans mon script , on est bien d'accord sur ce point ? Oui, voir le man iptables. Merci pour ses précisions. Le 18/09/2019 à 14:11, Daniel Huhardeaux a écrit : Le 18/09/2019 à 13:49, G2PC a écrit : Je dis des bêtises, cette règle sert à flush, elle n'est pas directement ajoutée à mon script de protection, elle est dans les prémices : -F -X -t nat -F -t nat -X -t mangle -F -t mangle -X J'ai lu que je devrais appliquer cette règle avant de flush, ton avis ? sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT Je le fais après le flush puis sauve les règles iptables dans un fichier nommé inactive (c'est mon truc pour avoir quelque part zéro règles, jamais utilisé) puis applique les policy DROP et le reste. La table filter étant implicite je ne la mentionne pas: les règles flush s'appliquent à toutes les tables (mentionnées ou non). J'insiste, ceci est _ma_ manière de faire. Ensuite, pour le début du script, je mettrais : # Début de la règle. *filter # Fermer tous les ports pour les connexions entrantes. # REJECT les paquets est plus propre mais DROP est plus sécurisé ! # Avec DROP, si un paquet arrive et n'est pas accepté, on l'efface. Le client attendra de son côté une réponse en vain, jusqu'au timeout. # Avec REJECT, si un paquet non sollicité arrive, on renvoie au client une erreur et il n'attend plus car il a une réponse négative. # En cas d'envoi de paquets à répétition sur un mauvais port, avec DROP le serveur ne traitera pas les requêtes, alors qu'avec REJECT le serveur prendra le temps de répondre. # -A INPUT -j DROP # Interdire toutes les autres connexions entrantes et sortantes. # Les connexions entrantes seront bloquées par défaut. -P INPUT -j DROP # Les connexions destinées à être forwardées seront bloquées par défaut. -P FORWARD -j DROP # Les connexions sortantes seront bloquées par défaut. -P OUTPUT -j DROP Je ne suis pas sur pour le *filter si je dois l'appliquer, au tout début, ou, après les blocages. Merci de ton avis. Le 18/09/2019 à 13:41, G2PC a écrit : Hum, ok, à la fin du script, j'avais : Donc, la, je rajoute ceci au début de mon script : -F -X -t nat -F -t nat -X -t mangle -F -t mangle -X Le 17/09/2019 à 20:15, Daniel Huhardeaux a écrit : Le 17/09/2019 à 19:58, G2PC a écrit : [...] Ok, donc, je n'ai pas besoin d'ajouter les règles pour DROP le multicast et / ou IGMP. Si tu DROP par défaut [...] La règle que je suis entrain d'écrire, mais, pas encore appliquée, est la suivante : https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_propos.C3.A9e_pour_configurer_Iptables_par_d.C3.A9faut Mais tu ne DROP _PAS_ par défaut. Tes règles devraient commencer par: # Flush all Rules $IPTABLES -F $IPTABLES -X $IPTABLES -t nat -F $IPTABLES -t nat -X $IPTABLES -t mangle -F $IPTABLES -t mangle -X # *** Now we start to setup our rules *** # Deny all by default $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP Puis tu définis tes règles qui acceptent du flux comme par exemple ### ## Special Chain ALLOW_PORTS ## Rules to allow packets based on port number. This sort of thing is generally ## required only if you're running services on(!!!) the firewall or if you have a ## FORWARD policy of DROP(which we don't right now). $IPTABLES -N ALLOW_PORTS $IPTABLES -F ALLOW_PORTS ## ## ## ACCEPT TCP traffic based on port number. for PORT in $TCP_PORTS_ALLOWED; do $IPTABLES -A ALLOW_PORTS -p tcp -m state --state NEW \ --dport $PORT -j ACCEPT done ## ## ## ACCEPT UDP traffic based on port number. for PORT in $UDP_PORTS_ALLOWED; do $IPTABLES -A ALLOW_PORTS -p udp -m state --state NEW \ --dport $PORT -j ACCEPT done Merci de vos avis, si quelque chose n'est pas cohérent, que je puisse améliorer ce scr
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Très bien je prend note, j'appliquerais après avoir flush : sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT Si * filter est implicite, je n'ai donc pas à l'ajouter dans mon script , on est bien d'accord sur ce point ? Merci pour ses précisions. Le 18/09/2019 à 14:11, Daniel Huhardeaux a écrit : > Le 18/09/2019 à 13:49, G2PC a écrit : >> Je dis des bêtises, cette règle sert à flush, elle n'est pas >> directement ajoutée à mon script de protection, elle est dans les >> prémices : >> -F >> -X >> -t nat -F >> -t nat -X >> -t mangle -F >> -t mangle -X >> >> J'ai lu que je devrais appliquer cette règle avant de flush, ton avis ? >> >> sudo iptables -P INPUT ACCEPT >> sudo iptables -P FORWARD ACCEPT >> sudo iptables -P OUTPUT ACCEPT > > Je le fais après le flush puis sauve les règles iptables dans un > fichier nommé inactive (c'est mon truc pour avoir quelque part zéro > règles, jamais utilisé) puis applique les policy DROP et le reste. > > La table filter étant implicite je ne la mentionne pas: les règles > flush s'appliquent à toutes les tables (mentionnées ou non). > > J'insiste, ceci est _ma_ manière de faire. > >> >> >> Ensuite, pour le début du script, je mettrais : >> >> # Début de la règle. >> *filter >> # Fermer tous les ports pour les connexions entrantes. >> # REJECT les paquets est plus propre mais DROP est plus sécurisé ! >> # Avec DROP, si un paquet arrive et n'est pas accepté, on l'efface. >> Le client attendra de son côté une réponse en vain, jusqu'au timeout. >> # Avec REJECT, si un paquet non sollicité arrive, on renvoie au >> client une erreur et il n'attend plus car il a une réponse négative. >> # En cas d'envoi de paquets à répétition sur un mauvais port, avec >> DROP le serveur ne traitera pas les requêtes, alors qu'avec REJECT le >> serveur prendra le temps de répondre. >> # -A INPUT -j DROP >> # Interdire toutes les autres connexions entrantes et sortantes. >> # Les connexions entrantes seront bloquées par défaut. >> -P INPUT -j DROP >> # Les connexions destinées à être forwardées seront bloquées par >> défaut. >> -P FORWARD -j DROP >> # Les connexions sortantes seront bloquées par défaut. >> -P OUTPUT -j DROP >> >> >> Je ne suis pas sur pour le *filter si je dois l'appliquer, au tout >> début, ou, après les blocages. Merci de ton avis. >> >> >> >> Le 18/09/2019 à 13:41, G2PC a écrit : >>> >>> Hum, ok, à la fin du script, j'avais : >>> >>> >>> Donc, la, je rajoute ceci au début de mon script : >>> >>> -F >>> -X >>> -t nat -F >>> -t nat -X >>> -t mangle -F >>> -t mangle -X >>> >>> >>> Le 17/09/2019 à 20:15, Daniel Huhardeaux a écrit : >>>> Le 17/09/2019 à 19:58, G2PC a écrit : >>>> [...] >>>>> Ok, donc, je n'ai pas besoin d'ajouter les règles pour DROP le >>>>> multicast >>>>> et / ou IGMP. >>>> >>>> Si tu DROP par défaut >>>> >>>> [...] >>>> >>>>> La règle que je suis entrain d'écrire, mais, pas encore appliquée, >>>>> est >>>>> la suivante : >>>>> https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_propos.C3.A9e_pour_configurer_Iptables_par_d.C3.A9faut >>>>> >>>> >>>> Mais tu ne DROP _PAS_ par défaut. Tes règles devraient commencer par: >>>> >>>> # Flush all Rules >>>> $IPTABLES -F >>>> $IPTABLES -X >>>> $IPTABLES -t nat -F >>>> $IPTABLES -t nat -X >>>> $IPTABLES -t mangle -F >>>> $IPTABLES -t mangle -X >>>> >>>> # *** Now we start to setup our rules *** >>>> >>>> # Deny all by default >>>> $IPTABLES -P INPUT DROP >>>> $IPTABLES -P OUTPUT DROP >>>> $IPTABLES -P FORWARD DROP >>>> >>>> Puis tu définis tes règles qui acceptent du flux comme par exemple >>>> >>>> ### >>>> >>>> ## Special Chain ALLOW_PORTS >>>> ## Rules to allow packets based on port number. This sort of thing >>>> is generally >>>> ## required only if you're r
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 18/09/2019 à 13:49, G2PC a écrit : Je dis des bêtises, cette règle sert à flush, elle n'est pas directement ajoutée à mon script de protection, elle est dans les prémices : -F -X -t nat -F -t nat -X -t mangle -F -t mangle -X J'ai lu que je devrais appliquer cette règle avant de flush, ton avis ? sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT Je le fais après le flush puis sauve les règles iptables dans un fichier nommé inactive (c'est mon truc pour avoir quelque part zéro règles, jamais utilisé) puis applique les policy DROP et le reste. La table filter étant implicite je ne la mentionne pas: les règles flush s'appliquent à toutes les tables (mentionnées ou non). J'insiste, ceci est _ma_ manière de faire. Ensuite, pour le début du script, je mettrais : # Début de la règle. *filter # Fermer tous les ports pour les connexions entrantes. # REJECT les paquets est plus propre mais DROP est plus sécurisé ! # Avec DROP, si un paquet arrive et n'est pas accepté, on l'efface. Le client attendra de son côté une réponse en vain, jusqu'au timeout. # Avec REJECT, si un paquet non sollicité arrive, on renvoie au client une erreur et il n'attend plus car il a une réponse négative. # En cas d'envoi de paquets à répétition sur un mauvais port, avec DROP le serveur ne traitera pas les requêtes, alors qu'avec REJECT le serveur prendra le temps de répondre. # -A INPUT -j DROP # Interdire toutes les autres connexions entrantes et sortantes. # Les connexions entrantes seront bloquées par défaut. -P INPUT -j DROP # Les connexions destinées à être forwardées seront bloquées par défaut. -P FORWARD -j DROP # Les connexions sortantes seront bloquées par défaut. -P OUTPUT -j DROP Je ne suis pas sur pour le *filter si je dois l'appliquer, au tout début, ou, après les blocages. Merci de ton avis. Le 18/09/2019 à 13:41, G2PC a écrit : Hum, ok, à la fin du script, j'avais : Donc, la, je rajoute ceci au début de mon script : -F -X -t nat -F -t nat -X -t mangle -F -t mangle -X Le 17/09/2019 à 20:15, Daniel Huhardeaux a écrit : Le 17/09/2019 à 19:58, G2PC a écrit : [...] Ok, donc, je n'ai pas besoin d'ajouter les règles pour DROP le multicast et / ou IGMP. Si tu DROP par défaut [...] La règle que je suis entrain d'écrire, mais, pas encore appliquée, est la suivante : https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_propos.C3.A9e_pour_configurer_Iptables_par_d.C3.A9faut Mais tu ne DROP _PAS_ par défaut. Tes règles devraient commencer par: # Flush all Rules $IPTABLES -F $IPTABLES -X $IPTABLES -t nat -F $IPTABLES -t nat -X $IPTABLES -t mangle -F $IPTABLES -t mangle -X # *** Now we start to setup our rules *** # Deny all by default $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP Puis tu définis tes règles qui acceptent du flux comme par exemple ### ## Special Chain ALLOW_PORTS ## Rules to allow packets based on port number. This sort of thing is generally ## required only if you're running services on(!!!) the firewall or if you have a ## FORWARD policy of DROP(which we don't right now). $IPTABLES -N ALLOW_PORTS $IPTABLES -F ALLOW_PORTS ## ## ## ACCEPT TCP traffic based on port number. for PORT in $TCP_PORTS_ALLOWED; do $IPTABLES -A ALLOW_PORTS -p tcp -m state --state NEW \ --dport $PORT -j ACCEPT done ## ## ## ACCEPT UDP traffic based on port number. for PORT in $UDP_PORTS_ALLOWED; do $IPTABLES -A ALLOW_PORTS -p udp -m state --state NEW \ --dport $PORT -j ACCEPT done Merci de vos avis, si quelque chose n'est pas cohérent, que je puisse améliorer ce script. Je l'utilise ici pour un VPS OVH, sur Debian, qui est utilisé pour serveur web avec Apache , mariaDB, et, avec un serveur FTP ProFTPd. Le 17/09/2019 à 12:19, Daniel Huhardeaux a écrit : Le 17/09/2019 à 12:12, G2PC a écrit : Bonjour, Du coup, si je bloque tout ce dont je n'ai pas besoin, mais, que IPV6 en aurait besoin, je ne suis pas plus avancé. iptables est pour ipv4 ip6tables est pour ipv6, ce ne sont pas les mêmes commandes. Pour nft n'utilises pas inet mais ip ou ipv6 si tu veux différencier. Bon, je n'utilise pas IPV6 pour le moment, mais, j'aurais aimé avoir plus d'informations sur les règles présentées, pour savoir justement si il y a du sens à les mettre en place, les autoriser, ou, les refuser. C'est bien car je ne sais pas que j'ai posté cette demande. J'ai pu voir de nombreux sites proposer
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Je dis des bêtises, cette règle sert à flush, elle n'est pas directement ajoutée à mon script de protection, elle est dans les prémices : -F -X -t nat -F -t nat -X -t mangle -F -t mangle -X J'ai lu que je devrais appliquer cette règle avant de flush, ton avis ? sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT Ensuite, pour le début du script, je mettrais : # Début de la règle. *filter # Fermer tous les ports pour les connexions entrantes. # REJECT les paquets est plus propre mais DROP est plus sécurisé ! # Avec DROP, si un paquet arrive et n'est pas accepté, on l'efface. Le client attendra de son côté une réponse en vain, jusqu'au timeout. # Avec REJECT, si un paquet non sollicité arrive, on renvoie au client une erreur et il n'attend plus car il a une réponse négative. # En cas d'envoi de paquets à répétition sur un mauvais port, avec DROP le serveur ne traitera pas les requêtes, alors qu'avec REJECT le serveur prendra le temps de répondre. # -A INPUT -j DROP # Interdire toutes les autres connexions entrantes et sortantes. # Les connexions entrantes seront bloquées par défaut. -P INPUT -j DROP # Les connexions destinées à être forwardées seront bloquées par défaut. -P FORWARD -j DROP # Les connexions sortantes seront bloquées par défaut. -P OUTPUT -j DROP Je ne suis pas sur pour le *filter si je dois l'appliquer, au tout début, ou, après les blocages. Merci de ton avis. Le 18/09/2019 à 13:41, G2PC a écrit : > > Hum, ok, à la fin du script, j'avais : > > > Donc, la, je rajoute ceci au début de mon script : > > -F > -X > -t nat -F > -t nat -X > -t mangle -F > -t mangle -X > > > Le 17/09/2019 à 20:15, Daniel Huhardeaux a écrit : >> Le 17/09/2019 à 19:58, G2PC a écrit : >> [...] >>> Ok, donc, je n'ai pas besoin d'ajouter les règles pour DROP le >>> multicast >>> et / ou IGMP. >> >> Si tu DROP par défaut >> >> [...] >> >>> La règle que je suis entrain d'écrire, mais, pas encore appliquée, est >>> la suivante : >>> https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_propos.C3.A9e_pour_configurer_Iptables_par_d.C3.A9faut >>> >> >> Mais tu ne DROP _PAS_ par défaut. Tes règles devraient commencer par: >> >> # Flush all Rules >> $IPTABLES -F >> $IPTABLES -X >> $IPTABLES -t nat -F >> $IPTABLES -t nat -X >> $IPTABLES -t mangle -F >> $IPTABLES -t mangle -X >> >> # *** Now we start to setup our rules *** >> >> # Deny all by default >> $IPTABLES -P INPUT DROP >> $IPTABLES -P OUTPUT DROP >> $IPTABLES -P FORWARD DROP >> >> Puis tu définis tes règles qui acceptent du flux comme par exemple >> >> ### >> >> ## Special Chain ALLOW_PORTS >> ## Rules to allow packets based on port number. This sort of thing is >> generally >> ## required only if you're running services on(!!!) the firewall or >> if you have a >> ## FORWARD policy of DROP(which we don't right now). >> >> $IPTABLES -N ALLOW_PORTS >> $IPTABLES -F ALLOW_PORTS >> >> >> ## >> >> ## >> ## ACCEPT TCP traffic based on port number. >> >> for PORT in $TCP_PORTS_ALLOWED; do >> $IPTABLES -A ALLOW_PORTS -p tcp -m state --state NEW \ >> --dport $PORT -j ACCEPT >> done >> >> >> ## >> >> ## >> ## ACCEPT UDP traffic based on port number. >> >> for PORT in $UDP_PORTS_ALLOWED; do >> $IPTABLES -A ALLOW_PORTS -p udp -m state --state NEW \ >> --dport $PORT -j ACCEPT >> done >> >> >> >>> >>> Merci de vos avis, si quelque chose n'est pas cohérent, que je puisse >>> améliorer ce script. >>> Je l'utilise ici pour un VPS OVH, sur Debian, qui est utilisé pour >>> serveur web avec Apache , mariaDB, et, avec un serveur FTP ProFTPd. >>> >>> >>> Le 17/09/2019 à 12:19, Daniel Huhardeaux a écrit : >>>> Le 17/09/2019 à 12:12, G2PC a écrit : >>>>> Bonjour, >>>>> Du coup, si je bloque tout ce dont je n'ai pas besoin, mais, que IPV6 >>>>> en aurait besoin, je ne suis pas plus avancé. >>>> >>>> iptables e
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Hum, ok, à la fin du script, j'avais : # Fermer tous les ports pour les connexions entrantes. # REJECT les paquets est plus propre mais DROP est plus sécurisé ! # Avec DROP, si un paquet arrive et n'est pas accepté, on l'efface. Le client attendra de son côté une réponse en vain, jusqu'au timeout. # Avec REJECT, si un paquet non sollicité arrive, on renvoie au client une erreur et il n'attend plus car il a une réponse négative. # En cas d'envoi de paquets à répétition sur un mauvais port, avec DROP le serveur ne traitera pas les requêtes, alors qu'avec REJECT le serveur prendra le temps de répondre. # -A INPUT -j DROP # Interdire toutes les autres connexions entrantes et sortantes. # Les connexions entrantes seront bloquées par défaut. -P INPUT -j DROP # Les connexions destinées à être forwardées seront bloquées par défaut. -P FORWARD -j DROP # Les connexions sortantes seront bloquées par défaut. -P OUTPUT -j DROP Donc, la, je rajoute ceci au début de mon script : -F -X -t nat -F -t nat -X -t mangle -F -t mangle -X Le 17/09/2019 à 20:15, Daniel Huhardeaux a écrit : > Le 17/09/2019 à 19:58, G2PC a écrit : > [...] >> Ok, donc, je n'ai pas besoin d'ajouter les règles pour DROP le multicast >> et / ou IGMP. > > Si tu DROP par défaut > > [...] > >> La règle que je suis entrain d'écrire, mais, pas encore appliquée, est >> la suivante : >> https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_propos.C3.A9e_pour_configurer_Iptables_par_d.C3.A9faut >> > > Mais tu ne DROP _PAS_ par défaut. Tes règles devraient commencer par: > > # Flush all Rules > $IPTABLES -F > $IPTABLES -X > $IPTABLES -t nat -F > $IPTABLES -t nat -X > $IPTABLES -t mangle -F > $IPTABLES -t mangle -X > > # *** Now we start to setup our rules *** > > # Deny all by default > $IPTABLES -P INPUT DROP > $IPTABLES -P OUTPUT DROP > $IPTABLES -P FORWARD DROP > > Puis tu définis tes règles qui acceptent du flux comme par exemple > > ### > > ## Special Chain ALLOW_PORTS > ## Rules to allow packets based on port number. This sort of thing is > generally > ## required only if you're running services on(!!!) the firewall or if > you have a > ## FORWARD policy of DROP(which we don't right now). > > $IPTABLES -N ALLOW_PORTS > $IPTABLES -F ALLOW_PORTS > > > ##---- > > ## > ## ACCEPT TCP traffic based on port number. > > for PORT in $TCP_PORTS_ALLOWED; do > $IPTABLES -A ALLOW_PORTS -p tcp -m state --state NEW \ > --dport $PORT -j ACCEPT > done > > > ## > > ## > ## ACCEPT UDP traffic based on port number. > > for PORT in $UDP_PORTS_ALLOWED; do > $IPTABLES -A ALLOW_PORTS -p udp -m state --state NEW \ > --dport $PORT -j ACCEPT > done > > > >> >> Merci de vos avis, si quelque chose n'est pas cohérent, que je puisse >> améliorer ce script. >> Je l'utilise ici pour un VPS OVH, sur Debian, qui est utilisé pour >> serveur web avec Apache , mariaDB, et, avec un serveur FTP ProFTPd. >> >> >> Le 17/09/2019 à 12:19, Daniel Huhardeaux a écrit : >>> Le 17/09/2019 à 12:12, G2PC a écrit : >>>> Bonjour, >>>> Du coup, si je bloque tout ce dont je n'ai pas besoin, mais, que IPV6 >>>> en aurait besoin, je ne suis pas plus avancé. >>> >>> iptables est pour ipv4 ip6tables est pour ipv6, ce ne sont pas les >>> mêmes commandes. Pour nft n'utilises pas inet mais ip ou ipv6 si tu >>> veux différencier. >>> >>>> >>>> Bon, je n'utilise pas IPV6 pour le moment, mais, j'aurais aimé avoir >>>> plus d'informations sur les règles présentées, pour savoir justement >>>> si il y a du sens à les mettre en place, les autoriser, ou, les >>>> refuser. >>>> C'est bien car je ne sais pas que j'ai posté cette demande. J'ai pu >>>> voir de nombreux sites proposer de DROP ou ACCEPT ces paquets, mais, >>>> sans plus d'informations que cela. >>> >>> Ce que dit Pascal c'est que tu DROP par défaut et ensuite tu acceptes >>> ce qui t'es nécessaire. Du coup tu ne t'occupes pas du multicast (ou >>> tout autre) sauf si tu veux l'ouvrir. >>> >>>> >>>> Merci de vos avis. >>>> >>>> # DROP le Multi
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 17/09/2019 à 19:58, G2PC a écrit : [...] Ok, donc, je n'ai pas besoin d'ajouter les règles pour DROP le multicast et / ou IGMP. Si tu DROP par défaut [...] La règle que je suis entrain d'écrire, mais, pas encore appliquée, est la suivante : https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_propos.C3.A9e_pour_configurer_Iptables_par_d.C3.A9faut Mais tu ne DROP _PAS_ par défaut. Tes règles devraient commencer par: # Flush all Rules $IPTABLES -F $IPTABLES -X $IPTABLES -t nat-F $IPTABLES -t nat-X $IPTABLES -t mangle -F $IPTABLES -t mangle -X # *** Now we start to setup our rules *** # Deny all by default $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARDDROP Puis tu définis tes règles qui acceptent du flux comme par exemple ### ## Special Chain ALLOW_PORTS ## Rules to allow packets based on port number. This sort of thing is generally ## required only if you're running services on(!!!) the firewall or if you have a ## FORWARD policy of DROP(which we don't right now). $IPTABLES -N ALLOW_PORTS $IPTABLES -F ALLOW_PORTS ## ## ## ACCEPT TCP traffic based on port number. for PORT in $TCP_PORTS_ALLOWED; do $IPTABLES -A ALLOW_PORTS -p tcp -m state --state NEW \ --dport $PORT -j ACCEPT done ## ## ## ACCEPT UDP traffic based on port number. for PORT in $UDP_PORTS_ALLOWED; do $IPTABLES -A ALLOW_PORTS -p udp -m state --state NEW \ --dport $PORT -j ACCEPT done Merci de vos avis, si quelque chose n'est pas cohérent, que je puisse améliorer ce script. Je l'utilise ici pour un VPS OVH, sur Debian, qui est utilisé pour serveur web avec Apache , mariaDB, et, avec un serveur FTP ProFTPd. Le 17/09/2019 à 12:19, Daniel Huhardeaux a écrit : Le 17/09/2019 à 12:12, G2PC a écrit : Bonjour, Du coup, si je bloque tout ce dont je n'ai pas besoin, mais, que IPV6 en aurait besoin, je ne suis pas plus avancé. iptables est pour ipv4 ip6tables est pour ipv6, ce ne sont pas les mêmes commandes. Pour nft n'utilises pas inet mais ip ou ipv6 si tu veux différencier. Bon, je n'utilise pas IPV6 pour le moment, mais, j'aurais aimé avoir plus d'informations sur les règles présentées, pour savoir justement si il y a du sens à les mettre en place, les autoriser, ou, les refuser. C'est bien car je ne sais pas que j'ai posté cette demande. J'ai pu voir de nombreux sites proposer de DROP ou ACCEPT ces paquets, mais, sans plus d'informations que cela. Ce que dit Pascal c'est que tu DROP par défaut et ensuite tu acceptes ce qui t'es nécessaire. Du coup tu ne t'occupes pas du multicast (ou tout autre) sauf si tu veux l'ouvrir. Merci de vos avis. # DROP le Multicast : # Ce système est plus efficace que l'unicast pour diffuser des contenus simultanément vers une large audience. (Audio, Vidéo.) -A INPUT -m pkttype --pkt-type multicast -j DROP -A FORWARD -m pkttype --pkt-type multicast -j DROP -A OUTPUT -m pkttype --pkt-type multicast -j DROP # DROP IGMP : # Également pour bloquer le multicast ? Quelle méthode préférer, les deux ? # Si nécessaire, tenter de logger tout paquet igmp sans spécifier de source pour voir ce que ça donne dans "/var/log/syslog". # iptables -A INPUT -p igmp -j LOG --log-level info --log-prefix "IGMP:" # L'IGMP est un protocole standard utilisé par la suite de protocoles TCP/IP pour la multidiffusion dynamique, le multicast. -A INPUT -p igmp -j DROP -A FORWARD -p igmp -j DROP -A OUTPUT -p igmp -j DROP Le 16/09/2019 à 20:48, Pascal Hambourg a écrit : Le 16/09/2019 à 12:57, G2PC a écrit : Bonjour, Je ne pense pas en avoir besoin pour le moment, d'utiliser le multicast, il me semble de ce fait inutile de l'autoriser dans ma configuration Iptables ? Il ne s'agit pas de penser mais de savoir. Si tu n'utilises pas le multicast, tu n'as pas besoin de l'autoriser. Par contre, je trouve deux types de règles via mes recherches, et, je ne suis pas très sur de la bonne façon de l'interdire. Il suffit de ne pas l'autoriser. Tu interdis tout par défaut et n'autorises que ce dont tu as besoin, n'est-ce pas ? # DROP IGMP : # Également pour bloquer le multicast ? Quelle méthode préférer, les deux ? IGMP n'est pas le multicast, ce n'est que le protocole de gestion du multicast. Tous les flux multicast ne font pas forcément l'objet d'un abonnement avec IGMP. J'ignore si tout le trafic IGMP est aussi en multicast. Note que si tu fais aussi du filtrage pour IPv6, réfléchis à deux fois avant de bloquer du trafic multicast. Certains flux multicast sont indispensables au bon fonctionnement d'IPv6.
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Ok pour IP6tables, j'ai du survoler ça quelques fois maintenant, sans m'en préoccuper pour le moment. Ok, donc, je n'ai pas besoin d'ajouter les règles pour DROP le multicast et / ou IGMP. Par contre, si je devais l'accepter, dans quel cas ouvrir le multicast, ou, IGMP, d'après Pascal, ce n'est donc pas le même usage ? J'aimerais pouvoir ajouter une note sur mon wiki, concernant ses deux commandes, mais, je n'ai pas trouvé d'informations en première lecture. Pourquoi ouvrir le multicast ? Pourquoi ouvrir IGMP ? La règle que je suis entrain d'écrire, mais, pas encore appliquée, est la suivante : https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_propos.C3.A9e_pour_configurer_Iptables_par_d.C3.A9faut Merci de vos avis, si quelque chose n'est pas cohérent, que je puisse améliorer ce script. Je l'utilise ici pour un VPS OVH, sur Debian, qui est utilisé pour serveur web avec Apache , mariaDB, et, avec un serveur FTP ProFTPd. Le 17/09/2019 à 12:19, Daniel Huhardeaux a écrit : > Le 17/09/2019 à 12:12, G2PC a écrit : >> Bonjour, >> Du coup, si je bloque tout ce dont je n'ai pas besoin, mais, que IPV6 >> en aurait besoin, je ne suis pas plus avancé. > > iptables est pour ipv4 ip6tables est pour ipv6, ce ne sont pas les > mêmes commandes. Pour nft n'utilises pas inet mais ip ou ipv6 si tu > veux différencier. > >> >> Bon, je n'utilise pas IPV6 pour le moment, mais, j'aurais aimé avoir >> plus d'informations sur les règles présentées, pour savoir justement >> si il y a du sens à les mettre en place, les autoriser, ou, les refuser. >> C'est bien car je ne sais pas que j'ai posté cette demande. J'ai pu >> voir de nombreux sites proposer de DROP ou ACCEPT ces paquets, mais, >> sans plus d'informations que cela. > > Ce que dit Pascal c'est que tu DROP par défaut et ensuite tu acceptes > ce qui t'es nécessaire. Du coup tu ne t'occupes pas du multicast (ou > tout autre) sauf si tu veux l'ouvrir. > >> >> Merci de vos avis. >> >> # DROP le Multicast : >> # Ce système est plus efficace que l'unicast pour diffuser des >> contenus simultanément vers une large audience. (Audio, Vidéo.) >> -A INPUT -m pkttype --pkt-type multicast -j DROP >> -A FORWARD -m pkttype --pkt-type multicast -j DROP >> -A OUTPUT -m pkttype --pkt-type multicast -j DROP >> >> # DROP IGMP : >> # Également pour bloquer le multicast ? Quelle méthode préférer, les >> deux ? >> # Si nécessaire, tenter de logger tout paquet igmp sans spécifier de >> source pour voir ce que ça donne dans "/var/log/syslog". >> # iptables -A INPUT -p igmp -j LOG --log-level info --log-prefix >> "IGMP: " >> # L'IGMP est un protocole standard utilisé par la suite de protocoles >> TCP/IP pour la multidiffusion dynamique, le multicast. >> -A INPUT -p igmp -j DROP >> -A FORWARD -p igmp -j DROP >> -A OUTPUT -p igmp -j DROP >> >> >> >> Le 16/09/2019 à 20:48, Pascal Hambourg a écrit : >>> Le 16/09/2019 à 12:57, G2PC a écrit : >>>> Bonjour, >>>> >>>> Je ne pense pas en avoir besoin pour le moment, d'utiliser le >>>> multicast, il me semble de ce fait inutile de l'autoriser dans ma >>>> configuration Iptables ? >>> >>> Il ne s'agit pas de penser mais de savoir. Si tu n'utilises pas le >>> multicast, tu n'as pas besoin de l'autoriser. >>> >>>> Par contre, je trouve deux types de règles via mes recherches, et, >>>> je ne suis pas très sur de la bonne façon de l'interdire. >>> >>> Il suffit de ne pas l'autoriser. Tu interdis tout par défaut et >>> n'autorises que ce dont tu as besoin, n'est-ce pas ? >>> >>>> # DROP IGMP : >>>> # Également pour bloquer le multicast ? Quelle méthode préférer, >>>> les deux ? >>> >>> IGMP n'est pas le multicast, ce n'est que le protocole de gestion du >>> multicast. Tous les flux multicast ne font pas forcément l'objet >>> d'un abonnement avec IGMP. J'ignore si tout le trafic IGMP est aussi >>> en multicast. >>> >>> Note que si tu fais aussi du filtrage pour IPv6, réfléchis à deux >>> fois avant de bloquer du trafic multicast. Certains flux multicast >>> sont indispensables au bon fonctionnement d'IPv6. >>> >
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 17/09/2019 à 12:12, G2PC a écrit : Bonjour, Du coup, si je bloque tout ce dont je n'ai pas besoin, mais, que IPV6 en aurait besoin, je ne suis pas plus avancé. iptables est pour ipv4 ip6tables est pour ipv6, ce ne sont pas les mêmes commandes. Pour nft n'utilises pas inet mais ip ou ipv6 si tu veux différencier. Bon, je n'utilise pas IPV6 pour le moment, mais, j'aurais aimé avoir plus d'informations sur les règles présentées, pour savoir justement si il y a du sens à les mettre en place, les autoriser, ou, les refuser. C'est bien car je ne sais pas que j'ai posté cette demande. J'ai pu voir de nombreux sites proposer de DROP ou ACCEPT ces paquets, mais, sans plus d'informations que cela. Ce que dit Pascal c'est que tu DROP par défaut et ensuite tu acceptes ce qui t'es nécessaire. Du coup tu ne t'occupes pas du multicast (ou tout autre) sauf si tu veux l'ouvrir. Merci de vos avis. # DROP le Multicast : # Ce système est plus efficace que l'unicast pour diffuser des contenus simultanément vers une large audience. (Audio, Vidéo.) -A INPUT -m pkttype --pkt-type multicast -j DROP -A FORWARD -m pkttype --pkt-type multicast -j DROP -A OUTPUT -m pkttype --pkt-type multicast -j DROP # DROP IGMP : # Également pour bloquer le multicast ? Quelle méthode préférer, les deux ? # Si nécessaire, tenter de logger tout paquet igmp sans spécifier de source pour voir ce que ça donne dans "/var/log/syslog". # iptables -A INPUT -p igmp -j LOG --log-level info --log-prefix "IGMP: " # L'IGMP est un protocole standard utilisé par la suite de protocoles TCP/IP pour la multidiffusion dynamique, le multicast. -A INPUT -p igmp -j DROP -A FORWARD -p igmp -j DROP -A OUTPUT -p igmp -j DROP Le 16/09/2019 à 20:48, Pascal Hambourg a écrit : Le 16/09/2019 à 12:57, G2PC a écrit : Bonjour, Je ne pense pas en avoir besoin pour le moment, d'utiliser le multicast, il me semble de ce fait inutile de l'autoriser dans ma configuration Iptables ? Il ne s'agit pas de penser mais de savoir. Si tu n'utilises pas le multicast, tu n'as pas besoin de l'autoriser. Par contre, je trouve deux types de règles via mes recherches, et, je ne suis pas très sur de la bonne façon de l'interdire. Il suffit de ne pas l'autoriser. Tu interdis tout par défaut et n'autorises que ce dont tu as besoin, n'est-ce pas ? # DROP IGMP : # Également pour bloquer le multicast ? Quelle méthode préférer, les deux ? IGMP n'est pas le multicast, ce n'est que le protocole de gestion du multicast. Tous les flux multicast ne font pas forcément l'objet d'un abonnement avec IGMP. J'ignore si tout le trafic IGMP est aussi en multicast. Note que si tu fais aussi du filtrage pour IPv6, réfléchis à deux fois avant de bloquer du trafic multicast. Certains flux multicast sont indispensables au bon fonctionnement d'IPv6.
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Bonjour, Du coup, si je bloque tout ce dont je n'ai pas besoin, mais, que IPV6 en aurait besoin, je ne suis pas plus avancé. Bon, je n'utilise pas IPV6 pour le moment, mais, j'aurais aimé avoir plus d'informations sur les règles présentées, pour savoir justement si il y a du sens à les mettre en place, les autoriser, ou, les refuser. C'est bien car je ne sais pas que j'ai posté cette demande. J'ai pu voir de nombreux sites proposer de DROP ou ACCEPT ces paquets, mais, sans plus d'informations que cela. Merci de vos avis. # DROP le Multicast : # Ce système est plus efficace que l'unicast pour diffuser des contenus simultanément vers une large audience. (Audio, Vidéo.) -A INPUT -m pkttype --pkt-type multicast -j DROP -A FORWARD -m pkttype --pkt-type multicast -j DROP -A OUTPUT -m pkttype --pkt-type multicast -j DROP # DROP IGMP : # Également pour bloquer le multicast ? Quelle méthode préférer, les deux ? # Si nécessaire, tenter de logger tout paquet igmp sans spécifier de source pour voir ce que ça donne dans "/var/log/syslog". # iptables -A INPUT -p igmp -j LOG --log-level info --log-prefix "IGMP: " # L'IGMP est un protocole standard utilisé par la suite de protocoles TCP/IP pour la multidiffusion dynamique, le multicast. -A INPUT -p igmp -j DROP -A FORWARD -p igmp -j DROP -A OUTPUT -p igmp -j DROP Le 16/09/2019 à 20:48, Pascal Hambourg a écrit : > Le 16/09/2019 à 12:57, G2PC a écrit : >> Bonjour, >> >> Je ne pense pas en avoir besoin pour le moment, d'utiliser le >> multicast, il me semble de ce fait inutile de l'autoriser dans ma >> configuration Iptables ? > > Il ne s'agit pas de penser mais de savoir. Si tu n'utilises pas le > multicast, tu n'as pas besoin de l'autoriser. > >> Par contre, je trouve deux types de règles via mes recherches, et, je >> ne suis pas très sur de la bonne façon de l'interdire. > > Il suffit de ne pas l'autoriser. Tu interdis tout par défaut et > n'autorises que ce dont tu as besoin, n'est-ce pas ? > >> # DROP IGMP : >> # Également pour bloquer le multicast ? Quelle méthode préférer, les >> deux ? > > IGMP n'est pas le multicast, ce n'est que le protocole de gestion du > multicast. Tous les flux multicast ne font pas forcément l'objet d'un > abonnement avec IGMP. J'ignore si tout le trafic IGMP est aussi en > multicast. > > Note que si tu fais aussi du filtrage pour IPv6, réfléchis à deux fois > avant de bloquer du trafic multicast. Certains flux multicast sont > indispensables au bon fonctionnement d'IPv6. >
Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
Le 16/09/2019 à 12:57, G2PC a écrit : Bonjour, Je ne pense pas en avoir besoin pour le moment, d'utiliser le multicast, il me semble de ce fait inutile de l'autoriser dans ma configuration Iptables ? Il ne s'agit pas de penser mais de savoir. Si tu n'utilises pas le multicast, tu n'as pas besoin de l'autoriser. Par contre, je trouve deux types de règles via mes recherches, et, je ne suis pas très sur de la bonne façon de l'interdire. Il suffit de ne pas l'autoriser. Tu interdis tout par défaut et n'autorises que ce dont tu as besoin, n'est-ce pas ? # DROP IGMP : # Également pour bloquer le multicast ? Quelle méthode préférer, les deux ? IGMP n'est pas le multicast, ce n'est que le protocole de gestion du multicast. Tous les flux multicast ne font pas forcément l'objet d'un abonnement avec IGMP. J'ignore si tout le trafic IGMP est aussi en multicast. Note que si tu fais aussi du filtrage pour IPv6, réfléchis à deux fois avant de bloquer du trafic multicast. Certains flux multicast sont indispensables au bon fonctionnement d'IPv6.
Faut t'il bloquer le Multicast - IGMP avec Iptables
Bonjour, Je ne pense pas en avoir besoin pour le moment, d'utiliser le multicast, il me semble de ce fait inutile de l'autoriser dans ma configuration Iptables ? Par contre, je trouve deux types de règles via mes recherches, et, je ne suis pas très sur de la bonne façon de l'interdire. Je proposerais éventuellement cette approche, mais, pouvez vous me confirmer que bloquer ainsi le multicast est fonctionnel et cohérent ? # DROP le Multicast : # Ce système est plus efficace que l'unicast pour diffuser des contenus simultanément vers une large audience. (Audio, Vidéo.) -A INPUT -m pkttype --pkt-type multicast -j DROP -A FORWARD -m pkttype --pkt-type multicast -j DROP -A OUTPUT -m pkttype --pkt-type multicast -j DROP # DROP IGMP : # Également pour bloquer le multicast ? Quelle méthode préférer, les deux ? # Si nécessaire, tenter de logger tout paquet igmp sans spécifier de source pour voir ce que ça donne dans "/var/log/syslog". # iptables -A INPUT -p igmp -j LOG --log-level info --log-prefix "IGMP: " # L'IGMP est un protocole standard utilisé par la suite de protocoles TCP/IP pour la multidiffusion dynamique, le multicast. -A INPUT -p igmp -j DROP -A FORWARD -p igmp -j DROP -A OUTPUT -p igmp -j DROP Merci,
Re: Exemple iptables ultimes
Hello, Le 10/09/2019 à 18:47, Olivier a écrit : Je viens bientôt installer plusieurs machines sous Stretch ou Buster qui vont hériter d'une IP publique alors que j'ai plutôt l'habitude de configurer des machines protégées de la jungle d'Internet par un routeur et le NAT. Ces machines (Core i3 ou i5) doivent principalement assurer le routage de réseaux locaux avec l'ambition d'offrir les meilleures performances possibles (pour fixer un ordre de grandeur, je dirai qu'elles doivent pouvoir NATer un traffic de.l'ordre de 500Mb/s). Sans même avoir à "tweaker" la configuration iptables et du kernel, J'ai eu une machine à base d'Atom (N270 si je dis pas trop de bêtises) qui "nattait" sans sourciller 200Mb/s il y a 3 ans, mais la machine datait de 8 ou 9 ans. Donc un i3 ou i5 moderne, la question ne se pose même pas pour 500Mb/s. En fait ce n'est pas tant le débit qui doit être source d'inquiétude, mais plutôt le nombre de paquets/s ou le nombre de nouvelles connexions à la seconde, d'autant plus quand c'est du trafic à bloquer (ça, ça peut mettre une machine par terre, Expérience vécue). Et point important, ce sont les cartes réseau qui équipent la machine. L'expérience m'indique que les cartes réseau Intel sont idéales pour ce genre de configuration, surtout parce que le driver Linux (e1000 pour référence) a été en grosse partie développé par les ingénieurs d'Intel eux-même. @+ Christophe.
Re: Exemple iptables ultimes
Voici un lien [1] qui traite du sujet. [1] https://geekeries.org/2017/12/configuration-avancee-du-firewall-iptables/ Le mar. 10 sept. 2019 à 18:01, Olivier a écrit : > Hello, > > Je viens bientôt installer plusieurs machines sous Stretch ou Buster qui > vont hériter d'une IP publique alors que j'ai plutôt l'habitude de > configurer des machines protégées de la jungle d'Internet par un routeur et > le NAT. > > Ces machines (Core i3 ou i5) doivent principalement assurer le routage de > réseaux locaux avec l'ambition d'offrir les meilleures performances > possibles (pour fixer un ordre de grandeur, je dirai qu'elles doivent > pouvoir NATer un traffic de.l'ordre de 500Mb/s). > > Quelqu'un aurait-il un exemple de configuration iptables ultime, adaptable > à un tel contexte, et éprouvée avec des mois (années) de pratique ? > > J'ai lu ici ou làdes exemples où l'auteur, par exemple, prenait soin > d'écarter du trafic volontairement mal-formé (DoS) mais un exemple > exhaustif ne serait pas de refus. > > Slts >
Exemple iptables ultimes
Hello, Je viens bientôt installer plusieurs machines sous Stretch ou Buster qui vont hériter d'une IP publique alors que j'ai plutôt l'habitude de configurer des machines protégées de la jungle d'Internet par un routeur et le NAT. Ces machines (Core i3 ou i5) doivent principalement assurer le routage de réseaux locaux avec l'ambition d'offrir les meilleures performances possibles (pour fixer un ordre de grandeur, je dirai qu'elles doivent pouvoir NATer un traffic de.l'ordre de 500Mb/s). Quelqu'un aurait-il un exemple de configuration iptables ultime, adaptable à un tel contexte, et éprouvée avec des mois (années) de pratique ? J'ai lu ici ou làdes exemples où l'auteur, par exemple, prenait soin d'écarter du trafic volontairement mal-formé (DoS) mais un exemple exhaustif ne serait pas de refus. Slts
Re: Retour d'expérience sur la geo-localisation par iptables
Le mardi 30 juillet 2019 à 13:57 +0200, Ph. Gras a écrit : > Si le trafic est effectivement destiné à être circonscrit à une zone > géographique spécifiée, il conviendrait plutôt d'exclure toutes les > zones à l'exception de la zone cible. On peut le faire efficacement > dans la configuration de son serveur Web, et pour un MTA je ne > sais pas… Mais c'est très restrictif : pour l'utilisateur, interdit de > partir en vacances à l'étranger ! Peut-être pour une école, alors ? D'autant que le VPN est à la mode... je me demande si identifier les plages d'IP n'est pas beaucoup plus productif que la géolocalisation sans avoir les outils d'espionnage généralisés qui vont avec... Bref, banir les pays entiers c'est plutôt pour moi une méthode qui fleure bon la nostalgie des temps passés, ainsi qu'une manière très peu subtile et avec des effets secondaire potentiellement importants pour résoudre ce genre de problème.
Re: Retour d'expérience sur la geo-localisation par iptables
> Le 30 juil. 2019 à 13:57, Ph. Gras a écrit :
>
> Salut la liste !
>
>> En combinant iptable avec le résultat d’un :
>> whois ${IP} | grep '^country:FR'
>> par exemple. Mais cela risque de ralentir sensiblement le processus…
>
> D'après ce que j'ai vu, ce n'est pas tellement le pays qui pose problème dans
> le sens où il existe énormément de zombies partout,
> que le type de requêtes effectuées… et là, on est ramené au classicisme du
> problème précédent !
>
> Ceci dit, j'ai en effet constaté des zones géographiques potentiellement
> casse-pieds, dès qu'une tension géopolitique se fait jour,
> Mais ça ne dure que le temps que le contexte s'apaise et que la situation
> revienne à la normale.
Effectivement, chez nous, ce sont ces adresses :
- ^[^@]+@(.*\.)?eu$
- ^[^@]+@(.*\.)?press$
- ^[^@]+@(.*\.)?co\.ua$
- ^[^@]+@(.*\.)?co\.za$
- ^[^@]+@(.*\.)?biz\.ua$
- ^[^@]+@(.*\.)?oicp\.net$
- ^[^@]+@(.*\.)?icu$
qui sont systématiquement rejetées.
C’est souvent les services mails et DNS qui sont ciblés mais aussi les services
Web (http, https).
Dans ce cas, selon le service, j’ai mis en place un petit outil très drastique
qui, combiné avec Fail2ban, blacklist systématiquement les emm… dans une base
de donnée automatiquement après 10 tentatives répétée sur le même service. Ça
évite certains lourdingues mais pas tous. Par exemple beaucoup d’adresses
Amazon… qui changent souvent d'IP (no comments sur le sérieux du prestataire).
Cela oblige quand même à une vérification régulière, histoire de ne pas bloquer
un correspondant de bonne foi (faux positif).
Si ça vous intéresse, faites un tour sur :
https://www.cybernaute.ch/bannir-definitivement-ip-bannies-frequemment-fail2ban/
Ce système a au moins l’avantage de ne pas trop ralentir le traitement mais il
faut bien savoir qu’il n’existe aucun système efficace à 100%.
>
>>>
>>> J'envisage de protéger quelques serveurs par des règles iptables rejetant
>>> des requêtes ne provenant pas de certains pays.
>
> Si le trafic est effectivement destiné à être circonscrit à une zone
> géographique spécifiée, il conviendrait plutôt d'exclure toutes les
> zones à l'exception de la zone cible. On peut le faire efficacement dans la
> configuration de son serveur Web, et pour un MTA je ne
> sais pas… Mais c'est très restrictif : pour l'utilisateur, interdit de partir
> en vacances à l'étranger ! Peut-être pour une école, alors ?
>
>>>
>>> Comme ces serveurs sont à destination de clients français, j'ai en tête de
>>> rejeter la terre entière sauf la France et quelques pays où des clients
>>> passeraient leurs vacances.
>>>
>>> Qui a déjà utilisé dans Debian un module déterminant le pays à partir d'une
>>> IP ?
>>> Quel retour d'expérience ?
>>> Avec la rareté des adresses IPv4 et j'imagine, la revente de plages entre
>>> opérateurs divers, une telle détection fonctionne-t-elle correctement pour
>>> la France ?
>>> Comment s'opère la mise à jour des règles ?
>
>
> J'ai développé deux extensions Wordpress utilisant la géolocalisation, avec
> envoi d'un message dans les logs en cas d'anomalie.
>
> Mais elle me sert uniquement comme élément d'information et pas de
> discrimination. Pour ce qui concerne le mailing, je reçois des
> notifications via le protocole DMARC et j'effectue des sondages incluant une
> géolocalisation, mais c'est purement informatif.
>
> Pour traiter la géolocalisation, il faut une table établissant la
> correspondance entre les IP et leur distribution spatiale. Donc l'analyse
> des données par le logiciel qui reçoit l'information. Les tables doivent être
> mises à jour régulièrement.
>
> Ce qui implique fatalement un ralentissement du processus, comme l'indique
> Pierre.
>
> Bonne journée,
>
> Ph. Gras
--
Pierre Malard
« La mondialisation de l'économie a, « en moyenne », eu pour conséquence
l'augmentation du niveau de vie « moyen ».
Un homme avec la tête dans un four et les jambes dans un congélateur a,
« en moyenne », une température corporelle idéale... »
Philippe Val - France Inter 09/04/2001
|\ _,,,---,,_
/,`.-'`'-. ;-;;,_
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_) πr
perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\
( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_):
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
signature.asc
Description: Message signed with OpenPGP
Re: Retour d'expérience sur la geo-localisation par iptables
Salut la liste !
> En combinant iptable avec le résultat d’un :
> whois ${IP} | grep '^country:FR'
> par exemple. Mais cela risque de ralentir sensiblement le processus…
D'après ce que j'ai vu, ce n'est pas tellement le pays qui pose problème dans
le sens où il existe énormément de zombies partout,
que le type de requêtes effectuées… et là, on est ramené au classicisme du
problème précédent !
Ceci dit, j'ai en effet constaté des zones géographiques potentiellement
casse-pieds, dès qu'une tension géopolitique se fait jour,
Mais ça ne dure que le temps que le contexte s'apaise et que la situation
revienne à la normale.
>>
>> J'envisage de protéger quelques serveurs par des règles iptables rejetant
>> des requêtes ne provenant pas de certains pays.
Si le trafic est effectivement destiné à être circonscrit à une zone
géographique spécifiée, il conviendrait plutôt d'exclure toutes les
zones à l'exception de la zone cible. On peut le faire efficacement dans la
configuration de son serveur Web, et pour un MTA je ne
sais pas… Mais c'est très restrictif : pour l'utilisateur, interdit de partir
en vacances à l'étranger ! Peut-être pour une école, alors ?
>>
>> Comme ces serveurs sont à destination de clients français, j'ai en tête de
>> rejeter la terre entière sauf la France et quelques pays où des clients
>> passeraient leurs vacances.
>>
>> Qui a déjà utilisé dans Debian un module déterminant le pays à partir d'une
>> IP ?
>> Quel retour d'expérience ?
>> Avec la rareté des adresses IPv4 et j'imagine, la revente de plages entre
>> opérateurs divers, une telle détection fonctionne-t-elle correctement pour
>> la France ?
>> Comment s'opère la mise à jour des règles ?
J'ai développé deux extensions Wordpress utilisant la géolocalisation, avec
envoi d'un message dans les logs en cas d'anomalie.
Mais elle me sert uniquement comme élément d'information et pas de
discrimination. Pour ce qui concerne le mailing, je reçois des
notifications via le protocole DMARC et j'effectue des sondages incluant une
géolocalisation, mais c'est purement informatif.
Pour traiter la géolocalisation, il faut une table établissant la
correspondance entre les IP et leur distribution spatiale. Donc l'analyse
des données par le logiciel qui reçoit l'information. Les tables doivent être
mises à jour régulièrement.
Ce qui implique fatalement un ralentissement du processus, comme l'indique
Pierre.
Bonne journée,
Ph. Gras
Re: Retour d'expérience sur la geo-localisation par iptables
Salut,
En combinant iptable avec le résultat d’un :
whois ${IP} | grep '^country:FR'
par exemple. Mais cela risque de ralentir sensiblement le processus…
> Le 30 juil. 2019 à 09:38, Olivier a écrit :
>
> Bonjour,
>
> J'envisage de protéger quelques serveurs par des règles iptables rejetant des
> requêtes ne provenant pas de certains pays.
>
> Comme ces serveurs sont à destination de clients français, j'ai en tête de
> rejeter la terre entière sauf la France et quelques pays où des clients
> passeraient leurs vacances.
>
> Qui a déjà utilisé dans Debian un module déterminant le pays à partir d'une
> IP ?
> Quel retour d'expérience ?
> Avec la rareté des adresses IPv4 et j'imagine, la revente de plages entre
> opérateurs divers, une telle détection fonctionne-t-elle correctement pour la
> France ?
> Comment s'opère la mise à jour des règles ?
> Suggestions ?
>
> Slts
--
Pierre Malard
« Si, comme le disait le général de Gaulle, la France n'avait pas été la
France... on peut logiquement penser que tous les français auraient été
des étrangers » ;-)
Pierre Dac
|\ _,,,---,,_
/,`.-'`'-. ;-;;,_
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_) πr
perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\
( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_):
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
signature.asc
Description: Message signed with OpenPGP
Retour d'expérience sur la geo-localisation par iptables
Bonjour, J'envisage de protéger quelques serveurs par des règles iptables rejetant des requêtes ne provenant pas de certains pays. Comme ces serveurs sont à destination de clients français, j'ai en tête de rejeter la terre entière sauf la France et quelques pays où des clients passeraient leurs vacances. Qui a déjà utilisé dans Debian un module déterminant le pays à partir d'une IP ? Quel retour d'expérience ? Avec la rareté des adresses IPv4 et j'imagine, la revente de plages entre opérateurs divers, une telle détection fonctionne-t-elle correctement pour la France ? Comment s'opère la mise à jour des règles ? Suggestions ? Slts
Re: [résolu] HS: iptables interface de sortie par la même que l'entrée.
Le 17/04/2019 à 23:49, Pascal Hambourg a écrit : > Le 17/04/2019 à 22:07, Jérémy Prego a écrit : >> Le 17/04/2019 à 21:51, Pascal Hambourg a écrit : >>>>> ) >>>> Par contre, l'inconvénient est que du coup j'ai 2 lignes par host au >>>> lieu d'une seul du coup ça va me doubler toute les rules. Je ne pense >>>> pas qu'on puisse réduire ça en une ligne ? >>> >>> Comment ça, par host ? Il y en a d'autres ? >> >> oui, quelques uns. >>> Combien ? >> >> plusieurs centaine. > > Alors ipset est probablement plus efficace que des centaines de règles. oui je suis en train de regarder, ça semble plus optimisé en effet :) et pas difficile a mettre en place. > >>> Tu peux factoriser l'adresse grâce à une autre chaîne utilisateur. >> >> ??? > > iptables -t mangle -N ROUTING-POLICY > iptables -t mangle -N ROUTING-POLICY-2 > > iptables -t mangle -A ROUTING-POLICY -d adresse1 -j ROUTING-POLICY-2 > iptables -t mangle -A ROUTING-POLICY -d adresse2 -j ROUTING-POLICY-2 > iptables -t mangle -A ROUTING-POLICY -d adresse3 -j ROUTING-POLICY-2 > ... > iptables -t mangle -A ROUTING-POLICY-2 -m conntrack --ctstate NEW -j > CONNMARK --set-mark 0x1 > iptables -t mangle -A ROUTING-POLICY-2 -j CONNMARK --restore-mark > merci beaucoup pour tout ! Jerem
Re: [quasi résolu] HS: iptables interface de sortie par la même que l'entrée.
Le 17/04/2019 à 22:07, Jérémy Prego a écrit : Le 17/04/2019 à 21:51, Pascal Hambourg a écrit : ) Par contre, l'inconvénient est que du coup j'ai 2 lignes par host au lieu d'une seul du coup ça va me doubler toute les rules. Je ne pense pas qu'on puisse réduire ça en une ligne ? Comment ça, par host ? Il y en a d'autres ? oui, quelques uns. Combien ? plusieurs centaine. Alors ipset est probablement plus efficace que des centaines de règles. Tu peux factoriser l'adresse grâce à une autre chaîne utilisateur. ??? iptables -t mangle -N ROUTING-POLICY iptables -t mangle -N ROUTING-POLICY-2 iptables -t mangle -A ROUTING-POLICY -d adresse1 -j ROUTING-POLICY-2 iptables -t mangle -A ROUTING-POLICY -d adresse2 -j ROUTING-POLICY-2 iptables -t mangle -A ROUTING-POLICY -d adresse3 -j ROUTING-POLICY-2 ... iptables -t mangle -A ROUTING-POLICY-2 -m conntrack --ctstate NEW -j CONNMARK --set-mark 0x1 iptables -t mangle -A ROUTING-POLICY-2 -j CONNMARK --restore-mark
Re: [quasi résolu] HS: iptables interface de sortie par la même que l'entrée.
Le 17/04/2019 à 21:51, Pascal Hambourg a écrit : >>> ) >> Par contre, l'inconvénient est que du coup j'ai 2 lignes par host au >> lieu d'une seul du coup ça va me doubler toute les rules. Je ne pense >> pas qu'on puisse réduire ça en une ligne ? > > Comment ça, par host ? Il y en a d'autres ? oui, quelques uns. > Combien ? plusieurs centaine. en fait, je fais passer des services par des connexion différentes, mais il arrive que ces mêmes service doivent pouvoir contacter la connexion principal du routeur. ssh, http, dns ... > La liste est fixe ou dynamique ? > plutot fixe, il m'arrive parfois d'ajouter des adresses mais ça ne change pas souvent. > Tu peux factoriser l'adresse grâce à une autre chaîne utilisateur. ??? > Tu peux utiliser ipset pour gérer une liste d'adresses. Merci, je vais regarder. Jerem
Re: [quasi résolu] HS: iptables interface de sortie par la même que l'entrée.
Le 17/04/2019 à 18:14, Jérémy Prego a écrit : Le 17/04/2019 à 07:27, Pascal Hambourg a écrit : Le 16/04/2019 à 18:44, Jérémy Prego a écrit : iptables -t mangle -A ROUTING-POLICY -d jeremy.domain.net -m conntrack --ctstate NEW -j CONNMARK --set-mark 0x1 iptables -t mangle -A ROUTING-POLICY -d jeremy.domain.net -j CONNMARK --restore-markc(...) Par contre, l'inconvénient est que du coup j'ai 2 lignes par host au lieu d'une seul du coup ça va me doubler toute les rules. Je ne pense pas qu'on puisse réduire ça en une ligne ? Comment ça, par host ? Il y en a d'autres ? Combien ? La liste est fixe ou dynamique ? Tu peux factoriser l'adresse grâce à une autre chaîne utilisateur. Tu peux utiliser ipset pour gérer une liste d'adresses.
Re: [quasi résolu] HS: iptables interface de sortie par la même que l'entrée.
Le 17/04/2019 à 07:27, Pascal Hambourg a écrit : >> Le 16/04/2019 à 18:44, Jérémy Prego a écrit : >>> j'ai testé ça qui ne fonctionne pas non plus: >>> iptables -t mangle -D ROUTING-POLICY -d jeremy.domain.net -m conntrack >>> --ctstate NEW -j CONNMARK --set-mark 0x1 >>> iptables -t mangle -A ROUTING-POLICY -d jeremy.domain.net -j CONNMARK >>> --restore-markc >> Je suppose que -D et --restore-markc sont des erreurs de copier-coller ? > oui > >> Qu'est-ce qui se passe exactement ? >> > ça ne sort pas du tout ... c'est pour ça que j'aimerai bien un peu > d'aide sur les règles a appliquer vraiment pour comprendre parce que là > je patauge vraiment. j'ai aucune idée de ce qu'est une bonne règle dans > ce cas précis. re, bon alors, voyant que ça ne fonctionnait pas j'ai décidé de partir sur une vm fraîche pour faire des tests et effectivement ça fonctionne ! du coup, merci beaucoup ! Par contre, l'inconvénient est que du coup j'ai 2 lignes par host au lieu d'une seul du coup ça va me doubler toute les rules. Je ne pense pas qu'on puisse réduire ça en une ligne ? > Jerem
Re: HS: iptables interface de sortie par la même que l'entrée.
Le 17/04/2019 à 07:27, Pascal Hambourg a écrit : > Le 16/04/2019 à 18:44, Jérémy Prego a écrit : >> >> j'ai testé ça qui ne fonctionne pas non plus: >> iptables -t mangle -D ROUTING-POLICY -d jeremy.domain.net -m conntrack >> --ctstate NEW -j CONNMARK --set-mark 0x1 >> iptables -t mangle -A ROUTING-POLICY -d jeremy.domain.net -j CONNMARK >> --restore-markc > > Je suppose que -D et --restore-markc sont des erreurs de copier-coller ? oui > Qu'est-ce qui se passe exactement ? > ça ne sort pas du tout ... c'est pour ça que j'aimerai bien un peu d'aide sur les règles a appliquer vraiment pour comprendre parce que là je patauge vraiment. j'ai aucune idée de ce qu'est une bonne règle dans ce cas précis. Jerem
Re: HS: iptables interface de sortie par la même que l'entrée.
Le 16/04/2019 à 18:44, Jérémy Prego a écrit : j'ai testé ça qui ne fonctionne pas non plus: iptables -t mangle -D ROUTING-POLICY -d jeremy.domain.net -m conntrack --ctstate NEW -j CONNMARK --set-mark 0x1 iptables -t mangle -A ROUTING-POLICY -d jeremy.domain.net -j CONNMARK --restore-markc Je suppose que -D et --restore-markc sont des erreurs de copier-coller ? Qu'est-ce qui se passe exactement ?
Re: HS: iptables interface de sortie par la même que l'entrée.
Le 16/04/2019 à 18:44, Jérémy Prego a écrit : Le 16/04/2019 à 07:05, Pascal Hambourg a écrit : Le 16/04/2019 à 03:48, Jérémy Prego a écrit : Le 15/04/2019 à 20:18, Pascal Hambourg a écrit : Si je comprends bien tu veux marquer seulement les paquets des connexions sortantes. Une solution consiste à utiliser le marquage de connexion avec la cible CONNMARK et la correspondance connmark. pourrais-tu m'éclaircir sur cette partie en me fournissant un exemple de règle ? je trouve rien qui correspond vraiment après avoir testé plusieurs règles trouvé et adapté ici et là ... par exemple j'ai trouvé et adapté une règles comme ça: iptables -t mangle -A ROUTING-POLICY -d jeremy.domain.net -m conntrack --ctstate NEW -j CONNMARK --set-mark 0x3 iptables -t mangle -A ROUTING-POLICY -j CONNMARK --restore-mark vu que ça ne correspond pas tout à fait à ce que tu indiques plus haut et que le résultat n'est pas vraiment celui attendu je suppose que je suis pas bon. Un peu d'aide afin de comprendre comment former ma règle ne serait pas de refus. La seconde règle ne doit marquer que les paquets à destination de l'adresse distante. Il ne faut pas rerouter les paquets provenant de cette adresse. j'ai testé ça qui ne fonctionne pas non plus: iptables -t mangle -D ROUTING-POLICY -d jeremy.domain.net -m conntrack --ctstate NEW -j CONNMARK --set-mark 0x1 iptables -t mangle -A ROUTING-POLICY -d jeremy.domain.net -j CONNMARK --restore-markc de ce que j'ai lu, il semble falloir plusieurs règles par destination une pour marquer les paquets et une autre pour restaurer, mais une aide supplémentaire ne serait pas de refus parce que là j'arrive pas a grand chose. beaucoup de tuto que j'ai trouvé sur internet ne souhaite que faire de la répartition de charge et pas faire du routage avancé dans le sens un host // une connexion. ou alors, quand je trouve ça ça utilise encore -J MARK donc comme je fais jusqu'à présent. merci encore pour l'assistance. Tu as bien # marked packets go out through there route ip rule add fwmark $markISP1 table isp1 ip rule add fwmark $markISP2 table isp2 ? -- Daniel Huhardeaux +33.368460...@tootai.netsip:8...@sip.tootai.net +41.445532...@swiss-itech.ch tootaiNET
Re: HS: iptables interface de sortie par la même que l'entrée.
Le 16/04/2019 à 07:05, Pascal Hambourg a écrit : > Le 16/04/2019 à 03:48, Jérémy Prego a écrit : >> >> Le 15/04/2019 à 20:18, Pascal Hambourg a écrit : >>> Si je comprends bien tu veux marquer seulement les paquets des >>> connexions sortantes. Une solution consiste à utiliser le marquage de >>> connexion avec la cible CONNMARK et la correspondance connmark. >> >> pourrais-tu m'éclaircir sur cette partie en me fournissant un exemple de >> règle ? je trouve rien qui correspond vraiment après avoir testé >> plusieurs règles trouvé et adapté ici et là ... >> >> par exemple j'ai trouvé et adapté une règles comme ça: >> iptables -t mangle -A ROUTING-POLICY -d jeremy.domain.net -m conntrack >> --ctstate NEW -j CONNMARK --set-mark 0x3 >> iptables -t mangle -A ROUTING-POLICY -j CONNMARK --restore-mark >> >> vu que ça ne correspond pas tout à fait à ce que tu indiques plus haut >> et que le résultat n'est pas vraiment celui attendu je suppose que je >> suis pas bon. Un peu d'aide afin de comprendre comment former ma règle >> ne serait pas de refus. > > La seconde règle ne doit marquer que les paquets à destination de > l'adresse distante. Il ne faut pas rerouter les paquets provenant de > cette adresse. > j'ai testé ça qui ne fonctionne pas non plus: iptables -t mangle -D ROUTING-POLICY -d jeremy.domain.net -m conntrack --ctstate NEW -j CONNMARK --set-mark 0x1 iptables -t mangle -A ROUTING-POLICY -d jeremy.domain.net -j CONNMARK --restore-markc de ce que j'ai lu, il semble falloir plusieurs règles par destination une pour marquer les paquets et une autre pour restaurer, mais une aide supplémentaire ne serait pas de refus parce que là j'arrive pas a grand chose. beaucoup de tuto que j'ai trouvé sur internet ne souhaite que faire de la répartition de charge et pas faire du routage avancé dans le sens un host // une connexion. ou alors, quand je trouve ça ça utilise encore -J MARK donc comme je fais jusqu'à présent. merci encore pour l'assistance. Jerem
Re: HS: iptables interface de sortie par la même que l'entrée.
Le 16/04/2019 à 03:48, Jérémy Prego a écrit : Le 15/04/2019 à 20:18, Pascal Hambourg a écrit : Si je comprends bien tu veux marquer seulement les paquets des connexions sortantes. Une solution consiste à utiliser le marquage de connexion avec la cible CONNMARK et la correspondance connmark. pourrais-tu m'éclaircir sur cette partie en me fournissant un exemple de règle ? je trouve rien qui correspond vraiment après avoir testé plusieurs règles trouvé et adapté ici et là ... par exemple j'ai trouvé et adapté une règles comme ça: iptables -t mangle -A ROUTING-POLICY -d jeremy.domain.net -m conntrack --ctstate NEW -j CONNMARK --set-mark 0x3 iptables -t mangle -A ROUTING-POLICY -j CONNMARK --restore-mark vu que ça ne correspond pas tout à fait à ce que tu indiques plus haut et que le résultat n'est pas vraiment celui attendu je suppose que je suis pas bon. Un peu d'aide afin de comprendre comment former ma règle ne serait pas de refus. La seconde règle ne doit marquer que les paquets à destination de l'adresse distante. Il ne faut pas rerouter les paquets provenant de cette adresse.
Re: HS: iptables interface de sortie par la même que l'entrée.
Le 15/04/2019 à 20:18, Pascal Hambourg a écrit : > Si je comprends bien tu veux marquer seulement les paquets des > connexions sortantes. Une solution consiste à utiliser le marquage de > connexion avec la cible >CONNMARK et la correspondance connmark. pourrais-tu m'éclaircir sur cette partie en me fournissant un exemple de règle ? je trouve rien qui correspond vraiment après avoir testé plusieurs règles trouvé et adapté ici et là ... par exemple j'ai trouvé et adapté une règles comme ça: iptables -t mangle -A ROUTING-POLICY -d jeremy.domain.net -m conntrack --ctstate NEW -j CONNMARK --set-mark 0x3 iptables -t mangle -A ROUTING-POLICY -j CONNMARK --restore-mark vu que ça ne correspond pas tout à fait à ce que tu indiques plus haut et que le résultat n'est pas vraiment celui attendu je suppose que je suis pas bon. Un peu d'aide afin de comprendre comment former ma règle ne serait pas de refus. Merci beaucoup. Jerem
Re: HS: iptables interface de sortie par la même que l'entrée.
Le 15/04/2019 à 20:18, Pascal Hambourg a écrit : > Je n'ai rien compris. Et pourtant j'ai la prétention de m'y connaître > un peu. > oups, je n'utilise pas les bon termes. >> est-ce qu'une solution existe pour que si ça arrive par l'interface >> wan0, ça reparte par la même interface et que ça ne passe pas par les >> règle que j'ai mis pour l'output ? > > >> pour rappel, un petit exemple de ce que je fais: >> ##routage alternatif >> iptables -t mangle -N ROUTING-POLICY >> iptables -t mangle -A OUTPUT -j ROUTING-POLICY >> iptables -t mangle -A PREROUTING -j ROUTING-POLICY >> iptables -t mangle -D ROUTING-POLICY -d jeremy.domain.net -j MARK >> --set-mark 0x3 > > -D, vraiment ? non, -A bien entendu. erreur de copier / coller. > > C'est du routage avancé, pas de la redirection. Pas étonnant que je > n'ai rien compris. oui, routage avancé, pardon. au temps pour moi. > > Si je comprends bien tu veux marquer seulement les paquets des > connexions sortantes. Une solution consiste à utiliser le marquage de > connexion avec la cible CONNMARK et la correspondance connmark. oui, exactement. du coup je vais tester ça, merci. > Une autre possibilité plus simple mais probablement incomplète > consiste à discriminer l'adresse source originelle de la connexion > avec l'option --ctorigsrc de la correspondance conntrack, en ajoutant > à la règle de marquage : > > -m conntrack ! --ctorigsrc jeremy.domain.net > ça pour le coup j'ai pas trop compris, mais je relierai ça si la solution 1 ne fonctionne pas :) Merci Pascal. Jerem
