Newsgroup: it.comp.os.linux.sys
Titolo: scheda virtuale etho:0 iptables

Ciao a tutti,
ho un firewall Linux Red Hat 7.3 con due schede ethernet; la prima
ovviamente va in cross ad un router HDSL mentre la seconda alla LAN interna.
Ho un server web sul quale faccio NAT delle porte 80 e 443 dall'ip pubblico
all'ip privato.
Bene; è necessario aggiungere un ulteriore server web che va in ascolto
sempre sulla 80.
Mi prendo un altro ip statico (tanto ne ho 16!!!) e aggiungo una interfaccia
virtuale eth0:0 sulla macchina Linux. Faccio NAT di tutto quello che arriva
sulla 80 della ethernet eth0:0 alla porta 80 del server web aggiuntivo.
Il problema è questo: siccome ho definito delle policy abbastanza
restrittive che fanno capo all'ip statico della eth0 (la prima, quella
reale!), devo aggiungere tutte le tables relative alla eth0:0 (l'interfaccia
virtuale) altrimenti il secondo ip statico che butto su rimane scoperto??
Ciao, grazie mille.
Francesco Co.

 virtuale) altrimenti il secondo ip statico che butto su rimane scoperto??
Ovvio che si.
Altrimenti funzionarebbe!!!
Magari ti fai loggare tutti i pacchetti scartati e vedi quelli che sono
bloccati
E aggiungi solo le regole necessarie.
MA ribadisco: perchè complicarsi la vita col natting quando potresti avere
nuna bella DMZ???
Proxy arp e via... magari i webserver sono anche sulla lan, e allora il FW
serve a poco...
se non a bloccare rumenta in uscita
Max

 virtuale) altrimenti il secondo ip statico che butto su rimane scoperto??
Si. Se non centralizzi devi farlo per ogni macchina. Se centralizzi, sulle
singole reimposti solo la redirezione IP alias > IP real.
Ti consiglio vivamente di usare LVS ed un solo IP: poi dietro, o a bordo dei
due master, il firewall.
Hai in più un load balancer, completo di fault tolerance, semplifichi la
situazione a livello gestione ed usi 1 solo IP per tutti i server invece di
fare routing sul firewall.
In più semplifichi le policy, il che vuol dire che le rendi più sicure.
Che ne pensi?
Ciao.
Techs.

Grazie innanzitutto per i validissimi consigli e suggerimenti.
Vorrei capire una cosa: il gestore dell'HDSL mi ha dato si 16ip ma sono
tutti della stessa classe e non di due classi diverse; pertanto la dmz, a
mio avviso, dovrebbe essere virtuale.
Mi spiego con un esempio:
                                                ROUTER HDSL
                                                            |(etho ip
Internet)
                                                FIREWALL LINUX
                                                            |
|-eth1-----------LAN (192.168.0.x/24)------------
                                                            |
AS/400, PC, server interni, ecc.
                                                            |
|-eth2-----------DMZ (192.168.100.x/24)---------
Server IIS5 (grrr), postale
Secondo me, e vi prego di correggermi se è errato, faccio nat soltanto delle
porte che voglio rendere pubbliche nelle macchine che si trovano sulla DMZ;
separando i due segmenti di rete, casomai qualcuno da fuori bucasse qualche
server che offre servizi Internet, comunque si fermerebbe lì senza arrivare
alla LAN interna, in quanto le policy di forwarding dei pacchetti dalla LAN
alla DMZ sono molto restrittive, e permettono alla DMZ di accedere alla LAN
solo come risposta a pacchetti inviati dalla LAN (--state established,
related).
Graditissima vs. opinione in merito, ciao, grazie mille.
Francesco Co.

 mio avviso, dovrebbe essere virtuale.
Vabbč...
parti da leggere qui...
Stessa classe o no, la DMZ si puň fare.
MAx

 mio avviso, dovrebbe essere virtuale.
Che vuol dire?? Di quante classi vuoi che te li dia??
A te serve un IP per ricevere le chiamate, la DMZ può essere anche su rete
privata con indirizzo non routable! Che sarebbe anche meglio...
Il creare una DMZ di IP pubblici su device virtuali (o no), ritengo sia
inutile.
Se l'attaccante ottiene privilegi sul server se ne fa una cippa delle regole
di iptables, ed entra diretto il LAN anche se la device non ha IP ma è
collegata fisicamente!
Con i privilegi di root sai che ti frega..
Se vuoi isolare i server devi mettere SOLO l'IP_pubblico/IP_DMZ sulle eth0,
ed isolarle anche fisicamente onde evitare attachi layer2 tipo
man_in_the_middle/IP_spoofing.
Poi tieni una eth0 di una consolle di amministrazione collegata alla DMZ,
magari senza IP, lo attivi quando ti serve, e gli fai fare da sensore IDS
(disabilita anche l'ARP altrimenti uno bravo ti sgama lo stesso).
I server su uno switch DIVERSO da quello della LAN, se sono sullo stesso con
ARP_SPOOFING ed ARP_POISONING con ettercap hai la mappa della rete in 20
secondi!
A questo punto, dal firewall regoli il traffico in ingresso in DMZ come ti
pare, se per disgrazia uno ti fa un exploit, ti sega i server perchè si
incacchia parecchio (ma tu hai un bel backup VERO!!) ma deve ripartire da 0
per attaccare la LAN, e tu hai il tempo di trovarlo e fargli un mazzo cosi!
(se sei fortunato :-) siamo ottimisti, se è bravo ti fa il bidet e non te ne
accorgi....)
Quindi a mio modo di vedere 16 IP servono quasi ad una mazza per una sola
realtà (se sei un ISP è diverso), penso col massimo dello spreco, a qualcosa
tipo:
DNS1
DNS2 slave
WEB farm http su load balancer (ORRORE IIS!!!!!)
WEB farm https su load balancer (bis di quanto sopra)
FTP se serve, con 1 Gb di spazio e i laser fotonici spaziali puntati contro
(stile se lampeggia il cdrom ti disintegro)!!!
(scherzo, può esserci un lato positivo in un FTP bucato, un mio collega si è
ritrovato in un colpo solo tutti i giochi della EA sports sul server!! Non
ti dico suo figlio la gioia!!)
MX 1
MX 2 (non si sa mai) backup
Application server e vari da valutarsi, troppo particolari.
Firewall 1                |
Firewall 2 backup    |> proxy (su privata) e portale intranet
Ma questo lo potresti fare con il router hdsl e poi  impostare le chains
sulle singole macchine, con i firewall che filtrano solo la LAN, ma è molto
laborioso.
Volendo fare un bel lavoro solo sui firewall riderigi le chiamate sulla 25,
21, 110, 443 ed 80 a delle macchine non pubbliche e nattate.
Per la LAN, sul FW per i servizi chiave POP3 e SMTP fai un tunnel ssh sul MX
per non farti sniffare le password in chiaro.
Per non incasinare le tables sui FW e gestire il FW di scorta, usa un
programma come Shorewall che genera le tables a partire da variabili legate
all'IP della macchina, eventualmente fai le modifiche del caso, nello script
di failover cambi del tutto l'IP e fai ripartire shorewall che dovrebbe
rigenerare le tables correttamente.
Forse riesci a gestire tutto anche direttamente in LVS, devi solo stare
attento ai collegamenti fisici dei due director.
Devi limitare il più possibile le informazioni che possono essere raccolte
sulla LAN.
La fregatura è che i servizi tipo SMTP (se non smanacci alla grande il
server) negli header dei messaggi un uscita, lasciano IP della macchina che
ha inviato il messaggio, fornendo un'informazione preziosa sulla topologia
della LAN.
Una soluzione con più aspetti utili: webmail su server Unix (NON IIS che non
è virus free) per la intranet e niente client mail sulle macchine, così
eviti che 
12045998766
 messaggi al giorno tipo "guarda la cippa di mio
cugino.." finiscano sulle workstation a fare catastrofi, visto che hanno
allegati 20/30 tipi diversi di Trojan che chiamano dall'interno un IP
pubblico, il firewall (con la policy che dici established) le fa passare ed
uno è bello che entrato! (stile ssh per capirci)
Poi li disintegri!
In più gli utenti si possono guardare la posta da qualunque posto se imposti
bene https (ti fai un certificato e lo fornisci solo ai dipendenti che ne
hanno bisogno)
e puoi fare backup su una sola macchina.
Come vedi le soluzioni possono essere molte, e gli strumenti per attuarle
moltissimi.
Spero di essere stato chiaro, non sempre lo sono.
Se serve un consulente per un progettino :-)) mailami.
Buona fortuna.
Techs