Vissa dörrar går inte att stänga

De flesta vägar in börjar med något någon öppnade. En port, en fjärråtkomst, ett administrationsgränssnitt som blev nåbart för att någon skulle kunna sköta driften hemifrån. Någon löste ett praktiskt problem en gång, och sedan blev det kvar.

Men inte alla. Vissa system är nåbara utifrån för att det är hela deras uppgift. En e-postserver tar emot meddelanden från vem som helst som vill skicka till er. Det är inte en inställning någon har valt. Det är funktionen.

Den här veckan blev skillnaden mellan de två sorterna ovanligt tydlig, och det var tillverkaren själv som skrev ut den.

Vad som hände

Den 14 september kom en säkerhetsuppdatering från Cisco för en kritisk brist i Secure Email Gateway, deras produkt för att ta emot och filtrera inkommande e-post. Samma dag lade den amerikanska myndigheten CISA in bristen i sin katalog över kända utnyttjade sårbarheter — Ciscos eget säkerhetsteam hade då redan sett att den användes i angrepp.

Bristen kräver ingen inloggning, ingen administratörsbehörighet och ingen användare som klickar på något. Den utlöses av att ett meddelande skickas genom servern. Den som lyckas kan köra kommandon med högsta behörighet på det underliggande operativsystemet.

Två dagar senare, den 16 september, kom nästa: en brist i Cisco Identity Services Engine, systemet som avgör vilken enhet och vilken användare som släpps in på vilket nät. Även den användes i angrepp innan uppdateringen fanns, även den kräver ingen inloggning, och även den ger högsta behörighet.

CERT-SE tog upp e-postservern dagen efter Cisco och rekommenderade att uppgradera till säker version så snart som möjligt, undersöka egna system och i övrigt följa leverantörens anvisningar.

Poängen är inte Cisco

Alla större tillverkare har både system som avgör åtkomst och system som tar emot e-post, och båda sorterna har stått i tur förr.

De två bristerna hör hemma i olika kategorier, och därför skiljer sig åtgärden åt.

Identity Services Engine går att begränsa. Ett system som beslutar om åtkomst behöver inte svara mot hela internet — det behöver svara mot dem som administrerar det. Cisco skriver det själv: ingen tillfällig lösning tar bort bristen, men “use infrastructure access control lists (iACLs) to allow only required management and control plane traffic that is destined to the affected device” hindrar att den utnyttjas utifrån. Bristen finns kvar i koden oavsett vad man gör med nätet. Det som går att ändra på en eftermiddag är vem som kan komma åt den. Frågan att ställa om den sortens system är därför den vanliga: varför är det här nåbart utifrån, och för vem behöver det vara det?

E-postservern går inte att begränsa på samma sätt. Den kan inte läggas bakom fjärråtkomsten, för då tar den inte emot någon e-post. Ingen brandväggsregel löser det och ingen åtkomstlista hjälper, för den ska ta emot trafik från avsändare ni inte känner till. Samma sak gäller webbplatsen, DNS och varje portal som är till för att allmänheten ska kunna använda den.

För den kategorin återstår bara två kontroller som betyder något: vilken version som svarar, och hur snabbt den byts. Det är inte en särskilt inspirerande insikt. Men det är den som gäller, och den blir fel om man behandlar alla system som svarar mot internet som vore de av det första slaget.

Vad vi ser i kartläggningen

Det här är ovanligt tacksamt att titta på utifrån, av ett skäl värt att vara tydlig med: en åtkomstbegränsning är en kontroll som syns, inte en version som ska tolkas. Om ett administrationsgränssnitt svarar oss från internet, då omfattar begränsningen inte oss. Det är en observation om vad som är nåbart, och den kräver varken inloggning eller att vi rör något.

E-post och webb är lika enkla att hitta, och av samma skäl: en MX-post måste vara publik, eftersom det är så avsändare vet vart e-posten ska. Det finns ingen version av det systemet som är gömd.

Men gränsen åt andra hållet ska sägas rakt ut, för den är viktigare än den låter. Att något svarar oss är ett belägg. Att något inte svarade oss är inget belägg alls — en åtkomstlista som stänger ute oss kan fortfarande släppa in ett helt adressintervall, en leverantörs hela nät eller en molntjänst. Vi kan visa att dörren står öppen. Vi kan inte visa att den är rätt låst.

Vi börjar utifrån, utan att röra era system. Aktiva kontroller görs efter överenskommelse och aldrig mot driftmiljö. Det vi kan belägga är att en tjänst är nåbar och kör en berörd version, inte att den är bekräftat sårbar. Och för just en e-postserver: vi provar den inte genom att skicka något till den.

Vad ni gör åt det

• Dela listan över det som är nåbart från internet i två. De system där ni kan styra vem som kommer åt dem, och de som måste svara vem som helst. Åtgärderna är olika, och prioriteringen blir fel om de blandas.
• Behandla åtkomstlistan som ett påstående med bäst-före-datum. Den var rätt den dag den skrevs. Sedan kom ett nytt kontor, en ny leverantör, en ny molntjänst och en tillfällig öppning under en incident som aldrig stängdes. Kontrollen slutar gälla tyst.
• Följ läget över tid. Båda bristerna ovan användes i angrepp innan det fanns någon uppdatering att installera. Ingen genomgång i somras hade fångat dem. Det som fångar dem är att någon tittar igen.

Själva arbetet, att uppdatera enheten eller sätta åtkomstlistan på plats, ligger hos den som driftar utrustningen, ofta en leverantör. Vi visar var dörren sitter och att den svarar.

Så tänker vi

Två kritiska brister hos samma tillverkare på tre dagar säger mindre om tillverkaren än om frågan. ”Vad har vi öppet mot internet” är två frågor, inte en. En del av svaret går att göra något åt genom att begränsa vem som når fram. Resten går bara att hålla aktuellt.

Vill ni veta vad som svarar mot internet hos er idag? Hör av er.

Källor: Cisco, Cisco Identity Services Engine Authentication Bypass Vulnerability (16 sep 2026); CISA, Known Exploited Vulnerabilities Catalog (CVE-2026-76461 upptagen 14 september 2026, CVE-2026-76460 upptagen 16 september 2026); CERT-SE, Kritisk sårbarhet i Cisco Secure Email Gateway utnyttjas aktivt (15 sep 2026).