Någon som har tränat med mig kan berätta jag är riktigt stora på att kunna läsa dina egna upptäcker. Även om vi har gott om säkerhetsanordningar som försöker att exakt beskriva vad de tror att de ser på tråden, de är programmerade av människor och människor gör misstag. Försök att automatisera processen och misstag blir förvärras. Även Cisco har backade lite på deras grandiosa påståenden om vad en själv Defending Network är faktiskt klarar av. Ingenting ersätter ha en skicklig analytiker granskar resultaten.

God hjälp är svårt att hitta

Naturligtvis nyckelordet i den sista kommentaren är skicklig. Jag har behandlat med mycket högre säkerhet folk som aldrig har sett en avkoda av ett IP-paket, än mindre kan berätta vad en legit IP-session ska se ut. Ett av problemen är när vi behöver utbildning vi brukar vända sig till leverantörer. Leverantörer tenderar att fokusera på sina vackra GUI, inte vad som händer bakom kulisserna.

I ett tidigare liv jag ägde en ISP och hade några mycket underhållande missbruk inlämnade rapporter. En av mina personliga favoriter var en admin rapporterar att en av mina system var "skicka fientliga ICMP-paket" till en av hans system. När jag granskade mina loggar, noterade jag att en av mina routrar i själva verket skicka honom ICMP-meddelanden värd onåbar. Detta skulle hända varje gång hans värd sonderade RPC-porten på en IP-adress som inte används. Jag skrev tillbaka och förklarade att om hans system skulle helt enkelt sluta sondera för icke-existerande system, skulle min router stoppa träffande honom värden är off-line.

En annan admin (på ett ganska stort, välkänt företag kan jag tillägga) informerade mig om att en av mina system var attackera honom med Code Red via e-post. Om du kommer ihåg Code Red, angrep det bara IIS-webbservrar via HTTP. Den "attacker" i fråga var användarna prenumererar på en e-postlista. Folk pratade om hur man skriver bra intrång underskrifter för att korrekt fånga Code Red. Om det inte var ironiskt nog, den nyttolast avkoda han sände mig som bevis förklarade att attackerna var bara HTTP-baserad. Om det twist är fortfarande inte tillräckligt för att få dig att skratta, erkände han senare att han var en av de personer prenumererar på den listan.

Ju mer saker förändras desto mer förblir de desamma

Min webbhotellet Host Monster (ett dotterbolag till blå Host) har lagt ett filter på plats blockera all tillgång till SANS Institute postservern (sysadmin, revision, nätverk, säkerhet institutet, ger datasäkerhet utbildning), The Internet Storm Center (dagligen dagbok av Internet säkerhetshot) och DShield (ett system för tidig varning för hot på Internet). Jag kontaktade support och de bekräftade att de är filtrering av dessa platser. Jag kunde inte ta reda på varför bortom "på grund av misstänkt aktivitet".

Jag känner folk som upprätthåller SANS och servrar Dshield. De är hård kärna säkerheten människor med en allvarlig ledtråd. När jag först registrerade dig med min webbhotellet jag var imponerad av kunskapsnivå deras supportpersonal. På senare tid dock, jag hittade dem saknas i ens grunderna. Medan jag är kvar att gissa om vad som faktiskt orsakade förbudet, jag är benägen att tro att någon på Host Monster (eller möjligen Blue Host) såg en varning men inte har kompetens att räkna ut sin ett falskt positivt.

Kommunikation är en ömsesidig process

Blå Host anspråk 1.500.000 värd webbplatser igenom alla sina innehav. Så de har nu 1.5 miljoner kunder som inte kan:

• Ta emot realtid blockering varnar för skadliga IP: s
• Ta emot bedömningar om aktuella hot på Internet
• Ta emot info om vad som händer i säkerhetsbranschen

Så samtidigt som man försöker skydda sig är något positivt, har genomförandet haft en negativ inverkan på säkerheten för sina kunder.

Så för att verifiera en detektera

Så låt oss dra något positivt ur allt detta och identifiera korrekt förfarande för kontroll av en säkerhetsvarning. Vi måste först börja med bra redskap. Inte ens överväga en detektering av intrång eller förebyggande system som inte innehåller:

• Tillgång till signaturen språk
• Fullständig avkodning av misstänkta paket

Utan dessa funktioner du fotograferar i mörker.

Steg 1: Förstå attack

När ett larm blir utlöst, se till att du förstår attacken mekanism. Vilka portar eller tjänster går det efter? Finns det några kända signaturer? Om du Google attacken namn följt av nyckelorden "falska positiva" och "falska", gör något kommer upp?

Steg 2: Förstå dina intrång systemet

Ingen säkerhet produkt är perfekt. De har alla svagheter eller begränsningar. Har din intrång systemet upprätthåller staten? Om så, är det hela tiden eller bara en del av tiden? Är det korrekt validera CRC fält? Hur det behandlar inte fragmenterad trafik? Är det känt att generera falsklarm? Om så är fallet, är de falska positiva begränsat till endast vissa signaturer eller protokoll, eller är det hela tiden?

Steg 3: Sanity kontrollera larm

Ibland falska positiva kan rensas bort från det begränsad mängd information som presenteras i en varning. Till exempel går larmet anspråk på att ha upptäckt en HTTP-angrepp som kommer från TCP/80 istället för att gå till det? Om så är fallet finns det ett uppenbart problem med undertecknandet generera registreringen.

Steg 4: Kontrollera signatur

Några signaturer är skrivna mycket specifikt, så att det är liten chans att ett falskt positivt. Vissa är mer generella dock så det är möjligt att ha falskt positiva faller ut. Granska signatur som genererade varningen och göra en bedömning. Har signaturen kolla 3-4 olika villkor eller tio eller fler? Uppenbarligen fler parametrar vi kontrollerar, desto mindre sannolikt vi ska få ett falskt positivt.

Steg 5: Kontrollera avkoda

Om du förstår attacken mönster, bör du redan har en förväntan på vad som kommer att vara i attacken avkoda. Har paketet matchen dina förväntningar? Jag har sett massor av falska positiva som genereras av människor som läser information på en webbplats som beskriver en HTTP-baserad attack. Dessa är lätt att skilja på grund av den extra HTML, riktig agent och fält referrer, etc. Kort sagt, om paketet inte matchar en känd avkoda den verkliga attacken, räkna ut varför.

Steg 6: Forskning källan

Jag tar alltid tid att se till att jag förstår vem som sitter bakom källan IP-adress. Ibland kan detta räcka långt mot att utröna om jag kan lita på registreringen. Jag påminns om en vän som förbjöd ett antal IP-adresser sitt intrång systemet hade identifierats som fientligt. Kort efter började han lägga märke till att delar av Internet inte längre nås. Det visade sig att någon förfalskat en serie attacker från IP-adresser rotnamnsservrar . Hade han tagit sig tid att slå upp IP-adresserna först, han säkerligen inte skulle ha blockerat dem.

Exec Sammanfattning

Blockering kända för att vara fientligt inställd IP-adresser kan säkert vara till nytta för säkerheten, men det måste genomföras med försiktighet. Kärnan i något nätverk säkerhetssystem måste vara en kunnig säkerhet expert med sunt förnuft. Om denna komponent saknas, kan hela strukturen falla ihop som ett korthus.

Uppdatering: Eftersom att publicera den här jag har upptäckt att Host Monster (Blue Host) blockerar åtkomsten till en eller flera Cisco -servrar också. Gissa listan fortsätter ...