Newsgroup: it.comp.sicurezza.varie
Titolo: Dps

Salve a tutti,
ancora non facciamo il ns meritato dps, guardando con un amico, che 
tempo fa ci ha configurato un firewall con server di posta, antivirus 
centrale incluso, ci siamo posti questo quesito: bisogna installare per 
ogni macchina un antivirus? I dati che andiamo a gestire risiedono su un 
server linux, autenticazione con password all'accesso ed il pc lo usiamo 
con alcuni programmi tipo skype e molta posta elettronica da dove 
inviamo fatture, preventivi, foto etc etc.
Grazie tutti
Axel

 ogni macchina un antivirus?
Sě, su tutti i pc che hanno accesso ai dati

Sě, su tutti i pc che hanno accesso ai dati
Quale punto dell'allegato B prevede necessariamente un antivirus?
-- 
Bye, Yorgos
To send me an email, please change loose with free

 
16. I dati personali sono protetti contro il rischio di intrusione e
dell'azione di programmi di cui all'art. 615-quinquies del codice penale,
mediante l'attivazione di idonei strumenti elettronici da aggiornare con
cadenza almeno semestrale.
Giustamente il legislatore non ha detto "antivirus" perchè non poteva dirlo.
Il punto 16 non significa necessariamente "ANTIVIRUS" -- se riesci a farlo
in altro modo fallo (per esempio in alcuni Sistemi Operativi viene bene
montando eseguibili e librerie in partizioni read-only, in altri firmando
elettronicamente con tecniche di hashing gli eseguibili, in altri
ancora ... non esiste solo Microsoft...) 
-- 
AB

Il punto 16 non significa necessariamente "ANTIVIRUS"
Era proprio questo il punto che volevo saltasse fuori. Non sempre č
necessario un antivirus!


 dirlo.
Ma lo ha pensato. E, quello che piu' importa, praticamente tutti hanno 
capito cosi', compresi quelli che dovranno fare applicare la norma ;-)
Gia' il fatto che i client siano windows e usino web e posta vi espone
a rischi. Ancor di piu' se usate dei dispositivi di storage rimovibili
(non so come sia progettato il vostro antivirus centrale, ma dubito si
possa prendere cura di un CD-ROM arrivato da un cliente).
Per quanto riguarda gl ialtri sistemi citati, considera che quella che
richiede il legislatore e' una misura proattiva, mentre montare dischi
write-only o firmare gli eseguibili son norme di buona pratica che, in
questo caso, non mi sembra che soddisfino le richieste.
Fabio

 
Il read-only e' certamente una tecnica difensiva e basta.
L'hashing e' proattiva perchè riverifico la genuinita' dell'eseguibile che
vado ad usare regolarmente (idealmente tutte le volte che lo carico in
memoria) e se la verifica fallisce non eseguo! In particolare l'hashing
degli eseguibili puo' essere molto piu' efficace degli antivirus soliti
perche' protegge anche dai virus *ignoti* -- mentre gli antivirus che trovi
nelle solite scatoline in giro hanno il grosso difetto che il virus per
fermarlo gli deve essere noto (il che significa che qualcuno deve fare da
agnello sacrificale per aggiornare l'antivirus a favore degli altri... mai
pensato a questo?). Il principale difetto di questa tecnica e' la quantità
industriale di cicli di CPU che si divora ad ogni lancio di programma... il
secondo è la difficolta' amministrativa degli aggiornamenti di sistema (un
bel casino lo ammetto, o hai un sysadmin con gli attributi che gli fumano o
lasci stare).
Comunque mi rendo conto che nel 90% dei casi il punto 16 dell'allegato B
nelle PMI italiane significa "antivirus". E mi sta anche bene quando mi
parlano di antivirus in ministeri o banche dal lato client. Mi inalbero un
po' di piu' quando in certi ambienti mi parlano di antivirus dal lato
server o mi dicono "il mainframe o il server unix non e' soggetto a codice
maligno" (dimenticando che il padre di tutti i worm partito dall'MIT negli
anni '80 fu scritto sotto Unix...).
-- 
AB

 
Necessario no, purche' tu abbia una tecnica alternativa valida per
soddisfare il punto 16. E dal momento che il d.lgs.196/2003 prevede
l'inversione dell'onere della prova (art.15 del decreto combinato con
l'art.2050 del Codice Civile), il problema e' che se qualcuno te lo
contesta non sara' chi te lo contesta a dover provare qualcosa, sarai tu a
dover provare che la tua tecnica alternativa e' valida.... bella fregatura
eh?
Dura lex, sed lex  :-(
-- 
AB


Potresti spiegarmi esattamente cosa intendi per '..hashing degli 
eseguibili..'  ???
E' una modifica agli eseguibili degli applicativi che vengono usati ?
E con che strumenti viene eseguita?
Grazie e ciao
RobertoA

E' una modifica agli eseguibili degli applicativi che vengono usati?
Sostanzialmente, c'e' un programma - m'invento un nome: HashScan :-) - che
ha un database di hash.
Quando esegui una qualsiasi applicazione, HashScan verifica che il file da
cui parte corrisponda all'hash. Non e' una cosa troppo costosa perche', in
fondo, basta controllare dimensione ed alcune zone del file: a meno che il
virus non conosca a tal punto uno specifico eseguibile da potersi inserire
al suo interno (con la sicurezza di essere attivato) se l'hash corrisponde
vuol dire che il file non e' stato modificato da un virus.
A quel punto il file e' marcato "pulito" e fino all'arresto del sistema e'
autorizzato a partire; ovviamente, scritture su quel file ed operazioni di
tipo furbo (rename, ecc.) lo marcano nuovamente come "sporco".
E i programmi sconosciuti non possono essere mandati in attivita', perche'
HashScan non li conosce e quindi prima di tutto domanda conferma.
Questo non ti difende contro la patch scaricata da Astalavista che DICE di
essere il crack per Budiulnet 4.2, e invece e' un trojan tipo Bacterio. In
quel caso HashScan dice "Questo file non lo conosco, sei sicuro di volerlo
eseguire?", tu clicchi "Sicuro!", e l'attimo dopo bye bye hard disk.
In un caso del genere ci vorrebbe un antivirus possibilmente euristico. Ma
nessuno vieta di usare entrambi gli approcci in parallelo.
Leonardo
-- 
"Se e' vero che Linux in se' e' gratis, non lo sono le indispensabili
interfacce grafiche (X, KDE ecc.) che consentono alle persone normali
di utilizzarlo."                    -- Jason Matusow, Microsoft Corp.

 
Intendo quella tecnica "antivirus" nota anche come "controllo di
integrita'".
Ormai l'antivirus si e' di fatto standardizzato sulla tecnica dello
scanning (per ovvie e ragionevoli questioni di efficienza) che ci siamo
dimenticati che esistono (esistevano?) altre due  tecniche ed una di queste
e' l'integrita' che consiste nel verificare che il programma che ho sul
disco sia ancora quello _noto_ che avevo all'origine e di cui mi _fidavo_ .
Faccio un esempio sul nostro sistema linux (ma su un qualsiasi altro Sistema
Operativo non cambierebbe il concetto):
1. quando ho installato mysql abbiamo verificato che
l'eseguibile /usr/bin/mysql aveva un hash md5 di:
75380b1532819c3ba23f3bc6f0e7b5e3
2. se siamo paranoici andiamo a verificare questo hash TUTTE le volte prima
di andare a rieseguire mysql, se no rieseguiamo l'md5sum di mysql (e
degli altri eseguibili) ogni notte o ogni fine settimana.
3. se l'hash non corrisponde con quello che avevamo al momento
dell'installazione, non sappiamo che cosa sia successo, ma sappiamo che
l'eseguibile non e' quello che dovrebbe essere e non ce ne fidiamo...
Tutto questo lo facciamo per qualunque pezzo di software (eseguibile, batch,
applicativo) di sistema, scritto in proprio o acquistato.
PREGI: 
_Non dobbiamo conoscere il virus per rilevarlo (molto utile in ambienti
ostili dove l'attacco non viene necessariamente dall'esterno, si pensi ad
un ente bancario/finanziario dove i soldi girano in abbondanza o dove ci
sono informazioni tali che e' pensabile che qualcuno possa pagare un
insider per ottenerle... per esempio militare o ricerca chimica,
farmaceutica, aerospaziale... ). 
DIFETTI: 
_Cicli di CPU a gogo.
_Un casino amministrativo, devo rifarmi il registro degli "hash buoni" ad
ogni aggiornamento di software (applicativo o di sistema).
_Se non si sta attenti (e prima o poi capita) un aggiornamento lecito passa
per un attacco.
Lo scanning (che e' la tecnica usata da tutti gli A/V gialli o di qualunque
altro colore in commercio) e' stato adottato perche' il 99 percento degli
utenti PC non puo' permettersi simili casini amministrativi.
Quello che sostenevo all'inizio del thread, pero', e' che da certi utenti
(leggi GRANDI UTENTI) mi aspetto che per certi server, mainframe e grandi
sistemi possano anche permettersi di pensare un po' piu' in la del mio
salumiere e di mia figlia dodicenne che loro si, giustamente, nella tecnica
dello scanning trovano tutto quello di cui hanno bisogno....
-- 
AB

 vuol dire che il file non e' stato modificato da un virus.
Scusa un chiarimento:
se l'hash di due file è identico -> i due file sono uguali?


Probabilita' matematiche (specie in MD5) piuttosto remote. Se poi oltre
l'MD5 tieni conto anche di qualche altra caratteristica (per esempio
dimensione e permessi) le possibilita' di una c.d. "collisione" sono piu'
remote di quelle di fare 5+1 al superenalotto...
-- 
AB

_Cicli di CPU a gogo.
Ma nemmen poi tanto, io credo. Salvo casi specialissimi penso che non
serva esaminare tutto il file, ma solo le sue aree "attive"... quelle
che l'OS utilizza per lanciare il codice, che sono note. E inoltre in
ogni caso il costo di lettura c'e' anche con lo scan-on-execute; solo
si fa un MD5 invece di passare tutto alla macchina a stati che esegue
la scansione per firme o euristica. Io credo che l'MD5 costi forse un
po' di meno, a parita' di byte trattati.
Sarebbe invece interessante - dovremmo coinvolgere Paolo Monti, se ci
legge - discutere delle tecniche di accelerazione di questa scansione
(per esempio - **se** posso fidarmi del fatto che intercetti tutte le
scritture, rename, ecc., sui file, allora una volta scandito il file,
e trovatolo sano, non mi serve riesaminarlo fino al successivo reboot
del sistema; anziche' ri-hashare il file mi basta cercarne i dati nel
mio database interno. Oppure... tenendo in memoria un elenco dei file
piu' utilizzati, nei reboot passati, posso esaminarli durante i cicli
di idle successivi al prossimo boot e trovarmeli "freschi").



Certo, sono funzione diretta del livello di paranoia del sysadmin e
geometrica del numero di utenti serviti ;-)
Se si scandisce tutto il file eseguibile, ad ogni sua riesecuzione (o piu'
rigorosamente ad ogni sua ricaricamento in RAM -- che non e' la stessa cosa
necessariamente) in un sistema multiutente che serve centinaia di utenze la
cosa si fa seria... infatti come accennavo io e hai meglio dettagliato tu
si scende a compromessi; si aspettano cicli di idle, si fa al boot, (se si
fa il boot -- noi abbiamo sistemi accesi da mesi...) o durante le notti del
weekend.
-- 
AB