Linux et firewall

OoO En cette nuit nuageuse du dimanche 09 avril 2006, vers 01:26,
"Stephane Catteau" <steph.nospam@sc4x.net> disait:

Il n'est pas dit que ce soit vraiment le cas, juste qu'elles ne sont
pas attribuables. De plus, le status est succeptible de changer un peu
n'importe quand, donc considérer ces adresses comme non routables
lorsque l'on configure un routeur revient à prendre un risque, même
s'il est minime ; l'on se retrouverait alors avec des paquets légitimes
à destination de 01/08 (pour garder la classe prise en exemple) qui se
retrouveraient droppé en cours de route par un routeur, embêtant non
?

Le risque est loin d'être minime. C'est assez embêtant d'aller
chercher pourquoi gmail ou java.sun.com ne marche pas derrière
certains routeurs et de découvrir qu'il y a 3 ans, on avait collé
toutes les classes non encore affectées par l'IANA comme non
routables.

Je ne vois que des inconvénients de ce style de les traiter ainsi. Et
aucun avantage : qui voudrait faire une attaque en prenant comme IP
une IP qui a largement plus de risque de ne pas être routée plutôt
qu'une IP correctement attribuée ?
--
printk("Entering UltraSMPenguin Mode...n");
2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c

Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote in
news:e15man$2bbv$1@biggoron.nerim.net:

Je pense qu'Eric ne parlait pas en terme de cheminement dans la pile
IP mais d'entrée et de sortie du processus de traitement par une règle
: - entrée = critères de correspondance du paquet = filtrage
- sortie = action (DROP, ACCEPT, LOG, MARK...)

Je ne vois pas comment interpréter son propos autrement.

c'etait effectivement le sens de mon propos, j'entendais "filtrage" dans le

sens de sélection... je pensais pourtant m'être exprimé clairement...
désolé !

--
Rico

Erwan David n'était pas loin de dire :

Pas que sous windows Les politiques par défaut avec iptables sont
uniqueent les target prédéfinies.

C'est aussi la politique par défaut pour IPFilter, Packet Filter[1],
IPFirewall, et j'en passe. Mais d'une part cela tient à la syntaxe
utilisée pour les règles (du moins pour les trois cités), et d'autre
part ils permettent de faire autre chose, ce qui n'est pas le cas des
firewalls pour Windows.


[1]
Quoi que Packet Filter permette de changer la politique par défaut.

Xavier Roche devait dire quelque chose comme ceci :

L'avantage n'est pas de se croire invisible, mais de limiter les
attaques [...] ce qui permet au contraire de focaliser son attention
sur les quelques scans restants qui eux, peuvent éventuellement être
intéressants à regarder.

J'ai déjà répondu à cela samedi soir :

<news:mn.48477d64e0c59fd9.30736@freu-inside.eu>
| Ce genre de personnes [NdA: les kiddies scanners] à tendance à ne
|pas savoir ce qu'elles font, donc lorsque leur magnifique outils de la
|mort qui tue leur dit qu'il n'y a pas eu de réponse, ils recommencent
|encore et encore, accusant qui leur incapable de FAI qui a perdu le
|paquet, qui ce "logiciel de [beep] de chez [beep]" qui ne sait
|décidément pas fonctionner correctement. A l'inverse, si le logiciel
|leur dit "c'est fermé", ils passent à l'adresse suivante.

A cela j'ajouterais les vers, qui eux aussi semblent réagir de la même
façon. Cela vaut ce que cela vaut, puisque les réseaux sont différents,
mais le routeur de ma môman, qui a la gentillesse (le routeur) de
m'envoyer ses logs tous les jours, est nettement plus solicité que ma
passerelle. Lui DROP, moi je réponds, et force m'est de constater que
chez moi les ports sont solicités une fois par adresse IP, et très
rarement deux ou trois fois, alors qu'ils le sont jusqu'à dix fois par
adresse IP chez ma chère môman et jamais une seule et unique fois.

Alors ton argument selon lequel être invisible limiterait le bruit de
ton côté, et bien désolé, mais je n'y crois pas. Pour ce que je peux en
constater c'est l'inverse qui se produit.

C'est comme les techniques de filtrage de spam, ou de masquage d'adresse
email: la plupart peuvent être facilement contournées ([...] ou bien la
réécriture des email en "nospam" pour le masquage) mais dans la
pratique, peu de spammeurs s'en donnent la peine.

Alors pourquoi mon adresse (*valide*) ne reçoit-elle qu'un ou deux
spams par semaine, contre plus de deux cents par jour pour une autre
adresse, moins utilisée sur le même domaine ?
Enfin, cela est hors charte, c'était juste pour l'annecdote.

Bref ce n'est pas parce qu'un moyen de protection n'est pas infaillible
qu'il ne faut pas l'utiliser.

La question demeure, le fait de dropper systématique te protège en
quoi ?

Il faut juste garder à l'esprit que ce n'est qu'un artifice qui ne
peut que ralentir ou limiter les attaques.

Les attaques ou les désagréments ? Les kiddies n'attaquent pas, ils
profitent de ce qui existe déjà. Par conséquent, que tu dropes ou que
tu répondes, s'ils peuvent passer, ils passeront. A l'inverse, les
pirates eux ne sont pas stupides au point de s'en tenir à un simple
DROP pour définir s'il y a une machine ou non ; cela d'autant plus
qu'ils ont les mêmes yeux que toi, et se sont donc eux aussi aperçu que
le réseau était parsemé de "trous noirs".

Erwan David devait dire quelque chose comme ceci :

Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :

En effet et c'est aussi bien ainsi, car un REJECT systématique ne se
justifierait pas (et avec quel type de réponse par défaut ?). Ça ne
change rien au fond. La politique par défaut DROP des chaînes de
filtrage ne devrait servir que de filet de sécurité en dernier ressort
en cas d'erreur dans le jeu de règles, et le sort de tout paquet
devrait normalement être déterminé explicitement par un règle.

Non, puisque la règle est de tout bloquer par défaut et d'ouvrir ce
dont on a besoin. Il faut donc que la politique par défaut corresponde
à cette méthode.

Au contraire. Il faut que la politique de bloquage par défaut
corresponde à autre chose que celle que tu appliqueras. De cette façon
en scannant ta machine pour vérifier que tu n'as pas merdé dans tes
règles, tu identifieras sans problèmes les ports bloqués parce que tu
as mis la règle qu'il faut (avec les restictions de ton choix
concernant l'ouverture du port), des ports qui sont bloqués par le DENY
ALL interne.

[De la réponse des routeurs si une adresse IP est injoignable/down]

J'ai cherché très rapidement, donc j'ai pu passer à côté de quelque
chose, mais j'ai trouvé la RFC 792 :

[Snip]

C'est un "may", donc pas d'obligation.
Par contre dans RFC 1818 "Requirements for IPv4 routers", les
paragraphes 4.3.3.1 et 5.2.7.1 disent "MUST".

Ce qui n'est toujours pas un "SHOULD", donc autant pour mon "il me
semblait que".

Si je ne m'abuse, MUST marque une obligation plus forte que SHOULD.

Pourquoi une classe réservée devrait-elle forcément être considérée
comme non routé/routable ?

Parce que ces adresses ne sont allouées à aucune machine accessible par
internet ?

Il n'est pas dit que ce soit vraiment le cas, juste qu'elles ne sont
pas attribuables. De plus, le status est succeptible de changer un peu
n'importe quand, donc considérer ces adresses comme non routables
lorsque l'on configure un routeur revient à prendre un risque, même
s'il est minime ; l'on se retrouverait alors avec des paquets légitimes
à destination de 01/08 (pour garder la classe prise en exemple) qui se
retrouveraient droppé en cours de route par un routeur, embêtant non ?

En fait je pensais à "réservé" au sens de "réservé à un usage
particulier" (Cf. RFC3300 : 0/8, 127/8, 169.254/16...) et non "réservé
pour usage futur" (non alloué). La première catégorie ne me semble pas
susceptible d'évoluer.

Quoi que, à bien y réfléchir, je me demande ce qu'il en est du côté
des éditeurs de logiciels. Envoyer un RST ou un host unreachable au
lieu de dropper les paquets bloqués n'est pas bien compliqué et,
puisque tous les filtres IP Unix/Linux savent le faire, cela ne pose
pas de problèmes en terme de sécurité. Donc, pourquoi tous les
firewalls Windows, ou presque, persistent-ils dans cette voie ? :-/

Parce que c'est plus compliqué ? Il faut que le firewall compose et
envoie un paquet arbitraire de réponse avec la bonne adresse IP source,
le bon type, etc.

1) Tu as un enregistrement DNS (ou un DNS dynamique) qui pointe sur
toi.

Je suppose que tu veux dire un enregistrement DNS *connu* ?

Oui, mais il faut être un brin dépensier pour avoir un enregistrement
DNS pointant sur sa machine et ne jamais s'en être servi d'une façon ou
d'une autre ;-)

Je pourrais m'en servir sans que personne d'autre ne le connaisse. Et il
ne m'a pas coûté bien cher. ;-) On peut aussi obtenir un enregistrement
A gratuitement après d'un certain nombre de services de DNS dynamique.

[DROP systématique]

Tout à fait. Cela reste une invisibilité de façade, et clairement pas
la défense suprème qui est l'argument de vente de cette méthode.

Moi, ça me fait penser à la si décriée "sécurité par l'obscurité".

Bonjour,

Pascal Hambourg a wroté :

[ pour bloquer il faut DROPer]

Y a-t-il une personne sensée et informée qui souscrive à ce "précepte" ?

Je dois être un insensé, mais cette question m'interpelle :) .
Avec IPtables je me contente de faire des choses simples et efficaces :
j'applique la politique qui DROPe (presque) tout sur l'interface
externe, de sorte que je n'ai pas à me préoccuper d'éventuels accès sur
les serveurs qui répondent en interne, ni des flood ping, ni... ni... .

Comme en revanche je veux prêcher au monde entier ébahi ma sainte parole
sur des pages ouaibe (sic), j'autorise tout accès sur le port 80,
derrière lequel je sais alors qu'il me faudra gérer la sécurité
"applicative". Je ne vois pas où est le problème à procéder de la sorte,
au contraire : C'est simple, efficace et ça ne prend pas de place en
mémoire.

AMA avoir en même des ports ouverts avec des services en écoute et des
ports DROPés n'est pas très cohérent et ne peut qu'attirer la curiosité.
Il me semble que le seul cas où le DROP se justifie est quand *tout* est
DROPé en entrée afin que la machine apparaisse invisible.

Mais même dans le cas où on DROPe tout, la présence de la machine peut
être détectable indirectement. Par exemple, en IP/ADSL, si un traceroute
vers l'adresse cible bloque après un LNS au lieu d'un routeur core, ça
veut dire que la connexion est active sur ce LNS..

Quelle meilleure protection aurais-je en renvoyant des REJECT là ou je
ne renvoie rien du tout ?

Conclusion, sauf si tu es un utilisateur vraiment lambda, ou que tu
n'as pas le choix, il est préférable de répondre aux requêtes.

Et en plus c'est plus poli. :-) En posant des limites pour ne pas trop
bouffer son upload sur une connexion à débit asymétrique en cas de flood
ou polluer des innocents en cas de spoofing.

Soit, j'admets dans ce cas que ma machine soit impolie, mais à un
certain niveau de compétences (en-dessous du vôtre, je vous le concède
volontiers), ne vaut-il pas mieux tout DROPer en dehors des ports
utiles, plutôt que de se lancer dans des paramétrages fins et difficiles
pour résister aux floods ou ne pas s'exposer au spoofing et risquer
d'avoir une config' bancale, juste pour que la machine réponde "poliment" ?

Merci,

--
Guillaume

[Modération]
Habituellement un article en anglais serait refusé.
Mais ici il s'agit d'une réponse à des nuances sur des
termes anglais qu'on trouve dans les RFC.
Il est donc naturel que ces nuances ne soient pas
traduites, la lecture des RFC nécessitent
la connaissance de la langue originale.

Eric Razny. Co-modérateur de fcs
[fin de modération]

Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:

Par contre dans RFC 1818 "Requirements for IPv4 routers", les
paragraphes 4.3.3.1 et 5.2.7.1 disent "MUST".

La RFC 2119 explique le poids à donner aux MUST, MAY et autres dans les
RFCs :

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.

2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.

5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)

HTH


--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.