mod_security 960015 blocca Google e altri buoni bot

la regola mod_security 960015 mantiene la cattura di Google e altri buoni bots. Ho il seguente nel vhost per impedire che i buchi siano catturati:

SecRule REQUEST_HEADERS:User-Agent "Mail.ru" log,allow SecRule HTTP_USER_AGENT "Mail.RU_Bot" log,allow 

Stesso per Google e Yandex.

  • Apache: SSLCertificateKeyFile: il file non esiste o è vuoto
  • Autenticazione di base solo in DirectoryIndex
  • mod_deflate Codici supportti per la compressione
  • Comando per verificare la validità dei file di configuration del server Apache
  • Sottodomini di wildcard automatici su Apache
  • Via logwatch, ottengo i messaggi che la radice sta aprendo sessioni "-> nessuno". È una preoccupazione per la sicurezza o un normale funzionamento?
  • Funziona il 99% dei tempi, tuttavia non riesce ad altre volte per una ragione veramente bizara, ecco l'esempio di log per Mail.ru bot:

    Di successo:

     217.69.134.79 - - [07/Mar/2014:10:17:13 +0400] "GET / HTTP/1.1" 200 189934 "-" "Mozilla/5.0 (compatible; Linux x86_64; Mail.RU_Bot/Fast/2.0; +http://go.mail.ru/help/robots)" [Fri Mar 07 10:17:13 2014] [error] [client 217.69.134.79] ModSecurity: Access allowed (phase 2). Pattern match "Mail" at REQUEST_HEADERS:User-Agent. [file "/etc/apache2/sites-enabled/xxx"] [line "28"] [hostname "xxx"] [uri "/"] [unique_id "UxlkaQp-d4EAABU9BSIAAAAV"] 

    E il prossimo minuto non riesce:

     217.69.134.79 - - [08/Mar/2014:02:14:19 +0400] "GET / HTTP/1.1" 403 389 "-" " Mozilla/5.0 (compatible; Linux x86_64; Mail.RU_Bot/2.0; +http://go.mail.ru/ help/robots)" [Sat Mar 08 02:14:19 2014] [error] [client 217.69.134.79] ModSecurity: Access denied with code 403 (phase 2). Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/share/modsecurity-crs/activated_rules/ modsecurity_crs_21_protocol_anomalies.conf"] [line "47"] [id "960015"] [rev "2.2.5"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "xxx"] [uri "/"] [unique_id "UxpEuwp-d4EAAEMnBFQAAAAE"] 

    So che il modo giusto è fare ricerche inverse, ma rallentano il sito web e voglio avere alless una certa sicurezza, ma in questo momento non posso usare il 960015 perché blocca Google e altri. Allo stesso tempo è una regola molto utile che ha catturato 100s di bots cattivi.

    Se qualcuno sa come impostarla con la ricerca inversa che effettivamente functionrà e consentirà a Google e altri buoni bots di indicizzare – siete invitati a pubblicare qui. Tuttavia io sto anche cercando una soluzione veloce e sporca per farlo funzionare in questo momento, poiché una certa sicurezza è migliore allora nessuna sicurezza.

  • Rails app (Redmine) sul passeggero di Phusion
  • Come posso installare Apache con una versione specifica?
  • Stranezze di latenza di connessione tcp da 3 secondi (Linux, HTTP)
  • Distriggersre errori e registri di accesso per un host virtuale
  • Essere inondati da wpad.dat
  • C'è qualcosa di diverso nei requisiti dei nameserver per il TLD di .ORG?
  • 2 Solutions collect form web for “mod_security 960015 blocca Google e altri buoni bot”

    Innanzitutto un disclaimer: sono l'autore di Bad Behavior , un prodotto simile e alcune delle regole di base di ModSecurity sono state derivate da Bad Behaviour.

    RFC 2616 afferma che l'intestazione Accept DOVREBBE essere presente in tutte le richieste. Si noti che questo non è un requisito assoluto, quindi un utente-agente è ancora conforms a condizioni (come definito nella RFC) se non invia questa intestazione.

    La ragione per negare le richieste senza un'intestazione Accept è che tutti i browser web regolari inviino l'intestazione, mentre molti bot non lo fanno. In pratica, però, dopo aver visto milioni di richieste, alcuni "buoni" bot non inviano l'intestazione Accept. Quindi questa regola non è perfetta e genera falsi positivi.

    Bad Behaviour non li blocca a less che la richiesta sia una richiesta POST. Questo riduce lo spam e riduce i falsi positivi a circa zero, ma passa ancora ad altri bot. Nella mia esperienza, molti di essi sono comunque catturati da altre regole.

    Nella tua situazione, disattivo questa regola. Non ti sta acquistando altrettanto da pensare. Se lo si desidera, è ansible modificarlo in modo che esso si applica solo alle richieste POST.

    Ecco una regola modificata che si adatta allo scopo, è stata eseguita per 48 ore, Google e altri funzionano bene mentre i cattivi sono ancora catturati, wohoo!

    Aggiungi questo al vhost in questione:

     SecRule REQUEST_HEADERS:User-Agent "Google|Mail|Yandex" "phase:1,t:none,pass,nolog,ctl:ruleRemoveById=960015" 

    2015 Aggiornamento con una situazione più recente – i truffatori hanno intensificato e ora per lo più submit falle intestazioni che fingono di essere Google, necessarie diverse strategie di sicurezza.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.