Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Connaitre la gestion du firewall (iptables, ufw, etc.)

notezik

Bonjour à toutes et tous,

Ça ne va pas faire sérieux du tout, mais sur mon serveur principale, je ne sais pas quel service gère mon firewall. Je m'explique :
1/ si sur une machine du réseau je fais un nmap, j'ai :

Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-13 22:10 CEST
Nmap scan report for XXX (XXX.XXX.X.XX)
Host is up (0.0088s latency).
Not shown: 986 closed ports
PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
25/tcp    open  smtp
80/tcp    open  http
389/tcp   open  ldap
443/tcp   open  https
587/tcp   open  submission
993/tcp   open  imaps
5222/tcp  open  xmpp-client
5269/tcp  open  xmpp-server
5280/tcp  open  xmpp-bosh
8888/tcp  open  sun-answerbook
9001/tcp  open  tor-orport
10000/tcp open  snet-sensor-mgmt
MAC Address: XX:XX:XX:XX:XX:XX (ASRock Incorporation)

Nmap done: 1 IP address (1 host up) scanned in 0.33 seconds

2/ mais si sur mon serveur je fais un coup de :

/root iptables -L                    
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

3/ si je regarde si c'est ufw qui gère, un

ufw status

me dit inactif...
4/ J'ai bien un fichier /etc/iptables.firewall.rules mais que ne correspond pas aux règles données par le nmap.
5/ Sur mon webmin, rien de configurer...

Si quelqu'un·e peut m'aider !
Merci d'avance.

bruno

Bonjour,

Effectivement tu n'a pas de règles iptables. Est-ce grave ? Non.

Que fait nmap ?
En simplifiant nmap envoie des paquets sur les différents ports (par défaut de 1 à1024) de ton serveur et examine la réponse.
Si aucun service n'est en écoute sur ce port le noyau ignore silencieusement le paquet reçu. nmap ne reçoit donc aucune réponse : le port est fermé.
Si un service est en écoute, par exemple SSH sur le port 22, le noyau renvoie un paquet. nmap reçoit une réponse le port est ouvert.

Autrement dit, on ne peut atteindre ton serveur que sur des ports correspondant à des services actifs et en écoute sur une IP publique.

Le pare-feu n'est utile que pour établir des règles précises de filtrage entre le réseau et ton serveur : limitations de certains services à certaines IP si on ne peut faire autrement, limitations sur le nombre/la fréquence des connexion pour une me IP, blocage global d'IP externe, etc.

Si tu t'inquiètes de la sécurité, plutôt que d’établir des règles de pare-feu qui sont souvent inutiles, concentre-toi sur la sécurité des services que tu héberges.

EDIT : fôtes

notezik

bruno a écrit Le pare-feu n'est utile que pour établir des régles précises de filtrage entre le réseau et ton serveur : limitations de certains services à certaines IP si on ne peut faire autrement, limitations sur le nombre/la fréquence des connexion pour une me IP, blocage global d'IP externe, etc.

Si tu t'inquiètes de la sécurité, plutôt que d’établir des règles de pare-feu qui sont souvent inutiles, concentre-toi sur la sécurité des services que tu héberges.

Super merci de cette réponse.
Je me suis lancé là dedans car je voudrais, depuis une autre machine, me connecter au ldap, mais, si j'ai bien compris, pour pouvoir utiliser le ssh, il me faut m'y connecter en ssl. Et donc je veux ouvrir en plus le port 636.
Comment dois-je procéder à ton avis ? Utiliser ufw ? mais ça ne va pas écraser tout le reste ?

bruno

Je pensais avoir été clair : un port est ouvert parce qu'il y a un service actif en écoute dessus. Cela n'a pour l'instant rien à voir avec le pare-feu.
Tu as déjà un service ldap en écoute sur le port 389 :

389/tcp   open  ldap

Et le connexion en SSH se fait sur le port 22 :

22/tcp    open  ssh

notezik

bruno a écritJe pensais avoir été clair : un port est ouvert parce qu'il y a un service actif en écoute dessus. Cela n'a pour l'instant rien à voir avec le pare-feu.
Tu as déjà un service ldap en écoute sur le port 389 :

389/tcp   open  ldap

Et le connexion en SSH se fait sur le port 22 :

22/tcp    open  ssh

Oui oui j'ai bien compris ce que tu as dit qui était très clair. Mais le problème c'est que je veux que mon ldap écoute aussi le 636. Et j'ai suivi les instructions pour le faire (https://computingforgeeks.com/secure-ldap-server-with-ssl-tls-on-ubuntu/), mais ça ne m'a pas ouvert le 636. Et comme test sur le client (autre machine de mon réseau), si j'active ssl dans ldap.conf, je ne peux plus me connecter, et si je fais ça (test que j'ai lu qu'il fallait faire pour checker le paramétrage de ldap en ssl) :

openssl s_client -connect XXX.XXX.X.XX:636 -showcerts
140338386142528:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110:
140338386142528:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=111

Évidemment sur le port 443 ça fonctionne.
J'espère avoir été clair.
Merci.

bruno

Ça c'est dans la configuration de LDAP, cela n'a rien à voir avec un quelconque pare-feu.
Si tu l'a modifiée pour qu'il prenne en charge le protocole ldaps sur le port 636, il faut penser à redémarrer le service. Et ensuit vérifier avec :

sudo netstat -tnlp

Et visiblement il manque la modification de /etc/default/slapd dans ton tuto :
https://wiki.debian.org/LDAP/OpenLDAPSetup#Enable_TLS.2FSSL

notezik

Super merci du lien et des infos. Maintenant le port 636 est écouté, mais ça ne règle pas mon problème. Je vais donc ouvrir un autre fil de discussion !