Newsgroup: it.comp.os.linux.sys
Titolo: syslog-ng chiama syslogd ..

Ciao a tutti,
ho installato un server con syslog-ng il quale dovrà recuperare tutti i
log dagli altri server linux.
Ho letto la documentazione e la cosa che mi rende perplesso è che su
ogni server che dovrò monitorare deve esserci attiva la porta di syslogd
(514/UDP) tramite il comando syslogd -r, questo per poter recuperare i
logs da remoto...
che voi sappiate non è possibile configurare syslogd in modo che possa
restringere l'accesso solamente ad un IP (quello del server syslog-ng)??
Purtroppo per policy aziendali non posso usare iptables ..
grazie mille!
bye
andrea

 logs da remoto...
Duh?

 Purtroppo per policy aziendali non posso usare iptables ..
Bella policy :-/
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 Bella policy :-/
è anche da capire, su un server di produzione non ha senso tenere un
firewall locale quando hai una DMZ..
grazie.

 firewall locale quando hai una DMZ..
Chi l'ha detto?
Tra l'altro è ormai così trendy parlare di endpoint protection e di
eliminazione delle DMZ...

whiplash ha scritto:

sarà.. ma dover replicare la stessa (o simile) config. firewall su tutti
i server, non mi sembra molto comodo e nemmeno sicuro (le possibilità di
errori aumentano)

 e nemmeno sicuro (le possibilità di errori aumentano)
Gli errori non vanno fatti né in un caso né in un altro. Ma in caso di
penetrazione su un singolo server, magari per la classica applicazione php
bacata, rendi arduo il compito dell'attaccante di spostarsi di server in
server per fare altri danni, e questo anche se hai commesso un singolo
errore, dato che questo inficerà solo la sicurezza di quel singolo server.


 firewall locale quando hai una DMZ..
Bella policy! :-(


 99% dei casi sono risorse sprecate
Allora farò prima dei test, per capire quante risorse sono utilizzate
per crittografare la comunicazione.
In effetti non è proprio necessario, visto che le comunicazioni
rimangono all'interno della LAN. Anche se un utente volesse divertirsi
con uno sniffer, non gli sarà proprio semplice ingannare gli switch.
grazie

 con uno sniffer, non gli sarà proprio semplice ingannare gli switch.
ettercap.


 con uno sniffer, non gli sarà proprio semplice ingannare gli switch.
O hai una serie di configurazioni di port security che *raramente* ho
visto in giro o non puoi fare troppo affidamento sul fatto che una rete
switchata è a prova di sniffing.

whiplash ha scritto:

non ho assolutamente detto che sia a prova di switch, ma che ad un
UTENTE "non gli sarà proprio semplice ingannare gli switch".
Mi era capitato in passato che uno user usasse uno sniffer per
"debugging" del suo programma, o magari per curiosità..

 firewall locale quando hai una DMZ..
L'autore di questa bella pensata dovrebbe imparare il concetto di difesa in
profondita'.
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname

 
ok, quello che voglio dire è che bisogna definire un grado di sicurezza
a seconda delle situazioni. Per esempio e' assurdo implementare un
hardening "restrittivo" su una macchina M$ che magari non fa altro che
  print server in una subnet interna aziendale, bensì applicherò le
"best practices" che mi consentono un buon grado di sicurezza sul server.
Bisogna tener conto del tipo di dati con cui abbiamo a che fare, il
grado di esposizione del server, etc..
i server su cui sto lavorando con syslog sono ambienti di Test e di
sviluppo quindi, IMHO giustamente, è più che sufficiente una DMZ ed un
buon hardening sull'OS.
Come giustamente ha detto Zipman, bisogna valutare l'impatto sulle
risorse ed aggiungo io sia in termini di risorse utilizzate sui server
sia per il costo di gestione (TCO)
ora cercherò di valutare se sarà necessario usare stunnel per syslogd..

 firewall locale quando hai una DMZ..
E perche' loggare via stunnel, allora, visto che avete una dmz?
A parte gli scherzi, valuta se vale la pena di cifrare. E se si',
valuta se potrebbe valere la pena di utilizzare openvpn, al posto
di stunnel, che ti eviterebbe di dover passare subito a syslog-ng
su tutte le macchine coinvolte invece che sul solo server di log.
Fabio

 sarai costretto ad usare udp.
ma infatti syslogd usa UDP (514) per inviare i log.

 ma infatti syslogd usa UDP (514) per inviare i log.
Quindi NON potrai usare stunnel perché syslogd non supporta TCP e stunnel
non supporta UDP.
http://www.onsight.com/faq/stunnel/stunnel-faq-7.html


 
ok, allora userò syslog-ng in chiaro, al limite come consigliato da bio
racchiudo tutto con openvpn.
grazie