Revision a58010e4 body.tex

View differences:

body.tex
18 18
\begin{beamerboxesrounded}[shadow=true]{Jamming}
19 19
\begin{itemize}
20 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 com cavi non
21
permette, come nel caso di reti wireless o reti wired con cavi non
22 22
schermati}
23 23
\uncover<2->{\item anche se il jamming è difficile, basta far
24 24
fallire la ricezione di un bit per invalidare il checksum e far scartare
......
28 28
}
29 29

  
30 30

  
31
\pgfdeclareimage[height=4cm]{switched-net}{images-intro/switched-net}
32
\pgfdeclareimage[height=4cm]{arp-1}{images-intro/arp-1}
33
\pgfdeclareimage[height=4cm]{arp-2}{images-intro/arp-2}
34
\pgfdeclareimage[height=4cm]{arp-3}{images-intro/arp-3}
35
\pgfdeclareimage[height=4cm]{arp-4}{images-intro/arp-4}
36
%\pgfdeclareimage[height=4cm]{arp-fields}{images-intro/arp-fields}
37

  
38 31
\frame
39 32
{
40 33
\frametitle{Attacchi al livello di collegamento}
......
55 48
\uncover<1->{\item un flood può essere mirato alla saturazione della
56 49
banda.}
57 50
\uncover<2->{\item se il mezzo è condiviso si possono non rispettare i
58
tempi di timout e creare numerose collisioni, oppure mantenere il canale
51
tempi di timeout e creare numerose collisioni, oppure mantenere il canale
59 52
sempre occupato}
60 53
\uncover<3->{\item un flood può essere mascherato inviando pacchetti con
61 54
indirizzo mittente modificato}
......
200 193
\begin{frame}
201 194
\frametitle{ARP spoofing: dettagli}
202 195
\bi
203
\ii Alla fine dell'attacco Alice e Bob possono mantenere delle connsessioni funzionanti che vengono in realtà analizzate da Eve
196
\ii Alla fine dell'attacco Alice e Bob possono mantenere delle connessioni funzionanti che vengono in realtà analizzate da Eve
204 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.
205 198
\ei
206 199
\end{frame}
......
210 203
\bi
211 204
\ii Che succede se per qualche motivo Alice deve mandare un pacchetto ad un quarto host?
212 205
\ii Alice invia una nuova richiesta ARP in broadcast, e corregge la tabella ARP di Bob
213
\ii Perchè l'attacco sia efficace, Eve deve mandare continuamente pacchetti ARP modificati per continuare a mantenere inquinate le tabelle ARP delle vittime.
206
\ii Perché l'attacco sia efficace, Eve deve mandare continuamente pacchetti ARP modificati per continuare a mantenere inquinate le tabelle ARP delle vittime.
214 207
\ei
215 208
\end{frame}
216 209

  
217
\begin{frame}
218
\frametitle{}
219
\bi
220
\ii 
221
\ei
222
\end{frame}
223 210

  
224
\begin{frame}
225
\frametitle{}
226
\bi
227
\ii 
228
\ei
229
\end{frame}
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
}
230 222

  
231
\begin{frame}
232
\frametitle{}
233
\bi
234
\ii 
235
\ei
236
\end{frame}
223
\subsection{Fragmentation attacks}
224
\frame
225
{
226
\frametitle{Fragmentation attacks}
237 227

  
238
\begin{frame}
239
\frametitle{}
240
\bi
241
\ii 
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
  }
242 324
\ei
243
\end{frame}
325
}
244 326

  
245
\begin{frame}
246
\frametitle{}
247
\bi
248
\ii 
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}
249 375
\ei
250
\end{frame}
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
}
251 572

  
252 573
\begin{frame}
253
\frametitle{}
254
\bi
255
\ii 
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
256 579
\ei
257 580
\end{frame}
258 581

  
582

  
583

  
259 584
\begin{frame}
260
\frametitle{}
261
\bi
262
\ii 
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
263 590
\ei
264 591
\end{frame}
265 592

  
266
\begin{frame}
267
\frametitle{}
268
\bi
269
\ii 
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
270 688
\ei
271
\end{frame}
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
}
272 698

  
273
\begin{frame}
274
\frametitle{}
275
\bi
276
\ii 
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 
277 713
\ei
278
\end{frame}
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

  

Also available in: Unified diff