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


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


Archivio: Marzo 2002 ml@sikurezza.org
Soggetto: PenTestL2
Mittente: gino latino
Data: 31 Mar 2002 00:24:27 -0000
Diversi cicli orsono lanciai il thread, se le vlan fossero una soluzione 
sicura, dato che l'argomento scalda ancora gli animi vorrei aggiungere, se 
posso, ancora un pò di carbone alla mia domanda alquanto generica.
Partendo dal presupposto che le Vlan sono un compromesso alquanto insicuro, 
per i motivi noti, è anche vero però che sono sempre più necessarie a tutte 
quelle strutture che vogliono offrire servizi High Density in HA contenendo 
i costi e razionalizzando al massimo per una più facile fruibilità del 
servizio al cliente finale.

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.

Allora per quanto mi riguarda io razionalizzerei i test sulla base dei 
seguenti punti:

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;
2.	Information Ghatering - Verificare l’inaccessibilità delle info per il 
discovery dell’apparato
3.	Verificare la possibilità di sniffing e tentativi di DOS
4.	Exploit - Verifiche atte a controllare che lo switch non sia vulnerabile 
a qualche bug noto

Io alcune risposte già me le sono date, ma sono sicuro che Voi ne avete 
tantissime altre, e sono le seguenti:

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:

-	Primo livello D’accesso, dove di solito vengono posizionati i border 
router per la connettività internet;
-	SF
-	Secondo livello, dove vengono posizionati tutti quegli host che 
interagiscono con Internet, tipo: web,mail, ect…
-	SF
-	Terzo livello, dove vengono posizionati gli host che svolgono mansioni di 
tipo application, tipo: DB, ect…
-	SF
-	Quarto livello, dove vengono posizionati gli accessi per i collegamenti 
d’amministrazione, tipo: dialup, cdn, ect..

Sulla base di questo possibile modo di separare i servizi, bisogna aver cura 
che anche il L2 abbia la stessa discriminazione per evitare qualsiasi 
convivenza abusiva spiacevole, perciò:
1.1.1	Verificare che su gli apparati(HA)  non convivano livelli diversi, ma 
solamente vlan con le stesse mansioni per evitare eventuali salti 
effettuabili in diversi modi.

NB: purtroppo qui viene fuori il primo limite delle VLan classiche nelle 
strutture distribuite, HD, in quanto il tagging, 802.1q, necessario per 
definire i trunk di traporto sui vari apparati L2 non è autenticato.

1.2	Un altro must che ritengo di rilevante importanza per la security in 
generale, su tutta l’infrastruttura è che ogni apparato di rete deve essere 
configurato, tramite un’altra rete con separazione fisica obbligatoria.
1.2.1	Verificare che l’accesso agli apparati di rete non avvenga tramite la 
rete di erogazioni dei clienti, ma esclusivamente tramite una rete dedicata.
1.2.2	Verificare ancora prima di comprarli che gli apparati L2 supportino la 
possibilità di loggare  e di esportare su syslog, per ovvi motivi di 
monitoraggio.

2.1	Questo è un argomento molto interessante per limitare di molto i 
successivi, in quanto limitare l’accesso alle informazioni dell’apparato è 
importantissimo per sventare sul nascere molte attività maliziose. Se la 
struttura rispetta il PT 1.2.1, già siamo a cavallo, ma senza sella, perché 
anche se le configurazioni sono effettuate su una rete separata e 
firewollata, molte delle verifiche di funzionalità si devono fare 
attraversando la rete di erogazione, per ovvi motivi di sensibilità e 
misurazioni di SLA.
Dunque, bisogna concentrarsi sui seguenti punti:
2.1.1	Verificare che sia configurato solamente il servizio SNMP V2 con ACL 
verso la sola rete di management autorizzata e con comunity non Standard, 
tipo public;
2.1.2	Sempre facendo riferimento al rispetto del PT 1.2.1, è importante che 
gli apparati L2 e superiori non permettano alcun interfacciamento diretto o 
tutto quello che non sia inerente al loro compito principale con gli host 
messi sulla rete di erogazione, tramite il controllo che tutte le porte 
siano chiuse, tutte!! non esclusivamente: telnet, ftp, tftp, snmp, icmp.
2.1.3	Verificare che le vlan dello stesso livello funzionale, ma di clienti 
diversi, siano separate da ACL e che pertanto non comunichino in alcun modo 
tra loro, questo è importante per svariati motivi, ma in questo contesto di 
test è essenziale per non scoprire il tag relativo all’altra vlan 
d’appartenenza, tramite un semplice ping.

3.1	Quest’argomento è sicuramente uno dei più noti poiché lo sniffing 
attivo, tramite poisoning è un altro limite di molti apparati L2 e pertanto 
dobbiamo prevedere come must, che i mac dei gateway siano inseriti sullo 
switch in modo statico e anche gli host abbiamo un entry statica sulle porte 
degli switchs o un range definito nel caso dei sistemi in HA;
3.1.1	Verificare la possibilità di eseguire il poisoning delle arp dello 
switch.

Qui chi più ne ha più ne metta.

5.1	Questo punto è molto chiaro e pertanto è certo che se l’apparato ha dei 
bug noti che aprono delle problematiche è il caso di fixarli, perciò:
5.1.1	Verificare tramite ricerche sui vari bugtraq, che le versioni degli 
apparati non siano affette da bug.

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.

PS: A tutte le persone che si domandassero questo dove lo trova il tempo, o 
non ha niente di meglio da fare che scrivere ste s***nzate.....Rispondo 
molto chiaramente che stando male a letto con l'influenza era l'unica cosa 
che potessi fare....e pure la Pasqua me la sono bruciata...Sarà la sindrome 
da CED???
PS2: Insultatemi pure per l'italiano....lo so fa un pò pena
PS3: Invece per il resto oltre agli insulti inserite anche l'eventuali 
correzione o eventuali migliorie.

>>THNK<<
Un thnk a Naif per i gli ottimi puntatori, come risposta esaustiva alla mia 
question.
http://rr.sans.org/switchednet/switch_security.php
http://www.sans.org/newlook/resources/IDFAQ/vlan.htm
Un thnk a AndreaT per il PVLAN.
http://www.cisco.com/warp/public/473/90.shtml

Ciaos
CaT








_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


________________________________________________________
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