Newsgroup: it.comp.os.linux.sys
Titolo: Sicurezza reti KVM over IP

In riferimento ad un mio vecchio thread, stavo valutando
come mettere in sicurezza una rete dedicata alle KVM over IP.
Nel mio caso si tratta di una VLAN associata alla DRAC della DELL.
Stando alla documentazione non mi pare sia supportato alcun sistema
di sicurezza, se non un banale filtro sugli IP sorgenti.
Partendo dal presupposto che il server con la KVM non sia sotto
la mia gestione (ergo: il cliente fa quel che vuole sulla sua macchina)
come posso evitare che un pirla buchi la KVM e faccia danni in giro?
Da quel che leggo, la DRAC assegna (spero) un mac differente da quello
delle nic integrate. In questo modo, sullo switch, posso forzare la
VLAN50, sulla porta 20, a funzionare solo tramite il macaddress
corretto.
Se un pirla si autoimpostasse il mac di un altro cliente, non andrebbe
da nessuna parte.
Ma se il solito pirla cambiasse il mac alla propria nic, impostando
quello della sua KVM? finirebbe automaticamente nella vlan corretta
con l'intera linux-box, e potrebbe fare dei danni.
Voi come vi tutelereste? sopratutto considerando che la vlan della
kvm potrebbe (come da precedente thread) mettere in connessione sia
una rete pubblica non protetta, sia una rete interna protetta.
Non saprei nemmeno come configurare il firewall, sinceramente. Una
volta autorizzato il traffico kvm, sei dentro la rete interna ed il
traffico malevolo potrebbe essere veicolato usando le porte tcp/udp
della kvm over ip.
Son tutto orecchi, non ho proprio idea di come poter mettere in
sicurezza una piccola rete KVM

 Voi come vi tutelereste? 
Cambiando modello di KVM e scegliendone uno più serio.
Se non vuoi mettendo degli ALERT sull'operazione di disconnessione della
porta (e magari mandando in shutdown una porta che sia stata staccata).
Personalmente però metterei un banale arpwatch che monitori eventuali nuove
macchine su quella rete e mi avvisi.
Il fatto è che se l'attaccante ha già fisicamente accesso allo switch tu sei
regolarmente fottuto o fottibile.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 regolarmente fottuto o fottibile.
No, non ha fisicamente accesso allo switch.
Ha solo accesso al suo server, da remoto, e devo fare in modo che non
possa accedere alla VLAN della KVM con un server ma solo con la KVM
vera e propria.
Mentre invece, per il collegamento, tramite VLAN KVM della lan pubblica
e lan privata? Come faresti?
In pratica avrei questo:
lan pubblica -> vlan kvm -> lan privata locale.
non c'è firewall, non sarebbe di alcuna utilità per i problemi suddetti.
non saprei riconoscere traffico kvm legittimo da traffico di rete
veicolato sulla stessa vlan della kvm sulle sue stesse porte (proprio
nel caso un utente spostasse il mac autorizzato dalla kvm al server)

 veicolato sulla stessa vlan della kvm sulle sue stesse porte
Nemmeno con l7-filter?


 
non ho ben chiaro come funzionino gli oggetti che condividono un solo 
connettore, ma visto che il mac identifica univocamente l'interfaccia, se 
su quel connettore si affacciano due oggetti diversi ma con lo stesso id, 
qualche problema di connettivita' dovrebbe verificarsi...
o no?
[cut]
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 Nemmeno con l7-filter?
Si, ma non risolverebbe il problema.
A livello di switch l7-filter non interverrebbe, perchè se sullo stesso
apparato ho connessi altri 10 server, tutti nella stessa vlan della kvm,
l7-filter non ci mette becco (visto che il traffico non transiterebbe
attraverso un firewall, ma sarebbe intra-switch).
O faccio una vlan kvm per ciascun cliente, ed è improponibile, oppure
provo con le PVLAN, dove la vlan kvm viene splittata in pvlan, una per
ciascun cliente, ma anche in tal caso, sarebbe improponibile.
Però, così facendo, il cliente 1 non comunicherà mai con il cliente2
tramite la vlan della kvm.
a monte, nel router tuttofare, non faccio instradare le vlan delle kvm,
quindi chi è connesso allo switch1 non comunica con chi è connesso allo
switch2 e chi è connesso allo switch1 non comunica con gli altri dello
switch1 per via della PVLAN.

 o no?
Sicuro, ma i problemi dove sono, lato kvm (ed al malintenzionato non
gliene può fregar di meno) oppure lato server?
Il problema è che se affacciando due oggetti con lo stesso macaddress
a soffrire è la kvm, poco importa al malintenzionato, tanto lui accede
alla vlan tramite il server.
Il mio problema è proprio fare in modo che sia il server ad aver
problemi. Se cerchi di bucarmi la vlan e resti tagliato fuori, 'zzi tuoi
in pratica io ho una porta dello switch che veicola due vlan e questa
porta termina in una nic. su questa nic c'è sia una interfaccia normale
accessibile dal sistema operativo, sia una kvm, attestata ad una vlan
ben precisa.
un malintenzionato ci mette poco a cambiarsi la vlan ed il mac e ad
accedere alla lan della kvm (dove son presenti altri clienti) con
l'intero sistema operativo.
Una volta che si è cambiato la VLAN, può provare a bucare le
altre kvm.
Ma visto che questa kvm è accessibile sia dalla rete pubblica, sia
dalla rete privata, se un malintenzionato accedesse alla kvm avrebbe
già una mezza gamba sulla lan interna.
In pratica è così:
                  /--------> kvm ->--------------------\
                  |           |                        |
internet -> lan pubblica -> server -> firewall -> lan privata -> server
protetto
la vlan kvm può essere usata come ponte, teoricamente non possono
fare nulla di malevolo, se non avere connettività verso altre
kvm, ma non si sa mai.
Voi che dite? E' un non problema avere la vlan kvm che unisce la
lan pubblica e quella privata o ci possono essere complicazioni?

 O faccio una vlan kvm per ciascun cliente, ed è improponibile,
E perché dovrebbe essere improponibile? Questa è la soluzione più corretta.
Ad ogni cliente le proprie risorse.


 le nic integrate. In tal caso, non saprei come tutelarmi.
switchport port-security maximum 2
Ma significa che la KVM e l'host stan sulla stessa VLAN.
E non vedo altra strada, se vuoi avere un minimo di sicurezza.
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 Ad ogni cliente le proprie risorse.
Vacca miseria.
Quindi tu dici di creare tre vlan per ciascun cliente:
- vlan rete pubblica
- vlan rete protetta
- vlan kvm

 switchport port-security maximum 2
Non tutela affatto.
Esempio:
mac drac: XX:XX:XX:XX:XX:XX
mac nic integrata: YY:YY:YY:YY:YY:YY
il "maximum 2" autorizza al massimo 2 mac, e mi sta bene.
il cliente inverte i mac, o meglio, setta come mac della nic
integrata, quello che in realtà è della KVM.
il portsecurity non entra in funzione, perchè i mac son meno  di 2
ed il cliente si trova catapultato sulla vlan della kvm con una intera
macchina anzichè una kvm, e da li il passo è breve, dai e dai prima o
poi qualche cosa sfonda.
c'è da dire che nella vlan della kvm insistono solo le altre kvm, non
penso sia possibile bucare un server passando dalla kvm, spero.

 poi qualche cosa sfonda.
Hai dimenticato di quotare il resto:
[...]
Ma significa che la KVM e l'host stan sulla stessa VLAN.
E non vedo altra strada, se vuoi avere un minimo di sicurezza.
[...]
Traducendo: se tu stai proiettando una macchina in una VLAN piuttosto
che nell'altra affidandoti del fatto che ha un determinato MAC, il
problema è *tuo*, non del cliente...
Poi uno potrebbe obiettare che se si proietta la NIC su una VLAN diversa
da quella che consente la raggiungibilità del server, è un po' difficile
che la macchina sia ancora raggiungibile per proseguire l'opera di
hacking...
Ma son quisquilie.
Smistare tra VLAN sulla base del MAC è una troiata, se l'obiettivo è
ottenere sicurezza.


 - vlan kvm
Sì. Io ne ho anche di più per certi clienti, ma lo standard è di 3 vlan:
lan, dmz, pub. Poi ci sono quelle di gestione separate e condivise ma non
raggiungibili dai clienti.
Per esempio puoi dare:
da 1 a 1000 le tue reti
da 1500 a 1699 le LAN
da 2000 a 2199 le PUB
da 2500 a 2699 le DMZ
da 3000 a 3199 le KVM
da 3500 a 4000 le altre reti condivise o prese a cazzo...
Se tanto mi da tanto quando hai 200 clienti in housing sulla stessa rete
dovresti essere ben più che contento ed avere capitali per poter
rivoluzionare l'infrastruttura (senza contare che puoi arrivare a 500 già
con questa).


 integrata, quello che in realtà è della KVM.
... e si taglia la connettività.


 ottenere sicurezza.
Tu quindi faresti una sola VLAN per il cliente, e dentro li ci
butteresti anche la kvm?
In tal caso, il problema del cambio di vlan non sussisterebbe.
ma se son tutte reti separate, io come caspita le raggiungo ?
Mi ci vuole un apparato che faccia da routing tra vlan, ed a quel punto,
avrei nuovamente raggiungibili tutte le reti. In pratica sposto
il problema dalla vlan al router.

 butteresti anche la kvm?
1 Porta fisica = 1 VLAN.
Far passare più VLAN sulla stessa porta lo fai solo se tutte le VLAN le
puoi trattare "come un tutt'uno" dal punto di vista della sicurezza (es:
sono due VLAN a disposizione dello stesso cliente) *o* se hai il
controllo completo di entrambi gli apparati ai due capi del NIC (es:
segmenti trunk tra gli switch).
Se non sei in alcuna di queste condizioni, apri un buco di sicurezza, e
non c'è uscita da ciò.


 penso sia possibile bucare un server passando dalla kvm, spero.
C'è sempre il genio che resta loggato sulla console, eh.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 con questa).
Capitali a parte, supponiamo di averne 600 di clienti.
Tu, come faresti?

 ... e si taglia la connettività.
Poco importa, lui vuole andare a smanettare nelle kvm altrui.
Resta tagliato fuori da internet, ma altri danni magari li
riesce a fare se ha accesso fisico al server (e non allo switch)
In caso fosse collegato da remoto, appena sposta il mac resta
tagliato fuori.
A 'sto punto, quindi, è un problema che non sussiste. Poco importa
se un cliente riesce a saltare di vlan cambiandosi la rete, lo fa
e resta isolato.

 non c'è uscita da ciò.
Allora me ne sbatto allegramente.
Semplifico ulteriormente:
VLAN privata del cliente. E basta. Una sola VLAN per ciascun cliente.
Dentro li, ci veicolo anche la KVM.
Nel caso il cliente avesse una nic dedicata, anche quella nic va a
finire nella stessa VLAN.
Così, il router a monte, deve ruotare solo tra clienti e clienti, e non
anche tra le svariate vlan di ciascun cliente.
In pratica se il cliente avrà IP 10.10.10.1, la KVM avrà 10.10.10.2 ed
il mio router 10.10.10.3
Più semplice di così, non si fa. E dovrebbe essere abbastanza sicura
come soluzione, presumo, perchè a livello di router, taglio il traffico
tra le VLAN (così non si parleranno mai) se non dalla VPN del cliente
che apre un tunnel diretto nella propria VLAN


Allora stai sbagliando a definire il problema, semplicemente.
Ti faccio un esempio con le SUN: la scheda KVM che montano è del tutto
indipendente dal sistema (no NIC condivisa).
E' anche un sistema linux su CPU PPC, in tutto e per tutto.
Di cui la stessa Sun fornisce i sorgenti (e anche relativo SDK, se ben
rammento).
Nulla mi vieta di upgradare l'immagine e cacciargli dentro la versione
ricompilata da me, che mi porta ad una shell bash anzichè alla shell di
management che monta di default. E da lì devastare la tua lan dei KVM
esattamente come farei nello scenario "NIC condivisa" che dipingi.
Ergo: il problema di quello scenario non è la NIC condivisa. E' il fatto
che non ti permette di separare il traffico dei tuoi clienti.


 che non ti permette di separare il traffico dei tuoi clienti.
Si, probabilmente si, ma a 'sto punto creo UNA vlan per ciascun
cliente su ciascuna sezione di rete (pubblica e privata), poi
blocco la comunicazione, a livello di switch (semplicemente non
attivando il routing L3) tra le vlan. Che faccia quel
che gli pare il cliente, anche se fa stronzate, dalla sua vlan
non ci esce.

 Tu, come faresti?
Farei esattamente la stessa cosa ma suddividendo l'infrastruttura in almeno
6 isole autonome, tutte speculari, in modo da non avere più di 100 clienti
per isola.


 per isola.
Questo non è un problema, è già così.

 alla configurazione in caso di emergenza.
Bah... solo una questione di ordine. Alla fine non cambia molto tra una
config di 2000 righe e una di 2400.


 config di 2000 righe e una di 2400.
Infatti, io preferisco restare sotto il decimo della tua cifra.

 colorate).
Che consiglieresti, sia come switch 10/100 (con almeno 2 uplink giga),
sia fullgigabit, a 48 porte? (24 non mi bastano)
Dato che dovrà fare da switch per le KVM e LAN interna, non servono
grosse features se non il supporto alle VLAN/PVLAN ed il supporto LACP
(magari, ma non importa, la possibilità di limitare la velocità della
porta in singoli megabit)
Ci sarebbe un l'SMC6152L2 che fa tutto quel che mi serve ed anche
di più, è 48 porte, costa praticamente niente, fa anche rate limiting
sulla porta a tagli di singoli kbit, ma è "solo" 100mbit, visto che devo 
veicolare anche il backup, te cosa dici, avere la porta a 100mbit
rispetto una gigabit fa la differenza?
(io credo di no, alla fine metterci 3 ore anzichè 2 ore e 45 cambia 
poco. I server SAS hanno pochi dati da backuppare, come dimensioni,
i server SATA invece devono backuppare giga e giga di dati, ma dubito
che i dischi riescano a sostenere una trasmissione gigabit costante per
svariate ore considerato che nel frattempo devono anche servire i dati
agli utenti)
Solo che è un SMC...... Ne ho uno, ed a pelle mi sembra veramente un
giocattolo, nonostante un feature-pack.
(I procurve, che preferisco, hanno 1/50 di features e costano in media
3 volte tanto)
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 Le feature se non ti servono sono inutili :-)
Si, ma considero anche il rapporto qualità/prezzo.
I procurve fanno 10 "cose" ad esagerare, anzi, forse non superano le 5.
E costano 3 volte gli SMC (e lo dice uno che ha non meno di 10-12
procurve 2610, quindi li conosco bene)
Oggi una data feature non mi serve, ma se un domani servisse, sapere
di poterla usare è comodo, senza dover obbligatoriamente cambiare
l'intero switch.

 Se vuoi veicolarci anche altri servizi seri allora lo switch deve essere serio.
Confermo, è un ex linksys.
Erano giocattolini entrylevel e son restati tali pur raddoppiando
il prezzo, anche se ora il marchio è Cisco. Non mi piacciono proprio.
Basta guardare la gestione, via web o via console tramite "menu".
Come minimo poi salva una configurazione in formato binario come
praticamente tutti gli apparati SOHO.
Tra i due, SMC tutta la vita, almeno la gestione tramite console 
è vera e non a menu.
Al limite, prendo la versione gigabit, in caso di necessità: SMC8150L2,
tanto gli switch in un modo o nell'altro si riutilizzano, difficilmente
restano a prendere la polvere in un cassetto.
Te che dici?

 Te che dici?
Che non conosco gli SMC. Io ho a che fare con Cisco, HP e Brocade, tutto il
resto è un mondo sconosciuto :-)
