Scenario DMZ
Server pubblico in DMZ + LAN Venezia protetta + navigazione Web “return traffic”
established controlla soltanto i flag TCP ACK/RST. Non mantiene una tabella delle connessioni e non garantisce che ogni pacchetto ammesso sia una risposta a una richiesta precedente. Qui osserviamo il filtraggio del normale traffico HTTP in Packet Tracer. Riferimento Cisco: established e filtri di sessione.Scenario DMZ – Topologia e obiettivo
La sede di Venezia ha una LAN interna che deve essere protetta: dall’esterno non deve essere possibile avviare connessioni dirette verso i PC interni.
Nella stessa sede è presente un server web pubblico che deve essere raggiungibile da qualunque rete. Per questo motivo viene collocato in una DMZ (rete separata dalla LAN e “sul perimetro”).
Inoltre, la LAN di Venezia deve poter “andare su Internet” (qui: raggiungere un server esterno che simula un sito). Per sicurezza però non consentiamo ingresso indiscriminato: useremo il principio:
- Request: la LAN può iniziare comunicazioni verso l’esterno;
- Response: ammettiamo pacchetti TCP con porta sorgente 80 e flag ACK/RST, normalmente presenti nelle risposte HTTP;
- i SYN iniziali privi di ACK/RST vengono bloccati. Il filtro non verifica che esista una sessione precedente.
80) verso la LAN, ma non altri protocolli.
ACL 1 – Permettere l’accesso HTTP al Web Server in DMZ
Prima regola: il web server in DMZ (172.16.3.100) deve essere raggiungibile da
qualunque rete sulla porta 80.
access-list 100 permit tcp any host 172.16.3.100 eq 80
Applichiamo l’ACL sull’interfaccia del router Venezia esposta verso l’esterno (in ingresso):
interface fa0/0
ip access-group 100 inACL 2 – Filtrare il traffico HTTP con ACK/RST verso la LAN
Per permettere la navigazione solo Web dalla LAN di Venezia, dobbiamo
autorizzare il traffico di risposta che rientra dall’esterno.
In Cisco, per TCP, possiamo usare la keyword established (ACK/RST impostati).
La regola ammette pacchetti TCP provenienti da server web (porta sorgente
80) verso la rete LAN Venezia (172.16.2.0/24), solo
se
hanno il flag ACK o RST impostato. Questo filtro non verifica che esista una sessione già avviata.
access-list 100 permit tcp any eq 80 172.16.2.0 0.0.0.255 established
-
La keyword
establishedè valida solo per TCP: consente esclusivamente pacchetti con flag ACK o RST, senza verificare lo stato di una connessione. ACK/RST sono normalmente presenti nel traffico di risposta, ma la regola non mantiene una tabella delle sessioni. Non è applicabile a UDP, che non prevede flag di stato. -
L’uso di
eq 80limita il traffico ai soli pacchetti con porta sorgente 80. Le connessioni HTTPS (porta 443) non verrebbero quindi autorizzate. -
Per consentire anche la navigazione HTTPS è necessario aggiungere
una regola analoga per la porta
443, oppure utilizzare un opportuno intervallo di porte.
Esempio(https):access-list 100 permit tcp any eq 443 172.16.2.0 0.0.0.255 established
Esempio(intervallo porte):access-list 100 permit tcp any range 80 443 172.16.2.0 0.0.0.255 established
Attenzione: in questo modo si autorizzano anche altre porte TCP comprese tra 80 e 443, quindi è meno “mirato”.
Test (cosa deve funzionare e cosa deve essere bloccato)
- DMZ: HTTP verso 172.16.3.100 deve passare.
- Venezia → esterno: navigazione HTTP deve funzionare.
- Esterno → Venezia: i SYN iniziali senza ACK/RST devono essere bloccati.
- ICMP e altro: bloccato (in questo esercizio).
Variante: ammettere ACK/RST per più servizi TCP
Adesso hai autorizzato solo Web HTTP come “return traffic” (porta sorgente 80).
Se vuoi consentire anche altre risposte TCP (es. HTTPS/443, mail, ecc.), puoi allargare la
regola
mantenendo established.
access-list 100 permit tcp any 172.16.2.0 0.0.0.255 established