Le blocage de toutes les connexions en dehors des États-Unis, à l'exception du port 80, entraînera-t-il une charge élevée du serveur?

16

Comme la plupart des serveurs (je suppose), nous avons des gens qui essaient de forcer nos services 24/7. J'ai cpHulk blacklist leurs IP, mais il semble que ce serait mieux s'ils ne sont pas allés aussi loin en premier lieu. Moi et mon hôte sont les seuls qui se connectent au serveur sur des ports autres que 80, donc je voudrais bloquer les connexions de tous les pays en dehors des États-Unis, à l'exception du port 80. J'ai contacté mon hôte pour configurer cela, mais ils étaient hésitants car ils ont dit que cela créerait une charge de serveur exceptionnellement élevée. Il s'agit d'un serveur Xeon 1230 dédié avec 32 Go de RAM exécutant CentOS 6.6 et iptables.

Tout d'abord, une raison de ne pas le faire? Deuxièmement, ce que mon hôte m'a dit est-il correct? Troisièmement, existe-t-il un moyen d'y parvenir sans impact sur les performances?

iptables

— Big Iron
source

12

Il est regrettable que votre contact d'hébergement n'ait pas mentionné "Mais il existe un moyen standard de faire la même chose que vous voulez avec beaucoup moins de maintenance, une meilleure sécurité et une faible charge de serveur appelée Explicit Deny All. Obtenez-moi la liste des adresses IP dont vous avez besoin sur la liste blanche et je vais le configurer pour vous dans 20 minutes. " - C'est ce que je m'attends à entendre de la part de tout administrateur système digne de la chaise dans laquelle ils sont assis.

— corsiKa

il suffit de les bloquer lorsqu'ils abusent ... la maintenance est minimale de cette façon ... avec une table complète, vous devez la tenir à jour

— Skaperen

33

La définition de règles spécifiques pour bloquer chaque plage IP (en répertoriant chaque plage) n'est pas la bonne approche.

Définissez les règles par défaut dans iptables pour supprimer tout le trafic vers vos ports de gestion. Ajoutez ensuite des règles pour n'autoriser l'accès qu'à partir de vos adresses IP de confiance (la vôtre et celle de votre hôte).

Tout bloquer par défaut et autoriser uniquement le trafic approuvé est généralement appelé "refuser explicitement tout" et est considéré comme une meilleure pratique. Dans ce cas, cela permet également d'éviter l'impact sur les performances de votre hôte.

— jlehtinen
source

Pourquoi, si vous le savez, est-ce un refus explicite lorsque vous refusez implicitement tout le monde en n'autorisant explicitement que quelques adresses IP à travers le pare-feu?

— Ben

Il n'y a rien d'implicite là-dedans vraiment ...

— mr-sk

Un accès potentiel à la liste blanche est l'accès à distance. Vous aurez besoin d'un VPN fiable (distinct de ce serveur) et autorisez également sa plage IP.

— Foo Bar

9

Pour ce faire, vous devez ajouter des dizaines de milliers de règles de pare-feu, une pour chaque netblock, où un pays peut avoir entre un et plusieurs milliers de netblocks associés.

Lorsqu'une demande arrive, elle doit être vérifiée par rapport à chaque règle , ce qui prend très peu de temps pour quelques dizaines ou peut-être même quelques centaines de règles, mais avec autant de règles que vous devez utiliser, (1) chaque la demande sera considérablement ralentie et (2) elle utilisera beaucoup de CPU.

La façon de le faire sans impact significatif sur les performances consiste à faire ce que vous faites déjà: bloquer uniquement les adresses spécifiques qui posent problème.

— Michael Hampton
source

Merci pour la réponse, Michael. N'existe-t-il pas un moyen d' autoriser uniquement les adresses IP basées aux États-Unis, ne nécessitant ainsi qu'une seule règle?

— Big Iron

2

@BigIron Bien sûr que non. Il existe également des dizaines de milliers de netblocks aux États-Unis. Vous perdez de toute façon.

— Michael Hampton

1

@SamuelEdwinWard Non, ce n'est pas le cas. Bien qu'ils soient répartis partout, ces listes de blocage ne comptent généralement pas plus de quelques centaines d'entrées.

— Michael Hampton

1

Avez-vous une référence sur l'importance du ralentissement? Une recherche linéaire bien que tous les ensembles de règles semble terriblement inefficace, au moins une recherche binaire signifierait que la recherche dans une table de règles 60 000 ne prendrait que 16 sondes dans la table, et cela pourrait être plus rapide que de laisser le trafic passer vers le serveur Web qui pourrait doivent exécuter les E / S disque pour répondre à la demande. Je n'ai trouvé aucune métrique sur les grands ensembles de règles dans iptables.

— Johnny

1

@Johnny netfilter (iptables) traite ses règles de manière linéaire malheureusement: serverfault.com/questions/334885/…

— Ross Ridge

5

Vous avez besoin d'un outil appelé ipsets

Les ensembles IP sont un cadre à l'intérieur du noyau Linux, qui peut être administré par l'utilitaire ipset. Selon le type, un ensemble IP peut actuellement stocker des adresses IP, des numéros de port (TCP / UDP) ou des adresses IP avec des adresses MAC, ce qui garantit une vitesse fulgurante lors de la mise en correspondance d'une entrée avec un ensemble.

la chose importante à noter ici, c'est que c'est rapide comme l'éclair! En effet, un grand nombre de réseaux IP peuvent être représentés par un seul hachage au lieu de centaines ou de milliers de lignes de règles iptables.

Pour les pays bloquants, voir cet exemple :

— Ricardo
source

1

Ignorer le peu de savoir si le faire de cette façon est une bonne idée, vous pouvez faire ce que vous avez demandé avec le module GeoIP pour iptables.

Après avoir construit et installé le module (et gardé vos listes IP mises à jour mensuellement), vous pouvez faire des choses comme ça pour bloquer des pays individuels:

iptables -I INPUT -m geoip --src-cc CN -j DROP

Ou utilisez --src-cc US -j ACCEPTet ainsi de suite si vous préférez spécifier les pays que vous souhaitez conserver.

— Scott Dudley
source

Ne serait-ce pas un gâchis de performances même si vous utilisez "refuser explicitement tout" et n'autorisez qu'un seul pays?

@ AndréDaniel, j'avoue que je n'ai pas regardé le code GeoIP lui-même, mais en supposant qu'ils utilisent une implémentation non naïve qui est plus intelligente que de comparer séquentiellement un tas de netblocks (par exemple un trie), il n'a pas besoin d'être.

— Scott Dudley

Et si vous parlez d'IPv4 et que vous disposez de 512 Mo de réserve par règle, une implémentation théorique utilisant une table de recherche pourrait faire le travail dans O (1).

— Scott Dudley

1

Si vous souhaitez conserver la possibilité de vous connecter de n'importe où sans maintenir une liste noire / liste blanche de géolocalisation, vous pouvez implémenter le port-knocking . Il arrêterait la plupart des tentatives automatisées tout en vous permettant de vous connecter à partir de n'importe quelle adresse.

Remarque: ne mettez pas le port à frapper à côté du port à ouvrir, sinon une analyse séquentielle du port activera votre règle.

— seren
source

0

Si vous avez un ou deux routeurs compatibles BGP dans votre pile ET avez une sorte d'idée ce que vous faites / travaillez avec quelqu'un qui sait ce que c'est qu'ils font, ou sont peut-être derrière un fournisseur de prévention DDoS assez cool pour aider à la mise en œuvre de cela, il y a une méthode relativement nouvelle pour restreindre le trafic aux régions géographiques appelée blackholing sélectif qui, je pense, vaut le détour.

https://ripe68.ripe.net/presentations/176-RIPE68_JSnijders_DDoS_Damage_Control.pdf

http://mailman.nanog.org/pipermail/nanog/2014-F February/064381.html

http://www.internetsociety.org/deploy360/blog/2014/07/video-selective-blackholing-at-ripe-68/

Comme cette méthode fonctionne sur la manipulation des routes, elle contourne tous les problèmes de charge du serveur.

— Dmitri DB
source