Firewall/NAT

[davide73]

Ciao a tutti!

Stiamo allestendo un rack in colocation i cui server saranno protetti da un firewall hardware (Clavister).
La mia idea è quella di creare una LAN privata 192.168.x.x per i server lasciando al firewall il compito di mascherare il traffico in uscita (ogni server avrà il suo ip pubblico) e di eseguire il DNAT per il traffico in ingresso permesso. Vi saranno anche altre due reti private fisicamente separate: una per la gestione dei dispositivi di rete e iLO ed una per la SAN iScsi.

Mi dareste una vostra opinione su quanto vorrei fare ?

Grazie

Ciao!

[WizOfOz]

il primo consiglio è di avere una ridondanza HW sul firewall o al primo problema hai tutta la tua rete isolata.

PS. hai preso una appliance o solo il sw ? che modello?

[davide73]

il primo consiglio è di avere una ridondanza HW sul firewall o al primo problema hai tutta la tua rete isolata.

PS. hai preso una appliance o solo il sw ? che modello?

Ciao,

il firewall è già in HA, abbiamo preso due appliance SG55 con in più il servizio di sostituzione per 3 anni in 24 ore.

Hai esperienze con prodotti Clavister ?

ciao,
Davide.

[WizOfOz]

ho un cliente che ne ha preso uno ma per uso interno.. li trovo un po complicati.. ma sono buoni prodotti.

[etr]

Ti rispondo con una domanda .... come mai volete tenere i server web con ip privato e poi nattare ? Non è meglio lasciare gli ip pubblici sui server ?

[WizOfOz]

Provo a rispondere io e attendiamo conferma.
Sicuramente non per risparmiare sugli ip, visto che associa un ip pubblico a ogni server. Questa scelta credo sia dettata dal fatto di non volere esporre direttamente il server ad attacchi, dato che non può essere raggiunto direttamente se non tramite il FW

[etr]

Beh, ma se c'è il firewall tra i server e internet c'è comunque una protezione ... anche solo una configurazione transparent firewall. Io sono sempre dell'idea di dare l'ip pubblico alla eth del server

Se invece si parla di "risparmio" di IP, beh questo è vero ...

[davide73]

L'obiettivo principale è quello di risparmiare indirizzi IP soprattutto per quei servizi come le iLO ed i server di backup che non devono pubblicare su internet nessun servizio e che amministriamo attraverso VPN.

@WizOfOz: i firewall Clavister all'inizio hanno una gestione più complessa ma quando prendi confidenza con il client di gestione FineTune non li lasceresti più. Implementano anche un sistema di versioning con cui puoi risalire ad una delle precedenti configurazioni.

[WizOfOz]

si le prime configurazioni le ho fatte io e ho usato il FineTune... ma per un singolo cliente non mi mettevo a studiare in prodotto proprietario a alla fine ho passato il tutto a un tecnico Clavister Italia

[davide73]

Beh, ma se c'è il firewall tra i server e internet c'è comunque una protezione ... anche solo una configurazione transparent firewall. Io sono sempre dell'idea di dare l'ip pubblico alla eth del server

Se invece si parla di "risparmio" di IP, beh questo è vero ...

In settimana abbiamo ottenuto due classi /24 ripe
Quindi sto pensando di rivedere l'utilizzo del NAT ... mi viene male solo a pensare di cambiare gli ip a tutti i server

[SkyWebHosting]

Buongiorno,
In questo caso quindi potrebbe convenirti subnettare le due /24 ed utilizzare il Clavister come device di L3 e fare routing.
In questo modo avresti i server su indirizzo pubblico ed inoltre protetti dal firewall ed isolati fisicamente al L2 dal routing e switching. In questo modo tutto il traffico passerà dal Clavister.

Inoltre il NAT non aggiunge sicurezza al sistema in quanto non è una metodologia indicata per aumentare la sicurezza.

[SkyWebHosting]

Per l'accesso all'amministrazione puoi sempre utilizzare una VPN su una subnet privata dove fai risiedere le tue interfacce iLO.

[davide73]

Ciao,
il Clavister attualmente lavora gia come device L3, mi potresti dare qualche informazione in più su come muovermi per ottenere questa configurazione ?

PS:Conosci i prodotti Clavister ?

Buongiorno,
In questo caso quindi potrebbe convenirti subnettare le due /24 ed utilizzare il Clavister come device di L3 e fare routing.
In questo modo avresti i server su indirizzo pubblico ed inoltre protetti dal firewall ed isolati fisicamente al L2 dal routing e switching. In questo modo tutto il traffico passerà dal Clavister.

Inoltre il NAT non aggiunge sicurezza al sistema in quanto non è una metodologia indicata per aumentare la sicurezza.

[SkyWebHosting]

Fondamentalmente dovresti usare il Clavister come un router che ruoterà i pacchetti tra le diverse subnet.
Potresti dividera una /24 in 8 /27 per esempio ed inserire i frontend in una subnet ed i mail server in un'altra subnet.

Una soluzione ottimale secondo me, da valutare se il tuo appliance lo permetta sia sotto il profilo delle performance che delle funzionalità, metterei su un'interfaccia il cavo che va sull'uplink del provider, sulla seconda ruoterei una o due subnet e sulla terza metterei i back-end su classe privata.

In questo modo i db del backend non sono ragiungibili dal pubblico ma solo dal frontend (ovviamente con due schede dir rete).

L'unico problema è che il clavister dovrà lavorare il doppio in quanto ogni singola richiesta genererà traffico sia sul frontend che sul backend, ma in questo caso hai un sistema two-tier con un firewall di front end ed unno di backend.

Se hai anche la possibilità di incapsulare il traffico con lo 802.1q in VLAN potresti anche isolare i singoli frontend all'interno della stessa subnet pubblica per esempio.

Alternative ce ne sono tante, ti consiglio però che il tutto sia fatto con cognizione. Se non sei in grado ti consiglio di richeidere a qualcuno che ha esperienza in questo genere di soluzioni. Le conseguenze potrebbero essere letali per la soluzione.

[davide73]

Sto valutando anche di migrare verso una soluzione in bridge con il firewall trasparente, anche se dalla documentazione Clavister gli esempi non sono molto chiari.

Con il subnetting una /27 la perderei per assegnare gli ip all'interfaccia wan, corretto ?

Fondamentalmente dovresti usare il Clavister come un router che ruoterà i pacchetti tra le diverse subnet.
Potresti dividera una /24 in 8 /27 per esempio ed inserire i frontend in una subnet ed i mail server in un'altra subnet.

Una soluzione ottimale secondo me, da valutare se il tuo appliance lo permetta sia sotto il profilo delle performance che delle funzionalità, metterei su un'interfaccia il cavo che va sull'uplink del provider, sulla seconda ruoterei una o due subnet e sulla terza metterei i back-end su classe privata.

In questo modo i db del backend non sono ragiungibili dal pubblico ma solo dal frontend (ovviamente con due schede dir rete).

L'unico problema è che il clavister dovrà lavorare il doppio in quanto ogni singola richiesta genererà traffico sia sul frontend che sul backend, ma in questo caso hai un sistema two-tier con un firewall di front end ed unno di backend.

Se hai anche la possibilità di incapsulare il traffico con lo 802.1q in VLAN potresti anche isolare i singoli frontend all'interno della stessa subnet pubblica per esempio.

Alternative ce ne sono tante, ti consiglio però che il tutto sia fatto con cognizione. Se non sei in grado ti consiglio di richeidere a qualcuno che ha esperienza in questo genere di soluzioni. Le conseguenze potrebbero essere letali per la soluzione.