Limitation de la vitesse de concordance (match limit) avec Netfilter/iptables
2 réponses
Annie D.
Bonjour,
J'ai cru comprendre qu'il était souhaitable de limiter la vitesse de
certaines concordances grâce à l'option "-m limit" d'iptables pour,
entre autres :
- la cible LOG
- la cible REJECT
- les requêtes ICMP (ex: echo request) entrantes
- les nouvelles (state NEW) connexions entrantes TCP, UDP ou autres
[ajouter ici d'autres cas auxquels je n'ai pas pensé]
Dans le dernier cas, j'ai une interrogation sur le comportement à
programmer une fois la limite de vitesse de nouvelles connexions
atteintes : REJECT (avec une nouvelle limitation bien sûr, et ensuite
c'est DROP) ou DROP d'office ?
Le critère étant de respecter au maximum les standards tout en limitant
la pollution collatérale.
Merci de vos avis hautement éclairés et argumentés.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
T0t0
"Annie D." wrote in message news:cever4$2p11$
Dans le dernier cas, j'ai une interrogation sur le comportement à programmer une fois la limite de vitesse de nouvelles connexions atteintes : REJECT (avec une nouvelle limitation bien sûr, et ensuite c'est DROP) ou DROP d'office ? Le critère étant de respecter au maximum les standards tout en limitant la pollution collatérale. Merci de vos avis hautement éclairés et argumentés.
Arf, la question n'est pas des plus simple. Disons que je la contournerai en me demandant l'intérêt de la cible DROP si on veut rester en accord avec les RFC. Ca en reviendrait donc à savoir si beaucoup de ressources sont utilisées pour envoyer un TCP reset ou icmp X unreachable par rapport à un drop silencieux. Si vous vous faites flooder, cela peut s'avérer lourd, mais dans le cas d'un simple scan ce n'est peut-être pas nécessaire.
Dans ce cas, il est peut être utile de repousser l'utilisation de drop au maximum pour rester RFC compliant. Mais bon, pourquoi vouloir rester RFC compliant face à un flood ou un scan ? si ce n'est pour les quelques requêtes réelles perdues au milieu... Par ailleurs, l'option --limit-burst peut aussi être intéressante pour conserver les ressources machine tout en ayant un comportement "correct"
En définitive, je pense qu'il peut y avoir une réponse différente pour chaque config et selon les débits. Je vous aide pas beaucoup là :-(
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Annie D." <annie.demur@free.fr> wrote in message
news:cever4$2p11$1@biggoron.nerim.net
Dans le dernier cas, j'ai une interrogation sur le comportement à
programmer une fois la limite de vitesse de nouvelles connexions
atteintes : REJECT (avec une nouvelle limitation bien sûr, et ensuite
c'est DROP) ou DROP d'office ?
Le critère étant de respecter au maximum les standards tout en limitant
la pollution collatérale.
Merci de vos avis hautement éclairés et argumentés.
Arf, la question n'est pas des plus simple.
Disons que je la contournerai en me demandant l'intérêt de la cible DROP
si on veut rester en accord avec les RFC.
Ca en reviendrait donc à savoir si beaucoup de ressources sont utilisées
pour envoyer un TCP reset ou icmp X unreachable par rapport à un drop
silencieux.
Si vous vous faites flooder, cela peut s'avérer lourd, mais dans le cas
d'un simple scan ce n'est peut-être pas nécessaire.
Dans ce cas, il est peut être utile de repousser l'utilisation de drop
au maximum pour rester RFC compliant. Mais bon, pourquoi vouloir
rester RFC compliant face à un flood ou un scan ? si ce n'est pour les
quelques requêtes réelles perdues au milieu...
Par ailleurs, l'option --limit-burst peut aussi être intéressante
pour conserver les ressources machine tout en ayant un comportement
"correct"
En définitive, je pense qu'il peut y avoir une réponse différente pour
chaque config et selon les débits.
Je vous aide pas beaucoup là :-(
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Dans le dernier cas, j'ai une interrogation sur le comportement à programmer une fois la limite de vitesse de nouvelles connexions atteintes : REJECT (avec une nouvelle limitation bien sûr, et ensuite c'est DROP) ou DROP d'office ? Le critère étant de respecter au maximum les standards tout en limitant la pollution collatérale. Merci de vos avis hautement éclairés et argumentés.
Arf, la question n'est pas des plus simple. Disons que je la contournerai en me demandant l'intérêt de la cible DROP si on veut rester en accord avec les RFC. Ca en reviendrait donc à savoir si beaucoup de ressources sont utilisées pour envoyer un TCP reset ou icmp X unreachable par rapport à un drop silencieux. Si vous vous faites flooder, cela peut s'avérer lourd, mais dans le cas d'un simple scan ce n'est peut-être pas nécessaire.
Dans ce cas, il est peut être utile de repousser l'utilisation de drop au maximum pour rester RFC compliant. Mais bon, pourquoi vouloir rester RFC compliant face à un flood ou un scan ? si ce n'est pour les quelques requêtes réelles perdues au milieu... Par ailleurs, l'option --limit-burst peut aussi être intéressante pour conserver les ressources machine tout en ayant un comportement "correct"
En définitive, je pense qu'il peut y avoir une réponse différente pour chaque config et selon les débits. Je vous aide pas beaucoup là :-(
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
RAKOTOMALALAL Renaud
J'ai cru comprendre qu'il était souhaitable de limiter la vitesse de certaines concordances grâce à l'option "-m limit" d'iptables pour, entre autres : [../..]
Le critère étant de respecter au maximum les standards tout en limitant la pollution collatérale. Merci de vos avis hautement éclairés et argumentés.
Je t'invite à poster ta question sur fr.comp.securite qui sera plus adapté au sujet, et te permettra d'obtenir plus de reponse.
Cordialement, -- Renaud RAKOTOMALALA
J'ai cru comprendre qu'il était souhaitable de limiter la vitesse de
certaines concordances grâce à l'option "-m limit" d'iptables pour,
entre autres :
[../..]
Le critère étant de respecter au maximum les standards tout en limitant
la pollution collatérale.
Merci de vos avis hautement éclairés et argumentés.
Je t'invite à poster ta question sur fr.comp.securite qui sera plus
adapté au sujet, et te permettra d'obtenir plus de reponse.
J'ai cru comprendre qu'il était souhaitable de limiter la vitesse de certaines concordances grâce à l'option "-m limit" d'iptables pour, entre autres : [../..]
Le critère étant de respecter au maximum les standards tout en limitant la pollution collatérale. Merci de vos avis hautement éclairés et argumentés.
Je t'invite à poster ta question sur fr.comp.securite qui sera plus adapté au sujet, et te permettra d'obtenir plus de reponse.
