Iedereen die is opgeleid met mij kan je vertellen ik ben echt groot op de mogelijkheid om uw eigen lezen detecteert. Hoewel we hebben genoeg van veiligheidsvoorzieningen die proberen om nauwkeurig te beschrijven wat ze denken dat ze zien op de draad, worden ze geprogrammeerd door mensen en mensen maken fouten. Probeer en automatiseren van het proces en de fouten worden verergerd. Ook Cisco heeft een back-off een beetje op hun grandioze aanspraken van wat een zelf Defending Network is eigenlijk in staat. Niets vervangt het hebben van een ervaren analist de herziening van de bevindingen.

Goede hulp is moeilijk te vinden

Natuurlijk is het sleutelwoord in die laatste opmerking is opgeleid. Ik heb behandeld met veel senior security mensen die nog nooit hebben gezien een decode van een IP-pakket, laat staan ​​kan je vertellen wat een legitieme IP-sessie eruit moet zien. Een van de problemen is wanneer we moeten trainen we meestal terecht bij de leveranciers. Leveranciers hebben de neiging zich te richten op hun mooie GUI, niet wat er gaande is achter de schermen.

In een vorig leven heb ik in handen een ISP en had een aantal zeer vermakelijke ingediend misbruik rapporten. Een van mijn persoonlijke favorieten was een admin melden dat een van mijn systemen werd 'vijandige ICMP-pakketten versturen "om een ​​van zijn systemen. Toen ik mijn logs beoordeeld, merkte ik dat een van mijn routers was in feite het verzenden van hem ICMP gastheer onbereikbaar berichten. Dit zou gebeuren elke keer als zijn gastheer onderzoek gedaan naar de RPC-poort van een IP-adres dat niet in gebruik was. Ik schreef terug en legde uit dat als zijn systeem zou gewoon stoppen met te zoeken naar niet-bestaande systemen, mijn router zou stoppen met hem te vertellen van de host is off-line.

Een andere admin (bij een vrij groot, bekend bedrijf waar ik zou kunnen toevoegen) vertelde me dat een van mijn systemen werd hem aanvallen met Code Red via e-mail. Als u het zich herinnert Code Red, het alleen IIS-webservers aangevallen via HTTP. De "aanslagen" in kwestie waren gebruikers ingeschreven op een mailinglijst. Mensen hadden het over hoe je goede inbraak handtekeningen schrijven om goed te vangen Code Red. Als dat niet ironisch genoeg, de lading van de decode stuurde hij me als bewijs legt uit dat de aanvallen alleen werden HTTP gebaseerd. Als dat twist is nog steeds niet genoeg om je grinniken, hij gaf later toe dat hij de een van de mensen ingeschreven op die lijst.

Hoe meer dingen veranderen hoe meer ze hetzelfde blijven

Mijn hosting provider Host Monster (een dochteronderneming van Blue Host) heeft een filter op zijn plaats het blokkeren van alle toegang tot het SANS Institute mailserver (SysAdmin, Audit, Network, Security Institute, is voorzien in computerbeveiliging opleiding), Het Internet Storm Center (dagelijks dagboek van Internet bedreigingen van de veiligheid) en DShield (een systeem voor vroegtijdige waarschuwing voor Internet bedreigingen). Ik nam contact op ondersteuning en ze bevestigd dat ze zijn deze sites te filteren. Ik was niet in staat om uit te vinden waarom dan "als gevolg van verdachte activiteiten".

Ik weet dat de mensen die de SANS en Dshield servers te onderhouden. Ze zijn hard core security mensen met een ernstige aanwijzing. Toen ik voor het eerst aangemeld bij mijn hosting provider was ik onder de indruk van het kennisniveau van hun ondersteunend personeel. De laatste tijd echter, ik heb ze gevonden te ontbreken zelfs in de basis. Terwijl ik van links naar raden naar wat er werkelijk de oorzaak van de ban, ben ik geneigd te denken dat iemand bij Host Monster (of eventueel Blue Host) zag een waarschuwing, maar niet over de vaardigheden om erachter te komen het is een false positive.

Communicatie is tweerichtingsverkeer

Blue Host claimt 1,5 miljoen gehoste websites door alle van hun aandelen. Dus ze hebben nu 1,5 miljoen klanten die niet kunnen:

• Ontvang real-time blokkering waarschuwingen van kwaadaardige IP's
• Ontvang evaluaties van de huidige internetbedreigingen
• Ontvang informatie over wat er in de beveiligingsbranche

Dus tijdens een poging om zichzelf te beschermen is een goede zaak, heeft de uitvoering had een negatief effect op de veiligheid van hun klanten.

Hoe maak je een detecteren controleren

Dus laten we iets positiefs te trekken uit dit alles en identificeren van de juiste procedure voor het verifiëren van een beveiligingswaarschuwing. We hebben eerst moeten beginnen met een goede versnelling. Niet eens overwegen een inbraak sporen of te voorkomen systeem dat niet zijn:

• De toegang tot de handtekening taal
• Volledige decode van verdachte pakketjes

Zonder deze functies u opnamen maakt in het donker.

Stap 1: Begrijp de aanval

Bij een alarm wordt geactiveerd, zorg ervoor dat u inzicht in de aanval mechanisme. Welke poorten of diensten gaat het naartoe na? Zijn er bekende handtekeningen? Als u Google de aanval de naam gevolgd door de sleutelwoorden "valse positieve" en "spoofed", is er iets komen?

Stap 2: Begrijp uw inbraaksysteem

Geen beveiliging product is perfect. Ze hebben allemaal zwakheden of beperkingen. Heeft uw inbraak in stand te houden staat? Zo ja, is het de hele tijd of alleen een deel van de tijd? Is het correct valideren CRC velden? Hoe werkt het omgaan met gefragmenteerde verkeer? Is het bekend dat valse meldingen te genereren? Zo ja, zijn de valse positieven beperkt tot alleen bepaalde handtekeningen of protocollen, of is het de hele tijd?

Stap 3: Sanity controleer de alert

Soms false positives kan worden uitgeroeid uit de beperkte hoeveelheid informatie gepresenteerd in een waarschuwing. Zo heeft de waarschuwing aanspraak op hebben gedetecteerd dat een HTTP-aanval uit TCP/80 in plaats van naar het? Zo ja, is er een duidelijk probleem met de handtekening van het genereren van de waarschuwing.

Stap 4: Controleer de handtekening

Sommige handtekeningen zijn zeer speciaal geschreven zodat er weinig kans op een vals positief. Sommige zijn meer in het algemeen echter zo is het mogelijk om vals-positieve val hebben uit. Bekijk de handtekening die de waarschuwing gegenereerd en zich een oordeel gesprek. Heeft de handtekening te controleren 3-4 verschillende voorwaarden of tien of meer? Uiteraard is de meer parameters we controleren, hoe minder de kans dat we tot een vals positieve te krijgen.

Stap 5: Controleer de decoderen

Als u begrijpt de aanval patroon, moet u al een verwachting van wat er in de aanval decoderen. Is het pakket aan je verwachtingen? Ik heb gezien dat veel valse positieven gegenereerd door mensen die het lezen van informatie op een website beschrijven van een HTTP-based aanval. Deze zijn gemakkelijk te wijten aan de extra HTML, een goede agent en referrer velden, enz. onderscheiden Kortom, als het pakket niet overeenkomt met een bekende decode van de echte aanval, erachter te komen waarom.

Stap 6: Onderzoek van de bron

Ik neem altijd de tijd om ervoor te zorgen dat ik te begrijpen wie zit achter de bron IP-adres. Soms kan dit gaan een lange weg naar het identificeren van of ik de waarschuwing vertrouwen. Ik moet denken aan een vriend die een aantal IP-adressen zijn inbraaksysteem had geïdentificeerd als vijandig verboden. Kort daarna begon hij te merken dat delen van het internet niet meer bereikbaar. Blijkt dat iemand spoofed een reeks aanvallen van de IP-adressen van de root name servers . Had hij de tijd om te kijken op de IP-adressen eerst genomen, dat hij zeker niet zou hebben geblokkeerd zijn.

Exec Samenvatting

Het blokkeren van bekend is dat ze vijandig IP-adressen kan zeker nuttig zijn om de veiligheid, maar het moet worden uitgevoerd met de nodige voorzichtigheid. Aan de basis van elke netwerkbeveiliging moet een goed geïnformeerde security expert met gezond verstand zijn. Als dat onderdeel ontbreekt, kan de hele structuur uit elkaar valt als een kaartenhuis.

Update: Omdat het posten van dit Ik heb ontdekt dat Host Monster (Blue Host) is toegang tot een of meer het blokkeren van Cisco servers ook. Denk dat de lijst gaat verder ...