Server Apache / Linux, attacco DoS dal proprio IP

Prima cosa: scopri da dove vengono queste richieste. Deve essere un processo locale, nient'altro è in grado di spoofare un handshake TCP su una piattaforma Linux moderna (niente, cioè, che poi procederebbe a sprecare tale abilità nel richiedere random immagini).

Se esistono URL ricorrenti, puoi ombreggiarli dietro un RewriteRule in modo che qualsiasi richiesta di questo tipo attivi effettivamente uno script . Nello script è possibile eseguire ulteriori controlli per vedere se la richiesta è legittima (e quindi si stamperanno le intestazioni corrette proprio come se fosse l'immagine che il client legittimo si aspetta), o se è una delle richieste fasulle. Contro la richiesta fasulla puoi accedere ad es. la porta in arrivo. Armato di questo, puoi interrogare netstat e scoprire il processo. Puoi anche eseguire ps e ispezionare tutti i processi attivi nell'istante della richiesta fasulla.

Sono abbastanza sicuro che il colpevole si rivelerà essere Apache stesso (una volta ho avuto uno script di "cache priming" mi ha lasciato per colpa di una modifica di vhost - avevo dimenticato di mettere lo script in crontab - e ho avuto sintomi davvero strani , un po 'come il tuo, finché non mi è tornato tutto, ma il tuo caso è diverso)

Per perfezionare ulteriormente la scena contenendo i costi, puoi aggiungere PID / TID al CustomLog di Apache. Quindi sarai in grado di verificare le richieste ricevute dal bambino Apache andato falso.

Un'altra possibilità è determinare esattamente come queste richieste sono fatte. Se attraverso Apache, ciò significa fopen_wrappers, cURL, funzioni socket, o forse utilità di shell (queste dovrebbero apparire entrambe in ps output e provocare un sovraccarico molto più massiccio del server, però). Puoi preparare una serie di script che:

• riavvia con grazia Apache senza modifiche
• "", disabilitando temporaneamente una di quelle funzioni
• "", riattivazione stesso

Dopo aver verificato (solo per essere sicuri) che un riavvio non risolva il problema (se lo facesse, sarebbe un diverso tipo di worm), puoi procedere a disabilitare temporaneamente - a una ventina di secondi ciascuno, non più - una funzione dopo l'altra. Supponiamo che disabilitare i risultati dell'arricciatura nel sistema ritorni immediatamente alla normalità: quindi potresti limitare le investigazioni agli script usando cURL, e magari persino wrap la funzione cURL con un wrapper di registrazione.

Nel caso in cui la parte colpevole non sia Apache, sarai comunque in grado di determinare cosa sta facendo; quindi reinstallare il programma interessato (anche se trovo improbabile che si verifichi un'anomalia casuale per trasformare un programma in un richiedente ripetizione-HTTP-GET) o ispezionare la sua configurazione, i file di dati ausiliari, gli script e così via e così via, cercando per qualsiasi differenza rispetto a un'installazione pulita conosciuta. Poiché di solito non credo nei gremlin, mi aspetto che alla fine emerga una certa differenza.

Unix (e Linux) ha una vasta gamma di strumenti per analizzare cose come questa. La mia prima fermata sarebbe quella di prendere l'output di netstat -nap, ad es. sulla mia macchina locale ...

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
...
tcp        0      0 192.168.0.2:80              192.168.0.2:59875           ESTABLISHED 5281/httpd
...
tcp        0      0 192.168.0.2:59875           192.168.0.2:80              ESTABLISHED 32588/chrome
...

Qui posso vedere che chrome (pid 32588) è collegato alla porta 80 / httpd (pid 5281). Poiché si tratta di un'installazione pre-fork di apache, posso ottenere maggiori informazioni sul processo httpd registrando% P o cercando in / proc / 5281 / fd (quest'ultimo probabilmente richiederà lo scripting per catturare i dati al momento della richiesta ).

Questo ti permetterà di identificare il processo del cliente.

I candidati più probabili sono un proxy o un codice bug mal configurato.

Se questo fosse il mio server, eseguirò un strace su Apache. L'esecuzione di questo processo su ogni processo figlio in modalità prefork può essere piuttosto intensivo sul disco, specialmente quando il server è già sovraccaricato. Devi tenere d'occhio anche lo spazio del tuo disco, perché se si esaurisce, Apache interrompe la richiesta.

Assicurati di utilizzare una lunghezza abbastanza lunga per acquisire l'intera richiesta: -s 400 dovrebbe fare.

Se Apache sta facendo richieste a se stesso, qualsiasi stringa GET apparirà nei dump strace per due PID diversi: uno che ha fatto la richiesta e uno che lo ha ricevuto. In quello che ha fatto la richiesta, vuoi trovare la richiesta che ha ricevuto ed è stata elaborata quando ha effettuato la richiesta a se stessa.

Normalmente faccio qualcosa del genere:

for x in 'ps -ef | grep apache | awk '{print $2}''; do strace -s 2000 -p $x -o trace.$x & done

Se vuoi limitarti a un sottogruppo di bambini Apache per motivi di rendimento, aggiungi un head lì dentro:

for x in 'ps -ef | grep apache | head | awk '{print $2}''; do strace -s 2000 -p $x -o trace.$x & done

Tuttavia, tieni presente che ciò rende meno probabile la cattura di ciò che sta accadendo.

Assicurati di avere due sessioni SSH aperte in quanto tutte quelle attività in background possono ancora scrivere nella tua sessione. Quando si desidera interrompere le stringhe, riavviare Apache o eseguirlo nell'altra:

 for x in 'ps -ef | grep strace | awk '{print $2}''; do kill $x; done

Il mio istinto su questo è un modulo "statico" scritto in PHP che pre-elabora le immagini (ridimensionandole per esempio) prima di inviarle al client e lo fa con include($image) . Se $image contiene un URL immagine dal tuo sito piuttosto che un percorso file dal filesystem locale, le richieste ricorsive sono il risultato.

Potrebbe utilizzare le funzioni curl() anziché include() .

Sembra un tipico attacco DOS. Probabilmente stanno sperando di ottenere il server per rispondere a una richiesta da sé e sperando di ottenere un ciclo come il "ping of death". È anche un modo conveniente per fare lo spoof per aggirare alcune regole del firewall e causare mal di testa generale. Bloccare l'IP esterno sul firewall è probabilmente la scelta migliore, in modo che non possano ricevere le richieste alla porta.

Sembra un attacco DDoS che sta falsificando l'IP del server. L'azione migliore sarebbe quella di inserire un filtro di pacchetti sul router esterno anziché utilizzare le regole del firewall, in quanto l'utilizzo del router ridurrà il carico sul firewall. Su un router Cisco la soluzione semplice sarebbe scrivere un elenco di accessi con la sorgente come blocco pubblico e la destinazione come qualsiasi, quindi applicarla all'interfaccia esterna come "gruppo di accesso ip in".

Anche l'ICMP che limita la velocità sarebbe una buona idea, potrebbero provare a fare il ping di te.

Dovresti pensare di valutare anche la limitazione del traffico valido, il prossimo attacco DDoS non falsificherà i tuoi IP personali, utilizzeranno indirizzi IP validi che non puoi filtrare senza filtrare i tuoi clienti. Un limite di frequenza ben scelto manterrà il tuo server a corto di risorse.