Ricevo molte richieste nei nostri log di Apache che sembrano così
www.example.com:80 10.240.1.8 - - [06/Mar/2013:00:39:19 +0000] "-" 408 0 "-" "-" -
Sembra che non ci siano richieste né agenti utente. Qualcuno l'ha mai visto prima?
Ricevo molte richieste nei nostri log di Apache che sembrano così
www.example.com:80 10.240.1.8 - - [06/Mar/2013:00:39:19 +0000] "-" 408 0 "-" "-" -
Sembra che non ci siano richieste né agenti utente. Qualcuno l'ha mai visto prima?
Risposte:
Sei per caso in esecuzione i tuoi server Web in Amazon dietro un bilanciamento del carico elastico?
Sembra che generino molte 408 risposte a causa dei loro controlli sanitari .
Alcune delle soluzioni da quel thread del forum:
RequestReadTimeout header=0 body=0
Ciò disabilita le 408 risposte in caso di timeout di una richiesta.
Disabilita la registrazione per gli indirizzi IP ELB con:
SetEnvIf Remote_Addr "10\.0\.0\.5" exclude_from_log
CustomLog logs/access_log common env=!exclude_from_log
E da questo post del blog :
RequestReadTimeout header=0 body=0
disabiliterei la richiesta di timeout di lettura tutti insieme, non lo consiglierei
Qualcosa si connette alla porta e quindi non invia mai dati. HTTP 408 è un errore di "timeout". C'è un buon commento qui: http://www.checkupdown.com/status/E408.html
Ci sono già alcune buone risposte qui, ma vorrei mettere in pericolo una nota aggiuntiva che non è stata affrontata in modo specifico. Come molti dei precedenti commentatori già menzionati, 408 indica un timeout; e ci sono molte circostanze in cui si verificano timeout su un server web.
Detto questo, 408 errori possono essere generati in una varietà di casi in cui il tuo server è sottoposto a scansione per exploit. I client in questi casi raramente presentano un programma utente e spesso terminano bruscamente le connessioni, causando un arresto interrotto per quella connessione che può generare un errore 408.
Ad esempio, supponiamo che io sia un pirata informatico che sta eseguendo la scansione di Internet alla ricerca di computer che sono ancora vulnerabili alla vulnerabilità di POODLE. Come tale, ho scritto uno script che apre le connessioni a grossi blocchi di indirizzi IP per trovare server che accetteranno la versione 3 di SSL - in seguito userò quell'elenco per cercare specificamente l'exploit POODLE. Tutto ciò che fa questo primo script è stabilire una connessione usando openssl per verificare SSLv3, in questo modo:
openssl s_client -connect [IP]:443 -ssl3
Questo comando, in molte configurazioni di Apache, genererà un messaggio 408 esattamente come descritto. L'esecuzione di questo comando su due dei miei server ha comportato questa voce nel registro di accesso:
<remote IP address> - - [04/Nov/2015:08:09:33 -0500] "-" 408 - "-" "-"
Volevo chiarirlo come anche in una situazione in cui OP non utilizzava alcuna forma di bilanciamento del carico, 408 errori possono verificarsi in una varietà di circostanze: alcuni dannosi, alcuni che indicano problemi con il client e altri che indicano problemi con il server. (Ho notato nel registro fornito da OP che un IP locale era indicato come IP remoto, ma OP non menzionava specificamente l'uso di un bilanciamento del carico, quindi non ero sicuro se OP avesse semplicemente usato un IP non instradabile per gli scopi di dimostrazione, come ha fatto con l'URL)
Comunque, anche se il mio post è ovviamente troppo tardi per aiutare l'OP, si spera che possa aiutare gli altri che arrivano qui alla ricerca di una soluzione a tutti quei maledetti errori di timeout.
Esistono vari motivi per un timeout 408. Ma partiamo dal presupposto che tutto vada bene, quindi a un certo punto questi 408 iniziano a comparire nel registro di accesso, ovvero 408 0 "-" "-".
Come molti sottolineano in rete, un 408 indica che viene stabilita una connessione ma nessuna richiesta viene inviata nella scala temporale appropriata, quindi il server interrompe la connessione con un 408. Un arrogante individuo ha effettivamente risposto a qualcuno chiedendo aiuto su questo problema con - "Quale parte del timeout non capisci".
Penso che sia una risposta da principiante e dimostra una totale mancanza di comprensione di come funzionano alcuni metodi di sicurezza con il software web server.
Quindi, all'inizio, perché vedo tutti questi 408. Una cosa che avrai in comune con il resto di noi che gestiamo un server è la grande quantità di attacchi che ricevi quotidianamente. Ora, cosa fai di questi? Bene: impieghi i metodi di sicurezza scelti per gestirli, questo è ciò che cambia.
Facciamo un esempio molto semplice, rilascia un indirizzo IP. Incluso in un file iptabes (rules.v4) hai "-A ufw-user-input -s 37.58.64.228 -j DROP". Quindi arriva 37.58.64.228 il firewall riconosce l'IP e interrompe la connessione. In molte configurazioni non sapresti nemmeno che ha bussato alla porta.
Ora facciamo un esempio più avanzato, Rilascia la connessione in base ad alcuni criteri. Incluso in un file iptabes (rules.v4) hai "-A INPUT -p tcp -m tcp --dport 80 -m string --string" cgi "--algo bm --to 1000 -j DROP". Questo è diverso perché in questa regola iptable stiamo dicendo guarda i primi 1000 byte della stringa di richiesta e vedi se riesci a trovare una sotto-stringa di "cgi" e se trovi quella sotto-stringa allora non andare inoltre, basta rilasciare la connessione.
Qui il metodo di sicurezza è buono, ma per quanto riguarda i tuoi registri sono fuorvianti. Il 408 0 "-" "-" generato è il migliore apache può fare in queste circostanze. La connessione è stata stabilita e la richiesta ha dovuto essere accettata fino a un certo punto per applicare la regola di confronto delle stringhe che alla fine risulta in un 408 perché la regola ha soddisfatto i criteri per la connessione da eliminare. Quindi, i nostri piccoli cari principianti non potrebbero essere più sbagliati se provassero. È stata stabilita una connessione e è stata ricevuta una richiesta (in questi casi non ne avrai visibilità). Sebbene venga generato un 408, non è un "Timeout"; il tuo server ha semplicemente abbandonato la connessione dopo aver effettuato la richiesta in associazione con la regola del firewall. Ci sono molte altre regole, che creerebbero la stessa situazione 408. Don'
Idealmente ci sarebbe un altro codice di errore generato da Apache, ad esempio '499' che significherebbe 'Il server ha letto la tua richiesta e ha deciso che non poteva preoccuparsi di intrattenerti - Sod Off HaHa'.
Con l'ultimo software per server Web è possibile escludere praticamente gli attacchi DOS e il nuovo gene dei browser che incorpora capacità predittive non causa questo problema, come alcuni hanno suggerito.
In breve, il 408 viene generato perché il server non ha risposto alla richiesta, quindi per quanto riguarda il client è scaduto il collegamento, quando in realtà il server ha letto la richiesta ma ha lasciato cadere la connessione per motivi diversi da un timeout in attesa di una richiesta.
Abbiamo avuto questo problema e ci siamo lasciati per un po 'perplessi. La migliore soluzione che abbiamo trovato è stata suggerita dal team ELB del supporto AWS. Fondamentalmente dipende dal fatto che le impostazioni di timeout del tuo server httpd siano tutte maggiori delle tue idle timeout
impostazioni ELB (che per impostazione predefinita è 60 secondi).
Timeout
valore della tua direttiva apache sia il doppio idle timeout
dell'impostazione del tuo ELB.KeepAlive
funzione, assicurati che MaxKeepAliveRequests
sia molto grande (0 per infinito o molto alto, come 2000) e che KeepAliveTimeout
sia maggiore di quello dei tuoi ELB idle timeout
.Abbiamo scoperto che l' KeepAlive
impostazione (e le impostazioni associate) ha ridotto in modo specifico la quantità di 408s a 0 (ne vediamo alcuni, ma pochissimi).
Ho avuto questo problema dietro AWS Elastic Load Balancer. I controlli sanitari hanno generato una quantità orribile di 408 risposte nel registro.
L'unica soluzione che ha funzionato per me è stata quella di impostare il Timeout di inattività di Load Balancer su un valore inferiore rispetto al Timeout di risposta di Health Check .
Un collega ha recentemente osservato che mentre il mio ultimo post ha fornito una spiegazione valida di come un 408 potesse avere un'associazione con una misura di sicurezza, non ha offerto alcuna soluzione.
Il registro di accesso con pipe è la mia soluzione personale.
Quanto segue dovrebbe funzionare immediatamente sulla maggior parte delle configurazioni di Ubuntu e con armeggi minimi su altre configurazioni di Apache. Ho scelto PHP perché è il più facile da capire. Esistono due script: il primo impedisce la scrittura di un 408 nel registro di accesso. Il secondo script invia tutti i 408 a un file di registro separato. In ogni caso, il risultato non è più 408s nel registro di accesso. È la tua scelta quale script implementare.
Usa il tuo editor di testo preferito, io uso nano. Apri il file in cui hai le direttive 'LogFormat' e 'CustomLog'. Commenta gli originali con il solito # e aggiungi quanto segue. Puoi trovare queste direttive nel file qui sotto.
sudo nano / etc / apache2 / sites-available / default
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" AccessLogPipe
CustomLog "|/var/log/apache2/PipedAccessLog.php" AccessLogPipe env=!dontlog
NOTA: non registro le immagini nel mio registro di accesso. Nel mio file etc / apache2 / httpd.conf includo la riga
SetEnvIfNoCase Request_URI ".(gif)|(jpg)|(png)|(css)|(js)|(ico)$" dontlog
Se questo non ti interessa, rimuovilo env=!dontlog
dalla CustomLog
direttiva.
Ora crea uno dei seguenti script PHP ( #!/usr/bin/php
è un riferimento alla posizione dell'interprete, assicurati che la posizione sia corretta per il tuo sistema - puoi farlo digitando al prompt $; whereis php
- questo dovrebbe restituire qualcosa di simile php: /usr/bin/php /usr/bin/X11/php /usr/share/man/man1/php.1.gz
. posso vedere #!/usr/bin/php
è giusto per la mia configurazione).
sudo nano /var/log/apache2/PipedAccessLog.php
#!/usr/bin/php
<?php
$file = '/var/log/apache2/access.log';
$no408 = '"-" 408 0 "-" "-"';
$stdin = fopen ('php://stdin', 'r');
ob_implicit_flush (true);
while ($line = fgets ($stdin)) {
if($line != "") {
if(stristr($line,$no408,true) == "") {
file_put_contents($file, $line, FILE_APPEND | LOCK_EX);
}
}
}
?>
sudo nano /var/log/apache2/PipedAccessLog.php
#!/usr/bin/php
<?php
$file = '/var/log/apache2/access.log';
$file408 = '/var/log/apache2/408.log';
$no408 = '"-" 408 0 "-" "-"';
$stdin = fopen ('php://stdin', 'r');
ob_implicit_flush (true);
while ($line = fgets ($stdin)) {
if($line != "") {
if(stristr($line,$no408,true) != "") {
file_put_contents($file408, $line, FILE_APPEND | LOCK_EX);
}
else {
file_put_contents($file, $line, FILE_APPEND | LOCK_EX);
}
}
}
?>
Aver salvato la PipedAccessLog.php
sceneggiatura; assicurarsi che root abbia la proprietà eseguendo quanto segue al prompt $.
sudo chown -R root:adm /var/log/apache2/PipedAccessLog.php
Lo PipedAccessLog.php
script avrà bisogno delle autorizzazioni di lettura / scrittura ed esecuzione, quindi eseguire quanto segue al prompt $.
sudo chmod 755 /var/log/apache2/PipedAccessLog.php
Finalmente per far funzionare tutto ciò che serve è necessario riavviare il servizio Apache. Eseguire quanto segue al prompt $.
sudo service apache2 restart
Se i log di Apache si trovano altrove, modificare i percorsi in base alla propria configurazione. In bocca al lupo.
Ho scoperto che 408 errori stanno aumentando sia in numero che in frequenza. Anche l'intervallo di indirizzi IP da cui provengono è in aumento (questi sono registrati nel proprio file separato). Esistono anche schemi di log evidenti che mostrano 408 consecutivi dagli stessi gruppi di IP che non sono dovuti a normali timeout del server in quanto l'originatore sta tentando connessioni distanti tra loro a circa 2 o 3 secondi in un modello ciclico (non è necessario attendere un timeout prima di un altro tentativo di connessione) Vedo questi come semplici tentativi di connessione in stile DDOS. A mio avviso, si tratta di un tipo di messaggio di conferma per il creatore che un server è online ... poi tornano più tardi con diversi strumenti .... Se aumenti l'intervallo di timeout, stai semplicemente dando loro un time_allocation più grande da eseguire i loro programmi di hacking all'interno.