Progetto Netkit

Progetto Reti
Azienda americana con filiali in Italia presenti
sia a Roma che a Milano
Description
http://www.uniroma1.it/Web
coltellese.1534700@studenti.uniroma1.itE-mail
S.Coltellese, F.Tanasache,N.MascaroAuthor(s)
1.3Version

netkit – [ footer ]© Some Organization
Ltd.
last update: some-date
copyright notice
All the pages/slides in this presentation, including but not limited to,
images, photos, animations, videos, sounds, music, and text
(hereby referred to as “material”) are protected by copyright.
This material, with the exception of some multimedia elements
licensed by other organizations, is property of the authors and/or
organizations appearing in the first slide.
This material, or its parts, can be reproduced and used for didactical
purposes within universities and schools, provided that this
happens for non-profit purposes.
Information contained in this material cannot be used within network
design projects or other products of any kind.
Any other use is prohibited, unless explicitly authorized by the
authors on the basis of an explicit agreement.
The authors assume no responsibility about this material and provide
this material “as is”, with no implicit or explicit warranty about the
correctness and completeness of its contents, which may be
subject to changes.
This copyright notice must always be redistributed together with the
material, or its portions.

Lab topologyLab topology rootNSrootNS
roma.euroma.eu
webing.comwebing.com
manhattan.usmanhattan.us
milano.eumilano.eu
test.eutest.eu
.us.us .eu.eu
server
3
Authority for
webing
Authority for
webing
dnsUS dnsEU
server
4
ns3
ns1
ns2
Authority for
manhattan.us
Authority for
manhattan.us
Authority for
roma.eu
Authority for
roma.eu
Authority for
milano.eu
Authority for
milano.eu
Authority for
.eu
Authority for
.eu
Authority for
.us
Authority for
.us
Authority for
test.eu
Authority for
test.eu
dnsCOM
comcom
Authority for
com
Authority for
com

Ltd.
rootNS
R3
A
8.2.2.0/24
B
server
1
server
2
server
back-
end
eth0
4
eth0
3
eth0
2
R6
R5
R4
R1
R2
ns1
ns3
ns2
client1
client2
hostMilano
server
5
eth0
1
eth0
1
eth0
1
eth0
1
eth3
1
eth1
1
eth0
2
150.168.0.0/24
server
3
E
C
D
I
H
NF
M
eth1
1
eth0
1
eth2
2
eth1
1
eth2
2
eth0
3
eth0
2
eth1
1
eth0
1
eth1
1
111.11.13.0/24
111.11.11.0/24
111.169.0.0/24
eth2
2
eth1
1
eth2
2
eth0
2
eth0
1
eth1
1
eth0
3
eth0
2
eth0
2
111.11.12.0/24
192.80.80.0/24
192.0.2.0/24
CA
137.168.1.0/24
eth3
1
X
eth0
2
115.15.15.0/30
192.167.5.0/24
eth0
3
eth0
2
eth2
1
eth0
4
eth0
3
server
4
192.0.0.0/24
192.0.1.0/24
eth0
2
network
running rip
network
running
ospf 30
3020
20
20
20
L
V
dnsUS
eth0
3
dnsEU
eth0
3dnsCOM
160.120.0.0/24
Z
eth0
2
eth4
1
NatUs
NatEueth1
1
20
R
111.11.14.0/24
20
20
20
20
eth0
2
192.168.1.0/24
G
eth1
1

Ltd.
Start lab
Usare il comando lstart per far partire il laboratorio
Per prima cosa ricordarsi di settare le variabili d'ambiente (per
esempio usando uno script).
user@lab_progetto:~$ lstart
Attendi l'avvio di tutte le macchine.

Ltd.
Protocolli di routing
 Per la rete in questione si è scelto un tipo di
routing dinamico e non statico per diversi motivi:
1. Tabelle di routing aggiornate in maniera
dinamica e non dal amministratore come per il
caso del routing statico.
2. Tipologia adatta sopratutto per reti di grandi e
grandissime dimensioni.
3. Reattivo ai guasti (il router conoscendo un
guasto cerca percorsi alternativi).
4. No congestionamento.

Ltd.
 Ogni router nella nostra rete implementa un
protocollo di routing tramite il software
zebra/quagga. Quagga è costituito da un
insieme di demoni che implementano i vari
protocolli di routing. Le informazioni ottenute dai
vari protocolli sono “raggruppate” da un demone
specifico (Zebra) che ha il compito di
comunicare con il Kernel del PC. Ogni macchina
che è stata designata per fungere da router
avvia il software mediante il comando nel file
startup
● /etc/init.d/zebra start

Ltd.
 Per mandare in esecuzione uno qualsiasi dei
demoni relativi ai protocolli di routing bisogna
scrivere un file di configurazione, cioè file di
testo in cui sono riportati dei comandi che
permettono di configurare la tipologia di
protocollo secondo le proprie esigenze. Nella
nostra rete utilizzeremo solo i protocolli di ospf e
rip.
 Per dire a zebra quali demoni si devono avviare
bisogna scrivere nel file daemons i seguenti
comandi in questo formato:
● zebra=yes
● ripd=no
● ospfd=yes

Ltd.
 Nel file zebra.conf andranno le informazioni
generali come password e hostname e percorso
per il logfile:
● ! -*- zebra -*-
● !
● ! zebra configuration file
● !
● hostname zebra
● password zebra
● enable password zebra
● !
● !
● !
● log file /var/log/zebra/zebra.log

Ltd.
 A seconda del protocollo scelto andremo a
creare un file specifico, per esempio se vogliamo
utilizzare il protocollo ospf andremo a scrivere
un file ospfd.conf di questo tipo dove come
metrica scegliamo la distanza fra due router,
questo per ogni interfaccia che fa utilizzo di ospf.
Inoltre distribuiamo le informazioni anche ai
router rip vicini su tutte le sottoreti direttamente
connesse:
● !
● hostname ospfd R3
● password zebra
● enable password zebra
● ! (segue slide successiva -->)

Ltd.
● interface eth1
● ip ospf cost 20
● !
● interface eth2
● ip ospf cost 30
● !
● router ospf
● network 111.11.0.0/16 area 0
● redistribute connected
● redistribute rip
● !
● log stdout

Ltd.
NAT
 Entrambe le filiali hanno un indirizzamento
interno privato in modo da estendere il numero
di host interni. I servizi pubblici sono quindi
nattati. Le filiali hanno entrambe un router che
effettua questi compiti. Per entrambi i router nei
file di startup impostiamo le regole della tabella
NAT in particolare le catene
FORWARD,PREROUTING,POSTROUTING.
 La policy FORWARD permette ad un
amministratore di controllare dove vengono
diretti i pacchetti all'interno di una LAN.

Ltd.
NAT
 Iniziamo concedendo ai sistemi situati dietro
firewall/gateway, la possibilità di accedere alla
rete interna. Il gateway direziona i pacchetti da
un nodo LAN alla sua destinazione prevista,
passando tutti i pacchetti attraverso il proprio
dispositivo eth1.
● iptables -A FORWARD -i eth1 -j ACCEPT
● iptables -A FORWARD -o eth1 -j ACCEPT
 Ora configuriamo il firewall per l'IP
masquerading, il quale maschera le richieste
provenienti dai nodi LAN con l'indirizzo IP dei
dispositivi esterni del firewall (in questo caso,
eth0).

Ltd.
NAT
 POSTROUTING permette ai pacchetti di essere
modificati quando gli stessi abbandonano il
dispositivo esterno del firewall. Il target -j
MASQUERADE viene specificato in modo da
poter mascherare l'indirizzo IP privato di un
nodo, con l'indirizzo IP esterno del
firewall/gateway.
● iptables -t nat -A POSTROUTING -o eth0 -j
MASQUERADE
 Ora essendo in possesso di più server nella
nostra rete interna, desiderate rendere il
suddetto server disponibile esternamente, allora
usiamo il target -j DNAT della catena
PREROUTING in NAT.

Ltd.
NAT
 In questo modo siamo in grado di specificare
l'indirizzo IP di destinazione insieme ad una
porta dove i pacchetti in entrata, che richiedono
un collegamento al nostro servizio interno,
possono essere inoltrati. Nel nostro caso,
desideriamo inoltrare richieste HTTP in entrata,
al nostro sistema server Server HTTP Apache
bilanciando il carico sui vari server
● iptables -t nat -A PREROUTING -p tcp --dport
domain -i eth0 -j DNAT --to 150.168.0.4

Ltd.
NAT
 Solo per il router della server farm in US
rendiamo disponibile il server3 per i servizi di
DNS
● iptables -t nat -A PREROUTING -p tcp --dport
● iptables -t nat -A PREROUTING -p udp --dport

Ltd.
Tunneling
 OpenVPN è una soluzione Open Source che
opera in user space, creando un tunnel point-to-
point TCP over UDP che permette la creazione di
VPN.
 La necessità primaria di aziende, cooperative,
società o qualunque altro genere di
organizzazione è lo scambio di dati ed
informazioni fra sedi remote.
 Le VPN, per comunicare, usano un sistema di
tunnelling. Questo evita anche attacchi di tipo
spoofing (mascherare il proprio indirizzo IP).

Ltd.
Tunneling
 Come primo passo dobbiamo creare il certificato
e la chiave privata del CA (Certification
Authority):
 cd /home dove ci sono due eseguibili:
➔ createFolder.sh
➔ createKey.sh
 Lanciamo per ora solo l'eseguibile
createFolder.sh che ci crea ca.crt e ca.key:
● source createFolder.sh

Ltd.
Tunneling
 Con il secondo passo generiamo la chiave
privata e la richiesta di certificato di hostMilano
e server_back_end rispettivamente andando ad
eseguire sulla macchina virtuale hostMilano e
server_back_end un eseguibile come fatto in
precedenza per la CA.
● cd /home dove c'è l'eseguibile:
➔ pushkey.sh
 La password da digitare per la generazione della
chiave e del certificato é “root”. L'eseguibile non
fa altro che mandare a CA la richiesta propria
del certificato (hostMilano.csr e
server_back_end.csr).

Ltd.
Tunneling
 Il terzo passo consiste nella generazione ( e
invio) del certificato di hostMilano e
server_back_end da parte di CA (poichè
precedentemente con il passo 2 ha ricevuto le
due richieste di certificato) ai diretti interessati.
 Per questa operazione si esegue il secondo
comando situato nelle cartella home come
spiegato il precedenza:
● cd /home
● source createKey.sh
 Di seguito ci verrà chiesto le conferme per la
signature del certificato (digitare y per
conferma). Anche qui la password richiesta da
digitare è root (viene richiesta 4 volte).

Ltd.
Tunneling
 A questo punto dovremmo avere nella cartella
keys di hostMilano i seguenti file:
➔ ca.crt --> il certificato di CA
➔ hostMilano.csr -->la richesta di certificato
➔ hostMilano.crt -->il certificato generato da CA
➔ hostMilano.key -->la chiave privata

Ltd.
Tunneling
 Nella cartella keys di server_back_end:
➔ ca.crt --> il certificato di CA
➔ server_back_end.csr -->la richesta di certificato
➔ server_back_end.crt -->il certificato generato da
CA
➔ server_back_end.key -->la chiave privata
● Eseguire inoltre il comando per generare la
chiave di Diffie-Helllman
➔ /etc/openvpn/2.0/build-dh
➔ Dh1024.pem -->la chiave Diffie-Hellman

Ltd.
Tunneling
 L'ultimo e il più importante passo è la
configurazione l'avvio del server.
 Per avviare il server dobbiamo semplicemente
eseguire l'eseguibile nella cartella /home del
server:
 Source start_openvpn.sh
 Per la giusta verifica del server diamo il
comando ifconfig tun0 e per un corretto
funzionamento dovremmo visualizzare
l'interfaccia VPN da utilizzare.

Ltd.
Tunneling
 La stessa cosa la andremo a fare sul client (nel
nostro caso hostMilano).
● source start_openvpn.sh
 Un ulteriore test effettuato consiste nel catturare
alcuni pacchetti tramite Wireshark facendo il
ping da hostMilano a server_back_end.
● ping 10.8.0.1

Ltd.
Tunneling
Row 1 Row 2 Row 3 Row 4
0
2
4
6
8
10
12
Column 1
Column 2
Column 3

Ltd.
DNS e Load Balancing
 Come illustrato nella slide 3 ci sono diverse autorità per ogni
zona. Questa scelta porta diversi vantaggi:
1. Minore tolleranza ai guasti
2. Traffico eccessivo evitato
3. Problema Database centrale troppo distante
4. Scalabilità
 I server {1, 2, 3, 4, 5} sono tutti web server che usano apache2
(hanno tutti il file /var/www/index.html)
 Inoltre I server {3, 4} sono anche server DNS (oltre al file
index.html eseguono il comando bind poichè sono autorità per la
zona webing.com e roma.eu rispettivamente)
 DnsUS e dnsEU sono autorità per le zona US ed EU.
 DnsCOM è autorità per la zona COM.

Ltd.
 Ns1, ns2, ns3 sono le autorità per le zone manhattan, test,
milano rispettivamente.
 Esempio di prova:
client2client2
client2:~# ping client2.test.eu
 Il load balancing è stato fatto sia su base geografica sia in base
al carico. Quest'ultima scelta è dovuta al fatto che un solo server
web sarebbe stato sovracaricato da una eccessiva richiesta del
servizio web.

Ltd.
 Il carico è stato distribuito in base alla locazione del richiedente.
 Il servizio web è offerto sotto il nome www.webing.com.
 Le richieste proveniente dall'America (per esempio da
client1.manhattan.us) saranno servite dalla server farm-us
(server1, server2, server3) su cui è stato scelta una politica di
tipo random per il bilanciamento del carico.
 Le richieste proveniente dall'Europa (per esempio da
client2.test.eu) saranno servite dalla server farm-eu(server4,
server5 )su cui è stato scelta una politica di tipo cyclic per il
bilanciamento del carico.

Ltd.
 Si può eseguire un test attraverso il comando dig
www.webing.com oppure lanciare lo script del client 1 e 2
count_server_replies.sh che effettua N richieste del servizio web
contando quante volte ha risposto un determinato server in base
alla scelta del tipo di bilanciamento (cyclic or random).
 Esempio
client1:~# source count_server_replies.sh
Sending 100 requests to www.webing.com...
33 replies received from server 1
client1client1

Ltd.
Firewall
 Per configurare il nostro firewall inseriamo nel
nostro file di startup dei comandi che
modificheranno l'iptables.La configurazione
scelta permetterà solo i servizi di ssh ed http/s,
facendo attenzione a configurare correttamente
i nostri server DNS.La configurazione è
minimale, pensata per un server pubblico che
distribuisce contenuti tramite http da controllare
con ssh(il caso più comune).
 La politica scelta per la nostra iptables per
quanto riguarda la tabella FILTER è quella di
scartare tutti i pacchetti di INPUT che non sono
considerati dalle nostre rules(regole)e lo stesso
per la FORWARD.

Ltd.
Firewall
 Per la tabella di OUTPUT vogliamo permettere
qualsiasi traffico in uscita quindi scegliamo come
politica ACCEPT:
● iptables -P INPUT DROP
● iptables -P FORWARD DROP
● iptables -P OUTPUT ACCEPT
 Innanzitutto dobbiamo consentire tutto il traffico
interno al nostro computer, che passa per
l'interfaccia di loopback "lo":
● iptables -A INPUT -i lo -j ACCEPT

Ltd.
Firewall
 La seconda cosa che faremo è navigare nel web
e più in generale lasciare entrare tutto il traffico
che è stato da noi richiesto e stabilito:
● iptables -A INPUT -m state --state
RELATED,ESTABLISHED -j ACCEPT
● iptables -A INPUT -m conntrack --ctstate
ESTABLISHED,RELATED -j ACCEPT
 Ora i servizi che noi vogliamo permettere,
iniziamo con ssh:
● iptables -A INPUT -p tcp --dport ssh -j ACCEPT

Ltd.
Firewall
 Il server web usa la porta 80(http) e 443(https),
quindi consentiamo tutto il traffico che
dall'esterno chiede di entrare attraverso la
nostra porta 80 e 443:
● iptables -A INPUT -p tcp --dport 80 -j ACCEPT
● iptables -A INPUT -p tcp --dport 443 -j ACCEPT
 Dobbiamo anche consentire le risposte DNS in
ingresso da nostri server DNS:
● iptables -A INPUT -s xxx.xxx.xxx.xxx -i eth0 -p
udp -m state --state ESTABLISHED -m udp --sport
53 -j ACCEPT
● iptables -A INPUT -s xxx.xxx.xxx.xxx -i eth0 -p
tcp -m tcp --sport 53 -m state --state
ESTABLISHED -j ACCEPT

Ltd.
Firewall
 Scartiamo tutto il resto:
● iptables -A INPUT -j DROP
 Infine scegliamo come livello di registrazione di
dati di log 7, cioè il minimo livello per mantenere
informazioni e permettere debug per evitare di
mantenere troppe informazioni dei registri del
server:
● iptables -I INPUT 5 -m limit --limit 5/min -j LOG
--log-prefix "iptables denied: " --log-level 7
 Per visionare il nostro piccolo firewall:
● sudo iptables -vv -L

Ltd.
devices
network
interface
card
router
switch
hub
pc
pc with
mua
pc
laptop
named
router
firewalled
router
firewall

Ltd.
servers
server
name
server
mail
exchanger
mail transfer
agent
mx + ns
mx + ns +
mta

Ltd.
tunnels

Ltd.
windows
pc2:~# ping 195.11.14.5 ┃
pc2pc2pc2pc2
user@localhost:~$ cd netkit-lab_arp
user@localhost:~/netkit-lab_arp$ lstart ┃
host machinehost machinehost machinehost machine
user@localhost:~$ cd netkit-lab_arp
user@localhost:~/netkit-lab_arp$ lstart ┃
host machinehost machinehost machinehost machine

Ltd.
callouts
description of
a specific
element on
the page
description of
a specific
element on
the page
some notessome notes

Ltd.
other symbols
data
routing
software
sniffer
autonomous system
mail

Ltd.
C
eth1
1
AS1
AS2eth0
2
200.1.1.0/24
eth0
1
A
B
eth1
1
195.11.14.0/24
193.10.11.0/24
sample
interdomain
topology

Progetto Netkit

More Related Content

What's hot

Viewers also liked

Similar to Progetto Netkit

Progetto Netkit