Domanda

Apri i registri di una dozzina di siti drupali e vedrai alcuni schemi per pacchetti non drupali nelle richieste HTTP che hanno ricevuto una risposta 404. Richieste come /postnuke/article.php, /exchange/logon.asp, /awstats.pl, /wpcontent /, /mailman /, /phpbb/page_header.php, ecc. Ecc.

Quasi il 100% di questi è la scansione di robot per gli exploit. So che ci sono diversi moduli per bloccare queste richieste in base a IP, intestazione HTTP o altri dati chiave.

Ho riflettuto sull'idea di scrivere un modulo che si avvicina in modo diverso.

Invece di provare a bloccare la richiesta, basta memorizzare nella risposta. Per i siti che utilizzano una cache a livello di proxy inversa come la vernice, impostare la massima età per un tempo ridicolmente lungo (1 anno). Il modulo generare semplicemente voci di menu per pacchetti comuni che è molto improbabile che un sito Drupal abbia installato. Includerei l'opzione per escludere un pacchetto specifico, quindi se volessi davvero eseguire Drupal e PHPBB nella stessa root web, potresti ... ma potresti richiedere l'installazione https://www.drupal.org/project/bad_judgement fare quello :)

Mi rendo conto che questo tipo di configurazione può essere fatto anche a livello .htaccess, ma mantenerlo per tutti i bot di pacchetti stanno cercando di sfruttare è oltre l'insieme di abilità di molte persone.

Esiste già qualcosa del genere?

Mi manca qualche ovvia ragione per questo non funzionerebbe. Sembra che ciò migliorerebbe le prestazioni di un sito semplicemente non lasciando mai una seconda richiesta a raggiungere il livello PHP/MySQL per un altro anno (o fino a quando non hai cancellato la cache della vernice)?

Nessuna soluzione corretta

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a drupal.stackexchange
scroll top