Newsgroup: it.comp.os.linux.iniziare
Titolo: Centos 5.5 quali servizi sono "insicuri"?

considerando una macchina centos 5.5 32bit con SELinux attivato firewall 
attivo, con i servizi nfs e samba in esecuzione, firewall attivo
(macchina aggiornata, solo repo ufficiali, non è possibile accedere 
fisicamente alla macchina)
1. a quali attacchi-pericoli puo' essere sottoposta la macchina dall'interno 
della lan? c'è modo di "inchiodarla tramite qualche tipo di attacco?
2. e dall'esterno (internet) se la macchina sta direttamente su una DMZ ?
vorrei provare a capire d+ sulla sicurezza dei sistemi Centos, non devo 
sabotare nessuna macchina, che tra l'altro sono le mie e uso per studiare 
Centos

 studiare Centos
cerca i bug di RHEL5, Centos è per il 99.9999% RHEL
S.

Il 20/06/10 23:01, Mario l'amico del gatto ha scritto:

Interno/esterno non fa differenza in questo caso, il firewall di centos 
di default opera come un "personal firewall" aprendo esclusivametne le 
porte ceh gli indichi indipendentemente dalla provenienza (ammenoché non 
hai ravanato manualmente tra schede di rete e iptables..)
Gli attacchi possibili sono quelli classici, si attende pazientemente 
che venga segnalato un bug in qualche servizio e pubblicato un exploit, 
poi si prova..
Ci sono però 3 piccolissimi problemi, il primo è che generalmente il 
team Security Response di Red Hat (che sta li proprio per questo) patcha 
il pacchetto e lo inserisce nei propri repository in un tempo variabile 
dai 20 minuti a 2 ore (dalla segnalazione del bug, parliamo ovviamente 
dei demoni classici Apache, samba, nfs, mysqlecc.. e del kernel non 
delle gigiate Desktop..) e mediamente 24 ore dopo sono disponibili anche 
per centos.
Il secondo problema è che generalmente dalla segnalazione del bug 
all'uscita dell'exploit passano alcuni giorni, a volte anche mesi.
Il ché combinato con il primo problema rende evidente che se si mantiene 
aggiornato il proprio server ci sono poche probabilità di avere il tempo 
materiale di sfruttare un bug (per l'attaccante ovviamente)
Terzo ed ultimo problema, ipotizzando che venga pubblicato un bug e 
simultaneamente l'exploit (capita mooolto ma moolto raramente) c'è il 
cagnaccio da guardia SELinux che impedisce al demone di eseguire 
operazioni "fuori dall'ordinario" vanificando de facto molti exploit.
In pratica le policy di SELinux indicano cosa un applicazione può fare e 
negano qualsiasi altra operazione non strettamente indispensabile
Per avere un idea di cosa viene "bloccato" rispetto ad un sistema 
standard basta digitare
getsebool -a
come vedi la lista è infinita..
si può affinare in base al demone di nostro interesse
getsebool -a |grep samba
samba_domain_controller --> off
samba_enable_home_dirs --> off
samba_export_all_ro --> off
samba_export_all_rw --> off
samba_share_fusefs --> off
samba_share_nfs --> off
use_samba_home_dirs --> off
virt_use_samba --> off
ed eventualmente abilitare una o più funzioni se necessarie con
setsebool -P samba_enable_home_dirs on
poi ovviamente c'è il controllo sulle areee di scrittura all'interno del 
filesystem ls -Z
E questo spiega perché è tanto odiato da tutti..
Quindi per tornare alla domanda.. quali sono i servizi insicuri?
quelli non di default e non protetti da policy di SELinux, ovvero se 
decidi di installare un demone *esotico* oltre a non disporre 
automaticamente degli aggiornamenti non disporrai nemmeno del supporto 
di SELinux il ché rende abbastanza probabile che prima o poi si creerà 
l'occasione per entrare.
Ricorda comunque che niente ti mette al riparo dalla segretaria stordita 
che scrive le password sul postit incollandolo al monitor!

 all'uscita dell'exploit passano alcuni giorni, a volte anche mesi.
-cut- 
grazie delle info!
complimenti per la preparazione!

 Interno/esterno non fa differenza in questo caso... [cut]
E' sempre bello avere dei post cosě.. Chapeau !! 
Davide.
p.s. Stampato e appiccicato sulla parete sopra al server :-)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it