Newsgroup: it.comp.os.linux.sys
Titolo: idea malata su bridge e antivirus

Visto un casino capitato da un cliente, dove un bel portatile (con virus 
allegato) collegato alla rete winzozz ha creato uno stop alla 
produzione, mi è venuta st'idea malata:
Classica rete a stella, tot switch in cascata per ufficio/dipartimento.
La mia mente malata, visto che tutto il resto è già implementato (mail 
server con antivirus, client pure), ha partorito questa idea:
possibile implementare su un bridge un antivirus? so che controllare i 
frame ethernet non è facile e sicuramente cpu intensive ma pensavo di 
mettere una minibox per dipartimento/ufficio.
Avete idee oppure è una minchiata?
Mike.

 Avete idee oppure è una minchiata?
IMHO l'ultima :-) 
Fabio

mike wrote:

Forse puoi istruire snort per riconoscere i pattern dei virus e modificare
iptables o route in modo da tagliarti fuori le macchine infette. Pero' mi
sembra un poco un accrocchio.
Luca
-- 
<<>><<>><<>><<>><<>><<>><<<>><<>><<>><<
Luca Paredi
Computing technical supporter              
Universita' degli Studi dell'Insubria  
<<>><<>><<>><<>><<>><<>><<<>><<>><<>><<

 Di chi era il portatile?
di un esterno.. e ora il titolare è paranoico in merito.

 Luca
Ecco, pensavo ad una cosa similare. Il mio problema fondamentalmente è 
come fare sta cosa: ebtables passa a snort che legge e confronta i patterns.
Info in merito?



Se il titolare ha un sacco di soldi da spendere, cisco
sta facendo qualcosa del genere...Network Admission Control
(presentato al cisco secure tour 2005)
http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.html
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 Info in merito?
A me sembra non fattibile: dovresti sostituire ogni switch con una linux
box...ed immagina che onere computazionale avresti.
ebtables, del resto, non dovrebbe passare nulla a snort, visto che snort
cattura i pacchetti direttamente dall'interfaccia messa in modalità
promiscua.
Molto più banalmente, i consulenti/esterni vanno messi in una vlan
isolata, dove non possano fare danni.


 di un esterno.. e ora il titolare è paranoico in merito.
Ok.
Non e' la risposta che cercavi, ma la soluzione (IMHO) e'
prevenire invece che curare. Analizza quali sono state le
cause ed intervieni su quelle. Perche' il tizio ha potuto
collegarsi alla rete aziendale? La cosa si puo' ripetere?
Cosa puoi fare per evitarlo? Che cosa fare per limitare i
danni qualora dovessero accadere ancora eventi simili (un
worm in LAN)? Ci sono strumenti e pratiche per affrontare
ognuno di questi problemi.
| possibile implementare su un bridge un antivirus? so che 
| controllare i frame ethernet non è facile e sicuramente 
| cpu intensive ma pensavo di mettere una minibox per 
| dipartimento/ufficio.
Quello che vorresti fare richiederebbe che a filtrare sia
lo switch, perche' occorrerebbe analizzare il traffico di
rete diretto da qualsiasi porta a qualsiasi porta (fisica
ethernet). Questo oltre a tutte le altre complicazioni.
Fabio

 
http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.html
Anche microsoft lavora ad una cosa simile al nac di cisco (microsoft 
nap). Mi pareva si muovesse qualcosa anche nel open source, ma forse
mi ricordo male. Tra l'altro, vedo ora che il client cisco e' open.
Fabio

 isolata, dove non possano fare danni.
Ci ho già provato, non ci sente da quell'orecchio.
Mike.

 
http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.html
Beh, non è proprio quello che dice lui: NAC si "limita" a non fornire 
accesso ai supplicant non "validati", e a confinarli un quarantena.
C'è anche il NAP di MS, che fa praticamente la stessa cosa...
Il limite è che ogni client che deve accedere deve però avere l'agent 
installato. 2 palle...
Stai prima a mantenere una DMZ ove attestare dei servizi di appoggio ben 
blindati, soprattutto se non sei una azienda enorme...

 Ci ho già provato, non ci sente da quell'orecchio.
E' probabilmente la cosa più sensata, però...
[1] quello vecchio, con i connettori "vampire"...

 coassiale[1], sì...
Potrebbe valutare un sensore snort-clamav attaccato a una porta 
monitor dello switch e un event correlator (sec, logsurfer) che
ne analizza i log e blocca le porte dello switch in caso di una
sequenza di eventi predefinita.
Fabio

 blindati, soprattutto se non sei una azienda enorme...
Quoto.




Bella, ma...se lo switch è bello carico, sicuramente non si riuscirebbe
a monitorare tutto.
E poi dovresti automatizzare lo shutdwon della porta incriminata...uhm,
beh, sulla proattività di questo tipo ho sempre qualche dubbio. ;-)


 Avete idee oppure è una minchiata?
Vedi se i Fortigate della Fortinet non facciano al caso tuo...
Alessio

 [1] quello vecchio, con i connettori "vampire"...
Parli del tick-ethernet?
-- 
Sidewinder
"Oops!" - Shannon Foraker, Ashes of Victory

 mandi in crisi la rete aziendale, no? :-)
Vero, anche se continuo ad avere grosse perplessità sull'approccio.
Che senso ha far entrare qualcuno in rete perchè "afferma" di essere 
pulito e controllato?
Non potrebbe essere malato terminale e non saperlo?
Bah.. Cmq, qui è OT..

 beh, sulla proattività di questo tipo ho sempre qualche dubbio. ;-)
Scherzi a parte, le soluzioni sono altre, e sono gia' venute fuori:
dall'auth 802.1x, al "confino" per gli esterni, all'hardening delle
macchine interne. E poi non s'e' ancora capito cosa avrebbe causato
lo "stop alla produzione", che mi sembra un dato essenziale. Quella
sopra potrebbe, forse, essere una cosa in piu' e implementabile con
bassi costi ma, da sola, e' del tutto insufficiente. E non solo per
questioni legate al carico di rete: in quel modo (e anche con altri
sistemi simili) hai una visione parziale del traffico: non vedi gli
archivi compressi, non vedi tutto il traffico cifrato ed encodato e
tutto il traffico, in genere, per cui il layer applicativo maschera
allo scanner i contenuti. Oltre ai limiti stessi di snort-clamav.
Fabio

Prova un pò a vedere questa soluzione zyxel:
http://www.zyxel.com/product/model.php?indexcate=1093509676&indexFlagvalue=1093509635
ciao
Sergio