Enorme attacco 404 con URL inesistenti. Come prevenirlo?

Il problema è un intero carico di 404 errori, come riportato da Strumenti per i Webmaster di Google, con pagine e query che non ci sono mai state. Uno di questi è viewtopic.php, e ho anche notato un numero spaventoso di tentativi di verificare se il sito è un sito WordPress ( wp_admin) e per l'accesso cPanel. Blocco già TRACE e il server è dotato di qualche difesa contro la scansione / hacking. Tuttavia, questo non sembra fermarsi. Il referrer è, secondo Google Webmaster, totally.me.

Ho cercato una soluzione per fermare questo, perché non è certamente buono per i poveri utenti reali, per non parlare delle preoccupazioni SEO.

Sto usando la mini lista nera di Perishable Press (che si trova qui ), un blocco dei referrer standard (per siti porno, di erbe, di casinò) e persino alcuni software per proteggere il sito (blocco XSS, iniezione SQL, ecc.). Il server sta usando anche altre misure, quindi si presume che il sito sia sicuro (si spera), ma non sta finendo.

Qualcun altro ha lo stesso problema o sono l'unico a vederlo? È quello che penso, cioè una sorta di attacco? C'è un modo per risolverlo, o meglio, prevenire questo inutile spreco di risorse?

EDIT Non ho mai usato la domanda per ringraziare per le risposte, e spero che questo possa essere fatto. Grazie a tutti per le vostre perspicue risposte, che mi hanno aiutato a trovare la mia via d'uscita da questo. Ho seguito i suggerimenti di tutti e ho implementato quanto segue:

• un honeypot
• uno script che ascolta gli URL sospetti nella pagina 404 e mi invia un'e-mail con l'agente utente / ip, restituendo al contempo un'intestazione 404 standard
• uno script che premia gli utenti legittimi, nella stessa pagina 404 personalizzata, nel caso in cui finiscano per fare clic su uno di questi URL. In meno di 24 ore sono stato in grado di isolare alcuni IP sospetti, tutti elencati in Spamhaus. Tutti gli IP registrati finora appartengono a società di hosting VPS di spam.

Grazie ancora a tutti, avrei accettato tutte le risposte se avessi potuto.

Vedo spesso un altro sito che collega a tonnellate di pagine del mio sito che non esistono. Anche se fai clic su quella pagina e non vedi il link:

• In precedenza il sito avrebbe potuto avere quei collegamenti
• Il sito potrebbe nascondere e servire tali collegamenti solo a Googlebot e non ai visitatori

È uno spreco di risorse, ma non confonderà Google e non danneggerà le tue classifiche. Ecco cosa dice John Mueller di Google (che lavora su Strumenti per i Webmaster e Sitemap) sui 404 errori che compaiono negli Strumenti per i Webmaster :

AIUTO! IL MIO SITO HA 939 ERRORI CRAWL !! 1

Vedo questo tipo di domanda più volte alla settimana; non sei solo: molti siti Web presentano errori di scansione.

1. 404 errori su URL non validi non danneggiano in alcun modo l'indicizzazione o il posizionamento del tuo sito . Non importa se ci sono 100 o 10 milioni, non danneggeranno il posizionamento del tuo sito. http://googlewebmastercentral.blogspot.ch/2011/05/do-404s-hurt-my-site.html
2. In alcuni casi, gli errori di scansione potrebbero derivare da un legittimo problema strutturale all'interno del tuo sito Web o CMS. Come lo dici? Ricontrolla l'origine dell'errore di scansione. Se sul tuo sito è presente un collegamento interrotto, nell'HTML statico della tua pagina, vale sempre la pena correggerlo. (grazie + Martino Mosna )
3. Che dire degli URL stravaganti che sono "chiaramente interrotti?" Quando i nostri algoritmi come il tuo sito, possono provare a trovare più contenuti su di esso, ad esempio cercando di scoprire nuovi URL in JavaScript. Se proviamo quegli "URL" e troviamo un 404, è fantastico e previsto. Non vogliamo perdere nulla di importante (inserisci qui il meme Googlebot troppo attaccato). http://support.google.com/webmasters/bin/answer.py?answer=1154698
4. Non è necessario correggere gli errori di scansione in Strumenti per i Webmaster. La funzione "Contrassegna come risolto" serve solo per aiutarti, se vuoi tenere traccia dei tuoi progressi lì; non cambia nulla nella nostra pipeline di ricerca web, quindi sentitevi liberi di ignorarlo se non ne avete bisogno. http://support.google.com/webmasters/bin/answer.py?answer=2467403
5. Elenchiamo gli errori di scansione negli Strumenti per i Webmaster per priorità, che si basa su diversi fattori. Se la prima pagina di errori di scansione è chiaramente irrilevante, probabilmente non troverai errori di scansione importanti in altre pagine. http://googlewebmastercentral.blogspot.ch/2012/03/crawl-errors-next-generation.html
6. Non è necessario "correggere" gli errori di scansione sul tuo sito Web. Trovare 404 è normale e ci si aspetta da un sito Web sano e ben configurato. Se hai un nuovo URL equivalente, reindirizzarlo è una buona pratica. Altrimenti, non dovresti creare contenuti falsi, non reindirizzare alla tua home page, non dovresti robots.txt non consentire tali URL - tutte queste cose ci rendono più difficile riconoscere la struttura del tuo sito ed elaborarlo correttamente. Chiamiamo questi errori "soft 404". http://support.google.com/webmasters/bin/answer.py?answer=181708
7. Ovviamente - se questi errori di scansione vengono visualizzati per gli URL che ti interessano, forse gli URL nel tuo file Sitemap, allora è qualcosa su cui dovresti agire immediatamente. Se Googlebot non è in grado di eseguire la scansione dei tuoi URL importanti, potrebbero essere eliminati dai nostri risultati di ricerca e gli utenti potrebbero non essere in grado di accedervi.

Ci sono tonnellate di script là fuori che scansionano in modo ottimale indirizzi IP casuali su Internet per trovare vulnerabilità note in vari tipi di software. Il 99,99% delle volte non trova nulla (come sul tuo sito) e lo 0,01% delle volte, lo script solleverà la macchina e farà tutto ciò che il controller di script desidera. In genere, questi script sono gestiti da botnet anonime da macchine che sono state precedentemente pwnd, non dalla macchina reale del kiddie di script originale.

Cosa dovresti fare

1. Assicurati che il tuo sito non sia vulnerabile. Ciò richiede una costante vigilanza.
2. Se ciò genera un carico talmente elevato da influire sulle normali prestazioni del sito, aggiungere una regola di blocco basata su IP per evitare di accettare connessioni dal sito specifico.
3. Impara a filtrare le scansioni per CMD.EXE o cPanel o phpMyAdmin o tonnellate di altre vulnerabilità durante la ricerca nei registri del server.

Sembra che credi che qualsiasi 404 restituito dal tuo server a chiunque avrà un impatto su ciò che Google pensa del tuo sito. Questo non è vero. Solo 404 restituiti dai crawler di Google, e forse dagli utenti di Chrome, influenzeranno il tuo sito. Finché tutti i collegamenti sul tuo sito sono collegamenti appropriati e non invalidi i collegamenti che hai precedentemente esposto al mondo, non vedrai alcun impatto. I bot di script non parlano in alcun modo a Google.

Se vieni attaccato in modo reale, dovrai registrarti per un qualche tipo di servizio del provider di mitigazione DoS. Verisign, Neustar, CloudFlare e Prolexic sono tutti venditori che hanno vari tipi di piani per vari tipi di attacchi - dal semplice proxy web (che può anche essere libero da alcuni provider) al filtro su richiesta basato su DNS, al BGP completo altalene basate sul punto di presenza che inviano tutto il tuo traffico attraverso "scrubbing" dei data center con regole che mitigano gli attacchi.

Ma sembra da quello che stai dicendo che stai vedendo i normali script di vulnerabilità che qualsiasi IP su Internet vedrà se è in ascolto sulla porta 80. Puoi letteralmente installare un nuovo computer, avviare un Apache vuoto, e entro poche ore, inizierai a vedere quelle righe nel registro di accesso.

Questo probabilmente non è in realtà un attacco ma una scansione o una sonda.

A seconda dello scanner / prober, potrebbe essere benigno, il che significa che sta solo cercando problemi in qualche tipo di capacità di ricerca o potrebbe avere una funzione per attaccare automaticamente se trova un'apertura.

I browser Web forniscono informazioni valide sui referrer ma altri programmi possono semplicemente compensare qualunque referrer desiderino.

Il referrer è semplicemente un'informazione che è facoltativamente fornita dai programmi che accedono al tuo sito web. Può essere qualsiasi cosa scelgano di impostarlo su come totally.meo random.yu. Può anche essere un vero sito Web che hanno appena selezionato.

Non puoi davvero aggiustarlo o impedirlo. Se hai provato a bloccare ogni richiesta di questo tipo, finisci per dover mantenere un elenco molto grande e non ne vale la pena.

Fintanto che il tuo host tiene il passo con le patch e previene le vulnerabilità, ciò non dovrebbe causare alcun problema reale.

In effetti sembra una frenesia da bot. Ci sono stati martellati anche da migliaia di IP su molti host, molto probabilmente all'insaputa del sito OP. Prima di offrire alcune soluzioni utili, una domanda che ho è:

D: Come vedi i 404 del tuo sito nel suo insieme negli strumenti per i webmaster di Google? GWT è l'output dei risultati di Googlebots, non l'output di altri bot. Inoltre, quegli altri robot non eseguono JS per l'analisi ... hai qualche tipo di API che va su GWT dove puoi vedere le statistiche del tuo server? In caso contrario, potrebbe essere causa di allarme poiché si tratta di un googlebot che trova errori.

• Se si tratta di errori SOLO googlebot, ciò potrebbe indicare che qualcuno ha installato link al tuo sito su forum e cose per bersagli di bot malevoli umani reali che lo colpiscono. Pensa che harverstor + fioriera sia in esecuzione su un server sfruttato, impostando una tonnellata di obiettivi per i futuri "contratti di spam" su cui passare il portale.

• Se sai davvero che sta riportando le tue statistiche complete sul server, allora hai bisogno di alcuni strumenti. Alcune app e servizi potrebbero aiutarti a ridurlo. Supponendo che si esegue un server Linux:

1) Inizia ad aggiungere IP offensivi a una lista nera di htaccess. Sembra "negare da 192.168.1.1" e 403 glielo proibiranno. Non lasciarti trasportare, basta bloccare i biggens. Controllali contro i siti nel passaggio 4) per assicurarti che non siano veri ISP di peoles. Puoi copiare questo file e incollarlo su qualsiasi account / app oltre il firewall.

2) Installa APF. è davvero facile gestire il firewall tramite SSH in Linux. Mentre costruisci l'ht, aggiungili in APF in questo modo "apf -d 192.168.1.1". Sembra ridondante a causa di APF, ma è portatile.

3) Installa cPanel Hulk e assicurati di autorizzare i tuoi IP in modo che non ti blocchi mai se dimentichi un passaggio. Questa sarà anche una bella fonte di IP da aggiungere a ht + apf. Ha un po 'di intelligenza in modo da poter mitigare in modo intelligente i tentativi di accesso alla forza bruta.

4) Collegati a stopforumspam.com e projecthoneypot.org e avvia i loro moduli. Entrambi aiutano molto a negare le richieste conosciute e identificare + segnalare nuovi bruti / reti / chinaspam. Ci sono anche filtri e-mail che puoi usare, ma Gmail lo possiede quando si tratta di filtri antispam.

5) Dato che i robot non mollano mai, proteggi i tuoi percorsi di amministrazione. Se esegui wordpress, modifica il percorso di amministrazione, aggiungi captcha, ecc. Se usi SSH, modifica la porta di accesso in qualcosa di non utilizzato, quindi disattiva l'accesso root SSH. Crea un "radmin" a cui devi prima accedere, quindi su per root.

• Una nota su captcha, se si esegue il proprio captcha su un sito ad alto volume e non si nega la frenesia dei bot a livello di firewall / ht, potrebbero essere martellare i cicli della CPU a causa della generazione di immagini in tutti quei widget "antispam".

• Una nota sul carico, se si esegue CentOS sul proprio server e si dispone di capacità VPS, CloudLinux è fantastico per il rafforzamento e il controllo del carico. Supponiamo che un bot passi, CageFS è lì per limitarlo in un account. Supponiamo che decidano di fare DDoS .... LVE è lì per mantenere il carico dell'account (sito) limitato per non arrestare in modo anomalo il server. È una buona aggiunta per accentuare l'intero sistema di "gestione errata delle entità" :)

Solo alcuni pensieri, spero che ti aiuti

Spiegazione del problema

Prima di tutto non sei l'unico ad avere questo problema - lo sono tutti. Quello che hai visto è il risultato di robot automatizzati che eseguono la scansione di ogni IP e cercano vulnerabilità comuni. Quindi in pratica cercano di trovare quali cose stai usando e se usi phpmyadmin proveranno in seguito a un mucchio di combinazioni standard di password nome utente.

Sono sorpreso che questo tipo di cose che hai trovato proprio ora (potresti essere tu abbia appena avviato il tuo server). Il problema è che non puoi bloccare il loro indirizzo IP per sempre (molto probabilmente si tratta di un computer infetto e il suo vero utente non è a conoscenza di ciò che sta facendo, inoltre ci sono molti di questi IP).

Effetto SEO

Non ha alcun effetto. Significa solo che qualcuno ha provato ad accedere a qualcosa sul tuo computer e non era lì

Importa davvero?

Certo, queste persone cercano di sondarti per alcuni problemi. Inoltre stanno sprecando le tue risorse (il tuo server deve reagire in qualche modo) e inquinando il tuo file di registro

Come dovrei ripararlo

Ho avuto lo stesso problema che ho provato a risolvere e lo strumento migliore (semplicità da usare vs quello che posso fare con esso) che sono riuscito a trovare è fail2ban

Sei anche abbastanza fortunato perché ho già trovato un modo per risolvere lo stesso problema e lo ho persino documentato qui (quindi non è necessario trovare come installarlo e come farlo funzionare). Controlla la mia domanda su ServerFault . Ma per favore leggi un po 'di fail2ban per sapere come funziona.

Come molti hanno già detto, questo non è un attacco ma un tentativo di sondare o scansionare l'app del tuo sito e / o le funzionalità del tuo server. Il modo migliore per filtrare tutto questo traffico inutile e scansioni potenzialmente pericolose è implementare un WAF (Web Application Firewall). In questo modo verranno catturati tutti i diversi tentativi e contrassegnati e solo successivamente verrà inviato un traffico pulito e legittimo reale ai server e all'app Web.

È possibile utilizzare WAF DNS basato su cloud o dispositivi dedicati. Personalmente utilizzo Incapsula e F5 ASM per diversi siti client. I costi sono bassi fino a $ 500 al mese e aiutano enormemente. Offre inoltre una migliore protezione per i tuoi clienti e riduce le risorse sui server Web stessi, il che ti farà risparmiare denaro e aumentare la velocità, inoltre questi dispositivi offrono conformità PCI 6.6 e recensioni con report.

Spero che sia di aiuto.