Rilevato tentativo di hacking elaborato - ora cosa?

2

Sto sviluppando un'applicazione web basata su php / mysql. Ho preso il percorso complicato e piuttosto che utilizzare un framework o qualcosa che ho costruito le fondamenta della mia app da zero. Tutto questo mentre imparavo a codice DAVVERO (sapevo molto poco, ora sono abbastanza avanzato, ma faaa da esperto o professionista credo ...)

Mi sono creato pagine di errore 404 personalizzate, che registrano l'URL cercato dall'utente, l'URL da cui provengono e tutte le variabili attive nel contesto, compreso l'indirizzo IP. Questo è per rintracciare gli errori sul mio sito e per individuare i tentativi di hacking.

Da quando ho messo in live una versione BETA del mio sito come 5 mesi fa, ho avuto alcuni (meno di 3) bot che cercavano di accedere a wp-login.php Di solito quelli non erano più di 5 richieste fatte e sicuramente da un bot, a causa della velocità con cui sono state fatte le richieste.

Quelli non mi hanno infastidito molto (anche se ho segnalato l'IP su Godaddy, perché il loro nome si è presentato con esso). Dal momento che non uso wordpress e le directory che sono state tentate per la penetrazione non esistono nemmeno.

Oggi tuttavia un indirizzo IP in Spagna ha impiegato 20 minuti sul mio sito e ha effettuato oltre 60 richieste di URL come

  • /base/captcha/index/
  • /join
  • /signup.php
  • /register.php%22%3E%3Cspan
  • /?page=login&cmd=register
  • /sign_up.html
  • /action/sign_up
  • /modules.php?app=user_reg
  • /index.php?app=home&mod=public&act=register
  • /index.php?app=home&mod=Public&act=isEmailAvailable
  • /reg.asp?reg=reg
  • /ucp.php?mode=register&change_lang=en
  • /member/register
  • /includes/captcha.php
  • /login.php?part=register&action=person
  • /User/Register.aspx

L'elenco potrebbe continuare all'infinito ...

Non sono sicuro se si trattasse di un attacco automatico o se ci fosse una persona che sta provando ogni URL , dal momento che sono solo circa 3 richieste al minuto.

Fortunatamente nessuna di queste richieste ha dato alcun risultato, poiché la maggior parte di esse era mirata a directory non esistenti, quelle che hanno cercato di passare le variabili GET non hanno avuto alcun effetto, perché quelle variabili non sarebbero state usate dai miei script.

Quindi, mentre sono un po 'orgoglioso di me stesso, quell'attacco così elaborato non ha fatto nulla, il che dimostra che la mia base di codice è abbastanza solida, e non facilmente penetrante, sono anche nervosa perché mi sento un po' come Avrei potuto essere fortunato ad usare directory e nomi di file piuttosto non convenzionali ... Ero molto attento alla sicurezza quando programmavo la mia applicazione, ma mi sento così debole, a causa del mio background ...

Inoltre mi chiedo quale sia l'obiettivo dell'hacker per provare tutti questi URL. È possibile registrare un account sul mio sito ...?! E le imprese del mio il sito è attualmente super-duper basso ... solo circa un centinaio di indirizzi email è la cosa più preziosa che ho nel mio DB.

L'imprenditore in me pensa che un mio concorrente abbia tentato di penetrare nel mio sito ... MrGreen

Quindi, oltre alle domande indirette evidenziate, le mie domande principali sono:

Che cosa devo fare con le informazioni che ho ricevuto oggi?

Devo mettere in atto meccanismi che blocchino semplicemente gli IP dopo un certo numero di richieste di pagina non riuscite entro un certo lasso di tempo?

Qualcuno ha familiarità con questo attacco specifico?

    
posta olli 21.09.2013 - 21:26
fonte

3 risposte

7

Benvenuti negli intrecci selvaggi.
Entrambi gli attacchi che hai descritto sembrano piuttosto scansioni automatizzate fatte tramite qualche strumento. Alcuni strumenti possono anche limitare le richieste per evitare il rilevamento da parte di IDS, quindi questo potrebbe essere un motivo per una velocità di richiesta lenta della scansione che hai citato.
Questa scansione specifica che hai citato sembra annusare per la presenza di un software del forum sul tuo sito web. (ad esempio ucp.php è un file del forum phpBB).

I wonder what the hacker's goal was to try all these URLs

L'obiettivo dell'attaccante qui è identificare il linguaggio / il linguaggio / il software di scripting in esecuzione su questo dominio.

What should I do with the information I got today?

Bene, se sei curioso di saperne di più sulle intenzioni dietro questi attacchi, puoi cercare l'indirizzo IP su google e controllare se ci sono delle istanze note di attacchi da questo IP.
Ad esempio, ho appena controllato i log del mio server per tali scansioni automatiche in 1 ora passata e ho visto scansioni estese di questo IP 88.190.60.68 . La ricerca di questo su google mi ha portato immediatamente a questo rapporto e questa pagina che fornisce maggiori dettagli su questo IP rouge e le sue attività. Quindi almeno posso stare tranquillo che questo non era un attacco mirato (la maggior parte non lo sono).

Se vuoi fare un ulteriore passo avanti, puoi installare un software come fail2ban e configurarlo per rilevare automaticamente tali scansioni e la lista nera Indirizzo IP per un periodo di tempo specificato.

Is anyone familiar with this specific attack?

Temo che potresti vedere più di tali scansioni man mano che il tuo sito (dominio) diventa popolare / vecchio. Ci sono tonnellate di sceneggiature con varie intenzioni. Alcuni cercano di trovare commenti / pagine di feedback in cui possono pubblicare solo link spam. Altri potrebbero cercare una vulnerabilità molto specifica.

    
risposta data 22.09.2013 - 03:02
fonte
1

Probabilmente sarebbe abbastanza sicuro dire che si trattava di una scansione automatica alla ricerca di script noti con vulnerabilità. In tutta onestà, questo non ha nulla a che fare con la tua capacità di codificare, ma la pigrizia dei copioni in cerca di siti Web imperfetti.

Probabilmente un utente malintenzionato non ha idea di quali script, framework, app e servizi siano in esecuzione sul server se blocchi determinati attributi di intestazione in conformità con le best practice. Dovranno indovinare provando tutte le strutture di directory framework e i file di chiavi noti (come wp-config.php ) e sperando in una risposta 200 OK dal server HTTP. Se recuperano un 200, sanno che lo script è attivo e possono iniziare a restringere i difetti di sicurezza noti, ad esempio, se trovano wp-config.php possono provare l'inclusione remota per ottenere i tuoi vars, possono provare a trovare wp-ajax.php per backdoor o water hole del tuo sito, ecc.

Praticamente, prendi ciò che hai imparato dall'attacco e digita contro di esso. Non nominare alcun file o percorso con file e directory frequentemente scansionati. Rimanendo al di sotto del livello dell'acqua, si spera che il codice resti al sicuro solo per un po '.

    
risposta data 21.09.2013 - 23:31
fonte
0

Is anyone familiar with this specific attack? By looking at the requests, I would venture to say that you were visited by a registration bot.

What should I do with the information I got today? Yes, there are ways that you can use this information to manage/protect your server, but that is a much longer conversation and depends heavily on your network, your security needs, and your need to support clients/customers.

Una sorta di azione sulle informazioni (ad es. autoban / autoblock di IP et cetera) è possibile, come minimo, monitorare ciò che sta accadendo. Anche questa è una lunga conversazione e una miriade di approcci che dipenderanno dagli stessi aspetti principali (rete, sicurezza e supporto) sopra menzionati.

Se non stai già utilizzando una specie di pacchetto analytics sul tuo sito web, allora direi che sarebbe la cosa più utile e utile che potresti raddoppiare come meccanismo di segnalazione per il tuo legittimo utenti e visitatori indesiderati.

    
risposta data 22.09.2013 - 00:50
fonte

Leggi altre domande sui tag