Arbor networks peakflow tms
Upcoming SlideShare
Loading in...5
×
 

Arbor networks peakflow tms

on

  • 1,242 views

 

Statistics

Views

Total Views
1,242
Views on SlideShare
1,242
Embed Views
0

Actions

Likes
0
Downloads
43
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Per capire a cosa stiamo andando incontro è opportuno analizzare qualche dato,

Arbor networks peakflow tms Arbor networks peakflow tms Presentation Transcript

  • Arbor Networks Peakflow SA TMS (ver 0.3) Luigi Chiandetti
  • Peakflow SP TMS
    • Il TMS può essere configurato in modalità stand alone, in quel caso si fa riferimento al dispositivo con il nome Peakflow SA TMS
    • Peakflow SA TMS è stata progettata per essere utilizzata nei seguenti scenari:
      • Come replacement per i Cisco Guard, nel caso il cliente avesse già una struttura anti DoS che utilizzano l’architettura Cisco per effettuare mitigation, il peakflow SA TMS risulta essere il sostituto naturale a questa tecnologia.
      • Provider e Data Center di medie/piccole dimensioni, questi customers richiedono meno funzionalità e principalmente costi più ridotti rispetto a quelli forniti dai prodotti di punta di Arbor Networks, quali per esempio il peakflow SP, ma nonostante ciò forniscono un modo potente e versatile per contrastare attacchi di tipo DoS e DDoS
  • Configurazione hardware adottata: In-line
    • La configurazione adottata in laboratorio è quella In-line.
    • Il TMS viene posto tra la sorgente e la destinazione, e funziona come uno smart cable, non c’è bisogno di configurare un indirizzo ip (se non quello di management) e non richiede l’utilizzo del BGP.
    • Deve essere fatto il mapping delle porte di ingresso e di uscita del peakflow SA TMS
    • Lo schema generico per una configurazione In-line è il seguente, la destinazione è messa subito dopo l’appliance e si preoccuperà di mitigare un eventuale attacco, bloccando il traffico specificato nella fase di configurazione delle mitigation.
  • Componenti LAB
    • Teconologia Arbor da testare:
      • Peakflow SA TMS 1200 v5.5.p1 (192.168.80.252)
    • Attacker:
      • OS: Backtrack 4 R2 (192.168.80.247)
      • Tool per simulare l’attacco:
        • Packit (generatori di pacchetti)
        • Hping3 (generatori di pacchetti)
    • Target:
      • OS: Backtrack 4 R2 (192.168.80.218)
      • Servizi attivi:
        • Server WEB (por 80)
    • Client
      • Simulerà il normale utilizzo di un server web
      • Richieste pagine web, download/upload file
  • Peakflow SA TMS Hardware view
    • mgt0 : ip 192.168.80.252 interfaccia per la management da CLI e da UI (https)
    • tms0 : interfaccia d’ingresso (punto di ingresso del traffico diretto al pc target)
    • tms1 : interfaccia di uscita (dove è attaccato il pc target)
  • Schema del LAB: configurazione inline tms0 : Intefaccia ingresso peakflow tms1: Intefaccia uscita peakflow Client 10.3.254.18
  • Configurazione Arbor Peakflow SA TMS 1/2
    • Step 1 : configurazione del Management:
      • / ser tms sp_management disable
        • È necessario dire al TMS che non è gestito da un SP e verifichiamo con il comando #ser tms sp_management show
    • Step 2 : Configuriamo il tipo di Deployment
      • / ser tms dep mod set inline
        • Con questo comando impostiamo il TMS in modalità inline
    • Step 3 : Definire il numero di mitigation sul dispositivo (max 25 TMS 1200 )
      • / services tms deployment limits mitigation set 25
    • Step 4 : Configurare il TMS per reagire ai fallimenti
      • / ser tms dep failure
        • Comando generale che ci permette di configurare l’appliance in modo da gestire le mitigation in esecuzione in caso si verifichino dei fallimenti a degli specifici componenti quali: BGP, GRE Tunnel, Interface, next hop. (nel nostro caso sono configurati per stoppare la mitigation, l’altra opzione è per far continuare la mitigation)
  • Configurazione Arbor Peakflow SA TMS 2/2
    • Step 5 : impostiamo le intefacce dell’appliance
      • / ser tms deployment interfaces modify tms0 capabilities mitigation enable
      • / ser tms deployment interfaces modify tms0 output set tms1
        • Abbiamo abilitato le mitigation sull’interfaccia tms0 dell’arbor e abbiamo mappato l’ingresso (tms0) con l’uscita (tms1)
  • Altri comandi utili per la gestione
    • Abilitare la shell per la modalità DIAG>
      • / system attributes set shell.enabled = 1
    • Attivare la modalita DIAG (il prompt dei comandi passa da # a DIAG>)
      • / shell
    • Salvere la configurazione
      • / config write
    • Trasferire file da e verso il Peakflow SA TMS (vanno eseguiti una volta entrati in modalità DIAG>)
      • scp FileSorgente nomeUtente@host:directory/FileDestinazione
      • scp nomeUtente@host:directory/FileSorgente FileDestinazione
    • Per abilitare la subnet (o indirizzo) sui Peakflow, vanno eseguiti i seguenti comandi sulle macchine a cui volete accedere (come minimo almeno sul Leader):
      • / ip access add ssh all <vostro_ip/subnetmask>
      • / ip access add https all <vostro_ip/subnetmask > (solo sui Leader)
      • / ip access commit
  • Intefaccia web del TMS SA 5.5 sp1 Summary Intefaccia ingresso tms0 Intefaccia di uscita tms1 Gestione delle mitigation Pannello di amministrazione del sistema Stato delle interfacce del TMS
  • Intefaccia web del TMS SA 5.5 sp1 Mitigation>List Mitigation Lista delle Mitigation create Stato del sistema Comandi per gestire le mitigation in particolare avviare/stoppare
  • Aggiungere una Mitigation Mitigation>add mitigation Passi da seguire per configurare una mitigation: 1- nome mitigation e prefisso da proteggere 2- selezionare interfaccia 3- configurare le contromisure Interfacce del TMS nel nostro caso tms0 (ingresso), tms1 (uscita verso il Target) L’interfaccia che va spuntata è quella relativa all’ingresso del traffico nel nostro caso tms0
  • Aggiungere una Mitigation Mitigation>add mitigation>countermeasures Immagine non completa sono disponibili ulteriori opzioni Note: è possibile configurare, le mitigation per essere stoppate nel caso si rinscontrasse qualche anomalia nel sistema (vedi step 4 pag. 7). È possibile startare un sola mitigation sullo stesso prefisso, mentre sono consentire mitigation diverse su prefissi diversi. I parametri posso essere modificati anche in real time mentre la mitigation sta operando Attiva/Disattiva
  • Intefaccia web del TMS SA 5.5 sp1 Mitigation>View Mitigation Nome mitigation Prefisso da proteggere Pannello per la configurazione dei parametri delle mitigation Riassunto sul traffico passed/droped Flusso del traffico
  • Intefaccia web del TMS SA 5.5 sp1 Mitigation>Sample Packets Informazioni sui pacchetti droppati Pacchetti droppati Info pacchetto
  • Intefaccia web del TMS SA 5.5 sp1 Administrator>Configure general panel Pannello di configurazione del sistema Opzioni varie, visualizzazioni log, creazione account, configurazione degli alerts, etc
  • Struttura del Test
    • Fase 1: Configurazione
      • Configurazine mitigations web_test per bloccare potenziali attacchi DoS indirizzati al protocollo http (porta 80) della macchina Target (192.168.80.218)
    • Fase 2: Attacco – Mitigation off
      • Mitigations settata su STOP per vedere gli effetti che si hanno sul Target senza il filtraggio attivo del TMS durante l’attacco.
      • Tool di attacco:
        • Hping3
        • Packit
        • (suggerimenti di tool per test…)
    • Fase 3: Attacco – Mitigation ON
      • Mitigations settata su START per vedere come viene effettuato il filtraggio da parte del TMS e di conseguenza il nostro Target
      • Stessa tipologia di attacco della Fase 2
  • Configurazione Mitigations
  • Mitigation 1/2
    • Il nostro intento sarà quello di configurare una mitigation in grado di bloccare potenziali attacchi diretti verso un server web lasciando pero passare il traffico ritenuto non dannoso, evitando cosi di chiudere le “porte” ad eventuali richieste legittime al nostro server web.
    Mitigation OFF Traffico consentito Traffico da mitigare Mitigation ON
  • Mitigation 2/2
    • Peakflow TMS utilizza i seguenti tipi di contromisure:
      • Per-packet : queste contromisure sono applicate ad ogni pacchetto che corrisponde al prefisso a cui è associata la mitigation e sono le seguenti (sono processate prima delle Event-driven ):
        • Invalid Packets
        • Zombie Removal
        • Payload Regular Expression
        • TCP SYN Authentication
        • DNS Aut.hentication
      • Event-driven: questo tipo di contromisura è divisa nei seguenti gruppi
        • Application-specific stream-based, il TMS identifica il traffico con un id prima di applicare la contromisura
        • Time-based, viene utilizzato un timer per decidere come comportarsi con un determinato flusso di dati, es. droppa il traffico quando una connessione rimane idle per troppo tempo
    • Note: Dynamic Blacklisting, quando viene incontrato del traffico considerato pericoloso, viene droppato e viene messa in una blacklist l’host sorgente per la durata di un minuto, durante questo periodo tutto il traffico (sia legittimo che non), proveniente da quell’host viene scartato. Allo scadere del timer il TMS riabilita la sorgente viene tolta dalla blacklist (per maggiori informazioni fare riferimento manuale arbor networks peakflow TMS configuration and user guide ver. 5.5).
  • Parametri Mitigation mitigation name: web_test
    • I parametri abilitati nella mitigation web_test sono i seguenti:
      • Zombie Detection (parametri di default ) : utilizza dei parametri di soglia per identificare e bloccare gli host che mandano eccessive quantità di traffico verso la rete sotto protezione (nel nostro caso il Target). Protegge contro, Flood, TCP SYN.
      • TCP SYN Authentication: intercetta ed autentica tutto il traffico TCP in arrivo, verifica che il Three way hand-shake sia completato. Protegge contro, TCP SYN flood, ed altri TCP flag attack quali, ACK flood o altre combinazioni di flag. In questi tipi di attacchi si punta a consumare le risorse del Target. La sorgente non viene messa in blacklist.
      • TCP Connection Reset: traccia le connessioni TCP stabilite e blocca il traffico quando la connessione rimane inattiva per troppo tempo. Un host che vuole aprire una connessione dati deve inviare una specifica quantità di payload all’interno di un determinato lasso di tempo. L’host sorgente che non manda la specificata quantità di payload viene messo in blacklist.
      • Malformed HTTP Filtering: filtra il traffico HTTP che non rispetta le specifiche imposte dallo standard RFC. Protegge contro quegli attacchi che mandano richieste vuote o invalide verso un server per saturare le risorse o exploitare le eventuali vulnerabilità. In caso di non conformità l’host sorgente viene messo in blacklist e i pacchetti scartati.
      • HTTP Rate Limiting: limita il rate con cui un host può mandare richieste HTTP. Protegge contro il sovraccarico delle risorse di un web server dovuto alla ricezione di troppe richieste.
  • Attacco: Analisi e Considerazioni
  • Attacco #1 con Mitigation “Stopped”
    • Packit command:
      • packit -t tcp -c 0 -d &quot;192.168.80.218&quot; -D 80 -w .1 -b 1 -F S
    Inizio attacco L’interfaccia verso il Target viene messa Down dal sistema ed il server web diventa irragiungibile L’attacco lanciato è del tipo syn flood Viene visualizzato un alert
  • Analisi dell’attacco (mitigation OFF)
    • Lato Attaccante
      • packit -t tcp -c 0 -d &quot;192.168.80.218&quot; -D 80 -w .1 -b 1 -F S
          • Attacco di tipo SYN Flood
          • -t tcp inviamo pacchetti TCP
          • -c 0 indica di mandare pacchetti all’infinito (diversamente si può specificare il numero)
          • -w .1 –b 1 indica intervallo e burst rate
          • -F serve a selezionare i flag attivi nel header TCP in particolare con S si indica il flag SYN è l’opzione fondamentale che specifica il tipo di attacco syn flood .
          • -sR (spoofing) abilitiamo l’invio di pacchetti da sorgenti random (non attivata in questo attacco)
          • -d indica la destinazione
          • Injected: 3899824 Packets/Sec: 35452.104 Bytes/Sec: 1418117.90 Errors: 0
    • Lato Target
      • tcpdump -n tcp port 80 -w traffic_p80_RAW.txt
        • Catturiamo i pacchetti destinati alla porta 80 per vedere che tipo di traffico viene generato da e verso il Web Server
        • ^C100792 packets captured -- 100792 packets received by filter
  • Considerazione sulla prima fase di attacco (mitigation OFF) 1/3
    • Lanciando l’attacco verso l’obietto con le mitigation non startate ho notato che dopo qualche secondo l’interfaccia verso l’obiettivo ossia la tms1 del peakflow SA TMS viene messa down, impedendo cosi al traffico di arrivare al server web ma bloccando di fatto l’accesso al sito.
    • Note : non mi aspettavo che l’interfaccia tms1 venisse messa DOWN dal sistema (fare riferimento alla slide successiva per un ulteriore considerazione).
    • Esito attacco:
    • NB: l’esito dell’attacco è stato conseguenza del anomalo funzionamento del TMS ha messo down l’interfaccia di uscita verso il server web
    D.o.S Riuscito !!!
  • Considerazione sulla prima fase di attacco (mitigation OFF) 2/3
    • Interfaccia TMS Down  implicazioni
      • Su che base viene presa questa decisione dal TMS (intefaccia tms1 down)?
      • E se il target dall’altra parte fosse stato in grado di gestire i 30 Mbps (scarsi) di traffico (screenshot pg 17) generati dall’attacco o eventualmente fosse in grado di gestire un attacco Syn Flood cosa oramai frequente nei nuovi web server.
      • E se al posto di un solo pc ci fosse stato un segmento di rete collegato all’interfaccia tms1, si sarebbe bloccato tutto il traffico verso quella parte di rete generando di fatto un DoS di proporzioni maggiori rispetto alle intenzioni dell’attacco visto che era diretto verso un Host specifico.
      • In un secondo tentativo di attacco ho notato che la porta tms1 dopo essere stata messa down, viene riattivata per qualche secondo e poi nuovamente impostata su down.
  • Considerazione sulla prima fase di attacco (mitigation OFF) 3/3
    • Analizzando i Log del TMS
      • / services logging view syslog tail 100
      • L’opzione tail server a visualizzare le ultime righe del log
    Messaggio di errore del TMS
  • Attacco #1 con Mitigation “Started” (mitigation utilizzata: web_test)
    • Packit command:
      • packit -t tcp -c 0 -d &quot;192.168.80.218&quot; -D 80 -w .1 -b 1 -F S
    Cambiando questo parametro da quello di default 100000 a 200000 siamo riusciti a fare un upload senza che il TMS bloccasse anche il client Possiamo vedere il traffico bloccato e quello lasciato passare dalla mitigation
  • Considerazione sulla seconda fase di attacco (mitigation ON) 1/2
    • L’interfaccia tms1 che prima veniva posta down dal TMS ora rimane in up e il traffico fluisce normalmente tra le due interfacce dell’appliance.
    • Una volta lanciato l’attacco con la mitigation startata e configurata con i parametri descritti nelle slide precedenti il comportamento del TMS è quello che ci aspettavamo, l’interfaccia tms1 che prima veniva posta down dal TMS ora rimane in up e il traffico fluisce normalmente tra le due interfacce dell’appliance, il traffico sospetto viene bloccato mentre le normali richieste alle pagine web del server Target sono consentite, rendendo possibile la navigazione web.
    • Nota: client  effettua un upload (file 3 MB circa)
      • Se da una semplice richiesta di una pagina web proviamo a fare un upload sul server Target , la situazione cambia, il TMS dopo un minuto circa di traffico in upload da parte del Client(ossia il pc che genera traffico lecito) , blocca anche quest’ultimo.
    • Cambiando un parametro nelle configurazioni delle mitigation ( zombie detection>Zombie bits per second threshold = 200000 ) riusciamo a ristabilire il normale funzionamento, anche il traffico in upload viene consentito.
  • Considerazione sulla seconda fase di attacco (mitigation ON) 2/2
    • Altra soluzione testata e funzionante correttamente è disattivare definitivamente l’opzione Zombie detection, l’attacco verrà comunque filtrato dal’opzione TCP SYN Authentication, (vedere riferimento slide precedenti).
  • Attacco #2 con Mitigation “Started” (mitigation utilizzata: web_test)
    • Scopo dell’attacco: inibire l’accesso al web server da parte del client.
    • Packit command:
      • packit -t tcp -c 0 -s &quot;10.3.254.18&quot; -d &quot;192.168.80.218&quot; -D 80 -w .1 -b 1 -F S
        • Con l’opzione –s <ip _client> effettueremo un attacco spoofando l’indirizzo ip sorgente.
    Sor: 10.3.254.18 Dest: 192.168.80.218
  • Considerazione sulla seconda fase di attacco (mitigation ON) D.o.S Riuscito !!! Esito attacco:
  • Tipologie di Attacco (brevi note)
    • SYN Flood: wikipedia
  • Pagina degli update
    • Ver 0.3
      • Modificata pag. 6, 9, 25
      • Aggiunta pag. 27, 30, 31, 32
      • Cancellata pag 31 e spostata in 28
    • Ver 0.2
      • Modificata pagina 4, 6, 18
      • Aggiunta pagina 19, 20 e 27
    • Ver 0.1.1
      • Aggiunte slide 12, 13 e 22
    • Ver 0.1
      • creazione slide da 1 a 21 (pagina update esclusa)