shorewall (suite)

Le
jip
bonjour,

Grâce aux réponses à mes posts précédents, j'ai réussi à
configurer shorewall 1.4.8 sous mandrake 9.2 avec
adsl et partage de connexion avec un pc réseau sous win98
en adaptant les fichiers récupérés dans le 'pak'
"two-interfaces.gz" du site de shorewall.
Tout fonctionne bien, même ssh (Putty) depuis le pc win
vers le pc linux.

J'ai lancé le test sur http://scan.sygate.com/stealthscan.html
qui me signale que certains ports sont fermés mais pas
bloqués (80, 113, 139 et 445).
C'est grave, docteur ?
Que faudrait-il modifier dans la config de shorewall pour avoir
un résultat de test "parfait" ?

merci,
jip
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
g.patel
Le #1520397
On Fri, 30 Apr 2004 17:30:36 +0200, jip wrote:

J'ai lancé le test sur http://scan.sygate.com/stealthscan.html
qui me signale que certains ports sont fermés mais pas
bloqués (80, 113, 139 et 445).
C'est grave, docteur ?


Pas vraiment à mon avis. L'idée est de se cacher tellement
bien que les 'vilains' croiront qu'il n'y a personne et ne reviendront
pas; mais les vilains sont nombreux et il cherchent en permanence.
De toute manière un port fermé ne peut pas etre utilisé plus
qu'un port bloqué. Seul un port ouvert sur un service vulnérable
est dangereux.
Par ailleurs, certains pensent qu'il n'est pas poli de se
cacher completement; par exemple le service ident (113) sert
à s'identifier, montrer qu'on n'a rien à cacher, qu'on est un
client 'civilisé', quand on se connecte sur un serveur sur Internet
pour utiliser ses services. Impératifs contradictoires...(en
fait Shorewall rejette le port ident pour éviter des délais
désagréables dans certains cas)

Que faudrait-il modifier dans la config de shorewall pour avoir
un résultat de test "parfait" ?


éditer /etc/shorewall/common.def et supprimer les lignes
correspondants aux ports en question qui provoquent un
'reject' (actif) plutot qu'un 'drop' (mise à la poubelle, qui est
la politique par défaut pour ce qui vient d'Internet).
Un grep de /etc/shorewall pour 445 aurait retourné l'information.

Gérard Patel

Le #1058567
Bonjour,

Je voulais simplement vous remercier pour cette réponse
qui m' a permis effectivement de bloquer complètement les
ports 80, 113, 139 et 445 en passant DROP dans le fichier
/etc/shorewall/common.def

run_iptables -A common -p icmp -j icmpdef
############################################################################
# NETBIOS chatter
#
# run_iptables -A common -p udp --dport 135 -j reject
run_iptables -A common -p udp --dport 135 -j DROP

Au début je me suis fais avoir par la syntaxe de DROP qui doit
impérativement être orthographié en MAJUSCULE sinon message
d'erreur au redémarrage de shorewall.

Merci encore

On Fri, 30 Apr 2004 17:30:36 +0200, jip wrote:


J'ai lancé le test sur http://scan.sygate.com/stealthscan.html
qui me signale que certains ports sont fermés mais pas
bloqués (80, 113, 139 et 445).
C'est grave, docteur ?



Pas vraiment à mon avis. L'idée est de se cacher tellement
bien que les 'vilains' croiront qu'il n'y a personne et ne reviendront
pas; mais les vilains sont nombreux et il cherchent en permanence.
De toute manière un port fermé ne peut pas etre utilisé plus
qu'un port bloqué. Seul un port ouvert sur un service vulnérable
est dangereux.
Par ailleurs, certains pensent qu'il n'est pas poli de se
cacher completement; par exemple le service ident (113) sert
à s'identifier, montrer qu'on n'a rien à cacher, qu'on est un
client 'civilisé', quand on se connecte sur un serveur sur Internet
pour utiliser ses services. Impératifs contradictoires...(en
fait Shorewall rejette le port ident pour éviter des délais
désagréables dans certains cas)


Que faudrait-il modifier dans la config de shorewall pour avoir
un résultat de test "parfait" ?



éditer /etc/shorewall/common.def et supprimer les lignes
correspondants aux ports en question qui provoquent un
'reject' (actif) plutot qu'un 'drop' (mise à la poubelle, qui est
la politique par défaut pour ce qui vient d'Internet).
Un grep de /etc/shorewall pour 445 aurait retourné l'information.

Gérard Patel



Publicité
Poster une réponse
Anonyme