[wiki]iptables:un pare-feu pour un client

anonyme · 08-05-2015 14:28:46

je voulais faire un résumé , disons rapidement regles incomplettes pour un pc de bureau , une erreur de commande .
en autre services important , dhcp client , imprimante sur le reseau local , ntp ,peut etre partage de fichier sur le reseau.
regles a verifier ou a créer
cas du dhcp a eclaircir , important.
vérifier les regles , pas forcement la meilleure methode
sinon ce tuto client serait le meilleur pour moi a ma connaissance et il fonctionne

ce qui n est pas le cas pour le tuto "pare-feu pour une passerelle" (je precise pour quelqu un qui le met en place sans trop comprendre ce qu il fait )

ps: l ajout d une regle pour steam aussi (port 27000 il me semble )

Dernière modification par anonyme (08-05-2015 15:09:53)

anonyme · 13-05-2015 13:27:35

Bonjour

un lien pour ceux qui se lance dans ce tuto https://debian-facile.org/viewtopic.php … 60#p119960

ce matin j ai teste la messagerie exim4 c est ok
quelques petites modifs suite au conseil du membre raleur
j'espere qu il fera d autres observations

j'ai énuméré et testé toutes mes applications (meme steam )
voila pour le client

,pour le pare-feu de la passerelle c est un echec

il y a un petit paragraphe pour la désactivation d ipv6 .
ps: pour exim4 je sais pas si il y a un tuto , le cas ou je peut donner un coup de main
@++

milou · 25-10-2015 13:27:52

J'ai remplacé un lien cassé par la sortie de la page DHCP du chantier.
Vu les nombreuses remarques ci-dessus

la page est à mettre en conformité ?

milou · 01-11-2015 17:51:43

Bon j'ai quand même mis en conformité
Retours de commande et fichier passés en blocs config
J'ai séparé deux lignes de commande

plop6 · 21-10-2016 23:27:56

J'ai suivi le Tuto pour un poste desktop avec quelques modifications pour l'ipv6 qui n'y est pas traité ( ui je n'utilise pas ipv6 du coup j'ai tout fermé ).
J'utilise le paquet "iptables-persistent" pour ma part plutôt qu'un script init oubien systemd.
Voiçi le script que j'ai utilisé:

#!/bin/bash

####################

## CLEAN IPTABLES

####################

## flush iptables

/sbin/iptables -F

/sbin/ip6tables -F

## dell all users chain

/sbin/iptables -X

/sbin/ip6tables -X

#################

## DEFAULT POLICY

#################

## input drop

/sbin/iptables -P INPUT DROP

/sbin/ip6tables -P INPUT DROP

## output drop

/sbin/iptables -P OUTPUT DROP

/sbin/ip6tables -P OUTPUT DROP 

## forward drop

/sbin/iptables -P FORWARD DROP

/sbin/ip6tables -P FORWARD DROP

################

# LO SETTING

################

/sbin/iptables -t filter -A OUTPUT -o lo -j ACCEPT

/sbin/iptables -t filter -A INPUT -i lo -j ACCEPT

##############################

# Allow DNS server TRAFIC

##############################

/sbin/iptables -t filter -A OUTPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT

/sbin/iptables -t filter -A INPUT -p udp -m udp --sport 53 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

#############################

# Allow ping internal network

#############################

/sbin/iptables -A OUTPUT -o eth0 -p icmp -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

/sbin/iptables -A INPUT -i eth0 -p icmp -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

#########

# Get web

#########

/sbin/iptables -t filter -A OUTPUT -p tcp -m multiport --dports 80,443,8000 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT

/sbin/iptables -t filter -A INPUT -p tcp -m multiport --sports 80,443,8000 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

on lance le script avec sudo, ce qui va ré-initialisé les règles (suivant le tuto) puis appliquer les règles que j'ai choisi depuis le script.
Ensuite il faut juste utiliser:

sudo netfilter-persistent save

 

run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save

run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save

Bon ne sachant pas si le fait de laisser la POLICY de ipv6 en ACCEPT ou DROP de manière générale, j'ai drop.
N'hésitez pas a rectifié mes choix !!

En tout cas très beau tuto dans l'ensemble
Testé et validé.

anonyme · 23-10-2016 00:24:25

Sur linux tu peut désactiver aussi l IPV6 sur la machine par grub ou par le noyau , j'ai plus la commande en tete mais ça fonctionne
oui le tuto pour un client fonctionne , c'est pour la passerelle ou j ai eu des soucis mais bon suis pas très bon la dessus

Croutons · 06-01-2017 10:58:40

Bonjour
J'ai survolé le tuto, un peu prise de tête pour un matin

Je vois ping sur google.fr en root, pas besoin d’être en root pour le ping si? en fin c'est juste un détail

Beta-Pictoris · 22-08-2018 15:04:02

Bonjour,

En ce qui concerne les échanges udp avec les serveurs dns, sous Stretch, pourquoi les règles suivantes seraient moins bien que celles du wiki ?

iptables -t filter -A OUTPUT -p udp --dport 53 -m conntrack --ctstate NEW         -j ACCEPT

iptables -t filter -A INPUT  -p udp --sport 53 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Pour information, voici les règles du wiki :

iptables -t filter -A OUTPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT

iptables -t filter -A INPUT  -p udp -m udp --sport 53 -m conntrack --ctstate RELATED,ESTABLISHED     -j ACCEPT

Dernière modification par Beta-Pictoris (22-08-2018 15:11:19)

smolski · 22-08-2018 16:58:57

Croutons a écrit :

Je vois ping sur google.fr en root, pas besoin d’être en root pour le ping

Ah oui ! Non, en user ça fonctionne. Modifié le wiki.
Merci

Beta-Pictoris · 23-08-2018 12:29:12

Beta-Pictoris a écrit :

Bonjour,

En ce qui concerne les échanges udp avec les serveurs dns, sous Stretch, pourquoi les règles suivantes seraient moins bien que celles du wiki ?
iptables -t filter -A OUTPUT -p udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT

iptables -t filter -A INPUT -p udp --sport 53 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Pour information, voici les règles du wiki :

iptables -t filter -A OUTPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT

iptables -t filter -A INPUT -p udp -m udp --sport 53 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

L'abus de 'RELATED' peut entraîner des problèmes de sécurité: https://gist.github.com/azlux/6a70bd38b … 7e3a7ea8ac

Ça ne vous gène pas ?

Dernière modification par Beta-Pictoris (23-08-2018 12:29:42)

smolski · 23-08-2018 12:50:15

Le mieux est que tu prennes en main le tuto et que tu corriges le tuto du wiki.
C'est le principe que chaque membre mette à jour et en améliore ou corrige les tutos.

Ne te gêne de rien et tu peux supprimer ce qui te paraît obsolète en le signalant, c'est tout.

Merci de ton intervention !

Edit : nous avons une sauvegarde, il n'y a pas de problème.

Dernière modification par smolski (23-08-2018 12:51:11)

raleur · 23-08-2018 19:39:28

Croutons a écrit :

pas besoin d’être en root pour le ping si?

Réponse courte : non, pas besoin.
Réponse longue :
La commande ping utilise un socket "raw" pour émettre et recevoir les paquets ICMP, ce qui nécessite un privilège que n'a pas un utilisateur normal.
Historiquement ces privilèges étaient acquis par le bit SUID activé dans les permissions de l'exécutable /bin/ping qui le fait exécuter avec les privilèges de son propriétaire root et qu'on peut voir avec ls.

$ ls -l /bin/ping

-rwsr-xr-x 1 root root 31360 14 oct.   2010 /bin/ping

A partir de la version 8 de Debian, l'exécutable /bin/ping n'a plus le bit SUID mais le privilège (capability) CAP_NET_RAW permettant d'utiliser des sockets "raw", qu'on peut voir avec getcap.

$ ls -l /bin/ping

-rwxr-xr-x 1 root root 43056 nov.   8  2014 /bin/ping

/sbin/getcap /bin/ping

/bin/ping = cap_net_raw+ep

Beta-Pictoris a écrit :

En ce qui concerne les échanges udp avec les serveurs dns, sous Stretch, pourquoi les règles suivantes seraient moins bien que celles du wiki ?

Elles ne le sont pas, les tiennes sont meilleures. Le trafic DNS n'utilise pas l'état RELATED.

Beta-Pictoris · 23-08-2018 23:09:59

Ok, j'ai fait la modification dans le wiki.

Raleur, avec le noyau 4.9, les modules helpers ne sont plus chargés et activés automatiquement. Tu confirmes ?

Mais quelle est la situation pour les connexions icmp ?

naguam · 23-08-2018 23:19:13

Faudra que je prenne des cours avec vous

Beta-Pictoris · 24-08-2018 08:36:04

J'ai fait une formation sur 'iptables' il y a plusieurs années (à l'ENI). Je constate finalement que les formateurs ne maîtrisaient que partiellement le sujet.

Redhat est passé sur 'firewalld' il y a quelques années. Même si certains critiquent, ça reste plus simple à configurer, et moins dangereux pour la sécurité.

De même sur Ubuntu, c'est 'ufw' qui est installé par défaut.

naguam · 24-08-2018 09:45:20

Oui des surcouches de configuration de iptables.
Il existe aussi nftables qui permet une gestion différente des règles de configuration (qui n'est pas une surcouche de iptables) mais il semble pas percer. (pas beaucoup de monde semble l'utiliser).

raleur · 24-08-2018 11:15:47

Beta-Pictoris a écrit :

avec le noyau 4.9, les modules helpers ne sont plus chargés et activés automatiquement. Tu confirmes ?

Les modules helpers n'ont jamais été chargés automatiquement. Si tu veux parler de l'association automatique des helpers aux connexions concernées, je confirme qu'elle n'est plus activée par défaut. On peut la réactiver en passant un paramètre au module nf_conntrack ou en écrivant 1 dans /proc/sys/net/netfilter/nf_conntrack_helper (de mémoire, je n'ai plus les informations exactes en tête). Sinon il faut affecter un helper explicitement à une connexion avec la cible CT dans la table raw.

Beta-Pictoris a écrit :

Mais quelle est la situation pour les connexions icmp ?

Les paquets ICMP de types d'erreur (destination unreachable, time exceeded, parameter problem...) liés à une "connexion" existante sont automatiquement classés dans l'état RELATED si le module nf_conntrack_ipv4 est chargé. Ce module est chargé automatiquement notamment si une règle utilisant la correspondance state ou conntrack est créée.

Beta-Pictoris a écrit :

J'ai fait une formation sur 'iptables' il y a plusieurs années (à l'ENI). Je constate finalement que les formateurs ne maîtrisaient que partiellement le sujet.

Cela ne me surprend pas. Il faut un minimum de pratique pour bien maîtriser iptables et netfilter, sans parler de la veille pour se tenir informé des changements incessants.

Beta-Pictoris · 24-08-2018 14:19:05

raleur a écrit :

Les paquets ICMP de types d'erreur (destination unreachable, time exceeded, parameter problem...) liés à une "connexion" existante sont automatiquement classés dans l'état RELATED si le module nf_conntrack_ipv4 est chargé. Ce module est chargé automatiquement notamment si une règle utilisant la correspondance state ou conntrack est créée

Sais-tu si on peut empêcher le classement des paquets icmp dans l'état RELATED et les laisser dans l'état NEW ?

Dernière modification par Beta-Pictoris (24-08-2018 14:27:24)

raleur · 24-08-2018 15:19:53

Les messages d'erreur ICMP ne peuvent pas être dans l'état NEW car ils ne n'établissent pas une nouvelle connexion (ce type de paquet n'attend aucune réponse, pas même un autre message d'erreur ICMP pour éviter une éventuelle boucle sans fin). Seuls les paquets qui sont susceptibles d'engendrer une réponse peuvent avoir l'état NEW, comme le type ICMP echo-request envoyé par la commande ping.

Le plus qu'on puisse faire à ma connaissance est de leur appliquer la cible NOTRACK dans la table "raw" afin qu'ils soient ignorés par le suivi de connexion. Ils auront alors l'état UNTRACKED.

Mais pourquoi vouloir qu'ils aient l'état NEW ? Quel est le problème avec l'état RELATED de ces paquets ?
Un message d'erreur ICMP ne correspondant à aucune "connexion" enregistrée par le suivi de connexion est classé dans l'état INVALID.

Debian-facile

#26 08-05-2015 14:28:46

Re : [wiki]iptables:un pare-feu pour un client

#27 13-05-2015 13:27:35

Re : [wiki]iptables:un pare-feu pour un client

#28 25-10-2015 13:27:52

Re : [wiki]iptables:un pare-feu pour un client

#29 01-11-2015 17:51:43

Re : [wiki]iptables:un pare-feu pour un client

#30 21-10-2016 23:27:56

Re : [wiki]iptables:un pare-feu pour un client

#31 23-10-2016 00:24:25

Re : [wiki]iptables:un pare-feu pour un client

#32 06-01-2017 10:58:40

Re : [wiki]iptables:un pare-feu pour un client

#33 22-08-2018 15:04:02

Re : [wiki]iptables:un pare-feu pour un client

#34 22-08-2018 16:58:57

Re : [wiki]iptables:un pare-feu pour un client

#35 23-08-2018 12:29:12

Re : [wiki]iptables:un pare-feu pour un client

#36 23-08-2018 12:50:15

Re : [wiki]iptables:un pare-feu pour un client

#37 23-08-2018 19:39:28

Re : [wiki]iptables:un pare-feu pour un client

#38 23-08-2018 23:09:59

Re : [wiki]iptables:un pare-feu pour un client

#39 23-08-2018 23:19:13

Re : [wiki]iptables:un pare-feu pour un client

#40 24-08-2018 08:36:04

Re : [wiki]iptables:un pare-feu pour un client

#41 24-08-2018 09:45:20

Re : [wiki]iptables:un pare-feu pour un client

#42 24-08-2018 11:15:47

Re : [wiki]iptables:un pare-feu pour un client

#43 24-08-2018 14:19:05

Re : [wiki]iptables:un pare-feu pour un client

#44 24-08-2018 15:19:53

Re : [wiki]iptables:un pare-feu pour un client

Pied de page des forums