> A parte che io personalmente sono abbastanza disilluso sulle cose che
> "dovrebbero essere certamente notate", quelle 100.000 query servivano
> per recuperare la chiave privata, non generiche password che dovrebbero
> essere molto più comuni. E poi, come qualcuno ha già notato, 100.000
> query consecutive da un singolo IP sono una cosa, 100.000 query da 1000
> Ip distribuite in qualche giornata probabilmente non le nota nessuno o
> le scambia per altro.
Concordo.
Niente nei log. Traffico che appare come ssl [1][2]. 100k richieste
possono anche sembrare tante viste così, ma sono nulla nel contesto
dove avresti dovuto notarle: che quota percentuale sono del normale
traffico ssl di @SITI_MOLTO_SUCCOSI nella stessa finestra temporale
(ore) in cui avviene l'attacco? Se poi è distribuito, appunto...
Altre considerazioni: alcuni attacchi al cloudfarechallenge.com (che
è l'origine delle cifre) per i quali sono stati pubblicati dettagli,
sono stati portati con tool che elicitavano un heartbeat di soli 16k
o che guardavano solo nel primo dei segmenti TLS (16kB) di risposta,
e rieseguivano l'handshake per ogni heartbeat richiesto (ne potresti
chiedere due, da test fatti). Con tool più furbi sarebbero già state
sufficienti 1/3 delle richieste citate.
Ultima considerazione: da apache appena avviato il modulo m'è uscito
alla seconda richiesta.
Ciao
Fabio
[1] tranne che nel payload degli hertbeat di risposta: dei nids con
regole di egress casualmente pertinenti, avrebbero anche potuto
matchare qualcosa, sempre che vedendo l'header ssl non avessero
chiuso l'analisi di quello stream (che tanto è criptato, no?) o
che proprio non analizzassero TLS (che tanto è criptato, no?).
[2] quanti [n]ids verificavano che la dimensione del payload di una
oscura estensione TLS non corrispondeva a quanto dichiarato?
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
