Inkräktarlarm måste byggas in i tillämpningarna

Nätverkssäkerhet har hamnat i fokus inte minst efter de allvarliga störningsattackerna mot stora nätplatser som Yahoo och Ebay.

Larm kan utformas på några olika sätt, men grundprincipen är densamma: Trafiken avlyssnas till och från det system eller nät som ska skyddas. Larmet letar efter specifika mönster av IP-paket och av data i själva paketen för att försöka hitta angrepp. När larmet hittar något skumt loggas detta och administratören meddelas.

Klarar inte högtrafik

Flera olika angreppsmönster kan hittas. Exempelvis är sekventiell portsökning (uppkopplingsförsök till flera IP-portar på en maskin) typexempel på hur en mindre slug angripare börjar sin attack. Mer sofistikerade angrepp som kan upptäckas är speciellt utformade HTTP-anrop för att utnyttja fel hos webbserverns skriptprogram eller e-post med ondsint javascript-kod i.

Gemensamt för angreppsmönstren är det hela tiden dyker upp nya metoder, varför larmen kontinuerligt måste uppdateras.

Att sätta larm på ett nät med låg trafikvolym är inte speciellt svårt: En speciellt modifierad Unix-maskin kopplas in på ett nav (hubb) med in och utgående trafik och avlyssnar alla paket.

Enligt Marcus J Ranum, chef för Network Flight Recorder - ett av företagen som tillverkar inkräktarlarm, är dock alla på marknaden förekommande system otillräckliga för nät med hög trafik:

- De flesta system börjar tappa paket vid 30 Mbit/s. Med högre trafik avgör slumpen vilka angrepp som upptäcks, säger Ranum.

Bänktest som visar prestandamått är i det flesta fall värdelösa. Det går att konstruera test som visar att ett godtyckligt system har bättre prestanda än alla andra.

- Testa istället systemet med verklig trafik och kontrollera att det verkligen meddelar när trafiken blir för hög och paket kastas. Det värsta är vissa system som bara tyst kastar paket.

Alla nät med hög trafik har också växlade portar mot omvärlden vilket ställer till problem. För att larmet ska fungera måste all trafik speglas ut på den växelport som larmet sitter på. Beroende på nätstruktur kan det vara enkelt eller praktiskt taget omöjligt.

Enligt Marcus J Ranum (som ju är part i målet) bör ett modernt larm klara att upptäcka fyra specifika sätt att luras med paket: Fragmentrouting, falska slutpaket (FIN), paket med olika livstid (TTL) samt flera versioner av samma paket.

Hur man lurar larmet

I det första försöker angriparen lura larm och brandvägg genom att skicka fragment av IP-paket som är ändrade på något vis. Förhoppningen är att larmet bara tittar på första fragmentet i paketet för att avgöra vilken typ av paket det är. Följande fragment kan sedan adresseras på annat sätt för att kartlägga nät eller attackera tjänster på servrar.

Falska slutpaket ska lura larmet till att tro att en TCP-förbindelse är avslutad och inte längre behöver kontrolleras. I själva verket är förbindelsen till servern fortfarande igång och kan användas för angrepp utan att larmet reagerar.

Livstiden på paket anger hur många routrar de kan gå igenom innan de kastas. Genom att variera livstiden på paket i samma TCP-förbindelse kan en angripare selektivt adressera paket bara till larm eller brandvägg och på så vis ge en falsk bild av data i TCP-förbindelsen.

Till sist kan en angripare skicka flera TCP-paket med samma sekvensnummer men olika innehåll. Ett dumt larm tittar bara på det första paketet och tror att efterföljande bara är omsändningar av samma paket.

(Se länkarna för information om testverktyg för olika fall.)

Men hur bra larmet än är finns det oändliga möjligheter att kringgå det. HTTP-anrop kan till exempel skrivas om som hexkod i stil med %41%45 för att kringgå sökning på textsträngar. Dessutom klarar inte larm krypterade förbindelser, exempelvis SSL (secure sockets layer) som används för säkra webbsidor. Sådana krypterade förbindelser ger inget skydd mot angrepp som sker via dem samtidigt som de inte kan avlyssnas av larm.

Därför är det absolut bästa, och det enda som möjliggör larm på krypterade tjänster, att bygga in larmfunktioner direkt i tillämpningsprogrammen: webbservrar ska larma när felaktiga eller bisarra data skickas till dem; logintjänster ska larma för uppkopplingsförsök från okända adresser och så vidare.

Sätt interna larm

Att bygga och underhålla ett larm är inte alltför arbetskrävande. Enligt Marcus J Ranum krävs en heltidstjänst för att hålla sig ajour med utvecklingen samt ett till två manårs utveckling för själva programlogiken. Kräv alltså larm i alla tillämpningsprogram!

Eftersom större delen av de allvarliga dataintrången sker inifrån nätverket och görs av personer som verkligen ska ha tillgång till nättjänster, bör också larm sättas internt. Ekonomisystemet ska larma om någon utanför ekonomiavdelningen använder det och servern med programkod ska larma om någon utanför utveckling använder den.

Men enligt Marcus J Ranum är tekniken sällan det viktigaste. Personliga relationer spelar större roll och det är viktigt med klara nedskrivna regler:

- Det är lätt att ta hand om inkräktare utifrån - stäng dem ute eller släpp loss juristerna.

Svårt få skurkar dömda

- Det är värre när du finner att en medarbetare gör skumma saker. Kan du anmäla en vän för chefen? Vem går du till om chefen skickar information till konkurrenterna? från Ranum retoriskt.

Att lyckas med att sätta dit en cracker hör till undantagen. Att få en någon dömd i domstol kan kosta enorma summor i främst arbetstid och de flesta företag måste ta ställning till om det är värt kostnaden. Eftersom bevisningen är svår, lagarna nya, oklara och skiftande från land till land är det svårt att få en fällande dom även vid uppenbara dataintrång. Eller som Marcus J Ranum formulerar det:

- Bra killar får du inte fast. De som går att sätta dit är inte värda besväret.

  (20000323)

Externa länkar

Axent

Computer Associates

Internet Security Systems

IBM

Cisco

Cybersafe

Intrusion.com

Network Associates