È possibile servire pagine specifiche in base all'indirizzo IP?

8

Sono stato il bersaglio di un attacco di forza bruta su due siti WordPress che possiedo. L'attaccante sta usando la buona vecchia cosa XML-RPC per amplificare gli attacchi con password a forza bruta. Fortunatamente abbiamo password estremamente ben generate, quindi dubito fortemente che arrivi mai da nessuna parte.

Ho appena usato iptables per bloccare le sue richieste ogni volta che compare di nuovo (sempre dallo stesso provider di cloud virtuale), ma preferirei di gran lunga modificare il server in modo che ogni volta che il suo indirizzo IP richieda qualsiasi pagina, riceva una risposta che gli dice per ottenere una vita. La maggior parte delle richieste sono POST, quindi idealmente vorrei solo modificare l'intestazione di risposta per includere qualcosa come "Buona fortuna la prossima volta!" o qualcosa di altrettanto soddisfacente.

È possibile? Sono tutt'altro che un esperto di Apache, quindi non sono sicuro di quanto sia difficile implementarlo. Ma anche se mi ci vorranno ore, la soddisfazione non avrà prezzo.

Per riferimento, sto eseguendo Ubuntu 16.04.2 LTS, con Apache 2.4.18 che ospita Wordpress 4.7.3.

apache-2.4 http-headers

— Aurelio
fonte

"sempre dallo stesso provider di cloud virtuale" OVH? Ho notato che molti kiddie di script usano i loro servizi per qualche motivo.

— hd.

No, online.net ... finora non hanno risposto a nessuna delle mie segnalazioni di abuso. Inoltre, la prima volta che ho inviato una richiesta di abuso, ho scoperto che inoltrano automaticamente il reclamo al cliente. Da qui come ha trovato il mio sito web personale. Ottimo lavoro, online.net ....

— Aurelius

25

Installa fail2ban con il jail appropriato e completa l'operazione. Non preoccuparti di dare una risposta personalizzata, poiché è molto probabile che non venga mai vista.

— EEAA
fonte

1

Di sicuro. Ma questo è sicuramente qualcosa che ho sempre voluto fare. Anche se non lo vede mai, solo la possibilità mi fa ridere così forte che quasi piango.

— Aurelio,

14

Bene: 1) L'IMHO che scopre come mostrare un insulto meschino a un kiddie della sceneggiatura è fuori tema qui. 2) In questo modo consumerai comunque le tue risorse di apache, mentre fail2ban / iptables blocca le richieste a monte in modo che la tua applicazione non debba mai occuparsene.

— SEE

1

Oh certo. Ma voglio divertirmi un po 'prima del divieto permanente. Che sia meschino o no, voglio solo ridere, e questo è su richiesta della persona che usa il server.

— Aurelio,

4

@Aurelius, se conosci l'ip, e questa persona non lo maschera perché non lo fai nell'app stessa, php in questo caso. Basta verificare se è ip xx.xx.xx.xx e se è solo uccidere lo script con una risposta,die("blah blah");

— Miguel

Accettato come risposta, soprattutto perché non sapevo di fail2ban e quindi è davvero utile in generale. La risposta di Miguel sopra, così come la risposta di BlackWebWolf qui sotto, sono entrambe le cose che esaminerò!

— Aurelio

5

C'è una possibilità, e l'abbiamo fatto parecchio, per invertire possibili attacchi. Usa iptables per reindirizzare il provider cloud (intervallo di indirizzi) su una porta diversa e fornire una risposta all'attaccante, anche in semplici intestazioni.

In Apache puoi modificare le intestazioni con l'esempio:

Header set GetOut "Better luck next time!"

— BlackWebWolf
fonte

Hehehe !! Ecco di cosa sto parlando. Buona idea! Lo esaminerò.

— Aurelio,

5

questa strategia probabilmente ritorcerà contro la risposta, perché consente all'aggressore di sapere cosa sta funzionando e cosa non lo è, è molto meglio passare silenziosamente la richiesta a nulla e non far scattare alcun flag di avviso nel suo software di attacco bot. Restituire idealmente l'html della pagina richiesta, ad esempio. non sanno mai che li hai catturati, non succede nulla e il tuo sito è più sicuro. Resisti alla tentazione di farglielo sapere, è sempre un ERRORE. Li aiuta semplicemente a eseguire il debug del problema. Nel tuo caso, passa semplicemente a intervalli IP più dinamici, ecc., Rendendo il problema MOLTO più difficile da risolvere.

— Lizardx,

1

Hai ragione, non è consigliato - è anche forse pericoloso. La strategia con honeypot è sempre migliore, ma la domanda era chiara: come

— trollare

Non mi interessa davvero se si tratta di un errore: ho installato Fail2ban e verrà comunque bandito. Dubito fortemente che andrà davvero ovunque; per quanto ne so, le recenti versioni di WordPress hanno effettivamente risolto questo bug di sicurezza? Per non parlare del fatto che le password brutali sono più lunghe di 20 caratteri .... sì, non accadono nella vita del nostro universo.

— Aurelio

blackwebwolf, è simile a qualcuno che chiede come implementare l'estensione mysql_ deprecata di php, mentre si può tecnicamente rispondere a quella domanda, quella risposta è sbagliata perché la vera risposta significa farlo nel modo giusto, in quel caso, ad esempio, usando mysqli_ invece o xpdo. È solo l'idea, che molti di noi hanno fatto anche nel nostro passato, che rispondere in qualche modo come la pesca a traina sia qualcosa di diverso da un enorme negativo, dovrebbe essere corretto, perché è un grave errore e se uno ha mai sofferto a causa di quell'errore, si capirà immediatamente perché la domanda era sbagliata.

— Lizardx,

3

Questo è molto semplice con ModSecurity che è un modulo WAF di terze parti per Apache. Sebbene implichi l'apprendimento della sua sintassi del linguaggio delle regole.

È inoltre possibile utilizzare ModSecurity per interrompere la connessione anziché rispondere a tutti.

Detto questo, installare ModSecurity proprio per questo, quando, come altri hanno suggerito, è probabile che le risposte vengano ignorate potrebbe essere eccessivo.

— Barry Pollard
fonte

2

Andrei con fail2ban e rilasciando richieste da luoghi noti di abuso. E se ritieni che la colpa non sia del fornitore di servizi dell'aggressore, segnala gli attacchi al loro indirizzo e-mail di abuso.

Se vuoi passare il tempo a creare qualcosa che rallenti l'attaccante, potresti provare a creare un tarpit . Innanzitutto devi ovviamente sapere da dove provengono gli attacchi. Quindi potresti usare apache per reindirizzare la richiesta dall'ip (range?) A uno script specifico. Questo potrebbe fare il trucco anche se non l'ho provato da solo. Quindi implementa solo uno script che, ad esempio, stampi un punto (o qualcosa da / dev / null) ogni 15 secondi per mantenere la connessione dell'attaccante aperta indefinitamente.

Poiché l'attaccante sta molto probabilmente usando degli script per attaccare il tuo sito, potrebbe essere necessario del tempo per notare che gli attacchi si sono arrestati, poiché le connessioni sono tutte apparentemente attive, non ci sarà timeout e la richiesta non verrà negata sul posto.

Il problema è che dedichi tempo e risorse a qualcosa che probabilmente non sarà utile quanto la preoccupazione più importante: proteggere il tuo login. È difficile attaccare quando non sai dove attaccare. Considera alcuni dei seguenti:

limitare l'accesso alla pagina di accesso (solo la tua intranet? ip range? vpn? altro?).
aggiungi reCaptcha o un'altra domanda di verifica per accedere.
utilizzare l' autenticazione a più fattori .
nascondi la tua pagina di accesso. Se possibile, non collegarti ad esso dalla tua pagina principale e non utilizzare / login o altra posizione ovvia.

— Comunità
fonte

Grazie per le informazioni! Quindi, per chiarire le cose, A) i due utenti che sono in grado di accedere hanno password lunghe generate casualmente. B) C'è una sorta di captcha nella pagina di accesso. C) Sto cercando di far funzionare .htaccess per impedire l'accesso a quella pagina. Tuttavia sembra che gli standard per .htaccess siano cambiati più volte - continuo a vedere sintassi diverse ovunque e finora htaccess funziona a malapena.

— Aurelio

Inoltre, ho segnalato tutti gli attacchi a online.net senza alcuna risposta.

— Aurelio

Alcuni consigli utili per htaccess: stackoverflow.com/questions/6441578/… (consiglio vivamente l'autenticazione digest).

Guardando i commenti su questa pagina, digest non sembra un'ottima idea? httpd.apache.org/docs/2.4/mod/mod_auth_digest.html

— Aurelius

1

Mi hai portato lì. Sì, me ne sono ricordato dal momento in cui ho usato l'autenticazione digest e quindi non avevamo https ovunque. Il motivo per cui non utilizziamo password htacces è che non è una soluzione a lungo termine. Va bene usarlo per nascondere qualcosa una settimana prima della pubblicazione, ma per l'uso quotidiano non vuoi un altro livello di password. Non è nemmeno molto più sicuro. Quando la risorsa è a posto che non viene mostrata affatto in Internet pubblico, allora siamo sulla strada giusta.