Eviter les temps morts après le DOS et le changement d'adresse IP
J'ai une petite entreprise qui conçoit, programme et maintient des sites Web. J'héberge mes sites Web sur un plan d'hébergement partagé (cpanel). Il y a deux jours, j'ai reçu un e-mail l'informant qu'il y avait eu une attaque par le DOS et que le fournisseur avait modifié l'adresse IP. J'ai ensuite dû changer l'adresse IP du serveur de noms et attendre la propagation du DNS. Cela a pris presque deux jours ouvrables au cours desquels mes clients n'avaient pas accès à leurs courriels ni à leur site Web. En outre, le temps d'arrêt affectera les sites Web à court terme (classement, etc.). Je ne pouvais donc que rester assis à ne rien faire pendant que mes clients m'appelaient furieusement (je ne les blâme pas).
Donc mes questions sont:
- Est-ce la bonne solution pour la société d'hébergement de modifier l'IP lorsqu'une attaque DOS se produit? Je suis passé d'une entreprise qui coupait les serveurs à des occasions similaires (!)
- Que puis-je faire pour me défendre de ce qui se passe à nouveau. Bien que petite entreprise, j’avais jusqu’à présent une excellente réputation. Je ne veux pas que cela se reproduise.
Déplacer vers un serveur dédié ne changera rien si leur stratégie est de changer d'adresse IP lors d'une attaque par le DOS. Une autre option que j’ai trouvée est le DNS de basculement, qui requiert la mise en miroir de tous les sites sur un deuxième serveur (coût double) et je n’ai pas lu les meilleures choses à propos de cette pratique. Y a-t-il d'autres alternatives?
S'il s'agit d'une petite/moyenne entreprise avec une bande passante limitée (<1-10 Gbps), la modification du pool d'adresses IP est la meilleure solution, plus économique et plus rapide.
Seuls les opérateurs, les fournisseurs de CDN ou les grandes entreprises peuvent atténuer les attaques par déni de service avec d'autres solutions (et la bande passante ne leur pose aucun problème).
En ce qui concerne la propagation DNS, les registres whois sont ceux qui prennent beaucoup de temps, les entrées DNS peuvent être rapidement modifiées et propagées aussi rapidement que leur TTL expire.
Voici un exemple de TTL cache:
redstar@nvidiastar:~$ Dig +nocmd +noall +answer www.google.com
www.google.com. 72 IN A 216.58.201.132
redstar@nvidiastar:~$ Dig +nocmd +noall +answer www.google.com @216.239.32.10
www.google.com. 300 IN A 74.125.206.147
www.google.com. 300 IN A 74.125.206.104
www.google.com. 300 IN A 74.125.206.103
www.google.com. 300 IN A 74.125.206.99
www.google.com. 300 IN A 74.125.206.106
www.google.com. 300 IN A 74.125.206.105
Quand je cherche une résolution DNS, mon FAI DNS me répond une adresse IP avec un TTL de 72 secondes. Pour savoir quel est le TTL, vous devez demander à un serveur DNS ce domaine (216.239.32.10 est l'un d'entre eux). Dans google, les entrées ont une durée de vie de 300 secondes, elles peuvent donc modifier leurs adresses IP et le temps de propagation est de 5 minutes au maximum.
L'utilisation d'un serveur DNS de secours sur un autre réseau résoudrait le problème.
Il existe des fournisseurs DNS secondaires gratuits que vous pouvez utiliser. J'utilise Twisted4Life depuis plusieurs années, mais vous pouvez aussi vérifier BuddyNS ou rechercher des "DNS secondaires gratuits" dans n'importe quel moteur de recherche.
Et en parlant de serveurs DNS secondaires gratuits, vous pouvez également utiliser CloudFlare comme serveur DNS libre ainsi qu’un CDN qui met en cache (ou non, vous pouvez désactiver cette fonctionnalité) votre contenu statique.
Est-ce la bonne solution pour la société d'hébergement de modifier l'IP lorsqu'une attaque DOS se produit? Je suis passé d'une entreprise qui fermait les serveurs à des occasions similaires
Je ne vous vois pas gagner d'avantage avec un changement d'adresse IP car 1, un changement d'adresse IP empêche votre site Web d'être prêt jusqu'à l'expiration du nom de domaine TTL, ce qui peut prendre plusieurs jours. et 2, les pirates informatiques sérieux vont scanner chaque adresse IP sur Internet à la recherche de systèmes pouvant devenir des cibles faciles pour des attaques. Arrêter le serveur peut être une meilleure idée, en fonction de l'attaque.
Que puis-je faire pour me défendre de ce qui se passe à nouveau. Bien que petite entreprise, j’avais jusqu’à présent une excellente réputation. Je ne veux pas que cela se reproduise.
Vérifiez vos ressources système et vos sites Web.
Assurez-vous que le logiciel du serveur Web fonctionne efficacement
Assurez-vous que votre serveur Web ne possède pas de paramètre de délai d'expiration trop élevé, et assurez-vous que vos scripts s'exécutant sur votre serveur ne sont pas à la traîne (par exemple, n'exécutez pas de script contenant une boucle infinie).
Dans Apache, seul un nombre x d'emplacements disponibles est disponible pour traiter les scripts. Une fois que tous ces emplacements sont utilisés, les connexions ultérieures à Apache devront attendre la libération d'un emplacement. Les emplacements sont libérés au moment de l'expiration du délai ou du dernier octet du résultat (page HTML ou image ou code brut, etc.).
La valeur de x est importante. Si la valeur est trop basse, les invités risquent d'attendre plus longtemps que d'habitude qu'une page soit servie, en particulier si un invité télécharge un fichier de plusieurs gigaoctets. N'oubliez pas que chaque ressource demandée utilise un emplacement de serveur. Pour une page typique, cela signifie que 3 emplacements peuvent être utilisés simultanément pour environ 200 millisecondes chacun. Un emplacement pour le HTML, un pour l'icône de site Web (favicon.ico?) Et un pour une image de la page.
Si x est défini trop haut, l’impression de DOS risque de se produire encore plus, car une mémoire de permutation (mémoire de l’espace de stockage le plus lent: le disque dur) sera nécessaire car le système manquera de RAM réelle alors que essayer de gérer les demandes.
Maximiser les ports
Un serveur ne peut avoir qu'un nombre limité de ports ouverts simultanément. Certains serveurs prêts à l'emploi sont configurés pour ouvrir un nombre très limité de ports. Augmentez autant que possible la portée sans chevaucher les ports utilisés par d'autres démons du système. J'ai un serveur avec WHM/cpanel et je règle la plage de ports sur 5000-65535.
le plus important
Faites attention à vos scripts et surveillez votre timimg.
Lorsque vous créez une page, allez sur webpagetest.org et exécutez l'URL à travers elle. Choisissez le paramètre de connexion native sous vitesse de connexion et si le délai jusqu'au premier octet est supérieur à 400 ms depuis le serveur le plus éloigné de votre serveur et que le périphérique distant n'est pas mobile, vous savez que vous avez un problème.
En outre, comme je l’ai dit, vérifiez tous vos scripts sur votre serveur. Assurez-vous qu'aucun d'entre eux n'exécute une boucle sans fin ou d'autres ressources. Vérifiez également que les fichiers de remplacement du serveur (tels que .htaccess si vous utilisez Apache) sont malveillants.
Tout sécurisé
Enfin, sécurisez tout. Fermez les ports (en y déposant des demandes) que le monde ne mérite pas. J'ai fermé le port MySQL (juste au cas où quelqu'un se demanderait pourquoi leur visage est devenu rouge en essayant sans cesse d'accéder à mon serveur MySQL).
Le seul port auquel tous les utilisateurs devraient avoir accès est le port 80, le port du serveur Web.
Ouvrez uniquement les autres ports si nécessaire. Et fermez les ports 22 et 23, car les pirates les connaissent comme les ports d’accès standard du serveur principal. En fait, si vous avez besoin d'un accès Shell, utilisez un autre port.