Alle som har trent med meg kan fortelle deg er jeg virkelig stor på å kunne lese din egen oppdager. Selv om vi har nok av sikkerhet enheter som forsøker å nøyaktig beskrive hva de tror de ser på wire, de er programmert av mennesker og mennesker gjør feil. Prøv og automatisere prosessen og feilene blir forsterket. Selv Cisco har støttet seg litt på deres grandiose påstander om hva en selv forsvare nettverk faktisk er i stand til. Ingenting erstatter å ha en dyktig analytiker gjennomgang av funnene.

God hjelp er vanskelig å finne

Selvfølgelig søkeordet i den siste kommentaren er dyktig. Jeg har behandlet mange senior sikkerhet folk som aldri har sett en dekode av en IP-pakke, la alene kan fortelle deg hva en legit IP sesjon bør se ut. Et av problemene er når vi trenger treningen vi vanligvis slår til forhandlerne. Leverandører har en tendens til å fokusere på sine vakre GUI, ikke hva som skjer bak kulissene.

I et tidligere liv eide jeg en ISP og hadde noen veldig underholdende misbruk rapporter framlagt. En av mine personlige favoritter var en admin rapporterer at en av mine systemer var "sende fiendtlig ICMP pakker" til en av sine systemer. Da jeg anmeldt loggene mine, bemerket jeg at en av mine rutere var faktisk sende ham ICMP host unreachable meldinger. Dette vil skje hver gang hans vert analysert RPC-porten på en IP-adresse som ikke var i bruk. Jeg skrev tilbake og forklarte at hvis hans system ville bare stoppe undersøkelser for ikke-eksisterende systemer, ville min router stoppe fortelle ham verten er off-line.

En annen admin (at en ganske stor, kjent selskap jeg kan legge til) informerte meg om at en av mine systemer var å angripe ham med Code Red via e-post. Hvis du husker Code Red, det eneste angrepet IIS Web servere via HTTP. Den "angrep" i spørsmålet var brukerne abonnerer på en adresseliste. Folk snakket om hvordan du skriver gode inntrenging underskrifter til riktig fange Code Red. Hvis det ikke var ironisk nok, nyttelast på decode han sendte meg som bevis forklarte at angrepene var bare HTTP basert. Hvis det twist er likevel ikke nok til å gjøre deg latter, han senere innrømmet at han var en av dem abonnerer på den listen.

Jo mer ting endrer jo mer de holder samme

Min hosting leverandør Host Monster (et datterselskap av Blue Host) har lagt et filter på plass blokkere all tilgang til SANS Institute postserveren (administratorvennlige, Audit, Network, Security Institute, gir datasikkerhet trening), The Internet Storm Center (daglig dagbok av Internett sikkerhetstrusler) og DShield (et tidlig varslingssystem for trusler fra Internett). Jeg kontaktet support og de bekreftet at de filtrerer disse områdene. Jeg klarte ikke å finne ut hvorfor utover "på grunn av mistenkelig aktivitet".

Jeg kjenner folk som opprettholder SANS og Dshield servere. De er harde kjernen sikkerhet folk med en alvorlig anelse. Når jeg først registrert med min hosting leverandør Jeg ble imponert over kunnskapsnivået om deres støtte personell. I det siste derimot, har jeg funnet dem å være mangler selv det grunnleggende. Mens jeg igjen å gjette på hva som egentlig forårsaket forbudet, er jeg tilbøyelig til å tro at noen på Host Monster (eller muligens blå Host) så en advarsel, men ikke har kompetanse til å regne ut sin en falsk positiv.

Kommunikasjon er en toveis gate

Blå Host hevder 1.500.000 vert nettsteder gjennom alle sine beholdninger. Så de har nå 1.5 millioner klienter som ikke kan:

• Motta real time blokkering varsler ondsinnet IP-adresser
• Motta vurderingene på dagens Internett-trusler
• Motta informasjon om hva som skjer i sikkerhetsbransjen

Så mens du forsøker å beskytte seg er en positiv ting, har implementeringen hatt en negativ effekt på sikkerheten til sine klienter.

Hvordan verifisere en oppdage

Så la oss trekke noe positivt ut av alt dette og identifisere riktig prosedyre for å verifisere en sikkerhetsadvarsel. Vi må først starte med godt utstyr. Ikke engang vurdere en intrusion detection eller forebygging system som ikke inkluderer:

• Tilgang til signaturen språk
• Full dekode av mistenkelige pakker

Uten disse funksjonene er du fotograferer i mørket.

Trinn 1: Forstå angrepet

Når et varsel blir utløst, sørg for at du forstår angrepet mekanismen. Hvilke porter eller tjenester går det etter? Er det noen kjente signaturer? Hvis du Google angrepet navn etterfulgt av stikkordene "falske positive" og "falske", gjør noe kommer opp?

Trinn 2: Forstå din inntrenging system

Ingen sikkerhet produktet er perfekt. De har alle svakheter og begrensninger. Har din inntrenging system opprettholde staten? I så fall er det hele tiden eller bare noen av tiden? Betyr det riktig validere CRC felt? Hvordan håndtere den med fragmenterte trafikk? Er det kjent for å generere falske positiver? Hvis ja, er falske positiver begrenset til bare enkelte signaturer eller protokoller, eller er det hele tiden?

Trinn 3: Sanity sjekke varselet

Noen ganger falske positiver kan lukes ut fra den begrensede mengden av informasjon som presenteres i et varsel. For eksempel gjør varselet hevder å ha oppdaget en HTTP-angrep som kommer fra TCP/80 stedet for å gå til det? Hvis ja, det er en åpenbar problem med signaturen generere varselet.

Trinn 4: Sjekk signatur

Noen signaturer er skrevet veldig spesielt slik at det er liten sjanse for en falsk positiv. Noen er mer generelle imidlertid så det er mulig å få falske positive faller ut. Gjennomgå signatur som genererte vakt og gjør en vurderingssak. Har signaturen sjekker 3-4 forskjellige tilstander eller ti eller mer? Tydeligvis flere parametere vi sjekker, jo mindre sannsynlig at vi skal få en falsk positiv.

Steg 5: Sjekk decode

Hvis du forstår angrepet mønsteret, bør du allerede har en forventning om hva som vil være i angrepet dekode. Har pakken matche dine forventninger? Jeg har sett nok av falske positiver generert av folk leser informasjon på et nettsted som beskriver en HTTP-basert angrep. Disse er lett å skille på grunn av den ekstra HTML, riktig agent og referrer felt, etc. Kort sagt, hvis pakken ikke samsvarer en kjent dekode av den virkelige angrepet, finne ut hvorfor.

Trinn 6: Forskning kilden

Jeg tar alltid tid til å sørge for at jeg forstå hvem sitter bak kildens IP-adresse. Noen ganger kan dette gå en lang vei mot å identifisere om jeg kan stole varselet. Jeg minnes en venn som forbød en rekke IP-adresser hans inntrenging systemet hadde identifisert som fiendtlig. Kort tid etter at han begynte å legge merke til at deler av Internett ikke lenger var tilgjengelig. Slår ut noen forfalskede en rekke angrep fra IP-adressene til roten navnet servere . Hadde han tatt seg tid til å slå opp IP adressene først, han absolutt ikke ville ha blokkert dem.

Exec Summary

Blokkering kjent for å være fiendtlige IP-adresser kan sikkert være gunstig for sikkerhet, men det må iverksettes med forsiktighet. I kjernen av noe nettverk sikkerhetssystem må være en kunnskapsrik sikkerhetsekspert med sunn fornuft. Hvis denne komponenten mangler, kan hele strukturen falle sammen som et korthus.

Oppdatering: Siden poste dette har jeg funnet ut at Host Monster (Blue Host) blokkerer tilgang til én eller flere Cisco servere også. Gjett listen fortsetter ...