[ Home | Liste | F.A.Q. | Risorse | Cerca... ]


[ Data: precedente | successivo | indice ] [ Argomento: precedente | successivo | indice ]


Archivio: Aprile 2002 ml@sikurezza.org
Soggetto: Re: PenTestL2
Mittente: Marco Ivaldi
Data: 1 Apr 2002 11:40:54 -0000
On Sat, 30 Mar 2002, gino latino wrote:

> Sulla base di questa premessa tecnico-economica, su cui molti ci hanno già
> sbattuto la testa, vorrei chiedervi di aiutarmi a selezionare un certo
> numero di Pen-Test atti a limitare e a circoscrivere al massimo i bug di uno
> strato insicuro, dove ancora molti vendor sono deficitari e non pensano ad
> altro che alle performance, distogliendo l'attenzione ad un argomento a cui
> non sanno ancora dare risposte, eccetto il solito noto.

Io suggerisco innanzitutto di separare le 2 cose:

1) Test sullo switch (chiamiamolo Hardware Security Probe)
2) Penetration Test sulla rete in produzione

Per prima cosa occorre valutare il prodotto switch (possibilmente anche
confrontandolo con altri simili per capire quale si comporta meglio in
certi casi), alla ricerca di vulnerabilita' tipiche. Occorre definire un
piano di test da applicare al device, facendo particolare attenzione
agli attacchi a datalink layer e, per gli switch ultima generazione, anche
a quelli a layers superiori (dal 3 in su).

In seconda analisi, si puo' passare al Penetration Test vero e proprio,
eseguito sulla rete in produzione con lo switch prescelto montato e
configurato. A questo punto riprendiamo le fasi da te esposte.

> 1.	Verifiche architetturali - Pre-Pen-Test o Riskanalisys, in quanto gli
> errori di progettazione, converrete con me, sono sempre quelli che dopo
> rendono la vita difficile;

D'accordissimo, si tratta di un passo fondamentale per procedere in modo
rigoroso.

> 2.	Information Ghatering - Verificare l’inaccessibilità delle info per il
> discovery dell’apparato

Qui posso anche essere d'accordo, ma in finale non e' che sia obbligatorio
fare information hiding per fare sicurezza, IMHO. Diciamo che in questa
fase verificherei che non vi sia un Information Leakage, non previsto
dalla security policy (elaborata al punto 1).

> 3.	Verificare la possibilità di sniffing e tentativi di DOS

Questo probabilmente rientra nella prima fase da me individuata (non hai
bisogno che lo switch sia operativo nella rete in produzione per
verificare questo tipo di vulnerabilita' specifiche).

> 4.	Exploit - Verifiche atte a controllare che lo switch non sia vulnerabile
> a qualche bug noto

O non sia mal configurato. L'assenza di bug non determina necessariamente
una condizione di sicurezza.

> 1.1	L’architettura deve tener conto, come must, della separazioni fisica su
> diversi L2 dei diversi livelli logico applicativo dei vari servizi che sono
> separati da firewall, mi spiego meglio…..
> Nelle grandi strutture HD si tende a discriminare la posizione di un host in
> base al servizio che eroga e a come deve interfacciarsi con gli altri.
> Queste macro distinzioni sono rese tali tramite l’introduzione di Separation
> Firewall; box con il compito di dividere la struttura L3 in diversi livelli,
> tipo:

[...]

Mi piace molto come hai organizzato il discorso: le tue riflessioni possono
costituire un valido punto di partenza per impostare correttamente la
sicurezza sin dal layer 2. Attenzione pero' che concentrandosi troppo
sugli schemi di sicurezza a basso livello si rischia di trascurare quelli
ad un livello piu' alto, con conseguente rischio di buchi ad application
layer. In altre parole: tu configuri tutta la rete come hai descritto e la
verifichi come Dio comanda, poi pero' hai un RAS su verde su cui si entra
con cisco/cisco. L'anello debole e' l'uomo, temo, piu' che il Datalink:)

> Concludendo, spero che adesso la domanda sia più qualificata e che la
> richiesta di definire ulteriori check di verifica sul layer 2 venga accolta
> positivamente.

Ce ne sarebbero molti da definire... Quando trovero' un po' di tempo da
dedicarci magari ne riparliamo: tieni cmq presente che qualcuno questo
lavoro l'ha gia' fatto, magari non benissimo o non specifico per quello
che ti serve, ma e' sempre un buon punto di partenza. Sul sito del NIST,
ad esempio, c'e' qualche documento del genere che potrebbe tornare utile,
se non ricordo male.

Ciao e Auguri,

:raptor
Antifork Research, Inc.				@ Mediaservice.net
http://www.0xdeadbeef.eu.org			http://www.mediaservice.net





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




[ Home | Liste | F.A.Q. | Risorse | Cerca... ]

www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005