Jo, du kan fortfarande övervaka krypterad nätverkstrafik – här är tre sätt

Säkerhetsexperter har länge propagerat, med all rätt, för att nätverkstrafiken mellan en sajt och dess användare ska krypteras. Att använda https är förstås en bra ide, speciellt som de standarder, protokoll och produkter som tillämpas uppnått hög grad av mognad, tillförlitlighet och prestanda. Om du infört kryptering har du gjort ett gott jobb.

Men alla mynt har en baksida. Som allt annat här i världen har även krypterad nätverkstrafik sina kompromisser. Den förmodligen största nackdelen med https är att det blir mycket svårt för dig som administratör av sajten att inspektera paketen i syfte att upptäcka skadlig kod eller oönskat innehåll. Så hur gör man i så fall?

Det korta svaret är att det inte går; möjligheten till så kallad Deep Packet Inspection, DPI, är stängd. Det längre svaret är att det finns möjligheter att inspektera trafiken i ändpunkterna, där kryptering och avkryptering sker, och att du kan ta del av en hel del information och trafikens metadata, som till exempel var trafiken kommer ifrån och vart den ska.

Det mesta av inspektionen kan ske med hjälp av varje vettigt Intrusion Detection/Protection System, IDS/IPS, i nätverket eller på ändpunkter, som ju kan ge en hel del information om trafiken även om dessa system inte kan läsa själva innehållet i paketen. Men det är också bra att kunna gå bortom de uppenbara verktygen och lära sig sin trafik. Vi ska titta på tre metoder som ger nyttig information om nätverkstrafiken på protokollnivå.

Hitta avvikelser i trafiken

Om du inte kan inspektera innehållet i paketen behöver du övervaka trafikflödet för att upptäcka avvikelser. Och för att kunna hitta avvikelser behöver du veta vad som är normalt. Om du till exempel upptäcker trafik mellan två system som normalt sett inte ska kommunicera med varandra, antingen mellan interna system eller mellan ett internt system och en okänd extern part, är det något du bör reagera på. Det är helt klart ett misstänkt beteende.

Ett annat misstänkt beteende du bör hålla koll på är onormalt användande av tcp/udp-portar. Du kan använda listor över välkända och inte fullt så välkända portar som en utgångspunkt. Misstänkt beteende handlar inte bara om ovanliga portar utan även hur portar används för applikationer de normalt inte används för, exempelvis om det skickas ren text över tcp-port 443 som är reserverat för ssl/tls.

Denna typ av analyser kräver någon form av automatisering eftersom det blir hopplösa mängder data att tröska igenom manuellt. Det finns ett antal kommersiella produkter att välja mellan, men även öppen källkods-produkten Snort IPS. Det mest sofistikerade produkterna kan även ta hjälp av AI och analysera trafik på global nivå. När du behöver gräva djupare i trafiken på detaljnivå finns det andra bra verktyg i form av Wireshark – numer i en fräsch ny version för Windows – och Fiddler. Ett annat intressant verktyg är JA3 och JA3S som utvecklats av Salesforce och finns att tillgå under öppen källkod. Dessa verktyg skapar ”fingeravtryck” av TLS-kopplingar som visar detaljer om kommunikationen och TLS-implementationen av de kommunicerande parterna.

Använd proxyservrar för SSL/TLS

Ett sätt att faktiskt göra så att viss, men inte all, krypterad kommunikation kan inspekteras är att använda en SSL/TLS-proxy. Kommunikationen passerar då proxyservern som tar emot och krypterar upp trafiken i ena änden och krypterar och skickar vidare i den andra. Däremellan kan proxyn inspektera innehållet eller genomsöka det efter skadlig kod eller blockera skadliga sajter. Många tredjeparts-säkerhetsprodukter opererar som SSL/TLS-proxys.

Nackdelen är att denna typ av produkter adderar komplexitet till en redan komplex nätverkskonfiguration. Även om de till och med kan accelerera trafiken genom buffring, har de också potentialen att göra trafiken långsammare. Det finns även varningar, från till exempel amerikanska myndigheten Department of Homeland Security, som pekar på att produkterna ibland inte validerar certifikat på ett korrekt sätt och att de kan vidarebefordra felaktiga paket. Många experter, som Will Dormann på Carnegie Mellon, menar också att ssl-inspektion inte är värt risken de introducerar.

Var beredd på andra typer av kryptering än SSL/TLS

Legal krypterad trafik på paketnivå är typiskt krypterad med SSL/TLS, men det finns ju även andra protokoll du kan stöta på. Vissa kan vara ok, men andra har inget att hämta i ditt nätverk. Högt upp på topplistan över misstänkta krypteringsprotokoll är Secure Shell, ssh. Det är inget fel på ssh i sig; det används en hel del för fjärradministration och utveckling, utan problemet är att ssh även är favoritprotokollet bland cyberkriminella förövare. Och det finns inte mycket till silverkulor att ta till; du behöver öppna för ssh, men kanske inte för alla användare på alla nätverkssegment. Du behöver också hålla koll på ssh-trafik som inte fogar sig efter legitima profiler.

Om du använder Windows-terminaler kommer du antagligen se en massa trafik över rdp för wts (Windows Terminal Server) och även Independent Computing Architecture, ICA, för citrix-servrar på ditt nätverk. Dessa är krypteringsprotokoll som för det mesta använder tls, men de kommer sannolikt att kommunicera över andra tcp-portar och uppvisa andra skillnader. Din organisation bör ha kontroll över ändpunkterna och ha möjlighet att inspektera aktiviteten på dem.

På den lite mer skumma sidan finns det upd-baserade Quick UDP Internet Connections, Quic, som är framtaget som en mindre fördröjningsskapande variant av tls. Quic finns med i standarden http/3, men det har begränsade användningsområden då det kör över udp. Brandväggar brukar i allmänhet stoppa udp för inkommande trafik. Eftersom Quic är relativt nytt är risken fortfarande liten att du kommer se denna typ av trafik.

Bortom skumt finner du säkerhetsprotokollet och proxy-nätverket Tor, favoritprotokollet på den så kallade mörka webben. Tor använder flera lager av kryptering och trafiken bollas runt mellan olika reläer innan den släpps ut via en slumpmässigt valt utgångspunkt. Tor bör blockeras om du inte har en bra anledning att använda det för extra starkt integritetsskydd.

Fördelarna med TLS är för bra för att inte vara utan dem, men krypteringen gör det svårare att upprätthålla kontrollen över innehållet i trafiken. Alternativet, att inte kryptera, är dock avsevärt sämre. Vare sig du använder metadata eller inspekterar ändpunkter finns det fortfarande många metoder och verktyg du kan använda för att skydda ditt nätverk och dina användare.

Läs också:
8.8.8.8 – Nu börjar Google med DNS över TLS
Webbens viktigaste säkerhetsprotokoll uppgraderat – här är nyheterna i TLS 1.3