Newsgroup: it.comp.os.linux.sys
Titolo: Syslog server

Ciao a tutti.
Che caratteristiche hanno i vostri server syslog?
Mi interessano in particolare lo spazio disco ed il processore. Ed anche 
quanti server loggano sul syslog server.
Devo implementare un server log per circa 20-30 macchine, non ho la 
minima idea di quali caratteristiche siano necessarie (un P4, uno Xeon, 
un P3.....) e di quanto spazio possano portare via i log (questo però me 
lo calcolo da per me).
Inoltre, (chiederò meglio nel gruppo appropriato), per quanti anni o 
mesi bisogna tenere i log della posta, del web, del proxy etc ?

 mesi bisogna tenere i log della posta, del web, del proxy etc ?
Occhio, se ci vuoi gestire log sensibili *non* usare syslogd che 
trasporta solo su UDP, usa syslog-ng e falli trasportare su TCP.
-- 
Luca Villani        NOC, OpenSailing.org
                     Remove "+settanta" in address for e-mail replies
http://www.opensailing.org
 , il primo Portolano collaborativo online

 trasporta solo su UDP, usa syslog-ng e falli trasportare su TCP.
Con quale vantaggi oltre alla certezza dell'arrivo del pacchetto?

 Con quale vantaggi oltre alla certezza dell'arrivo del pacchetto?
Di poter essere trasportato dentro sessioni SSL, ad esempio...
-- 
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.

 Di poter essere trasportato dentro sessioni SSL, ad esempio...
Ok, ma con quale utilità dato che non devo uscire dalla mia rete?
E se dovessero leggere il traffico generato dal server verso il syslog 
direi che i miei problemi sarebbero ben altri che garantire la cifratura 
della comunicazione.
Tra l'altro, impossibile sniffare traffico collegato direttamente al 
server via cavo di rete.
server -----> switch ----> firewall -----> syslog)
Dove si infilano per sniffare il tutto? la rete è protetta

 Con quale vantaggi oltre alla certezza dell'arrivo del pacchetto?
Basta ed avanza, se sono log sensibili e se sono le uniche copie ad 
essere tenute.


 Dove si infilano per sniffare il tutto? la rete è protetta
Basta che uno qualsiasi dei server che si affacciano alla stessa VLAN
venga compromesso, e che venga usato per fare un arp poisoning allo
switch: tutto passa in unicast-flood (come fosse un hub) e da lì in poi
basta uno sniffer....
Ciò detto, non dico che sia *necessario* approntare meccanismi di questo
genere: dipende dal tipo di dato che viene veicolato dai log; ma dato
che ci possono essere (se non ora, in futuro) dati che richiedono un
tale trattamento, meglio porsi il problema quando si progetta
l'infrastruttura che trovarsi a dover modificare tutto dopo...


 essere tenute.
Be questo è ovvio.

 l'infrastruttura che trovarsi a dover modificare tutto dopo...
Parole sacrosante, infatti farò veicolare tutto in tcp con in futuro 
potrò incapsulare via ssl. Però non mi sembra un requisito fondamentale 
almeno nella mia rete.

 dei problemi. Non trovi?
No, affatto.
Il fatto che possano bucare un server non deve e non può compromettere
la riservatezza di dati che si stanno scambiando macchine *diverse* da
quella bucata.
Quindi, se in attraverso un canale (i log come qualsiasi altra cosa)
transitano dati *riservati*, allora *devono* esserci meccanismi a
forzarne la riservatezza.
Il fatto di essere "dietro al firewall" non cambia il discorso di una
virgola, IMHO...


 Mi server per sapere quanto spazio devo prevedere.
Mi sa che stai affrontando il problema nella maniera sbagliata.
Non devi chiedere a noi queste cose, le devi valutare *tu*.
A spanne, se vai su tutti i server, fai un du -hs /var/log/ e poi sommi 
le cifre, quello è lo spazio massimo cumulativo di un mese dei tuoi log, 
bzippati.
Lo spazio necessario alla tua struttura lo puoi sapere solo *tu*, in 
base al traffico che hai *tu* e alle applicazioni che hai *tu*, non puoi 
domandare qui dome magari ti può rispondere gente che gestisce un 
cluster di webserver con tanti hits che solo le /var/log/apache2/ di 
ogni server sono da 2 GByte giornalieri l'una.
O gente che gestisce parecchi domini di posta che generano 50 GByte di 
/var/log/mail/ al giorno.
Siamo su ICOLS e si presume che tu sia un sistemista, ossia il discorso 
sullo spazio necessario non avrebbe dovuto neppure iniziare.


 virgola, IMHO...
Esatto, era solo per dire che il syslog 'non è bucabile' (ovviamente il 
tutto è relativo)

 sullo spazio necessario non avrebbe dovuto neppure iniziare.
Si stava parlando giusto a titolo informativo. Ovviamente lo spazio lo 
devo calcolare da me (come anche lo spazio necessario allo storage dei 
dati).
Era piuttosto per sapere come organizzavate il log server voi.
Quanti giorni di dati online sui server, quanti online sul syslog e 
quanti mesi/anni di archivio.

 quanti mesi/anni di archivio.
Sui server, se sono dati sensibili non vengono loggati.
Sul loghub, appena bzippati li spostiamo sulla library.
Su nastro, da qualche parte ho degli ampex del 1994.


 Di poter essere trasportato dentro sessioni SSL, ad esempio...
Penso che il motivo principale per utilizzare tcp sia quello di
evitare che qualcuno possa inserire righe di log arbitrarie nel
syslog server (in modo banale, per lo meno). 
Anche la possibilita' di cifare ha il suo peso, e' ovvio, ma si
porta dietro almeno un aspetto negativo: anche nell'ultima 2.0,
syslog-ng non puo' usare nativamente ssl. La soluzione, quindi,
e' ancora quella di forwardare tutto attraverso stunnel. Questo
vuol dire che il server syslog-ng vedra' tutto il traffico come
se provenisse da localhost [1], impedendoti di classificare una
riga di log in base all'ip sorgente, l'unico metodo affidabile.
Inoltre, usare tcp puo' essere un problema nel caso di ambienti
con syslogd misti (che non possano lavorare via tcp) mantenendo
la cifratura.
Se si vuole cifrare, valuterei seriamente openvpn, che non ha i
limiti di cui sopra.
Fabio
[1] a parte usare stunnel in "transparent mode" con le relative
    complicazioni.

 basta uno sniffer....
Se si usano client *nix o windows>=2003, si possono [1] usare arp entry
statiche per mitigare il problema.
Fabio
[1] per non dire *devono*

 limiti di cui sopra.
Io non avevo pensato minimante a stunnel.
Avevo dato per scontato una vpn. 10 righe di codice et voila.
Stunnel è più facile, ma sinceramente openvpn la reputo una soluzione 
migliore.


Il che impedisce di fare arp-poisoning e proxare il traffico a L2, ma
non impedisce di emettere arp arbitrari fino a saturare la
mac-address-table dello/degli switch, col risultato di farlo/i lavorare
in unicast-flood (come HUB) e quindi poter vedere sulla NIC anche il
traffico diretto ad altri mac-address...
Questo si può mitigare/risolvere configurando adeguatamente lo switch
affinchè metta in shutdown la porta se vi appaiono più di TOT mac-address:
switchport port-security maximum <TOT>
switchport port-security violation shutdown
Oppure direttamente settandovi il MAC address che ci si attende collegato:
switchport port-security mac-address XX:XX:XX:XX:XX:XX
(tanto se inserisci le entry ARP statiche, hai già i dati che ti servono...)
Ovviamente, la complessità di gestione cresce di conseguenza...
Un altro modo di ottenere la stessa cosa (l'unicast-flood intendo), che
mi viene in mente, sarebbe emettere un flusso costante di BPDU topology
change, che dovrebbe funzionare altrettanto "bene", a patto che
- gli switch usino STP (comune, comunque)
- le porte degli switch dove son connessi i server non presentino
direttive bpdufilter/bpduguard (o equivalente non-cisco)
Non ho idea se ci siano in giro kit di attacco che exploitino in questo
modo, però: non ne ho mai sentito parlare, quantomeno...


 direttive bpdufilter/bpduguard (o equivalente non-cisco)
Normalmente le porte connesse a macchine sono switchport mode access, il
che (AFAIR) dovrebbe prevenire tale possibilità.
-- 
Flavio Visentin
Membro del CICAP
Comitato Italiano per il Controllo delle Affermazioni di P4

 che (AFAIR) dovrebbe prevenire tale possibilità.
Solo se specifichi esplicitamente una delle due direttive di cui sopra,
altrimenti no.
Nulla impedisce di avere uno switch facente parte dello spanning-tree
collegato ad una porta access: significa solamente che porta solo una
vlan, nulla più...


 change, che dovrebbe funzionare altrettanto "bene", a patto che
Ho giusto un paio di procurve inutilizzati. Nei prossimi giorni magari
ci provo.
Fabio

 migliore.
Bah, non direi che sia piu' facile. Solo diverso.
Fabio

 modo, però: non ne ho mai sentito parlare, quantomeno...
Partiro' da questo: 
http://www.securiteam.com/tools/6K00O0ABFC.html
Fabio


Interessante, gli darò un occhio quando ho tempo (il che significa
praticamente mai... :-\ )




Mai rpovato nello specifico, ma anche ettercap-ng consente attacchi a STP.
-- 
Words are very unnecessary
They can only do harm