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.
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).
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...
Il est là l'applet, enfin l’icône:
(https://i.ibb.co/0ywpbVG/firewall-applet.png) (https://ibb.co/0ywpbVG)
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,
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.
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...
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…
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 ?
@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.
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é.
On voit que susefirewall2 n'est pas installé, parfait.
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."
Je ne connaissais, ça a l'air intéressant et pratique.
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".
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:
- 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
- refuser tous les paquets en input avec le port-destination 445, protocol tcp
=> 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…
Oui ;)
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.
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....
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é.
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.
Fais voir un
iptables -L -n --line-numbers | grep -B2 192.168.0.0/24
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 ).
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…
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....
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…
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:
- Tu n'as pas rentré la règle iptable, tu utilises la règle firewalld que tu as citée au dessus
Mais normalement, si firewalld est actif, tu n'as pas besoin de ces règles firewalld, il bloque quasiment tout par défaut. - Tu as rentré la règle iptable
Constat: elle ne se trouve pas en haut comme chez moi, dans ce cas je ne peux pas t'assurer du bon fonctionnement
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.
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