Rapporto sugli abusi di Amazon EC2

Question

Rapporto sugli abusi di Amazon EC2

#1 da (1 voti)

2

La mia azienda ha ricevuto di recente un'email da Amazon che ci ha comunicato attività dannose che si verificano sulla nostra istanza EC2 in esecuzione.

L'email afferma: Abbiamo osservato le macchine sotto il tuo controllo partecipando a un attacco DDoS targeting per gli IP di Google.

L'attacco era un attacco di amplificazione UDP. In questo attacco, basato su UDP il servizio è abusato per attaccare gli altri, sprecando la larghezza di banda e l'elaborazione risorse.

Sono abbastanza nuovo a tutte queste cose oltre ad AWS e non ho idea di dove cominciare. Quali dovrebbero essere i primi passi da seguire per attenuare questo?

Dopo aver eseguito i comandi da @ximaera

Davids-MacBook-Pro:~ davidpham$ ntpdc -nc monlist *ip*
*ip*: timed out, nothing received
***Request timed out
Davids-MacBook-Pro:~ davidpham$ dig @ip +edns=0 +ignore com ANY

<<>> DiG 9.10.6 <<>> @ip +edns=0 +ignore com ANY
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
Davids-MacBook-Pro:~ davidpham$

Questo è stato l'output che ho ricevuto. Mi manca qualcosa?

cloud-computing aws attack-prevention ddos

posta David Pham 06.10.2018 - 00:00

fonte

1 risposta

Leggi altre domande sui tag cloud-computing aws attack-prevention ddos

Il soggetto deve dominare l'oggetto per accedere all'oggetto? Come gestire i token di aggiornamento

score 1 · Accepted Answer

Generalmente, esiste una lunga lista di server e protocolli vulnerabili per l'amplificazione UDP. Alcune chiamate da riga di comando per determinare la presenza di alcuni dei più importanti vettori di amplificazione potrebbero essere trovati qui . Tutti i comandi dovrebbero essere meglio richiamati da remoto. Per esempio. se il tuo server è 192.0.2.1, quindi, per verificare la presenza di un amplificatore NTP, fai

ntpdc -nc monlist 192.0.2.1

dal computer portatile o da un computer del centro dati adiacente.

Consiglierei di controllare prima NTP e DNS, e se non c'è corrispondenza, quindi di approfondire i dettagli.

tcpdump -ni any udp sul server stesso ti aiuterà sicuramente ad immergerti. Se sei in grado di individuare qualsiasi traffico che non ti aspetti di vedere nella discarica, puoi rintracciare l'applicazione vulnerabile in ascolto sulla porta vista nel dump guardando (o grep ing) all'output di% % co_de.

EDIT. Così ora, dato che hai fornito l'indirizzo IP del tuo server, sono stato in grado di controllarlo da solo, e risulta che hai un amplificatore PORTMAP attivo:

$ rpcinfo -T udp $ip | wc -l
      17
$

Quindi in pratica hai bisogno di passare attraverso il resto dei controlli passati a quelli DNS e NTP.

La correzione è ovviamente quella di disabilitare port mapper ( ecco come lo fai su Debian / Ubuntu) o almeno blocca l'accesso alla porta 111 / UDP tramite firewall.