OVH Cloud OVH Cloud

Fedora Core 3 et iptables

6 réponses
Avatar
Guilhem
Bonjour à tous,
Alors voilà, j'aimerais faire appel aux experts en matière de sécurité.
J'ai installé l'ensemble des packages de Fedora Core 3 sur mon
ordinateur. En démarrant mon ordinateur, je remarque qu'un firewall a
été installé. Je me connecte sur le site web "Shields up" et je vois que
le port 0 est ouvert. Est-ce grave ? A quoi sert ce port ? Comment le
fermer ?
J'ai donc essayé de réagir en créant moi-même mon script iptables que voici:

==========================================================================
. /etc/rc.d/init.d/functions

# Suppression de toutes les chaines pre-definies de la table FILTER
iptables -t filter -F

# Suppression de toutes les chaines utilisateur de la table FILTER
iptables -t filter -X

# Par defaut, toute les paquets sont detruits
iptables -t filter -P INPUT DROP
iptables -t filter -P OUTPUT DROP
iptables -t filter -P FORWARD DROP

# Autorise l'interface loopback a dialoguer avec elle-meme
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

#Connexion a internet (dns, http, ...). Les reponses ne sont envoyees
#seulement lorsque je les demande
iptables -t filter -A OUTPUT -o ppp0 -p all -m state --state ! INVALID
-j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p all -m state --state
RELATED,ESTABLISHED -j ACCEPT
==========================================================================

Ce script passe avec succès les tests de "Shields Up" mais je suis
surpris par-rapport à la simplicité de ce script, comparé çà celui
proposé par Fedora Core 3. Ai-je commis une erreur ? Si oui, laquelle ?

J'hésite donc à remettre la configuration par défaut du firewall, quitte
à avoir le port 0 d'ouvert. Qu'en pensez-vous ?

Enfin, FC3 installe SELInux. Qu'est-ce donc ? Dois-je l'activer ?

Je sais que tout cela fait beaucoup de questions mais si il y a des
experts en la matière, j'aimerais bien qu'il me dise ce qu'ils en
pensent. Merci.

Cordialement.

Guilhem.

6 réponses

Avatar
Rakotomandimby (R12y) Mihamina
( Thu, 10 Mar 2005 10:54:24 +0100 ) Guilhem :

la simplicité de ce script, comparé çà celui
proposé par Fedora Core 3.


Celui proposé par défaut est censé pouvoir etre adaptable à un grand
nombre de situation.
Ton script à toi n'a pas été pensé pour éventuellement convenir à
d'autres.
Ca aide beaucoup à faire des choses simples :-)

Sinon tu peux encore le faire plus simple, en enlevant tous les '-t
filter' car quand tu ne mentionne pas '-t' et son argument, c'est par
défaut considéré comme '-t filter'.

Quant au port 0 et à SeLinux:
http://www.google.fr/search?q=iptables+block+port+0
http://www.google.fr/search?q=selinux
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)

Avatar
Pascal
Salut,

Alors voilà, j'aimerais faire appel aux experts en matière de sécurité.


A ce propos, ce n'est pas une bonne idée d'avoir multiposté ici et dans
fr.comp.securite. Ça va créer deux discussions indépendantes avec pour
inconvénients la redondance (des participants vont dire la même chose
dans les deux discussions) et la moindre interaction entre les
participants (un participant à une des discussion ne pourra pas réagir à
ce qu'un autre participant a écrit dans l'autre discussion). Un
crosspost avec suivi dans un des deux forums aurait été préférable.

J'ai installé l'ensemble des packages de Fedora Core 3 sur mon
ordinateur. En démarrant mon ordinateur, je remarque qu'un firewall a
été installé. Je me connecte sur le site web "Shields up" et je vois que
le port 0 est ouvert. Est-ce grave ?


Ça dépend. Port TCP ou UDP ? De mémoire Shields Up! ne sonde que les
ports TCP.

A quoi sert ce port ?


Normalement à rien, il est réservé. Faut voir quel processus écoute
dessus (netstat --inet -lpn).

Comment le fermer ?


En arrêtant le processus qui écoute dessus.

J'ai donc essayé de réagir en créant moi-même mon script iptables que
voici:
[...]

iptables -t filter -A OUTPUT -o ppp0 -p all -m state --state ! INVALID
-j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p all -m state --state
RELATED,ESTABLISHED -j ACCEPT

Ce script passe avec succès les tests de "Shields Up" mais je suis
surpris par-rapport à la simplicité de ce script, comparé çà celui
proposé par Fedora Core 3. Ai-je commis une erreur ? Si oui, laquelle ?


Connais pas le firewall de Fedora, mais le tien est l'exemple-type du
firewall simpliste qui bloque sauvagement sans respecter les standards.
Malheureusement les scanners de ports en ligne comme Shields Up!
incitent cette attitude. :(

Les paquets reçus valides non acceptés devraient être rejetés proprement
avec la cible REJECT au lieu d'être bloqués silencieusement.

Attention aussi si tu utilises une version de noyau inférieure à 2.4.29
ou 2.6.10 : certains messages d'erreur ICMP émis par ta machine sont à
tort marqués INVALID au lieu de RELATED et donc bloqués par ta règle OUTPUT.

--
Pascal
Vous pouvez me tutoyer.
Piège à spam :

Avatar
Guilhem
Alors voilà, j'aimerais faire appel aux experts en matière de sécurité.
A ce propos, ce n'est pas une bonne idée d'avoir multiposté ici et dans

fr.comp.securite. Ça va créer deux discussions indépendantes avec pour
inconvénients la redondance (des participants vont dire la même chose
dans les deux discussions) et la moindre interaction entre les
participants (un participant à une des discussion ne pourra pas réagir à
ce qu'un autre participant a écrit dans l'autre discussion). Un
crosspost avec suivi dans un des deux forums aurait été préférable.
Oups, je suis désolé. Mais c'est quoi un crosspost ?


J'ai installé l'ensemble des packages de Fedora Core 3 sur mon
ordinateur. En démarrant mon ordinateur, je remarque qu'un firewall a
été installé. Je me connecte sur le site web "Shields up" et je vois
que le port 0 est ouvert. Est-ce grave ?
Ça dépend. Port TCP ou UDP ? De mémoire Shields Up! ne sonde que les

ports TCP.
TCP. Je viens de remettre la config. par défaut en modifiant légèrement

le script et là, le test est passé avec succès (stealth pour tous les
ports TCP) sauf:

========================================================================= Ping Reply: RECEIVED (FAILED) — Your system REPLIED to our Ping (ICMP
Echo) requests, making it visible on the Internet. Most personal
firewalls can be configured to block, drop, and ignore such ping
requests in order to better hide systems from hackers. This is highly
recommended since "Ping" is among the oldest and most common methods
used to locate systems prior to further exploitation.
=========================================================================
Est-ce grave ?

A quoi sert ce port ?
Normalement à rien, il est réservé. Faut voir quel processus écoute

dessus (netstat --inet -lpn).
Le résultat de la commande est le suivant:


========================================================================= Proto Recv-Q Send-Q Local Address Foreign Address
State PID/Program name
tcp 0 0 127.0.0.1:631 0.0.0.0:*
LISTEN 3969/cupsd
tcp 0 0 127.0.0.1:5335 0.0.0.0:*
LISTEN 3934/mDNSResponder
udp 0 0 0.0.0.0:631 0.0.0.0:*
3969/cupsd
=========================================================================
Que cela signifie-t-il ?

Comment le fermer ?
En arrêtant le processus qui écoute dessus.

Mais il va se relancer à chaque démarrage ?


J'ai donc essayé de réagir en créant moi-même mon script iptables que
voici:
[...]

iptables -t filter -A OUTPUT -o ppp0 -p all -m state --state ! INVALID
-j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p all -m state --state
RELATED,ESTABLISHED -j ACCEPT
Ce script passe avec succès les tests de "Shields Up" mais je suis
surpris par-rapport à la simplicité de ce script, comparé çà celui
proposé par Fedora Core 3. Ai-je commis une erreur ? Si oui, laquelle ?
Connais pas le firewall de Fedora, mais le tien est l'exemple-type du

firewall simpliste qui bloque sauvagement sans respecter les standards.
Malheureusement les scanners de ports en ligne comme Shields Up!
incitent cette attitude. :(
Je veux bien le croire car je ne connais pas grand chose à Linux...

Comment l'améliorer ? (il s'agit d'un poste personnel, sans serveur)

Les paquets reçus valides non acceptés devraient être rejetés proprement
avec la cible REJECT au lieu d'être bloqués silencieusement.
Mais alors "STEALTH" devient "CLOSE"... Et c'est moins discret, non ?


Attention aussi si tu utilises une version de noyau inférieure à 2.4.29
ou 2.6.10 : certains messages d'erreur ICMP émis par ta machine sont à
tort marqués INVALID au lieu de RELATED et donc bloqués par ta règle
OUTPUT.
Comment ça ?


Je suis désolé pour toutes ces questions mais j'ai un peu de mal avec
iptables... Pouvez-vous m'aider ?

Merci mille fois. :-)

Cordialement.

Guilhem.


Avatar
Pascal

crosspost avec suivi dans un des deux forums aurait été préférable.


Oups, je suis désolé. Mais c'est quoi un crosspost ?


Pardon, c'est expliqué là :
http://www.usenet-fr.net/fur/minis-faqs/crosspost.html

TCP. Je viens de remettre la config. par défaut en modifiant légèrement
le script et là, le test est passé avec succès (stealth pour tous les
ports TCP) sauf:

========================================================================= > Ping Reply: RECEIVED (FAILED)
[snip blabla paranoïaque]


Est-ce grave ?


Pas du tout. Ta machine répond au ping, c'est bien.

(netstat --inet -lpn).
========================================================================= > Proto Recv-Q Send-Q Local Address Foreign Address

State PID/Program name
tcp 0 0 127.0.0.1:631 0.0.0.0:*
LISTEN 3969/cupsd
tcp 0 0 127.0.0.1:5335 0.0.0.0:*
LISTEN 3934/mDNSResponder
udp 0 0 0.0.0.0:631 0.0.0.0:*
3969/cupsd
========================================================================= >
Que cela signifie-t-il ?


Cela signifie qu'aucun processus n'est à l'écoute sur le port TCP 0. Le
seul port en écoute accessible de partout est UDP 631 utilisé par cupsd.
Les deux autres ports n'écoutent qu'en local (127.0.0.1).

Comment le fermer ?


En arrêtant le processus qui écoute dessus.


Mais il va se relancer à chaque démarrage ?


Certes :) il faut aussi l'empêcher de se relancer au démarrage. Voir les
scripts d'init.

[commentaires sur les règles iptables]
Les paquets reçus valides non acceptés devraient être rejetés
proprement avec la cible REJECT au lieu d'être bloqués silencieusement.


Mais alors "STEALTH" devient "CLOSE"... Et c'est moins discret, non ?


"Closed", c'est la réponse normale d'un port fermé et c'est bien.
Quel intérêt d'être "discret" ?

Attention aussi si tu utilises une version de noyau inférieure à
2.4.29 ou 2.6.10 : certains messages d'erreur ICMP émis par ta machine
sont à tort marqués INVALID au lieu de RELATED et donc bloqués par ta
règle OUTPUT.


Comment ça ?


Dans certaines conditions, une machine qui reçoit un paquet IP peut être
amenée à renvoyer un message ICMP à la source du paquet pour signaler
une erreur ou un problème. Cette signalisation est utile et il ne faut
pas la bloquer en émission ni réception. Normalement, ces paquets ICMP
sont dans l'état RELATED, mais un bug dans les anciens noyaux fait que
lorsqu'il sont émis par la machine elle-même ils peuvent être marqués
INVALID. Par contre les paquets ICMP reçus de l'extérieur sont
correctement marqués RELATED. Comme ta règle OUTPUT bloque les paquets
INVALID, avec un noyau trop vieux tu empêches ta machine de signaler les
problèmes aux autres, ce qui est gênant.

Je suis désolé pour toutes ces questions mais j'ai un peu de mal avec
iptables... Pouvez-vous m'aider ?


En fait je pense plutôt que tu as du mal avec la famille des protocoles
IP. iptables n'est qu'un moyen d'écrire des règles, le plus dur est de
définir quelles règles on va créer et pourquoi. Pourquoi autoriser ceci
ou bloquer cela. C'est là qu'une certaine connaissance d'IP est
nécessaire. Elle est aussi bien utile pour ne pas se faire enfumer par
les messages volontairement alarmants des sites de scan ou des firewalls
personnels. ;-)

--
Pascal
Vous pouvez me tutoyer.
Piège à spam :



Avatar
Guilhem
crosspost avec suivi dans un des deux forums aurait été préférable.
Oups, je suis désolé. Mais c'est quoi un crosspost ?

Pardon, c'est expliqué là :

http://www.usenet-fr.net/fur/minis-faqs/crosspost.html
Ah, d'accord !


TCP. Je viens de remettre la config. par défaut en modifiant
légèrement le script et là, le test est passé avec succès (stealth
pour tous les ports TCP) sauf:

==========================================================================
Ping Reply: RECEIVED (FAILED)
[snip blabla paranoïaque]

Est-ce grave ?
Pas du tout. Ta machine répond au ping, c'est bien.

Oh la la... Je crains que nous n'ayons pas du tout le même point de vue

de la sécurité ! Un ordinateur qui répond à un ping se fait
immédiatement reperé sur le réseau... ;-) Il existe des outils que les
pirates utilisent et qui balayent sans cesse le réseau en envoyant des
pings et attendent des réponses...

(netstat --inet -lpn).


==========================================================================

Proto Recv-Q Send-Q Local Address Foreign Address
State PID/Program name
tcp 0 0 127.0.0.1:631 0.0.0.0:*
LISTEN 3969/cupsd
tcp 0 0 127.0.0.1:5335 0.0.0.0:*
LISTEN 3934/mDNSResponder
udp 0 0 0.0.0.0:631 0.0.0.0:*
3969/cupsd
==========================================================================

Que cela signifie-t-il ?
Cela signifie qu'aucun processus n'est à l'écoute sur le port TCP 0. Le

seul port en écoute accessible de partout est UDP 631 utilisé par cupsd.
Les deux autres ports n'écoutent qu'en local (127.0.0.1).
Accessible de partout ? C'est à dire ? Je peux désactiver cupsd ?


Les paquets reçus valides non acceptés devraient être rejetés
proprement avec la cible REJECT au lieu d'être bloqués silencieusement.
Mais alors "STEALTH" devient "CLOSE"... Et c'est moins discret, non ?

"Closed", c'est la réponse normale d'un port fermé et c'est bien.

Quel intérêt d'être "discret" ?
De passer inaperçu ! :-)


Attention aussi si tu utilises une version de noyau inférieure à
2.4.29 ou 2.6.10 : certains messages d'erreur ICMP émis par ta
machine sont à tort marqués INVALID au lieu de RELATED et donc
bloqués par ta règle OUTPUT.
Comment ça ?

Dans certaines conditions, une machine qui reçoit un paquet IP peut être

amenée à renvoyer un message ICMP à la source du paquet pour signaler
une erreur ou un problème. Cette signalisation est utile et il ne faut
pas la bloquer en émission ni réception. Normalement, ces paquets ICMP
sont dans l'état RELATED, mais un bug dans les anciens noyaux fait que
lorsqu'il sont émis par la machine elle-même ils peuvent être marqués
INVALID. Par contre les paquets ICMP reçus de l'extérieur sont
correctement marqués RELATED. Comme ta règle OUTPUT bloque les paquets
INVALID, avec un noyau trop vieux tu empêches ta machine de signaler les
problèmes aux autres, ce qui est gênant.
Bah je n'ai pas envie de le signaler aux autres, donc ce n'est pas

gênant. ;-)

Cordialement.

Guilhem.



Avatar
Pascal

(netstat --inet -lpn).
[...]



Cela signifie qu'aucun processus n'est à l'écoute sur le port TCP 0.


Petite correction : sous Linux, si IPv6 est activé, un processus qui
écoute sur un port en IPv6 écoute aussi implicitement sur le même port
en IPv4 avec le mécanisme des adresses IPv4 mappées en IPv6 sous la
forme ::ffff:<IPv4>. Donc il faut aussi vérifier les ports et processus
en écoute en IPv6 (netstat --inet6 -lpn). Ou alors on peut simplement
afficher les processus en écoute sur des ports TCP quelle que soit la
version d'IP (netstat -ltpn).

--
Pascal
Vous pouvez me tutoyer.
Piège à spam :