Filtro per XMLRPC di worpress

Il modulo di Remote Procedure Call di WordPress è molto utile per interfacciare il proprio blog con il mondo esterno, ma è anche un punto di ingresso molto apprezzato dai vari bot a caccia di password facili e sistemi non aggiornati.

Se nei log compaiono troppe cose simili a questa:

91.121.108.229 - - [30/Nov/2015:03:14:19 +0100] "POST /xmlrpc.php HTTP/1.0" 200 560 "-" "-"

E’ ora di preoccuparsi.

Fail2Ban

Gli attacchi ad un dispositivo connesso ad internet si dividono in due categorie (10 per i nerd). Gli attacchi perpetrati da chi vuole le risorse del dispositivo e da chi vuole guardarci dentro.

I primi sono perpetrati da sistemi automatici che cercano nella massa, testando le vulnerabilità più diffuse in modo sistematico per sfruttare la vostra connessione, il vostro spazio di archiviazione o la vostra potenza di calcolo. I secondi sono messi in atto per motivi economici, politici o personali per capitalizzare dati sensibili o farvi fare una bella (?) figura.

Molto probabilmente l’unico tipo di attacco con cui vi troverete ad avere a che fare è il primo tipo. Fail2Ban è una risposta reattiva a questo tipo di attacchi. La strategia sottostante è di base questa: se un attacco è condotto da un bot proverà tutte le vulnerabilità più diffuse molto velocemente fino a trovarne una effettivamente esistente sul dispositivo target. Questo pattern è facilmente riconoscibile dall’analisi dei log, un bot difensivo (fail2ban) può riconoscere i primi tre/quattro attacchi che non vanno a buon fine per bannare l’ip sorgente prima che trovi la vulnerabilità che effettivamente c’è (reperibile al decimillesimo tentativo) per un tempo sufficientemente lungo a rendere inefficace l’attacco di forza bruta.

La configurazione di fail2ban va calibrata attentamente per trovare l’equilibrio tra gli errori che si possono generare dalla normale navigazione ed un efficace riconoscimento di questi bot.

Gli obbiettivi che ho scelto di monitorare sono, tra gli altri:

  • Richieste di componenti attivi non offerti dal server. Se supporto solo PHP, e tu mi chiedi script asp, perl, cgi, python o altro … c’è qualcosa che non va.
  • Richieste di proxy verso altri server. Non esiste, un webserver non è un proxy, se cerchi di sfruttare uno script o un modulo per fare qualcosa di non previsto … sei bannato.
  • Autenticazioni http. Se sbagli la password piu di 3 o 4 volte … devi aspettare almeno 10 minuti per riprovare.
  • Autenticazioni di webapp. Idem come sopra.
  • Richieste di risorse non esistenti. Una url sbagliata capita, magari un link rotto o una pagina indicizzata tempo fà. La richiesta massiva di risorse non esistenti, magari cercando vulnerabilità nel sistema delle virtual directory è un indizio chiaro di attacco.

Alcuni link sono già finiti nel post settimanale automatico originato da delicious. Ci sono delle imperfezioni negli script quindi copiare va bene, ma cercando di capire cosa si copia ;).

 

Addio all’hosting parte 2

La piattaforma che ho scelto è nginx per le risorse statiche e come reverse prowxy, php-fpm o tomcat 8 per le app, mariadb per la persistenza.

Ma la prima cosa da far funzionare è la persistenza, in quanto le app è facile mantenerle sull’hosting attuale fino alla scadenza ma la persistenza deve essere spostata per prima.

Ma per la persistenza serve una piattaforma di gestione … il che significa l’odiato/amato phpMyAdmin e quindi un server php funzionante. Quindi facciamo le cose in ordine … questa è la guida da cui ho tratto ispirazione -> LINK. Poi forse la traduco con le personalizzazioni che ho fatto, o forse no.

Ora probabilmente php deve essere configurato per gestire l’upload di file un pò piu grossi della configurazione standard a meno che i vostri database siano microscopici.

Quindi su php.ini

post_max_size = 50M
upload_max_filesize = 50M

In caso di DB molto grossi può essere utile comprimere in zip il dump e alzare il limite della ram assegnata a php e il timeout. Ad esempio

php.ini :

max_input_time = -1
memory_limit = 128M

(Sarebbe bene riportare questi parametri a valori piu cautelativi una volta terminata l’importazione, sopratutto per il max_input_time)

Scarichiamo phpMyAdmin e installiamolo su un virtual host fatto apposta. Noip.com offre la possibilita di creare un pò di domini di terzo livello gratuitamente e può essere utile per il nostro scopo.

In alternativa se proprio phpMyAdmin non digerisce il dump c’è sempre l’importazione da linea di comando. L’istruzione è questa :

mysql -u <username> -p -h localhost <database_name> < dumpfile.sql  

Per ogni database si dovrebbe essere un utente diverso, momentaneamente abilitato alla connessione da qualsiasi host con privilegi sui soli dati (SELECT/INSERT/UPDATE/DELETE) per il solo database che deve usare. Non cadete nella tentazione di assegnare ad un utente con accesso remoto tutti i permessi su tutti i database.
Terminata la migrazione bisognerà disattivare l’accesso da remoto.

I permessi possono essere testati con lo stesso phpMyAdmin.