Question sur les ports à autoriser en sortie pour un serveur

[lol]

Salut,
Je suis en train de lister les ports qui ont un intérêt à être ouverts en sortie pour un serveur, j'aimerais votre avis pour être sur de ne pas en oublier...
Sur ce serveur Mails, Apache2 et pas mal de sites web, un git, un redmine, Nextcoud, un serveur XMPP, FTP, etc... (un peu comme le serveur qui héberge le forum).
J'en oublie surement...

UDP 53 pour la résolution
UDP 1194 pour le client openvpn

TCP 80 et 443 pour apt et d'éventuels téléchargement avec curl ou wget.
TCP 22 Scripts qui font du ssh
TCP 21 Scripts FTP
TCP 25 pour lenvoi de mail. Faut-il aussi mettre 587 et 465 ?

Le ping en sortie évidemment.

Vous en voyez d'autres indispensables ?
Autre question: Faut-il dupliquer tous les ports IPv4 ouverts en sortie en IPv6 ? J'aurais tendance à dire oui, évidemment, mais j'aimerais confirmation.

[Dunatotatos]

ouverts en sortie

Pas en entrée ? Je peux me tromper, mais tout bloquer en sortie devrait rendre un simple wget impossible.

[franb]

Non, il y a des règles
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
et
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
i'imagine...

Tu peux mettre les ports 123 UDP/TCP pour le service NTP. Mais regarde au fur et à mesure je pense

[lol]

u
ouverts en sortie

Pas en entrée ? Je peux me tromper, mais tout bloquer en sortie devrait rendre un simple wget impossible.

Oui, en sortie.
La politique par défaut d'un pare feu devrait être à DROP (INPUT FORWARD et OUTPUT).
Relis mon poste, j'ouvre les ports 80 et 443 en sortie, donc pas de soucis pour apt wget et curl.

Non, il y a des règles
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
et
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
i'imagine...

Tu peux mettre les ports 123 UDP/TCP pour le service NTP. Mais regarde au fur et à mesure je pense

Oui il y a évidemment toutes les autres règles (established, lo, etc.).
Je n'avais pas pensé au 123, merci!

Je suppose que l'idéal est d'activer les logs et de regarder ce qui est DROP en output afin de faire les réglages...

[PascalHambourg]

Bonne année.

Aucun port n'est indispensable. Ce ne sont pas des ports qu'il faut autoriser mais les connexions nécessaires.
La résolution DNS passe par tels serveurs caches récursifs ? Alors il faut autoriser les requêtes DNS vers ces serveurs et eux seuls.
Les mises à jours se font depuis tels miroirs ? Alors il faut autoriser les connexions HTTP vers ces seuls serveurs.
Le VPN se connecte à tel serveur ? Alors il faut autoriser le tunnel vers ce serveur seulement.
Et ainsi de suite.

[lol]

Salut,
Et bonne année, j'avais oublié...

Ok, évidemment c'est le plus prudent. Un port 53 ouvert en sortie autorise à taper n'importe quel dns y compris un vérolé...

Il faudrait donc, au coup par coup, mettre en place ce genre de règle ?
iptables -A OUTPUT -p tcp -d debian-fr.xyz --dport 80 -j ACCEPT

Mais ça ne simplifie pas trop la mise en place des règles.
Je sais tu n'as jamais dis que c'était simple.
Il nous arrive par exemple à tous de faire des wget pour récupérer des fichiers à droite et à gauche, il faut modifier ses règles à chaque fois, c'est un peu chiant.
A moins d'avoir un fichier avec une liste de destinations et faire une boucle récursive dans ce fichier au lancement du script iptables.
Fichier qu'on complète au fur et à mesure.

Je suppose que tu t'emmerde pas avec ça, tu entre la ligne iptables directement en ligne de commande ?

[lol]

Autre problème auquel je viens de penser: le serveur de mail.
Impossible de savoir quelles destinations accepter, on est bien obligé de laisser le port 25 ouvert vers toutes les destinations, non ?

[franb]

Si ton serveur fonctionne en reception tu dois le laisser ouvert en INPUT (i.e autoriser l'établissement des connexions entrantes dirait Pascal). Si tu te sers d'un smarthost pour le courrier sortant, tu n'autorises en sortie que vers ce smarthost. SInon oui, tu dois l'autoriser en sortie (i.e autoriser l'établissement des connexions sortantes vers ce port.

Tu as la possibilité de réserver l'accès à un seul utilisateur ou un seul groupe (option --uid-owner, man iptables-extensions), bref tu peux clairement faire un réglage aux petits oignons, tout dépend du temps que tu peux y consacrer et de la sensibilité de ta machine...

[lol]

Merci pour la réponse,
C'est bien ce que je pensais pour le mail faut laisser tout ouvert (bien obligé...).
Mais le --uid_owner est une bonne idée, ça évite les envois pas des programmes indésirables!
Je vais regarder tout ça à tête reposée.

[lol]

Du coup je pense activer les logs iptables sur les paquets sortants pendant 8 jours pour avoir une meilleur vue de ce qui sort.

Code : Tout sélectionner

if $LOGGING ; then
        iptables -t filter -A OUTPUT -j LOG --log-level=4
        ip6tables -t filter -A OUTPUT -j LOG --log-level=4
fi

ça fait du monde...
Vous savez comment éviter de logguer les OUT=lo ???

[PascalHambourg]

Tu peux ajouter "! -o lo".
Ou bien placer la règle LOG après celle qui accepte les paquets sortant par lo.
Et limiter le log au premier paquet d'une connexion (état NEW), soit avec "-m state --state NEW" soit en plaçant la règle après celle qui accepte les paquets dans les états ESTABLISHED,RELATED.

[lol]

Parfait, merci.
J'avais bien pensé préciser la source en spécifiant l'interface, mais il y a du vpn. La règle négative est donc impeccable.
Et ne prendre que le premier paquet de chaque connexion est aussi une très bonne idée, ça allège beaucoup...

[Mimoza]

Pour le FTP uniquement le 21 n'est pas suffisant, de plus il faut choisir entre le mode passif ou actif :
https://fr.wikipedia.org/wiki/File_Tran ... connexions

[lol]

Hello,
Pour le client le 21 suffit non ? Le reste est en "related" qui lui est autorisé.
Pour ce qui est du passif/actif ça se règle au niveau du serveur.

Edit: Tu as raison il faut spécifier le mode passif/actif au client.

[Mimoza]

Même pour le client le 21 n suffit pas, c'est juste le canal de commande, il faut ouvrir le/les canals des données en plus. Pour ce qui est actif/passif il me semble que c'est une négo entre le client & serveur si les 2 supporte un ou les 2 mode.

FTP n'est pas si simple que ça a bien configurer pour naviguer sur le réseau.

[lol]

Tu as raison, c'est aussi chiant pour le client que pour le serveur.
J'ai configuré le serveur (passif avec les ports qui vont bien) de ce côté pas de soucis.
Faut que j'autorise aussi en sortie le client pour la fourchette des ports passifs.

Merci de m'y avoir fait penser.

[franb]

Il me semble qu'il y a un module nf_conntrack_ftp qui permet de considérer les connexions sur les ports passifs comme découlant de la connexion en cours et donc de les soustraire aux filtres sur les nouvelles connexions. En clair, à condition de laisser entrer les connexions établies «established», ce module permet de se passer de spécifier les ports passifs. Mais c'est à vérifier, je dis ça de mémoire.

Pour le mode actif, il faut juste autoriser le port 20 en sortie, de mémoire là encore, le mode actif fait que le serveur initalise la connexion à partir du port 20 sur un port précisé par le client. Dans le mode passif, le serveur propose un port au client et c'est le client qui initialise la connexion.

Pascal rectifiera si je dis une betise...

[Mimoza]

Oui le module nf_conntrack_ftp facilite pas mal les choses

[PascalHambourg]

Pour le mode actif, il faut juste autoriser le port 20 en sortie

Non.

le mode actif fait que le serveur initalise la connexion à partir du port 20 sur un port précisé par le client.

Oui.

Le module nf_conntrack_ftp seul ne suffit plus avec le noyaux récents : par défaut l'affectation automatique du helper ftp au port 21 est désactivée, il faut donc ajouter une règle iptables avec la cible CT pour l'affecter explicitement à une connexion de commande FTP.

Idem avec les helpers des autres protocoles "complexes" : PPTP, SIP, TFTP...

[lol]

Je n'ai qu'un seul script hebdo de backup ftp.
A destination d'une cible unique, je vais probablement autoriser toutes les connexions vers ce serveur, ce sera le plus simple.
Il y a finalement assez peu de protocoles à ouvrir en sortie: HTTP(S) et SMTP (sécurisé avec --uid-owner comme le suggérait François).
Le reste ce sont des connexions vers des cibles uniques (à autoriser).

J'enregistre les logs pendant 8 jours et j'épluche. Pas simple avec l'IPv6...