RE: NAC

** VENDOR REPLY **


http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns75/netqa09186a00801d82
2e.html

>>>1. Che la compatibilita' come al solito e' un'opinione.
>> Mi sfugge qualcosa.. Compatibilita' di cosa e con cosa ? 
> Beh mi sembra ovvio, con qualsiasi sistema non Microsoft
> viste le premesse.

L'URL qui sopra, recita (fine della prima risposta) :
" NAC will initially support endpoints running Microsoft® Windows NT, XP and
2000 operating systems."
Mi sembra un normale approccio al mercato, quello di iniziare con microsoft
che statisticamente e' il sistema 1) piu diffuso, 2) piu vulnerabile. Il
fatto stesso che sia specificato "initially" significa 1) che la massima
priorita' e' stata messa sull'ambiente piu diffuso e vulnerabile, a cui
seguiranno, evidentemente, altri sistemi operativi secondo priorita' di
questo tipo.


>> Se il problema é il deployment del 'demone' (si chiama CTA, 'Cisco Trust
>> Agent'), questo sara' incluso nelle prossime versioni di antivirus dei
tre
>> vendor sopracitati, quindi il problema del delpoyment e' minore di quello
>> che sembra.

> Beh ma mi spieghi che livello di sicurezza può mai dare un aggeggio del
> genere?

Certo, spiego. Il sistema di autenticazione e' basato su Extensible
Authentication Protocol (EAP) [1], che e' un generico framework di
autenticazione che puo essere usato per fare enforcement di controllo
dell'accesso in base a diversi tipi di credenziali, la cui flessibilita' lo
rende utile in svariati ambiti. In questo momento EAP e' utilizzato  anche
in 802.1x, IKE versione 2 e PPP per lo scambio di credenziali di identitá
fra un supplicant ed un gateway. Inoltre il RADIUS e' stato esteso (no, non
da cisco, vedi [2]) per portare messaggi EAP inmodo che il gateway di
autenticazione possa appoggiarsi ad un server AAA RADIUS per la valutazione
delle credenziali ed il mapping su una policy.

Questo fa un 'demone' integro fa. Se poi il demone non e' integro, ricadiamo
in problemi ben piu grossi. 
Se riesco a manomettere il 'demone' posso anche installare un keylogger
della macchina ed aggirare qualsivoglia altro sistema di autenticazione.

> Ma se il client non lo gestisci tu a che serve il NAC?

A fare in modo che sulla mia rete si abbia accesso solo se si e' confugurati
come ho stabilito io, esattamente come posso volere che a casa mia non si
fumi il sigaro, indipendentemente dal fatto che il fumatore sostenga che il
sua Avana ha un profumo meraviglioso. Il balcone (o la guest VLAN) resta
disponibile.

> Secondo me il punto debole di tutto il discorso sta proprio qui: ci
> fidiamo di quello che ci racconta il client perchè ci mettiamo un
> aggeggio proprietario sopra che ci racconta cosa fa. Personalmente ho
> abbandonato qualsiasi fiducia nel security through obscurity da molto
> tempo.

Cosa c'entra la security thru obscurity? 
Se vogliamo discutere di tecnicismi della soluzione sono apertissimo, se
vogliamo dare addosso a tutto quello che non e' open source, ed innescare
ancora una volta la diatriba su open/closed source, disclosure, eccetera, é
un altro discorso, dal quale mi sottraggo.

> Secondo me un aggeggio del genere è un bell'esempio di potenza di
> marketing, 

Certo, c'e' del marketing. Tutti I vendor fanno del marketing. 
Oltre al marketing c'e' anche una soluzione che (mi dicono persone che non
ho nemmeno interpellato) e' interessante ed indirizza una necessita' delle
aziende.


> rischia di ingenerare un firte quanto falso senso di sicurezza
> oltre a dei bei malditesta a tutti quelli che hanno macchine non
> compliant.

Ripeto, e me, amministratore di rete che stabilisce che sulla mia rete si
entra solo se configurati cosí-e-cosá,non frega niente dei mal di testa di
chi non ha la macchina compliant, proprio perche questa tecnologia da la
possibilita' di lasciar fuori dalla rete le macchine non compliant.

> E qui non si parla dei soliti sfigati che usano linux, ma di
> tutta una serie di apparati, dalle stampanti di rete in su, che di
> sicuro non usano ne windows ne tanto meno un antivirus.

Calma, calma... :-)
Non e' una situazione ON/OFF... C'e' parecchia granularita' in termini di
scelta delle zone dove e' applicata questa soluzione. Ci manca l'antivirus
sulle stampanti... ;-)

> (Se mi dici che puoi escludere la stampante di rete dal controllo ti
> rispondo che è altrettanto facile prendere il posto della stampante e
> fregarsene allegramente del NAC, 

No, non puoi escludere la stampante, puoi stabilire le zone di accesso alla
rete che sottostanno a questa regola. 
Alla stampante, in quanto non rispondente (in quanto non ha ildemone
addosso) non verrebbe dato l'accesso alla rete, se collegata in una zona
d'accesso con NAC.

> effettivamente a niente, se non a far spendere un po' di soldi in più a
> qualcuno).

Questo é un punto importante. Il vendor/io con l'aplicazione di NAC non
vende piú hardware. Voglio dire il tutto e' implementabile su
apparecchiature di rete esistenti da aggiornare con le eventuali versioni
del software adeguate, tutto qui. 

> Chi mi dice che dall'altra parte non ci sia
> qualcuno che mi sfrutta il NAC per conoscere al meglio il mio stato e
> quale sw mi gira per portare un attacco mirato?

La mutua autenticazione con EAP ed il fatto che il -chiamiamolo NAC_daemon -
manda informazioni relative al tuo anvivirus, personal firewall e
patchlevel.

>> Vedila come una sofisticata autenticazione 802.1x
> No guarda, posso anche condividere altre cose, ma io nelle
> autenticazioni 802.1x non ho bisogno di dirti cosa c'è sulle mie
> macchine o far girare software che non posso controlloare direttamente,
> mi sa che siamo ben lontani.

Guarda che mica e' obbligatorio usare NAC se non ne senti l'esigenza, eh...
:-))


---[REFERENZE]----------
[1] L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, H. Levkowetz, Ed. 
Extensible Authentication Protocol (EAP), 
draft-ietf-eap-rfc2284bis-03.txt

[2] C.Rigney et al, Radius Extensions, RFC2869
-------------------------


Ciao,
Marco


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List