Torna a reti ethernet

Firewall

Il firewall è un dispositivo che eleva il livello di sicurezza di una rete locale mediante il processo di filtraggio (eliminazione selettiva) dei pacchetti in transito in base a delle regole di controllo predefinite che, per essere efficaci, devono esaminare costantemente le principali arterie obbligate di traffico da e verso la LAN.

Il firewall + un componente essenziale della rete e ne esiste sempre almeno uno al confine tra la rete LAN e Internet. Funzionalità basilari di un firewall di qualità:

Il firewall è usato anche come reverse proxy server per realizzare un ALG (Application Level Gateway) con funzione di redirezione delle richieste tra server diversi sulla medesima porta TCP. E’ usato anche per realizzare la funzione di NAT, cioè traduzione degli indirizzi IP da privati a pubblici e viceversa. E’ adoperato come router tra le sue interfacce standard quali LAN, WAN e DMZ. Può essere usato anche come bilanciatore di carico delle connessioni WAN multiple (ad es. due in fibra e una wireless).

ALG

il destination NAT può reindirizzare dinamicamente le connessioni anche in base a criteri che valutano l’intestazione della richiesta. Un comportamento comune è quello di esaminare il path dell’indirizzo url cioè la parte compresa tra il nome dell’host e la sezione della query. Ad ogni path corrisponde un backend con un proprio pool di server. Tutti i server, indipendentemente dal pool di appartenenza, possono condividere una stessa porta esterna sul router/NAT.

alt text

Questa tecnica permette di superare il limite tecnico del port forwarding tradizionale che impone il vincolo della non condivisibilità di una stessa porta esterna del router tra più server interni nella LAN. Questa tecnica può essere adoperata per realizzare il partizionamento del carico in base al tipo di servizio oppure, per uno stesso servizio, in base alla provenienza geografica della richiesta. Ad esempio una richiesta con l’indirizzo https://segreteria.marconicloud.it /non è utilizzabile dall’utente perché è riservato agli accessi ad un webservice https da parte dell’aministrazione remota di axios. https://segeteria.marconicloud/guacamole/ invece, pur afferendo alla stessa porta 443, viene dal modulo ALG rediretto verso il server di VPN Guacamole.

alt text

Esempio di partizionamento e bilanciamento del carico

# Configurazione HAProxy
global
  log /dev/log    local0
  log /dev/log    local1 notice
  maxconn 4096
  user haproxy
  group haproxy
  daemon

defaults
  log     global
  mode    http
  option  httplog
  option  dontlognull
  timeout connect 5000
  timeout client  50000
  timeout server  50000

frontend http_front
  bind *:80
  bind *:443 ssl crt /etc/haproxy/cert.pem  # Certificato SSL (opzionale)
  
  # Reindirizza automaticamente le richieste HTTP a HTTPS, a meno che non siano già in SSL
  http-request redirect scheme https unless { ssl_fc }
  # Indica al backend che è posto dietro ad un reverse proxy che termina la connessione https
  http-request add-header X-Forwarded-Proto https if { ssl_fc }

  # ACL per indirizzo del blog
  acl is_blog hdr_end(host) -i blog.miosito.com

  # ACL per indirizzo del web
  acl is_web hdr_end(host) -i web.miosito.com

  use_backend blog_backend if is_blog
  use_backend web_backend if is_web

backend blog_backend
  server blog_server1 blog.miosito.com:80 check

backend web_backend
  balance roundrobin    # Bilanciamento del carico round-robin tra i server
  server web_server1 web.miosito.com:80 check
  server web_server2 web.miosito.com:80 check
  server web_server3 web.miosito.com:80 check

IPS

IDS (Intrusion Detetection System): talvolta ad un firewall è associata anche la funzione rilevamento delle intrusioni:

Scansione dei contenuti

Le connessioni cifrate HTTPS, essendo End to End, in realtà non sono ispezionabili per cui la funzione di deep inspection su di esse è, di fatto, inefficace. Connessioni cifrate end to end (HTTPS) sono ispezionabili solo in modalità proxy mediante SSL MITM Filtering.

SSL MITM Filtering

Si può alternativamente realizzare con un proxy HTTPS (ad es Squid) + autorità di certificazione locale. Per far ciò bisogna installare su ogni client il certificato CA di una CA locale (normalmente lo stesso firewall/proxy). Il sistema guadagna in sicurezza ma può sorgere qualche problema di privacy: • Consenso informato degli utenti • Responsabilità sulla fedeltà e correttezza dei sistemisti

alt text

Fasi dell’ispezione SSL MITM Filtering

  1. Il proxy SSL intercetta le connessioni dal client sulla porta TCP 443.
  2. Il proxy SSL Effettua negoziazioni SSL con il server web per conto del cliente.
  3. Analizza il certificato inviato dal server. Se il certificato non è conforme, l’accesso al server verrà bloccato.
  4. Se il certificato è conforme, il proxy SSL cercherà le regole del filtro SSL: blocca, passa o decifra
  5. Se il certificato è conforme, il proxy SSL genererà un certificato falso e lo presenterà al client, che verificherà il certificato. Se il certificato dell’autorità di firma non è stato installato nel browser o nel sistema e dichiarato come autorità attendibile, verrà visualizzato un messaggio di errore.
  6. Se il certificato è presente, il traffico sarà protetto. Verranno quindi applicate le protezioni dell’applicazione (ad es. antivirus, antispam, sandboxing). Benchè il firewall Pfsense consenta questo tipo di ispezione intrusiva, considerazioni di tipo organizzativo (oneroso installare altri certificati su un gran numero di pc) e di tipo etico ci hanno scoraggiato dall’applicarla.

Regole firewall

alt text

Pubblicazione dei servizi di sistema

I servizi di sistema quali server DNS interni, server DHCP, server NAS, server di Active Directory, server di autenticazione Kerberos, server Radius, server di desktop remoto RDP, non dovrebbero essere esposti direttamente nella DMZ in quanto sono servizi progettati per essere utilizzati all’interno di una LAN, benchè molti di questi implementino protocolli di cifratura e di autenticazione molto robusti. In quanto servizi di sistema, i client di queste macchine dovrebbero essere interni alla LAN e non macchine poste nella WAN.

Diverso è il discorso per servizi che pubblicano all’esterno e che utilizzano, per svolgere i loro compiti, servizi interni. Ad esempio un server Guacamole di desktop remoto che utilizza il servizio RDP di una macchina interna della LAN o il servizio di autenticazione dell’utente basato su Radius o sulla consultazione di una database LDAP. In questo caso i server che pubblicano all’esterno nella DMZ sono bifronti e in gergo vengono chiamati three tier, in quanto posseggono un terminale remoto in WAN che è il processo client dell’utente (tipicamente web), un server nella DMZ che gestisce il dialogo con il client e che realizza le funzioni di business per l’utente che però necessita, a sua volta, di dati o servizi posti nella LAN e forniti da server posti al suo interno.

Nel caso di Guacamole, sicuramente il server in DMZ ha necessità dell’accesso ad un PC interno alla LAN (postazione di lavoro) e dell’accesso ad un server di autenticazione, molto probabilmente attestato sul core switch (CS) o sullo switch che realizza la server farm. E’ bifronte perchè è un server di un client che ha iniziato nella WAN la sua connessione verso la DMZ, ma è anche lui stesso un client, posto nella DMZ, che inizia una connessione verso un server della LAN. In sostanza è una applicazione distribuita three tier con il tier 1 nella WAN (il client utente), il tier 2 nella DMZ (il server utente + il client dei servizi interni), il tier 3 nella LAN (un server dati o multimediale).

alt text

L’architettura del firewall deve essere adatta a quella di un servizio multitier (modello server farm), per cui nella DMZ si espongono:

  1. prima le funzioni di pubblicazione blandamente protette da un primo firewall.
  2. Poi si espongonole funzioni di business (microservizi interni) protetti in maniera più occhiuta da un altro firewall (può accedere solo il server in DMZ)
  3. Poi alla fine si espone il server dei dati o dei contenuti multimediali che può essere acceduto solo da un ristretto numero di server di business e mai direttamente dall’utente.

La logica è quella dei compartimenti stagni dove ogni intrusione causa danni di importanza via via maggiore. I beni aziendali sicuramente più preziosi per l’azienda sono i dati e dovrebbero stare nella zona più interna, quella protetta da più linee di difesa.

Non è necessario che esistano davvero degli switch che creino delle LAN su cui si attesta il firewall comune a molti server. Potrebbe semplicemente esserci una cascata di server ciascuno con a bordo un firewall applicativo o WAF (https://www.oracle.com/it/security/cloud-security/what-is-waf/) che filtri gli accessi limitandoli a gruppi di client via via numericamente più ristretti e più fidati.

alt text

In questo ultimo caso la DMZ2 viene sostituita da un WAF sul server di microservizi e sul server dati.

Azioni di una regola

alt text

Le ACL si dividono in:

alt text

Le ACL (Access Control List ) vengono elaborate dal router secondo l’ordine con cui le varie clausole compaiono (lista con priorità). Si scorre la lista fino a che non si trova il primo match (verifica) delle condizioni, a questo punto si interrompe la valutazione, viene applicata la decisione presa e si passa al pacchetto successivo:

Le ACL devono essere:

In base alla direzione dell’interfaccia in cui sono applicate le regole possono essere:

Impostazione dei filtraggi WAN inbound

Nell’interfaccia WAN gli indirizzi di destinazione possono essere:

Poichè la WAN è una interfaccia con una rete insicura allora la politica di default delle sue regole è la deny all, di conseguenza le regole sono tutte delle white list che permettono esplicitamente tutto ciò che non è già negato. Le regole sono organizzabili in liste con scopi diversi:

Impostazione dei filtraggi WAN inbound su Pfsense

alt text

Impostazione dei filtraggi WAN inbound su un router Cisco

! Blocca gli indirizzi non validi (antispoofing)
access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip 127.0.0.0 0.255.255.255 any
access-list 101 deny ip 169.254.0.0 0.0.255.255 any
access-list 101 deny ip 224.0.0.0 15.255.255.255 any
access-list 101 deny ip 240.0.0.0 7.255.255.255 any

! Permetti il traffico verso servizi specifici sull'IP pubblico del router/firewall
access-list 101 permit tcp any host <public-ip> eq 80
access-list 101 permit tcp any host <public-ip> eq 443

! Permetti il traffico verso servizi specifici sull'IP privato di un server interno
access-list 101 permit tcp any host <internal-server-ip> eq 22
access-list 101 permit tcp any host <internal-server-ip> eq 3389

! Blocca tutto il traffico rimanente
access-list 101 deny ip any any

! Applica le ACL all'interfaccia WAN
interface GigabitEthernet0/1
 ip access-group 101 in

Impostazione dei filtraggi LAN inbound

In questa direzione i pacchetti attraversano prima le regole di firewall dell’interfaccia LAN e poi il SNAT OUTBOUND. Quindi sia gli indirizzi di sorgente sono ancora privati.

Poichè la LAN è una interfaccia con una rete sicura allora la politica di default delle sue regole è la permit all, di conseguenza le regole sono tutte delle black list che negano esplicitamente tutto ciò che non è già permesso. Le regole sono organizzabili in liste con scopi diversi:

Impostazione dei filtraggi LAN inbound su Pfsense

alt text

Impostazione dei filtraggi LAN inbound su un router Cisco

! Permetti l'accesso amministrativo al firewall
access-list 101 permit ip host <admin-ip> any

! Blocca il traffico da un gruppo specifico di utenti
access-list 101 deny ip <user-group-subnet> <subnet-mask> any

! Consenti tutto il traffico rimanente
access-list 101 permit ip any any

! Crea la class map per il traffico HTTP
class-map match-all WEB-TRAFFIC
 match protocol http

! Crea la policy map per taggare il traffico HTTP
policy-map SHAPE-WEB-TRAFFIC
 class WEB-TRAFFIC
  set dscp af21

! Applica le ACL e le politiche all'interfaccia WAN
interface GigabitEthernet0/1
 ip access-group 101 in
 service-policy output SHAPE-WEB-TRAFFIC

Regole floating

Le regole floating in un firewall sono regole avanzate che possono essere applicate in modo più flessibile rispetto alle regole standard, poiché non sono legate a una specifica interfaccia o direzione del traffico, cioè, possono essere applicate a più interfacce contemporaneamente e in una o in entrambe le direzioni.

Molti firewall commerciali permettono di base solo l’impostazione di regone inbound. Le regole outbound sono di norma scoraggiate nei firewall perimetrali per motivi di:

Cisco non usa il termine “floating rules”, configurazioni avanzate come policy map e class map possono essere utilizzate per applicare politiche QoS o altre regole sofisticate in modo simile alle regole floating di firewall commerciali come pfSense.

Scopo delle regole floating

Esempio di utilizzo

NAT

Il NAT è un processo (non è un protocollo!) che esegue la traduzione di indirizzi nel passaggio di pacchetti attraverso l’interfaccia tra interno ed esterno e viceversa:

SNAT

Si usa per:

Si divide in:

DNAT

Si usa per:

Esempio si SNAT PNAT con due port forward

! Configurazione dell'interfaccia WAN
interface GigabitEthernet0/1
 description WAN Interface
 ip address dhcp
 ip nat outside

! Configurazione dell'interfaccia LAN
interface GigabitEthernet0/0
 description LAN Interface
 ip address 192.168.1.1 255.255.255.0
 ip nat inside

! Creare un pool di indirizzi NAT (se necessario)
ip nat pool mynatpool 203.0.113.10 203.0.113.10 netmask 255.255.255.0

! Associare l'interfaccia LAN al NAT realizzando un PNAT
ip nat inside source list 1 pool mynatpool overload

! Access list per consentire il NAT per la rete interna
access-list 1 permit 192.168.1.0 0.0.0.255

! Port forwarding per HTTPS verso il server interno 192.168.1.100
ip nat inside source static tcp 192.168.1.100 443 interface GigabitEthernet0/1 443

! Port forwarding per SSH verso il server interno 192.168.1.101
ip nat inside source static tcp 192.168.1.101 22 interface GigabitEthernet0/1 22

Sitografia:

Torna a reti ethernet