Differences
This shows you the differences between two versions of the page.
|
rl:labs:08:contents:01 [2013/09/18 16:45] razvan.deaconescu [1. Trafic criptat și necriptat] |
rl:labs:08:contents:01 [2025/11/28 11:22] (current) radu.mantu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 1. Trafic criptat și necriptat ==== | + | ==== 01. [10p] Configurare translatare de adrese (MASQUERADE) ==== |
| - | Traficul generat de servicii se clasifică în trafic criptat și trafic în clar. Traficul în clar (necriptat) poate fi interpretat și înțeles dacă este capturat. Traficul criptat nu poate fi interpretat în absența cheii de criptare; doar transmițătorul și receptorul cunosc cheia pentru a putea comunica. | + | Epuizarea adreselor IPv4 în cadrul rețelelor curente a condus la folosirea de adrese IP din clase private (de ex. ''192.168.0.0/24''). Pe lângă comunicația dintre stațiile unei rețele, dorim și accesul la Internet al acestora. De aceea s-a introdus conceptul de translatare de adrese (NAT: //Network Address Translation//) prin care mai multe stații dispun de acces la Internet folosind aceeași adresă IP rutabilă: adresa gateway-ului. Activarea translatării de adrese (NAT) pe gateway conduce la înlocuirea perechii <adresă IP sursă, port sursă> (aparținând stației) cu perechea <adresa IP gateway, port disponibil>. |
| - | Ne propunem să analizăm, din punctul de vedere al criptării traficului, următoarele protocoale/servicii: | + | Configurarea NAT pe Linux se realizează tot prin intermediul comenzii ''iptables'', la fel ca în cazul configurării firewall-ului. Dacă pentru configurarea firewall-ului foloseam tabela ''filter'' (tabela implicită a ''iptables''), pentru configurarea translatării de adrese vom folosi tabela ''nat''. |
| - | * telnet (port TCP 23) | + | |
| - | * SSH (port TCP 22) | + | |
| - | * FTP (port TCP 21) | + | |
| - | Vom folosi ''dsniff'', un utilitar cu ajutorul căruia putem captura în clar pachetele care trec printr-un anumit server, pentru a afișa datele transmise (username, parolă, comenzi). Vom folosi toplogia de laborator și ne vom conecta de la stația ''red'' la stația ''green'' prin intermediul stației ''host''. | ||
| - | Pentru a porni procesul de captură, autentificați-vă ca ''root'' pe stația ''host'' și rulați comanda<code bash> | + | |
| - | dsniff -i veth-green | + | Astfel, pentru a activa NAT pe un server Linux executăm comanda<code bash> |
| + | root@host:~# iptables -t nat -A POSTROUTING -j MASQUERADE | ||
| </code> | </code> | ||
| + | În comanda de mai sus: | ||
| + | * ''-t'' specifică tabela pe care se aplică regula, în cazul nostru tabela ''nat''. | ||
| + | * ''-A'' înseamnă adăugarea unei reguli la sfârșitul listei de reguli. | ||
| + | * ''POSTROUTING'' se referă la momentul când va fi realizat procesul de translatare de adrese: după rutare. | ||
| + | * În nomenclatura ''iptables'' acesta se numește și **lanț (chain)**. | ||
| + | * [[https://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html|Exemple de alte lanțuri: ''INPUT'', ''OUTPUT'', ''FORWARD'', ''PREROUTING'']]. | ||
| + | * ''-j'' este acțiunea ce va fi luată, iar în acest caz este ''MASQUERADE'' (acțiune simplă de translatare de adrese). | ||
| - | Pentru comunicație prin telnet, rulați pe stația ''red'' comanda<code bash> | + | Pentru a verifica și valida regula, afișăm intrările din lanțul ''POSTROUTING'' din tabela ''nat'' folosind comanda<code bash> |
| - | telnet green | + | root@host:~# iptables -t nat -L POSTROUTING -n -v |
| + | Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) | ||
| + | pkts bytes target prot opt in out source destination | ||
| + | 0 0 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 | ||
| </code> | </code> | ||
| - | În urma rulării comenzii ați realizat o conexiune telnet de la stația ''red'' la stația ''green'' prin intermediul stației ''host''. La prompt-ul generat de comandă folosiți username-ul ''student'' și parola ''student''; după aceea rulați comanda ''ls'' și apoi comanda ''exit'' pentru a închide conexiunea. Observați pe stația ''host'' captura credențialelor (username și parolă) transmise prin telnet între stațiile ''red'' și ''green'' => traficul telnet între cele două stații a fost **trafic în clar** și a fost capturat pe stația ''host''. | ||
| - | Pentru comunicație prin FTP, rulați pe stația ''red'' comanda<code bash> | + | Vrem să verificăm configurarea corectă a NAT. Pentru acesta vom trimite de pe stația ''red'' un pachet către ''1.1.1.1''. Pachetul va trece prin gateway (adică stația ''host'') și va fi translatat. Pe stația ''red'' rulăm comanda<code bash> |
| - | ftp green | + | root@red:~# ping -c 2 1.1.1.1 |
| + | PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. | ||
| + | From 192.168.1.2 icmp_seq=1 Destination Host Unreachable | ||
| + | From 192.168.1.2 icmp_seq=2 Destination Host Unreachable | ||
| + | |||
| + | --- 1.1.1.1 ping statistics --- | ||
| + | 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 999ms | ||
| </code> | </code> | ||
| - | În urma rulării comenzii ați realizat o conexiune FTP de la stația ''red'' la stația ''green'' prin intermediul stației ''host''. La prompt-ul generat de comandă folosiți username-ul ''student'' și parola ''student''; după aceea rulați comanda ''ls'' și apoi comanda ''quit'' pentru a închide conexiunea. Observați pe stația ''host'' captura credențialelor (username și parolă) transmise prin FTP între stațiile ''red'' și ''green'' => traficul FTP între cele două stații a fost **trafic în clar** și a fost capturat pe stația ''host''. | ||
| - | Pentru comunicație prin SSH, rulați pe stația ''red'' comanda<code bash> | + | Observăm că nu există conectivitate de la stația ''red'' către adresa IP ''1.1.1.1''. Consultăm întreaga tabelă ''nat'':<code bash> |
| - | ssh -l student green | + | root@host:~# iptables -t nat -L -n -v |
| + | Chain PREROUTING (policy ACCEPT 2 packets, 168 bytes) | ||
| + | pkts bytes target prot opt in out source destination | ||
| + | |||
| + | Chain INPUT (policy ACCEPT 0 packets, 0 bytes) | ||
| + | pkts bytes target prot opt in out source destination | ||
| + | |||
| + | Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) | ||
| + | pkts bytes target prot opt in out source destination | ||
| + | |||
| + | Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) | ||
| + | pkts bytes target prot opt in out source destination | ||
| + | 0 0 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 | ||
| + | </code> | ||
| + | Observăm că pachetele ajung în lanțul ''PREROUTING'' (înainte de rutare), dar nu ajung în lanțul ''POSTROUTING'' (după rutare). Ne gândim că este posibil să fie o problemă cu rutarea pe gateway. Verificăm dacă rutarea este activată:<code bash> | ||
| + | root@host:~# sysctl net.ipv4.ip_forward | ||
| + | net.ipv4.ip_forward = 0 | ||
| </code> | </code> | ||
| - | În urma rulării comenzii ați realizat o conexiune SSH de la stația ''red'' la stația ''green'' prin intermediul stației ''host''. La prompt-ul generat de comandă folosiți username-ul ''student'' și parola ''student''; după aceea rulați comanda ''ls'' și apoi comanda ''exit'' pentru a închide conexiunea. Observați că pe stația ''host'' ''dsniff'' nu afișează informații despre credențialele (username și parolă) transmise între stațiile ''red'' și ''green'' => traficul SSH între cele două stații a fost **trafic criptat** și **nu** a putut fi capturat pe stația ''host''. | ||
| + | Într-adevăr, rutarea nu este activată. Pentru a activa rutarea pe stația ''host'' rulăm comanda<code bash> | ||
| + | root@host:~# sysctl -w net.ipv4.ip_forward=1 | ||
| + | net.ipv4.ip_forward = 1 | ||
| + | </code> | ||
| + | |||
| + | Intrăm din nou pe stația ''red'' și folosim ''ping'' pentru a testa conectivitatea la adresa IP ''1.1.1.1'':<code bash> | ||
| + | root@red:~# ping -c 2 1.1.1.1 | ||
| + | PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. | ||
| + | 64 bytes from 1.1.1.1: icmp_req=1 ttl=61 time=92.9 ms | ||
| + | 64 bytes from 1.1.1.1: icmp_req=2 ttl=61 time=81.2 ms | ||
| + | |||
| + | --- 1.1.1.1 ping statistics --- | ||
| + | 2 packets transmitted, 2 received, 0% packet loss, time 1001ms | ||
| + | rtt min/avg/max/mdev = 81.272/87.094/92.917/5.829 ms | ||
| + | </code> | ||
| + | Acum există conectivitate, lucru certificat și de prezența unor pachete în lista prelucrată pe lanțul ''POSTROUTING'':<code bash> | ||
| + | root@host:~# iptables -t nat -L POSTROUTING -n -v | ||
| + | Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) | ||
| + | pkts bytes target prot opt in out source destination | ||
| + | 2 168 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 | ||
| + | </code> | ||
