Ersätta osäkra protokoll: Telnet kontra SSH, FTP kontra SFTP

Många grundläggande internetprotokoll utformades under 1970- och 1980-talen, när säkerhet inte var en huvudfråga. Klartextprotokoll överför alla data – inklusive användarnamn, lösenord och känslig information – i klartext över nätverket. Alla enheter i samma nätverkssegment, eller alla system som paketen passerar, kan fånga upp och läsa denna trafik med fritt tillgängliga verktyg som Wireshark. I miljöer med nätverksswitchar (som normalt isolerar trafik mellan portar) kan ARP-spoofing omdirigera trafiken till angriparens system, vilket gör klartextprotokoll farliga även i ”interna” nätverk.

Telnet (TCP-port 23) ger fjärråtkomst till kommandoraden på system men överför allt i klartext. Det har ingen inbyggd autentisering utöver användarnamn och lösenord, som skickas okrypterade. SSH (Secure Shell) (TCP-port 22) ersätter Telnet med en krypterad och autentiserad kanal. SSH använder asymmetriskt nyckelutbyte för att upprätta en sessionsnyckel och krypterar sedan all efterföljande kommunikation med symmetrisk kryptering. SSH autentiserar även servern (vilket förhindrar att en server utger sig för att vara en annan) och stöder autentisering med offentlig nyckel (lösenordsfri men säkrare än lösenord) utöver lösenordsautentisering.

SSH:s säkerhet bygger på en robust process för nyckelutbyte. Vid anslutning verifierar klienten serverns värdnyckel mot en lokalt lagrad kopia – detta förhindrar att en server utger sig för att vara en annan. Om värdnyckeln ändras oväntat varnar SSH användaren, vilket är ett vanligt tecken på en man-in-the-middle-attack. När servern har verifierats kan klientautentisering använda: lösenord (krypteras under överföringen men är känsliga för brute force), offentlig nyckel (klienten bevisar att den har den privata nyckeln; betydligt starkare) eller keyboard-interactive (stöder MFA). Organisationer bör kräva nyckelbaserad autentisering och inaktivera lösenordsautentisering på internetanslutna SSH-tjänster.

FTP (File Transfer Protocol) (TCP-portarna 20/21) överför filer i klartext – autentiseringsuppgifter, kommandon och fildata exponeras. FTP använder dessutom en separat datakanal (passivt eller aktivt läge), vilket gör brandväggsregler mer komplicerade. SFTP (SSH File Transfer Protocol) tunnlar filöverföringen över SSH på port 22 – det är helt skilt från FTP och har bara ett liknande namn. FTPS (FTP Secure) lägger till TLS-kryptering i det ursprungliga FTP-protokollet. SFTP föredras vanligtvis eftersom det använder en enda port och ärver SSH:s autentisering och kryptering. FTP bör inaktiveras på alla produktionssystem.

HTTP (TCP-port 80) överför webbinnehåll, inklusive formulärdata, sessionscookies och autentiseringstoken, i klartext. HTTPS (TCP-port 443) kapslar in HTTP i TLS och tillhandahåller kryptering, serverautentisering och dataintegritet. Organisationer bör kräva HTTPS överallt: omdirigera all HTTP-trafik till HTTPS (301-omdirigering), implementera HSTS för att förhindra att webbläsare ansluter via HTTP och konfigurera cookieflaggorna secure och HttpOnly för att förhindra att sessionstoken stjäls via HTTP eller JavaScript. Moderna webbläsare markerar HTTP-webbplatser som ”Inte säker” – HTTPS är nu den förväntade grundnivån för alla webbtjänster.

SNMP (Simple Network Management Protocol) hanterar nätverksenheter och servrar. SNMPv1 och v2c använder community-strängar (i praktiken delade lösenord) som skickas i klartext – community-strängar som ”public” (läsning) och ”private” (skrivning) är standardvärden som angripare känner till. En angripare som fångar upp SNMP-trafik får reda på community-strängen och kan läsa enhetskonfigurationer eller ändra enhetsinställningar. SNMPv3 lägger till autentisering (HMAC-MD5 eller HMAC-SHA) och kryptering (AES) med användarspecifika autentiseringsuppgifter, vilket gör det till den enda versionen som är lämplig för produktionsmiljöer. SNMPv1/v2c bör inaktiveras.

LDAP (Lightweight Directory Access Protocol) (TCP-port 389) autentiserar mot och skickar frågor till katalogtjänster (Active Directory, OpenLDAP) i klartext som standard, vilket exponerar autentiseringsuppgifter och katalogdata. LDAPS (LDAP over SSL/TLS, TCP-port 636) krypterar anslutningen med hjälp av ett certifikat. StartTLS är ett alternativ som uppgraderar en befintlig LDAP-anslutning till TLS via samma port 389. Både LDAPS och StartTLS tillhandahåller kryptering, men LDAPS är vanligtvis enklare och mer tillförlitligt. Organisationer bör konfigurera alla LDAP-användande program till att använda LDAPS och blockera LDAP i klartext på port 389 i brandväggen.

Äldre e-postklienter hämtar e-post med POP3 (port 110) och IMAP (port 143) i klartext. Krypterade alternativ är: POP3S (port 995, TLS) och IMAPS (port 993, TLS). Moderna e-postplattformar (Exchange Online, Google Workspace) kräver TLS för alla klientanslutningar och stöder tokenbaserad autentisering med OAuth 2.0 i stället för lösenord. Organisationer bör inaktivera grundläggande autentisering för e-postprotokoll – krav på modern autentisering (OAuth 2.0 + MFA) förhindrar credential stuffing-attacker som utnyttjar autentiseringsmekanismerna i äldre e-postprotokoll, vilka skickar uppgifter i klartext.

Att ersätta osäkra protokoll kräver mer än att bara aktivera den säkra versionen – den osäkra versionen måste aktivt inaktiveras. Steg: granska befintlig protokollanvändning (Nmap-skanningar, brandväggsloggar), migrera program och konfigurationer till det säkra protokollet, testa noggrant (företagsprogram kan sluta fungera) och blockera sedan det osäkra protokollet i brandväggen och på värddatorn. Vanliga fallgropar: äldre skrivare och inbäddade enheter stöder ofta endast FTP eller SNMPv2, och äldre industriella system kan vara beroende av Telnet. Dessa kräver nätverksisolering eller att leverantören ersätter dem, snarare än en enkel protokolluppgradering.

RDP (Remote Desktop Protocol) (port 3389) används i stor utsträckning för fjärradministration av Windows och är ett viktigt angreppsmål. Osäkra RDP-konfigurationer omfattar att exponera port 3389 mot internet, använda enbart lösenordsautentisering och inaktivera NLA. Skydda RDP: aktivera Network Level Authentication (NLA), som autentiserar innan den fullständiga sessionen öppnas (och blockerar oautentiserade anslutningar), kräv TLS 1.2+ för alla RDP-sessioner, placera RDP bakom en VPN eller RDP-gateway i stället för att exponera det mot internet och tillämpa kontolåsning för att förhindra brute force. Många ransomwarekampanjer får sin första åtkomst via exponerad och bristfälligt säkrad RDP.

Att migrera bort från osäkra protokoll i produktionsmiljöer kräver noggrann planering för att undvika störningar i verksamheten. Ett stegvis tillvägagångssätt: Fas 1 – Upptäck: kör Nmap-skanningar och granska brandväggsloggar för att identifiera all användning av klartextprotokoll. Fas 2 – Aktivera säkra alternativ: konfigurera SSH, SFTP och HTTPS parallellt med de befintliga osäkra tjänsterna. Fas 3 – Migrera användare: uppdatera skript, program, övervakningsverktyg och användararbetsflöden så att de använder det säkra protokollet. Fas 4 – Inaktivera och blockera: inaktivera den osäkra tjänsten på varje värd och blockera porten i brandväggen. Testning i varje fas förhindrar driftstopp i produktionen.

I den här lektionen har ni lärt er att klartextprotokoll (Telnet, FTP, HTTP, SNMPv1/v2c, LDAP) exponerar inloggningsuppgifter och data för avlyssning i nätverket och måste ersättas, att säkra ersättare (SSH, SFTP, HTTPS, SNMPv3, LDAPS) använder TLS- eller SSH-kryptering för att skydda samma funktionalitet, samt att ersättning av protokoll kräver att den osäkra versionen inaktiveras på brandväggs- och värdnivå efter en granskning av beroenden till äldre system. Nästa avsnitt handlar om TLS-versioner, chiffersviter och perfekt framåtsekretess.