Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
comme le démon avahi , le genre de chose que j' évite d'utiliser
par contre j'ai des dépendances installé de snmp (libsnmp30 et libsnmp-base )
Pareil pour moi. Snmp peut être très pratique pour gérer un gros réseau local,
mais je n'en vois pas l'utilité dans mon cas.
Dernière modification par enicar (08-08-2019 13:37:05)
Hors ligne
pour ton #100 c'était juste pour te montrer que plus de multicast
mais intéressant d'utiliser "dig" pour la provenance des paquets
par contre ci dessus j'ai désactivé #log prefix "INPUT_DROP "
inondé de :
Dernière modification par anonyme (08-08-2019 17:49:03)
pour l'IPv6 c'est correct ?
Oui.
Au début du fichier tu pourrais rajouter :
Ça permet de modifier le fichier, puis de recharger avec
Hors ligne
je l'ai ajouté
j'ai testé la commande , ça recharge sans redémarrer le service nftables
Dernière modification par anonyme (08-08-2019 18:05:46)
je fais
systemctl restart nftables.service
Oui, ça doit revenir au même.
Hors ligne
Le nom de mon interface est enp63s0, il faut bien entendu
adapter en fonction du nom de l'interface.
Le fichier est à placer dans /etc/systemd/system. Ensuite on
l'active avec :
Au démarrage de la machine ça va lancer tcpdump dès que le
réseau est disponible.
Comme je n'ai pas envie de remplir mon disque avec un dump, je ne l'ai
pas laissé tourner lontemps, le temps de démarrer ma session xorg
de me lancer un shell en root, et de voir dans les logs du noyau que
les paquets que j'attendais, était arrivé et j'arrête tout cela :
Je désactive le service, parce que je n'ai pas envie que ça recommence
au prochain démarrage :
(Oui, je sais on peut faire cela en une seule commande…).
Enfin on désactive le mode promiscuité de l'interface réseau :
(je ne sais pas si ça a marché, je n'ai rien vu dans les logs du noyau).
Bref, j'ai mon fichier « enp63s0.cap », que j'ai regardé avec wireshark.
Et là je vois effectivement que j'ai des paquets snmp envoyé par ma machine.
Dans les logs j'ai :
Alors, je me demande quel programme génére ces paquets, j'incrime
systemd car il fait tellement de choses et puis ça fait du bien de
se défouler sur systemd 
Ensuite toujours sur la même adresse de diffusion 255.255.255.255 mais sur
des ports différents j'ai d'autre paquets. Je les ai retrouvé dans la capture
de tcpdump, mais ces paquets ne sont pas identifiés par wireshark… J'en ai
deux à destination du port udp 3289 :
Ce qui est inquiétant puisqu'il est dit qu'un vieux virus/trojan se servait
de ce port pour communiquer : https://www.auditmypc.com/udp-port-3289.asp.
Je ne sais si il faut vraiment que je prenne la chose au sérieux.
Ce n'est pas fini (il ne faut jamais faire de dump, on finit à coup
sûr par croire qu'il y a un virus quelque part…). J'ai des paquets
qui ont été identifié comme utilisant le protocole BJNP :
Après une petite recherche, c'est un protocole (propriétaire) utilisé par
de veille imprimante canon. Bon, je n'ai aucun driver pour une
imprimante Canon d'installer. Mon imprimante est une hp, et je l'utilise
sur usb (et la plupart du temps elle est éteinte).
Ce qui me gêne le plus c'est que ce sont des paquets qui semblent provenir de
ma machine (SRC=192.168.1.8) et qui me reviennent car adressé sur des adresses
de diffusion.
Bref, je n'y comprends rien. J'ai juste mis un filtre en sortie
(dans la chaîne output de ma table filter) :
Évidemment la seconde règle interdit le paquet envoyer pour obtenir
mon adresse ip par dhcp (0.0.0.0:68) -> (255.255.255.255:67), mais
au moment où cette règle entre en action, mon interface a déjà
obtenue son adresse ip.
Enfin, bon voilà je suis en vacances alors rien de tel que de passer
mon temps à regarder des trucs dont personne ne se souci.
Hors ligne
pour le snmp tu a pas un paquet installé qui surveille comme nagio4 (ou autres).
tu a forcément quelque chose qui utilise le port 161 et 162
Rien de tout ça, en plus ça ne le fait qu'au démarrage.
Hors ligne
bios machine et box aucun service snmp ?
Rien à ma connaissance. Il faut que je fasse de plus ample investigation.
De toute façon, ça vient de ma machine vu l'adresse source. J'aimerais
voir quelles sont les programmes responsables de ces paquets
comme avec « ss -nutp », mais au démarrage. Je ne sais pas si
possible d'enregistrer un historique des sockets qui ont existé.
Hors ligne
Hors ligne
)
modifié le ntpd.conf pour 192.168.1.10 et appliqué la règle
Dernière modification par anonyme (09-08-2019 13:56:54)
tu la branché en USB et elle partagé (configuration de cups coché )
Je n'ai jamais touché à cette configuration, ça doit être la
configuration par défaut. Je viens de mettre
dans /etc/cups/cupsd.conf, et j'ai redémarré le service, apparemment
c'était ça.
Hors ligne
y compris quand je désactive complètement le pare-feu, donc ça ne vient pas de là.
Mais je ne suis pas sûr que je puisse faire grand chose pour comprendre à quoi c'est du.
Hors ligne
c'est le client qui bloque le ping (passé en "accept" tout fonctionne )
Ce qui prouve que nftables fonctionne bien 
Hors ligne
pour ceci (#76) ça fonctionne , le switch se met a l'heure en local
ip saddr 192.168.1.2 ip daddr 192.168.1.10 udp dport 123 accept
modifié le ntpd.conf pour 192.168.1.10 et appliqué la règle
Tu as finalement opté pour mettre à l'heure le switch via
le serveur ntp de la passerelle. Je ne doutais pas que
la règle allait fonctionner, mais merci quand même pour le retour.
Ça montre aussi comme ce type de règle est facile à écrire.
Quand on veut filtrer une adresse source :
<adresse_source> pouvant être tout un sous réseau comme « 192.168.1.0/24 »
ou plusieurs adresses en écrivant : « {192.168.1.2, 192.168.10.3} »
Pour filtrer une adresse destination :
La seule chose qui change c'est qu'on remplace saddr par daddr.
Quand on veut filtrer un port destination :
<protocole> vaut ici udp ou tcp la plupart du temps mais on peut aussi
utiliser d'autres choses. Aussi, udp et tcp sont des raccourcis pour
« protocol udp » et « protocol tcp » respectivement.
<numero_port> est juste un nombre.
C'est pareil pour un port source, sauf qu'on met sport à la place de
dport.
Les règles des filtres ressemblent assez à ce qu'on peut faire
avec tcpdump ou pf sur les systèmes bsd.
Hors ligne
un ping du net ,par une ip locale , par nom machine , ou par nom-machine.domaine ça fonctionne.
juste un souci sur le serveur le ping par nom machine ne fonctionne pas
google.fr oui , et nom-machine.domaine aussi , c'est pas trop grave mais je vois pas pourquoi.
J'ai rien compris…
j'ai profité pour purger apparmor sur le client aussi (je suis en buster sur le serveur et testing sur le client)
De mon côté, ça partie des choses que je voudrais mettre en place (apparmor),
pour l'instant je l'ai même viré du noyau, mais je me suis dit que ça pouvait valoir
le coup.
Hors ligne
a priori c'est apparmor qui a perturbé dhcpd et bind9 (erreur sur les logs) et ma zone directe et inverse vide (plus de client)
purgé apparmor
remit les pare feu en accept
Si c'est apparmor qui fait cela, pas besoin de remettre tout en accept…
Hors ligne
va m' expliquer ce qui va pas
il n'y a pas que ce log qui bug sur bind9 et aussi sur isc-dhcp-server , sans parler des journaux "accès denied"
il y a tellement de choses a surveiller
la a priori tout est en ordre maintenant
Dernière modification par anonyme (09-08-2019 17:36:11)
il n'y a pas que ce log qui bug sur bind9 et aussi sur isc-dhcp-server , sans parler des journaux "accès denied"
La chose importante est que ça marche, après les erreurs et les avertissements dans
les logs ce n'est pas forcément très grave.
Hors ligne
alors que de n'importe quel client tout fonctionne correctement.
ps: c'est un souci local sur mon DNS sur la passerelle
de la passerelle si je fais : ping -c4 kabylake1.mondomaine c'est ok (sans ".domaine" => "Nom ou service inconnu" )
c'est vérifiant tout ça que je me suis rendu compte du souci
et au niveau des surprises sûrement pas la dernière
Dernière modification par anonyme (09-08-2019 17:51:54)
Hors ligne
de la passerelle si je fais : ping -c4 kabylake1.mondomaine c'est ok (sans ".domaine" => "Nom ou service inconnu" )
Peut-être qu'il faut dire à bind que mondomaine c'est le réseau 192.168.10.0
ou ça a été déjà fait ?
Dernière modification par enicar (09-08-2019 18:08:34)
Hors ligne