Hash dei log per la conformità al Garante

Post by xfilesit
Utilizzo Splunk per la racolta dei log centralizzata è funziona benino
ora ho il problema di calcolare l'hash e firmare digitalmente questi
log per la conformità al garante.

Premetto di non conoscere affatto bene la normativa, ma
perche' dovrebbero essere firmati e da chi?
perche' se ne dovrebbe calcolare un hash?
Qualora si dovessero svolgere queste attivita` (cosa che non credo),
non vedo quali siano i problemi tecnici a farlo.
A quanto ne ho capito io basta che i log non siano modificabili e
questo obiettivo viene raggiunto p.es. semplicemente masterizzandoli
su CD-ROM

Alessandro Pellizzari

2010-02-04 17:17:00 UTC

capito io basta che i log non siano modificabili e questo obiettivo
viene raggiunto p.es. semplicemente masterizzandoli su CD-ROM

Si`, ma non devono mai essere modificabili, nemmeno un nanosecondo dopo
che li hai scritti, quindi devi tenere una sessione aperta sul CD-ROM e
scrivere riga per riga li`. Non puoi farlo la sera o ogni ora, deve
essere in tempo reale.

Quella della firma non la sapevo nemmeno io, ma so che ci sono servizi su
Internet che offrono il servizio di logging remoto e di certificazione
della non modificabilita`.

Poi, come sappiamo, e` lo stesso root a configurare la propria macchina,
e puo` loggare come non loggare quello che vuole, ma tant'e`...

Bye.

THe_ZiPMaN

2010-02-04 17:33:42 UTC

capito io basta che i log non siano modificabili e questo obiettivo
viene raggiunto p.es. semplicemente masterizzandoli su CD-ROM

Dove sta scritto? Rileggiti le FAQ del garante, la mette giù in modo molto
differente rispetto alla prima lettura.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

twistedbrain

2010-02-04 17:43:04 UTC

capito io basta che i log non siano modificabili e questo obiettivo
viene raggiunto p.es. semplicemente masterizzandoli su CD-ROM

Dove sta scritto? Rileggiti le FAQ del garante, la mette giù in modo molto
differente rispetto alla prima lettura.

Quindi anche la demenza tecnica del garante non e` infinita.
Ma io mi chiedevo e con un logserver non acccedibile se non in lettura
e solo dall'auditor, i requisiti del caso non sarebbero
automaticamente rispettati? Ma e se poi il disco del logserver ci
lascia? Mi sa che comunque su CD ogni tanto e` meglio salvare i log.

THe_ZiPMaN

2010-02-04 18:01:28 UTC

capito io basta che i log non siano modificabili e questo obiettivo
viene raggiunto p.es. semplicemente masterizzandoli su CD-ROM

Dove sta scritto? Rileggiti le FAQ del garante, la mette giù in modo molto
differente rispetto alla prima lettura.

Quindi anche la demenza tecnica del garante non e` infinita.

non sarà infinita ma ci si avvicina molto. Prima ha partorito una normativa
tecnicamente valida (nella sua interpretazione restrittiva) ma inapplicabile
per via dei costi. Poi accortosi di aver fatto una cazzata ha distrutto
tutto ciò che c'era di tecnicamente valido rendendo la norma l'ennesimo
inutile balzello che le ditte sono costrette a pagare.

Post by twistedbrain
Ma io mi chiedevo e con un logserver non acccedibile se non in lettura
e solo dall'auditor, i requisiti del caso non sarebbero
automaticamente rispettati?

Va valutato in funzione della tua realtà. Se trattasi di uno studio di
commercialisti di 5 persone la risposta è sì, se si tratta di un'ospedale
con 1000 dipendenti la risposta è no.

Post by twistedbrain
Ma e se poi il disco del logserver ci
lascia? Mi sa che comunque su CD ogni tanto e` meglio salvare i log.

Teoricamente dovrebbe comunque rientrare nella 196/03 dato che nei log ci
sono dati personali (gli username), quindi saresti obbligato ad avere un
backup dei dati settimanale. C'è però da dire che se i log li mantieni per
almeno 7 giorni anche sulle macchine che centralizzi potresti considerare la
gestione centralizzata dei log alla stregua di un backup e quindi scamparla
in quel modo.

Io comunque faccio un salvataggio mensile su DVD.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

twistedbrain

2010-02-04 18:13:09 UTC

Post by twistedbrain
Ma io mi chiedevo e con un logserver non acccedibile se non in lettura
e solo dall'auditor, i requisiti del caso non sarebbero
automaticamente rispettati?

Va valutato in funzione della tua realtà. Se trattasi di uno studio di
commercialisti di 5 persone la risposta è sì, se si tratta di un'ospedale
con 1000 dipendenti la risposta è no.

Perche'? Nel senso che i dati comunque li`sopra vengono salvati, siano
di 5 o di 1000. Inoltre questa normativa non era per gli ADS e il
tracciamento dei loro accessi al sistema? Infine io sono in una
situazione intermedia di circa 100 utenti su 7-8 server.
Il logserver ha spazio a iosa per registrare anche anni di accessi, ma
ligio al minimo prescritto dalla normativa ricicla sui log dopo 6 mesi
e comunque li chiude e riapre ogni settimana.

Post by twistedbrain
Ma e se poi il disco del logserver ci
lascia? Mi sa che comunque su CD ogni tanto e` meglio salvare i log.

Eh si`, credo che mi mettero` a fare anch'io cosi`, che male non fa e
poi spedisco una copia al garante, augurandomi che tutti prendano
questa saggia decisione.

Post by THe_ZiPMaN
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Ubuntu in Tutzi significa "Preferisco usare Debian riuscita bene"

THe_ZiPMaN

2010-02-04 18:19:52 UTC

Post by twistedbrain
poi spedisco una copia al garante, augurandomi che tutti prendano
questa saggia decisione.

Così ti becchi pure una denuncia per trattamento illecito di dati personali
dato che li hai comunicati a terzi senza averne l'autorizzazione. Siamo in
Italia :-)

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

twistedbrain

2010-02-04 19:29:14 UTC

Post by twistedbrain
poi spedisco una copia al garante, augurandomi che tutti prendano
questa saggia decisione.

Così ti becchi pure una denuncia per trattamento illecito di dati personali
dato che li hai comunicati a terzi senza averne l'autorizzazione. Siamo in
Italia :-)

No, io pensavo di trasmettergli crittati e poi di fargli avere un bel
plico in cui descrivo tutta la loro storia e fornisco i recapiti per
chiedere la chiave per decrittarli. :-)

Max_Adamo

2010-02-04 20:28:08 UTC

Post by twistedbrain
poi spedisco una copia al garante, augurandomi che tutti prendano
questa saggia decisione.

Così ti becchi pure una denuncia per trattamento illecito di dati
personali dato che li hai comunicati a terzi senza averne
l'autorizzazione. Siamo in Italia :-)

qui entra in ballo la parte più controversa di tutta la norma.
La pretesa - secondo l'ufficio legale della azienda - era che io dovevo
essere in grado di poter amministrare tutto l'ambar-adam, senza però
poter accedere al dato stesso.

E vai lì, mesi a spiegare l'impossibilità di ciò.
Io parlavo il "tecnichese", il mio interlocutore parlava il "legalese" e
siamo andati avanti per mesi a non capirci l'uno con l'altro, fin quando
un bel giorno mi hanno recapitato una bella liberatoria da firmare che
ha risolto tutti i problemi nell'unico modo possibile.

Io mi impegnavo a non guardare un dato (del quale non mi interessava
assolutamente nulla) e loro si impegnavano a scomparire per sempre dalla
mia vita.

in tecnichese la cosa era di una stupidità unica: io ero admin di un DB
relazionale, sul quale dovevo poter fare delle insert e delle drop, ma
la granularità del DB "è quella che è", e sia una insert, sia un drop,
richiedono il privilegio minimo della select.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

whiplash

2010-02-04 18:18:23 UTC

Post by THe_ZiPMaN
non sarà infinita ma ci si avvicina molto. Prima ha partorito una
normativa tecnicamente valida

Bah, io avrei dei dubbi anche su questo, consentimelo. :)

Max_Adamo

2010-02-04 19:14:34 UTC

capito io basta che i log non siano modificabili e questo obiettivo
viene raggiunto p.es. semplicemente masterizzandoli su CD-ROM

Dove sta scritto? Rileggiti le FAQ del garante, la mette giù in modo molto
differente rispetto alla prima lettura.

Il caso citato mi pare che richieda l'attivazione dell'audit. Tu
registrerai l'accesso dell'utente 'pippo', nonché tutti i comandi che
pippo lancia fino al logout. Ripulirai la configurazione dell'audit per
evitare di ricevere syscall delle quali non te ne frega nulla, ma in
linea di massima, in una server-farm di quelle toste non è gestibile in
real-time.
Non credo che ce la fai ad usare un syslog server.

Ti dico solo una cosa (TIENITI FORTE E NON TI SPAVENTARE): la sola
server-farm dei server per la raccolta dell'audit nell'azienda XXX (la
conoscete tutti), consiste di 150 (centocinquanta) server RedHat!
150 server solo per raccogliere gli audit di tutti gli altri server...
non so se mi spiego....
Si tratta di un DB relazionale e gerarchico di tipo distribuito, dove i
dati sono distribuiti in questo anello composto da tutti questi nodi.

La server-farm analoga che ho "deployato" io in una azienda un po' più
piccola, consisteva di circa 40 RedHat.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

twistedbrain

2010-02-04 19:40:04 UTC

Post by Max_Adamo
Il caso citato mi pare che richieda l'attivazione dell'audit. Tu
registrerai l'accesso dell'utente 'pippo', nonché tutti i comandi che
pippo lancia fino al logout.

Si`, questo avrebbe senso, ma non pretenderai che la normativa abbia
senso. Che io sappia e` solo richiesta la registrazione degli accessi
e delle disconnessioni. In pratica l'auth.log (UNIX) e quello della
sicurezza Windows, dai quali potresti poi anche escludere gli accessi
che non riguardano gli ADS. Non e` poi tutta questa mole di dati. Non
e` molto utile (per usare un eufemismo) praticamente in qualsiasi
circostanza e infine e` facilmente aggirabile da un amministratore di
sistema che manometta i log prima che vengano registrati, quindi in
conclusione piu` che inutile direi che e` dannosa, dato il tempo che
fa perdere per ottenere dei risultati senza costrutto.

Max_Adamo

2010-02-04 19:52:19 UTC

Post by Max_Adamo
Il caso citato mi pare che richieda l'attivazione dell'audit. Tu
registrerai l'accesso dell'utente 'pippo', nonché tutti i comandi che
pippo lancia fino al logout.

Si`, questo avrebbe senso, ma non pretenderai che la normativa abbia
senso.

assolutamente no :-)

Che io sappia e` solo richiesta la registrazione degli accessi

Post by twistedbrain
e delle disconnessioni.

non prentendo di saperti rispondere, in quanto non lavoro in un ufficio
legale.
Posso solo dirti, quello che mi richiedevano di dover fare e nel nostro
caso registravamo *tutto*, ma proprio tutto:
wget http://porntube/porno.mpg, vlc porno.mpg e così via .... (*) :-)
Non so se questa differenza è normata anch'essa, forse in base al
settore in cui opera l'azienda.
Non ti so proprio dire. Nel mio caso era Telco.

Aggiungo che c'è un ulteriore, terzo caso: dati per la magistratura.
La registrazione di questi dati avviene in "gabbie" (aree con accesso VPN).

(*) era un lavoro da matti!! Bastava uno script in giro scritto ad
cacchium e ti mandava tutto a puttane sul tuo DB.
Una volta ho scovato uno script su uno dei tanti server che lanciava
degli awk, su degli array che lui si costruiva.
Di fatto era un casino (e ora non vado nel dettaglio) e sul DB mi
trovavo un milione di 'awk' al giorno provenienti da una singola
macchina .... ma io non ero responsabile delle macchine dalle quali
prendevo i dati. Chiedevo all'owner e mi diceva sempre "non so, non so".
Mi toccata andare su tutte quelle merde di macchine a risolvere i
problemi uno per uno.
Fortuna che ho cambiato lavoro :-)

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-04 19:56:56 UTC

Post by Max_Adamo
(*) era un lavoro da matti!!

un'altra volta ancora ho trovato una syscall in giro che mi generava
svariati milioni di entry al giorno. Si trattava della syscall 'semop'.
Per farla disattivare, cosa che sembra banalissima, abbiamo dovuto fare
una conference-call con i manager e uff... uff .... uff che non ti
dico..... una palla incredibile!

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

whiplash

2010-02-04 18:15:50 UTC

Post by Alessandro Pellizzari
Si`, ma non devono mai essere modificabili, nemmeno un nanosecondo dopo
che li hai scritti, quindi devi tenere una sessione aperta sul CD-ROM e
scrivere riga per riga li`. Non puoi farlo la sera o ogni ora, deve
essere in tempo reale.

Ma anche no.
Ripetete come un mantra "il provvedimento del Garante è una cagata
pazzesca" e leggete la FAQ.

Alessandro Pellizzari

2010-02-05 09:37:30 UTC

Post by whiplash
Ripetete come un mantra "il provvedimento del Garante è una cagata
pazzesca"

Gia` lo faccio. :)

Post by whiplash
e leggete la FAQ.

Questo lo faro` al piu` presto.

Bye.

xfilesit

2010-02-08 09:22:08 UTC

Post by whiplash
Ripetete come un mantra "il provvedimento del Garante è una cagata
pazzesca"

Gia` lo faccio. :)

Post by whiplash
e leggete la FAQ.

Questo lo faro` al piu` presto.
Bye.

Sarà pure quello che dici e potrei anche essere daccordo ma se ti
fanno un controllo e non sei in regola ti fanno il c....... e se sei
anche ADS te lo fanno due volte.

Max_Adamo

2010-02-04 19:06:20 UTC

Post by xfilesit
Utilizzo Splunk per la racolta dei log centralizzata è funziona benino
ora ho il problema di calcolare l'hash e firmare digitalmente questi
log per la conformità al garante.

Premetto di non conoscere affatto bene la normativa, ma
perche' dovrebbero essere firmati e da chi?

ci sono taluni casi per i quali è richiesta la firma, che serve a
garantire che i log provengano senza dubbio da un determinato host di
origine.

Da noi c'erano due lotti di server. Alcuni inviavano log firmati, e
altri invece no.

Quale era il motivo per cui in certi casi scattava la firma io non l'ho
mai chiesto, e non mi è mai importato saperlo..
A un certo punto, mi ricordo che mi infastidì a dover trattare liste
differenti, e gli proposi di piantarla con questo casino e di firmare
tutti i log :-)

Post by twistedbrain
perche' se ne dovrebbe calcolare un hash?
Qualora si dovessero svolgere queste attivita` (cosa che non credo),
non vedo quali siano i problemi tecnici a farlo.
A quanto ne ho capito io basta che i log non siano modificabili e
questo obiettivo viene raggiunto p.es. semplicemente masterizzandoli
su CD-ROM

non è questo il concetto. Nel mio caso (uguale per tutti gli operatori
Telco) si tratta di una mole immensa di dati di audit, che deve essere
scaricata giornalmente da ogni singolo server.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-04 17:40:17 UTC

Post by xfilesit
Utilizzo Splunk per la racolta dei log centralizzata è funziona benino
ora ho il problema di calcolare l'hash e firmare digitalmente questi
log per la conformità al garante.

Non è necessario, ma se vuoi farlo puoi fare una cosa così:

##########################################

#!/bin/bash
FILENAME=$1
TMP=$(mktemp)
MD5S=$(md5sum "$FILENAME")
HASH=$(echo "$MD5S" | cut -c1-32)
FILE=$(echo "$MD5S" | cut -c35-)
TIME=$(date '+%Y%m%d%H%M%S')
echo "File: $FILE" > $TMP
echo "Hash: $HASH" >> $TMP
echo "Time: $TIME" >> $TMP
ntpq -pn >> $TMP
if gpg --batch --sign --output "$FILENAME.sign" $TMP
then
logger -p local0.info -t sign "Successfully signed File: $FILE"
else
logger -p local0.error -t sign "Failed signing File: $FILE Error: $?"
fi
rm $TMP

##########################################

Ovviamente prima devi aver generato una chiave gpg con cui firmare.
Per vedere la firma

gpg --decrypt $FILENAME.sign

e confronti l'hash

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

twistedbrain

2010-02-04 17:49:54 UTC

Post by THe_ZiPMaN
MD5S=$(md5sum "$FILENAME")

So che e` ancora in uso, ma md5 non e` deprecato perche' crackabile?

THe_ZiPMaN

2010-02-04 18:16:53 UTC

Post by THe_ZiPMaN
MD5S=$(md5sum "$FILENAME")

So che e` ancora in uso, ma md5 non e` deprecato perche' crackabile?

Tutto va rapportato all'uso che se ne deve fare. Per questo scopo basterebbe
anche crc32 perché non vi è nulla di particolare da proteggere, è solo un
contentino per chi dovesse venire a rompere le palle e non si accontentasse
di un caffè.

Quanto alla cracckabilità di MD5, anche se la via è segnata, siamo ancora
distanti. Sono state trovate delle debolezze nell'algoritmo che fan sì che
in particolari condizioni si possa trovare una collisione in 2^39 o anche in
2^32 cicli invece che in 2^64, e questo può effettivamente essere un
problema perché quell'ordine di grandezza è oggi gestibile da un
supercomputer (o un cluster di calcolo). Ma se questo significa che un
certificato x509 non è da ritenersi sicuro se firmato usando MD5, non
significa che tale funzione non sia usabile per molti altri scopi come questo.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-04 18:50:34 UTC

Post by xfilesit
Utilizzo Splunk per la racolta dei log centralizzata è funziona benino
ora ho il problema di calcolare l'hash e firmare digitalmente questi
log per la conformità al garante.
Ringrazio chiunque mi dia indicazioni in merito anche in relazione
alle soluzioni adottate per la conformita al garante per l'D.d.S.

Io usavo certificati SSL, verificati localmente con openssl e abbiamo
passato la verifica del garante senza problemi ...

In linea di massima, veniva prodotto un certificato, con password, per
ogni server sul quale venivano raccolti i log.
La password veniva letta da un file di testo accessibile solo all'utente
che effettuava lo scambio dei file... un po' idiota questa parte qui.

se vuoi dettagli dammi un attimo per ricordare perché ho cambiato lavoro
a Novembre ....

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-04 19:37:29 UTC

Io usavo certificati SSL, verificati localmente con openssl e abbiamo
passato la verifica del garante senza problemi ...

chiaramente il gpg che suggerisce zipman va altrettanto bene.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

xfilesit

2010-02-05 08:45:56 UTC

La norma fra le altre cose dice testualmente :
4.5 Registrazione degli accessi
Devono essere adottati sistemi idonei alla registrazione degli accessi
logici (autenticazione informatica) ai sistemi di elaborazione e agli
archivi elettronici da parte degli amministratori di sistema. Le
registrazioni (access log) devono avere caratteristiche di
completezza, inalterabilità e possibilità di verifica della loro
integrità adeguate al raggiungimento dello scopo di verifica per cui
sono richieste.Le registrazioni devono comprendere i riferimenti
temporali e la descrizione dell'evento che le ha generate e devono
essere conservate per un congruo periodo, non inferiore a sei mesi.

4) Relativamente all'obbligo di registrazione degli accessi logici
degli AdS, sono compresi anche i sistemi client oltre che quelli
server?
Si, anche i client, intesi come "postazioni di lavoro informatizzate",
sono compresi tra i sistemi per cui devono essere registrati gli
accessi degli AdS.

La FAQ 4 dice :
Nei casi più semplici tale requisito può essere soddisfatto tramite
funzionalità già disponibili nei più diffusi sistemi operativi, senza
richiedere necessariamente l'uso di strumenti software o hardware
aggiuntivi. Per esempio, la registrazione locale dei dati di accesso
su una postazione, in determinati contesti, può essere ritenuta idonea
al corretto adempimento qualora goda di sufficienti garanzie di
integrità.

Sarà comunque con valutazione del titolare che dovrà essere
considerata l'idoneità degli strumenti disponibili oppure l'adozione
di strumenti più sofisticati, quali la raccolta dei log centralizzata
e l'utilizzo di dispositivi non riscrivibili o di tecniche
crittografiche per la verifica dell'integrità delle registrazioni.

La FAQ 12 dice

12) Come va interpretata la caratteristica di inalterabilità dei log?
Caratteristiche di mantenimento dell'integrità dei dati raccolti dai
sistemi di log sono in genere disponibili nei più diffusi sistemi
operativi, o possono esservi agevolmente integrate con apposito
software. Il requisito può essere ragionevolmente soddisfatto con la
strumentazione software in dotazione, nei casi più semplici, e con
l'eventuale esportazione periodica dei dati di log su supporti di
memorizzazione non riscrivibili. In casi più complessi i titolari
potranno ritenere di adottare sistemi più sofisticati, quali i log
server centralizzati e "certificati".

È ben noto che il problema dell'attendibilità dei dati di audit, in
genere, riguarda in primo luogo la effettiva generazione degli
auditable events e, successivamente, la loro corretta registrazione e
manutenzione. Tuttavia il provvedimento del Garante non affronta
questi aspetti, prevedendo soltanto, come forma minima di
documentazione dell'uso di un sistema informativo, la generazione del
log degli "accessi" (login) e la loro archiviazione per almeno sei
mesi in condizioni di ragionevole sicurezza e con strumenti adatti, in
base al contesto in cui avviene il trattamento, senza alcuna pretesa
di instaurare in modo generalizzato, e solo con le prescrizioni del
provvedimento, un regime rigoroso di registrazione degli usage data
dei sistemi informativi.

Ora la norma è stata fatta apposta prevede varie interpretazioni per
essere sicuro però in caso di controllo i log devono essere
immodificabili (crittografati) e raccolti su un log server
centralizzato. (nelle verifiche effettuate hanno sempre richiesto
queste caratteristiche).

Sono daccordo che come è stata fatta è una misura demenziale ma visto
che possono dare una multe da 30 a 180,000 €
è sempre meglio attuare la soluzione che nel tuo contesto di fornisce
piu garanzie anche perchè se sei stato nominato A.d.S. devi
giustificare le tue scelte tecniche al titolare.
Mi piacerebbe conoscere le vostre soluzione o indicazioni per la
raccolta dei log degli A.d.S. nelle vostre strutture operative e se
avete ricevuto la nomina ad A.d.S.
Ciao a tutti

THe_ZiPMaN

2010-02-05 09:54:41 UTC

Post by xfilesit
Ora la norma è stata fatta apposta prevede varie interpretazioni per
essere sicuro però in caso di controllo i log devono essere
immodificabili (crittografati)

Immodificabili != crittografati. Al più firmati, ma anche in questo caso
sarebbero *modificabili* solo che potresti verificare che sono stati
manipolati. L'immodificabilità la hai solo usando supporti WORM.

Post by xfilesit
e raccolti su un log server
centralizzato. (nelle verifiche effettuate hanno sempre richiesto
queste caratteristiche).

Che tipo di aziende sarebbero state controllate? Da chi? E' il solito
sentito dire (mio cuGGino mi ha detto che l'amico finanziere di sua cognata
ha controllato un'azienda e....) oppure hai documentazione affidabile?

Post by xfilesit
Mi piacerebbe conoscere le vostre soluzione o indicazioni per la
raccolta dei log degli A.d.S. nelle vostre strutture operative

Syslog centralizzato che raccoglie i soli accessi amministrativi e firma
elettronica non qualificata ogni ora con backup giornaliero e salvataggio
mensile su DVD.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Michele "L'emarginato"

2010-02-05 20:42:12 UTC

Post by THe_ZiPMaN
Syslog centralizzato che raccoglie i soli accessi amministrativi e firma
elettronica non qualificata ogni ora con backup giornaliero e
salvataggio mensile su DVD.

Chi gestisce il syslog server?

:)

THe_ZiPMaN

2010-02-05 21:59:42 UTC

Post by THe_ZiPMaN
Syslog centralizzato che raccoglie i soli accessi amministrativi e firma
elettronica non qualificata ogni ora con backup giornaliero e
salvataggio mensile su DVD.

Chi gestisce il syslog server?

Io. La legge non dice nulla a tal riguardo e visto che l'utilità di quei log
per la sicurezza è esattamente pari a zero non vedo perché complicarsi
inutilmente la vita.
Utilizzando syslog se volessi fare il coglione basterebbe che staccassi il
cavo di rete al login ed al logout e non si vedrebbe nulla.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Michele "L'emarginato"

2010-02-07 12:28:23 UTC

Post by Michele "L'emarginato"
Chi gestisce il syslog server?

Io. La legge non dice nulla a tal riguardo

Non è cosi, perchè non PUO' esistere un controllore che sia anche
controllato, a parte i sindaci revisori delle quotate in borsa
italiane... :)

Sull'utilità possiamo disquisire tranquillamente, sono d'accordo sul
fatto che sia inutile.

roberto

2010-02-07 12:59:03 UTC

Post by Michele "L'emarginato"
Chi gestisce il syslog server?

Io. La legge non dice nulla a tal riguardo

Non è cosi, perchè non PUO' esistere un controllore che sia anche
controllato, a parte i sindaci revisori delle quotate in borsa
italiane... :)

Qualche riferimento legislativo, per favore.

--
|Save our planet!
Ciao |Save wildlife!
roberto |For your E-MAIL use ONLY recycled Bytes !!
|roberto poggi ***@softhome.net

THe_ZiPMaN

2010-02-07 13:48:46 UTC

Post by Michele "L'emarginato"
Chi gestisce il syslog server?

Io. La legge non dice nulla a tal riguardo

Non è cosi, perchè non PUO' esistere un controllore che sia anche
controllato, a parte i sindaci revisori delle quotate in borsa
italiane... :)

Ma perché ci si deve divertire a sparar minchiate? Tu trova dove sta scritto
che io, amministratore di sistema, non posso amministrare il log server
centralizzato coi log degli accessi degli AdS, e ti offro una bella cena.

Se non la trovi me la offri tu?

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

roberto

2010-02-07 14:02:03 UTC

Post by Michele "L'emarginato"
Chi gestisce il syslog server?

Io. La legge non dice nulla a tal riguardo

Non è cosi, perchè non PUO' esistere un controllore che sia anche
controllato, a parte i sindaci revisori delle quotate in borsa
italiane... :)

Ma perché ci si deve divertire a sparar minchiate? Tu trova dove sta
scritto che io, amministratore di sistema, non posso amministrare il log
server centralizzato coi log degli accessi degli AdS, e ti offro una
bella cena.

Ehi, gliel'ho chiesto prima io.
Se non risponde, la cena ce la offriamo a vicenda. ;-)

--
|Save our planet!
Ciao |Save wildlife!
roberto |For your E-MAIL use ONLY recycled Bytes !!
|roberto poggi ***@softhome.net

Max_Adamo

2010-02-07 14:21:30 UTC

Post by Michele "L'emarginato"
Chi gestisce il syslog server?

Io. La legge non dice nulla a tal riguardo

Non è cosi, perchè non PUO' esistere un controllore che sia anche
controllato, a parte i sindaci revisori delle quotate in borsa
italiane... :)

Ma perché ci si deve divertire a sparar minchiate? Tu trova dove sta
scritto che io, amministratore di sistema, non posso amministrare il log
server centralizzato coi log degli accessi degli AdS, e ti offro una
bella cena.
Se non la trovi me la offri tu?

premetto che interpetare la legge non è un nostro compito (al massimo
possiamo interpretare ciò che fa EMC2, da un punto di vista tecnico(.
Ciò detto: la legge dice che il dato deve essere non mobificabile.

Il dato che tu registri su un syslog server, dal quale tu puoi staccare
il cavo di rete, e sul quale tu puoi fare login come root per brasare
tutto, ti pare che sia un dato non modificabile?

A registrarlo su blu-ray/dvd sarai sempre tu, ma non ci scrivi in tempo
reale. E prima di passarlo su tali supporto i dati sono sempre alla tua
mercé.

Secondo me è chiaro che non stai ottemperando a quanto prescritto dalla
legge.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 14:27:28 UTC

Post by Michele "L'emarginato"
Chi gestisce il syslog server?

Io. La legge non dice nulla a tal riguardo

Non è cosi, perchè non PUO' esistere un controllore che sia anche
controllato, a parte i sindaci revisori delle quotate in borsa
italiane... :)

Ma perché ci si deve divertire a sparar minchiate? Tu trova dove sta
scritto che io, amministratore di sistema, non posso amministrare il log
server centralizzato coi log degli accessi degli AdS, e ti offro una
bella cena.
Se non la trovi me la offri tu?

non modificabile = non alterabile, non cancellabile.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-07 15:56:45 UTC

Post by Max_Adamo
premetto che interpetare la legge non è un nostro compito

Non è il TUO compito. I miei compiti tu non sai quali sono.

Post by Max_Adamo
Secondo me è chiaro che non stai ottemperando a quanto prescritto dalla
legge.

Ma visto che tu non conti un cazzo, che le FAQ hanno dato un'interpretazione
di riferimento del concetto e che a diversi avvocati va bene così, io
continuo a dormire tranquillo.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

twistedbrain

2010-02-07 14:34:23 UTC

Post by Michele "L'emarginato"
Chi gestisce il syslog server?

Io. La legge non dice nulla a tal riguardo

Non è cosi, perchè non PUO' esistere un controllore che sia anche
controllato, a parte i sindaci revisori delle quotate in borsa
italiane... :)

Si`, a ben pensarci questa non e` piu` assurda di altre cose, dato che
lo stesso amministratore di sistema amministra le macchine da cui
vengono i log per cui volendo potrebbe direttamente falsificarli ab
origine, senza nemmeno dover staccare il cavo di rete del log server.
A fare le cose bene ci dovrebbe essere un amministratore di sistema
diverso dal primo responsabile dell'auditing, ma cio` non e` previsto
e credo nemmeno auspicabile, almeno in organizzazioni normali con
normali esigenze di sicurezza.

roberto

2010-02-07 14:50:50 UTC

twistedbrain ha scritto:
-cut-

Post by twistedbrain
Si`, a ben pensarci questa non e` piu` assurda di altre cose, dato che
lo stesso amministratore di sistema amministra le macchine da cui
vengono i log per cui volendo potrebbe direttamente falsificarli ab
origine, senza nemmeno dover staccare il cavo di rete del log server.
A fare le cose bene ci dovrebbe essere un amministratore di sistema
diverso dal primo responsabile dell'auditing, ma cio` non e` previsto

E chi controllerebbe gli accessi dell'amministratore di sistema
addetto al controllo dell'auditing?
E come si potrebbe eseguire l'auditing del controllore dell'auditing?

Insomma, io continuo a pensarla in questo modo:
A legiferare sul buon senso si ottengono degli aborti legislativi.

Se sono sysadmin, i log riporteranno solo quello che io voglio che
riportino, se ho deciso di fare qualche giochetto.

E se ci si inventa un super-super-user, che controlla il super-user,
e i cui poteri non ha il super-user, non si fa altro che spostare
verso l'alto il problema, oltre a richiedere la riscrittura della
maggior parte dei sistemi operativi, perché allora anche il
super-super-user dovrebbe essere controllato da un
super-super-super-user, e così via, ad libitum.

No, questa norma è una bella teoria inapplicabile.
O applicabile solo per forma, ne resta nulla la sostanza e il
beneficio, IMHO.

--
|Save our planet!
Ciao |Save wildlife!
roberto |For your E-MAIL use ONLY recycled Bytes !!
|roberto poggi ***@softhome.net

Max_Adamo

2010-02-07 15:09:33 UTC

Post by roberto
E chi controllerebbe gli accessi dell'amministratore di sistema
addetto al controllo dell'auditing?
E come si potrebbe eseguire l'auditing del controllore dell'auditing?

si chiama "self-auditing" :-) Le macchina di auditing, fanno audit su se
stesse.
L'auditor sarà controllato dal self-auditing.

Post by roberto
A legiferare sul buon senso si ottengono degli aborti legislativi.

OK, va bene. Ma se non rispetto la legge paghi una ammenda fino a tot
18mila euro. Chiaro questo? Poi, se vogliamo parlar di politica
spostiamoci su un altro gruppo.

Post by roberto
Se sono sysadmin, i log riporteranno solo quello che io voglio che
riportino, se ho deciso di fare qualche giochetto.

non sono sysadmin. Sono "power user" sul database dei log.
Se un audit di sistema sarà stato fermato, comparira un vuoto sulla
raccolta dei log.

Post by roberto
E se ci si inventa un super-super-user, che controlla il super-user,
e i cui poteri non ha il super-user, non si fa altro che spostare
verso l'alto il problema, oltre a richiedere la riscrittura della
maggior parte dei sistemi operativi, perché allora anche il
super-super-user dovrebbe essere controllato da un
super-super-super-user, e così via, ad libitum.
No, questa norma è una bella teoria inapplicabile.

E' di difficilissima, o forse impossibile applicazione. Di questo do atto.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 15:05:19 UTC

Post by Michele "L'emarginato"
Chi gestisce il syslog server?

Io. La legge non dice nulla a tal riguardo

Non è cosi, perchè non PUO' esistere un controllore che sia anche
controllato, a parte i sindaci revisori delle quotate in borsa
italiane... :)

intendiamoci: la legge non prevedere che ci debbano essere
amministratori distinti e non deve prevederlo.
La legge ti dice quale deve essere l'obiettivo (immodificabilità del
dato). E tu a questo devi attenerti.
Come fai ad ottenere ciò, se non tramite la segregazione dei ruoli? Se
trovi un sistema differente, userai quello.

Difatto il problema è l'obiettivo: il dato non deve essere modificabile.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Crononauta

2010-02-07 15:54:33 UTC

Post by twistedbrain
A fare le cose bene

A fare cose per bene dovrebbero evitare di fare leggi obiettivamente
così del cazzo e che tecnicamente non stanno in piedi comunque le si
guardi. :-(

--
Massimo Bacilieri AKA Crononauta
Skype: crononauta <***@gmail.com>
Facebook: Massimo Bacilieri

THe_ZiPMaN

2010-02-07 15:57:30 UTC

Post by Crononauta

Post by twistedbrain
A fare le cose bene

A fare cose per bene dovrebbero evitare di fare leggi obiettivamente
così del cazzo e che tecnicamente non stanno in piedi comunque le si
guardi. :-(

Siamo in Italia. Non c'è da aggiungere altro.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-07 16:52:26 UTC

On Sun, 7 Feb 2010 06:34:23 -0800 (PST), twistedbrain

Post by twistedbrain
A fare le cose bene

A fare cose per bene dovrebbero evitare di fare leggi obiettivamente
così del cazzo e che tecnicamente non stanno in piedi comunque le si
guardi. :-(

Siamo in Italia. Non c'è da aggiungere altro.

Temo che questa norma sia simile/uguale in tutta europa.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 16:51:04 UTC

Post by Crononauta

Post by twistedbrain
A fare le cose bene

A fare cose per bene dovrebbero evitare di fare leggi obiettivamente
così del cazzo e che tecnicamente non stanno in piedi comunque le si
guardi. :-(

quoto.
p.s.: il problema di fondo è che ad essere fuorilegge (secondo questa
norma) sono i sistemi operativi stessi, che non sono granulari in tal
senso, al punto di consentire ciò che il legislatore vorrebbe ottenere.

Con lo storage speciale ti avvicini maggiormento al risultato, ma è
difficile riuscire ad escludere tutte le back-doors.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-07 17:01:34 UTC

Post by Max_Adamo
p.s.: il problema di fondo è che ad essere fuorilegge (secondo questa
norma) sono i sistemi operativi stessi, che non sono granulari in tal
senso, al punto di consentire ciò che il legislatore vorrebbe ottenere.

Dicci la verità.... ti stai allenando per il campionato del mondo di
velocità o per quello di consistenza?

Sappi che sei già preparatissimo per entrambi; cazzate ne spari a raffica di
immense, non ti serve altro allenamento per arrivare primo. Risparmia pure
la banda.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-07 17:59:40 UTC

Dicci la verità.... ti stai allenando per il campionato del mondo di
velocità o per quello di consistenza?
Sappi che sei già preparatissimo per entrambi; cazzate ne spari a
raffica di immense, non ti serve altro allenamento per arrivare primo.
Risparmia pure la banda.

Zip, dillo chiaramente: su questa cosa non ci ho capito una cippa, ma
ostento ugualmente sicurezza e conoscenza che effettivamente NON ho
acquisito.

gli avvocati spiegano a te come si interpretano le leggi, ma tu devi
spiegare agli avvocati i dettagli tecnici dei quali loro necessitano, e
i problemi tecnici cui vai incontro, nel tentare di applicare la norma.

Sei riuscito ad ottenere un dato *non* modificabile? Come pensi di
ottenere il raggiungimento di questo scopo? Perché i certificato ISO9001
e gli uffici legali delle varie aziende non sono d'accordo con quel che
tu dici?

Io non ho difficoltà a dire che la legge è difficilmente applicabile, ma
tu non puoi dire che la legge è applicata, non avendola applicata per
niente.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-07 18:06:38 UTC

Post by Max_Adamo
Sei riuscito ad ottenere un dato *non* modificabile?

Sì.

Post by Max_Adamo
Come pensi di ottenere il raggiungimento di questo scopo?

L'ho già spiegato decine di volte. Informati.

Post by Max_Adamo
Perché i certificato ISO9001

Strano... L'auditor ISO che ci ha appena fatto visita la scorsa settimana
non ha obiettato nulla.

Post by Max_Adamo
e gli uffici legali delle varie aziende non sono d'accordo con quel che
tu dici?

Strano anche in questo caso. Lo stesso sistema adottato da noi è adottato
anche da diverse aziende, da banche, da assicurazioni, da studi legali...
che tutti non abbiano capito nulla e solo tu sia detentore della Verità?

Post by Max_Adamo
Io non ho difficoltà a dire che la legge è difficilmente applicabile, ma
tu non puoi dire che la legge è applicata, non avendola applicata per
niente.

Se tu non capisci quel che leggi è un TUO problema; o magari non leggi e
quindi non capisci. Comunque è inutile proseguire; tu butta pure tutti i
milioni che vuoi in inutili storage immodificabili, ma smettila di sparare
minchiate e vedi di informarti meglio (magari anche attingendo a qualche
fonte affidabile invece che dai commerciali di storage immodificabili).

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

MaxAdamo

2010-02-08 01:38:37 UTC

Post by Max_Adamo
Sei riuscito ad ottenere un dato *non* modificabile?

Sì.

dove modificabile = non cancellabile, oltre che non alterabile ? Cosa
fai: stampi gli hash su carta non strappabile, ignifuga e resistente
persino ai cestini dell'immondizia?
che sei un po' una macchietta, te lo hanno mai detto?

Ho deciso di accettare la tua scommessa.
Le mie regole sono solo due:
1. memorizzo l'md5 di auditd e dei suoi file di configurazione.
2. è sufficiente che io tracci un riavvio forzato di auditd e avrai
perso.

spero che il punto 2 sia chiaro, ovvero, spero che tu abbia letto bene
il thread.

Per quanto riguarda le modalità di svolgimento della scommessa, ahimé,
qualche problema ce l'ho: ho una gamba rotta e tengo il gesso fino al
19.
Fammi sapere come si può fare.

ValeRyo Saeba

2010-02-07 21:28:26 UTC

Appunto.
Se sono amministratore del mio sistema come puoi fidarti dei log che
lo stesso ti manda _sulle mie attività_?

--
ValeRyo
XT600 "Katoki Pajama" - http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - http://www.slimmit.com/go.asp?7X0
GamerTag: Loading Image...

Michele "L'emarginato"

2010-02-08 09:20:55 UTC

Post by THe_ZiPMaN
Ma perché ci si deve divertire a sparar minchiate? Tu trova dove sta
scritto che io, amministratore di sistema, non posso amministrare il log
server centralizzato coi log degli accessi degli AdS, e ti offro una
bella cena.

Ti offro quello che vuoi.
Se sei avvocato....

http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499

4.4 Verifica delle attività3
L'operato degli amministratori di sistema deve essere oggetto, con
cadenza almeno annuale, di un'attività di verifica da parte dei titolari
o dei responsabili del trattamento, in modo da controllare la sua
rispondenza alle misure organizzative, tecniche e di sicurezza rispetto
ai trattamenti dei dati personali previste dalle norme vigenti.

4.5 Registrazione degli accessi
Devono essere adottati sistemi idonei alla registrazione degli accessi
logici (autenticazione informatica) ai sistemi di elaborazione e agli
archivi elettronici da parte degli amministratori di sistema. Le
registrazioni (access log) devono avere caratteristiche di completezza,
"inalterabilità"* e possibilità di verifica della loro integrità
adeguate al raggiungimento dello scopo di verifica per cui sono richieste.

Le registrazioni devono comprendere i riferimenti temporali e la
descrizione dell'evento che le ha generate e devono essere conservate
per un congruo periodo, non inferiore a sei mesi.

TU non le puoi gestire.

Poi fai quello che minchia ti pare....
Noto solo che tanti avvocati ,così bravi, sono davvero sprecati per il
settore IT!!

THe_ZiPMaN

2010-02-08 10:58:33 UTC

Post by Michele "L'emarginato"
Ti offro quello che vuoi.
Se sei avvocato....

Perché questi limiti? Gli avvocati prendono già soldi a sufficienza :-)

Post by Michele "L'emarginato"
4.4 Verifica delle attività3
L'operato degli amministratori di sistema deve essere oggetto, con
cadenza almeno annuale, di un'attività di verifica da parte dei titolari
o dei responsabili del trattamento, in modo da controllare la sua
rispondenza alle misure organizzative, tecniche e di sicurezza rispetto
ai trattamenti dei dati personali previste dalle norme vigenti.

Perfetto. E dove leggi qui sopra che l'AdS non può amministrare i sistemi
che raccolgono quelle informazioni (che peraltro non è nemmeno obbligatorio
raccogliere centralmente, ma questo è un dettaglio che per chi non ha
affrontato la problematica seriamente probabilmente sfugge)?

Post by Michele "L'emarginato"
4.5 Registrazione degli accessi
Devono essere adottati sistemi idonei alla registrazione degli accessi
logici (autenticazione informatica) ai sistemi di elaborazione e agli
archivi elettronici da parte degli amministratori di sistema. Le
registrazioni (access log) devono avere caratteristiche di completezza,
"inalterabilità"* e possibilità di verifica della loro integrità
adeguate al raggiungimento dello scopo di verifica per cui sono richieste.

Perfetto. E dove leggi qui sopra che l'AdS non può amministrare i sistemi
che raccolgono quelle informazioni?

Post by Michele "L'emarginato"
Le registrazioni devono comprendere i riferimenti temporali e la
descrizione dell'evento che le ha generate e devono essere conservate
per un congruo periodo, non inferiore a sei mesi.

Ottimo. E dove leggi qui sopra che l'AdS non può amministrare i sistemi che
raccolgono quelle informazioni

Post by Michele "L'emarginato"
TU non le puoi gestire.

Ora caro, dimmi dove vedi scritto nei pezzi da te quotato che
l'amministratore di sistema non può amministrare i sistemi con i log.
Di chiederò anche di più: dimmi dove leggi che l'amministratore di sistema
non può essere anche il titolare o il responsabile del trattamento dei dati
e quindi essere incaricato non solo di amministrare i propri log ma anche di
autocontrollare il proprio operato (per inciso conosco più di una realtà di
questo tipo).

TU puoi anche dire che IO devo saltellare sulla gamba sinistra intonando
canti per Chtulu ogni volta che inserisco la password di root, ma la legge
non afferma questo e non afferma nemmeno che IO non posso gestire i sistemi
su cui sono memorizzati i log. Io attendo sempre di poter offrire una cena.

Post by Michele "L'emarginato"
Poi fai quello che minchia ti pare....
Noto solo che tanti avvocati ,così bravi, sono davvero sprecati per il
settore IT!!

Fai una cosa "mister ho capito tutto"; posta quanto sopra su
it.diritto.internet e poni la domanda fatidica a chi ha più competenza di
noi. La domanda, o meglio le domande, sono molto semplici:

«Può un amministratore di sistema, ai sensi della normativa sugli accessi
dell'AdS, amministrare il sistema che raccoglie centralmente i log? E può
essere egli stesso incaricato della masterizzazione delle informazioni su
supporto non riscrivibile qualora si sia scelta questa strada? Può un AdS
essere anche titolare o responsabile del trattamento e quindi avere il
compito di verificare il proprio operato?»

Prima magari puoi anche dare un'occhiata agli archivi (l'argomento è stato
trattato abbastanza approfonditamente), e magari dai un occhio anche a
quelli di law.sikurezza.it.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-05 11:54:45 UTC

Post by xfilesit
Sarà comunque con valutazione del titolare che dovrà essere
considerata l'idoneità degli strumenti disponibili oppure l'adozione
di strumenti più sofisticati, quali la raccolta dei log centralizzata
e l'utilizzo di dispositivi non riscrivibili

eccolo qua un altro dei punti: "dispositivi non riscrivibili": vedi
spiegazione di seguito.

Post by xfilesit
o di tecniche
crittografiche per la verifica dell'integrità delle registrazioni.
La FAQ 12 dice
12) Come va interpretata la caratteristica di inalterabilità dei log?

Devi avere uno speciale storage, il quale non consente cancellazioni, se
non quelle che farà lui automaticamente in base alla retention che è
stata impostata .... in una piccola azienda ciò non è praticabile
perché lo storage è troppo costoso.

Lo storage che conosco io si chiama Centera.

Fra l'altro, in Centera, la modifica delle impostazioni prevede
l'intervento di due operatori differenti, se non ricordo male, i quali
intervengono, fisicamente, e contemporaneamente, con due diverse chiavi
sullo storage.

chiunque avesse idee alternative le faccia presenti....

Post by xfilesit
È ben noto che il problema dell'attendibilità dei dati di audit, in
genere, riguarda in primo luogo la effettiva generazione degli
auditable events e, successivamente, la loro corretta registrazione e
manutenzione. Tuttavia il provvedimento del Garante non affronta
questi aspetti, prevedendo soltanto, come forma minima di
documentazione dell'uso di un sistema informativo, la generazione del
log degli "accessi" (login) e la loro archiviazione per almeno sei
mesi

a me in certi casi hanno parlato sia di "retention minima", sia di
"retention massima". In quali casi e in quali circostanze non saprei
dirtelo, ma sembra che in quei casi, non puoi tenere i log per periodi
superiori.

Post by xfilesit
Ora la norma è stata fatta apposta prevede varie interpretazioni per
essere sicuro però in caso di controllo i log devono essere
immodificabili (crittografati) e raccolti su un log server
centralizzato. (nelle verifiche effettuate hanno sempre richiesto
queste caratteristiche).

il fatto che da noi siano stati predisposti diversi gruppi di macchine,
alcuni dei quali inviavano log crittografati, e altri no, mi fa ritenere
con assoluta certezza che noi *qui* potremmo non averci capito una cippa :-)
Perché avrebbero operato questa distinzione? E quale era la circostanza?

La crittografia, con chiave unica per ogni host, serve a garantire la
provenienza del dato dallo specifico host.

Post by xfilesit
Sono daccordo che come è stata fatta è una misura demenziale ma visto
che possono dare una multe da 30 a 180,000 €

ecco: questo è uno dei motivi per cui eviterei, se possibile, di
mettermi a fare anche l'avvocato oltre che l'informatico.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-05 22:04:51 UTC

Devi avere uno speciale storage, [CUT]

Non *DEVI* avere nulla. Puoi, se vuoi, buttare i soldi come meglio ti aggrada.

chiunque avesse idee alternative le faccia presenti....

Salvi su uno storage normalissimo e firmi digitalmente. Oppure se vuoi
qualcosa di worm recuperi una vecchia stampante ad aghi e un pacco di nastro
continuo e stampi l'hash di ogni file firmato. Oppuri salvi su DVD come
detto dal garante. Oppure manti in append su un nastro LTO4 Worm (hai 800GB
non compressi a nastro da poter riempire).

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-06 02:08:21 UTC

Devi avere uno speciale storage, [CUT]

Non *DEVI* avere nulla. Puoi, se vuoi, buttare i soldi come meglio ti aggrada.

capiamoci su una cosa. Io NON voglio dire la mia e l'ho chiarito da
principio.
Sono entrato in questa discussione dicendo che non faccio l'avvocato e
che riporto quanto gli uffici legali e i vari certificati ISO900?? (non
mi ricordo) dell'azienda, richiedevano di fare.

Ci sono delle questioni che io ho posto, qui, e per le quali non ho
ricevuto risposte.

Loro mi fecero mantenere due gruppi diversi di server, alcuni dei quali
usavano la crittografia con chiave unica per ogni host, per certificare
l'origine del dato, e in altri casi invece non mi si richiedeva di fare ciò.

Perché operarono questa distinzione tra gruppi di server? Sarà mica che
ci sfugge qualcosa (che a me non interessa nemmeno sapere in fin dei conti)?

Tutto questo lo dico, non tanto per ottenere una risposta, che può
importarmi anche poco, ma per far capire che forse sarebbe il caso di
non avventurarsi troppo in discussioni simili.

chiunque avesse idee alternative le faccia presenti....

Salvi su uno storage normalissimo e firmi digitalmente.

questo è carino, ma ti protegge contro la modifiche, ma non contro la
cancellazione.
Puoi aggiungere attribui estesi, tipo quelli che si danno con chattr,
per inibire la cancellazione....
poi, quelli di EMC si sono inventati che Centera offre quel tantino di
sicurezza in più che è richiesto in questo caso: due omini devono agire
contemporaneamente per poter operare le modifiche allo storage e
abilitare quindi la cancellazione.

Tu mi dirai: data una password di 16 caratteri, la spezzi in due e dai i
primi 8 caratteri ad una persona, e gli altri 8 caratteri all'altra persona.

NO. La password se la possono passare l'uno con l'altro, la possono dire
a tutti, la possono trascrivere sui post-it e ci si può collegare in
remoto. Gli omini del centera, invece, usano un CHIAVE fisica e devono
recarsi fisicamente, e insieme, sul dispositivo e devono uscire dalla
stanza, ciascuno con la sua chiave in mano.

Post by THe_ZiPMaN
Oppure se vuoi
qualcosa di worm recuperi una vecchia stampante ad aghi e un pacco di
nastro continuo e stampi l'hash di ogni file firmato.

mmhhh ... un po' meglio, magari butti gli hash stampati in cassaforte.
Ma va bene per piccole realtà.... sotto ti sparo un paio di numeri.

Post by THe_ZiPMaN
Oppuri salvi su
DVD come detto dal garante.

Anche questo va bene in contesti di ridotte dimensioni.

Nel contesto in cui ho operato, erano stati predisposti 40 server Linux
con lo scopo di raccogliere dati di audit.
Successivamente ho cambiato azienda, e anche tipo di lavoro, e a un paio
di scrivanie di distanza ascoltavo dei colleghi che parlavano dello
stesso prodotto che io avevo usato poco prima.
Un giorno gli ho chiesto delucidazioni e mi hanno detto che
l'installazione del prodotto (che si chiama Sensage) consiste di 150
server Linux.
Ciò ti fa rendere conto, di quanto possa essere *immenso* il database
che memorizza i dati di audit e di che mole di dati stiamo parlando?

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

twistedbrain

2010-02-06 13:14:24 UTC

Post by Max_Adamo
capiamoci su una cosa. Io NON voglio dire la mia e l'ho chiarito da
principio.
Sono entrato in questa discussione dicendo che non faccio l'avvocato e
che riporto quanto gli uffici legali e i vari certificati ISO900?? (non
mi ricordo) dell'azienda, richiedevano di fare.

Cio` di cui credo si stia parlando e` la normativa introdotta dal
garante ed entrata in vigore a meta` di dicembre 2009 sugli ADS
(amministratori di sistema), la quale, che io sappia, non fa richieste
ulteriori rispetto a quelle esposte da Zippomanno.

Max_Adamo

2010-02-06 19:05:42 UTC

Può darsi che per le aziende del settore telecomunicazioni ci siano
norme aggiuntive. Perché, ripeto, per soddisfare le norma del garante,
sia azienda XXX, sia azienda YYY hanno fatto le stesse identiche cose.

Però, se parliamo di "non modificabilità del dato" penso che la cosa non
cambi. E allora cerchiamo di inquadrare le cose nel loro scenario
corretto e cerchiamo di capire che io non posso stampare hash per 1000
server tutti i santi giorni, e che non posso masterizzare 50 DVD al giorno.

Allo stesso modo non fa una grinza quel che fa notare Michela nell'altro
post: controllore e controllato non possono essere la stessa persona.
Sarebbe al di fuori di ogni logica.

A rigor di logica non puoi amministrare al tempo stesso sia la server
farm, sia la raccolta dei tuoi audit.

IMHO ci sono tanti punti oscuri... e anche come è stato fatto da noi,
secondo me presentava tante lacune. Ma credimi la discussione sarebbe
talmente lunga che nemmeno ci inizio :)

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

twistedbrain

2010-02-06 22:11:12 UTC

Post by Max_Adamo
Può darsi che per le aziende del settore telecomunicazioni ci siano
norme aggiuntive. Perché, ripeto, per soddisfare le norma del garante,
sia azienda XXX, sia azienda YYY hanno fatto le stesse identiche cose.

Ci sono diverse altre e piu` vaste norme a riguardo, questa specifica
riguarda solo gli ADS e richiede che vengano registrati i loro
accessi. Quindi non un auditing completo e solo di costoro (quando si
collegano e quando si scollegano dai sistemi con funzioni
amministrative di utente privilegiato).
Dunque i dati da raccogliere non sono tanti.

Post by Max_Adamo
Allo stesso modo non fa una grinza quel che fa notare Michela nell'altro
post: controllore e controllato non possono essere la stessa persona.
Sarebbe al di fuori di ogni logica.

Di fatti il controllore e` l'auditore che puo` accedere a quei log per
controllarli.
Resta il problema che chi gli da` quella possibilita` e` il sistemista
che dunque, anche se egli configura il sistema in modo che
effettivamente solo l'auditore vi possa accedere potrebbe anche
lasciarsi aperta una back door, senza parlare poi delle operazioni di
amministrazione di sistema che non necessariamente l'auditore sarebbe
in grado di fare.

Post by Max_Adamo
A rigor di logica non puoi amministrare al tempo stesso sia la server
farm, sia la raccolta dei tuoi audit.
IMHO ci sono tanti punti oscuri... e anche come è stato fatto da noi,
secondo me presentava tante lacune. Ma credimi la discussione sarebbe
talmente lunga che nemmeno ci inizio :)

Bisognerebbe cominciare dalla fine e cioe` da qual e` l'obiettivo che
voleva raggiungere il legislatore.

THe_ZiPMaN

2010-02-07 00:55:17 UTC

Post by twistedbrain
Bisognerebbe cominciare dalla fine e cioe` da qual e` l'obiettivo che
voleva raggiungere il legislatore.

L'obbiettivo del legislatore era chiaro: visto che per poter lavorare
l'amministratore deve avere dei privilegi che gli consentono di accedere a
dati personali e/o sensibili cui non dovrebbe né potrebbe avere accesso, è
opportuno istituire un minimo di controllo sugli accessi in modo da sapere
quando l'admin ha avuto tale possibilità.

Peccato che come al solito si sia perso in un bicchier d'acqua, imponendo
cose inutili e non considerando cose invece essenziali (come la
conservazione dei backup).

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-07 01:56:53 UTC

Bisognerebbe cominciare dalla fine e cioe` da qual e` l'obiettivo che
voleva raggiungere il legislatore.

non è un "minimo" di controllo e facciamo le cose tanto per passare il
tempo. Il controllo o c'è, o non c'è.
E se il controllore e il controllato sono la stessa persona, è chiaro
che il controllo non c'è, perché sei tu che te la canti e tu te la suoni.

Non è ammissibile che tu stesso vieni poi qui a dire: se voglio stacco
il cavo di rete e nel frattempo faccio quello che voglio.
Ma allora che stiamo a fare? Giochiamo? Perdiamo tempo?
Bisogna studiare un sistema a prova di furbo, e il sistema che tu hai
proposto, dove arriva pirla e cancella quello che gli pare, non è un
sistema a prova di furbo.

Post by THe_ZiPMaN
Peccato che come al solito si sia perso in un bicchier d'acqua,
imponendo cose inutili e non considerando cose invece essenziali (come
la conservazione dei backup).

Non è possibile fare backup di una quantità di dati così imponenente.
Ma non tanto perché ti serviranno troppe cassette, ma perché i dati
successivi ti arriverano ancora prima che tu abbia finito il backup in
corso.
Non farai in tempo a backuppare i dati: sono troppi e arrivano in
continuazione.

I dati sono ridondati con un cluster applicativo: ciascuno dei nostri
nodi contiene i suoi dati, e i dati del nodo successivo.

Se ti scoppiano i due nodi adiacenti, denunci l'evento, e fai una nota
scritta per il garante.

Inoltre, non serve conservare quei dati, perché pian piano, saranno
svecchiati dalla politica di max retention.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 02:13:22 UTC

Post by Max_Adamo
I dati sono ridondati con un cluster applicativo: ciascuno dei nostri
nodi contiene i suoi dati, e i dati del nodo successivo.

per inciso: puoi trovare un thread iniziato da me, dove chiedevo
consiglio su come fare il backup di una directory contenente svariati
milioni di file.

Bene - leggi bene - in attesa che venisse il garante, dovevo fare il
deploy per l'estensione dei nodi e dovevo fare il backup di uno di
questi nodi, il quale nodo conteneva SOLO 5 giorni di auditing (poiché i
dati più vecchi di 5 giorni venivano spostati su Centera).

Per fare, la copia raw dei file, con un tar, o con un rsync, ho
impiegato 24 ore.

LEGGI ANCORA MEGLIO: stiamo parlando solo di 5 giorni, e stiamo parlando
solo di un trentesimo del dato complessivo, poiché il dato completo era
distribuito su 30 nodi.... e nell'altra azienda di cui ti parlavavo il
dato completo era distribuito su 150 nodi.

Siamo ancora alla teoria dell'hash stampato sui pizzini, o ci stiamo
evolvendo verso qualcosa di più avanzato?

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-07 18:11:12 UTC

Post by Max_Adamo
Bisogna studiare un sistema a prova di furbo, e il sistema che tu hai
proposto, dove arriva pirla e cancella quello che gli pare, non è un
sistema a prova di furbo.

Ti sfido pubblicamente a mettere in piedi un sistema a prova di furbo del
quale io abbia accesso amministrativo e accesso fisico in cui tu possa
loggare tutti i miei accessi al sistema.

Quando ci sarai riuscito ne riparliamo, fino ad allora non fai altro che
confermare d'essere un quaqquaraqquà che scrive senza aver balia di quel che
dice.

Post by THe_ZiPMaN
Peccato che come al solito si sia perso in un bicchier d'acqua,
imponendo cose inutili e non considerando cose invece essenziali (come
la conservazione dei backup).

Dì la verità, ti pagano per far la figura del pirla. Non credo che qualcuno
possa arrivare a tanto senza un sostanziale interesse economico.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-07 19:01:05 UTC

Post by Max_Adamo
Non è possibile fare backup di una quantità di dati così imponenente.
Ma non tanto perché ti serviranno troppe cassette, ma perché i dati
successivi ti arriverano ancora prima che tu abbia finito il backup in
corso.
Non farai in tempo a backuppare i dati: sono troppi e arrivano in
continuazione.

Dì la verità, ti pagano per far la figura del pirla. Non credo che
qualcuno possa arrivare a tanto senza un sostanziale interesse economico.

se vuoi, incazzati pure, perché è l'unica cosa che sai fare.
So di cosa sta parlando perché si tratta di qualcosa che conosco,
evidentemente meglio di te, e l'ironia non fa assolutamente centro.

Ripeto: se una copia disk to disk mi ha preso 24 ore, una copia su
nastro, su un backup server remoto, avrebbe impiegato il triplo, il
quadruplo, 10 volte più tempo.

Nella realtà alle quali mi riferisco, non è possibile fare un backup di
quei dati.

E per finire, c'è pure qualcun altro che tenta di spiegarti che la *tua*
non è una soluzione al problema.

poi succede che anche i legali non hanno ben chiari i problemi e questa
è colpa della norma che è di difficile applicazione.
Ma tu non puoi dire di aver soddisfatto i requisiti della norma...
almeno fintanto che non proporrai all'OP e a me, un metodo per non
consentire la cancellazione del dato.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 19:04:48 UTC

Post by Max_Adamo
poi succede che anche i legali non hanno ben chiari i problemi e questa
è colpa della norma che è di difficile applicazione.
Ma tu non puoi dire di aver soddisfatto i requisiti della norma...
almeno fintanto che non proporrai all'OP e a me, un metodo per non
consentire la cancellazione del dato.

il fatto che tu dopo 5 giorni li riversi su blu-ray, non è una
soluzione, perché in quei 5 giorni può succedere di tutto.
Concentrati su questo, rispondi su questo e lascia fottere tutto il resto.

Inizia a parlarmi di "chattr" e di segregazione dei ruoli e forse
iniziano ad esserci un po'. Io - francamente - oltre allo speciale
storage (del quale tu non disporrai di chiavi) e quello che ho appena
detto (chattr+segregazione) non vedo altre soluzioni.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-07 19:14:42 UTC

Post by Max_Adamo
Io - francamente - oltre allo speciale
storage (del quale tu non disporrai di chiavi) e quello che ho appena
detto (chattr+segregazione) non vedo altre soluzioni.

Se non hai chiaro il problema (ti è stato detto circa 50 volte di leggere la
norma e le FAQ che ne sono l'interpretazione di riferimento ma ancora non
l'hai fatto e continui a battere incessantemente le tue stupide fantasie ),
è ovvio che tu non possa vedere nulla al di là delle idee che ti sei creato
nella tua mente.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-07 19:30:14 UTC

Io - francamente - oltre allo speciale storage (del quale tu non
disporrai di chiavi) e quello che ho appena detto
(chattr+segregazione) non vedo altre soluzioni.

Se non hai chiaro il problema (ti è stato detto circa 50 volte di
leggere la norma e le FAQ che ne sono l'interpretazione di riferimento
ma ancora non l'hai fatto e continui a battere incessantemente le tue
stupide fantasie ), è ovvio che tu non possa vedere nulla al di là delle
idee che ti sei creato nella tua mente.

non sono le mie fantasie, caro: io ho semplicemente riportato le
fantasie di azienda XX e azienda YY....

Parlando di questo aspetto del problema, posto da me e dall'OP, tu hai
proposto la firma digitale.
Ti si fa subito notare che la firma digitale (memorizzata o stampata su
carta) protegge solo contro la alterazione del dato.

Adesso, visto che quella *non* è una soluzione, cambi discorso e dici
che non è necessario.

Bene, ti propongo IO un'altra soluzione alternativa valida per le
piccole e medie aziende, e pongo fine della discussione:

La firma digitale andrà in realtime su uno storage di dimensioni
modestissime, sul quale la cancellazione è stata inibita.
Ad ogni file di firma, deve corrisondere un file dei log.
Se per una firma mancherà un file di log, vuol dire che qualcuno lo ha
cancellato.

Altresì, ascolta bene, testaccia dura: se tu fermi l'audit sul target,
il riavvio successivo sarà stato registra nel file di audit stesso.
ECCO PERCHE' SI RENDE NECESSARIO REGISTRARE TUTTO, E NON SOLO LE LOGIN
(non perché il garante richiede ciò, ma perché questa pratica consente
di chiudere il cerchio di tutte le verifiche)

Ma ti si sta iniziando ad aprire un pochettino la mente?

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 19:31:55 UTC

Post by Max_Adamo
Altresì, ascolta bene, testaccia dura: se tu fermi l'audit sul target,
il riavvio successivo sarà stato registra nel file di audit stesso.
ECCO PERCHE' SI RENDE NECESSARIO REGISTRARE TUTTO, E NON SOLO LE LOGIN
(non perché il garante richiede ciò, ma perché questa pratica consente
di chiudere il cerchio di tutte le verifiche)

questa parte qui credo che dovrebbe render chiaro il processo, più di
tutto il resto.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

twistedbrain

2010-02-07 21:32:23 UTC

So di non sapere, ma:

1. come da oggetto si sta parlando del logging degli ADS secondo
quanto previsto da legge entrata in vigore il 15/12/2009, non di altro
2. tale audit richiede solo la registrazione degli accessi (login e
logout) degli ADS e la memorizzazione non alterabile di questi dati e
la loro conservazione per almeno 6 mesi
3. se stacchi il cavo dal log server non e` che l'audit si fermi anche
se certamente finche' non lo riattacchi non arrivano piu` i dati
4. la cosa piu` semplice, senza dover mettere le mani sul log server
per un ADS maligno sarebbe manomettere i logger delle macchine che
inviano le registrazioni al log server.

Data questa situazione non risolvi nemmeno con accrocchi hardware come
quelli che hai descritto, devi avere una o piu` figure di
amministratori addetti a questo compito che soli abbiano i privilegi
per configurare e gestire i logger di tutti i sistemi e del logserver
e di quanto loggato e non solo del logserver. Questo non e` previsto e
dunque la normativa, QED, e` un piccolo monumento alla inutilita`
dannosa in quanto tale.

ValeRyo Saeba

2010-02-07 21:35:36 UTC

Post by twistedbrain
3. se stacchi il cavo dal log server non e` che l'audit si fermi anche
se certamente finche' non lo riattacchi non arrivano piu` i dati

Ops, sorry, io a questo non c'ero arrivato.
Immaginavo di staccare il cavo *del mio server*, invio sulla pass,
riattacco il cavo.
Syslogd non lavora in udp?

--
ValeRyo
XT600 "Katoki Pajama" - http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - http://www.slimmit.com/go.asp?7X0
GamerTag: http://card.mygamercard.net/IT/nxe/ValeRyo76.png

twistedbrain

2010-02-07 22:06:39 UTC

Post by ValeRyo Saeba

Post by twistedbrain
3. se stacchi il cavo dal log server non e` che l'audit si fermi anche
se certamente finche' non lo riattacchi non arrivano piu` i dati

Ops, sorry, io a questo non c'ero arrivato.

Era l'esempio di Zippo. Mi sono espresso male. E' chiaro che l'audit
si ferma, ma non il demone, rsyslogd o chi per lui sul logserver,
semplicemente non gli arrivano piu` dati. Chiaramente per fare le cose
bene al logserver non dovrebbero avere accesso fisico coloro i cui
login e logout vi vengono registrati (ma questo non e` assolutamente
scritto nella legge).

Post by ValeRyo Saeba
Immaginavo di staccare il cavo *del mio server*, invio sulla pass,
riattacco il cavo.

Ma va benissimo, per cominciare, poi modifichi il logger a inviare i
tuoi dati di login e logout a random o come meglio preferisci.

Post by ValeRyo Saeba
Syslogd non lavora in udp?

Mi sembra proprio di si`

Max_Adamo

2010-02-07 22:34:53 UTC

Post by ValeRyo Saeba
Immaginavo di staccare il cavo *del mio server*, invio sulla pass,
riattacco il cavo.

Ma va benissimo, per cominciare, poi modifichi il logger a inviare i
tuoi dati di login e logout a random o come meglio preferisci.

contestualizziamo il tutto: nella grande realtà, tu non hai accesso
fisico alla sala macchine. Parliamo quindi della piccola realtà.
cerco di spiegarmi:
L'evento del quale tu parli (distacco del cavo) va a finire nell'audit.
se tu lanci: "vi /file/di/audit" va a finire anch'esso nel file di audit.
se tu lanci: "rm /file/di/audit/", ho l'impressione che l'rm potrebbe
andare a finire nell'audit successivo, e quindi sarebbe registrato.
se tu fermi l'audit, cancelli il file, e riavvi l'audit, oltre ad aver
creato un vuoto nel collezionamento degli audit, avrai anche una
notifica di riavvio eseguita da utente pippo (se hai fatto sudo), o da
utente root (se hai fatto login direttamente come root).

p.s.: il syslog NON ha vuoti, perché un syslog può restare immodificato
per diverso tempo. L'audit no. L'audit ti dice anche che la macchina sta
respirando.

Post by ValeRyo Saeba
Syslogd non lavora in udp?

Mi sembra proprio di si`

syslog-ng lavora in tcp. Ma io non parlo più di syslog.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 22:10:53 UTC

Post by ValeRyo Saeba

Post by twistedbrain
3. se stacchi il cavo dal log server non e` che l'audit si fermi anche
se certamente finche' non lo riattacchi non arrivano piu` i dati

Ops, sorry, io a questo non c'ero arrivato.
Immaginavo di staccare il cavo *del mio server*, invio sulla pass,
riattacco il cavo.
Syslogd non lavora in udp?

syslog lavora anche tcp (syslog-ng)

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 22:15:20 UTC

nessuno sa (mi metto anche io tra quelli che non sanno e che cerchiamo
di ragionarci un po').

Post by twistedbrain
1. come da oggetto si sta parlando del logging degli ADS secondo
quanto previsto da legge entrata in vigore il 15/12/2009, non di altro

Claro.

Post by twistedbrain
2. tale audit richiede solo la registrazione degli accessi (login e
logout) degli ADS e la memorizzazione non alterabile di questi dati e
la loro conservazione per almeno 6 mesi

Claro che la direttiva non parla di audit. La direttiva pone obiettivi e
non parla degli strumenti per raggiungere questi obiettivi.

Post by twistedbrain
3. se stacchi il cavo dal log server non e` che l'audit si fermi anche
se certamente finche' non lo riattacchi non arrivano piu` i dati

vuoi vedere che se stacchi il cavo ti ritrovi qualcosa nel file di
audit? ;-) Ripeto: sull'audit ti ritrovi persino le syscall (che
filtrerai adeguatamente).

Post by twistedbrain
4. la cosa piu` semplice, senza dover mettere le mani sul log server
per un ADS maligno sarebbe manomettere i logger delle macchine che
inviano le registrazioni al log server.

appunto: modificare i log è una cavolata. Per questo io parlo di audit.
Qui la discussione si complica e viene fuori man mano tutto il resto...
che spero chiarisca tutti, me compreso.... e se vogliamo parlare
*seriamente* di non modificabilità del dato.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 22:20:00 UTC

Post by twistedbrain
3. se stacchi il cavo dal log server non e` che l'audit si fermi anche
se certamente finche' non lo riattacchi non arrivano piu` i dati

vuoi vedere che se stacchi il cavo ti ritrovi qualcosa nel file di
audit? ;-) Ripeto: sull'audit ti ritrovi persino le syscall (che
filtrerai adeguatamente).

Chiaramente, il server che raccoglie l'audit, farà pure self-auditing.
Andiamo avanti.... perché credo che stiamo ingranando un pochettino.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Crononauta

2010-02-07 22:32:53 UTC

On Sun, 7 Feb 2010 13:32:23 -0800 (PST), twistedbrain <***@gmail.com> wrote:
[...]

Post by twistedbrain
Data questa situazione non risolvi nemmeno con accrocchi hardware come
quelli che hai descritto, devi avere una o piu` figure di
amministratori addetti a questo compito che soli abbiano i privilegi
per configurare e gestire i logger di tutti i sistemi e del logserver
e di quanto loggato e non solo del logserver. Questo non e` previsto e
dunque la normativa, QED, e` un piccolo monumento alla inutilita`
dannosa in quanto tale.

È sempre stata la considerazione che mi è venuta... nel momento in cui
un administrator è appunto administrator, ovvero ha potere di gestione
sulla macchina, ha facoltà di alterare il logger a piacere.

A quel punto il log nasce corrotto "ab origine", e tutto il discorso
sulla registrazione, firma, non manomissibilità, duplicazione, storage
su supporti non modificabili e quant'altro, è pura fuffa.

--
Massimo Bacilieri AKA Crononauta
Skype: crononauta <***@gmail.com>
Facebook: Massimo Bacilieri

Max_Adamo

2010-02-07 22:48:27 UTC

Post by Crononauta
È sempre stata la considerazione che mi è venuta... nel momento in cui
un administrator è appunto administrator, ovvero ha potere di gestione
sulla macchina, ha facoltà di alterare il logger a piacere.

per questo lo speciale storage cui si fa riferimento richiede
l'intervento di due omini armati di due distinte chiavette.
Non è tutto affidato al caso e EMC² non si muove per niente.

Post by Crononauta
A quel punto il log nasce corrotto "ab origine", e tutto il discorso
sulla registrazione, firma, non manomissibilità, duplicazione, storage
su supporti non modificabili e quant'altro, è pura fuffa.

siamo prossimi alla fuffa e questo non lo metto in dubbio ^_^

Vi prego, però, di descrivermi passo passo tutte le operazioni che
eseguireste per alterare un file di audit, o cancellarlo senza farvene
accorgere.
Spiegatemi, passo passo, la procedura che usereste. Attenzione: non
parlo di loggin, ma di auditing (che viene utilizzato in luogo del
loggin per questa precisa ragione).

ti dico in partenza che:
- non puoi fermarlo perché il riavvio viene registrato a nome
dell'utente che lo riavvia.
- non puoi cancellarlo (a occhio l'rm finisce nel file successivo).
- un vuoto nell'auditing è palesemente riscontrabile
- l'auditing stesso avrà un pid differente al riavvio successivo.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Crononauta

2010-02-08 00:15:47 UTC

Secondo me stai commettendo un errore in partenza nel pensare che un
sysadmin voglia in qualche modo "hackerare" un sistema funzionante,
quando molto più semplicemente - essendo sysadmin - può benissimo
configurare in partenza tutto il sistema di logging o auditing per
lasciarsi una "porta" aperta dove farsi i suoi porci comodi.

Al limite, se uno vuol farla proprio sporca ed ha buone capacità, può
prendersi i sorgenti di audit e farsi una versione "ad hoc", e allora
ciao.

A quel punto chiunque può ragionevolmente ritenere che la macchina sia
configurata nel rispetto della normativa, quando nei fatti il sysadmin
continua a fare il cazzo che vuole impunemente.

Insomma, stiamo parlando dell'*amministratore di quella macchina*,
diamine, mica di un utente qualsiasi.

In sostanza, la normativa è uno degli ennesimi esempi di UCAS (*) per
creare problemi inutili senza ottenere nei fatti ciò che si voleva,
perché alla fine quand'anche hai fatto tutto "a norma", ti ritrovi
sempre con un sistema che funziona sulla buona fede dell'amministratore,
e nient'altro.

Al che, se devi basarti sulla buona fede dell'amministratore, allora
vanno bene anche i normali log, senza complicazioni.

(*) Ufficio Complicazioni Affari Semplici

--
Massimo Bacilieri AKA Crononauta
Skype: crononauta <***@gmail.com>
Facebook: Massimo Bacilieri

THe_ZiPMaN

2010-02-08 00:20:07 UTC

Post by Crononauta
Insomma, stiamo parlando dell'*amministratore di quella macchina*,
diamine, mica di un utente qualsiasi.

Oh, sono 20 post che si tenta di farglielo capire, ma probabilmente il
neurone è in pausa caffè e non gli risponde :-)

Post by Crononauta
In sostanza, la normativa è uno degli ennesimi esempi di UCAS (*) per
creare problemi inutili senza ottenere nei fatti ciò che si voleva,
perché alla fine quand'anche hai fatto tutto "a norma", ti ritrovi
sempre con un sistema che funziona sulla buona fede dell'amministratore,
e nient'altro.

Esattamente

Post by Crononauta
Al che, se devi basarti sulla buona fede dell'amministratore, allora
vanno bene anche i normali log, senza complicazioni.

Appunto, e proprio per questo non vi è nemmeno alcun motivo per vietare
all'amministratore l'accesso a quei log.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-08 00:42:44 UTC

Post by Crononauta
Al limite, se uno vuol farla proprio sporca ed ha buone capacità, può
prendersi i sorgenti di audit e farsi una versione "ad hoc", e allora
ciao.

ciao si. Questo mi spiazza un po', però parliamo in termini pratici:
cosa inibisci tu a quell'auditd e cosa il garante potrebbe/dovrebbe
poter controllare per veririfaca il buon funzionamento?
Andiamo sull'ipotetico:
il garante ti dice:
ferma l'audit, riavvialo e controlla che questo evento venga registrato.
poi ti dice:
lancia un 'ls' e controlla che l'evento venga registrato.

A quel punto l'audit è stato testato. E c'è poco altro da aggiungere.

Certo, il tuo codice manomesso può prevedere che il 29 febbrario degli
anni bisestili l'audit non funzionerà, per l'utente root, in determinate
fasce orarie e questo il garante non lo vede. O potrai aggiungere tutte
le eccezioni assurde possibili ed immaginabili. E il garante non può
accorgersi di ciò.
Però, scusami, mi sembrano scenari un tantino parossistici.

Post by Crononauta
In sostanza, la normativa è uno degli ennesimi esempi di UCAS (*)

non dirmelo oltre, perché sono d'accordo.
E' possibile attenersi alla norma in aziende molto grandi, dove un cavo
di rete che viene scollegato, allarma un intero front-end preposto a
guardare le lucette del monitoring 24 ore al giorno.
E' quasi impossibile da attuare per le piccole aziende, dove il
sistemista è - per forza di cose - un fac-totum che fa anche
l'elettricista nella sala macchine. E non scherzo. Quando lavoravo per
una azienda media a milano, mi occupavo dai quadretti per abilitare le
linee telefoniche, al riordino dei cavi sui patch-panel, ai database e
alle applicazioni :-)

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-08 01:00:26 UTC

Post by Crononauta
Al limite, se uno vuol farla proprio sporca ed ha buone capacità, può
prendersi i sorgenti di audit e farsi una versione "ad hoc", e allora
ciao.

ciao si. Questo mi spiazza un po',

Ma non eri sicuro come una roccia che non si potesse fare nulla?

Post by Max_Adamo
cosa inibisci tu a quell'auditd e cosa il garante potrebbe/dovrebbe
poter controllare per veririfaca il buon funzionamento?
ferma l'audit, riavvialo e controlla che questo evento venga registrato.
lancia un 'ls' e controlla che l'evento venga registrato.
A quel punto l'audit è stato testato. E c'è poco altro da aggiungere.

Evita di osentare sicurezza su argomenti di cui hai già dimostrato
ampiamente di non capire nulla. Chiunque ricordi il famoso tentativo di
compromissione dei sorgenti di Linux non avrebbe alcun dubbio su cosa fare
per modificare l'audit.

Post by Max_Adamo
Certo, il tuo codice manomesso può prevedere che il 29 febbrario degli
anni bisestili l'audit non funzionerà, per l'utente root, in determinate
fasce orarie e questo il garante non lo vede. O potrai aggiungere tutte
le eccezioni assurde possibili ed immaginabili. E il garante non può
accorgersi di ciò.
Però, scusami, mi sembrano scenari un tantino parossistici.

Spiegaci o sommo... secondo te questo è uno scenario esasperato??? Una cosa
banale come questa è esasperata? E la famosa backdoor nel kernel di cui
sopra allora cosa doveva essere?

Post by Max_Adamo
E' possibile attenersi alla norma in aziende molto grandi, dove un cavo
di rete che viene scollegato, allarma un intero front-end preposto a
guardare le lucette del monitoring 24 ore al giorno.

Bah... quando uno non capisce nulla puoi anche metterlo di fronte alla
realtà ma l'unica cosa che vede sarà sempre e solo prosciutto.

Post by Max_Adamo
Quando lavoravo per
una azienda media a milano, mi occupavo dai quadretti per abilitare le
linee telefoniche, al riordino dei cavi sui patch-panel, ai database e
alle applicazioni :-)

Immagino sia fallita... o che si sia salvata dopo la tua dipartita.

Pussa via... f/u

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

MaxAdamo

2010-02-08 01:14:52 UTC

Post by Crononauta
Al limite, se uno vuol farla proprio sporca ed ha buone capacità, può
prendersi i sorgenti di audit e farsi una versione "ad hoc", e allora
ciao.

ciao si. Questo mi spiazza un po',

Ma non eri sicuro come una roccia che non si potesse fare nulla?

Spiegaci o sommo... secondo te questo è uno scenario esasperato??? Una cosa
banale come questa è esasperata? E la famosa backdoor nel kernel di cui
sopra allora cosa doveva essere?

Ma si, ma certo. Ma chi è che non si riscrive un sottosistema di audit
tutti i giorni?
A tal proposito, sarei curioso di sapere quanto codice tu hai generato
in vita tua.
sbaglio o tu dovevi fare login su un sistema da me configurato, dove
io, a questo punto mi memorizzo anche l'md5 dell'audit?

In base a quanto ho espresso fino ad ora:
a me basta sapere che c'è stato fermo volontario, una manomissione
sull'audit. Questo ti pone già nella situazione di "colpevole".
Tu puoi nascondermi quel che succede in mezzo. E questo l'ho detto
chiaramente (se rileggi bene): io ti traccio al successivo riavvio e
ti traccio anche perché crei un vuoto nella raccolta degli audit: gli
audit dei quali parlo io registrano il server che respira (ho rimosso
solo la syscall 'semop').

p.s.: mi pare che tu stia diventando un po' thorin di questi tempi,
che immagino sarà finito in qualche manicomio :-)

THe_ZiPMaN

2010-02-07 22:18:59 UTC

Post by Max_Adamo
Bene, ti propongo IO un'altra soluzione alternativa valida per le
La firma digitale andrà in realtime su uno storage di dimensioni
modestissime, sul quale la cancellazione è stata inibita.
Ad ogni file di firma, deve corrisondere un file dei log.
Se per una firma mancherà un file di log, vuol dire che qualcuno lo ha
cancellato.

Ora da bravo dismetti i panni del clown ed illustraci:
a) in cosa differisce quanto sopra dalla soluzione che ho ripetutamente
descritto
b) come fai la firma in *realtime* (o cosa intendi visto che parrebbe tu non
sappia quel di cui parli)
c) e se qualcuno cancella i log cosa fai? e come ha fatto a cancellarlo se
era inibita la cancellazione? E cosa cambia rispetto ad un sistema in cui la
cancellazione non era inibita?

Dopo tutte le stupidate che hai detto per decine di post alla fine forse ti
sei accorto di aver sparato minchiate e stai provando un ravvedimento operoso?

Post by Max_Adamo
Altresì, ascolta bene, testaccia dura: se tu fermi l'audit sul target,
il riavvio successivo sarà stato registra nel file di audit stesso.

Non è significativo dato che vi sono diversi motivi, tutti legittimi, per
cui è normale che l'audit venga fermato dall'amministratore (uno su tutti il
riavvio della macchina).

Post by Max_Adamo
ECCO PERCHE' SI RENDE NECESSARIO REGISTRARE TUTTO, E NON SOLO LE LOGIN

E non risolvi ugualemente nulla (ma spiegare a te qualche concetto di
sicurezza è alquanto difficoltoso) perché l'amministratore può ugualmente
fare quel che vuole senza che venga registrata la sua attività.

Post by Max_Adamo
Ma ti si sta iniziando ad aprire un pochettino la mente?

Sì, la mente mi si sta aprendo. E' sempre più limpida l'associazione tra te
ed Euclide, solo che lui, a volte, capisce di più.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-07 22:28:30 UTC

a) in cosa differisce quanto sopra dalla soluzione che ho ripetutamente
descritto
b) come fai la firma in *realtime* (o cosa intendi visto che parrebbe tu
non sappia quel di cui parli)

1. l'assunto è che stiamo parlando di auditing, e non di syslog. L'hai
capito il perché, o ancora dobbiamo reiterare: se tu stacchi il cavo di
rete l'audit lo registra, se tu fermi l'audit e lo cancelli, l'audit
registra l'avvio successivo ad opera di pincopallo (anche se ha fatto
sudo viene registrato come pincopallo) alle ore tal dei tali. Ma hai mai
visto un file di audit?

2. a questo punto è chiaro che sul target tu non puoi fare nulla (o ti
devo fare il disegnino?)

3. se la firma va su uno storage che inibisce la cancellazione, SENZA
GIACERE SU UN SERVER DOVE PUOI CANCELLARLA, necessiti di tale device
(del quale tu non hai parlato). Altrimenti tu cancelli la firma (o ingoi
la stampa), cancelli il log associato e non abbiamo risolto niente.
Purtroppo non si possono scrivere in append tanti filettini su DVD.
Quindi il dvd mi pare da scartare.

4. la firma che parte dal target deve andare *direttamente* su quello
storage, dove non è possibile cancellare.

Questa è un'idea buttata lì, per una realtà di piccole dimensioni.

Post by THe_ZiPMaN
c) e se qualcuno cancella i log cosa fai?

AUDIT non LOG.
se qualcuno cancella gli audit ha fatto qualcosa di penalmente
rilevamente. E pertanto è da inculare.

Al prossimo post ti faccio il disegnino.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 22:37:13 UTC

Post by Max_Adamo
1. l'assunto è che stiamo parlando di auditing, e non di syslog. L'hai
capito il perché, o ancora dobbiamo reiterare: se tu stacchi il cavo di
rete l'audit lo registra, se tu fermi l'audit e lo cancelli, l'audit
registra l'avvio successivo ad opera di pincopallo (anche se ha fatto
sudo viene registrato come pincopallo) alle ore tal dei tali. Ma hai mai
visto un file di audit?

se tu lanci "vi /file/di/audit" va a finire in audit anche questo
se lanci "rm /file/di/audit" questo va a finire nell'audit creato
successivamente.

Non hai scampo con l'audit.

Questo è il motivo per cui si rende necessario fare auditing, e non solo
collezzionamento di log.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-07 22:55:26 UTC

Post by Max_Adamo
La firma digitale andrà in realtime su uno storage di dimensioni
modestissime, sul quale la cancellazione è stata inibita.
Ad ogni file di firma, deve corrisondere un file dei log.
Se per una firma mancherà un file di log, vuol dire che qualcuno lo ha
cancellato.

a) in cosa differisce quanto sopra dalla soluzione che ho ripetutamente
descritto
b) come fai la firma in *realtime* (o cosa intendi visto che parrebbe tu
non sappia quel di cui parli)

1. l'assunto è che stiamo parlando di auditing, e non di syslog.

Veramente l'assunto è rispettare la normativa del garante, ma capisco che
ormai per poter fare mirror climbing ti faccia comodo cambiare assunti...
Per quanto mi riguarda la cosa è indifferente.

Post by Max_Adamo
2. a questo punto è chiaro che sul target tu non puoi fare nulla (o ti
devo fare il disegnino?)

Invece di sparare cazzate a raffica, la vuoi fare o no la scommessa? Ti do
una bella macchina, tu la logghi con tutto quel cazzo che vuoi, mi dai
accesso fisico e amministrativo alla macchina e io vi accedo
fraudolentemente senza che i tuoi log, pardon, AUDIT, riportino nulla.

Post by Max_Adamo
3. se la firma va su uno storage che inibisce la cancellazione, SENZA
GIACERE SU UN SERVER DOVE PUOI CANCELLARLA, necessiti di tale device
(del quale tu non hai parlato). Altrimenti tu cancelli la firma (o ingoi
la stampa), cancelli il log associato e non abbiamo risolto niente.

Vediamo dove stanno le differenze....
Se io ingoio la stampa ovviamente manca una stampa quindi so che il sistema
è stato manomesso ma non so da chi e perché.
Se io cancello una firma ovviamente questa risulta sul server di firma
mentre non è presente sul server syslog, quindi mi accorgo che il sistema è
stato manomesso ma non so da chi e perché.

Ora ci illustri la differenza che passa tra il non avere i dati e sapere di
non averli perché manca una pagina stampata, ed il non avere i dati perché
l'admin bastardo ha tolto 3 dischi dallo "storage che non permette le
cancellazioni e costa 3 milioni di euro" e gli ha dato sopra una martellata.

Post by Max_Adamo
Purtroppo non si possono scrivere in append tanti filettini su DVD.

Non si può far mai niente di quel che non si conosce.

Post by THe_ZiPMaN
c) e se qualcuno cancella i log cosa fai?

AUDIT non LOG.
se qualcuno cancella gli audit ha fatto qualcosa di penalmente
rilevamente. E pertanto è da inculare.

Innanzitutto comincia ad illustrarci COSA sarebbe penalmente rilevante e
PERCHÉ, ovviamente fornendo i relativi riferimenti normativi se non vuoi
passare per un cretino che spara cazzate a vanvera.

Poi illustraci dove starebbe la differenza tra cancellare gli audit del tuo
superfichissimo storage e stracciare la stampa delle firme dei log o la
normale cancellazione dei log.

Post by Max_Adamo
Al prossimo post ti faccio il disegnino.

Non servono dimostrazioni. Sono già certissimo che tu sia meglio come
disegnatore che come sysadmin.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-07 23:02:32 UTC

a) in cosa differisce quanto sopra dalla soluzione che ho ripetutamente
descritto
b) come fai la firma in *realtime* (o cosa intendi visto che parrebbe tu
non sappia quel di cui parli)

1. l'assunto è che stiamo parlando di auditing, e non di syslog.

Veramente l'assunto è rispettare la normativa del garante,

Il garante non parla di strumenti (quindi non parla di suyslog e di
auditd). Il garante pone degli obiettivi.

Post by Max_Adamo
2. a questo punto è chiaro che sul target tu non puoi fare nulla (o ti
devo fare il disegnino?)

Invece di sparare cazzate a raffica, la vuoi fare o no la scommessa? Ti
do una bella macchina, tu la logghi con tutto quel cazzo che vuoi, mi
dai accesso fisico e amministrativo alla macchina e io vi accedo
fraudolentemente senza che i tuoi log, pardon, AUDIT, riportino nulla.

Ottimo!
Quando ci sarai riuscito segna un bug direttamente qui:
http://people.redhat.com/sgrubb/audit/
e qui:
https://bugs.launchpad.net/ubuntu/+filebug

mi credi se ti dico che l'audit è di per se inalterabile? Altrimenti, ma
che cazzo l'hanno fatto a fare?
Già che ci sei, descrivimi passo passo come faresti ad alterare un file
di audit senza lasciare traccia.

Te lo do io un suggerimento: l'unica cosa che puoi fare è prendere a
martellate il device dove audisp scrive i suoi dati! Farai le operazioni
losche che devi fare, e poi richiederai la sostituzione del disco.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 23:04:12 UTC

Post by Max_Adamo
Te lo do io un suggerimento: l'unica cosa che puoi fare è prendere a
martellate il device dove audisp scrive i suoi dati! Farai le operazioni
losche che devi fare, e poi richiederai la sostituzione del disco.

ecco trovata una back-door. Ma questo è un altro paio di maniche, e sono
io il primo a dire che tale norma è di difficile applicazione.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 23:09:00 UTC

ecco trovata una back-door. Ma questo è un altro paio di maniche, e sono
io il primo a dire che tale norma è di difficile applicazione.

workaround: al contrario di come si è fatto nella nostra azienda,
l'audit deve scrivere sulla partizione di root.
Per evitare problemi con lo spazio disco, non appena viene superata una
certa dimensione, si dice al file di configurazione dell'audit, di
spezzare il file e di scrivere su uno nuovo (funziona così anche se
molti non hanno idea di cosa sia l'auditing su Unix).
Il file più vecchio sarà quindi inviato sullo storage.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-07 23:23:19 UTC

Post by Max_Adamo
2. a questo punto è chiaro che sul target tu non puoi fare nulla (o ti
devo fare il disegnino?)

Invece di sparare cazzate a raffica, la vuoi fare o no la scommessa? Ti
do una bella macchina, tu la logghi con tutto quel cazzo che vuoi, mi
dai accesso fisico e amministrativo alla macchina e io vi accedo
fraudolentemente senza che i tuoi log, pardon, AUDIT, riportino nulla.

Ottimo!
http://people.redhat.com/sgrubb/audit/
https://bugs.launchpad.net/ubuntu/+filebug

L'accetti la scommessa o no? Non mi sembra che ci sia molto dire o fare. Se
l'accetti nei termini in cui è stata posta prendiamo un paio di persone
competenti qui sul NG che giudicheranno. Ovviamente chi perde paga e come
minimo ci sono le spese di viaggio, vitto e alloggio.

Post by Max_Adamo
mi credi se ti dico che l'audit è di per se inalterabile? Altrimenti, ma
che cazzo l'hanno fatto a fare?

Quando uno non sa nemmeno a cosa servono gli strumenti che usa la cosa è
veramente triste.

Post by Max_Adamo
Già che ci sei, descrivimi passo passo come faresti ad alterare un file
di audit senza lasciare traccia.

Ma manco per il cazzo. Primo non inventare cose che io non ho detto, secondo
se vuoi vedere qualsiasi cosa, prima *paghi*. Se non vuoi pagare puoi
studiare, e magari eviti anche di fare figuracce a raffica.

Bravo... tu continua pure nelle tue convinzioni... io resto in attesa della
scommessa.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-07 23:38:03 UTC

Post by Max_Adamo
2. a questo punto è chiaro che sul target tu non puoi fare nulla (o ti
devo fare il disegnino?)

Invece di sparare cazzate a raffica, la vuoi fare o no la scommessa? Ti
do una bella macchina, tu la logghi con tutto quel cazzo che vuoi, mi
dai accesso fisico e amministrativo alla macchina e io vi accedo
fraudolentemente senza che i tuoi log, pardon, AUDIT, riportino nulla.

Ottimo!
http://people.redhat.com/sgrubb/audit/
https://bugs.launchpad.net/ubuntu/+filebug

L'accetti la scommessa o no? Non mi sembra che ci sia molto dire o fare.
Se l'accetti nei termini in cui è stata posta prendiamo un paio di
persone competenti qui sul NG che giudicheranno. Ovviamente chi perde
paga e come minimo ci sono le spese di viaggio, vitto e alloggio.

potremmo fare la scommessa in remoto.
Potrei installare un vserver. E' da capire come funziona il meccanismo
dell'auditing su eventuali jail.
Se funziona come sulle zone solaris (se non ricordo male) ti inculerei
in partenza senza troppo piacere, perché audisp girerebbe al di fuori
della jail e non potresti nemmeno toccarlo o nemmeno vederlo.
In caso si potesse installare all'inerno della jail, potrei installarlo
sulla mia macchina e ti darei una pass.

Quindi funziona così, se si riesce ad organizzare la cosa:
io lancio "screen -x blabla" tu ti agganci al mio screen con lo stesso
comando, e in questo modo vedo cosa stai facendo. O vuoi farlo a mia
insaputa? Ma io devo vedere che è vero che tu lanci qualcosa che audisp
non riesce ad intercettare.

Quindi non ci sono spese.
Se ci riesci, a me il compito di segnalare questa vulnerabilità del
sottosistema di audit
se non ci riesci .... uhm uhm .... dovresti cambiare la tua signature
per due mesi e dovrai scriverci dentro:
Max_Adamo effettivamente ha sbattuto la testa per un anno sulla
questione dell'auditing e qualcosa ha veramente imparato in questo
periodo. Perché, ho dovuto fare questa figuraccia con lui?

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-07 23:48:00 UTC

Post by Max_Adamo
2. a questo punto è chiaro che sul target tu non puoi fare nulla (o ti
devo fare il disegnino?)

Invece di sparare cazzate a raffica, la vuoi fare o no la scommessa? Ti
do una bella macchina, tu la logghi con tutto quel cazzo che vuoi, mi
dai accesso fisico e amministrativo alla macchina e io vi accedo
fraudolentemente senza che i tuoi log, pardon, AUDIT, riportino nulla.

Ottimo!
http://people.redhat.com/sgrubb/audit/
https://bugs.launchpad.net/ubuntu/+filebug

L'accetti la scommessa o no? Non mi sembra che ci sia molto dire o fare.
Se l'accetti nei termini in cui è stata posta prendiamo un paio di
persone competenti qui sul NG che giudicheranno. Ovviamente chi perde
paga e come minimo ci sono le spese di viaggio, vitto e alloggio.

potremmo fare la scommessa in remoto.

Quale parte di "accesso fisico e amministrativo alla macchina" non hai capito?

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

THe_ZiPMaN

2010-02-07 23:50:22 UTC

Post by THe_ZiPMaN
Quale parte di "accesso fisico e amministrativo alla macchina" non hai capito?

E comunque con piffero che ti mostro quel che faccio; per imparare bisogna
*pagare*. L'unica cosa che farei è darti una prova minimale che ho
effettivamente acceduto alla macchina senza che il tuo audit abbia rilevato
nulla di anormale.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-07 23:58:16 UTC

Post by THe_ZiPMaN
Quale parte di "accesso fisico e amministrativo alla macchina" non hai capito?

E comunque con piffero che ti mostro quel che faccio; per imparare
bisogna *pagare*. L'unica cosa che farei è darti una prova minimale che
ho effettivamente acceduto alla macchina senza che il tuo audit abbia
rilevato nulla di anormale.

il mio kernel non supporta vserver.
Spiega ai presente le operazioni che faresti passo passo.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Max_Adamo

2010-02-07 23:56:02 UTC

Post by Max_Adamo
2. a questo punto è chiaro che sul target tu non puoi fare nulla (o ti
devo fare il disegnino?)

Invece di sparare cazzate a raffica, la vuoi fare o no la
scommessa? Ti
do una bella macchina, tu la logghi con tutto quel cazzo che vuoi, mi
dai accesso fisico e amministrativo alla macchina e io vi accedo
fraudolentemente senza che i tuoi log, pardon, AUDIT, riportino nulla.

Ottimo!
http://people.redhat.com/sgrubb/audit/
https://bugs.launchpad.net/ubuntu/+filebug

L'accetti la scommessa o no? Non mi sembra che ci sia molto dire o fare.
Se l'accetti nei termini in cui è stata posta prendiamo un paio di
persone competenti qui sul NG che giudicheranno. Ovviamente chi perde
paga e come minimo ci sono le spese di viaggio, vitto e alloggio.

potremmo fare la scommessa in remoto.

Quale parte di "accesso fisico e amministrativo alla macchina" non hai capito?

Ti do root sul vserver. Chi se ne frega.... o adesso mi dici che sei in
grado di scalare anche fuori dalla jail? sei proprio una hacker de paura.

con l'accesso fisico cosa ci vuoi fare? Mi vuoi prendere il disco a
martellate? non c'è bisogno, ti ho detto io che quell'espediente funziona.

Vuoi giocare con il cavo di rete?
Descrivi qui passo pass quello che faresti e ti spiego perché non
funzionerebbe.

Inizio a essere sicuro che non hai chiaro il funzionamento dell'audit.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-08 00:16:16 UTC

Post by THe_ZiPMaN
Quale parte di "accesso fisico e amministrativo alla macchina" non hai capito?

Ti do root sul vserver. Chi se ne frega.... o adesso mi dici che sei in
grado di scalare anche fuori dalla jail? sei proprio una hacker de paura.

Spesso e volentieri mi chiedo se ci sei o se ci fai, poi capisco che è tempo
sprecato farsi certe domande. Non riesci a caomprendere 6 parole in fila
quindi attendersi che tu capisca qualcosa di informatica è effettivamente
fuori luogo. E non ci si vuole certo un acaro per queste cose, basta un
minimo di intelligenza.

Post by Max_Adamo
con l'accesso fisico cosa ci vuoi fare? Mi vuoi prendere il disco a
martellate? non c'è bisogno, ti ho detto io che quell'espediente funziona.
Vuoi giocare con il cavo di rete?

E' divertentissimo vederti zompettare come un criceto nella ruota...

Post by Max_Adamo
Descrivi qui passo pass quello che faresti e ti spiego perché non
funzionerebbe.

Se vuoi ti do le coordinate bancarie per il bonifico. Una volta arrivato il
bonifico non è un problema spiegarti tutto quel che vuoi.

Post by Max_Adamo
Inizio a essere sicuro che non hai chiaro il funzionamento dell'audit.

Continua a zompettare e quando ti sei stufato e avvisa. Per il momento però
torna nell'ignore list; ogni tanto mi sforzo di pensare che tu possa aver
imparato qualcosa e che non stia sempre a sparar cazzate e sparlare di quel
che non conosci, ma tutte le volte è sempre la solita delusione...
In questo sei una certezza.

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

Max_Adamo

2010-02-08 00:23:12 UTC

Post by THe_ZiPMaN
In questo sei una certezza.

A-S-S-O-L-U-T-A-M-E-N-T-E P-E-N-O-S-O.

Avevo chiesto una sola stupidissima cosa e non hai risposto:
riporta qui LE TRE OPERAZIONI IN CROCE che hai intenzione di fare quando
ti trovi di fronte alla macchina con accesso amministrativo.

Io, o chiunque altro, avremmo detto: funziona / non funziona.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

THe_ZiPMaN

2010-02-08 00:27:40 UTC

Post by Max_Adamo
riporta qui LE TRE OPERAZIONI IN CROCE che hai intenzione di fare quando
ti trovi di fronte alla macchina con accesso amministrativo.
Io, o chiunque altro, avremmo detto: funziona / non funziona.

Continua a rosicare... finché non paghi da me non avrai nulla.
Altrimenti prova con Crononauta; magari lui è più buono di me, o si lascia
commuovere dalla pena di vederti sbavare dietro alla soluzione, e te la cede
per meno.

Sciò, Sciò.... f/u

--
Flavio Visentin

Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

MaxAdamo

2010-02-08 01:02:39 UTC

La soluzione non la devi cedere a me, ma al popolo di Usenet, il
quale
ti legge e non sa più se aver paura o dover ridere di questo hacker
de
paura. .... e nun te 'ncazza!!

Crononauta non ha detto che riesce ad aggirare l'audit di una
macchina. Ciò che lui dice ha anche un senso, ma è una cosa un po'
parossistica (riscriversi il codice....)

Massimiliano

Crononauta

2010-02-08 08:45:09 UTC

Post by MaxAdamo
Crononauta non ha detto che riesce ad aggirare l'audit di una
macchina. Ciò che lui dice ha anche un senso, ma è una cosa un po'
parossistica (riscriversi il codice....)

Veramente ti sto dicendo una cosa ancora diversa: riscrivere l'audit è
una possibilità, ma il punto base è che se tu sei l'amministratore della
macchina, sei quello che la installa e la configura. E di conseguenza
configura anche l'audit. Ci siamo? ;-)

--
Massimo Bacilieri AKA Crononauta

Max_Adamo

2010-02-07 02:05:22 UTC

Post by Max_Adamo
Allo stesso modo non fa una grinza quel che fa notare Michela nell'altro
post: controllore e controllato non possono essere la stessa persona.
Sarebbe al di fuori di ogni logica.

ma questo è un problema che nelle grandi aziende si risolve con la
cosiddetta "segregazione dei ruoli".

Post by Max_Adamo
IMHO ci sono tanti punti oscuri... e anche come è stato fatto da noi,
secondo me presentava tante lacune. Ma credimi la discussione sarebbe
talmente lunga che nemmeno ci inizio :)

Bisognerebbe cominciare dalla fine e cioe` da qual e` l'obiettivo che
voleva raggiungere il legislatore.

gli obiettivi potrebbero anche essere pochi, ma, in piccole realtà, dove
la segregazione dei ruoli è inapplicabile, questi obiettivi sono quasi
irragiungibili. Quindi o farai finta di raggiungerli, o ti metti a fare
l'impossibile.

Abbiamo detto che il dato deve essere NON modificabile.
Abbiamo detto che chi amministra i sistemi non devo poter modificare
quel dato (viceversa chi amministra quel dato non deve amministrare gli
altri sistemi).
Abbiamo detto che in certi casi (come chiede l'OP) deve essere garantita
la fonte di provenienza.
Che deve essere garantita una "min retention" e probabilmente una "max
retention".
blablabla
Di fatto, gli unici semplice da applicare sono la provenienza (tramite
certificato SSL o chiave GPG) e la retention.

perché pensate che si può essere sempre freschi, e che tutto si può fare
sempre per scherzo?

Se la norma dice che il dato non deve essere modificabile, allora non
deve essere modificabile. E questo non è uno scherzo.
Nella piccola realtà li butterai su blue ray, o su DVD. Ma nella grossa
realtà devi trovare un altro sistema.

Poi, se ci dobbiamo mettere a parlare su Usenet di come poter risolvere
tutti questi problemi, se permetti, faccio un libro e lo pubblico, che
almeno ci faccio i soldi.

--
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo

Michele "L'emarginato"

2010-02-05 20:39:42 UTC

Post by xfilesit
Utilizzo Splunk per la racolta dei log centralizzata è funziona benino
ora ho il problema di calcolare l'hash e firmare digitalmente questi
log per la conformità al garante.

Faccio notare solamente che TU, che sei l'admin saresti in conflitto
d'interessi con te stesso quando vesti il ruolo di colui che raccoglie i
dati.
Poi ognuno può farsi i film che vuole su tale normativa, ma tanto alla
fine sono le solite cose all'italiana....

Max_Adamo

2010-02-06 02:17:23 UTC