|
Wiki
UniCrema
Materie per semestre
Materie per anno
Materie per laurea
Help
|
|
Uni.SNR-PS-Gennaio2008 History
Hide minor edits - Show changes to output
Changed lines 56-62 from:
Per quanto riguarda le variabili, esse sono già state scritte nello schema, quindi non sto ad inventarne di nuove. to:
Per quanto riguarda le variabili, esse sono già state scritte nello schema, quindi non sto ad inventarne di nuove. Per inventarmi la definizione, io direi:
* DMZ:=192.168.10.0/24
* MirrorDMZ:=192.168.20.0/24
* ServiceNW:=192.168.1.0/24
* ManagementNW:=192.168.100.0/24
* Partner:=10.1.0.0/16 (immagino che sia su un'altra rete locale, ma con tanti indirizzi, per questo uso la classe 10.1.0.0/16)
* Per i singoli nodi, va beh sbizzarritevi:)
Added lines 174-178:
Occorrono anche le tabelle per le coppie ETH0-ETH1 e ETH0-ETH2. In accordo alla politica 6, dovremmo proibire qualsiasi connessione da e verso l'esterno su queste interfacce, perché non è scritto da nessuna parte che qualche parte della rete aziendale possa uscire su Internet.
!!!Firewall 2, 3 e 4
Le cose sono simili al FW 1, non mi pare ci sia niente di strano qui.
Changed line 124 from:
(:cellnr cellpadding=9:) ''Le regole da 5 a 8 sono repliche delle regole precedenti, per permettere la connessione da porta alta del client a porta 20 del server, per lo scambio di dati'' to:
(:cellnr colspan=9:) ''Le regole da 5 a 8 sono repliche delle regole precedenti, per permettere la connessione da porta alta del client a porta 20 del server, per lo scambio di dati''
Changed line 124 from:
(:cellnr:) ''Le regole da 5 a 8 sono repliche delle regole precedenti, per permettere la connessione da porta alta del client a porta 20 del server, per lo scambio di dati'' to:
(:cellnr cellpadding=9:) ''Le regole da 5 a 8 sono repliche delle regole precedenti, per permettere la connessione da porta alta del client a porta 20 del server, per lo scambio di dati''
Changed line 73 from:
to:
Added lines 75-85:
(:cell:) Any
(:cell:) Any
(:cell:) Any
(:cell:) Any
(:cell:) Blacklist
(:cell:) Any
(:cell:) DENY
(:cellnr:) 1
(:cell:) OUT Added lines 126-165:
(:cellnr:) 9
(:cell:) OUT
(:cell:) UDP
(:cell:) Host1
(:cell:) 2222
(:cell:) Host2
(:cell:) 2222
(:cell:) **
(:cell:) PERMIT
(:cellnr:) 10
(:cell:) OUT
(:cell:) TCP
(:cell:) Host1
(:cell:) > 1023
(:cell:) DB3
(:cell:) 22
(:cell:) 1/0
(:cell:) PERMIT
(:cellnr:) 11
(:cell:) IN
(:cell:) TCP
(:cell:) DB3
(:cell:) 22
(:cell:) Host1
(:cell:) > 1023
(:cell:) 1
(:cell:) PERMIT
(:cellnr:) 12
(:cell:) Any
(:cell:) Any
(:cell:) Any
(:cell:) Any
(:cell:) Any
(:cell:) Any
(:cell:) Any
(:cell:) DENY Added lines 167-174:
Ecco la spiegazione:
* la regola 0 serve per implementare la politica 5, che dice di impedire la connessione DA DMZ al resto della rete aziendale sulle porte specificate da ''Blacklist''. Siccome questa lista può essere aggiornata e includere eventualmente anche porte precedentemente aperte, deve essere messa prima di tutte le altre.
* Le regole da 1 a 8 implementano FTP passivo per il mirror sulla ''Mirror DMZ'''
* La regola 9 implementa la politica 2, quella dell'Heartbeat. Assumo che non ci siano risposte da parte di Host2...
* Le regole 10 e 11 implementano la politica 4, cioè la connessione via SSH a DB3
* Le ultime due regole sono il DEFAULT DENY
Changed line 176 from:
[[Torna alla pagina di SnR -> SicurezzaNelleReti]] to:
[[Torna alla pagina di SnR -> SicurezzaNelleReti]]
Added lines 112-113:
(:cellnr:) ''Le regole da 5 a 8 sono repliche delle regole precedenti, per permettere la connessione da porta alta del client a porta 20 del server, per lo scambio di dati''
Added lines 56-113:
Per quanto riguarda le variabili, esse sono già state scritte nello schema, quindi non sto ad inventarne di nuove.
!!!Firewall 1
IN: eth2\\
OUT: eth1
(:table border=0 cellpadding=5 cellspacing=0 align=center:)
(:cellnr:) '''Num regola'''
(:cell:)'''Dir'''
(:cell:)'''Prot'''
(:cell:)'''IP sorg'''
(:cell:)'''PORT sorg'''
(:cell:)'''IP dest'''
(:cell:)'''PORT dest'''
(:cell:)'''Flag ACK'''
(:cell:)'''Azione'''
(:cellnr:) 1
(:cell:) OUT
(:cell:) TCP
(:cell:) Host1
(:cell:) > 1023
(:cell:) Host2
(:cell:) 21
(:cell:) 1/0
(:cell:) PERMIT
(:cellnr:) 2
(:cell:) IN
(:cell:) TCP
(:cell:) Host2
(:cell:) 21
(:cell:) Host1
(:cell:) > 1023
(:cell:) 1
(:cell:) PERMIT
(:cellnr:) 3
(:cell:) OUT
(:cell:) TCP
(:cell:) DB1
(:cell:) > 1023
(:cell:) DB2
(:cell:) 21
(:cell:) 1/0
(:cell:) PERMIT
(:cellnr:) 4
(:cell:) IN
(:cell:) TCP
(:cell:) DB2
(:cell:) 21
(:cell:) DB1
(:cell:) > 1023
(:cell:) 1
(:cell:) PERMIT
(:tableend:) \\
Added lines 34-54:
!!Esercizio 2
Si consideri la rete aziendale mostrata nello schema allegato. Compaiono 4 firewall:
* FW1: eth0, eth1, eth2
* FW2: eth0, eth1, eth2
* FW3: eth0, eth1
* FW4: eth0, eth1
Si assuma che tali fw siano di tipo Static Packet Filter.
Si definiscano:
* tutte le variabili, con nomi significativi, necessarie e sufficienti a configurare sorgenti e destinatari delle regole dei fw (nelle politiche non dovranno essere usati indirizzi IP ma solo variabili). Assegnare a tali variabili valori realistici (VARIABILE:=INDIRIZZO IP o INDIRIZZO SUBNET) facendo particolare attenzione alla definizione delle sottoreti.
* le politiche di sicurezza, necessarie e sufficienti, dei firewall, per gestire i seguenti servizi/connessioni:
# la sottorete ''Mirror DMZ'' è un mirror della DMZ. Tutti i contenuti presenti sui sistemi della DMZ devono essere replicati via FTP PASSIVO (20-21 tcp) sui corrispondenti sistemi della Mirror DMZ.
# L'Host1 genera un heartbeat verso l'Host2 via UDP (2222/udp)
# La sottorete Partner riceve segnalazioni dal Virtualization Server via SMTP (25/TCP)
# Host1 e Host2 accedono a DB3 via SSH (22/tcp)
# Si vogliono impedire eventuali diffusioni di malware dalla sottorete DMZ e Mirror DMZ verso il resto della rete aziendale. A tal fine viene utilizzata una variabile ''blacklist'' che include un numero (non predeterminato) di porte applicative destinatarie TCP e UDP che si vogliono inibire
# Ogni altra comunicazione tra le reti non esplicitamente prevista dai punti precedenti deve essere impedita (scrivere regole)
Attach:SNR-ReteGennaio2008.jpg
Added lines 1-36:
(:title Sicurezza nelle Reti - Prova scritta - Gennaio 2008:)
%titolo%''':: Sicurezza nelle Reti - Prova scritta - Gennaio 2008 ::'''
!!Esercizio 1
''Spiegare in sintesi ma con precisione in cosa consiste la tecnica di ARP Poisoning''.
Innanzitutto, qualche richiamo sull'ARP. ARP è un protocollo che si usa su un segmento di rete locale, e serve per richiedere quale sia il MAC di una scheda di rete associata ad un certo IP. I dati che pervengono in seguito a queste risposte vengono mantenuti in una cache detta '''ARP Table'''.
L'ARP Poisoning consiste nell'alterazione maliziosa di queste tabelle di ARP. L'idea è che, in seguito ad una richiesta da parte di un host di sapere il MAC di un certo IP, la risposta non venga inviata dal legittimo proprietario dell'IP, ma da un host malizioso. In questo modo la tabella ARP del cliente viene "avvelenata", ed i pacchetti verranno inviati tranquillamente a questo host cattivo.\\
È un classico attacco del tipo ''man in the middle'', in cui due stanno comunicando, ma non sanno che in mezzo c'è il cattivone che intercetta tutte le comunicazioni.
La criticità di questo tipo di attacco è molto alta, perché non c'è modo di stabilire se ci sia un man in the middle o no. Tuttavia, la sua incidenza è molto limitata perché occorre la presenza fisica dell'host cattivo all'interno del segmento di rete.
!!Esercizio 3
''Analizzare, in sintesi, il seguente annuncio di vulnerabilità:''
* ''motivare il livello di criticità attribuito;''
* ''proporre soluzioni possibili.''
'''Level''': CRITICAL: yaSSL Multiple Vulnerabilities
'''Affected''': yaSSL versions 1.7.5 and prior
'''Description''': YaSSL is an open source implementation of the Secure Socket Layer (SSL) and Transport Layer Security (TLS) standars, used for adding authentication and encryption to network traffic. It contains multiple vulnerabilities in its handling of SSL streams. A specially crafted request from a clinet could exploit one of these vulnerabilities, and allow an attacker to execute arbitrary code with the privileges of the vulnerable process using the library. Full technical details and proofs-of-concept are publicly available for these vulnerabilities. Note that the popular MySQL database server uses yaSSL: if SSL support is enabled on MySQL, it has been confirmed that it is vulnerable to a pre-authentication code execution attack. A proof-of-concept for the MySQL vulnerability is also publicly available.
'''Status''': YaSSL has not confirmed, no updates available
Qui la criticità è detta '''CRITICAL''', cioè la più alta possibile. I motivi sono i seguenti:
* esistono documentazioni pubbliche su come sfruttare la vulnerabilità
* permette l'esecuzione di codice con i privilegi dell'utente che usa la libreria. Siccome è una libreria usata da processi con alti privilegi (eg MySQL), potenzialmente i danni saranno molto ciccioni
* è incorporata in MySQL, che è molto diffuso
* non ci sono updates disponibili, e coinvolge tutte le versioni di YaSSL precedenti alla 1.7.5
La possibile soluzione è disabilitare il supporto SSL per MySQL, nel caso questo sia stato attivato.
----
[[Torna alla pagina di SnR -> SicurezzaNelleReti]]
|
|
