Jeder, der mit mir trainiert hat kann Ihnen sagen, ich bin real big auf die Möglichkeit, Ihr eigenes lesen erkennt. Während wir viele Sicherheitsvorrichtungen, die genau beschreiben, was sie denken, dass sie auf den Draht zu sehen versuchen, sie sind von Menschen programmiert und Menschen machen Fehler. Probieren und automatisieren den Prozess und die Fehler werden verschärft. Auch Cisco hat sich ein bisschen auf ihre grandiose Ansprüche, was eine gesicherte Self-Defending Network ist tatsächlich in der Lage. Nichts ersetzt, die eine qualifizierte Analysten der Überprüfung der Ergebnisse.

Gute Hilfe ist schwer zu finden

Natürlich ist das Schlüsselwort in diesem letzten Kommentar ist qualifiziert. Ich habe mit viel Senior Security Leute, die nie eine Dekodierung eines IP-Pakets haben gesehen, behandelt, geschweige denn kann Ihnen sagen, was für ein legit IP-Sitzung aussehen sollte. Eines der Probleme ist, wenn wir Training haben wir in der Regel die Anbieter wiederum müssen. Anbieter konzentrieren sich auf ihre hübschen GUI, nicht, was los ist hinter den Kulissen konzentrieren.

In einem früheren Leben, das ich im Besitz eines ISP und hatte einige sehr unterhaltsame Missbrauch vorgelegten Berichte. Einer meiner persönlichen Favoriten war ein admin berichtet, dass einer meiner Systeme war "Senden feindlichen ICMP-Pakete" zu einem seiner Systeme. Wenn ich meine logs überprüft, bemerkte ich, dass einer meiner Router in der Tat schickte ihn ICMP Host unreachable Nachrichten war. Dies würde passieren, jedes Mal, wenn sein Gastgeber sondiert den RPC-Port einer IP-Adresse, die nicht in Gebrauch war. Ich schrieb zurück und erklärte, dass, wenn sein System einfach aufhören würde Sondieren für nicht vorhandene Systeme, mein Router würde aufhören, ihm den Gastgeber ist off-line.

Ein weiterer admin (at eine ziemlich große, bekannte Unternehmen wie ich hinzufügen möchte) informierte mich, dass einer meiner Systeme griff ihn mit Code Red per E-Mail. Wenn Sie Code Red erinnern, nur angegriffen IIS Web-Server via HTTP. Die "Angriffe" in Frage Nutzern abonniert zu einer Mailing-Liste. Folks waren etwa, wie man gute Intrusion-Signaturen zu schreiben, um richtig zu fangen Code Red sprechen. Wenn das nicht ironisch genug, die Nutzlast des dekodieren schickte er mir als Beweis, erklärte, dass die Anschläge nur waren HTTP basiert. Wenn das Twist ist immer noch nicht genug zum Schmunzeln, wie er später zugab, dass er die eine der Personen abonniert, die Liste war.

Je mehr Dinge zu ändern, je mehr sie gleich bleiben

Mein Hosting-Provider Host Monster (eine Tochtergesellschaft von Blue Host) hat einen Filter eingerichtet blockiert alle Zugriffe auf das SANS Institute Mail-Server (SysAdmin, Audit, Network, Security Institute, bietet Computer-Sicherheit Ausbildung), The Internet Storm Center (täglich Tagebuch von Bedrohungen aus dem Internet) und DShield (ein Frühwarnsystem für Bedrohungen aus dem Internet). Ich kontaktierte unterstützen und sie bestätigten sie Filterung dieser Seiten. Ich konnte nicht herausfinden, warum darüber hinaus "wegen verdächtiger Aktivitäten".

Ich kenne die Leute, die SANS und dshield Server aufrecht zu erhalten. Sie sind harte Kern Sicherheit Leute mit einem ernsten Ahnung. Als ich das erste unterzeichnete mit meinem Hosting-Anbieter war ich mit dem Wissensstand ihrer Support-Mitarbeiter beeindruckt. In letzter Zeit jedoch habe ich festgestellt, sie selbst in die Grundlagen fehlen. Während ich links bin, was tatsächlich verursacht das Verbot schätze, ich bin geneigt zu glauben, dass jemand am Host Monster (oder möglicherweise Blau Host) sah eine Warnung, aber nicht über die Fähigkeiten, um herauszufinden, its a falsch positiv.

Kommunikation ist keine Einbahnstraße

Blau-Host Ansprüche 1,5 Millionen gehosteten Websites durch alle ihre Bestände. So haben sie jetzt 1,5 Millionen Kunden, die sich nicht:

• Receive Echtzeit blockiert Alarme von bösartigen IP ist
• Receive Einschätzungen zu aktuellen Bedrohungen aus dem Internet
• Erhalten Sie Informationen über das Geschehen in der Security-Branche

So bei dem Versuch, sich selbst zu schützen, ist eine positive Sache, hat die Umsetzung negativ auf die Sicherheit ihrer Kunden hat.

Wie überprüfen Sie eine Erkennung

So lasst uns ziehen etwas Positives aus der all dies und identifizieren das richtige Verfahren für die Überprüfung eine Sicherheitswarnung. Wir müssen zunächst mit einer guten Ausrüstung zu starten. Denkt nicht daran, ein Intrusion Detection oder Prevention-System, das keine:

• Der Zugriff auf die Unterschrift Sprache
• Vollständige Dekodierung von Verdächtigen Pakete

Ohne diese Funktionen sind Sie in der Dunkelheit schießen.

Schritt 1: Verstehen der Angriff

Wenn ein Alarm ausgelöst wird, machen Sie sich mit dem Angriff Mechanismus. Welche Ports oder Dienstleistungen geht sie nach? Gibt es irgendwelche bekannten Signaturen? Wenn Sie Google den Angriff der Name durch die Schlüsselwörter "false positive" und "gefälscht" gefolgt, der nichts kommen?

Schritt 2: Verstehen Sie Ihre Einbruchmeldeanlage

Keine Security-Produkt ist perfekt. Sie alle haben Schwächen oder Grenzen. Gibt es in Ihrem Intrusion System aufrechtzuerhalten Staat? Wenn ja, ist es die ganze Zeit oder nur einen Teil der Zeit? Ist es richtig validieren CRC-Felder? Wie sieht es mit den Traffic umgehen? Ist es bekannt, Fehlalarme zu erzeugen? Wenn ja, sind die Fehlalarme beschränkt, nur bestimmte Signaturen oder Protokolle, oder ist es die ganze Zeit?

Schritt 3: Sanity Check die Warnung

Manchmal Fehlalarme können von der begrenzten Menge an Informationen in eine Warnmeldung präsentiert gejätet werden. Zum Beispiel ist die Warnung Anspruch auf einen HTTP-Angriff erkannt, die aus TCP/80 anstatt ihn haben? Wenn ja, gibt es ein offensichtliches Problem mit der Signatur erzeugt die Warnung.

Schritt 4: Überprüfen der Signatur

Einige Signaturen sind sehr spezifisch, so dass es kaum eine Chance, ein falsch positives geschrieben. Einige sind allgemein jedoch so seine möglichen falsch-positiven Ergebnisse fallen haben. Überprüfen Sie die Signatur, die die Warnung generiert und ein Urteil nennen. Ist die Signatur zu überprüfen, 3-4 verschiedenen Bedingungen oder zehn oder noch mehr? Offensichtlich ist der weitere Parameter überprüfen wir, desto weniger wahrscheinlich sind wir zu einem falsch positiven zu bekommen.

Schritt 5: Überprüfen Sie die Dekodierung

Wenn Sie den Angriff Muster zu verstehen, sollten Sie bereits über eine Erwartung dessen, was in den Angriff zu decodieren. Ist das Paket Ihren Erwartungen entsprechen? Ich habe viele False Positives von Menschen zu lesen Informationen über eine Website beschreibt einen HTTP-basierte Angriffe generiert gesehen. Diese sind leicht zu unterscheiden durch die zusätzliche HTML, korrekte Agent-und Referrer Felder, etc. Kurz gesagt, wenn das Paket nicht mit einem bekannten Dekodierung von den eigentlichen Angriff, herauszufinden, warum.

Schritt 6: Forschung die Quelle

Ich habe immer die Zeit nehmen, um sicherzustellen, dass ich verstehe, wer sich hinter der Quell-IP-Adresse sitzen. Manchmal kann dies ein langer Weg zur Identifizierung, ob ich die Warnung Vertrauen zu gehen. Ich bin von einem Freund, dass eine Reihe von IP-Adressen seiner Intrusion-System als feindlich identifiziert hatte verboten erinnert. Kurz nachdem er angefangen zu bemerken, dass Teile des Internet nicht mehr erreichbar waren. Stellt sich heraus, jemandem gefälschte eine Reihe von Angriffen aus dem IP-Adressen der Root-Nameserver . Hätte er die Zeit zum Nachschlagen der IP-Adressen zuerst genommen, er sicherlich hätte sie nicht blockiert sind.

Exec Zusammenfassung

Blocking bekannt feindlichen IP-Adressen werden kann sicherlich von Vorteil sein, um die Sicherheit, aber es muss mit Vorsicht erfolgen. Im Kern jedes Netzwerk-Sicherheitssystem muss eine sachkundige Sicherheitsexperten mit gesundem Menschenverstand werden. Wenn diese Komponente fehlt, kann die gesamte Struktur fällt auseinander wie ein Kartenhaus.

Update: Da dieses Posting habe ich festgestellt, dass Host Monster (Blue Host) blockiert den Zugriff auf eine oder mehrere Cisco -Server sowie. Raten Sie die Liste geht weiter ...