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.

  • Ha senso sminuire il proxy Node.js attraverso Apache?
  • ProxyPreserveHost sulle singole regole di proxypass
  • HttpOnly e protegge i cookie con Apache mod_header per tutti i cookie
  • Apache server status di return 404, quindi reindirizzamento alla mia installazione di WordPress
  • Abilitazione di mod_headers su apache2
  • Come abilitare la deflazione di codifica dei contenuti con Apache2 mod_deflate?
  • 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.

  • Che cosa provoca tanti "httpd: <ul> </ ul>" voci in / var / log / messaggi?
  • Mixing Multiple Master Replication (MMR) con Linux-HA
  • Apache serve l'estensione di file alternativa per javascript?
  • Che cosa significa il messaggio di errore 'Tentativo a servire directory' nel log apache?
  • configurare correttamente mod_proxy_html?
  • Apache config: ritorna 404 per singolo <Location>
  • 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.