Que doit savoir chaque administrateur système avant d'administrer un serveur public?

Semblable à cette question sur Stack Overflow, que devrait savoir un administrateur système habitué à des situations privées de type intranet avant d'être l'administrateur d'un site public?

Il peut s'agir de choses liées à la sécurité, telles que «ne laissez pas telnetouvert» ou de choses pratiques, comme la façon d'équilibrer la charge pour un site à fort trafic.

• Chaque application, chaque binaire, chaque package qui existe sur le serveur est un handicap. Abonnez-vous au principe du «moindre bit»; s'il n'est pas installé, il ne peut pas être compromis.

• Implémentez la détection d'intrusion, comme Tripwire ou similaire, et scannez fréquemment.

• Investissez dans un pare-feu matériel et ouvrez uniquement les ports dont vous avez besoin pour votre application. Ne laissez pas vos ports d'administration (ssh, rdp, etc.) être visibles publiquement; les restreindre aux adresses IP de gestion approuvées.

• Ayez des sauvegardes de vos configurations de pare-feu / commutateur / routeur au moment de la mise en production. Si l'un de ces appareils est compromis, il est beaucoup plus rapide de récupérer en essuyant le cerveau de l'appareil et en rechargeant la configuration que d'effectuer un audit ligne par ligne de la configuration lorsque l'horloge tourne.

• Nappez fréquemment votre environnement de l'extérieur pour vous assurer qu'aucun nouveau port ne s'est ouvert.

• Ne faites jamais confiance à Internet; assurez-vous que tout ce que vous servez sur le net est un coffre-fort tel qu'il peut être (effectuez la validation et la désinfection des entrées côté serveur pour arrêter les attaques par injection SQL, par exemple).

• Restez au top de vos patchs.

• Si vous êtes compromis, reconstruisez à partir de zéro avec des supports fraîchement téléchargés. Vous ne pouvez plus faire confiance à la sécurité de vos sauvegardes et vous n'avez pas non plus été compromis (bien que tripwire puisse vous y aider) pour autre chose que des données inertes non exécutables.

Un outil que j'ai trouvé pratique pour renforcer le réseau est Nessus

Fondamentalement, vous l'avez installé sur un serveur externe et il essaie d' attaquer votre réseau avec une multitude de failles connues. Vous pouvez le définir pour le mode sans échec (où aucune des attaques ne devrait planter votre serveur), ou si vous êtes assez confiant que vous avez tout corrigé, ou pouvez vous permettre de redémarrer vos serveurs si nécessaire, pour un mode non sécurisé .

Ensuite, il fournira un rapport gradué très complet pour chaque machine, il pourra voir quelles vulnérabilités / faiblesses il trouve et les évaluer en fonction de leur gravité - et même recommander des mesures à prendre pour résoudre les problèmes.

Ils doivent savoir comment fonctionne leur système de sauvegarde et de reprise après sinistre et comment ils vont récupérer le système quand / s'il est compromis.

C'est un peu contraire, mais en termes de sécurité, je ne fais pas de différence entre un serveur interne et un serveur externe. Tôt ou tard, quelqu'un fera une erreur dans un pare-feu, la direction insistera pour qu'un serveur soit exposé à cause d'un client important, Betty en comptabilité obtiendra en quelque sorte un client VPN sur sa machine domestique infectée, etc.

Cela dit, les calques sont vos amis et vous devez les mettre sur liste noire par défaut.

Couches - vous devez avoir plusieurs couches de sécurité. Par exemple, un pare-feu matériel et un pare-feu logiciel. Celles-ci ont théoriquement le même objectif, mais le fait d'avoir plusieurs couches protège contre les erreurs et atténue les conséquences de l'exploitation d'une seule couche.

Un autre aspect de la superposition est le "homeycombing", qui est essentiellement de multiples DMZ. À un moment donné, vous devez avoir un certain niveau de confiance entre vos machines et les personnes accédant à vos comptes. Si vous pouvez restreindre ces points d'interaction, vous pouvez contrôler étroitement le type de trafic auquel vous faites confiance à tout moment. Par exemple, si vous séparez vos serveurs d'interface / application de vos serveurs de base de données, vous réduisez le niveau de confiance. Si vos serveurs d'applications sont compromis, ces attaquants prennent un pied minimal dans votre infrastructure (c'est-à-dire que pour continuer leur attaque et tenter d'exploiter vos autres serveurs, ils n'ont que les points de confiance établis à utiliser).

En ce qui concerne la liste noire par défaut, vous devez essentiellement tout fermer et exiger (même si ce n'est que de vous-même) une justification pour chaque port que vous ouvrez, le nom d'utilisateur auquel vous autorisez l'accès, l'application que vous installez, etc.

Sur les systèmes avec TOUTES interfaces publiques, assurez-vous que vos utilisateurs ont des mots de passe sécurisés en mettant en œuvre une politique de mot de passe sécurisée et en testant le fichier de mots de passe avec un utilitaire de craquage de mot de passe comme John the Ripper

Vous pouvez encore vous prémunir contre les attaques par devinette par mot de passe par force brute en bloquant les adresses IP après plusieurs tentatives infructueuses. Un bon outil pour cela (sous Linux) est fail2ban

Votre commutateur peut être piraté et quelqu'un peut altérer les données. Si vous ne possédez pas le commutateur, configurez un vpn, car la restriction d'accès au pare-feu par ip peut ne pas être suffisante.

Ne laissez aucun port ouvert, sauf ceux auxquels vous voulez que les utilisateurs et les pirates accèdent. Scannez vos propres serveurs depuis un autre site chaque mois.

Ne laissez pas le port par défaut de ssh ouvert pour les pirates.