Récemment (mais c'est aussi une question récurrente), nous avons vu 3 discussions intéressantes sur le piratage et la sécurité:

Comment gérer un serveur compromis? .
Trouver comment un serveur piraté a été piraté
Question sur les autorisations de fichiers

Le dernier n'est pas directement lié, mais il souligne à quel point il est facile de gâcher l'administration d'un serveur Web.

Comme il y a plusieurs choses qui peuvent être faites, avant que quelque chose ne se produise, j'aimerais avoir vos suggestions en termes de bonnes pratiques pour limiter les effets secondaires d'une attaque et comment réagir dans le cas le plus triste.

Il ne s'agit pas seulement de sécuriser le serveur et le code mais aussi d'auditer, de journaliser et de contre-mesures.

Avez-vous une liste de bonnes pratiques ou préférez-vous vous fier à des logiciels ou à des experts qui analysent en permanence vos serveurs Web (ou rien du tout)?

Si oui, pouvez-vous partager votre liste et vos idées / opinions?

MISE À JOUR

J'ai reçu plusieurs bons et intéressants retours.

Je voudrais avoir une liste simple, ce qui peut être pratique pour les administrateurs de la sécurité informatique mais aussi pour les maîtres du factotum web .

Même si tout le monde a donné de bonnes réponses, je préfère en ce moment celle de Robert car elle est la plus simple, claire et concise et celle de sysadmin1138 car elle est la plus complète et la plus précise.

Mais personne ne considère le point de vue et la perception des utilisateurs, je pense que c'est le premier à prendre en compte.

Ce que l'utilisateur pensera quand visitera mon site piraté, bien plus si vous possédez des données sensibles à leur sujet. Il ne s'agit pas seulement de savoir où stocker les données, mais aussi de calmer les utilisateurs en colère.

Qu'en est-il des données, des médias, des autorités et des concurrents?

Il y a deux grands domaines sur lesquels se concentrer:

1. Rendre difficile d'entrer.
2. Créer des politiques et des procédures pour gérer calmement et efficacement l'événement d'une personne dépassant le point 1.

Rendre difficile d'entrer

Il s'agit d'un sujet très complexe, qui se concentre en grande partie sur le fait de s'assurer que vous disposez de suffisamment d'informations pour comprendre que le WTF s'est produit après coup. Les puces abstraites pour plus de simplicité:

• Conserver les journaux (voir également, Gestion des événements d'informations de sécurité)
  • Toute tentative d'autorisation, réussie ou échouée, de préférence avec les informations source intactes.
  • Journaux d'accès au pare-feu (il peut être nécessaire d'inclure des pare-feu par serveur, le cas échéant).
  • Journaux d'accès au serveur Web
  • Journaux d'authentification du serveur de base de données
  • Journaux d'utilisation spécifiques à l'application
  • Si possible, le SIEM peut lancer des alertes sur les modèles suspects.
• Appliquer des contrôles d'accès appropriés
  • Assurez-vous que les droits sont définis correctement partout et évitez les «droits paresseux» («oh, donnez simplement à tout le monde la lecture») dans la mesure du possible.
  • Des audits périodiques des listes de contrôle d'accès pour s'assurer que les procédures sont réellement suivies et les étapes de dépannage temporaires («donnez à tout le monde la lecture, voyez si cela fonctionne alors») ont été correctement supprimés une fois le dépannage terminé.
  • Toutes les règles d'intercommunication du pare-feu doivent être justifiées et auditées périodiquement.
  • Les contrôles d'accès au serveur Web doivent également être audités, à la fois les listes de contrôle d'accès du serveur Web et du système de fichiers.
• Appliquer la gestion du changement
  • Toute modification de l'environnement de sécurité doit faire l'objet d'un suivi centralisé et être examinée par plusieurs personnes.
  • Les correctifs doivent être inclus dans ce processus.
  • Le fait d'avoir un build de système d'exploitation commun (modèle) simplifiera l'environnement et facilitera le suivi et l'application des modifications.
• Désactivez les comptes d'invité.
• Assurez-vous que tous les mots de passe ne sont pas définis par défaut.
  • Les applications standard peuvent configurer les utilisateurs avec des mots de passe prédéfinis. Changez-les.
  • De nombreux appareils informatiques sont livrés avec des paires utilisateur / mot de passe très connues. Changez-les, même si vous ne vous connectez à ce truc qu'une seule fois par an.
• Pratiquez le moindre privilège. Donnez aux utilisateurs l'accès dont ils ont réellement besoin.
  • Pour les utilisateurs Admin, une configuration à deux comptes est judicieuse. Un compte régulier utilisé pour le courrier électronique et d'autres tâches de bureau, et un second pour le travail privé élevé. Les machines virtuelles facilitent la vie avec.
  • N'encouragez PAS l'utilisation régulière des comptes administrateur / root génériques, il est difficile de savoir qui faisait quoi et quand.

Créer des politiques et des procédures pour gérer calmement et efficacement l'événement d'une personne entrant

Une politique d'événement de sécurité est indispensable pour toutes les organisations. Cela réduit considérablement la phase de réponse «courir avec la tête coupée», car les gens ont tendance à devenir irrationnels face à de tels événements. Les intrusions sont de grandes affaires effrayantes. La honte de subir une intrusion peut entraîner une réaction incorrecte des administrateurs système de niveau supérieur.

Tous les niveaux de l'organisation doivent être conscients des politiques. Plus l'incident est important, plus la haute direction est susceptible de s'impliquer d'une manière ou d'une autre, et avoir des procédures définies pour gérer les choses aidera grandement à repousser "l'aide" d'en haut. Il offre également un niveau de couverture pour les techniciens directement impliqués dans la réponse aux incidents, sous la forme de procédures permettant aux cadres intermédiaires d'interagir avec le reste de l'organisation.

Idéalement, votre stratégie de récupération après sinistre a déjà défini la durée pendant laquelle certains services peuvent être indisponibles avant que la stratégie de reprise après sinistre n'intervienne. Cela facilitera la réponse aux incidents, car ces types d'événements sont des catastrophes. Si l'événement est d'un type où la fenêtre de récupération ne sera PAS remplie (exemple: un site DR de sauvegarde à chaud obtient un flux en temps réel de données modifiées et les intrus ont supprimé un tas de données qui ont été répliquées sur le site DR avant qu'elles ne le soient) Par conséquent, des procédures de récupération à froid devront être utilisées), puis la haute direction devra s'impliquer pour les discussions sur l'évaluation des risques.

Certaines composantes de tout plan de réponse aux incidents:

• Identifiez les systèmes compromis et les données exposées.
• Déterminez très tôt si des preuves juridiques devront ou non être conservées pour d'éventuelles poursuites.
  • Si des preuves doivent être conservées , ne touchez à rien de ce système, sauf si cela est absolument nécessaire . Ne vous y connectez pas. Ne tamisez pas les fichiers journaux. Faire. Ne pas. Toucher.
  • Si des preuves doivent être conservées, les systèmes compromis doivent être laissés en ligne mais déconnectés jusqu'à ce qu'un expert en criminalistique informatique certifié puisse disséquer le système d'une manière compatible avec les règles de traitement des preuves.
    • La mise hors tension d'un système compromis peut entacher les données.
    • Si votre système de stockage le permet (périphérique SAN discret), prenez un instantané des LUN affectés avant la déconnexion et marquez-les en lecture seule.
  • Les règles de traitement des preuves sont complexes et tellement faciles à bousiller. Ne le faites que si vous avez reçu une formation à leur sujet. La plupart des administrateurs système généraux n'ont PAS ce type de formation.
  • Si des preuves sont conservées, traitez la perte de service comme une catastrophe liée à une perte matérielle et démarrez les procédures de récupération avec du nouveau matériel.
• Des règles préétablies pour quels types de catastrophes nécessitent quels types d'avis. Les lois et réglementations varient selon la localité.
  • Les règles relatives à «l'exposition» et au «compromis éprouvé» varient.
  • Les règles de notification exigeront que le service des communications s'implique.
  • Si l'avis requis est suffisamment important, une gestion de haut niveau devra être impliquée.
• À l'aide des données DR, déterminez combien de temps «WTF vient de se produire» peut être dépensé avant de remettre le service en ligne devient une priorité plus élevée.
  • Les délais de récupération des services peuvent nécessiter de déterminer ce qui s'est avéré être subordonné. Si tel est le cas, prenez une image du lecteur de l'appareil affecté pour la dissection après la restauration des services (ce n'est pas une copie de preuve, c'est pour les techniciens de faire de l'ingénierie inverse).
  • Planifiez vos tâches de récupération de service pour inclure une reconstruction complète du système affecté, et pas seulement pour nettoyer le gâchis.
  • Dans certains cas, les délais de récupération du service sont suffisamment courts pour que des images de disque soient prises immédiatement après l'identification d'un compromis et qu'aucune preuve légale ne soit conservée. Une fois le service reconstruit, le travail pour comprendre ce qui s'est passé peut commencer.
• Passez en revue les fichiers journaux pour savoir comment l'attaquant est entré et ce qu'il a pu faire une fois.
• Passez en revue les fichiers modifiés pour savoir comment ils sont entrés et ce qu'ils ont fait une fois qu'ils sont entrés.
• Passez en revue les journaux de pare-feu pour savoir d'où ils viennent, où ils ont pu envoyer des données et combien de données ont pu être envoyées.

Avoir des politiques et des procédures en place avant un compromis, et bien connu des personnes qui les mettront en œuvre en cas de compromis, est quelque chose qui doit être fait. Il fournit à chacun un cadre de réponse à un moment où les gens ne penseront pas correctement. La haute direction peut tonner et exploser au sujet des poursuites et des accusations criminelles, mais en réalité, le traitement d' une affaire est un processus coûteux et le fait de savoir que cela peut aider à atténuer la fureur.

Je note également que ces types d'événements doivent être pris en compte dans le plan global de réponse aux catastrophes. Un compromis sera très susceptible de déclencher la politique de réponse «matériel perdu» et également de déclencher la réponse «perte de données». La connaissance de vos délais de récupération de service permet de définir l'attente pendant combien de temps l'équipe de réponse de sécurité peut avoir à verser sur le système compromis réel (si elle ne conserve pas de preuves juridiques) avant qu'il ne soit nécessaire dans la récupération de service.

Comment les procédures d'assistance appropriées peuvent aider

Nous devons examiner comment les clients sont traités ici (cela s'applique aux clients internes et externes qui contactent un service d'assistance).

Tout d'abord, la communication est importante ; les utilisateurs seront fâchés de la perturbation des activités et peuvent également être préoccupés par l'étendue / les conséquences de toute violation d'informations qui pourrait avoir eu lieu dans le cadre d'une intrusion. Garder ces personnes informées aidera à gérer leur colère et leurs inquiétudes, à la fois du point de vue que le partage des connaissances est bon, et du point de vue peut-être un peu moins évident qu'une chose qu'ils auront besoin d'entendre est que vous contrôlez situation.

Le helpdesk et la gestion informatique doivent agir comme un «parapluie» à ce stade, protégeant les personnes effectuant le travail pour déterminer l'étendue de l'intrusion et restaurer les services d'innombrables demandes de renseignements qui perturbent ce travail.

1. Essayez de publier des mises à jour réalistes pour les clients et travaillez avec eux pour déterminer l'urgence de remettre un service en ligne. Il est important d'être conscient des besoins des clients, mais en même temps, ne leur permettez pas de vous dicter un horaire impraticable.
2. Assurez-vous que votre équipe d'assistance sait quelles informations peuvent et ne peuvent pas être divulguées, et qu'elles ne doivent pas encourager les rumeurs et les spéculations (et ne doivent absolument pas discuter de tout ce qui peut nuire à toute action en justice que votre organisation pourrait entreprendre ou faire face).
3. Une chose positive que le helpdesk devrait faire est d'enregistrer tous les appels relatifs à l'intrusion - cela peut aider à mesurer la perturbation causée à la fois par l'intrusion elle-même et les processus qui ont suivi pour y faire face. Mettre à la fois un temps et un coût financier sur l'intrusion et l'atténuation peut être très utile à la fois pour affiner les stratégies futures, et pourrait évidemment s'avérer utile avec toute action en justice. L'enregistrement des incidents et des problèmes ITIL peut aider ici - l'intrusion elle-même et l'atténuation peuvent être enregistrées comme des problèmes distincts, et chaque appelant est suivi comme un incident d'un ou des deux problèmes.

Comment les normes de déploiement peuvent aider

Le déploiement vers un modèle défini (ou au moins une liste de contrôle) est également utile, tout en pratiquant le contrôle / la gestion des modifications sur les personnalisations / mises à niveau de votre modèle de déploiement. Vous pouvez avoir plusieurs modèles pour tenir compte des serveurs effectuant des tâches différentes (par exemple un modèle de serveur de messagerie, un modèle de serveur Web, etc.).

Un modèle devrait fonctionner à la fois pour le système d'exploitation et les applications, et inclure non seulement la sécurité mais tous les paramètres que vous utilisez, et devrait idéalement être scripté (par exemple un modèle) plutôt qu'appliqué manuellement (par exemple une liste de contrôle) pour éliminer autant que possible les erreurs humaines.

Cela aide de plusieurs façons:

• Vous permet de restaurer / reconstruire plus rapidement en cas d'intrusion (notez que vous ne devez pas déployer à partir de ce modèle «tel quel » car vous savez qu'il est vulnérable, mais il vous permet de revenir à votre «dernière bonne configuration connue»). " qui doit subir un renforcement supplémentaire avant le déploiement en direct ... et n'oubliez pas de mettre à jour votre modèle de déploiement une fois que vous êtes sûr qu'il est correctement verrouillé non plus)
• Vous donne une "ligne de base" pour comparer un serveur piraté à
• Réduit les erreurs inutiles qui pourraient conduire à une intrusion en premier lieu
• Aide à la gestion des modifications et des correctifs car lorsqu'il devient évident que vous avez besoin d'un correctif / d'une mise à niveau ou d'un changement de procédure pour la sécurité (ou pour toute autre raison), il est plus facile de voir quels systèmes ont besoin du changement, il est plus facile d'écrire des tests pour voir si le changement est appliqué correctement, etc.).
• Si tout est aussi cohérent que possible et raisonnable, cela aide à faire ressortir les événements inhabituels et suspects.

Pour la plupart de nos serveurs, nous utilisons des pare-feu hôtes et réseau, des logiciels anti-virus / spywares, des ID réseau et des ID hôte pour la majorité de notre prévention. Ceci, ainsi que toutes les directives générales telles que les privilèges minimums, les programmes non essentiels désinstallés, les mises à jour, etc. À partir de là, nous utilisons des produits tels que Nagios, Cacti et une solution SIEM pour diverses doublures de base et des notifications lorsque des événements se produisent. Notre HIDS (OSSEC) fait également beaucoup de journalisation de type SIEM, ce qui est bien. Nous essayons fondamentalement de bloquer les choses autant que possible, mais nous nous connectons ensuite de manière centrale, donc si quelque chose se produit, nous pouvons l'analyser et le corréler.

Ce que vous voulez vraiment peut se diviser en 3 domaines de base:

1. Configuration système standard
2. Surveillance du système / des applications
3. Réponse aux incidents

Si vous avez du personnel d'information (assurance | sécurité) disponible, vous devez absolument leur parler. Bien que la réponse aux incidents soit souvent du seul ressort dudit bureau, le reste devrait être un effort de développement conjoint entre toutes les parties concernées.

Au risque d'auto-proxénétisme, cette réponse à une question connexe devrait indexer de nombreuses ressources utiles pour vous: Conseils pour sécuriser un serveur LAMP.

Idéalement, vous devriez avoir le plus petit nombre de systèmes d'exploitation pris en charge et les créer chacun à l'aide d'une image de base. Vous ne devez dévier de la base que pour fournir les services fournis par le serveur. Les écarts doivent être documentés, ou peuvent être nécessaires si vous devez satisfaire aux normes PCI / HIPAA / etc. ou d'autres conformités. L'utilisation de systèmes de gestion de déploiement et de configuration peut être très utile à cet égard. Les détails dépendront beaucoup de votre système d'exploitation, cordonnier / marionnette / Altiris / DeployStudio / SCCM, etc.

Vous devriez certainement effectuer une sorte de révision régulière du journal. Compte tenu de l'option, un SIEM peut être très utile, mais il présente également l'inconvénient d'être coûteux à la fois en termes de prix d'achat et de coûts de construction. Consultez cette question sur le site IT Security SE pour quelques commentaires sur l'analyse des journaux: Comment gérez-vous l'analyse des journaux? Si c'est encore trop lourd, même des outils courants tels que LogWatch peuvent fournir un bon contexte pour ce qui se passe. La partie importante, cependant, prend juste le temps de regarder les journaux. Cela vous aidera à vous familiariser avec ce qui constitue un comportement normal, afin que vous puissiez reconnaître anormal.

En plus de la révision des journaux, la surveillance de l'état du serveur est également importante. Il est crucial de savoir quand des changements se produisent, qu'ils soient planifiés ou non. L'utilisation d'un outil de surveillance local tel que Tripwire peut alerter l'administrateur des changements. Malheureusement, tout comme les SIEM et les IDS ont l'inconvénient d'être coûteux à régler et / ou à acheter. De plus, sans un bon réglage, vos seuils d'alerte seront si élevés que les bons messages seront perdus dans le bruit et deviendront inutiles.

Une politique de sécurité des informations et de gestion des événements (SIEM) en place contribuera grandement à faciliter votre vie en matière de sécurité.

Je ne suis pas un expert en sécurité, je m'en remets donc principalement à eux; mais commencer par le directeur de Least Privilege rend presque toujours leur travail beaucoup plus facile. Appliquer cela comme un baume de guérison fonctionne bien pour de nombreux aspects de la sécurité: autorisations de fichiers, utilisateurs d'exécution, règles de pare-feu, etc. KISS ne fait jamais de mal non plus.

La plupart des solutions mentionnées ici s'appliquent au niveau de l'hôte et du réseau, mais nous oublions souvent les applications Web non sécurisées. Les applications Web sont le trou de sécurité le plus souvent négligé. Par le biais d'une application Web, un attaquant peut accéder à votre base de données ou à votre hôte. Aucun pare-feu, IDS, pare-feu ne peut vous protéger contre ceux-ci. OWASP maintient une liste des 10 vulnérabilités les plus critiques et propose des correctifs pour celles-ci.

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide