Erstatning av usikre protokoller: Telnet kontra SSH, FTP kontra SFTP
Forstå hvorfor klartekstprotokoller som Telnet, FTP og HTTP eksponerer påloggingsopplysninger, og hvordan de krypterte erstatningene (SSH, SFTP, HTTPS) løser disse problemene.
Erstatning av usikre protokoller: Telnet kontra SSH, FTP kontra SFTP er en gratis leksjon i Security+ Academy på CoddyKit. Dette er leksjon 1 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Security+ Academy, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Security+ Academy inneholder totalt 4 leksjoner.
Problemet med klartekstprotokoller
Mange grunnleggende internettprotokoller ble utviklet på 1970- og 1980-tallet, da sikkerhet ikke var en hovedprioritet. Klartekstprotokoller overfører alle data – inkludert brukernavn, passord og sensitiv informasjon – i klartekst over nettverket. Alle enheter på det samme nettverkssegmentet, eller alle systemer pakkene passerer gjennom, kan fange opp og lese denne trafikken med fritt tilgjengelige verktøy som Wireshark. I miljøer med nettverkssvitsjer (som normalt isolerer trafikk mellom porter) kan ARP-spoofing omdirigere trafikken til angriperens system. Dermed er klartekstprotokoller farlige selv på «interne» nettverk.
# What an attacker sees on the wire with Telnet
# (captured via Wireshark or tcpdump)
tcpdump -i eth0 -A port 23
# Sample Telnet capture output:
..login: admin..
..password: S3cr3tPa$$...
..$ ls -la /etc/passwd..
# Every keystroke is visible in plaintext
# Credentials, commands, and file contents - all exposedTelnet kontra SSH
Telnet (TCP-port 23) gir ekstern tilgang til kommandolinjen på systemer, men overfører alt i klartekst. Protokollen har ingen innebygd autentisering utover brukernavn og passord, som sendes ukryptert. SSH (Secure Shell) (TCP-port 22) erstatter Telnet med en kryptert og autentisert kanal. SSH bruker asymmetrisk nøkkelutveksling til å opprette en øktnøkkel, og krypterer deretter all videre kommunikasjon med symmetrisk kryptering. SSH autentiserer også serveren (slik at serverimitasjon forhindres) og støtter autentisering med offentlig nøkkel (passordfri, men sikrere enn passord) i tillegg til passordautentisering.
# SSH connection (encrypted, server authenticated)
ssh admin@192.168.1.10
# SSH key-based authentication (no password)
ssh -i ~/.ssh/id_rsa admin@192.168.1.10
# Generate SSH key pair
ssh-keygen -t ed25519 -C 'admin@company.com'
# Copy public key to server
ssh-copy-id -i ~/.ssh/id_rsa.pub admin@192.168.1.10
# Disable Telnet on network devices (Cisco IOS)
no service telnet
line vty 0 4
transport input ssh
login localSSH-nøkkelutveksling og autentisering
Sikkerheten i SSH er avhengig av en robust nøkkelutvekslingsprosess. Ved tilkobling kontrollerer klienten serverens vertsnøkkel mot en lokalt lagret kopi – dette hindrer serverimitasjon. Hvis vertsnøkkelen endres uventet, advarer SSH brukeren. Dette er et vanlig tegn på et man-in-the-middle-angrep. Etter at serveren er verifisert, kan klienten autentiseres med: passord (kryptert under overføring, men utsatt for brute force), offentlig nøkkel (klienten beviser at den har den private nøkkelen; betydelig sterkere) eller keyboard-interactive (støtter MFA). Organisasjoner bør håndheve nøkkelbasert autentisering og deaktivere passordautentisering på internettilgjengelige SSH-tjenester.
# Harden SSH server configuration
# /etc/ssh/sshd_config
Port 22
PermitRootLogin no
PasswordAuthentication no # Require key auth only
ChallengeResponseAuthentication no
MaxAuthTries 3
AllowUsers admin deploy
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
ClientAliveInterval 300 # Disconnect idle sessions
ClientAliveCountMax 0
# Restart SSH after changes
systemctl restart sshdFTP kontra SFTP og FTPS
FTP (File Transfer Protocol) (TCP-portene 20/21) overfører filer i klartekst – påloggingsinformasjon, kommandoer og fildata er eksponert. FTP bruker også en separat datakanal (passiv eller aktiv modus), noe som gjør brannmurreglene mer kompliserte. SFTP (SSH File Transfer Protocol) sender filoverføringen gjennom SSH på port 22 – det er en helt annen protokoll enn FTP, selv om navnene ligner. FTPS (FTP Secure) legger TLS-kryptering til den opprinnelige FTP-protokollen. SFTP foretrekkes vanligvis fordi den bruker én port og arver SSHs autentisering og kryptering. FTP bør deaktiveres på alle produksjonssystemer.
# SFTP usage (over SSH, single connection)
sftp admin@fileserver.company.com
sftp> put localfile.zip /uploads/
sftp> get /reports/monthly.pdf .
sftp> ls /uploads/
sftp> exit
# Automated SFTP transfer with key auth
sftp -i ~/.ssh/id_rsa admin@fileserver.company.com <<EOF
put /tmp/report.csv /incoming/
EOF
# Disable FTP on Linux (remove vsftpd)
apt purge vsftpd
# Verify no FTP listener:
ss -tlnp | grep ':21'HTTP kontra HTTPS
HTTP (TCP-port 80) overfører nettinnhold, inkludert skjemadata, øktinformasjonskapsler og autentiseringstokener, i klartekst. HTTPS (TCP-port 443) legger HTTP inn i TLS og gir kryptering, serverautentisering og dataintegritet. Organisasjoner bør håndheve HTTPS overalt: Omdiriger all HTTP-trafikk til HTTPS (301-viderekobling), implementer HSTS for å hindre nettlesere i å koble til via HTTP, og konfigurer Secure- og HttpOnly-flagg for informasjonskapsler for å hindre at økttokener stjeles via HTTP eller JavaScript. Moderne nettlesere merker HTTP-nettsteder som «Ikke sikre» – HTTPS er nå en grunnleggende forventning for alle nettjenester.
# nginx: force HTTPS redirect
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
ssl_certificate /etc/ssl/example.crt;
ssl_certificate_key /etc/ssl/example.key;
add_header Strict-Transport-Security
'max-age=31536000; includeSubDomains; preload';
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
}SNMP v1/v2 kontra SNMPv3
SNMP (Simple Network Management Protocol) administrerer nettverksenheter og servere. SNMPv1 og v2c bruker community-strenger (i praksis delte passord) som sendes i klartekst. Community-strenger som «public» (lese) og «private» (skrive) er standardverdier som angripere kjenner. En angriper som fanger opp SNMP-trafikk, får vite community-strengen og kan lese enhetskonfigurasjoner eller endre enhetsinnstillinger. SNMPv3 legger til autentisering (HMAC-MD5 eller HMAC-SHA) og kryptering (AES) med legitimasjon per bruker, noe som gjør den til den eneste versjonen som egner seg for produksjonsmiljøer. SNMPv1/v2c bør deaktiveres.
# SNMPv3 configuration (Cisco IOS)
snmp-server group MYGROUP v3 priv
snmp-server user MONITORUSER MYGROUP v3 \
auth sha MyAuthP@ss priv aes 128 MyPrivP@ss
# SNMPv3 query from monitoring server
snmpwalk -v3 -l authPriv \
-u MONITORUSER \
-a SHA -A MyAuthP@ss \
-x AES -X MyPrivP@ss \
192.168.1.1 sysDescr
# Disable SNMPv1/v2c:
no snmp-server community public ro
no snmp-server community private rwLDAP kontra LDAPS
LDAP (Lightweight Directory Access Protocol) (TCP-port 389) autentiserer mot og gjør oppslag i katalogtjenester (Active Directory, OpenLDAP) som standard i klartekst, slik at legitimasjon og katalogdata eksponeres. LDAPS (LDAP over SSL/TLS, TCP-port 636) krypterer forbindelsen ved hjelp av et sertifikat. StartTLS er et alternativ som oppgraderer en eksisterende LDAP-forbindelse til TLS ved hjelp av den samme porten, 389. Både LDAPS og StartTLS gir kryptering, men LDAPS er vanligvis enklere og mer pålitelig. Organisasjoner bør konfigurere alle applikasjoner som bruker LDAP, til å benytte LDAPS og blokkere ukryptert LDAP på port 389 i brannmuren.
POP3/IMAP kontra kryptert e-posthenting
Eldre e-postklienter henter e-post ved hjelp av POP3 (port 110) og IMAP (port 143) i klartekst. Krypterte alternativer er POP3S (port 995, TLS) og IMAPS (port 993, TLS). Moderne e-postplattformer (Exchange Online, Google Workspace) håndhever TLS for alle klienttilkoblinger og støtter tokenbasert OAuth 2.0-autentisering i stedet for passord. Organisasjoner bør deaktivere grunnleggende autentisering i e-postprotokoller – krav om moderne autentisering (OAuth 2.0 + MFA) hindrer credential stuffing-angrep som utnytter klartekstmekanismene for autentisering i eldre e-postprotokoller.
# Protocol port reference card
Protocol Insecure Port Secure Port Replacement
--------- ------------ ---------- -----------
Telnet 23 22 SSH
FTP 20/21 22 SFTP
HTTP 80 443 HTTPS
SMTP 25 587/465 SMTPS
POP3 110 995 POP3S
IMAP 143 993 IMAPS
LDAP 389 636 LDAPS
SNMP 161/162 161/162 SNMPv3
RDP 3389 3389 RDP+NLA+TLSUtskifting av protokoller i praksis
Å erstatte usikre protokoller krever mer enn å bare aktivere den sikre versjonen – den usikre versjonen må deaktiveres aktivt. Fremgangsmåte: kartlegg eksisterende protokollbruk (Nmap-skanninger, brannmurlogger), migrer applikasjoner og konfigurasjoner til den sikre protokollen, test grundig (forretningsapplikasjoner kan slutte å fungere), og blokker deretter den usikre protokollen i brannmuren og på verten. Vanlige fallgruver: Eldre skrivere og innebygde enheter støtter ofte bare FTP eller SNMPv2, og eldre industrielle systemer kan være avhengige av Telnet. Disse krever nettverksisolering eller utskifting med en løsning fra leverandøren, ikke bare en enkel protokolloppgradering.
# Audit for insecure protocol usage
# Nmap: find all Telnet listeners on network
nmap -p 23 10.0.0.0/24 --open -sV
# Find FTP listeners
nmap -p 21 10.0.0.0/24 --open
# Find HTTP (not HTTPS) web services
nmap -p 80 --open 10.0.0.0/24
# Check for SNMPv1/v2c community strings
nmap -sU -p 161 --script snmp-info 10.0.0.0/24
# Block Telnet at firewall after migration
iptables -A FORWARD -p tcp --dport 23 -j DROP
iptables -A INPUT -p tcp --dport 23 -j DROPSikkerhet for Remote Desktop Protocol
RDP (Remote Desktop Protocol) (port 3389) brukes i stor utstrekning til ekstern Windows-administrasjon og er et viktig angrepsmål. Usikre RDP-konfigurasjoner omfatter å eksponere port 3389 mot internett, bruke autentisering med bare passord og deaktivere NLA. Herding av RDP: Aktiver Network Level Authentication (NLA), som autentiserer før hele økten åpnes og dermed blokkerer uautentiserte tilkoblinger; krev TLS 1.2+ for alle RDP-økter; plasser RDP bak en VPN eller RDP-gateway i stedet for å eksponere den mot internett; og håndhev kontosperring for å hindre brute force. Mange løsepengevirusangrep får først tilgang gjennom eksponert og dårlig sikret RDP.
Utfasing av usikre protokoller i flere trinn
Overgangen fra usikre protokoller i produksjonsmiljøer krever nøye planlegging for å unngå driftsforstyrrelser. En trinnvis fremgangsmåte er: Trinn 1 – Kartlegg: Kjør Nmap-skanninger og gjennomgå brannmurlogger for å identifisere all bruk av klartekstprotokoller. Trinn 2 – Aktiver sikre alternativer: Konfigurer SSH, SFTP og HTTPS parallelt med de eksisterende usikre tjenestene. Trinn 3 – Migrer brukerne: Oppdater skript, applikasjoner, overvåkingsverktøy og arbeidsflyter slik at de bruker den sikre protokollen. Trinn 4 – Deaktiver og blokker: Deaktiver den usikre tjenesten på hver vert og blokker porten i brannmuren. Testing i hvert trinn hindrer produksjonsavbrudd.
# Phase 4: Disable and block Telnet permanently
# Disable Telnet service on Linux
systemctl stop telnet.socket
systemctl disable telnet.socket
# Block Telnet at iptables
iptables -A INPUT -p tcp --dport 23 -j DROP
iptables -A OUTPUT -p tcp --dport 23 -j DROP
# Save rules
iptables-save > /etc/iptables/rules.v4
# Block at network firewall (Cisco ASA)
access-list OUTSIDE_IN deny tcp any any eq 23
# Verify: should timeout / connection refused
nc -zv 192.168.1.10 23Hurtigsjekk
Test forståelsen av CompTIA Security+-konseptene (SY0-701) fra denne leksjonen.
Oppsummering av leksjonen
I denne leksjonen har du lært at klartekstprotokoller (Telnet, FTP, HTTP, SNMPv1/v2c, LDAP) eksponerer påloggingsinformasjon og data for avlytting på nettverket og må erstattes, at sikre erstatninger (SSH, SFTP, HTTPS, SNMPv3, LDAPS) bruker TLS- eller SSH-kryptering for å beskytte den samme funksjonaliteten, og at bytte av protokoller krever at den usikre versjonen deaktiveres på brannmur- og vertsnivå etter at avhengigheter til eldre systemer er kartlagt. Neste tema er TLS-versjoner, cipher suites og perfekt videresendingshemmelighold.
Lær deg Security+ Academy med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 30
- Leksjoner
- 120
Ofte stilte spørsmål
Er leksjonen «Erstatning av usikre protokoller: Telnet kontra SSH, FTP kontra SFTP» gratis?
Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Security+ Academy, inkludert «Erstatning av usikre protokoller: Telnet kontra SSH, FTP kontra SFTP», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Security+ Academy inneholder totalt 4 leksjoner.
Hva lærer jeg i «Erstatning av usikre protokoller: Telnet kontra SSH, FTP kontra SFTP»?
Forstå hvorfor klartekstprotokoller som Telnet, FTP og HTTP eksponerer påloggingsopplysninger, og hvordan de krypterte erstatningene (SSH, SFTP, HTTPS) løser disse problemene. Du øver på Security+ Academy med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Security+ Academy?
Ingen tidligere erfaring er nødvendig. Security+ Academy på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 1 av 4.
Hvor lang tid tar leksjonen «Erstatning av usikre protokoller: Telnet kontra SSH, FTP kontra SFTP»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Security+ Academy-leksjonen?
Ja. Alle Security+ Academy-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Erstatning av usikre protokoller: Telnet kontra SSH, FTP kontra SFTP
- TLS-versjoner, chifferpakker og perfekt fremoverhemmelighold
- Sikker DNS: DNSSEC og DNS over HTTPS (DoH)
- IPsec, VPN-protokoller og sikkerhet for fjerntilgang