Statistics
| Branch: | Revision:

root / body.tex @ a58010e4

History | View | Annotate | Download (29.5 KB)

1
\section{Attacchi Al Mezzo Fisico}
2

    
3

    
4
\frame
5
{
6
\frametitle{Attacchi al mezzo fisico}
7
Ciascun mezzo fisico è più o meno vulnerabile ad attacchi di vario tipo.
8
\begin{itemize}
9
\uncover<1->{\item DoS: interruzione del collegamento o Jamming}
10
\uncover<2->{\item attacchi di \alert<2>{\textit{Wiretapping}}}
11
\uncover<3->{\item sniffer hardware, sniffing in reti broadcast}
12
\end{itemize}
13
}
14

    
15
\frame
16
{
17
\frametitle{Attacchi al mezzo fisico: accenni}
18
\begin{beamerboxesrounded}[shadow=true]{Jamming}
19
\begin{itemize}
20
\uncover<1->{\item jamming sul mezzo fisico si può fare se il mezzo fisico lo
21
permette, come nel caso di reti wireless o reti wired con cavi non
22
schermati}
23
\uncover<2->{\item anche se il jamming è difficile, basta far
24
fallire la ricezione di un bit per invalidare il checksum e far scartare
25
il pacchetto}
26
\end{itemize}
27
\end{beamerboxesrounded}
28
}
29

    
30

    
31
\frame
32
{
33
\frametitle{Attacchi al livello di collegamento}
34
\begin{beamerboxesrounded}[shadow=true]{}
35
\begin{itemize}
36
\uncover<1->{\item DoS: \alert<1>{\textit{flood}} di pacchetti, generazione di collisioni}
37
\uncover<2->{\item spoofing di indirizzi MAC}
38
\uncover<3->{\item ARP-Spoofing}
39
\end{itemize}
40
\end{beamerboxesrounded}
41
}
42

    
43
\frame
44
{
45
\frametitle{DoS al livello di collegamento: dettagli}
46
\begin{beamerboxesrounded}[shadow=true]{Flood vari}
47
\begin{itemize}
48
\uncover<1->{\item un flood può essere mirato alla saturazione della
49
banda.}
50
\uncover<2->{\item se il mezzo è condiviso si possono non rispettare i
51
tempi di timeout e creare numerose collisioni, oppure mantenere il canale
52
sempre occupato}
53
\uncover<3->{\item un flood può essere mascherato inviando pacchetti con
54
indirizzo mittente modificato}
55
\end{itemize}
56
\end{beamerboxesrounded}
57
}
58

    
59
\frame
60
{
61
\frametitle{ARP-Spoofing}
62
\begin{beamerboxesrounded}[shadow=true]{Il protocollo ARP}
63
\begin{itemize}
64
\uncover<1->{\item la macchina 192.168.2.51 vuole raggiungere l'indirizzo
65
192.168.2.52 nella stessa sottorete. Per farlo deve inviare un frame all'indirizzo
66
MAC corrispondente}
67
\uncover<2->{\item se non conosce l'indirizzo MAC corrispondente invia una
68
richiesta ARP in broadcast chiedendo che la macchina 192.168.2.52 risponda
69
notificando il suo MAC address}
70
\uncover<3->{\item la macchina 192.168.2.52 risponde con un messaggio di
71
ARP-Reply specificando che il suo indirizzo MAC corrisponde all'IP
72
192.168.2.52}
73
\end{itemize}
74
\end{beamerboxesrounded}
75
}
76

    
77

    
78
\frame
79
{
80
\frametitle{Campi di ARP}
81
\begin{itemize}
82
\uncover<1->{\item campi del protocollo ARP:
83
  \begin{table}
84
    \hbox to\textwidth{\hss
85

    
86
\begin{tabular}{|c|}
87
\hline
88
Hardware type (ethernet)\\
89
\hline
90
Protocol type (IPv4)\\
91
\hline
92
[...]\\
93
\hline
94
Sender hardware address  \\
95
\hline
96
Sender protocol address  \\
97
\hline
98
Receiver hardware address  \\
99
\hline
100
Receiver protocol address  \\
101
\hline
102
\end{tabular}
103
        \hss}
104
\end{table}
105
 }
106
\end{itemize}
107
}
108

    
109
\frame
110
{
111
\frametitle{Algoritmo ARP}
112

    
113
\begin{center}
114
\fbox{%
115
    \begin{minipage}{9cm}
116
      \UseVerbatim[fontsize=\tiny,fontfamily=courier, =1]{ARP-protocol}
117
    \end{minipage}
118
    }
119
    \end{center}
120
\vskip1cm
121
\bi 
122
\ii la tabella ARP viene aggiornata ad ogni pacchetto ARP ricevuto, sia di request che di reply
123
\ei 
124
}
125

    
126
\frame
127
{
128
\frametitle{ARP-Spoofing, segue}
129
\bcols
130
\col 
131
\begin{beamerboxesrounded}[shadow=true]{Attacco di ARP-spoofing}
132
\begin{itemize}
133
\uncover<1->{\item scopo dell'attacco è intercettare il traffico che passa
134
tra due macchine su una rete con switch. L'attaccante fa parte della rete
135
ma non fa parte del path tra le due macchine vittima.}
136
\end{itemize}
137
\end{beamerboxesrounded}
138
\col
139
\scaledimg{switched-net}
140
\ecols
141
}
142

    
143

    
144
\frame
145
{
146
\frametitle{ARP-Spoofing, segue}
147
\bcols
148
\col[0.4] 
149
\begin{beamerboxesrounded}[shadow=true]{Attacco di ARP-spoofing}
150
\bii
151
\item Eve manda messaggi ARP-Reply diretti
152
all'indirizzo MAC di \alert{Alice}, dichiarando che l'IP di
153
\alert{Bob} corrisponde al suo
154
indirizzo MAC
155
\item Eve manda anche messaggi ARP-Reply diretti
156
all'indirizzo MAC di \alert{Bob}, dichiarando che l'IP di \alert{Alice} corrisponde al suo
157
indirizzo MAC
158
\end{itemize}
159
\end{beamerboxesrounded}
160
\col[0.6]
161
\only<1>{\scaledimg[0.9]{arp-1}}
162
\only<2>{\scaledimg[0.9]{arp-2}}
163

    
164
\only<1>{ARP: 192.168.2.52 is at 08:00:46:b7:25:44}
165
\only<2>{ARP: 192.168.2.51 is at 08:00:46:b7:25:44}
166

    
167
\ecols
168
}
169

    
170

    
171

    
172
\frame
173
{
174
\frametitle{ARP-Spoofing, segue}
175
\bcols
176
\col[0.4] 
177
\begin{beamerboxesrounded}[shadow=true]{}
178
A questo punto le tabelle ARP di Alice e Bob sono inquinate
179
\bii
180
\item Alice manderà un pacchetto a Bob, inviandolo però al MAC di Eve
181
\item Eve guarda/modifica il pacchetto, e lo reinstrada a Bob
182
\end{itemize}
183
\end{beamerboxesrounded}
184
\col[0.6]
185
\only<1>{\scaledimg[0.8]{arp-3}}
186
\only<2>{\scaledimg[0.8]{arp-4}}
187

    
188
\only<1>{tcp syn: dst IP 192.168.2.52,\\ dst MAC 08:00:46:b7:25:44}
189
\only<2>{tcp syn: dst IP 192.168.2.52,\\ dst MAC 00:04:76:13:fb:1e}
190
\ecols
191
}
192

    
193
\begin{frame}
194
\frametitle{ARP spoofing: dettagli}
195
\bi
196
\ii Alla fine dell'attacco Alice e Bob possono mantenere delle connessioni funzionanti che vengono in realtà analizzate da Eve
197
\ii Se Eve realizza l'attacco tra tutti i nodi ed il gateway, diventa un man-in-the-middle sul traffico da qualsiasi host verso Internet.
198
\ei
199
\end{frame}
200

    
201
\begin{frame}
202
\frametitle{ARP spoofing: Mantenimento}
203
\bi
204
\ii Che succede se per qualche motivo Alice deve mandare un pacchetto ad un quarto host?
205
\ii Alice invia una nuova richiesta ARP in broadcast, e corregge la tabella ARP di Bob
206
\ii Perché l'attacco sia efficace, Eve deve mandare continuamente pacchetti ARP modificati per continuare a mantenere inquinate le tabelle ARP delle vittime.
207
\ei
208
\end{frame}
209

    
210

    
211
\frame
212
{
213
\frametitle{Attacchi al livello di rete}
214
\begin{beamerboxesrounded}[shadow=true]{}
215
\begin{itemize}
216
\uncover<1->{\item DoS: flood di pacchetti, smurf}
217
\uncover<2->{\item covert channels, fragmentation attacks, source routing}
218
\uncover<3->{\item spoofing di indirizzi IP}
219
\end{itemize}
220
\end{beamerboxesrounded}
221
}
222

    
223
\subsection{Fragmentation attacks}
224
\frame
225
{
226
\frametitle{Fragmentation attacks}
227

    
228
\bcols
229
\col[0.4]
230

    
231
\bi 
232
\ii Sappiamo che il IP permette di spezzare un pacchetto in
233
più frammenti
234
\ii Il campo Fragment Offset esprime l'offset del pacchetto rispetto all'originale, espresso in multipli di 8 byte
235
\ii Total length esprime la lunghezza del pacchetto (frammento) in Byte, header incluso
236
\ei 
237

    
238
\col[0.7]
239
%\setlength{\bitwidth}{.25cm}
240
\textbf{IP Packet Header:}
241

    
242
\begin{bytefield}{32}
243
\\
244
\bitheader{3,7,15,18,31}\\
245
\bitbox{4}{Vers} 
246
\bitbox{4}{IHL}
247
\bitbox{8}{TOS}
248
\bitbox{16}{Total lenght}\\
249
\bitbox{16}{Identification}
250
\bitbox{3}{Flg}
251
\bitbox{13}{Fragment Offset}\\
252
\bitbox{8}{TTL}
253
\bitbox{8}{Protocol}
254
\bitbox{16}{Header Checksum}\\
255
\bitbox{32}{Source IP}\\
256
\bitbox{32}{Destination IP}\\
257
\bitbox{32}{Options + Padding}\\
258
\end{bytefield}
259

    
260
\ecols
261
}
262

    
263

    
264
\frame
265
{
266
\frametitle{Overlapping Fragmentation attacks}
267
\bcols
268
\col[0.3]
269
Il protocollo IP permette di spezzare pacchetti in frammenti più piccoli di un header TCP. Inoltre i pacchetti che arrivano successivamente possono riscrivere quelli arrivati in precedenza.
270
\col[0.7]
271
\textbf{TCP Packet Header:}
272

    
273
      \begin{bytefield}{32}
274
      \\
275
      \bitheader{15,31}\\
276
      \bitbox{16}{Source port}
277
      \bitbox{16}{Destination Port} \\
278
      \bitbox{32}{Sequence number} \\
279
      \bitbox{32}{Acknowledgment number} \\
280
      \bitbox{4}{Offset} 
281
      \bitbox{4}{RES}
282
      \bitbox{8}{Flags} 
283
      \bitbox{16}{Window}\\ 
284
      \bitbox{16}{Checksum} 
285
      \bitbox{16}{Urgent Pointer} \\
286
      \bitbox{32}{Option + padding} \\
287
      \end{bytefield}
288
      
289
\ecols
290
}
291

    
292
\definecolor{lightgray}{gray}{0.8}
293

    
294

    
295
\frame
296
{
297
\frametitle{Frammentazione: esempio}
298
\bii 
299
\uncover<1->{\item 
300
  Pacchetto IP di partenza: Total length = 230, MTU = 100
301

    
302
  \begin{bytefield}[bitwidth=0.1em]{230}
303
  \\
304
  \bitheader{19,229}\\
305
  \bitbox{20}{IP}
306
  \bitbox{210}{Payload}\\
307
  \end{bytefield}
308
  }
309

    
310
\uncover<2->{\item 
311
  Verrà spezzato in:
312
  
313

    
314
  \begin{bytefield}[bitwidth=0.1em]{230}
315
  \\
316
  \bitheader{19,99, 199, 229}\\
317
  \bitbox{20}{IP}
318
  \bitbox{210}{}\\
319
  \bitbox[t]{100}{$\underbrace{\hspace{10em}}_{\text{\normalsize Frag 1}}$}
320
  \bitbox[t]{100}{$\underbrace{\hspace{10em}}_{\text{\normalsize Frag 2}}$}
321
  \bitbox[t]{30}{$\underbrace{\hspace{3em}}_{\text{\normalsize Frag 3}}$}\\
322
  \end{bytefield}
323
  }
324
\ei
325
}
326

    
327

    
328
\frame
329
{
330
\frametitle{Frammentazione: esempio}
331
\only<1>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
332
  \\
333
  \bitheader{19,99, 199, 229}\\
334
  \bitbox{20}{IP}
335
  \bitbox{210}{}\\
336
  \bitbox[t]{100}{$\underbrace{\hspace{10em}}_{\text{\normalsize Frag 1}}$}\\
337
  \end{bytefield}}}
338
\only<2>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
339
  \\
340
  \bitheader{19,99, 199, 229}\\
341
  \bitbox{20}{IP}
342
  \bitbox{210}{}\\
343
  \bitbox[t]{100}{}
344
  \bitbox[t]{100}{$\underbrace{\hspace{10em}}_{\text{\normalsize Frag 2}}$}\\
345
  \end{bytefield}}}
346

    
347
\only<3>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
348
  \\
349
  \bitheader{19,99, 199, 229}\\
350
  \bitbox{20}{IP}
351
  \bitbox{210}{}\\
352
  \bitbox[t]{200}{}
353
  \bitbox[t]{30}{$\underbrace{\hspace{3em}}_{\text{\normalsize Frag 3}}$}\\
354
  \end{bytefield}}}
355
    
356
\bii 
357
  \ii frammento 1:
358
  \begin{bytefield}[bitwidth=0.1em]{120}
359
  \\
360
  \bitbox{20}{IP}
361
  \bitbox{100}{\bytefieldsetup{bitheight=3ex}\bitbox{20}{IP}\bitbox{75}{}}
362
  \end{bytefield}
363
  \ii frammento 2: 
364
  \begin{bytefield}[bitwidth=0.1em]{120}
365
  \\
366
  \bitbox{20}{IP}
367
  \bitbox{100}{\bytefieldsetup{bitheight=3ex}\bitbox{96}{}}
368
  \end{bytefield}  
369
  \ii frammento 3:
370
  \begin{bytefield}[bitwidth=0.1em]{40}
371
  \\
372
  \bitbox{20}{IP}
373
  \bitbox{30}{\bytefieldsetup{bitheight=3ex}\bitbox{26}{}}
374
  \end{bytefield}
375
\ei
376
}
377

    
378

    
379
\frame
380
{
381
\frametitle{Fragmentation attacks, segue:}
382
\begin{itemize}
383
\uncover<1->{\item I firewall normalmente vengono configurati per bloccare
384
i tentativi di connessione dall'esterno della rete verso le porte alte
385
(oltre la 1024) dei server.  Devono pero' lasciare passare i pacchetti che
386
sono rivolti verso porte alte ma che fanno parte di una connessione aperta
387
dall'interno della rete verso l'esterno.}
388
\uncover<2->{\item Per bloccare i tentativi di aprire una connessione 
389
verso l'interno filtrano i pacchetti con il flag SYN del protocollo TCP
390
settato ad 1 (pacchetti di inizio connessione).}
391
\end{itemize}
392
}
393

    
394

    
395
\frame
396
{
397
\frametitle{Tiny Fragments Attack}
398
\only<1>{\centering{
399
Len = 300B
400

    
401
\begin{bytefield}[bitwidth=0.1em]{230}
402
  \\
403
  \bitheader{19,39,299}\\
404
  \bitbox{20}{IP}
405
  \bitbox{20}{TCP}
406
  \bitbox{260}{Payload}
407
  \end{bytefield}}}
408
\only<2>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
409
  \\
410
  \bitheader{23, 39,299}\\
411
  \bitbox{20}{IP}
412
  \bitbox{20}{TCP}
413
  \bitbox{260}{Payload}\\
414
  \bitbox[t]{24}{$\underbrace{\hspace{\width}}_{\text{\normalsize 24B}}$}
415
  \end{bytefield}}}
416
\only<3>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
417
  \\
418
  \bitheader{23, 39,299}\\
419
  \bitbox{20}{IP}
420
  \bitbox{20}{TCP}
421
  \bitbox{260}{Payload}\\
422
  \bitbox[t]{24}{}
423
  \bitbox[t]{276}{$\underbrace{\hspace{\width}}_{\text{\normalsize 276B}}$}
424

    
425
  \end{bytefield}}}
426
      
427
\bcols
428
\col[0.4]
429
\only<2-3>{
430
 \begin{bytefield}[bitwidth=0.3em]{32}
431
\tiny
432
    \begin{rightwordgroup}{\tiny IP Header + \\ \tiny 8B TCP header}
433
    \bitbox{4}{Ver}
434
    \bitbox{4}{IHL}
435
    \bitbox{8}{TOS}
436
    \bitbox{16}{LEN}\\
437
\tiny
438
      \bitbox{32}{[...]}\\
439
\tiny
440
      \bitbox{16}{Sport} 
441
    \bitbox{16}{\alert{Dport}}
442
    \end{rightwordgroup}
443
  \end{bytefield}
444
  Primo Frammento:\\
445
  offset = 0, len = 24  
446
  }
447
  
448

    
449
\col[0.6] 
450
\only<3>{
451
 \begin{bytefield}[bitwidth=0.5em]{32}
452
  \tiny
453
    \begin{rightwordgroup}{ \tiny Resto TCP header\\  \tiny + Payload}
454
      \bitbox{32}{Acknowledgment number} \\
455
 \tiny      \bitbox{4}{Offset} 
456
      \bitbox{4}{RES}  
457
      \bitbox{3}{\color{gray}\rule{\width}{\height}} 
458
      \bitbox{1}{\alert{S\\Y\\N}}      
459
      \bitbox{4}{\color{gray}\rule{\width}{\height}} 
460
      \bitbox{16}{Window}\\ 
461
 \tiny      \bitbox{16}{Checksum} 
462
      \bitbox{16}{Urgent Pointer} \\
463
 \tiny      \bitbox{32}{Option + padding} \\
464
 \tiny      \bitbox{32}{Payload...}
465
    \end{rightwordgroup}
466
  \end{bytefield}
467
  Secondo Frammento:\\
468
  offset = 3 (x8), len = 276
469
    }
470
\ecols
471
}
472

    
473

    
474
\frame
475
{
476
\frametitle{Fragmentation attacks, segue:}
477
\bii 
478
\item Utilizzando un primo frammento che non contiene i flag TCP il
479
firewall lascia passare il frammento anche se diretto verso una porta >
480
1024, il secondo frammento non viene interpretato come un pacchetto TCP
481
perché non contiene un header TCP valido, quindi anche quello non viene filtrato.
482
\item Quando il pacchetto arriva alla macchina di destinazione
483
viene riassemblato, è diretto verso una porta > 1024 ed ha il flag SYN=1
484
ma ha superato il firewall
485
\ii Rimedio: drop di tutti i frammenti sotto una dimensione minima. 
486
\item E se un firewall filtra tutti i pacchetti verso la porta 22 ma non verso la 80?
487
\end{itemize}
488

    
489
}
490

    
491

    
492
\frame
493
{
494
\frametitle{Overlapping fragments attack}
495
\only<1>{\centering{
496
Len = 300B
497

    
498
\begin{bytefield}[bitwidth=0.1em]{230}
499
  \\
500
  \bitheader{19,39,299}\\
501
  \bitbox{20}{IP}
502
  \bitbox{20}{TCP}
503
  \bitbox{260}{Payload}
504
  \end{bytefield}}}
505
\only<2>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
506
  \\
507
  \bitheader{23, 39,299}\\
508
  \bitbox{20}{IP}
509
  \bitbox{20}{TCP}
510
  \bitbox{260}{Payload}\\
511
  \bitbox[t]{24}{$\underbrace{\hspace{\width}}_{\text{\normalsize 24B}}$}
512
  \end{bytefield}}}
513
\only<3>{\centering{\begin{bytefield}[bitwidth=0.1em]{230}
514
  \\
515
  \bitheader{23, 39,299}\\
516
  \bitbox{20}{IP}
517
  \bitbox{20}{TCP}
518
  \bitbox{260}{Payload}\\
519
  \bitbox[t]{24}{}
520
  \bitbox[t]{276}{$\underbrace{\hspace{\width}}_{\text{\normalsize 276B}}$}
521

    
522
  \end{bytefield}}}
523
      
524
\bcols
525
\col[0.4]
526
\only<2-3>{
527
 \begin{bytefield}[bitwidth=0.3em]{32}
528
\tiny
529
    \begin{rightwordgroup}{\tiny IP Header + \\ \tiny 8B TCP header}
530
    \bitbox{4}{Ver}
531
    \bitbox{4}{IHL}
532
    \bitbox{8}{TOS}
533
    \bitbox{16}{LEN}\\
534
\tiny
535
      \bitbox{32}{[...]}\\
536
\tiny
537
      \bitbox{16}{Sport} 
538
    \bitbox{16}{\alert{Dport = 80}}
539
    \end{rightwordgroup}
540
  \end{bytefield}
541
  Primo Frammento:\\
542
  offset = 0, len = 24  
543
  }
544
  
545

    
546
\col[0.6] 
547
\only<3>{
548
 \begin{bytefield}[bitwidth=0.5em]{32}
549
  \tiny
550
    \begin{rightwordgroup}{ \tiny Src/Dest IP + \\ \tiny Resto TCP header\\  \tiny + Payload}
551
 \tiny 
552
     \bitbox{16}{Src IP}
553
     \bitbox{16}{Dest IP}\\
554
    \tiny
555
      \bitbox{16}{Sport} 
556
    \bitbox{16}{\alert{Dport = 22}}\\
557
\tiny      \bitbox{32}{Acknowledgment number} \\
558
 \tiny      \bitbox{4}{Offset} 
559
      \bitbox{4}{RES}  
560
      \bitbox{8}{Flags} 
561
      \bitbox{16}{Window}\\ 
562
 \tiny      \bitbox{16}{Checksum} 
563
      \bitbox{16}{Urgent Pointer} \\
564
 \tiny      \bitbox{32}{[...]}
565
    \end{rightwordgroup}
566
  \end{bytefield}
567
  Secondo Frammento:\\
568
  offset = 2 (x8), len = 276
569
    }
570
\ecols
571
}
572

    
573
\begin{frame}
574
\frametitle{Overlapping Fragments}
575
\bi 
576
\ii Il primo frammento ha un header IP valido ed un pezzo di header TCP con porta destinazione 80, quindi il firewall lo lascia passare
577
\ii Il secondo frammento riscrive parte del primo e cambia la porta, ma non contiene un pacchetto IP valido, quindi il firewall non lo può analizzare
578
\ii Il pacchetto viene consegnato a destinazione e riassemblato
579
\ei
580
\end{frame}
581

    
582

    
583

    
584
\begin{frame}
585
\frametitle{Sbagliata gestione dei pacchetti}
586
\bi 
587
\ii Si sono verificati in passato molti casi in cui gli stack protocollari sbagliavano a gestire i frammenti
588
\ii In particolare non verificavano la coerenza delle sovrapposizioni
589
\ii Mandando frammenti con buchi nel mezzo, o più lunghi della lunghezza massima si potevano provocare dei segfault nello stack della macchina ricevente
590
\ei
591
\end{frame}
592

    
593

    
594
\frame
595
{
596
\frametitle{Recall TCP}
597
\scaledimg{setup}
598
}
599

    
600

    
601

    
602
\frame
603
{
604
\frametitle{SYN Flooding}
605
\begin{beamerboxesrounded}[shadow=true]{SYN flood:}
606
\begin{itemize}
607
\uncover<1->{\item Ogni volta che un server riceve un pacchetto con
608
SYN=1 alloca delle risorse di memoria per gestire la connessione che sta
609
per essere creata, quindi invia un pacchetto con i flag SYN=1, ACK=1 e
610
fa partire un timeout per attendere l'arrivo del terzo pacchetto
611
dell'handshake. Si dice che in quel momento sul server c'è una connessione
612
\emph{half-open}.}
613
\end{itemize}
614
\end{beamerboxesrounded}
615
}
616

    
617

    
618

    
619
\frame
620
{
621
\frametitle{TCP SM}
622
\scaledimg[0.8]{tcp_SM}
623
}
624

    
625
\frame
626
{
627
\frametitle{SYN Flooding}
628
\begin{beamerboxesrounded}[shadow=true]{SYN flood:}
629
\begin{itemize}
630
\item Se un attaccante invia un grande numero di pacchetti
631
con SYN=1, prima o poi la memoria del server
632
si saturerà e il server comincerà a scartare pacchetti.
633
\item In alternativa, si raggiungerà il numero massimo di connessioni contemporanee ammesse dal server, ottenendo lo stesso scopo.
634
\item In questo modo si impedisce ad altre macchine di accedere al servizio, un DoS.
635
\end{itemize}
636
\end{beamerboxesrounded}
637
}
638

    
639
\frame
640
{
641
\frametitle{SYN Flooding + IP spoofing}
642
\begin{itemize}
643
\item Un server potrebbe accorgersi che da un IP remoto X sta iniziando un grande numero di connessioni, e cominciare a  filtrare solo i pacchetti provenienti da X.
644
\item L'attacco però per funzionare non necessita che X riceva il pacchetto SYN+ACK.
645
\item L'attacco può quindi essere compiuto usando IP sorgente spoofato, e filtrare con una ACL non è più sufficiente
646
\item L'attaccante deve però usare indirizzi IP sorgenti validi ma su cui non ci sono macchine in ascolto, altrimenti queste macchine risponderanno con un messaggio RST e faranno deallocare la memoria al server
647
\item Conclusione: con un piccolo sforzo da parte dell'attaccante si può produrre un DoS su un server con molte risorse.
648
\end{itemize}
649
}
650

    
651

    
652

    
653
\frame
654
{
655
\frametitle{Attacchi a livello IV:}
656
\begin{beamerboxesrounded}[shadow=true]{SYN cookies:}
657
\begin{itemize}
658
\item Non esistono rimedi comunemente accettati per gli
659
attacchi di SYN Flood, oltre a chiedere agli AS di filtrare i pacchetti da indirizzi IP che non sono loro.
660
\item Un metodo per evitare questo attacco prevede l'utilizzo
661
di SYN cookies, descritti nella RFC 4987: 
662
\begin{itemize}
663
\item quando il server invia il pacchetto SYN=1 e
664
ACK=1 non sceglie un numero di sequenza casuale, ma sceglie un numero che
665
è la codifica di informazioni riguardanti la connessione e non alloca
666
nessuna memoria. Es:
667
\bi 
668
\ii 5 bit: $t\, \%\, 32$ con $t$ contatore incrementato ogni 64 secondi
669
\ii \emph{\color{gray}3 bit: codifica di MSS} $\leftarrow$ non rilevante per noi
670
\ii 24 bit: $f(s, IP_s, Port_s, IP_d, Port_d, t)$ con $s$ segreto
671
\ei 
672
\end{itemize}
673
\item Il numero di sequenza è comunque impredicibile, per evitare gli attacchi di \alert{SYN spoofing}. 
674
\item C'è bisogno di uno stato interno (un unico contatore) ed un segreto usato come seed.
675
\end{itemize}
676
\end{beamerboxesrounded}
677
}
678

    
679

    
680
\frame
681
{
682
\frametitle{Attacchi a livello IV:}
683
\bi 
684
\item Quando il server riceve il terzo pacchetto della connessione (ACK), estrae l' acknowledgement number $a$. 
685
\ii estrae anche IP e porte dal pacchetto ACK
686
\ii calcola $a-1 \stackrel{?}{=} f(s, IP_s, Port_s, IP_d, Port_d, t)$ per valori recenti di $t$
687
\ii se trova un valore di $t$ percui la condizione è vera, il pacchetto ACK appartiene ad una connessione half-open e può allocare memoria
688
\ei
689
}
690
\frame
691
{
692
\frametitle{SYN Cookies}
693
\bi 
694
\ii In pratica, il server codifica informazioni di stato nel sequence number, sapendo che il client restituirà lo stato nell'ACK number
695
\ii Il server così non alloca memoria prima di ricevere un pacchetto di ACK
696
\ei
697
}
698

    
699

    
700

    
701
\frame
702
{
703
\frametitle{Problemi}
704
\bi 
705
\ii TCP supporta estensioni che vengono incluse nel pacchetto di SYN dal client (ad esempio il Maximum Segment Size che il client può ricevere, MSS)
706
\ii Normalmente un server quando riceve un SYN, alloca in memoria una struttura dati che contiene anche informazioni su tali estensioni
707
\ii Se il server non alloca memoria alla ricezione del SYN, si perde le opzioni.
708
\ii Workaround:
709
\bi 
710
\ii Codifica alcune opzioni nel sequence number
711
\ii Non usare sempre i SYN cookies, usarli solo quando si è sotto attacco (il numero di connessioni half-open supera una certa soglia)
712
\ei 
713
\ei
714
}
715

    
716

    
717
\frame
718
{
719
\frametitle{Attacchi a livello IV:}
720
\begin{beamerboxesrounded}[shadow=true]{TCP reset Guess:}
721
\begin{itemize}
722
\uncover<1->{\item Una connessione TCP può essere terminata da uno dei due
723
partecipanti inviando un pacchetto con il flag RST=1. Perché venga
724
accettato il pacchetto deve contenere i valori corretti di:
725
\begin{itemize}
726
\uncover<2->{\item Indirizzo IP mittente e destinazione}
727
\uncover<3->{\item Porta TCP mittente e destinazione}
728
\uncover<4->{\item Numero di sequenza corretto all'interno del flusso}
729
\end{itemize}
730
\uncover<5->{\item Un'attaccante che vuole interrompere una connessione
731
tra due macchine remote deve conosce gli IP, può indovinare le porte
732
(una è nota e l'altra predicibile), ma non può conoscere il numero di
733
sequenza corretto. Deve provare un \emph{Brute Force}.} 
734
\end{itemize}
735
\end{beamerboxesrounded}
736
}
737
}
738

    
739
\frame
740
{
741
\frametitle{Attacchi a livello IV:}
742
\begin{beamerboxesrounded}[shadow=true]{TCP reset Guess: qualche conto}
743
\begin{itemize}
744
\uncover<1->{\item Il numero di sequenza è un campo a 32 bit, quindi uno spazio
745
di $2^{32}=4,294,967,295$ cifre.} 
746
\uncover<2->{\item Il protocollo TCP però impone che per essere ricevuto
747
correttamente, un pacchetto di reset deve semplicemente cascare nella
748
finestra di ricezione valida della macchina sotto attacco . Una finestra di ricezione
749
può essere larga fino a $2^{16}$ bit.
750
\uncover<3->{\item Non c'è quindi bisogno di provare tutti i numeri di
751
sequenza, ma provando con numeri di sequenza distanti non più di $2^{16}$ si
752
è ragionevolmente sicuri di riuscire a interrompere la connessione.}
753
\uncover<4->{\item si ottiene che di $(2^{32}/2^{16})=2^{16}=65,535$ cifre.} 
754
\end{itemize}
755
\end{beamerboxesrounded}
756
}
757
}
758

    
759
\frame
760
{
761
\frametitle{TCP reset Guess: qualche conto}
762

    
763
Se un pacchetto TCP RST è composto da 20B di header IP + 24 di header TCP, abbiamo:
764
\begin{scriptsize}
765
\begin{table}[h]
766
  \begin{tabular}{|c|c|c|c|}
767
\hline
768
  Velocità upload & \# Pacchetti & Tempo per una porta \\
769
\hline
770
\hline
771
  256 kbps & 65,537 & $\approx$ 90s \\
772
\hline
773
  1 mbps & 65,537 & $\approx$ 20s \\
774
\hline
775
  32 mbps & 65,537 & $<$ 1s \\
776
\hline
777
  256 mbps & 65,537 & $<$ 1/10s \\
778
\hline
779
  \end{tabular}
780
\end{table}
781
\end{scriptsize}
782

    
783
Attacco realistico: fibra con 100 mbps di upload, finestra da 
784
}
785

    
786
\frame{
787
\frametitle{RWIN di default}
788
\scaledimg[0.8]{RWIN}
789

    
790
Misurati da cdnplanet nel 2011 (https://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/).
791
}
792

    
793

    
794

    
795
%
796
%
797
%\pgfdeclareimage[width=8cm]{rete}{images-intro/rete}
798
%\pgfdeclareimage[width=6cm]{retel}{images-intro/rete}
799
%%\pgfdeclareimage[width=8cm]{attack}{images-intro/attack}
800
%
801
%\subsection{DNS Poisoning}
802
%\frame{
803
%\frametitle{recall DNS}
804
%\bii
805
%\ii Ogni host deve poter risolvere un indirizzo di rete da una stringa
806
%alfanumerica (un dominio) ad un indirizzo IP. Questa operazione viene
807
%svolta con il protocollo DNS, Domain Name System.
808
%\ii Per ogni dominio in rete, esiste un server che può svolgere questo
809
%compito in modo \emph{autoritative}
810
%\ii L'indirizzo di un server \emph{autoritative} non è noto per ogni
811
%dominio a priori, quindi ogni host è configurato con un indirizzo di un
812
%server DNS locale
813
%\ii Il server DNS locale richiederà a dei root server l'indirizzo dei DNS
814
%validi per un certo dominio
815
%\ii Una volta realizzata la risoluzione nome/IP, il DNS locale mantiene
816
%l'associazione in una cache, per un certo periodo.
817
%\ei
818
%}
819
%
820
%\frame{
821
%\frametitle{recall DNS}
822
%\center\pgfuseimage{rete}
823
%
824
%}
825
%
826
%\frame{
827
%\frametitle{Attacchi sul DNS}
828
%\bii
829
%\ii In generale, un attacco su un DNS serve a far credere ad un certo host
830
%vittima che l'IP che corrisponde ad un nome di dominio è un IP diverso da
831
%quello originale.
832
%\ii Il protocollo DNS non utilizza forme di cifratura per proteggere i
833
%pacchetti, quindi si possono falsificare le risposte di un DNS server.
834
%\ii A cosa serve un attacco del genere?
835
%\bii
836
%\ii phishing, 
837
%\ii furto di credenziali
838
%\ii attacchi su home-banking
839
%\ii redirezione di connessioni e mitm in generale
840
%\ei
841
%\ei
842
%}
843
%
844
%\frame{
845
%\frametitle{DNS Attack}
846
%Dove può essere realizzato l'attacco?
847
%\begin{columns}
848
%\column{5cm}
849
%\bii
850
%\ii Nella rete locale
851
%\ii Nella richiesta da/verso il server DNS locale
852
%\ii Nella richiesta da/verso uno dei server authoritative
853
%\ei
854
%\column{6cm}
855
%\begin{center}
856
%\pgfuseimage{retel}
857
%\end{center}
858
%\end{columns}
859
%}
860
%
861
%\frame{
862
%\frametitle{DNS Attack - Layer II}
863
%\bii
864
%\ii Già abbiamo visto come a livello II si possono realizzare attacchi di
865
%tipo MITM su varie tecnologie:
866
%\bii
867
%\ii arp-spoofing per reti ethernet
868
%\ii attacchi sulle chiavi WEP per reti WiFi
869
%\ei
870
%Non è quindi sorprendente immaginare che lo stesso attacco possa essere
871
%utilizzato per modificare i pacchetti di:
872
%\bii
873
%\ii DHCP: assegnando ad un nodo della rete un nuovo indirizzo del server
874
%DHCP, controllato dall'attaccante
875
%\ii DNS responses: modificando i pacchetti che arrivano dal server DNS
876
%\ei
877
%\ei
878
%}
879
%\frame{
880
%\frametitle{DNS Attack - Layer III}
881
%\bii
882
%\ii Se l'attaccante è nel path tra il server DNS locale e quello remoto,
883
%l'attacco è banale
884
%\ii Altrimenti l'attaccante deve poter rispondere ad una richiesta DNS
885
%prima del server remoto pertinente.
886
%\ii Quali sono i campi interessanti di un pacchetto DNS?
887
%\bii
888
%\ii La porta UDP di origine e destinazione
889
%\ii L'IP di origine e destinazione
890
%\ii L'ID del pacchetto, ovvero un numero scelto a caso da chi invia la
891
%richesta che deve essere replicato nella risposta
892
%\ei
893
%\ei
894
%}
895
%\frame{
896
%\frametitle{DNS Attack - Layer III}
897
%\bii
898
%\ii Lo scopo dell'attaccante è quello di riuscire a inquinare la cache del
899
%server DNS locale, ovvero di rispondere al posto del server DNS remoto.
900
%\ii Per farlo, nel momento in cui il server DNS locale invia una richiesta
901
%per un dominio remoto l'attaccante deve rispondere con un pacchetto
902
%forgiato, che contenga le caratteristiche giuste:
903
%\bii
904
%\ii l'indirizzo IP sorgente $\rightarrow$ quello del server remoto
905
%(\alert{prevedibile})
906
%\ii la porta UDP sorgente $\rightarrow$ quella del server remoto
907
%(\alert{53})
908
%\ii l'indirizzo IP destinazione $\rightarrow$ quello del server locale
909
%(\alert{prevedibile})
910
%\ii la porta UDP destinazione $\rightarrow$ quella usata dal server locale
911
%per inviare la richiesta (\alert{non prevedibile?})
912
%\ii l'ID del pacchetto $\rightarrow$ quello del pacchetto di richiesta
913
%(\alert{non prevedibile!})
914
%\ei
915
%\ii Ci sono quindi due campi, entrambi di 16 bit (porta e ID) che
916
%potrebbero essere non prevedibili dall'attaccante 
917
%\ei
918
%}
919
%
920
%\frame{
921
%\frametitle{DNS Attack}
922
%\begin{center}
923
%\scaledimg[0.8]{DNS-attack}
924
%\end{center}
925
%}
926
%
927
%
928
%\frame{
929
%\frametitle{DNS Attack - due calcoli}
930
%\bii
931
%\ii 32 bit $\rightarrow$ $2^{32}$ possibilità 
932
%\ii $2^{32} \simeq$ 4 miliardi di pacchetti
933
%\ii L'attaccante, ammesso che sappia il momento in cui deve inviare la
934
%risposta fasulla, deve inviare prima del server remoto mediamente 2
935
%miliardi di pacchetti.
936
%\ii Se ogni pacchetto è lungo 80 byte, l'attaccante deve mandare 160GB di
937
%traffico prima che il server remoto possa rispondere.
938
%\ei
939
%}
940
%
941
%\frame{
942
%\frametitle{DNS Attack - restringiamo le ipotesi}
943
%\bii
944
%\ii Alcuni server DNS non utilizzano una porta casuale per inviare le
945
%richieste
946
%\bii
947
%\ii BIND sceglie una porta all'avvio e continua ad usarla
948
%\ei
949
%\ii una volta scoperta la porta rimangono $2^{16}$ bit da indovinare, che
950
%sono comunque $65000*80 \simeq 5MB$ da inviare in poche decine di
951
%millisecondi
952
%\ei
953
%}
954
%
955
%\frame{
956
%\frametitle{DNS Attack - restringiamo le ipotesi}
957
%\bii
958
%\ii Immaginiamo che l'attaccante (Eve) possa far iniziare la richiesta al server
959
%DNS (o è all'interno della rete, oppure il server DNS (Alice) accetta
960
%anche richieste dall'esterno)
961
%\ii A questo punto l'attaccante sa quando avverrà la richiesta:
962
%\bii
963
%\ii Eve invia ad Alice una richiesta per il dominio www.example.com
964
%\ii Alice reinvia la richiesta al server DNS di example.com (Bob)
965
%\ii Eve prova a rispondere prima di Bob, con un flood di n risposte fasulle
966
%\ei
967
%\ii quante probabilità ha di riuscire? $n/2^{16}$ ammesso che il server
968
%DNS riesca a elaborare tutte le risposte forgiate.
969
%\ii Ci può aiutare il paradosso del compleanno.
970
%\ei
971
%}
972
%\frame{
973
%\frametitle{DNS Attack - Bithday paradox}
974
%Una parentesi, il birthday paradox.
975
%\bii
976
%\ii Quale è la possibilità $P(n)$ che tra le persone in questa stanza ce ne siano
977
%due nate nello stessio giorno? Per calcolare questo valore si usa la
978
%probabilità inversa: 
979
%\bii
980
%\ii $\overline{P}(n)$ = \emph{probabilità che su n persone nessuna sia nata lo stesso giorno}
981
%\ii $\overline{P}(n) =
982
%\frac{364}{365}*\frac{363}{365}*\frac{362}{365}\ldots\frac{365-(n-1)}{365}$
983
%\ii Invertendo: $P(n) = 1-\overline{P}(n)$, che si può scrivere $P(n) = 1 - \prod_{i=1}^{(n-1)}\frac{365-i}{365}$.
984
%\ii Abbastanza sorprendentemente:
985
%\bii
986
%\ii per n=23 P(n) $\simeq$ 51\%, 
987
%\ii per n=30 P(n) $\simeq$ 70\%, 
988
%\ii per n=40 P(n) $\simeq$ 97\%, 
989
%\ei
990
%\ei
991
%\ei
992
%}
993
%
994
%
995
%\frame{
996
%\frametitle{DNS Attack - Bithday paradox}
997
%\bii
998
%\ii Come si applica il paradosso all'attacco di DNS poisoning?
999
%\ii Se Eve fa n richieste per l'host
1000
%www.example.com, Alice genererà un ID a caso tra 0 e $2^{16}$
1001
%per ognuna delle richieste verso Bob. Alice interromperà l'inivo delle richieste
1002
%quando riceverà almeno una risposta valida.
1003
%\ii Contemporaneamente Eve invierà un burst di risposte falsificate, con un ID scelto a caso.
1004
%\ii Se l'ID di almeno una di queste risposte false corrisponde con l'ID di
1005
%almeno una delle richieste inviate (e viene ricevuta prima di quella
1006
%di Bob) allora Alice avrà nella cache un entry
1007
%per www.example.com 
1008
%\ii Statisticamente, per il paradosso del compleanno, inviando 700
1009
%richieste/risposte si ha ua probabilità vicina al 100\% di indovinare
1010
%almeno una risposta. 
1011
%\ii In questo modo la cache rimane inquinata e tutte le richieste
1012
%successive verranno redirette verso l'host controllato da Eve.
1013
%\ei
1014
%}
1015
%
1016
%\frame{
1017
%\frametitle{DNS Attack - Conclusioni}
1018
%\bii
1019
%\ii Fare poisoning di un server DNS è in linea teorica possibile ma molto
1020
%difficile,
1021
%\ii Sotto opportune ipotesi però l'attacco è perfettamente realizzabile
1022
%con dei mezzi a disposizione di chiunque
1023
%\ii L'attacco può essere reso più facile se il server DNS originario (Bob)
1024
%è sotto un attacco di DoS, quindi non risponde prontamente
1025
%\ii Per evitare che l'attacco sia applicabile è importante scegliere bene
1026
%gli applicativi che si usano, avendo la certezza, ad esempio, che
1027
%utilizzino porte sorgenti casuali.
1028
%\ei
1029
%}
1030

    
1031