Vous n'êtes pas identifié(e).
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
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
Et voilà…
Hors ligne
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
'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
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
il suffit d'ajouter
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
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)
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 » :
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
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 ?).
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
Hors ligne
par exemple le daemon avahi pour debian
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 ).
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)
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
bien que le log soit désactivé
Dernière modification par anonyme (07-08-2019 21:54:51)
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 :
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 :
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
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 :
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 :
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
Hors ligne
j'ai ceci maintenant
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
pour le #89 c'est un des premier lien que j'ai parcouru
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 :
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
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 :
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
bon sur la livebox j'ai pas la main sur ces annonces en "224.0"
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
Il n'est pas terrible ce cours. On peut y lire par exemple « un serveur protégé par ssh »
pouah ! Quelle bêtise (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
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
en tant que boulet officiel , tu me dit au début de la chain input
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
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
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
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)
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 :
On a le retour :
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 :
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