Scenario DMZ

Scenario DMZ – Topologia e obiettivo

Topologia dell’esercizio: LAN Venezia, DMZ con server web e reti esterne (simulate).

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: dall’esterno lasciamo entrare solo risposte correlate a richieste già avviate;
• ogni tentativo di connessione in ingresso non correlato viene bloccato.

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

Configurazione della regola DMZ sul router di Venezia.

Applichiamo l’ACL sull’interfaccia del router Venezia esposta verso l’esterno (in ingresso):

interface fa0/0
 ip access-group 100 in

ACL 2 – Consentire solo le risposte HTTP (return traffic) 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).

Regola (come l’hai scritta tu): permette risposte TCP provenienti da server web (porta sorgente 80) verso la rete LAN Venezia (172.16.2.0/24), solo se appartengono a una connessione già avviata.

access-list 100 permit tcp any eq 80 172.16.2.0 0.0.0.255 established

Seconda regola: return traffic HTTP verso LAN Venezia.

Nota didattica:

• La keyword established è valida solo per TCP: consente esclusivamente pacchetti con flag ACK o RST, cioè traffico di risposta a connessioni già avviate. Non è applicabile a UDP, che non prevede flag di stato.
• L’uso di eq 80 limita il traffico alle sole risposte HTTP. 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)

Test 1: dalla rete esterna si raggiunge il Web Server in DMZ.

Test 2: dalla LAN Venezia si visita il server esterno (HTTP) grazie al return traffic.

Test 3: ping (ICMP) negato. È coerente: stai autorizzando solo Web (TCP/80) e DMZ (TCP/80).

Riassunto risultati attesi

• DMZ: HTTP verso 172.16.3.100 deve passare.
• Venezia → esterno: navigazione HTTP deve funzionare.
• Esterno → Venezia: nuove connessioni devono essere bloccate.
• ICMP e altro: bloccato (in questo esercizio).

Nota: se vuoi permettere più servizi (sempre “solo response”)

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