Toute personne qui a formé avec moi pouvez-vous dire que je suis vraiment grand d'être capable de lire votre propre détecte. Alors que nous avons beaucoup de dispositifs de sécurité qui tentent de décrire avec précision ce qu'ils pensent qu'ils voient sur le fil, ils sont programmés par les humains et les humains font des erreurs. Essayez et automatiser le processus et les erreurs deviennent aggravé. Même Cisco a reculé un peu sur leurs prétentions grandioses de ce qu'est un réseau auto défense est en fait capable de faire. Rien ne remplace ayant un analyste compétent examine les résultats.

Bonne aide est difficile à trouver

Bien sûr, le mot-clé dans ce dernier commentaire est habile. J'ai traité avec beaucoup de gens de sécurité de haut niveau qui n'ont jamais vu un décodage d'un paquet IP, sans parler peux vous dire ce qu'est une session IP légitime devrait ressembler. Un des problèmes, c'est quand nous avons besoin de la formation nous avons l'habitude se tourner vers les fournisseurs. Les vendeurs ont tendance à se concentrer sur leur interface graphique jolie, pas ce qui se passe dans les coulisses.

Dans une vie antérieure, j'ai été propriétaire d'un fournisseur de services Internet et ont eu des rapports d'abus très divertissant soumis. Un de mes favoris personnels était une déclaration d'administration qui l'un de mes systèmes a été "l'envoi de paquets ICMP hostiles" à l'un de ses systèmes. Lorsque j'ai examiné mes journaux, j'ai noté que l'un de mes routeurs était en fait en lui envoyant des messages ICMP hôte inaccessible. Ce serait le cas à chaque fois que son hôte sondé le port RPC d'une adresse IP qui n'était pas en usage. Je lui ai répondu et expliqué que si son système serait tout simplement arrêter de sondage pour inexistants systèmes, mon routeur ne s'arrête pour lui dire que l'hôte est hors-ligne.

Un autre admin (à une assez grande, entreprise bien connue, je pourrais ajouter) m'a informé que l'un de mes systèmes a été l'attaquant avec Code Red par e-mail. Si vous vous souvenez Code Red, il n'a attaqué serveurs Web IIS via HTTP. Les "attaques" en question étaient des utilisateurs abonnés à une liste de diffusion. Les gens parlaient de la façon d'écrire de bonnes signatures d'intrusion pour bien attraper Code Red. Si ce n'était pas ironique assez, la charge utile du décodage, il m'a envoyé comme preuve a expliqué que les attaques ne sont que HTTP basé. Si cette torsion n'est pas encore assez pour vous faire rire, il a admis plus tard qu'il était l'un des personnes abonnées à cette liste.

Les choses changent plus elles restent les mêmes

My Monster hébergement hôte du fournisseur (une filiale de l'hôte Bleu) a mis un filtre en place bloquant tout accès à l' institut SANS serveur de messagerie (SysAdmin, Audit, Network, Security Institute, fournit la sécurité informatique de formation), Le Internet Storm Center (journal quotidien des menaces de sécurité Internet) et DShield (un système d'alerte précoce pour les menaces Internet). J'ai contacté le support et ils ont confirmé qu'ils sont de filtrage de ces sites. Je n'ai pas pu savoir pourquoi au-delà "en raison de toute activité suspecte".

Je sais que les gens qui maintiennent les serveurs et SANS Dshield. Ils sont durs les gens de sécurité de base avec un indice sérieux. Quand j'ai signé avec mon fournisseur d'hébergement j'ai été impressionné par le niveau de connaissances de leur personnel de soutien. Dernièrement, toutefois, j'ai trouvé à faire défaut, même dans les bases. Même si je suis laissé à deviner à ce qui a causé l'interdiction, je suis enclin à penser que quelqu'un chez Monster hôte (ou Host éventuellement Bleu) a vu une alerte, mais n'avait pas les compétences nécessaires pour comprendre son un faux positif.

La communication est une rue à double sens

Hôte Bleu prétend 1,5 millions de sites hébergés par l'ensemble de leurs avoirs. Donc, ils ont maintenant 1,5 millions de clients qui ne peuvent pas:

• Recevez des alertes en temps réel de blocage de logiciels malveillants IP
• Recevoir des évaluations sur les menaces Internet actuelles
• Recevez des infos sur ce qui se passe dans le secteur de la sécurité

Donc, tout en essayant de se protéger est une chose positive, la mise en œuvre a eu un effet négatif sur la sécurité de leurs clients.

Comment vérifier une détection

Donc, nous allons tirer quelque chose de positif sur tout cela et d'identifier la bonne procédure pour vérifier une alerte de sécurité. Nous devons d'abord commencer avec un bon équipement. Ne pensez même pas un système de détection d'intrusion ou d'un système de prévention qui ne comprend pas:

• L'accès à la langue la signature
• Décodage complet des paquets suspects

Sans ces fonctions, vous prenez des photos dans l'obscurité.

Étape 1: Comprendre l'attaque

Lorsqu'une alerte se déclenche, assurez-vous de comprendre le mécanisme d'attaque. Quels sont les ports ou les services-t-il aller après? Y at-il signatures connues? Si vous Google le nom de l'attaque suivie par les mots clés "faux positif" et "usurpation", ne rien trouver?

Étape 2: Comprendre votre système anti-intrusion

Aucun produit de sécurité n'est parfait. Ils ont tous des faiblesses ou des limitations. Votre système anti-intrusion maintenir l'état? Si oui, est-il tout le temps ou juste une partie du temps? T-il de valider correctement les champs CRC? Comment ça faire face au trafic fragmenté? Est-il connu pour générer des faux positifs? Si c'est le cas, sont les faux positifs limités à seulement certaines signatures ou des protocoles, ou est-ce tout le temps?

Étape 3: Sanity vérifier l'alerte

Parfois, les faux positifs peuvent être éliminés de la quantité limitée d'info présenté dans une alerte. Par exemple ne la demande d'alerte d'avoir détecté une attaque HTTP venant TCP/80 au lieu d'aller à lui? Si oui, il ya un problème évident avec la signature générer l'alerte.

Étape 4: Vérifiez la signature

Certaines signatures sont écrits très précisément afin qu'il y ait peu de chances d'un faux positif. Certains sont plus générale, cependant si son possible pour des faux positifs sur l'automne. Examen de la signature qui a généré l'alerte et de faire un appel du jugement. T la signature vérifier 3-4 des conditions différentes ou dix ou plus? Évidemment, les autres paramètres, nous vérifions, moins il est probable que nous sommes pour obtenir un faux positif.

Étape 5: Vérifier le décodage

Si vous comprenez le schéma d'attaque, vous devriez déjà avoir une attente de ce qui sera dans le décodage attaque. Le paquet de correspondre à vos attentes? J'ai vu beaucoup de faux positifs générés par les gens qui lisent des infos sur un site Web décrivant une attaque basée sur HTTP. Ils sont faciles à distinguer en raison de la HTML supplémentaire, l'agent approprié et domaines référents, etc En bref, si le paquet ne correspond pas à un décodage connue de la véritable attaque, à comprendre pourquoi.

Étape 6: la recherche de la source

Je prends toujours le temps de m'assurer que je comprends qui est assis derrière l'adresse IP source. Parfois, cela peut aller un long chemin vers l'identification si je peux faire confiance à l'alerte. Je me souviens d'un ami qui interdit un certain nombre d'adresses IP de son système anti-intrusion avait identifiés comme hostiles. Peu de temps après il a commencé à remarquer que certaines parties de l'Internet ne sont plus accessibles. Il s'avère que quelqu'un usurpée une série d'attaques à partir des adresses IP des serveurs de noms racine . Avait-il pris le temps de rechercher les adresses IP d'abord, il n'aurait certainement pas pu les bloquer.

Résumé Exec

Blocage connu pour être des adresses IP hostiles peuvent certainement être bénéfique pour la sécurité, mais il doit être mis en œuvre avec prudence. Au cœur de tout système de sécurité du réseau doit être un expert en sécurité compétent avec bon sens. Si ce composant est manquant, toute la structure peut s'effondrer comme un château de cartes.

Mise à jour: Puisque l'envoi de ce que j'ai trouvé que Monster hôte (Host Bleu) bloque l'accès à un ou plusieurs Cisco serveurs ainsi. Devinez la liste continue ...