Cisco ASA SYN rilevamento e risposta alluvione non funzionanti

9

Ho un Cisco ASA 5510 (ASA versione 8.3 (2)) che ha ricevuto un attacco syn flood su di esso (o più accuratamente attraverso - indirizzando un host dietro di esso) un paio di volte al giorno negli ultimi giorni. La stessa connessione a Internet è decente e non sembra saturare completamente la linea, ma invece sembra che ciò accada è che la CPU va al 100% e quasi tutto il traffico valido viene eliminato.

Gli attacchi sembrano utilizzare IP spoofizzati randomizzati - gli indirizzi di origine non si ripetono affatto.

Ho seguito le istruzioni qui per abilitare una connessione massima e una massima per le connessioni embrionali. I comandi esatti usati erano:

fw1(config)# class CONNS
fw1(config-cmap)# match any
fw1(config)# policy-map CONNS
fw1(config-pmap)# class CONNS
fw1(config-pmap-c)# set connection timeout embryonic 0:0:5
fw1(config)#service-policy CONNS global

(La teoria è che le connessioni massime scatenerebbero qualsiasi risposta alla minaccia che l'ASA ha - o almeno impediscono alla CPU di ruotare e bloccare il dispositivo. E il timeout della connessione inferiore dovrebbe ovviamente farlo smettere di tenere traccia di false connessioni TCP prima e, auspicabilmente, ridurre il conteggio di ciò di cui ha bisogno per tenere traccia di.)

Tuttavia, questo sembrava non fare alcuna differenza quando arrivò il prossimo attacco. Le connessioni sono ancora al massimo (e anche la CPU è ancora al 100%):

fw1# show conn count
130000 in use, 130001 most used

Così ho impostato un test con un server che ho ed è stato in grado di ottenere questo scenario di test:

Linux test attacker:

(iptables configured to drop anything back from ASA)
# sudo hping2 -i u2000 -S -p 80 RE.DA.CT.ED

ASA:

fw1# show threat-detection statistics host RE.DA.CT.ED
Current monitored hosts:11991  Total not monitored hosts:28657651
                          Average(eps)    Current(eps) Trigger      Total events
Host:RE.DA.CT.ED: tot-ses:2993977 act-ses:6493 fw-drop:0 insp-drop:0 null-ses:2979635 bad-acc:0
  20-min Recv attack:             1227             492      43           1473050
  1-hour Sent byte:               6281             260       0          22611776
  1-hour Sent pkts:                142               5       0            513064
  1-hour Recv byte:              33377           11439       0         120159833
  1-hour Recv pkts:                834             285       0           3002986

Quando eseguo il comando hping2, incrementa la parte act-ses: 6493. mostra il conteggio delle connessioni mostra anche il conteggio complessivo delle connessioni in aumento.

Dopo un po 'nel registro ASA, ottengo messaggi come questo:

[   RE.DA.CT.ED] drop rate-1 exceeded. Current burst rate is 0 per second, max configured rate is 10; Current average rate is 84 per second, max configured rate is 5; Cumulative total count is 101750
TCP Intercept SYN flood attack detected to RE.DA.CT.ED/80 (RE.DA.CT.ED/80). Burst rate of 820 SYNs/sec exceeded the threshold of 400.

Tuttavia da quello che posso dire il conteggio totale delle connessioni continua ad aumentare, anche dopo aver rilevato il syn flood. Inoltre noto che il conteggio delle fw-drop sulle statistiche di rilevamento delle minacce è sempre zero.

Con tutto ciò, le mie domande specifiche sono:

1) C'è un modo per sapere con certezza che qualunque sia il "syn cookie" che supporta l'ASA è abilitato (per un IP target specifico o globalmente o qualsiasi contesto che sarebbe utile)?

2) Se i syn cookie sono attivati - non dovrebbero più contare questi pacchetti syn contro il conteggio degli esatti per quell'IP o contro il conteggio complessivo delle connessioni, corretto?

3) C'è qualche errore evidente nella mia configurazione di cui sopra o cosa chiave mi sembra che manchi?

EDIT: 3 giorni dopo, ancora nessuna idea. Qualsiasi input apprezzato.

    
posta bgp 20.10.2014 - 11:24
fonte

1 risposta

1

Mi chiedo se avresti potuto sperimentare questo - link (Capisco la differenza in termini di tempo, tuttavia ci sono stati molti di questi tipi di consigli nel corso degli anni) Spero che questo aiuti ...

    
risposta data 27.04.2018 - 11:11
fonte

Leggi altre domande sui tag