Dois-je limiter les paquets avec iptables?

J'utilise iptables sur Ubuntu Server. C'est un serveur Web sur un VPS.
Je voudrais savoir si je devrais limiter les paquets. Si oui, que dois-je limiter? Et dois-je le faire globalement ou par adresse IP?

Référence
J'ai vu des gens suggérer ceci:

# Limit packet traffic on a TCP or UDP port:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m limit --limit $lim/s --limit-burst $lb -j ACCEPT

# Limit established/related packet traffic:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit $lim/s --limit-burst $lb -j ACCEPT

Ce qui précède, une limite de taux globale ne semble pas très utile, du moins pour les cas que je peux imaginer. Y a-t-il un cas où je devrais limiter le taux globalement?
Je pense qu'une limite de débit par IP est généralement meilleure:

# Add the IP to the list:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m recent --set --name RATELIMITED
# Drop if exceeded limit:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m recent --update --seconds $sec --hitcount $hc --rttl --name RATELIMITED -j DROP
# Accept if inside limit:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -j ACCEPT

Question supplémentaire: les adresses IP distantes peuvent être usurpées. Comment les limiter correctement?
Ajout d'une autre question pour cela:
/server/340258/how-to-rate-limit-spoofed-ips-with-iptables

L'objectif
que j'essaie d'atténuer le risque de certaines attaques D / DoS et d'abus général.

Connexes
Comment puis - je limitons les connexions SSH avec iptables?

PS : Je viens d'ouvrir une question connexe juste pour ICMP et elle inclut la limitation de débit pour ce protocole: iptables | Types d'ICMP: lesquels sont (potentiellement) nuisibles?

Une limite de débit n'est pas une prévention mais plutôt une invitation au DoS - en particulier dans la saveur présentée ci-dessus où les paquets vont être abandonnés si un certain débit de paquets non authentifiés sans informations d'état a été dépassé. Étant donné que tout le monde peut forger des paquets (y compris les adresses IP source) à cet état de connexion sans plus d'effort, un nouveau vecteur d'attaque DoS tirant parti de votre facilité de limite de débit va apparaître.

Une limite de taux n'a généralement de sens que si vous avez

1. soit une limite de connexion dure ou douce prévisible dans votre configuration
2. définir la limite de débit pour le trafic général en dessous de cette limite afin de pouvoir établir des connexions pour le trafic prioritaire ou administratif quelle que soit la charge

Alors que 1. est souvent assez difficile à déterminer pour déranger, 2. ne fonctionnera évidemment que si vous êtes en mesure de différencier de manière fiable le trafic "prioritaire ou administratif" du reste lors de la configuration de la connexion - par exemple s'il passe par une interface réseau différente.

Dans d'autres cas, il serait préférable de réduire la résilience de votre système plutôt que d'y ajouter.

Le problème avec -m limit est la limitation de tous les paquets TCP quelles que soient les adresses IP source. Donc, si vous avez une faible limitation pour les paquets de synchronisation comme

-A INPUT -p tcp  --syn -m limit --limit 30/s --limit-burst 30 -j ACCEPT
-A INPUT -p tcp --syn -j DROP

un seul client avec la ligne de commande hping peut arrêter votre serveur en envoyant autant de paquets tcp avec l'indicateur SYN car la règle de limite correspondra et il abandonnera de nombreux paquets quelles que soient les adresses IP sources. la limite ne fait pas de différence entre un bon trafic et un mauvais trafic. Cela réduira également le bon trafic entrant.

hping pourrait être quelque chose comme:

hping thetargetedhostip -p 80 -S -c 1000 -i u20000

Il est préférable d'utiliser hashlimit pour limiter les connexions TCP entrantes par adresse IP . La règle suivante ne correspondra que si 30 paquets par seconde sont reçus, ce qui réduit le nombre de paquets autorisés par IP à 15 paquets par seconde.

-A INPUT -p tcp --syn -m hashlimit --hashlimit 15/s --hashlimit-burst 30 --hashlimit-mode srcip --hashlimit-srcmask 32 --hashlimit-name synattack -j ACCEPT 
-A INPUT -p tcp --syn -j DROP

En fait, je suis CONVAINCU que de nombreux serveurs qui sont arrêtés aujourd'hui ne le sont pas par manque de ressources lors d'une attaque, mais à cause du module de limitation supprimant tout le trafic entrant.

Je limite généralement les règles de limitation de débit aux serveurs que j'attends d'avoir:

• faible trafic attendu
• services d'authentification

Par exemple, la page de connexion d'un panneau de contrôle d'hébergement, POP3, IMAP, SSH, etc. Je laisse généralement les services HTTP ouverts et ne les bloque qu'en cas de problème.

Vous ne voulez pas laisser tomber le bon trafic Web. Un lien sur slashdot pourrait vous envoyer des tonnes de trafic et avec les règles globales, vous pourriez ne pas réaliser de problème.

En ce qui concerne les adresses IP usurpées, elles ne peuvent pas être bloquées à l'aide de cette méthode et ne sont généralement pas un problème car ces règles se concentrent principalement sur la limitation des connexions TCP établies. Avec une adresse IP frauduleuse, la connexion TCP ne peut jamais être établie.