Alionet - Communauté openSUSE francophone

openSUSE => Internet, réseaux et serveurs => Discussion initiée par: ricobolo le 05 Octobre, 2021, 15:42:56

Titre: YAST FIREWALL QUE 2 ONGLETS ?
Publié par: ricobolo le 05 Octobre, 2021, 15:42:56
Bonjour,
Quelqu'un sait pourquoi dans opensuse leap 15.2 => yast/firewall il n'y que les onglets services et ports ? Je vois pas les onglets sources / ipsets ...
Cela m'oblige a creuser la mise en place en ligne de commandes par moi même, et prends un temps fou à s'approprier les règles à mettre en place.
Je cherche simplement a avoir une regle pour plusieurs adresses locales, car je n'ai qu'une interface réseau et si je ne fais pas cela je dois ouvrir les ports ( par exemple samba ) sur la zone externe. J'ai plein de tentatives d'attaques SMB, et je ne veux pas ouvrir SMB au reste du monde mais que sur le réseau local.
D'avance merci.
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 05 Octobre, 2021, 20:35:29
Bonjour ricolo,

oui le réglage de firewalld via l'interface graphique Yast2 est succincte.

Installe "firewall-config" et si tu veux un icone dans ta barre "firewall-applet":
sudo zypper in firewall-config firewall-applet 
Tu te délogues, tu te relogues, dans ton menu tu auras un programme 'firewall', c'est assez complet, standard sur toutes les distributions avec firewalld (pas ubuntu out of the box, pour eux c'est ufw).
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: ricobolo le 06 Octobre, 2021, 11:20:37
Super, merci beaucoup Denebe ! J'avais cherché mais avec firewalld comme mot clé....

Cela ne change pas le firewall depuis Yast qui s'appelle "firewall" et qui a toujours que 2 onglets (peut-être besoin de reboot? je me suis pas encore délogué non plus), mais peu importe j'ai bien un nouveau programme qui apparait et qui s'appelle maintenant "pare feu". Celui-là présente bien tous les onglets. C'est un peu plus facile pour configurer ;) . Et l'avantage c'est que maintenant je maîtrise un peu mieux les lignes de commandes firewalld au cas ou :D

Par contre je me demande l'applet il est ou ? Est ce que c'est celui là ( celui qui s'appelle maintenant pare-feu avec tous les onglets ) ? Ou bien il y a t-il  encore un applet, je pensais à un genre de monitoring des audits FW dans la barre des taches par  exemple.

Et question pourquoi OpenSuse ne livre pas directement le firewalld complet dans yast ? Je n'en comprends pas l'intérêt...
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 06 Octobre, 2021, 14:27:12
Il est là l'applet, enfin l’icône:
(https://i.ibb.co/0ywpbVG/firewall-applet.png) (https://ibb.co/0ywpbVG)
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: ricobolo le 11 Octobre, 2021, 17:44:21
Ha oui, après reboot (pour autre raison)  il est apparut. Merci encore Denebe.!
En mouseOver il bugg un peu ( voir copie écran, des <br> apparaissent... ) , mais en cliquant dessus l'affichage est normal. On voit les interfaces, les ipSet, et on peut passer en zone Bloc avec clic droit/Protections activées. Super, nickel.

Alors tant que l'on est sur le sujet, si quelqu'un sait, je creuse un peu et je me demande comment fonctionne SuSEfirewalld2 ( et ou est sa GUI ) ? Je viens de faire un test et en lançant SuSEfirewalld2, et il arrête firewalld et son applet et vice versa. Donc apparemment on ne peut pas avoir les 2 en même temps.
Apparemment SuSEfirewalld2 il est lié a fail2ban (ou l'inverse), sauf que les fameuses règles de blocage générées par fail2ban elles sont ou? Sauf erreur Je ne les retrouve ni dans firewwald, ni dans iptables ( mais peut-être parce que justement j'ai arrêté SuSEfirewalld2 ?).

Il y a sans doute quelque chose qui m'échappe, j'aurais besoin d'un peu de lumière pour mieux maîtriser mon réseau,

Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 11 Octobre, 2021, 18:15:37
Tu penses à ça ?
thierry@toto-PC:~> sudo zypper info susefirewall2-to-firewalld
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...


Informationen zu Paket susefirewall2-to-firewalld:
--------------------------------------------------
Repository         : Haupt-Repository
Name               : susefirewall2-to-firewalld
Version            : 0.0.4-3.9.1
Arch               : noarch
Anbieter           : SUSE LLC <https://www.suse.com/>
Installierte Größe : 87,4 KiB
Installiert        : Nein
Status             : nicht installiert
Quellpaket         : susefirewall2-to-firewalld-0.0.4-3.9.1.src
Zusammenfassung    : Basic SuSEfirewall2 to FirewallD migration script
Beschreibung       :
    This is a simple bash script aiming to provide a basic migration path from
    SuSEfirewall2 to FirewallD.
C'était du temps où firewalld est arrivé dans Leap 15 (voir Opensuse 42.x) alors qu'il y avait encore susefirewall2, le firewall d'Opensuse d'alors.

Ce petit script servait. comme indiqué, pour migrer facilement vers firewalld… Je ne l'ai jamais utilisé, je pense qu'il s'agissait de migrer des règles de pare-feu.

Aujourd'hui, il ne sert plus à rien.

## Quant à l'applet firewalld, oui l'affichage est un peu buggy chez moi aussi, sauf quand je clique dessus aussi.

@edit: susefirewall2 (sans le d) est l'ancien firewall, avant firewalld.
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: ricobolo le 11 Octobre, 2021, 20:13:26
Merci Denebe pour cette réponse, je comprends mieux on peut oublier SuSEFirewall2, mais il vient encore par défaut dans leap 15.x et notamment quand on veut installer fail2ban :    (https://123ventes.com/fw2.png).
A moins que ce ne soit qu'un plugin indépendant en fait.

Bon j'ai creusé un peu, et grâce a webmin, je comprends que fail2ban peut adresser une action vers n'importe quel firewall, iptables, nftables, firewalld, shorewall....Mais pas de SuSEFirewall2 dans la liste ( ce doit être normal, que webmin et fail2ban ne connaissent pas SuSEfirewal2 spécifique a Suse et obsolete).

Étonnant que Leap continue à le proposer par défaut, c'est pas grave mais ça embrouille un peu...
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 11 Octobre, 2021, 22:03:43
Étonnant que Leap continue à le proposer par défaut, c'est pas grave mais ça embrouille un peu...
Peut-être as-tu trifouiller ta machine ??

Chez moi, sur deux machines avec Leap 15.3 saines (avec très peu de dépôts externes), si je veux installer fail2ban il ne m'est pas demandé d'installer SuSEfirewall2… (je n'ai pas de Tumbleweed sous la main maintenant)
(https://i.ibb.co/2qqtPZ7/firewalld-leap.png) (https://ibb.co/2qqtPZ7)

Fais voir ce que donne
sudo zypper se firewall
se=search…
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: ricobolo le 12 Octobre, 2021, 11:44:52
Bonjour Denebe,

Si tu veux vérifier il faut faire un
zipper info fail2ban 
ou
zypper search fail2ban
et voir les packages qu'il te propose, et non pas
 zypper se firewall
, je pense.

Tu peux essayer voir si tu retrouves les même dépendances que moi ?
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 12 Octobre, 2021, 15:52:32
@ricobolo
Je souhaitais, pour t'aider, avoir le retour d'une commande, que tu n'as toujours pas fourni. À partir de là…
Je n'ai aucun soucis chez moi.
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: ricobolo le 14 Octobre, 2021, 03:44:33
Salut denebe,

Voilà  la commande sudo zypper se firewall

edport:~ # sudo zypper se firewall
Loading repository data...
Reading installed packages...

S  | Name                       | Summary                                                             | Type
---+----------------------------+---------------------------------------------------------------------+-----------
   | SuSEfirewall2              | Stateful Packet Filter Using iptables and netfilter                 | package
   | SuSEfirewall2-fail2ban     | Files for integrating fail2ban into SuSEfirewall2 via systemd       | package
i+ | firewall-applet            | Firewall panel applet                                               | package
i+ | firewall-config            | Firewall configuration application                                  | package
i  | firewall-macros            | FirewallD RPM macros                                                | package
i+ | firewalld                  | A firewall daemon with D-Bus interface providing a dynamic firewall | package
i  | firewalld-lang             | Translations for package firewalld                                  | package
   | firewalld-rpcbind-helper   | Tool for static port assignment of NFSv3, ypserv, ypbind services   | package
i  | python3-firewall           | Python3 bindings for FirewallD                                      | package
   | susefirewall2-to-firewalld | Basic SuSEfirewall2 to FirewallD migration script                   | package
   | susefirewall2-to-firewalld | Basic SuSEfirewall2 to FirewallD migration script                   | srcpackage
i  | yast2-firewall             | YaST2 - Firewall Configuration                                      | package
   | yast2-firewall             | YaST2 - Firewall Configuration                                      | srcpackage

Mais je n'ai pas désinstallé SuSEfirewall2.

Pour l'essentiel j'ai à peu près résolu mes problèmes. J'ai fail2ban qui bloque des ip externes sur samba, mais on ne les voit pas les règles de blocage dans firewalld ( ce qui est étonnant ou qui m’échappe ) mais on les voit bien dans iptables -L.
J'ai réussi a installer munin, et je ne savais pas qu'il avait un graphe pour fail2ban. Grace au graphe je vois un peu mieux ce qui se passe, et j'ai quand même banni 2300 IP en 24heures rien que sur samba.
Mais comme je n'ai qu'une carte réseau je n'arrive pas a bloquer les ports 445/139/138 d'un point de vue du routeur (ip publique) sans bloquer le local, je crois que ce n'est pas possible. C'est a dire que si j'autorise pas le service samba sur mon interface reseau, j'ai plus de samba local. J'ai essayé de désactiver le partage freebox, mais c'est pareil, on atteint ma machine en 445 depuis l’extérieur.
Et d'ailleurs les ports ne sont a ma connaissance pas redirigés  depuis le routeur (freebox) sur cette machine,  seul les ports 80,443 sont redirigés, c'est pour ça que je ne comprends pas que ces ip atteignent ma machine. J'ai même fait une redirection factice depuis le routeur, c'est à dire vers une ip qui n'existe pas, mais j'ai toujours autant de visites indésirables... Mais bon heureusement fail2ban + le firewalld plus la config de samba semble bien bloquer tout ce monde, sans me bloquer moi en local.
SuSEfirewall2 dans tout ça ? Il est désactivé.



Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 14 Octobre, 2021, 12:48:13
edport:~ # sudo zypper se firewall
Loading repository data...
Reading installed packages...

S  | Name                       | Summary                                                             | Type
---+----------------------------+---------------------------------------------------------------------+-----------
   | SuSEfirewall2              | Stateful Packet Filter Using iptables and netfilter                 | package
On voit que susefirewall2 n'est pas installé, parfait.

Pour l'essentiel j'ai à peu près résolu mes problèmes. J'ai fail2ban qui bloque des ip externes sur samba, mais on ne les voit pas les règles de blocage dans firewalld ( ce qui est étonnant ou qui m’échappe ) mais on les voit bien dans iptables -L.
Je n'en sais pas plus. Je sais juste que firewalld, iptables et nftables tournent  dans l'espace utilisateur et permettent de fournir des règles pare-feu à Netfilter, qui lui est le parefeu dans l'espace noyau.
"firewalld is a firewall management tool for Linux operating systems. It provides firewall features by acting as a front-end for the Linux kernel's netfilter framework. firewalld's current default backend is nftables. Prior to v0.6.0, iptables was the default backend.[2] Through its abstractions firewalld acts as an alternative to nft and iptables command line programs."
J'ai réussi a installer munin, et je ne savais pas qu'il avait un graphe pour fail2ban. Grace au graphe je vois un peu mieux ce qui se passe, et j'ai quand même banni 2300 IP en 24heures rien que sur samba.
Je ne connaissais, ça a l'air intéressant et pratique.
Mais comme je n'ai qu'une carte réseau je n'arrive pas a bloquer les ports 445/139/138 d'un point de vue du routeur (ip publique) sans bloquer le local, je crois que ce n'est pas possible.
C'est a dire que si j'autorise pas le service samba sur mon interface reseau, j'ai plus de samba local. J'ai essayé de désactiver le partage freebox, mais c'est pareil, on atteint ma machine en 445 depuis l’extérieur.
Hum, cela fait un moment que je n'ai pas eu de Freebox sous la main. Une Freebox, c'est un routeur / pare-feu /switch.
Le pare-feu d'une box permet au minimum d'autoriser ou de bloquer ce qui vient de l'extérieur (d'internet), entre deux réseaux…
Par contre, ce pare-feu n'agit pas sur le switch (tes 4 ports ethernet + le wifi), tous les paquets transitant par ton switch ne sont pas traités, ils arrivent sur ton switch, et ton switch les orientent vers le bon port (eth0, eth1, eth2… ; il ne s'agit pas des ports de la couche transport…) grâce à l'adresse MAC du paquet, et grâce à sa table CAM i.e. vers l' "ordinateur destination".

Et d'ailleurs les ports ne sont a ma connaissance pas redirigés  depuis le routeur (freebox) sur cette machine,  seul les ports 80,443 sont redirigés, c'est pour ça que je ne comprends pas que ces ip atteignent ma machine. J'ai même fait une redirection factice depuis le routeur, c'est à dire vers une ip qui n'existe pas, mais j'ai toujours autant de visites indésirables... Mais bon heureusement fail2ban + le firewalld plus la config de samba semble bien bloquer tout ce monde, sans me bloquer moi en local.
1) Oui ce n'est pas normal. Il y a une couille dans le potage. (dans ta config, chez toi…)

C'est quoi comme Freebox ?

Il faut inspecter les paquets arrivant vers ton serveurs samba (tcp 445), trouver les ip sources de ces paquets, quelques-une. Et ensuite, aviser. Qui sait, si cela se trouve, ce sont des ip locals ??
Tu peux faire cela en installant un "sniffer" sur ton serveur samba. Le plus connu en gui: wireshark (à démarrer en cli admin - pas avec sudo). Sinon avec tcpdump en cli.

Par exemple, j'ai une imprimante/scaner réseau. Quand je scanne en réseau de mon imprimante, elle va se connecter sur le serveur samba de mon ordinateur, et en ainsi envoie le scan vers un dossier de mon ordinateur. Avec le sniffer, je vois très bien ce qui se passe:
(https://i.ibb.co/frkC2sy/samba.png) (https://ibb.co/frkC2sy)
C'est mon imprimante ipsource: 192.168.0.94 qui veut se connecter mon serveur samba port-dest:445 tcp

Peux-tu donner quelques ip sources qui se connectent à ton serveur samba ? (celles qui te semblent suspects)
Histoire d'y voir un peu clair.

2) sinon, il existe une solution pour établir des règles de pare-feu qui fonctionnent, pour l'ordi du serveur samba.
Il est important de comprendre que les règles de pare-feu ont un ordre, ainsi si tu insères ces règles dans cet ordre dans l'ordinateur où tourne ton serveur samba, cela fonctionnera comme convenu:
=> tu laisses passer tout ce qui est local (en input), puis tu bloques tout le reste ! (port-dest: tcp 445…)
Sinon tu peux accepter une plage d'ip 192.168.0.0/24 par exemple…

SuSEfirewall2 dans tout ça ? Il est désactivé.
Oui  ;)
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 14 Octobre, 2021, 14:13:44
J'ai essayé cette règle iptables, ça a l'air de fonctionner:
iptables -I INPUT ! -s 192.168.0.0/24 -p tcp --dport 445 -j DROP
Tout ce qui n'est pas dans mon réseau local ne peut pas accéder à mon serveur samba.

Test avec une ip hors de mon réseau local: 10.1.1.2, ça ne passe pas:
rem: le ping montre que j'ai bien accès au serveur samba (via une passerelle) en pinguant…
thierry@localhost:~> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:63:b3:80 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 10.1.1.2/24 brd 10.1.1.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5312:8e12:2cb5:ce28/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
thierry@localhost:~>
thierry@localhost:~>
thierry@localhost:~> ping 192.168.0.79 -c 1
PING 192.168.0.79 (192.168.0.79) 56(84) bytes of data.
64 bytes from 192.168.0.79: icmp_seq=1 ttl=63 time=1.07 ms

--- 192.168.0.79 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.072/1.072/1.072/0.000 ms
thierry@localhost:~>
thierry@localhost:~>
thierry@localhost:~> telnet 192.168.0.79 445
Trying 192.168.0.79...
^C
thierry@localhost:~>

Le même host avec connecté avec une ip de mon réseau local, ça passe:
thierry@localhost:~> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:63:b3:80 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 192.168.0.134/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 604787sec preferred_lft 604787sec
    inet6 2a02:8109:a380:310:232:8697:8a8c:d177/128 scope global dynamic noprefixroute
       valid_lft 604791sec preferred_lft 604791sec
    inet6 2a02:8109:a380:310:c074:2dde:68cd:dc1c/64 scope global temporary dynamic
       valid_lft 86399sec preferred_lft 43199sec
    inet6 2a02:8109:a380:310:f79e:a389:ab87:c771/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86399sec preferred_lft 43199sec
    inet6 fe80::5312:8e12:2cb5:ce28/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
thierry@localhost:~>
thierry@localhost:~>
thierry@localhost:~> ping 192.168.0.79 -c 1
PING 192.168.0.79 (192.168.0.79) 56(84) bytes of data.
64 bytes from 192.168.0.79: icmp_seq=1 ttl=64 time=0.577 ms

--- 192.168.0.79 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.577/0.577/0.577/0.000 ms
thierry@localhost:~>
thierry@localhost:~>
thierry@localhost:~> telnet 192.168.0.79 445
Trying 192.168.0.79...
Connected to 192.168.0.79.
Escape character is '^]'.
^C
^]
telnet> close
Connection closed.
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: ricobolo le 14 Octobre, 2021, 14:21:16
Salut Denebe,
et merci encore de tes conseils.
Peux-tu donner quelques ip sources qui se connectent à ton serveur samba ? (celles qui te semblent suspects)
Histoire d'y voir un peu clair. : =>


extrait de /var/log/log.smbd  (donc ces ip sont passées a travers le firewall, mais c'est fail2ban qui les bloquent en lisant le log.smbd  )

Denied connection from 187.141.63.50 (187.141.63.50)
[2021/10/13 00:01:18.930740,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 201.249.58.126 (201.249.58.126)
[2021/10/13 00:01:19.292747,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 201.249.58.126 (201.249.58.126)
[2021/10/13 00:01:44.277381,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 204.199.103.194 (204.199.103.194)
[2021/10/13 00:01:44.445291,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 204.199.103.194 (204.199.103.194)
[2021/10/13 00:01:48.761109,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 183.88.239.11 (183.88.239.11)
[2021/10/13 00:02:38.418434,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 190.145.40.34 (190.145.40.34)
[2021/10/13 00:02:38.576979,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 190.145.40.34 (190.145.40.34)
[2021/10/13 00:04:50.405420,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 189.180.65.18 (189.180.65.18)
[2021/10/13 00:05:14.639016,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 102.36.216.230 (102.36.216.230)
[2021/10/13 00:05:14.869070,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 102.36.216.230 (102.36.216.230)
[2021/10/13 00:05:26.214004,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 201.71.137.134 (201.71.137.134)
[2021/10/13 00:05:26.462254,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 201.71.137.134 (201.71.137.134)
[2021/10/13 00:06:08.460293,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 165.1.214.87 (165.1.214.87)
[2021/10/13 00:06:08.638399,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 165.1.214.87 (165.1.214.87)
[2021/10/13 00:06:42.343706,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 95.0.202.82 (95.0.202.82)
[2021/10/13 00:06:50.529544,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 222.209.84.114 (222.209.84.114)
[2021/10/13 00:06:50.772350,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 222.209.84.114 (222.209.84.114)
[2021/10/13 00:08:10.455900,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 187.174.255.114 (187.174.255.114)
[2021/10/13 00:08:10.684285,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 187.174.255.114 (187.174.255.114)
[2021/10/13 00:08:12.250489,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 213.74.115.50 (213.74.115.50)
[2021/10/13 00:09:38.499701,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 195.208.155.102 (195.208.155.102)
[2021/10/13 00:09:38.612640,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 195.208.155.102 (195.208.155.102)
[2021/10/13 00:12:44.487596,  0] ../../lib/util/access.c:371(allow_access)
  Denied connection from 124.40.245.92 (124.40.245.92)


2) sinon, il existe une solution pour établir des règles de pare-feu qui fonctionnent, pour l'ordi du serveur samba.
Il est important de comprendre que les règles de pare-feu ont un ordre, ainsi si tu insères ces règles dans cet ordre dans l'ordinateur où tourne ton serveur samba, cela fonctionnera comme convenu:
accepter le traffic en input avec le port-dest 445, protocol tcp et l'ip 192.168.0.x
accepter le traffic en input avec le port-dest 445, protocol tcp et l'ip 192.168.0.y
accepter le traffic en input avec le port-dest 445, protocol tcp et l'ip 192.168.0.z
accepter le traffic en output avec le port-dest 445, protocol tcp et l'ip 192.168.0.ton_ordi
pour que tu puisses accéder éventuellement à d'autres serveurs samba de ton réseau local…
refuser tous les paquets avec le port-destination 445, protocol tcp
=> tu laisses passer tout ce qui est local (en input et en output), puis tu bloques tout le reste ! (port-dest: tcp 445…)
Sinon tu peux accepter une plage d'ip 192.168.0.0/24 par exemple…


Oui, merci,  c'est exactement ce que j'ai fait, et c'est bien pour ça que j'avais besoin de la GUI du firewalld complète, parce que au début je me suis tapé les règles à la main en ligne de commande sur iptables et firewalld. Maintenant (et grâce a toi  ;)  ) je le fait maintenant avec la GUI complète de firewalld directement. J'ai crée un ipset local et j'autorise tout quand la destination ET la source sont en local ( le but était de fermer le service samba sur le firewall pour les accès publiques, mais si je fais ça ce ne fonctionne plus en local, qq chose m’échappe). Je n'ai pas mis de forward comme tu l'as indiqué, mais je me demande si je passe par un VPN si j'en aurais pas besoin ( forward local de ipLocal vers/de ipVpn ? et idem pour les VM qui passent par un pont réseau avant de récupérer leur 192.168.x.x ? ).
Donc je n'ai pas vraiment de problème pour me connecter sur Samba en local, hormis que j'ai pas encore bien règlé ipv6 et que la découverte samba ne fonctionne pas bien dans dolphin, mais l'accès par ip fonctionne nickel.

Je vais voir avec wireshark, mais ce qui serait intéressant c'est de sniffer sur la box Delta de free, je vais essayer de voir ça.
Ha ben tiens, après désactivation du partage de la box via son interface, j'ai fais un nmap sur la box, et le port 445/139 est bien ouvert :
Starting Nmap 7.70 ( https://nmap.org ) at 2021-10-14 14:18 CEST
Nmap scan report for freebox-server.gribouille (192.168.0.100)
Host is up (0.00020s latency).
Not shown: 983 filtered ports
PORT     STATE  SERVICE
21/tcp   open   ftp
53/tcp   open   domain
80/tcp   open   http
139/tcp  closed netbios-ssn
443/tcp  open   https
445/tcp  closed microsoft-ds
548/tcp  closed afp
554/tcp  open   rtsp
1723/tcp open   pptp
2020/tcp open   xinupageserver
5000/tcp closed upnp
5001/tcp closed commplex-link
5357/tcp open   wsdapi
5678/tcp open   rrac
6000/tcp closed X11
8090/tcp open   opsmessaging
9091/tcp open   xmltec-xmlmail


Je vais tenter un reboot de box....





Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 14 Octobre, 2021, 15:11:51
Je n'ai jamais utilisé fail2ban, je ne connais pas le fonctionnement, mais je sais à quoi cela sert…

Écris cette règle iptables (à adapter pour ton réseau local):
iptables -I INPUT ! -s 192.168.0.0/24 -p tcp --dport 445 -j DROP
Donne le résultat de:
# iptables -L -n --line-numbers

1a) ferme tous les ports de ta freebox; (si tu as un serveur que tu ne veux pas couper momentanément, ba mince!)
1b) tu inspectes voir si tout fonctionne comme attendu, voir si tu as encore des intrus… Normalement non !!

PS: reste concentré sur ton problème, tu verras le vpn plus tard… Ce n'est pas normal que tu aies du traffic venant du Mexique et Vénézuélas  ( http://www.localiser-ip.com/?ip=187.141.63.50 , http://www.localiser-ip.com/?ip=201.249.58.126 )

PS2: si ton pare feu est bien configuré (au moins celui de ton ordinateur), alors le serveur samba ne devrait, selon moi, rien recevoir. Ton log samba nous indique donc que ton parefeu est mal configuré.
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: ricobolo le 14 Octobre, 2021, 15:26:09
Denebe,

Nos messages se sont croisés.

Voici iptables -L -n  --line-numbers

1320 REJECT     all  --  37.36.70.156         0.0.0.0/0            reject-with icmp-port-unreachable
1321 REJECT     all  --  37.29.88.126         0.0.0.0/0            reject-with icmp-port-unreachable
1322 REJECT     all  --  37.29.15.114         0.0.0.0/0            reject-with icmp-port-unreachable
1335 REJECT     all  --  37.131.224.158       0.0.0.0/0            reject-with icmp-port-unreachable
1336 REJECT     all  --  36.95.63.98          0.0.0.0/0            reject-with icmp-port-unreachable
1337 REJECT     all  --  36.95.165.29         0.0.0.0/0            reject-with icmp-port-unreachable
1338 REJECT     all  --  36.94.90.10          0.0.0.0/0            reject-with icmp-port-unreachable
1339 REJECT     all  --  36.94.128.162        0.0.0.0/0            reject-with icmp-port-unreachable
1340 REJECT     all  --  36.92.59.249         0.0.0.0/0            reject-with icmp-port-unreachable
1341 REJECT     all  --  36.91.51.221         0.0.0.0/0            reject-with icmp-port-unreachable
1342 REJECT     all  --  36.91.182.130        0.0.0.0/0            reject-with icmp-port-unreachable
1343 REJECT     all  --  36.90.164.160        0.0.0.0/0            reject-with icmp-port-unreachable
1344 REJECT     all  --  36.88.148.249        0.0.0.0/0            reject-with icmp-port-unreachable
1345 REJECT     all  --  36.88.132.36         0.0.0.0/0            reject-with icmp-port-unreachable
1346 REJECT     all  --  36.83.123.28         0.0.0.0/0            reject-with icmp-port-unreachable
1347 REJECT     all  --  36.79.204.2          0.0.0.0/0            reject-with icmp-port-unreachable
1348 REJECT     all  --  36.78.96.180         0.0.0.0/0            reject-with icmp-port-unreachable
1349 REJECT     all  --  36.76.66.122         0.0.0.0/0            reject-with icmp-port-unreachable
1350 REJECT     all  --  36.73.83.167         0.0.0.0/0            reject-with icmp-port-unreachable
1351 REJECT     all  --  36.73.245.4          0.0.0.0/0            reject-with icmp-port-unreachable
1352 REJECT     all  --  36.72.90.93          0.0.0.0/0            reject-with icmp-port-unreachable
1353 REJECT     all  --  36.72.243.218        0.0.0.0/0            reject-with icmp-port-unreachable
1354 REJECT     all  --  36.72.125.217        0.0.0.0/0            reject-with icmp-port-unreachable
1355 REJECT     all  --  36.71.150.80         0.0.0.0/0            reject-with icmp-port-unreachable
1356 REJECT     all  --  36.68.175.4          0.0.0.0/0            reject-with icmp-port-unreachable
1357 REJECT     all  --  36.68.159.21         0.0.0.0/0            reject-with icmp-port-unreachable
1358 REJECT     all  --  36.67.209.195        0.0.0.0/0            reject-with icmp-port-unreachable
1359 REJECT     all  --  36.67.117.210        0.0.0.0/0            reject-with icmp-port-unreachable
1360 REJECT     all  --  36.66.74.234         0.0.0.0/0            reject-with icmp-port-unreachable
1361 REJECT     all  --  36.37.94.197         0.0.0.0/0            reject-with icmp-port-unreachable
1362 REJECT     all  --  36.238.70.208        0.0.0.0/0            reject-with icmp-port-unreachable
1363 REJECT     all  --  36.234.36.62         0.0.0.0/0            reject-with icmp-port-unreachable
1364 REJECT     all  --  36.233.158.180       0.0.0.0/0            reject-with icmp-port-unreachable
1365 REJECT     all  --  36.224.193.76        0.0.0.0/0            reject-with icmp-port-unreachable
1366 REJECT     all  --  36.22.179.166        0.0.0.0/0            reject-with icmp-port-unreachable
1367 REJECT     all  --  36.111.193.192       0.0.0.0/0            reject-with icmp-port-unreachable
1368 REJECT     all  --  35.233.62.116        0.0.0.0/0            reject-with icmp-port-unreachable
1369 REJECT     all  --  34.140.248.32        0.0.0.0/0            reject-with icmp-port-unreachable
1370 REJECT     all  --  34.103.168.65        0.0.0.0/0            reject-with icmp-port-unreachable
1371 REJECT     all  --  32.141.200.6         0.0.0.0/0            reject-with icmp-port-unreachable
1372 REJECT     all  --  31.48.78.247         0.0.0.0/0            reject-with icmp-port-unreachable
1373 REJECT     all  --  31.47.33.70          0.0.0.0/0            reject-with icmp-port-unreachable
1374 REJECT     all  --  31.223.22.218        0.0.0.0/0            reject-with icmp-port-unreachable
1375 REJECT     all  --  31.173.95.130        0.0.0.0/0            reject-with icmp-port-unreachable
1376 REJECT     all  --  31.162.158.20        0.0.0.0/0            reject-with icmp-port-unreachable
1377 REJECT     all  --  31.154.74.222        0.0.0.0/0            reject-with icmp-port-unreachable
1378 REJECT     all  --  31.145.174.90        0.0.0.0/0            reject-with icmp-port-unreachable
1379 REJECT     all  --  31.14.186.156        0.0.0.0/0            reject-with icmp-port-unreachable
1380 REJECT     all  --  31.135.182.238       0.0.0.0/0            reject-with icmp-port-unreachable
1381 REJECT     all  --  31.130.162.138       0.0.0.0/0            reject-with icmp-port-unreachable
1382 REJECT     all  --  27.77.111.24         0.0.0.0/0            reject-with icmp-port-unreachable
1383 REJECT     all  --  27.74.249.77         0.0.0.0/0            reject-with icmp-port-unreachable
1384 REJECT     all  --  27.73.60.16          0.0.0.0/0            reject-with icmp-port-unreachable
1385 REJECT     all  --  27.72.90.124         0.0.0.0/0            reject-with icmp-port-un

ça remplit tout le terminal, je ne peux pas remonter l'affichage.


1/ le reboot de la freebox ne change rien au nmap. Le 445 est toujours là. Et la box a perdu toute la config de redirection de ports !
  ==> ferme tous les ports de ta freebox; (si tu as un serveur que tu ne veux pas couper momentanément, ba mince!) : fait mais j'ai besoin du 80 et 445. Ce sont les seuls que j'ai re-ouvert.
Ca lui arrive des fois, mais je crois savoir pourquoi : il y deux manières d’accéder à la config : via l'ip de la passerelle, et via http:/mon compte free. Récemment je suis allé dans http:/mon compte free  et la config était nulle/vide ( mais pas depuis la passerelle). J'ai rajouté une redirection, et je pense que cela écrase la config, car elle doit être poussée après reboot. Avis a free.... Bref, une embrouille de free, et comme quoi il est toujours mauvais de pouvoir faire la même chose à deux endroits différents). Mais le pb est là : le port 445 ouvert alors que la config dit que non : le partage réseau de la box est désactivé, et pas de redirection 445 ( bon mais comme je suis sur la dmz c'est normal que ça tombe sur cette machine). A fouiller la config box peut-être il y un autre service qui l'ouvre.

2/ iptables -I INPUT ! -s 192.168.0.0/24 -p tcp --dport 445 -j DROP   :)  
Je n'y avais pas pensé.
Je l'ai fait pour firewalld, mais l'interface a un bugg : pas d'ipset dans la liste des sources. Mais comme je me suis aguerri aux lignes de commande je l'ai fait passé en ligne de commande :
firewall-cmd --permanent --zone=external --add-rich-rule='rule family="ipv4" source NOT ipset="reseauLocal" port port="139" protocol="udp" drop' 
firewall-cmd --permanent --zone=external --add-rich-rule='rule family="ipv4" source NOT ipset="reseauLocal" port port="445" protocol="tcp" drop'

Il n'y a pas de notion de Input dans firewalld a ce que j'ai compris, cela dépend juste de source et dest ( mais je ne suis pas complètement sûr, si quelqu'un sait ?).

l'avantage est que je peux visualiser mes règles dans firewalld, et modifier mon ipset réseau local au cas ou !

Je vais voir si ça fonctionne comme prévu maintenant, je n'ai plus qu'à regarder mes graphes fail2ban, déjà ça c'est calmé ce matin, mais je devrais avoir 0 banni pour samba maintenant.
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 14 Octobre, 2021, 15:45:46
Fais voir un
iptables -L -n --line-numbers | grep -B2 192.168.0.0/24
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: ricobolo le 14 Octobre, 2021, 17:03:47
Ha mais j'avais mal lu, les port 445/139 sont closed après le reboot de la box.

Donc c'est bien le partage de la box qui fait que les IP entrent sur la dmz en 445.

En tout cas plus rien concernant les tentatives d'accès sur samba, je continue la surveillance, et je pense que la règle du drop est nickel si je réactive le partage de la box ( elle me sert de sauvegarde donc j'en ai besoin ).
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 14 Octobre, 2021, 17:26:28
Donc c'est bien le partage de la box qui fait que les IP entrent sur la dmz en 445.

En tout cas plus rien concernant les tentatives d'accès sur samba, je continue la surveillance, et je pense que la règle du drop est nickel si je réactive le partage de la box ( elle me sert de sauvegarde donc j'en ai besoin ).
1) D'ici, je ne sais pas trop ce que veux dire "le partage de la box", je veux dire en terme d'informatique réseau… Bref.
2) La règle fonctionne très bien si elle n'est pas précédée d'une autre règle qui la contourne
Et là je ne peux pas vérifier pour toi: d'où ma demande avec la commande précédente pour laquelle tu n'as pas donné le résultat…  8)
3) Les plus de 1000 règles figurant dans iptables INPUT. Tu peux les virer, tu vas gagner en lisibilité !! La règle que je t'ai filée fait très bien le boulot. "fail2ban" c'est bien en cas d'attaque, par sécurité, mais pas au-delà…
4) Ça va mieux pour ton ordinateur. Il faut maintenant comprendre et traiter ce qui se passe au niveau de ta box… Sinon tu vas avoir du traffic pour rien sur ton réseau dans le meilleur des cas…
Je viens de te lire, effectivement si ton serveur samba est sur la dmz, tout passe malgré les blocages configurés sur ta freebox…

je te laisse,
M'en vais…
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: ricobolo le 15 Octobre, 2021, 10:55:51
Salut Denebe,
1) Il s'agit d'un partage SMBV2 de la box, qui fait que l'on voit le disque dur de la box dans le partage réseau. Donc c'est ça qui ouvre au moins le port 445 a mon avis. Mais j'en ai besoin, la box sert de sauvegarde.
2) Oui la règle fonctionne très bien. Dommage que firewalld ne permette pas de changer l'ordre des règles via l'interface (ou alors j'ai pas vu). L'astuce que j'ai trouvé c'est de modifier une règle (par exemple mettre un journal) et comme ça elle passe en dernier. Mais bon si on veut remonter une règle, il faut modifier toutes celles qui la précède, ça peut être lourd.
D'ailleurs j'avais pensé que le firewall devait avoir une règle block all qui est toujours en dernier, mais effectivement je ne vois pas cette règle par défaut. En gros tout ce qui n'est pas autorisé est interdit. Que penses tu de rajouter cette règle ?
3) La commande est passée :
edserv:~ # iptables -L -n --line-numbers | grep -B2 192.168.0.0/24
num  target     prot opt source               destination        
1    FWDI_external  all  --  0.0.0.0/0            0.0.0.0/0           [goto]  match-set reseauLocal src
2    FWDI_internal  all  --  192.168.0.0/24       0.0.0.0/0           [goto]
--
num  target     prot opt source               destination        
1    FWDO_external  all  --  0.0.0.0/0            0.0.0.0/0           [goto]  match-set reseauLocal dst
2    FWDO_internal  all  --  0.0.0.0/0            192.168.0.0/24      [goto]
--
num  target     prot opt source               destination        
1    IN_external  all  --  0.0.0.0/0            0.0.0.0/0           [goto]  match-set reseauLocal src
2    IN_internal  all  --  192.168.0.0/24       0.0.0.0/0           [goto]
--
3    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 ctstate NEW
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 ctstate NEW
5    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:25 ctstate NEW
6    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:465 ctstate NEW
7    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:587 ctstate NEW
8    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpts:30000:30100 ctstate NEW
9    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:21 ctstate NEW
10   ACCEPT     udp  --  0.0.0.0/0            192.168.0.0/24       udp dpt:137 ctstate NEW
11   ACCEPT     udp  --  0.0.0.0/0            192.168.0.0/24       udp dpt:138 ctstate NEW
12   ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:139 ctstate NEW
13   ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:445 ctstate NEW
14   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22 ctstate NEW
15   ACCEPT     udp  --  0.0.0.0/0            192.168.0.0/24       udp dpt:137 ctstate NEW
16   ACCEPT     udp  --  0.0.0.0/0            192.168.0.0/24       udp dpt:138 ctstate NEW
--
22   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:10000 ctstate NEW
23   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:4948 ctstate NEW
24   ACCEPT     udp  --  0.0.0.0/0            192.168.0.0/24       match-set reseauLocal src udp dpt:5353 ctstate NEW
--
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 ctstate NEW
5    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:3128 ctstate NEW
6    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:25 ctstate NEW
7    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:465 ctstate NEW
8    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:587 ctstate NEW
9    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpts:30000:30100 ctstate NEW
10   ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:21 ctstate NEW
11   ACCEPT     udp  --  0.0.0.0/0            192.168.0.0/24       udp dpt:137 ctstate NEW
12   ACCEPT     udp  --  0.0.0.0/0            192.168.0.0/24       udp dpt:138 ctstate NEW
13   ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:139 ctstate NEW
14   ACCEPT     tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:445 ctstate NEW
15   ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:5353 ctstate NEW
16   ACCEPT     all  --  0.0.0.0/0            192.168.0.1          match-set reseauLocal src
17   ACCEPT     all  --  0.0.0.0/0            192.168.0.0/24       match-set reseauLocal src
18   ACCEPT     all  --  0.0.0.0/0            192.168.122.0/24     match-set reseauLocal src
19   ACCEPT     all  --  0.0.0.0/0            192.168.27.0/24      match-set reseauLocal src
20   ACCEPT     udp  --  0.0.0.0/0            192.168.0.0/24       match-set reseauLocal src udp dpt:5353 ctstate NEW

Mon ipset est dans la capture écran.
192.168.0.0./24 => réseau local
192.168.0.13 => une machine local recalcitrante ( ne devrait pas y etre )
192.168.122.2/24 => le pont vers les VM
192.168.27.65/24 => le réseau sous VPN


4) Oui j'ai compris que effectivement le serveur est sur la DMZ (de la box), et d'ailleurs je me demande l'intérêt ( c'est une config depuis la box). Je n'ai qu'un serveur sur lequel j'ouvre apache pour mes sites web; Il fait DNS et dnsMasq (5353) / PROXY / FTP / CUPS et samba pour le réseau local;  et c'est la box qui fait passerelle pour les autres pc de la maison. Donc a ton avis je peux enlever cette config de DMZ ? Qu'est ce que tu en penses ? Que va t-il se passer si j'enlève la DMZ depuis la box, les connexions samba vont aller ou ? Elles vont être stoppées ou bien elles vont aller là ou elles peuvent (première ip trouvée? ou sur le disque dur de la box via ip local de la box ?). Les ports 80 / 443 étant redirigés explicitement il devrait pas y avoir de soucis pour apache.
Si tu sais merci !
Bon en fait je vais faire le test.

En tout cas plus de Denied connection sur log.smdb, sauf une ce matin une je ne sais pas pourquoi faudrait que j'analyse mais je verrai plus tard. C'est mieux que 2300....
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 16 Octobre, 2021, 14:59:58
1) Il s'agit d'un partage SMBV2 de la box, qui fait que l'on voit le disque dur de la box dans le partage réseau. Donc c'est ça qui ouvre au moins le port 445 a mon avis. Mais j'en ai besoin, la box sert de sauvegarde.
Selon moi sur une box classique, le pare-feu inspecte les paquets transitant par l'interface WAN (entre le réseau internet et ton réseau local), bloque ou laisse passer  ces paquets selon les règles de pare-feu établies, mais n'impacte pas ton réseau local LAN (switch)… Ainsi, dans les grandes lignes, comme ton serveur samba est dans ton réseau local (sauf config spécifique à ta box), alors il devrait être accessible de ton réseau local, peu importe tes règles de pare-feu (comprenant tcp 445 notamment).
Mais tout cela dépend à mon sens maintenant plus de ta box, de la topologie de ton réseau informatique que de ton ordinateur et d'Opensuse… Je peux t'aider à réfléchir à la sécurité de ton ordinateur avec Opensuse, pour le reste sauf si quelqu'un du forum connaît le sujet et peut te renseigner, j'irais plus me renseigner sur un forum informatique généraliste (avec une section Freebox par exemple), ou sur un forum free…
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: denebe le 16 Octobre, 2021, 15:31:32
Après avoir rentrée la règle iptables, chez moi cela me donne:
toto-PC:/etc/firewalld # iptables -L -n --line-numbers | grep -B2 192.168.0.0/24
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination        
1    DROP       tcp  -- !192.168.0.0/24       0.0.0.0/0            tcp dpt:445
Chez moi on voit clairement que cette règle est la première de la chaine INPUT, c'est l'objectif.

Chez toi, deux possibilités:

Pour finir je m'y perd avec tes descriptions, je ne sais plus de quoi tu parles exactement. Partage freebox (intégré à la box) ? Serveur samba que tu as rajouté ? Réglage du pare-feu de ta box ? Serveur sur une dmz ? Comme déjà dit, je peux t'aider avec opensuse, mais le reste, tu pars dans tous les sens !! Prend un sujet un par un…
Bonne chance  :D

PS: vérifie que la zone external est bien appliquée à l'interface d'opensuse (??) par où transitent tes données.
Titre: Re : YAST FIREWALL QUE 2 ONGLETS ?
Publié par: ricobolo le 17 Octobre, 2021, 06:44:32
Merci Denebe, désolé je suis effectivement parti dans plusieurs sens, mais en fait tu m'as permis de me rendre compte de mon erreur. Et la difficulté effectivement est que tu ne connais pas bien la freebox. Mais en essayant de rester simple et synthétique :

IP Publique --> Box (incluant firewall  et services samba) --> switch /wifi  --> 1 serveur + 3 pc.
Dans la box, partie configuration routeur,  il y a une case a cocher qui s'apelle DMZ et quand on la coche on donne une IP locale de DMZ, correspondant à une machine. Moi j'avais coché bêtement cette case et mis l'ip du serveur croyant bien faire. En faisant ça tous les ports du serveur ouverts ( services activés comme apache, ftp, samba, sur le serveur) étaient implicitement accessibles. Au lieu de faire ça on peut définir dans la config de la box les ports que l'on veut rediriger et vers quel machine au cas par cas. Donc c'est ce que j'ai fait, j'ai ouvert les ports apache et mysql vers le serveur et j'ai enlevé la case DMZ. Je n'ai plus rien dans mes logs samba venant de dehors. Donc effectivement ce n'était pas le partage samba de la box qui ouvrait samba sur le serveur mails la définition de ce serveur en DMZ.
Voilà, pour moi ce problème est résolu. J'aimerai maintenant faire fonctionner samba en VPN, j'ouvrirai un sujet si nécessaire après avoir cherché et essayé, je n'en ai pas encore eu le temps tout simplement.
Et encore merci pour ton aide,
Eric