Log di server dispari

Questo sembra essere un programma in esecuzione su alcuni PC di script kiddies, che sta provando casualmente i siti per rilevare quale CMS sono in esecuzione, per vedere se quel sistema è vulnerabile a SQL injection o qualsiasi altra cosa, e quindi lo sfrutta automaticamente o passare le informazioni alla persona che esegue il programma.

Fondamentalmente solo uno script che cerca un modo per accedere al tuo back-end, ma finché il tuo sito è sicuro, non c'è nulla di cui preoccuparsi.

Se sei preoccupato per gli 404 in cui è specificato referer , aspetta solo di guardare gli 404 in cui referer non è impostato! (ce ne saranno molti altri)

La verità è che dal momento in cui connetti il tuo server web a Internet, i bot proveranno a scansionare il tuo server per proxy Web e altre vulnerabilità in modo che possano sfruttarlo e inviare malware ai tuoi utenti finali. Questo è comune e rilevato vedendo 404 voci nel tuo registro.

Quello che dovresti fare è assicurarti che il tuo server sia corretto quando lo esporti ad Internet e aggiustato i patch quando vengono lanciati nuovi aggiornamenti. Questi robot stanno cercando di sfruttare server che sono stati trascurati o che non sono stati sottoposti a protezione avanzata.

Inoltre, dovresti sapere che referer non è un campo sicuro e può essere falsificato. Questo è probabilmente quello che sta succedendo. Riesco a vedere come vorresti assumere logicamente che questo provenga dal tuo sito, ma non è un campo che può essere considerato attendibile per motivi di sicurezza ... anche se è utile trovare collegamenti che gli utenti cliccano e vengono inviati a una pagina non trovato.

Aneddoticamente, i registri del server Web devono indicare l'IP di origine dell'utente che sta iniziando l'azione. Se si tratta di un indirizzo interno (nel nostro post si parla di un indirizzo 10.x), è possibile che l'utente si trovi nella sottorete e che abbia un virus che sta analizzando il server.

Dovresti eseguire una ricerca su google per la stringa UserAgent, poiché molti webmaster guardano i loro registri nello stesso modo in cui ti trovi. Un esempio è qui.

Bottom line: se il tuo server è patchato e i link non hanno rilevanza per il tuo sito, dovresti ignorarli o bloccare il loro IP.

Usando uno strumento chiamato OSSEC un famoso ben noto HIDS di trend micro puoi efficacemente non solo identificare ma bloccare questi tentativi. Instradando questi tentativi su Black Hole Route null. Ti mostrerò come.

Aggiunta di risposta attiva ∞

  <!-- Active response to block http scanning -->
<active-response>
    <command>route-null</command>
    <location>local</location>
<!-- Multiple web server 400 error codes from same source IP -->
    <rules_id>31151</rules_id>
    <timeout>600</timeout>
</active-response

Test della nuova risposta attiva ∞

$ bin / agent_control -L

OSSEC HIDS agent_control. Risposte attive disponibili:

Nome risposta: route-null600, comando: route-null.sh

Ora testiamo la risposta su uno dei client OSSEC.

$ bin / agent_control -b 2.3.4.5 -f route-null600 -u 083

OSSEC HIDS agent_control: esecuzione della risposta attiva 'route-null600' su: 083

The above blocks IP 2.3.4.5 using active-response route-null600 on agent 083.

Per verificare che la risposta sia stata eseguita correttamente sul client, guarda in /var/ossec/logs/active-responses.log per qualcosa di simile a questo,

active-response/bin/route-null.sh add - 2.3.4.5 (from_the_server) (no_rule_id)

Ora per verificare l'aggiunta alla tabella di percorso

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
2.3.4.5 

e anche un'altra verifica

# ip route get 2.3.4.5
RTNETLINK answers: Network is unreachable