Journal Shorewall, des trucs bizarre avec la mdk 10.

Posté par  (site web personnel) .
Étiquettes : aucune
0
23
juil.
2004
Je fais toujours un tour sur http://grc.com(...) -> shields up pour tester mon firewall.

Or, j'ai remarqué qu'en insatllant shorewall avec la mdk 10, j'ai plusieurs prots qui sont "closed". Ils devraient etre "stealth"

-> 135 nottament (netbios je crois)

Quelqu'un a-t-il une explication ? cela vient-il du mode de test de shields up ? de shorewall ?

sachant que ds rules je n'ai rien sur ces ports la...

  • # Fait exprès

    Posté par  . Évalué à 1.

    Il me semble avoir lu sur le site de shorewall que l'auteur avait laissé volontairement quelques ports ouverts car il avait remarqué que son réseau marchait mieux dans ce cas. Je trouve que c'est très troublant. J'ai rajouté les règles de filtrage manuellement:
    DROP net fw tcp 135,139,445,113
    DROP net fw udp 135,139,445,113

    • [^] # Re: Fait exprès

      Posté par  . Évalué à 5.

      n'importe quoi : les ports sont bien bloquer par default, c'est seulemnt que ces ports se comporte comme des ports fermer pour eviter que trop de connections restent bloque sur ces ports....

      • [^] # Re: Fait exprès

        Posté par  (site web personnel) . Évalué à 2.

        Peut-on m'expliquer ce que cela signifie ?

        Personnellement, le port netbios... je dirais pas que j'en ai rien a br*** mais bon. Moi, les seuls ports que j'ouvre c'est bittorent et xmule avec iptable, quand je fais mes scripts. Je ne vois pas en quoi shorewall m'en garderait 4 fermé, alors que je ne veux meme pas qu'ils soient visibles.

        Cependant, si une explication détaillée est fournie, je veux bien essayer de comprendre :))

    • [^] # Re: Fait exprès

      Posté par  (site web personnel) . Évalué à 2.

      Il me semble avoir lu sur le site de shorewall que l'auteur avait laissé volontairement quelques ports ouverts

      closed != ouvert, tu sais.
      Un port est ouvert si et seulement si un processus écoute dessus.
      Il est fermé si aucun processus n'écoute dessus, ou que le firewall a une règle REJECT avec.
      Il est "stealth" si le firewall a une règle DROP.

      Les seuls "avantages" d'un firewall qui droppe au lieu de rejeter, c'est
      1) Signifier aux scanners de ports que tu as un firewall
      2) Faire des timeout gigantesques au lieu d'avoir un "Connection refused"

      Or, les timeouts gigantesques, s'ils ralentissent un port scan (et encore, pas tellement) ralentissent aussi certaines autres choses. Par exemple, la plupart des serveurs IRC, mais aussi POP3 (et d'autres) essayent d'établir une connexion sur le port ident (113) du client. Si tu le droppe (ou que tu n'as ni firewall ni identd), la connexion normale continue immédiatement. Si tu le rejette, la connexion normale est interrompue un certain temps, et ça te fait chier toi.

      • [^] # Re: Fait exprès

        Posté par  . Évalué à 3.

        > Si tu le droppe (ou que tu n'as ni firewall ni identd), la connexion normale continue immédiatement. Si tu le rejette, la connexion normale est interrompue un certain temps, et ça te fait chier toi.

        c'est le contraire, non ?

  • # C'est peut-être ton FAI qui bloque ces ports là

    Posté par  . Évalué à 1.

    Moi par exemple, comme suggéré par www.grc.com, quand j'accepte tous le traffic venant de www.grc.com pour le test du firewall (il me suffit d'ajouter une règle iptables), j'obtiens ceci:
    http://home.tele2.fr/solsTiCe/grc_test.html(...)

    ce qui prouve que mon FAI bloque par défaut les ports 135-139, 445 et 593.

    Plus précisement il ne les bloque pas. il les filtre avec un pare-feu pour qu'ils apparaissent inéxistants pour ceux ne faisant pas parti de son réseau. C'est à dire tout le monde sur internet à part ses clients

    donc ca ne vient sans doute ni de shorewall, ni de mdk, ni de shields up mais de ton FAI.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.