logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#76 07-08-2019 15:34:41

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

oui je suppose qu'il est possible d' autoriser le switch a le faire
oui une route 192.168.1.0/24 => 192.168.10.0/24
autoriser uniquement 192.168.1.2 en entrée
ou une route 192.168.1.2 => 192.168.10.1
ça dépasse mes compétences  tongue


Vraiment ? Voyons ça…
Il faut autoriser les connexions ayant pour adresse source 192.168.1.2 vers 192.168.1.10 sur
le port 123 en udp. Donc c'est  dans la chaîne input de la table filter de la passerelle.
Un truc comme


ip saddr 192.168.1.2 ip daddr 192.168.1.10 udp dport 123 accept
 


Et voilà…

Hors ligne

#77 07-08-2019 15:41:38

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

enicar a écrit :

anonyme a écrit :

actuellement on a un drop sur "enp6s0f0" et accept sur "enp6s0f1" ?


En effet.


Pas tout à fait, le trafic qui arrive sur enp6s0f1 est accepté en input et dans forward.
Le trafic qui arrive sur lo est accepté en input.
Tout le reste du trafic qui n'est pas autorisé via le système de suivi de connexion
est interdit.
Je veux dire par là que si tu rajoutes un vpn, les mêmes règles seront appliquées
à l'interface réseau du vpn.

Dernière modification par enicar (07-08-2019 15:43:26)

Hors ligne

#78 07-08-2019 15:46:45

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

'ai beaucoup de log input-drop , je pense qu il vaut mieux supprimer la ligne log (je sais pas si les commentaires sont accepté je ne pense pas (par un # par exemple) ).
l'utiliser seulement pour surveiller et en cas de problème


Tu peux mettre un # pour commenter une règle, ça marche.

Dernière modification par enicar (07-08-2019 15:47:01)

Hors ligne

#79 07-08-2019 15:50:31

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur une passerelle

j'ai pris deux lignes , dans les plus récentes


Aug  7 16:23:19 debian1 kernel: [ 5470.014240] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2

Aug  7 16:03:51 debian1 kernel: [ 4302.235896] INVALID_INPUT IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a4:3e:51:5b:f9:1b:08:00 SRC=195.88.84.110 DST=192.168.1.10 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=443 DPT=42628 WINDOW=0 RES=0x
00 RST URGP=0
 



la première je sais pas pourquoi (pas d IP ) ce quel veut dire
la seconde celui la "195.88.84.110" a tenter d'atteindre 192.168.1.10

pour ntpd dans /etc/openntpd/ntpd.conf


# $OpenBSD: ntpd.conf,v 1.14 2015/07/15 20:28:37 ajacoutot Exp $
# sample ntpd configuration file, see ntpd.conf(5)

# Addresses to listen on (ntpd does not listen by default)
#listen on *
listen on 127.0.0.1
#listen on ::1
listen on 192.168.10.1

# sync to a single server
#server ntp.example.org

# use a random selection of NTP Pool Time Servers
# see http://support.ntp.org/bin/view/Servers/NTPPoolServers
#servers pool.ntp.org

# Choose servers announced from Debian NTP Pool
servers 0.debian.pool.ntp.org
servers 1.debian.pool.ntp.org
servers 2.debian.pool.ntp.org
servers 3.debian.pool.ntp.org

# use a specific local timedelta sensor (radio clock, etc)
#sensor nmea0

# use all detected timedelta sensors
#sensor *
 



il suffit d'ajouter


listen on 127.0.0.1  => pour le serveur
listen on 192.168.10.1 => pour le sous réseau
listen on 192.168.1.10 => pour le réseau local
 


l'IPV6 normalement n'est pas actif

il est possible de mettre une table en place et de bloquer l'IPV6 sur la passerelle ?
pour l'instant on ne bloque rien

pour ceci c'est réglé aussi


journalctl -r -p err
 



-- Logs begin at Wed 2019-08-07 14:52:13 CEST, end at Wed 2019-08-07 16:48:39 CEST. --
-- No entries --
 



remarque:
pour le serveur
la boucle locale est sollicité avec mon programme "FAH" , il faut aucun filtrage , pour l' envoie et la réception il utilise enp6s0f0.
comme c'est lui qui fait les demandes cela ne doit pas poser problème
pour les clients ça passe par la passerelle , et idem pour la boucle locale

je met le "#" en place sur "input" je laisse forward , a priori moins de messages
si besoin j' active les logs de nouveau

Dernière modification par anonyme (07-08-2019 15:57:20)

#80 07-08-2019 16:14:41

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

il est possible de mettre une table en place et de bloquer l'IPV6 sur la passerelle ?


Oui bien sûr. Au lieu de « table ip filter », tu mets « table ip6 filter » :


table ip6 filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif lo accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}
 


Avec ça tu autorises le trafic en entrée sur l'adresse [::1] qui est
l'interface lo. Le trafic en sortie est autorisé. Tout le reste est
interdit.

Hors ligne

#81 07-08-2019 16:59:40

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

la première je sais pas pourquoi (pas d IP ) ce quel veut dire


Si il y a une ip destination 224.0.0.1, je t'ai expliqué ce que c'était
dans le post #70 (enfin à peu près, ce sont des choses que je maîtrise pas
du tout).
La question, c'est pourquoi tu reçois de tels messages ? Et aussi
qu'est-ce qu'on en fait ? On peut les rejetter par exemples ou
les accepter (mais dans ce cas il faudrait savoir pourquoi,
à quoi ça va servir ?).

anonyme a écrit :

pour le serveur
la boucle locale est sollicité avec mon programme "FAH" , il faut aucun filtrage , pour l' envoie et la réception il utilise enp6s0f0.
comme c'est lui qui fait les demandes cela ne doit pas poser problème


C'est quoi FAH ?

Hors ligne

#82 07-08-2019 17:05:45

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

Pour voir comment sont organisés les hooks du noyau que l'on a utilisé :
https://wiki.nftables.org/wiki-nftables … lter_hooks
Et comme, j'ai utilisé les mêmes noms pour les chaînes que les hooks auxquels elles
sont attachées, c'est simple à suivre. Il faut garder ce schéma à l'esprit quand on
rédige des règles pour nftables (et iptables aussi, mais bon…).

Hors ligne

#83 07-08-2019 20:39:26

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur une passerelle

pour ceci :


ce sont des paquets igmp à destination d'une adresse multicast.
Ma bbox chez moi ne génère pas ce genre de choses. La livebox doit chercher
les groupes multicast (un truc qui permet d'envoyer des paquets à plusieurs
clients en même temps, mais contrairement au broadcast, il faut s'abonner
à un groupe multicat pour recvoir les paquets, c'est géré au niveau de routeurs
multicast, enfin  d'après ce que j'ai vaguement compris).
 


par exemple le daemon avahi pour debian


Avahi is a fully LGPL framework for Multicast DNS Service Discovery.
It allows programs to publish and discover services and hosts
running on a local network with no specific configuration. For
example you can plug into a network and instantly find printers to
print to, files to look at and people to talk to.

This package contains the Avahi Daemon which represents your machine
on the network and allows other applications to publish and resolve
mDNS/DNS-SD records.
 


cela n'a rien a faire sur le serveur surtout sur 192.168.1.10
les imprimantes réseau sont sur le sous-reseau 192.168.10.1 géré par cups (sans partage puisque les imprimante sont sur un switch )
donc soit c'est la livebox orange , soit le switch 192.168.1.2 mais je ne pense pas.
si je trouve la source j' essaierai de le désactiver , il y a ausi le PC de mon fils en windows 10 sur le réseau local 192.168.1.0/24

FAH (folding@home) c'est un utilitaire de calcul scientifique pour la médecine . il utilise gpu et cpu pour faire du calcul.
c'est une multitude de boucles en localhost , avec un client et un utilitaire de controle . (tout est a l' arrêt actuellement ).


La question, c'est pourquoi tu reçois de tels messages ? Et aussi
qu'est-ce qu'on en fait ?
 


a rejeter , aucune utilité dans mon utilisation.

je vais m'occuper des clients  aussi , pour nftables

je vais appliquer les règles pour l' IPv6 et voir les ping sur le sous réseau (nom et IP).

Nota:
les messages de nftables ce sont arrêté a 17h21 depuis plus rien sur le syslog
si je trouve la source et la couper ,  j' activerai de nouveau le log  .

Dernière modification par anonyme (07-08-2019 20:47:22)

#84 07-08-2019 20:46:51

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

par exemple le daemon avahi pour debian


Bref, tu peux supprimer avahi, en effet. Moi, ça partie des softs que je vire
systématiquement après une nouvelle installation. Ou alors, il faudrait
lui interdire les paquets multicast en sortie mais pourquoi se compliquer
la vie ?

Hors ligne

#85 07-08-2019 20:51:49

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur une passerelle

c'est pas debian , et avahi n'est pas installé , de plus c'est du mauvais coté "192.168.1.10"
il n'y a pas de machine debian
non pas exemple si mon fils a sur sa carte réseau le multicast activé .
ou ma livebox  .....

désactivé l' UPNP sur la box.
pour le pc de mon fils quand il ne l'utilise plus

ps: la box voit 4 machines , la passerelle , le pc de mon fils (avec les noms netbios) et le switch et un pc , quelle nomme pc14 et pc16 (pas de nom réel netbios )
pour le switch ok même réseau , la deuxième machine c'est surprenant si du sous-réseau.
elle analyse les paquets tongue

sur ma machine windows que l IPv4 sur la carte réseau , tout le reste est désactivé
le pare feu tout bloqué sauf defender et le dns
mais bon lors de mise a jour tous se réactives faut être vigilant  roll

j'ai encore quelques lignes de ce genre


Aug  7 21:05:30 debian1 kernel: [22400.840591] INVALID_INPUT IN=enp6s0f0
OUT= MAC=bc:ee:7b:1c:c6:93:a4:3e:51:5b:f9:1b:08:00 SRC=92.123.226.129
DST=192.168.1.10 LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=8102 DF PROTO=TCP SPT=443 DPT=54537
WINDOW=254 RES=0x00 ACK FIN URGP=0
 


bien que le log soit désactivé

Dernière modification par anonyme (07-08-2019 21:54:51)

#86 07-08-2019 21:42:42

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

c'est pas debian , et avahi n'est pas installé , de plus c'est du mauvais coté "192.168.1.10"
il n'y a pas de machine debian


bon alors tu peux rajouter une règle pour rejeter ce trafic. Je ne sais pas si c'est
vraiment un bonne idée, mais bon ça sera pas pire que de le dropper.
je viens de lire ici que c'est utilisé
aussi par OSPF, un protocole de routage dynamique que tu n'utilises pas…

En bref je propose, d'insérer au début de la chaîne input de la table filter :


ip daddr 224.0.0.0/8 reject with icmp type admin-prohibited
 


Tu ne devrais plus rien voir dans les logs à ce sujet (au moins pour
la tranche allant de 224.0.0.0 à 224.0.0.255, c'est celle utilisé par OSPF
d'après la page wikipedia). D'ailleurs même sur ton réseau local ce type d'adresse
sera rejeté.
On peut faire différemment en refusant le protocole igmp (PROTO=2 dans les logs).
Ça donnerait :


ip protocol igmp reject with icmp type admin-prohibited
 


Pour les protocoles reconnus tu peux regarder dans le
fichier /etc/protocols (et pour les services dans /etc/services).
Ça permet de connaître le nom du protocole utilisé en fonction du numéro
et vice versa. La liste proposée n'est pas exhaustive, il y a juste les plus utilisés.

Dernière modification par enicar (07-08-2019 21:49:44)

Hors ligne

#87 07-08-2019 22:07:45

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur une passerelle

merci pour l'information
coté orange j'ai la télévision mais normalement non activé sur mon profil orange , mais activé sur la box.
avant d'activer cette règle je vais chercher la source
pour les risques ça n'a rien a faire sur la passerelle  hmm
ce fil va me servir encore longtemps
on peu dire que c'est résolu (en partie ) a mon avis cela ne l'est jamais .............
toujours un truc a optimisé roll

ps: l' IPv6 est désactivé aussi dans la box , mais je pense que orange peu le fournir , mon quartier est en fibre (pas moi).
depuis le passage a la fibre plus aucun de mes modems ADSL2 ne fonctionnent , obligé de louer une box.

#88 07-08-2019 22:19:36

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

j'ai encore quelques lignes de ce genre


Aug  7 21:05:30 debian1 kernel: [22400.840591] INVALID_INPUT IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a4:3e:51:5b:f9:1b:08:00 SRC=92.123.226.129 DST=192.168.1.10 LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=8102 DF PROTO=TCP SPT=443 DPT=54537 WINDOW=254
RES=0x00 ACK FIN URGP=0
 


bien que le log soit désactivé


En fait il reste encore la règle suivante :


ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop
 


qui peut générer des messages dans les logs. Ça veut dire que le système de
suivi de connexion a détecté un paquet invalide. Dans ma seconde version j'ai
différencié le prefix pour ces paquets qui sont détectés soit dans la chaîne
input soit dans la chaîne forward, en mettant : "INPUT_INVALID " pour la
première et "FORWARD_INVALID " pour la seconde. Mais quand on voit que la
destination est l'adresse 192.168.1.10 on comprend que cela a été généré dans
la chaîne input.

Sur ma machine j'ai même une règle pour détecter le paquets tcp
qui sont dans le status related et qui n'ont pas de syn.
Je m'explique. La séquence pour l'établissement d'une connexion tcp est :

  • J'envoie une demande de connexion en mettant le bit SYN du paquet tcp à 1

  • On me renvoie un paquet tcp avec le bit ACK et le bit SYN à 1

  • Je renvoie un paquet tcp avec le bit ACK à 1.


C'est une sorte de poignée de main qui permet de se dire on est prêt à
communiquer
Supposons que je veuille créer une nouvelle socket vers le port 80 d'un
serveur web (df.org par exemple). Donc je vais créer une socket :
(192.168.1.10, 2229) - (df.org, 80)
(le 2229 est au pif, c'est le système qui choisit).
Le premier paquet de cette socket sera un SYN (c'est à dire un paquet tcp
avec le bit SYN à 1). Normalement, df.org doit me répondre
sur la même socket tcp (c'est une communication bidirectionnelle) un paquet
avec le bit ACK à 1 et le bit SYN à 1. À ce moment là le système de suivi
de connexion  a déjà enregistré qu'il existait une connexion  pour cette
socket, et le paquet reçu a alors le status related. Pour que la socket
soit une communication complétement établie il faut que je réponde ACK,
au SYN de df.org.
Le truc, c'est qu'un site peut très bien me renvoyer des paquets sur la même
socket tant qu'elle est dans l'état related, et cela sans SYN.
Et une règle comme :


ct related,established accept
 


accepterait ces paquets. Donc il y a moyen de détecter ces paquets et de les
interdire. Je ne sais pas si c'est vraiment utile car le noyau devrait se
débarraser de ces paquets quoiqu'il en soit, puisque la poignée de main
n'a pas eu lieu.
Mais tout ceci nous emmène un peu loin…

Hors ligne

#89 08-08-2019 00:01:10

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

Si tu veux tu peux lire https://www.it-connect.fr/cours/filtrag … -nftables/.
C'est assez approximatif, mais ça permet de savoir utiliser un peu nft pour les applications
les plus courantes.

Hors ligne

#90 08-08-2019 12:07:08

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur une passerelle

pour le #86 j'ai mit la première ligne en place


chain INPUT {
                ip daddr 224.0.0.0/8 reject with icmp type admin-prohibited
                type filter hook input priority 0; policy drop;
 



j'ai ceci maintenant


Aug  8 12:34:10 debian1 kernel: [ 6694.262337] INPUT_DROP IN=enp6s0f0 OUT= MAC=ff:ff:ff:ff:ff:ff:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=192.168.1.255 LEN=236 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=216
Aug  8 12:34:10 debian1 kernel: [ 6694.262542] INPUT_DROP IN=enp6s0f0 OUT= MAC=ff:ff:ff:ff:ff:ff:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=192.168.1.255 LEN=236 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=216
Aug  8 12:46:14 debian1 kernel: [ 7418.535234] INPUT_DROP IN=enp6s0f0 OUT= MAC=ff:ff:ff:ff:ff:ff:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=192.168.1.255 LEN=236 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=216
Aug  8 12:46:14 debian1 kernel: [ 7418.535437] INPUT_DROP IN=enp6s0f0 OUT= MAC=ff:ff:ff:ff:ff:ff:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=192.168.1.255 LEN=236 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=216
 



comme le PC de mon fils doit ếtre éteint , je pense que ça vient de la box orange (je peu aussi sortir le câble réseau du 192.168.1.2 qui lui fourni le net )
ps: sur ce switch (8 ports netgear GS108T) il y a la box , la passerelle et le pc windows 10 de mon fils
la passerelle en sortie un switch basic 8 ports.

pour le #88 je pense aussi maintenant que je t' ai lu  wink

pour le #89 c'est un des premier lien que j'ai parcouru  roll

#91 08-08-2019 12:16:34

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

pour le #86 j'ai mit la première ligne en place


chain INPUT {
                ip daddr 224.0.0.0/8 reject with icmp type admin-prohibited
                type filter hook input priority 0; policy drop;
 


euh, il fallait mettre la règle après « type filter… » comme ça :


chain INPUT {
        type filter hook input priority 0; policy drop;
        ip daddr 224.0.0.0/8 reject with icmp type admin-prohibited
 


La première ligne n'est pas une règle mais déclare le type de chaîne
que ça doit être, le hook auquel elle est rattachée, la priorité
de traitement et la policy par défaut.

Hors ligne

#92 08-08-2019 12:25:34

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

j'ai ceci maintenant


Aug  8 12:34:10 debian1 kernel: [ 6694.262337] INPUT_DROP IN=enp6s0f0 OUT= MAC=ff:ff:ff:ff:ff:ff:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=192.168.1.255 LEN=236 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=216
Aug  8 12:34:10 debian1 kernel: [ 6694.262542] INPUT_DROP IN=enp6s0f0 OUT= MAC=ff:ff:ff:ff:ff:ff:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=192.168.1.255 LEN=236 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=216
Aug  8 12:46:14 debian1 kernel: [ 7418.535234] INPUT_DROP IN=enp6s0f0 OUT= MAC=ff:ff:ff:ff:ff:ff:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=192.168.1.255 LEN=236 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=216
Aug  8 12:46:14 debian1 kernel: [ 7418.535437] INPUT_DROP IN=enp6s0f0 OUT= MAC=ff:ff:ff:ff:ff:ff:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=192.168.1.255 LEN=236 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=216
 


Ça vient de ta box en effet, on le voit, c'est écrit : « SRC=192.168.1.1 ».
En effet c'est le netbios. Contrairement à ce que j'ai affirmé hier, j'ai aussi les paquets
igmp et ceux là chez moi qui sont issus de la bbox.
J'ai ajouté les deux règles suivantes :


protocol igmp reject with icmp type admin-prohibited
udp sport {137, 138} reject
 


Mais à vrai dire ce n'est pas absolument nécessaire. C'est juste pour avoir
moins de logs et pour pouvoir quand même voir ce qui se passe.

Reste à savoir où il faut les insérer… je te laisse faire.
Mais j'aimerais bien voir ton ensemble de règles en entier.

Hors ligne

#93 08-08-2019 12:30:08

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur une passerelle

tongue en tant que boulet officiel , tu me dit au début de la chain input tongue
mais bon j'ai eu un moment d' hésitation , et j'ai posté sur le forum la modif et j'ai bien fait smile
c'est modifié et appliqué


table ip filter {

        chain INPUT {
                type filter hook input priority 0; policy drop;
                ip daddr 224.0.0.0/8 reject with icmp type admin-prohibited
                iif lo accept
                iifname "enp6s0f1" accept
                ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop
                ct state established,related accept
                icmp type { destination-unreachable,time-exceeded, parameter-problem } accept
                log prefix "INPUT_DROP "
        }
 




bon sur la livebox j'ai pas la main sur ces annonces en "224.0"

#94 08-08-2019 12:30:46

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

pour le #89 c'est un des premier lien que j'ai parcouru


Je l'ai lu en entier hier soir tôt ce matin wink
Il n'est pas terrible ce cours. On peut y lire par exemple « un serveur protégé par ssh »
pouah ! Quelle bêtise big_smile (ce n'est pas bien de se moquer, mais on a le droit de rire !).
J'ai relevé d'autres choses qui sont vraiment plus qu'approximative… mais j'ai quand même
appris quels trucs au passage.

Hors ligne

#95 08-08-2019 12:34:13

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

bon sur la livebox j'ai pas la main sur ces annonces en "224.0"


C'est pareil avec la bbox, c'est quelque chose que je ne peux pas régler.

J'ai vu que ma machine envoyer des paquets snmp (enfin apparemment),
je pense que ça vient de systemd… il faudrait que je capture ces paquets pour voir
ce qu'il y a réellement dedans.

Hors ligne

#96 08-08-2019 12:35:52

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

tongue en tant que boulet officiel , tu me dit au début de la chain input tongue
mais bon j'ai eu un moment d' hésitation


Ceci dit, j'ai l'impression que ça marchait quand même. Mais il vaut mieux garder
une configuration claire et organisée.

Hors ligne

#97 08-08-2019 12:36:07

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur une passerelle

j' ajoute après le redémarrage de nftables


Aug  8 13:23:20 debian1 systemd[1]: Stopping nftables...
Aug  8 13:23:20 debian1 systemd[1]: nftables.service: Succeeded.
Aug  8 13:23:20 debian1 systemd[1]: Stopped nftables.
Aug  8 13:23:20 debian1 systemd[1]: Starting nftables...
Aug  8 13:23:20 debian1 systemd[1]: Started nftables.
Aug  8 13:23:25 debian1 kernel: [ 9649.342901] INVALID_INPUT IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a4:3e:51:5b:f9:1b:08:00 SRC=54.69.60.143 DST=192.168.1.10 LEN=52 TOS=0x00 PREC=0x00 TTL=231 ID=672 DF PROTO=TCP SPT=443 DPT=43376 WINDOW=125 RES=0x00 ACK URGP=0
Aug  8 13:23:26 debian1 kernel: [ 9650.366352] INVALID_INPUT IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a4:3e:51:5b:f9:1b:08:00 SRC=54.69.60.143 DST=192.168.1.10 LEN=52 TOS=0x00 PREC=0x00 TTL=231 ID=673 DF PROTO=TCP SPT=443 DPT=43376 WINDOW=125 RES=0x00 ACK URGP=0
Aug  8 13:23:27 debian1 kernel: [ 9651.389799] INVALID_INPUT IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a4:3e:51:5b:f9:1b:08:00 SRC=54.69.60.143 DST=192.168.1.10 LEN=52 TOS=0x00 PREC=0x00 TTL=231 ID=674 DF PROTO=TCP SPT=443 DPT=43376 WINDOW=125 RES=0x00 ACK URGP=0
Aug  8 13:23:28 debian1 kernel: [ 9652.413748] INVALID_INPUT IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a4:3e:51:5b:f9:1b:08:00 SRC=54.69.60.143 DST=192.168.1.10 LEN=52 TOS=0x00 PREC=0x00 TTL=231 ID=675 DF PROTO=TCP SPT=443 DPT=43376 WINDOW=125 RES=0x00 ACK URGP=0
 



nota: cette nuit j'ai coupé le serveur (pas de client) , depuis ce matin je fais des cat /var/log/syslog.1 , mon syslog est vide
le système continue d'écrire dans syslog.1  hmm

#98 08-08-2019 12:43:50

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

ota: cette nuit j'ai coupé le serveur (pas de client) , depuis ce matin je fais des cat /var/log/syslog.1 , mon syslog est vide
le système continue d'écrire dans syslog.1


La rotation des logs s'est mal passé… mais je ne sais pas
ce qu'il faut faire à part redémarrer rsyslog…

Hors ligne

#99 08-08-2019 12:48:34

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur une passerelle

pour ton #95  => https://fr.wikipedia.org/wiki/Simple_Ne … t_Protocol

comme le démon avahi , le genre de chose que j' évite d'utiliser  roll


apt-cache policy snmp
snmp:
  Installé : (aucun)
  Candidat : 5.7.3+dfsg-5
 Table de version :
     5.7.3+dfsg-5 500
        500 https://deb.debian.org/debian buster/main amd64 Packages
 


par contre j'ai des dépendances installé de snmp (libsnmp30 et libsnmp-base )
et il y a un démon "snmpd" pas installé

oui redémarrer le service ou le serveur pour le souci du syslog

Dernière modification par anonyme (08-08-2019 12:50:46)

#100 08-08-2019 12:56:31

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : [resolu]Migration de iptables a nftables sur une passerelle

anonyme a écrit :

j' ajoute après le redémarrage de nftables


Aug  8 13:23:20 debian1 systemd[1]: Stopping nftables...
Aug  8 13:23:20 debian1 systemd[1]: nftables.service: Succeeded.
Aug  8 13:23:20 debian1 systemd[1]: Stopped nftables.
Aug  8 13:23:20 debian1 systemd[1]: Starting nftables...
Aug  8 13:23:20 debian1 systemd[1]: Started nftables.
Aug  8 13:23:25 debian1 kernel: [ 9649.342901] INVALID_INPUT IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a4:3e:51:5b:f9:1b:08:00 SRC=54.69.60.143 DST=192.168.1.10 LEN=52 TOS=0x00 PREC=0x00 TTL=231 ID=672 DF PROTO=TCP SPT=443 DPT=43376 WINDOW=125 RES=0x00 ACK URGP=0
Aug  8 13:23:26 debian1 kernel: [ 9650.366352] INVALID_INPUT IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a4:3e:51:5b:f9:1b:08:00 SRC=54.69.60.143 DST=192.168.1.10 LEN=52 TOS=0x00 PREC=0x00 TTL=231 ID=673 DF PROTO=TCP SPT=443 DPT=43376 WINDOW=125 RES=0x00 ACK URGP=0
Aug  8 13:23:27 debian1 kernel: [ 9651.389799] INVALID_INPUT IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a4:3e:51:5b:f9:1b:08:00 SRC=54.69.60.143 DST=192.168.1.10 LEN=52 TOS=0x00 PREC=0x00 TTL=231 ID=674 DF PROTO=TCP SPT=443 DPT=43376 WINDOW=125 RES=0x00 ACK URGP=0
Aug  8 13:23:28 debian1 kernel: [ 9652.413748] INVALID_INPUT IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a4:3e:51:5b:f9:1b:08:00 SRC=54.69.60.143 DST=192.168.1.10 LEN=52 TOS=0x00 PREC=0x00 TTL=231 ID=675 DF PROTO=TCP SPT=443 DPT=43376 WINDOW=125 RES=0x00 ACK URGP=0
 


si tu fais :


dig -x 54.69.60.143
 


On a le retour :


; <<>> DiG 9.11.5-P4-5.1-Debian <<>> -x 54.69.60.143
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 188
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;143.60.69.54.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
143.60.69.54.in-addr.arpa. 38   IN      PTR     ec2-54-69-60-143.us-west-2.compute.amazonaws.com.

;; Query time: 31 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: jeu. août 08 13:44:53 CEST 2019
;; MSG SIZE  rcvd: 116
 


Et j'ai déjà eu des paquets invalides de la part de amazonaws.com, c'est
un nom de domaine qui appartient à amazone d'après le whois. Pour le voir
tu fais :


whois amazonaws.com |less
 


C'est un peu volumineux comme réponse d'où le « |less ».
J'ai vu que firefox pouvait avoir des connexion avec ce type de site
sans qu'on lui ait rien demandé. Ça doit être du traçage pour la vente…
de l'espionnage quoi !
Toujours est-il que le paquet renvoyé était invalide, et il a été jeter.
Dès qu'on logge les paquets que l'on utilise pas, on voit passer
des trucs étranges. Je pense que ces paquets ont été envoyé
par erreur, c'est un problème de leur côté, ou c'était une réponse
mal formée à une requête de firefox.

Hors ligne

Pied de page des forums