CURSUL 08

Securizarea rețelei

Durată: 115 min de predare Nivel: licență, anul III - fără cunoștințe prealabile Disciplină: Rețele Locale Laborator asociat: Laboratorul 07 PDF: descarcă suportul EN English version

Până acum am construit o rețea care funcționează. Cursul acesta pornește de la observația neplăcută că Internetul nu este un loc prietenos, și adaugă trei lucruri care lipsesc. Întâi nivelul transport - pentru că aproape toate atacurile și aproape toate apărările se poartă acolo, la nivelul porturilor și al flag-urilor TCP. Apoi filtrarea cu iptables, adică ce se întâmplă când firewall-ul nu mai e un ruter Cisco, ci o mașină Linux. Și, la final, criptografia din spatele unei simple sesiuni SSH: cum reușesc două calculatoare care nu s-au întâlnit niciodată să se pună de acord asupra unei chei secrete, în văzul tuturor.

1Recapitulare5 min

Ce trebuie să aveți în minte
  • Un ACL este o listă ordonată, citită până la prima potrivire.
  • La final există un deny any invizibil.
  • Lista trebuie aplicată pe o interfață și o direcție ca să existe.
  • Listele extinse pot filtra după protocol și port - adică după nivelul 4.
  • Un ACL este fără stare: nu ține minte că am întrebat noi primii.

Ultimul punct este exact locul unde ne oprisem, nemulțumiți. Astăzi vedem ce înseamnă un echipament care ține minte sesiunile - dar, ca să înțelegem ce anume ține minte, trebuie mai întâi să înțelegem ce este o sesiune.

Rezultate ale învățării

  • Să explicați ce adaugă nivelul transport peste IP și de ce există porturi
  • Să alegeți între TCP și UDP pentru o aplicație dată, cu argumente
  • Să citiți o strângere de mână în trei pași și să spuneți ce face fiecare flag
  • Să recunoașteți cele trei familii de atacuri și să explicați cum funcționează un SYN flood
  • Să scrieți reguli iptables corecte, pe lanțul potrivit
  • Să construiți un firewall complet, cu politică implicită DROP
  • Să explicați ce garantează, separat, autentificarea, confidențialitatea și integritatea
  • Să descrieți schimbul Diffie-Hellman și să spuneți ce nu rezolvă el

2Nivelul transport: de ce există porturi10 min

Problema pe care o rezolvă nivelul 4

Până acum, un pachet ajunge la calculatorul potrivit. Adresa IP face exact atât: identifică mașina.

Dar pe mașina aceea rulează, în același timp, un browser, un client de mail, un joc și trei actualizări în fundal. Când sosește un pachet, sistemul de operare trebuie să știe cărei aplicații îi aparține. Adresa IP nu spune nimic despre asta.

De aceea nivelul 4 adaugă încă un număr: portul. Fiecare nivel introduce un nou tip de adresă - nivelul 2 adresa MAC, nivelul 3 adresa IP, nivelul 4 portul. Fără porturi, un calculator ar putea rula o singură aplicație de rețea la un moment dat.

Socket
Perechea adresă IP + număr de port, scrisă 192.168.1.10:49152. O conexiune este identificată complet de patru numere: socketul sursă și socketul destinație. Două conexiuni pot avea aceeași destinație și aceeași adresă sursă, dar porturi sursă diferite - și de aceea puteți deschide zece file spre același site fără să se amestece.
Rol al nivelului transportCe înseamnăTCPUDP
Segmentareîmparte fluxul aplicației în bucăți care încap într-un pachetdada
Adresareidentifică aplicația prin numărul de portdada
Multiplexaremai multe aplicații pe aceeași adresă IPdada
Siguranța transmisieiretransmite ce s-a pierdut, reordonează ce a sosit anapodadanu
Controlul fluxuluiîmpiedică un emițător rapid să înece un receptor lentdanu
Inițierea conexiunilorstabilește o sesiune înainte de transferul propriu-zisdanu
UDP nu este „TCP stricat" Tabelul de mai sus enumeră ce poate face nivelul transport. UDP face doar primele trei - și o face deliberat. La un apel video, un pachet pierdut retransmis peste 200 de milisecunde este inutil: momentul lui a trecut. Mai bine lipsește. Uneori viteza contează mai mult decât garanțiile.
TCP - Transmission Control Protocol
  • Orientat pe conexiune: se stabilește o sesiune înainte de transfer
  • Sigur: datele ajung garantat și în ordine
  • Control de flux, de congestie și de eroare
  • Antet de minimum 20 de octeți
  • SSH, HTTP, SMTP, transfer de fișiere, baze de date
UDP - User Datagram Protocol
  • Fără conexiune: se trimite și gata
  • Nesigur: segmentele se pot pierde sau sosi în altă ordine
  • Fără control de flux sau congestie
  • Antet de 8 octeți - sursă, destinație, lungime, sumă de control
  • DNS, DHCP, VoIP, IPTV, jocuri, streaming

Intervalele de porturi

IntervalDenumireCine le folosește
0 – 1023well-knownservicii standard: 22 SSH, 25 SMTP, 53 DNS, 80 HTTP, 443 HTTPS. Pe Linux, doar procesele privilegiate pot asculta aici.
1024 – 49151înregistrateaplicații cunoscute, dar neoficiale: 3306 MySQL, 3389 RDP, 8080 proxy HTTP
49152 – 65535dinamice / efemereporturile sursă alese automat de sistemul de operare la fiecare conexiune nouă
Consecința pentru filtrare Când stația dumneavoastră deschide o pagină web, conexiunea arată așa: 192.168.1.10:51423 → 93.184.216.34:80. Portul destinație este cunoscut (80), dar portul sursă este imprevizibil.

De aceea o regulă de firewall pentru traficul de întoarcere nu poate specifica portul destinație - el se schimbă la fiecare conexiune. Trebuie fie established, fie urmărirea sesiunilor. Aceasta e, în concret, limitarea de care ne-am lovit la finalul cursului trecut.
Terminal: porturi și socketuri

Priviți a doua comandă. Cele trei conexiuni au aceeași adresă locală, dar porturi sursă diferite - și tocmai asta le ține separate. Iar ultima linie e o conexiune în celălalt sens: cineva e conectat prin SSH la mașina noastră, deci portul local este 22, cel binecunoscut.

3Antetul TCP, câmp cu câmp9 min

Aproape toate mecanismele discutate mai jos - retransmisia, controlul de flux, strângerea de mână, atacul SYN flood, opțiunea established - sunt scrise, la propriu, în acest antet de 20 de octeți.

Antetul TCP - apăsați pe câmpuri
FlagRolUnde îl întâlniți
SYNcere sincronizarea numerelor de secvență - deschide conexiuneaSYN flood, --syn în iptables
ACKconfirmă datele primite; activează câmpul de confirmareestablished în ACL-uri
FINanunță că emițătorul a terminat de transmisînchiderea normală
RSTînchide brutal conexiunea; răspunsul la un pachet nevalidREJECT în iptables

4Deschiderea și închiderea unei conexiuni11 min

O conexiune TCP se deschide printr-un schimb de trei segmente, în care fiecare capăt își comunică numărul de secvență inițial și îl confirmă pe al celuilalt. Se închide, în schimb, prin patru - și motivul acestei asimetrii spune ceva despre cum este gândit TCP.

Strângerea de mână în trei pași
clientserver SYN, seq = x SYN + ACK, seq = y, ack = x+1 ACK, seq = x+1, ack = y+1 conexiune stabilită - începe transferul
Fig. 1 - Cele trei segmente ale deschiderii unei conexiuni TCP, în forma clasică de diagramă temporală. Panta liniilor reprezintă timpul de propagare.
De ce numărul de secvență inițial este aleatoriu Dacă ar fi previzibil, un atacator care cunoaște adresele și porturile ar putea fabrica segmente care par să facă parte din conversație - fără să vadă traficul. Se numește TCP sequence prediction și a fost o vulnerabilitate reală în anii ’90, când multe sisteme porneau numerotarea de la o valoare crescută cu un pas fix.

5Cele trei familii de atacuri11 min

Orice rețea conectată la Internet este, permanent, ținta unor tentative automatizate. Nu e nevoie să fiți interesant: scanările sunt continue și oarbe. Atacurile se împart în trei familii, după scop.

FamilieScopExempleCe ajută
De recunoaștereaflarea a ce există și ce ruleazăping sweep, port scan, sniffing, interogări DNS și whoisfiltrarea ICMP, DROP în loc de REJECT
De blocare (DoS/DDoS)indisponibilizarea serviciuluiSYN flood, smurf, amplificare DNSlimitarea ratei, SYN cookies
De accesobținerea de drepturi nemeritatespargere de parole, buffer overflow, man-in-the-middleautentificare puternică, criptare
De ce DROP e mai bun decât REJECT în fața Internetului

REJECT aruncă pachetul și trimite un răspuns: „port închis". Politicos - și extrem de util pentru cel care scanează, pentru că îi confirmă că mașina există.

DROP aruncă pachetul tăcut. Scanerul nu primește nimic și trebuie să aștepte expirarea temporizatorului pentru fiecare port. O scanare care ar dura o secundă durează minute.

În interiorul rețelei, însă, REJECT este preferabil: aplicațiile proprii primesc o eroare imediată în loc să aștepte 30 de secunde degeaba.

Mecanismul atacului SYN flood

SYN flood, pas cu pas
Firewall
Una sau mai multe mașini al căror scop este prevenirea accesului neautorizat la o rețea. Controlează accesul la servicii atât dinspre exterior spre interior, cât și invers. Poate fi un dispozitiv dedicat, o funcție a unui ruter sau un program pe o stație.
TipPână la ce nivel se uităȚine minte sesiunile?Exemplu
Stateless3–4nu - fiecare pachet este judecat izolatACL-uri pe ruter
Stateful3–4, cu tabelă de conexiunidaiptables cu conntrack, Cisco ASA
De nivel aplicație (proxy)până la 7da, plus conținutulproxy HTTP, WAF

Un firewall nu rezolvă toate cele trei familii, dar taie eficient primele două: poate bloca porturile vulnerabile, poate opri inițierea conexiunilor din exterior, poate refuza răspunsul la ICMP echo, poate limita numărul de sesiuni pe jumătate deschise și poate opri broadcast-urile direcționate care fac posibil atacul smurf. Împotriva atacurilor de acces ajută mai puțin: acolo lucrează criptografia și autentificarea, din secțiunea 10.

6iptables: tabele și lanțuri12 min

iptables este utilitarul din spațiul utilizator care configurează Netfilter, cadrul de filtrare din nucleul Linux. Permite unei mașini Linux să filtreze pachete, să translateze adrese și să rescrie câmpuri - adică să fie, simultan, ruter și firewall.

Analogie Netfilter e ca o clădire cu mai multe puncte de control, dispuse pe traseul obligatoriu al oricărui vizitator. La fiecare punct de control există un teanc de instrucțiuni.

Lanțul este punctul de control - unde pe traseu. Tabela este tipul de instrucțiuni - ce fel de decizie se ia acolo: filtrare, translatare de adrese sau modificare. Un punct de control poate avea mai multe teancuri.
TabelăCe conține
filterregulile care decid ce trece și ce se aruncă; tabela implicită, folosită dacă nu scrieți -t
natregulile de translatare a adreselor - subiectul cursului 9
manglealterarea specializată a pachetelor: TTL, marcaje, ToS
rawexcepții de la urmărirea conexiunilor

Lanțurile sunt punctele din traseul unui pachet în care se aplică reguli. Cheia înțelegerii lui iptables este să știți prin ce lanțuri trece fiecare tip de pachet - și sunt doar trei tipuri.

pachetintrare PREROUTINGnat, mangle FORWARDfilter, mangle POSTROUTINGnat, mangle pachetieșire INPUTfilter, mangle proces localsshd, httpd… OUTPUTfilter, nat trafic care doar tranzitează mașina trafic destinat mașinii sau generat de ea
Fig. 2 - Traseul pachetelor prin lanțurile Netfilter. Un pachet care tranzitează mașina trece prin FORWARD; unul destinat ei trece prin INPUT; unul generat de ea trece prin OUTPUT.
Confuzia INPUT / FORWARD Este cea mai frecventă sursă de reguli care nu au niciun efect. Întrebarea de pus, de fiecare dată: cine este destinatarul din antetul IP?

Dacă destinatarul este chiar mașina Linux (o sesiune SSH către ea, o pagină servită de ea) → INPUT.
Dacă destinatarul este altcineva, iar mașina doar rutează → FORWARD.

O regulă pusă pe INPUT pentru trafic care tranzitează nu se va aplica niciodată - și nici nu veți primi vreo eroare.
Ce lanț folosiți?
Traseul unui pachet prin Netfilter

7Anatomia unei reguli iptables11 min

O regulă are întotdeauna două părți: un șablon - ce condiții trebuie să îndeplinească pachetul - și o țintă - ce se întâmplă cu el.

o regulă completă, descompusă
iptables -t filter -A INPUT -s 10.0.0.0/8 -p icmp -j DROP
#         └ tabela  └ op    └ lant  └────── conditii ─────┘ └ tinta
#
#  -t filter   tabela (implicita, se poate omite)
#  -A INPUT    adauga la finalul lantului INPUT
#  -s 10...    sursa: aici masca este NORMALA, nu wildcard!
#  -p icmp     protocolul
#  -j DROP     jump: ce se face cu pachetul
Atenție la mască La Cisco am folosit wildcard (0.0.0.255). În iptables se folosește notația CIDR normală (/24) sau masca clasică. Este una dintre puținele locuri unde trecerea de la un ecosistem la altul chiar produce greșeli tăcute.
OperațieFormă lungăCe face
-A--appendadaugă o regulă la finalul lanțului
-I--insertinserează la o poziție dată (implicit prima)
-D--deleteșterge o regulă
-L -n -v --line-numbers--listafișează regulile, cu contoare și numere de linie
-F--flushgolește lanțul
-P--policyschimbă politica implicită
CondițieCe verifică
-i eth0 / -o eth1interfața de intrare / de ieșire
-s / -dadresa sursă / destinație, în notație CIDR
-p tcp --dport 22protocolul și portul destinație
-p tcp --syndoar segmentele de inițiere a conexiunii
-m state --state ESTABLISHED,RELATEDstarea sesiunii, din tabela conntrack
-m limit --limit 25/srata de sosire - pentru apărarea anti-flood
! -s 10.0.0.0/8negarea oricărei condiții, cu semnul exclamării
ȚintăCe face
ACCEPTlasă pachetul să treacă; evaluarea lanțului se oprește
DROParuncă tăcut - expeditorul nu află nimic
REJECTaruncă și trimite un ICMP sau un RST TCP
LOGînregistrează în jurnalul de sistem și continuă evaluarea
LOG este singura țintă care nu oprește parcurgerea

Toate celelalte sunt terminale: odată aplicate, pachetul a primit un verdict și lanțul nu se mai citește. La fel ca la ACL-urile Cisco.

LOG nu decide nimic - doar notează și lasă pachetul să meargă mai departe prin listă. De aceea o regulă de jurnalizare se pune imediat deasupra celei de DROP pe care vrea să o documenteze, cu exact aceleași condiții.

Terminal: inspectarea unui firewall Linux

Priviți prima comandă. Coloana pkts este echivalentul exact al contorului de potriviri de la ACL-urile Cisco, și se folosește la fel: regula 4 din INPUT are 0 pachete, ceea ce înseamnă că nimeni nu a accesat încă serverul web - sau că o regulă de deasupra prinde deja traficul.

Regulile iptables nu supraviețuiesc repornirii Sunt ținute în memoria nucleului. Fără iptables-save (sau serviciul netfilter-persistent), la următorul boot mașina pornește cu lanțurile goale și politicile pe ACCEPT - adică fără firewall.

Partea bună: dacă v-ați blocat singuri, o repornire vă salvează. Partea proastă: dacă ați crezut că ați configurat un firewall, nu l-ați configurat.

8Politica implicită și un firewall complet10 min

Fiecare lanț predefinit are o politică - acțiunea aplicată pachetelor care nu s-au potrivit cu nicio regulă. Este echivalentul lui deny any implicit de la Cisco, cu o diferență importantă: aici este configurabilă, iar implicit este ACCEPT.

Politica ACCEPT - permisivă
  • „Permite tot ce nu e interzis explicit"
  • Trebuie să anticipați fiecare lucru rău
  • Orice serviciu pornit din greșeală e expus
  • Un port uitat rămâne deschis pentru totdeauna
Politica DROP - restrictivă
  • „Interzice tot ce nu e permis explicit"
  • Trebuie să enumerați ce vreți să meargă
  • Un serviciu nou nu merge până nu îl deschideți - și e bine așa
  • Singura abordare acceptabilă în fața Internetului
Ordinea comenzilor, la propriu Setați întâi regulile de ACCEPT și abia apoi politica DROP. Dacă faceți invers și lucrați prin SSH, prima comandă vă deconectează instantaneu de la mașină.

Lanțurile create de utilizator nu pot avea politică implicită - evaluarea lor se întoarce,, în lanțul apelant.
un firewall complet, pentru un ruter Linux
# 1. Curatam si pornim de la zero
iptables -F
iptables -X

# 2. Traficul pe interfata de bucla - mereu primul, altfel se strica servicii locale
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# 3. Regula care rezolva TOT traficul de intoarcere, dintr-o linie
iptables -A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# 4. Serviciile pe care le expunem noi
iptables -A INPUT -i eth1 -s 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# 5. LAN-ul are voie spre Internet
iptables -A FORWARD -i eth1 -o eth0 -s 192.168.1.0/24 -j ACCEPT

# 6. Jurnalizam ce urmeaza sa aruncam (LOG nu opreste parcurgerea)
iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "IPTABLES-DROP: "

# 7. ABIA ACUM politicile
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  ACCEPT

# 8. Salvam, altfel totul dispare la repornire
iptables-save > /etc/iptables/rules.v4
Linia care merită reținută -m state --state ESTABLISHED,RELATED -j ACCEPT este exact ce ne lipsea la ACL-urile Cisco. Nucleul ține o tabelă de conexiuni (conntrack); orice pachet care aparține unei sesiuni deja stabilite este acceptat automat, indiferent de port.

RELATED merge mai departe: acceptă și traficul înrudit - de exemplu conexiunea de date a unui FTP activ, sau mesajele ICMP de eroare legate de o sesiune existentă. Aceasta este, în concret, diferența dintre stateless și stateful.
Exercițiu rezolvat - antispoofing

O rețea privată are un ruter Linux. Configurați o politică antispoofing: pachetele cu adrese private nu au voie nici să intre din Internet, nici să iasă spre el.

Vezi rezolvarea
antispoofing
iptables -A FORWARD -i eth0 -s 192.168.0.0/16 -j DROP
iptables -A FORWARD -i eth0 -s 172.16.0.0/12  -j DROP
iptables -A FORWARD -i eth0 -s 10.0.0.0/8     -j DROP
iptables -A FORWARD -o eth0 -d 192.168.0.0/16 -j DROP
iptables -A FORWARD -o eth0 -d 172.16.0.0/12  -j DROP
iptables -A FORWARD -o eth0 -d 10.0.0.0/8     -j DROP

Regulile se pun pe FORWARD, pentru că este vorba de trafic care tranzitează ruterul.

Condiția de interfață este obligatorie: -i eth0 înseamnă „venit dinspre Internet". Fără ea, ați bloca și traficul intern legitim dintre două subrețele private - adică exact traficul pe care ruterul trebuie să îl ducă.

Exercițiu propus - patru bilete de la utilizatori

Topologie: un ruter Linux cu eth0 spre Internet, eth1 spre un server (142.31.16.9) și eth2 spre LAN (142.31.16.128/25). Administratorul lucrează de la 214.13.177.2, din Internet. Configurația de plecare este: INPUT: politică ACCEPT, regula -i eth0 -j DROP; FORWARD: politică DROP, regula -i eth0 -j ACCEPT.

Vezi cele patru bilete și rezolvările

#1 - Stațiile din LAN nu ajung la server. Cauza: politica lanțului FORWARD este DROP, iar singura regulă permite doar traficul venit pe eth0 - adică din Internet.

soluția
iptables -P FORWARD ACCEPT

#2 - Doar stațiile din LAN au voie la HTTP-ul serverului.

soluția
iptables -F FORWARD
iptables -A FORWARD -s 142.31.16.128/25 -d 142.31.16.9 -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -d 142.31.16.9 -p tcp --dport 80 -j DROP

Ordinea este obligatorie: regula permisivă, mai specifică, trebuie să fie deasupra celei restrictive. Exact aceeași regulă ca la ACL-uri.

#3 - Doar administratorul are voie la SSH pe ruter. Fiind trafic destinat ruterului, lanțul este INPUT, nu FORWARD.

soluția
iptables -F INPUT
iptables -A INPUT -s 214.13.177.2 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

#4 - Sesiunile TCP să poată fi inițiate doar dinspre interior. Prima variantă, iptables -A FORWARD -p tcp --syn -j DROP, este greșită: blochează inclusiv conexiunile pornite din LAN. Trebuie restrânsă la traficul care intră dinspre Internet:

soluția
iptables -A FORWARD -i eth0 -p tcp --syn -j DROP

Observați că soluția modernă ar fi cu totul alta - o singură linie cu --state ESTABLISHED,RELATED - și că ea acoperă și UDP-ul, și ICMP-ul, pe care --syn nu le atinge deloc.

9Arhitectura perimetrului6 min

Unde anume se pune firewall-ul față de ruterul de margine? Decizia este, cel mai adesea, impusă de furnizorul de Internet, dar principiile sunt clare.

ArhitecturăCând se foloseșteObservații
Ruter în față, firewall în spaterețele medii și maricea mai frecventă: ruterul acoperă cerințele de rutare pe care firewall-ul nu le poate îndeplini
Firewall în față, ruter în spatecerințe de securitate foarte stricteruterul intern este protejat, dar firewall-ul trebuie să facă și rutare
Un singur echipamentrețele mici, rutare staticăsimplu și ieftin; punct unic de defectare

IDS și IPS

Un firewall decide pe baza antetelor. Pentru inspecția conținutului se adaugă un echipament separat, iar diferența dintre cele două variante este exclusiv de poziționare.

IPS - Intrusion Prevention System
  • Plasat în calea traficului, în serie
  • Poate opri pachetele periculoase
  • Devine un potențial punct de gâtuire
  • Dacă pică, poate întrerupe tot traficul
  • Un fals pozitiv taie trafic legitim
IDS - Intrusion Detection System
  • Primește o copie a traficului, în paralel
  • Doar semnalează; nu poate opri nimic
  • Nu influențează performanța rețelei
  • Dacă pică, traficul curge nestingherit
  • Un fals pozitiv generează doar o alarmă

Alegerea nu este „care e mai bun", ci „ce se întâmplă când greșește". Într-o rețea unde disponibilitatea contează mai mult decât riscul, IDS. Într-una unde un singur pachet greșit e inacceptabil, IPS.

10SSH și cele trei concepte de securitate13 min

Telnet transmite totul în clar, inclusiv parola. Oricine ascultă traficul o obține - nu e nevoie de niciun efort, doar de acces la un port de switch oglindit sau la o rețea wireless. SSH rezolvă problema pe trei planuri distincte, care merită înțelese separat, pentru că se regăsesc, cu alte nume, în orice discuție de securitate.

ConceptÎntrebarea la care răspundeMecanismul din SSH
AutentificareSunt cei doi cine pretind că sunt?parolă sau chei asimetrice
ConfidențialitatePoate altcineva să citească mesajul?criptare simetrică (AES, ChaCha20)
IntegritateA fost mesajul modificat pe drum?MAC - cod de autentificare a mesajului
De ce sunt trei probleme și nu una

Sunt independente, iar rezolvarea uneia nu o atinge pe cealaltă.

Un mesaj poate fi criptat perfect și totuși trimis de un impostor - criptarea nu spune cine scrie. Un mesaj poate fi semnat corect și totuși citit de toată lumea. Iar un mesaj criptat poate fi modificat în tranzit fără ca atacatorul să înțeleagă ce modifică, ceea ce e suficient ca să facă rău.

De aceea orice protocol serios le tratează pe toate trei, cu mecanisme diferite.

Confidențialitatea: problema cheii comune

Criptarea simetrică - aceeași cheie la ambele capete - este rapidă și eficientă. Are însă o problemă care pare imposibilă: cum ajung cele două capete să dețină aceeași cheie, dacă singurul canal disponibil este chiar cel pe care vor să îl protejeze?

Răspunsul este schimbul Diffie-Hellman, publicat în 1976, și e una dintre cele mai elegante idei din informatică: cele două capete construiesc o cheie comună fără ca aceasta să fie transmisă vreodată.

Analogie cu vopseluri Doi oameni vor o culoare secretă comună, dar tot ce își trimit este văzut de toată lumea.

Se pun de acord public asupra unei culori de bază - galben. Fiecare adaugă în secret o culoare proprie și trimite amestecul. Un observator vede cele două amestecuri, dar nu poate separa culorile din ele.

Fiecare adaugă apoi propria culoare secretă în amestecul primit. Ambii ajung la exact aceeași culoare finală - galben plus secretul lui plus secretul ei. Observatorul are galbenul și cele două amestecuri, dar nu poate produce culoarea finală, pentru că i-ar trebui unul dintre secrete.
Schimbul Diffie-Hellman

Jucați-vă cu valorile. Schimbați secretul clientului: cheia comună se schimbă - dar rămâne identică pe ambele capete, deși cele două secrete nu au părăsit niciodată calculatoarele respective. Ce circulă pe canal sunt doar p, g, A și B.

Securitatea stă în faptul că, deși A = ga mod p se calculează instantaneu, drumul invers - aflarea lui a din A - este problema logaritmului discret, pentru care nu se cunoaște niciun algoritm rapid. Cu numerele de jucărie de mai sus se sparge prin încercări; cu un p de 2048 de biți, nu.

client (Alice)server (Bob) cere parametrii publici p, g p = 7, g = 3 alege secret a = 12 alege secret b = 7 A = g^a mod p = 6 B = g^b mod p = 3 k = B^a mod p k = A^b mod p k = 6 k = 6
Fig. 3 - Schimbul Diffie-Hellman ca diagramă temporală. Cheia comună k nu circulă niciodată pe canal; ea este calculată independent, la ambele capete.
Ce NU rezolvă Diffie-Hellman Schimbul garantează că nimeni care doar ascultă nu află cheia. Nu garantează absolut nimic despre cine este la celălalt capăt.

Un atacator plasat în mijloc poate face două schimburi DH separate - unul cu clientul, altul cu serverul - și să decripteze, citească și recripteze tot traficul. Este atacul man-in-the-middle, iar soluția nu ține de DH, ci de autentificare: de aceea SSH vă întreabă, la prima conectare, dacă recunoașteți amprenta cheii serverului. Mesajul acela pe care toată lumea îl acceptă fără să citească este exact apărarea împotriva acestui atac.

Autentificarea: parolă sau cheie

Autentificarea are loc după ce canalul criptat există. Pare să rezolve problema parolelor - dar nu complet:

  • serverul trebuie să vadă parola ca să o valideze; dacă serverul este compromis, parola este compromisă - și, de regulă, e refolosită și altundeva;
  • parolele suficient de sigure sunt greu de reținut, deci utilizatorii aleg parole slabe;
  • o parolă poate fi ghicită prin încercări repetate, iar Internetul are răbdare infinită.

De aceea se preferă cheile asimetrice. O pereche de chei are proprietatea că ceea ce este criptat cu una poate fi decriptat doar cu cealaltă: K⁺(K⁻(M)) = M și K⁻(K⁺(M)) = M. Clientul își păstrează cheia privată - care nu părăsește niciodată calculatorul lui - iar cheia publică este configurată pe server.

  1. Se stabilește sesiunea sigură prin Diffie-Hellman.
  2. Clientul cere autentificarea pentru un anumit utilizator.
  3. Serverul trimite un challenge: un șir aleator pe care clientul trebuie să îl semneze.
  4. Clientul îl criptează cu cheia sa privată. Rezultatul se numește authenticator.
  5. Serverul verifică folosind cheia publică preconfigurată. Dacă rezultatul coincide cu șirul trimis, clientul deține cheia privată - deci este cine pretinde.

Observați ce nu s-a întâmplat niciodată în cei cinci pași: cheia privată nu a fost transmisă. Serverul nu o cunoaște și nu o poate afla. Un server compromis nu vă compromite identitatea pe alte servere - spre deosebire de o parolă.

De ce doar challenge-ul este criptat asimetric Criptarea asimetrică este cu ordine de mărime mai lentă decât cea simetrică. A cripta astfel tot traficul ar fi inacceptabil. Cheia privată este folosită strict pentru operația de autentificare; restul sesiunii merge pe cheia simetrică obținută prin Diffie-Hellman.

Același principiu - asimetric pentru schimbul de chei, simetric pentru date - stă la baza TLS și a oricărei conexiuni HTTPS pe care o deschideți.

Integritatea: codul MAC

Un MAC (Message Authentication Code) este, în esență, un hash calculat cu o cheie. Emițătorul îl calculează peste mesaj și îl trimite alături; receptorul îl recalculează cu aceeași cheie și compară. Dacă valorile diferă, mesajul a fost modificat pe drum.

Cheia este esențială. Un hash simplu nu ar ajuta: atacatorul ar modifica mesajul și ar recalcula hash-ul. Fără cheie, nu poate produce un MAC valid pentru mesajul modificat.

Ce se vede și ce nu, într-o captură SSH Un Wireshark pornit pe o sesiune SSH arată adresele IP, porturile, momentele și dimensiunile pachetelor - deci că există o conversație, cu cine și cât de intensă este. Se numesc metadate, și ele scapă criptării.

Nu arată conținutul, nu arată parola, nu arată comenzile executate și nu permite modificarea traficului fără ca ambele capete să observe imediat.

11Erori frecvente4 min

  • „Regula mea iptables nu are niciun efect" Aproape sigur e pe lanțul greșit: INPUT în loc de FORWARD, sau invers. Întrebați cine e destinatarul din antetul IP. Mașina însăși → INPUT. Altcineva → FORWARD.
  • „Am pus politica DROP și m-am deconectat" Politica s-a aplicat înaintea regulii care permitea SSH-ul dumneavoastră. Întâi toate regulile ACCEPT, apoi -P DROP. Pe mașini la distanță, testați cu o a doua sesiune deschisă.
  • „Firewall-ul a dispărut după repornire" Regulile trăiesc în memoria nucleului și nu se salvează singure. iptables-save sau serviciul netfilter-persistent.
  • „Am folosit wildcard-ul Cisco în iptables" -s 10.0.0.0/0.0.0.255 nu înseamnă ce credeți. iptables folosește masca normală sau CIDR. -s 10.0.0.0/24. Verificați cu iptables -L -n, care afișează prefixul rezultat.
  • „Am blocat ICMP complet, ca să fiu în siguranță" Ați blocat și mesajele fragmentation needed, esențiale pentru descoperirea MTU-ului. Rezultatul: conexiuni care se deschid și apoi îngheață inexplicabil. Blocați doar echo-request dinspre exterior; lăsați ICMP-ul de eroare să treacă.
  • „Diffie-Hellman mă protejează de tot" Vă protejează de cineva care ascultă. Nu de cineva care se așază în mijloc. Verificați amprenta cheii la prima conectare. Este singurul moment în care contează.
  • „Am confundat DROP cu REJECT" REJECT confirmă atacatorului că mașina există. DROP spre exterior, REJECT spre interior - ca aplicațiile proprii să nu aștepte degeaba.

12Rezumat și glosar5 min

Ce trebuie să rămână
  • Nivelul 4 adaugă portul; perechea IP + port se numește socket.
  • TCP e sigur și cu conexiune; UDP e rapid și fără garanții. Alegerea depinde de aplicație.
  • Strângerea de mână are trei segmente; închiderea are patru, pentru că fiecare sens se închide separat.
  • Un SYN flood umple coada de conexiuni pe jumătate deschise; apărarea sunt SYN cookies și limitarea ratei.
  • În iptables, lanțul spune unde, tabela spune ce fel de decizie.
  • INPUT = pentru mașină, FORWARD = prin mașină, OUTPUT = de la mașină.
  • Politica corectă este DROP, iar regulile ACCEPT se pun înaintea ei.
  • --state ESTABLISHED,RELATED rezolvă tot traficul de întoarcere într-o linie.
  • Autentificare, confidențialitate, integritate sunt trei probleme distincte, cu trei mecanisme distincte.
  • Diffie-Hellman rezolvă schimbul de chei, nu identitatea celuilalt capăt.
portnumăr de 16 biți care identifică aplicația
socketperechea adresă IP + port
MSSdimensiunea maximă a unui segment, negociată la deschidere
SYN floodatac care umple coada de conexiuni pe jumătate deschise
SYN cookieapărare care codifică starea în numărul de secvență
statefulfirewall care ține minte sesiunile deschise
conntracktabela de conexiuni a nucleului Linux
lanțpunctul din traseul pachetului unde se aplică reguli
politicăacțiunea implicită a unui lanț, când nicio regulă nu se potrivește
DMZzonă separată pentru serviciile expuse public
IDS / IPSdetectare în paralel / prevenție în serie
Diffie-Hellmanconstruirea unei chei comune fără a o transmite
MAChash calculat cu o cheie, care garantează integritatea
man-in-the-middleatacator care intermediază două sesiuni separate

13Întrebări de verificare6 min

14Direcții de aprofundare2 min

Cursul următor folosește exact aceleași unelte - ACL-uri pe Cisco, iptables pe Linux - dar pentru altceva decât filtrare: translatarea adreselor și construirea de tuneluri. Veți vedea acolo tabela nat pe care am amânat-o azi, și veți înțelege de ce o rețea privată poate naviga pe Internet cu o singură adresă publică.

Laboratorul 7 aplică practic partea de securitate: SSH pe echipamente, plus apărarea împotriva atacurilor de nivel 2 din cursul 12.

  • RFC 9293 - Transmission Control Protocol (versiunea consolidată a lui RFC 793)
  • RFC 4987 - TCP SYN Flooding Attacks and Common Mitigations
  • RFC 4251–4254 - arhitectura SSH
  • Manualele iptables(8) și iptables-extensions(8)
  • William Stallings, Cryptography and Network Security - capitolele despre Diffie-Hellman și MAC