Docs - traduzioni
Un documento su smurf di Craig A. Huegen
 

L'ULTIMO DEGLI ATTACCHI "DENIAL OF SERVICE":
DESCRIZIONE DELLO "SMURFING"
E INFORMAZIONI PER MINIMIZZARNE GLI EFFETTI

Craig A. Huegen
chuegen@quadrunner.com

Ultimo aggiornamento Martedì 8 febbraio 17:47:36 PST 2000
Aggiunte:
*Rimossa la sezione "aggiornamento sullo smurf" -non più valida dati i Dos distribuiti
Richiesta per l'editore: per favore distribuisci questa informazione gratis tenendo fede ai requisiti della mia ridistribuzione (guarda alla fine). E' importante che questi attacchi siano minimizzati e la comunicazione è l'unico modo per aiutare a farlo.

INTRODUZIONE:

L'informazione qui fornita riguarda gli attacchi "smurf" e i "fraggle", si pone particolare attenzione ai routers Cisco e a come si possano ridurre gli effetti di tali attacchi. Le informazioni sono generali e non in relazione ad un particolare venditore di un'organizzazione scelto; anche se lo scritto riguarda i routers Cisco. Nessuna verifica è stata fatta degli effetti sulle macchine di altri venditori; comunque altri mi hanno fornito informazioni sui vari venditori, che sono state messe in questo documento.
Vedere la sezione "Acknowledgemets" per le informazioni sulle fonti e i contatti. Sono lieto di avere informazioni da altri colleghi o altri venditori che desiderano fornirne riguardo argomenti inerenti a questo tema.

Aggiorno sempre questo documento non appena ricevo ulteriori informazioni inerenti gli attacchi e le maniere per minimizzarne gli effetti.

DESCRIZIONE

L'attacco "smurf" è uno dei più recenti nella categoria degli attacchi a livello network contro hosts.
Un attaccante manda una grande quantità di traffico echo (ping) a indirizzi IP broadcast, tutti aventi come sorgente l'indirizzo "spoofed" della vittima. Se il router che smista traffico verso quegli indirizzi broadcast, esegue la funzione broadcast ip --> broadcast di layer 2 descritta sotto, la maggioranza degli hosts su questa IP network, riceverà la richiesta echo ICMP e risponderà ad ognuna , moltiplicndo il traffico per il numero di hosts che rispondono. Su una rete broadcast multi-accesso, ci potrebbero essere potenzialmente centinaia di macchine che rispondono a ogni pacchetto.

Il cugino dell'attacco "smurf" si chiama "fraggle", usa i pacchetti echo UDP nella stessa maniera dei pacchetti echo ICMP; è una semplice riscrittura dello "smurf".

Di solito, i providers/macchine più comunemente colpiti sono gli IRC servers e i loro providers.

Ci sono due parti che sono colpite da questo attacco ....le macchine intermediarie (broadcast) - chiamiamole "amplificatori", e il bersaglio indirizzo spoofed, o la vittima. La vittima è il bersaglio di una gran quantità di traffico generato dagli amplificatori.

Consideriamo uno scenario per avere un'immagine della natura del danno di questo attacco. Prendiamo una rete "co-location switched" con 100 hosts, e ipotizziamo che l'attaccante ha una T1. L'attaccante manda, per esempio una fiumana di pacchetti echo ICMP (ping ) a 768kb/s, con l'indirizzo sorgente spoofed della vittima, all'indirizzo broadcast di un "bounce site". Questi pacchetti colpiscono la rete broadcast del "bounce site" di 100 hosts, a ognuno di questi arriva il pacchetto e risponde ad esso, creando 100 risposte ping verso l'esterno. Se si moltiplica la larghezza di banda, si vede che 76.8 Mbp/s sono usati verso l'esterno dal "bounce site" dopo che il traffico si è moltiplicato. Questo è mandato alla vittima ( l'intestatario spoofed che ha originato i pacchetti)

COME SI DETERMINA SE UNA RETE E' VULNERABILE

Si sono fatti molti siti per fare lo scanning attivo e passivo delle reti per determinare se il directed-broadcast è abilitato o meno.

http://www.netscan.org/ è un sito che attivamente fa lo scan dello spazio di indirizzo Ipv4 e spedisce contatti network con le informazioni su come disabilitarli. ??? (is a site which actively scans the IPv4 address space and mails network contacts with information on how to disable them).

http://www.powertech.no/smurf/ è un sito che testa la tua rete e ti permette di entrare in un sito conosciuto amplificatore di smurf.

COME EVITARE CHE IL TUO SITO SIA SFRUTTATO DAGLI ATTACCANTI PER PERPETRARE I LORO ATTACCHI.

Gli attaccanti si basano sulla capacità di generare pacchetti "spoofed" per gli amplificatori in modo da generare il traffico che crea il Dos.

Per fermarlo tutte le reti dovrebbero usare il filtraggio sia all'interfaccia della rete dove i clienti si connettono (livello di accesso) sia nll'interfaccia di connessione con i providers, a livello superiore, in modo da distruggere la possibilità che i pacchetti di indirizzo "spoofed" intestatari entrino dalla rete a livello inferiore o escano a livello superiore.

Paul Ferguson del Cisco Systems e Daniel Senie di Blazenet hanno scritto un RFC riguardo a questo argomento. Vedere:
ftp://ftp.isi.edu/in-notes/rfc2267.txt
per maggiori informazioni ed esempi su questo argomento.

In più, i venditori di router hanno aggiunto o stanno aggiungendo opzioni di impedire di spoofare gli indirizzi IP degli intestatari controllando l'indirizzo intestatario del pacchetto rispetto alla tabella di routing per assicurare che il percorso di ritorno del pacchetto avvenga attraverso l'interfaccia su cui era stato ricevuto.

Cisco ha aggiunto questa possibilità all'attuale 11.1CC branch, usato da molti NSP, in un comando di interfaccia: '[no] ip verify unicast reverse-path'.

COME IMPEDIRE DI ESSERE INTERMEDIARIO

Questo attacco fa affidamento su un router che serve una grande rete broadcast multiaccesso per formare un indirizzo IP bradcast (come 10.255.255.255) in un frame broadcast di layer 2 (?This attack relies on the router serving a large multi-access broadcast network to frame an IP broadcast address) (per Ethernet, FF:FF:FF:FF:FF:FF). RFC 1812, "Requirements for IP Version 4 Routers", sezione 5.3.5, specifica:
Un router PUO' avere un'opzione per disabilitare broadcast diretti a prefisso di rete (network-prefix-directed broadcast) in ingresso su un'interfaccia e DEVE avere un'opzione per disabilitare broadcast diretti a prefisso di rete (network-prefix-directed brooadcasts) in uscita. Queste regole non devono impedire di ricevere e spedire broadcasts diretti a prefisso di rete .

Generalmente con applicazioni IP come quelle di oggi questo comportamento non è necessario e ci si raccomanda che il broadcast diretto sia disabilitato per impedire gli effetti di questo attacco.

RCF 2644, la migliore pratica RFC attuale secondo Daniele Senie, aggiorna la RFC 1812 per stabilire che il software del router non deve impedire di negare il ricevere e spedire broadcasts diretti.

L'hardware NIC Ethernet ( l'hardware livello-MAC) ascolterà solo un numero selezionato di indirizzi in una normale operazione. Il primo indirizzo MAC che tutte le macchine hanno in comune in una normale operazione è il broadcast di comunicazione, o FF:FF:FF:FF:FF:FF. Se una macchina riceve un pacchetto destinato a un indirizzo broadcast link-layer, prenderà il pacchetto e manderà un interrupt per processarlo tramite le procedure di più alto layer.

Per fermare un router Cisco dal convertire i broadcasts di layer 3 in broadcast di layer 2, si usa il comando di configurazione di interfaccia "no ip directed broadcast". Questo deve essere configurato su ogni interfaccia di tutti i router.

Come per una versione 12.0 IOS Cisco, la "no ip directed-broadcast" è la norma, in modo da proteggere le reti di default, l' "ip directed-brodcast" sarà necessario se la rete ha bisogno di broadcasts diretti per essere abilitatata.

Altre informazioni:

* Proteon/OpenRoute
Daniel Senie (dts@senie.com) riporta che i routers di reti Proteon (OpenROUTE) hanno un'opzione per impedire il broadcast diretto nel menu di configurazione IP. La sequenza di comandi per attivarla è:
*CONFIG (sui routers più nuovi) o TALK 6 (sui routers più vecchi)
Config>Protocol IP
IP Config>DISABLE DIRECTED-BROADCAST
E' necesario riavviare il router.

** Nortel Networks (Bay Networks):
Jon Green (jcgreen@netins.net) riporta che il bugID CR33408 somma l'abilità di disabilitare i broadcast network-directed che iniziano nella versione 12.01 rev 1 del codice BayRS.
Per disabilitarl, digita:
[1:1]$bcc
bcc> config
hostname# ip
ip# set directed-bcast disabled
ip# exit
da notare che questo è rimbalzato su tutte le interfaccia IP.

Greg Hankins (ghankins@mindspring.net) riporta che a partire dalla versione 13.01, il directed-broadcast è disabilitato di default.

Tim Winders (twinders@SPC.cc.tx.us) dice che se si aggiorna la BayRS dalla 12.01 alla 13.01, i directed-brodcast non sono disabilitati.

* Prodotti 3Com NETBuilder:
Mike Kouri (Mike_Kouri@3com.com) riporta che tutte le NETBuilters 3Com hanno un'opzione per impedire al router di rispedire i directed-brodcasts. La sequienza di comandi per disabilirtare il forward è:
SETDefault -IP CONTrol = NoFwdSubnetBcast
In più i prodotti 3Com NETBuilder che hanno una versione a partire dalla 9.1 possono essere configurati per scaricare i pacchetti con intestatario spoofed:
SETDefault !port -FireWall CONTrol = (Filter, DenySrcSpoofing)
3Com afferma nella pagina web (elencata sotto) che questo comando "specifica se i pacchetti sono soggetti a controlli di intestatari -spoofing . Questa è un'opzione che implica un uso intenso della CPU e generalmente si ha una riduzione di performance. Bisogna disabilitare questa opzione tranne che per quelle interfacce che ricevono traffico esterno non fidato.
Gli indirizzi intestatari dei pacchetti in ingresso sono testati rispetto alla tabella di routing. Se le informazioni di routing mostrano che l'indirizzo intestatario è irraggiungibile, o raggiungibile su differenti interfacce allora è un attacco SrcSpoofing".

*Lucent (Ascend):
Will Pierce (willp@dreamscape.com) dice che su Maxes o Pipelines che girano con TAOS a partire dallla versione 6.0, si può andare al menu di configurazione Ethernet->Mod e settare entrambi "Reply DirectedBcast Ping" e "Forward Directed Bcast" a "No" . Per il Max TNT c'è un esempio a:
ftp://ftp.ascend.com/pub/Software-Releases/MaxTNT/Release-2.0.X/2.0.0/doc/tnt20.pdf a pagina 40 dalla versione TNT 2.00 ciò è supportato.

* Cabletron SmartSwitch Router (Yago/SSR):
Greg Hankins (ghankins@mindspring.net) dice che il directed-broadcast è disabilitato di default, e può essere abilitato grazie al comando globale " ip enable directed-broadcast".

* Foundry Networks:
Greg Hankins (ghankins@mindspring.net) dice che l'hardware che gira con il software di routing di Foundry può essere configurato per disabilitare i directed-broadcasts con il comando globale o per intefaccia " interface no ip directed-broadcast".

* Redback Networks:
Justin Streiner (streiner@stargate.net) dice che sugli switches di accesso SMS-500 e SMS-1000, non c'è il supporto per i directed-broadcasts a meno che usati in unione con DHCP e non siano rispediti di default.

* Extreme Networks:
Aurobindo Sundaram (sundaram@austin.apc.slb.com) dice che si può disabilitare il forwarding IP broadcast sugli switches Summit 1 di Extreme usando i seguenti comandi:
disable ipforwarding broadcast all
disable ipforwarding broadcast vlan vlan-name

* ArrowPoint Communications:
Greg Hankins (ghankins@mindspring.net) dice che il directed-broadcast può essere disabilitato usando il comando di configurazione globale "no ip subnet-broadcast".

* SGI IRIX as a router:
Mike O'Connor (mjo@dojo.mi.org) dice che IRIX è stato configurato di default per non forwardare i broadcasts diretti quando usato come router. Il comando per questo è in /var/sysgen/master.d/bsd..

C'è uno studio di un caso dove questo fermerà il comportamento voluto: in caso dove samba (un server SMB per UNIX) o NT è usato come "remote broadcast" in un workgroup di una LAN in maniera tale che le workstation sulla LAN possono vedere il server, questo impedirà alle macchine della LAN di vedere il server remoto. Questo è * solo* nel caso non esistono server WINS ( WINS è "routed unicast") ed è usato un "remote broadcast" - è una rara ma condizione degna di nota.

(Nota dell'editore: è benvenuto ogni commento come qualunque cosa d'altro che spacca senza il supporto del broadcast-diretto)

In più, gli hosts possono essere pecciati per rifiutare di rispondere ai pacchetti echo ICMP bradcasted. RCF 1122 "Requirements for Internet Host - Communicaions Layer" sezione 3.2.2.6 dice:

Una richiesta echo ICMP destinata a un broadcast IP o a un indirizzo multicast IP può essere tacitamente scaricata.

DISCUSSIONE:

Questo provvedimento neutrale è il risultato di un appassionato dibattito fra coloro che sostengono che l'echo ICMP a un indirizzo broadcast fornisce una capacità diagnostica preziosa e quelli che sostengono l'uso sconsiderato di tale possibilità facilmente crea packet storm.

A causa di ciò, la maggioranza degli implementatori di stack IP ha scelto di implementare tale provvedimento, quello che il rispondere a una richiesta echo ICMP, sia supporto di default. Come sopracitato nel paragrafo dagli RCF (sopra), è perfettamente legale per un host scaricare tacitamente gli echo ICMP. Molte patches sono state spedite nelle mailing list per disabilitare la risposta a echo ICMP broadcast per i sistemi UNIX gratuitamente.

Nel caso di attacco "smurf" o "fraggle", ogni host che difende questo comportamento sn una LAN broadcast felicemente risponderà a un pacchetto echo-reply ICMP o UDP ( smurf o fraggle rispettivamente) verso l'indirizzo intestatario spoofed, la vittima.

La seguente sezione contiene informazioni per configurare gli hosts per NON rispondere a richieste echo a indirizzi broadcast.

L'IBM ha fornito una configurazione in AIX4.x per disabilitare le risposte a indirizzi broadcast. Non è disponibile in AIX 3.x. Da usare il comando "no" per attivarla o meno. NOTA: sui sistemi AIX 4.x le risposte sono DISABILITATE di default.
..........no -o bcastping=0 # disabilita risposte ping broadcast (defautl)

Solaris può essere settata per non rispondere alle richieste echo ICMP. Aggiungere la seguente linea al
/etc/rc2.d/S69inet startup:
......... ndd -set /dev/ip ip_respond_to_echo_broadcast 0
Se si sta usando Solaris come router, si può configurare in modo che non forwardi i broadcast diretti mettendo la seguente linea nel /etc/rc2.d/S69inet startup:
ndd -set /dev/ip ip_forward_directed_broadcasts 0

A partire dalla versione 2.2.5,lo stack IP di FreeBSD non risponde alle richieste echo ICMP destinate ad indirizzi broadcast o multicast di default.
Il parametro sysctl per questa funzionalità è net.inet.icmp.bmcastecho.
A partire dalla versione 3.x FreeBSD rende questa opzione configurabile nel file /etc/rc.conf con un'opzione che è nella sezione miscellania di configurazione della rete.

Sotto NetBSD, il broadcast diretto può esser disabilitato usando il comando sysctl :
sysctl -w net.inet.ip.directed-broadcast=0
Sotto Linux, si può usare la variabile CONFIG_IP_IGNORE_ECHO_REQUESTS per ignorare completamente le richieste echo ICMP. Naturalmente ciò viola RFC 1122.
"ipfw" può essere usato da linux per bloccare gli echo broadcast:
qualunque sistema con ipfw può essere protetto aggiungendo regole come:
ipfwadm -I -a deny -P icmp -D 123.123.123.0 -S 0/0 0 8
ipfwadm -I -a deny -P icmp -D 123.123.123.255 -S 0/0 0 8
( sostituire 123.123.123.0 e 123.123.123.255 con tuo numero di rete e indirizzo broadcast rispettivamente)

Per proteggere un host contro gli attacchi "fraggle" sulla maggiornaza delle macchine UNIX, si devono commentare le righe che iniziano con "echo" e "chargen" nel file /etc/inetd.confe restart inetd.

INFORMAZIONI PER LE VITTIME E SU COME IMPEDIRE GLI ATTACCHI:

La quantità di banda e pacchetti per secondo (pps) che può essere generata da questo attacco è molto grande.
Con una rete di 200 host, ho potuto generare più di 80Mbps di traffico a circa 35 Kpps rispetto al mio target, una quantità abbastanza significativa. La vittima lo riceve perché il traffico è moltiplicato per il numero di host usati della rete broadcast ( in questo caso con una rete di 200 host, mi è stato richiesto di spedire 400 Kbps agli indirizzi broadcast - meno che un terzo di un T1)

Molti host non possono processare così tanti pacchetti per secondo, molti host sono connessi a LAN Ethernet a 10Mbps dove risulta spedito più traffico della velocità del cavo. Quindi è necessario di scaricare questi pacchetti ai bordi della rete, o prima che si intasino le pipes di ingresso (before it flows down the ingress pipes)

I router Cisco hanno molti "paths" attraverso cui i pacchetti possono essere smistati: ognuno a un grado variabile di overhead. Il più lento di questi è uno switching "process". Questo è usato quando è necessario un compito complesso per processare i pacchetti. Le altre maniere sono variazioni di percorsi veloci - ognuno di questi ha i suoi vantaggi e svantaggi. Comunque, sono trattati a livello di interrupt ( nessun tempo a livello di processo è necessario per spingere (to punsh)questi pacchetti).

Nella versione IOS ( anche le più recenti) le negazioni della lista di accesso sono trattate a livello di processo (lento) perché necessitano un ICMP irraggiungibile per essere generate verso l'host di origine. Tutti i pacchetti spediti a livello di processo automaticamente sono trattati in questa maniera.

A seguito di un recente cambiamento di codice (Cisco bug ID CSCdj35407-integrato nella versione 11.1(14)CA e più tardi 11.1CA, 11.1CC, 11.1CE, e infine 12.0), i pacchetti negati dalla lista di accesso saranno passati a livello interrupt (veloce) con l'eccezione di due pacchetti al secondi per linea di negazione della lista di accesso, questi due pacchetti al secondo saranno usati per mandare i messaggi "ICMP unreachable via administrative block". Ciò implica che non si vogliono loggare le violazioni della lista di accesso (attraverso le chiavi "log" o "log-input"). L'abilità di stimare-limitare le linee "log-input" della lista di accesso (?? The ability to rate-limit "log-input" access-list lines) (in modo da loggare più facilmente tali pacchetti) è attualmente integrata, vedi la sezione sotto sul attacchi tracing di un pacchetto spoofed per informazioni sul logging. see the section sotto "Sul tracing di attacchi per indormazioni sul logging.

Filtrare i pacchetti di risposta echo destinati a macchine di alto profilo alle interfaccia di ingresso dei routers di confine della rete permetterà ai pacchetti di essere lasciati al primo punto possibile.
Comunque ciò non significa che le pipes di accesso non possano riempirsi, non appena i pacchetti continuano ad arrivare alle pipe per essere lasciati al router. Sarà comunque necessario scaricare il sistema attaccato. Bisogna tenere presente che anche questo impedisce altri dall'essere in grado di pingare a quella macchina ( le risposte non raggiungeranno mai la macchina)

Per gli utenti di providers che usano Cisco, ciò può dare la possibilità di far leva sui teams di sicurezza del provider perché diano una mano a salvare le pipes con il filtraggio prima che il traffico sia spedito.

Un'ulteriore tecnologia che si può usare per proteggere le macchine è il "committed access rate" o CAR. CAR è una funzionalità che lavora con Cisco Express Forwarding, trovata nel 11.1CC 11.1CE e 12.0.
Permette agli operatori di rete di limitare certo tipo di traffico con specifici mittenti o/ destinazioni.

Per esempio, un provider ha filtrato il suo server IRC dal ricevere pacchetti echo-reply ICMP in modo da proteggerlo, ma molti attaccanti stanno ora attaccando altre macchine customer o mecchine di rete in modo da riempire qualche segmento di rete.

Il provider sopra sceglie di usare CAR in modo da limitare tutto il traffico echo e echo-reply ricevuto ai limiti di 256 Kbps. Un esempio segue:

! traffico che si vuole limitare
access-list 102 permit icmp any any echo
access-list 102 permit icmp any any echo-reply
! configurazioni di interfaccia per i confiniinterface Serial3/0/0
rate-limit input access-group 102 256000 8000 8000 conform-action transmit exceed-action drop

Questo limita il traffico echo e echo-reply a 256 Kbps con una piccola quantità di cedimento(?? with a small amount of burst).
I comandi "rate-limit" multipli possono essere aggiunti a un'interfaccia in modo da controllare anche altro tipo di traffico.

Il comando "show interface [interface-name] rate-limit" mostra le statistiche del grado di limitazione; "clear counters [interface-name]" resetterà tali statistiche.

CAR può essere anche usato per limitare i floods TCP SYN a particolari host - senza impedire le connessioni esistenti. Alcuni attaccanti hanno iniziato usando grandi flussi di pacchetti TCP SYN in modo da danneggiare i sistemi ancora una volta.

Ecco un esempio che limita i pacchetti TCP SYN diretti all'host 10.0.0.1 a 8 kbps o circa:

! Non si vogliono limitare le sessioni TCP stabilite - pacchetti non SYN access-list 103 deny tcp any host 10.0.0.1 established ! Si vuole limitare il resto del TCP ( questo in pratica include solo i SYN) access-list 103 permit tcp any host 10.0.0.1 ! configurazioni di interfaccia per i confini della rete interface Serial3/0/0 rate-limit input access-group 103 8000 8000 8000 conform-action transmit exceed-action drop

Attualmente, CAR è disponiibile solo per i routers di serie 7200 2 7500. Un supporto di piattaforma aggiuntivo e programmato in 12.0

In più, CAR può essere usato per settare precedenze IP, questo va al di là dello scopo di questo scritto. Vai a www.cisco.com per maggiori informazioni sull'uso del CAR.

TRACING SPOOFED PACKET STREAMS:
Il Tracking di questi attacchi può essere difficile, ma è possibile con la coordinazione e collaborazione dei providers. In questa sezione si pensa ai router Cisco, pechè posso parlare solo delle capacità del Cisco di loggare/filtrare i pacchetti e che impatto può avere.

Oggigiorno, i logging dei pacchetti che passano o vengono lasciati in una ACL è possibile; comunque tutti i pacchetti con l'opzione "log" o "log-input" sono mandati a livello di processo per il logging. Per un grosso flusso di pacchetti questo può causare problemi eccessivi alla CPU. Per questa ragione il tracking degli attacchi attraverso logging IOS oggigiorno è limitato ad attacchi a piccola plarghezza di banda ( più piccoli che 10k pacchetti al secondo.Anche così il numero dei messaggi di log generati dal router può sovraccaricare un server syslog.

Cisco bug ID CSCdj35856 parla di questo problema. E' stato integrato in una versione IOS, releases 11.1CA a partire dalla 11.1(14.1)CA ( una release interim di mantenimento) e rende possibile loggare i pacchetti a intervalli definiti e processare i pacchetti loggati non in quell'intervallo a path veloci. Aggiornerò questa pagina con i numeri di versione come delle release che sono integrate.

Alcune informazioni sul logging:

A partire dalle versioni 11.1 una nuova keyword è stata introdotta per il logging ACL: "log-input". Un alinea formattata ACL che utilizza la keyword sembra come questa:

access-list 101 permit icmp any any echo log-input

Quando applicata ad un'interfaccia questa linea loggherà tutti i pacchetti di ping ICMP con l'interfaccia di input e l'indirizzo MAC ( per le reti multi-access). Le interfacce point-to-point non hanno il MAC address listato.

Ecco un esempio di log per una rete multi-access (FDDI, Ether):

Sep 10 23:17:01 PDT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 10.0.7.30 (FastEthernet1/0 0060.3e2f.6e41) -> 10.30.248.3 (8/0), 5 packets

Ecco un esempio di log per una rete point-to-point:
Sep 10 23:29:00 PDT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp
10.0.7.30 (BRI0 *PPP*) -> 10.0.19.242 (8/0), 1 packet

se si sostituisce "log" con "log-input" si eliminerà l'interfaccia in ingresso e il MAC addres dai messaggi di log.

Userò il primo log per dimostrare come muoversi da qui. Questo log significa che il pacchetto arriva da una FastEthernet1/0 da un indirizzo MAC 0060.3e2f.6e41 destinato a 10.30.248.3 Da qui si può usare "show ip arp" ( se necessario) per determinare indirizzo Ip dell'indirizzo MAC, e andare al successivo hop per tracciare o contattare necessariamente il peer ( nel caso di un punto dis cambio) Questo è un metodo di tracing hop-by-hop.

Esempio di "show ip arp" usato per trovare il successivo hop:

netlab#show ip arp 0060.3e2f.6e41
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.183.65 32 0060.3e2f.6e41 ARPA FastEthernet1/0

Come si può vedere 10.0.183.65 è il successivo hop da cui i pacchetti provengono e dovremmo continuare il processo di tracing, utilizzando lo stesso metodo ACL. Facendo ciò puoi tracciare l'attacco spoof all'indietro.

Mentre questa è l'informazione generale sui pacchetti spoofed, si deve notare che le vittime di un attacco smurf/fraggle ricevono pacchetti di echo-reply da sorgenti listati nei pacchetti, cioè ricevono pacchetti realmente dai mittenti listati negli header IP. Questa informazione dovrebbe essere usata dagli intermediari o "amplificatori" per tracciare i pacchetti di richiesta echo indietro fino alla sorgente (l'attaccante).

ALTRO ATTACCHI DENIAL OF SERVICE DEGNI DI ESSERE MENZIONATI

Due altri Dos incontrati frequentemente sono TCP SYN floods e UDP floods diretti a porte diagnostiche sugli hosts.

Gli attacchi TCP Syn consistono in un grande numero di set-up di connessione TCP spoofed diretti a un particolare servizio su un host.
Le vecchie implementazioni TCP non possono sostenere molti pacchetti di set-up di connessione faked e non permetteranno l'accesso al servizio della vittima.

La forma più comune di UDP floading diretto a reti danneggiate è un attacco consistente in un gran numero di pacchetti spoofed UPD con lo scopo di fare una diagnostica delle porte sulle macchine di rete. Questo attacco è conosciuto come "pepsi", e può far usare alle macchine di rete quantità di CPU grosse che rispondono a questi pacchetti.

Per avere più informazioni per minimizzare gli effetti di questi attacchi, vedere:

Definire strategie per proteggersi contro TCP SYN
Denial of Service Attacks
http://cio.cisco.com/warp/public/707/4.html

Definire strategie per proteggersi contro una diagnostica UDP Port DoS Attacks
http://cio.cisco.com/warp/public/707/3.html

PERFORMANCE INFORMATION:

Un ISP ha riportato che, fatto girare su 3 router ( 2RSP2 e un RSP4) il codicee di eliminazione veloce ha retto un attacco smurf di 120 Mbps e tenuto la rete su senza problemi di performance.

Come sempre, il costo/distanza può variare (As always, your mileage may vary)

ACKNOWLEDGEMENTS: Grazie a tutti quelli che hanno aiutato nella revisione e stesura di questo scritto, lo stesso per coloro che lo hanno controllato.

Documenti di riferimento:

RFC-1122, "Requirements for Internet Hosts - Communication Layers"; R.T. Braden; October 1989.

RFC-1812, "Requirements for IP Version 4 Routers"; F. Baker; June 1995.
RFC-2267, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing"; P. Ferguson, D. Senie; January 1998.
RFC-2644, "Changing the Default for Directed Broadcasts in Routers"; D. Senie; August 1999.
Definire strategie per proteggersi contro TCP SYN Attacchi Dos http://cio.cisco.com/warp/public/707/4.html
Definire strategie per proteggersi contro diagnostici UDP Port Dos Attack
http://cio.cisco.com/warp/public/707/3.html Documentazione dei comandi Cisco per "spegnere" (disabilitare) i broadcast diretti http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/cs/csprtn1/csipadr.htm#xtocid748113
Documentazione dei comandi 3Com per disabilitare i broadcast diretti. http://infodeli.3com.com/infodeli/tools/bridrout/u_guides/html/nb101/family/REF/ip4.htm#190
Documentazione di comandi 3Com per disabilitare il source spoofing. http://infodeli.3com.com/infodeli/tools/bridrout/u_guides/html/nb101/family/REF/firewal3.htm#1823
Il permesso di duplicare questa informazione è dato sotto questi termini:
1. Il mio nome e indirizzo e_mail rimangono sullo scritto per domande e identificazione dell'autore.
2. Il mio discaimer compaia sullo scritto alla fine.
3. Sentirsi libero di aggiungere altre informazioni da altre discussione, ecc, ma per favore assicurarsi che l'attribuzione corretta sia fatta all'autore. Fornire inoltre una copia delle aggiunte a Craig Huegen (chuegen@quadrunner.com)
4. Per favore distribuisci tali informazioni ad altri amministratori di rete che subiscono tali attacchi

Se hai qualche domanda, sarò felice di risponderti al meglio delle mie possibilità conoscitive.

IL MIO DISCLAIMER Sto parlando di questo solo come parte interessata. Tutto il testo è stato scritto da me, non parlo, né scrivo per nessuno se non me stesso. Nessun venditore ha ufficialmente confermato/negato nessuna delle informazioni qui contenute. Tutta la ricerca che c'è in questo scritto è stata fatta solamente come motivo di interesse personale per aiutare a minimizzare gli effetti di questo attacco. Craig A. Huegen chuegen@quadrunner.com http://www.quadrunner.com/~chuegen/smurf.txt
Testo Originale