Introduzione a Remo - Un modo semplice per proteggere un’applicazione online insicura con ModSecurity

Diciamo che hai un’applicazione brutta sul tuo server web Apache che è stata installata da alcuni idioti del dipartimento marketing e non puoi né correggerla né rimuoverla. Forse è un problema di risorse, una mancanza di know-how, una mancanza di codice sorgente, o forse anche per motivi politici. Di conseguenza, devi proteggerla senza toccarla. C’è ModSecurity, ma dicono che sia solo per esperti. Un’alternativa semplice è Remo, un editor di regole grafico per ModSecurity che utilizza un approccio di whitelist. Ha tutto ciò di cui hai bisogno per bloccare l’applicazione.

Per il bene di questo tutorial utilizzeremo un’applicazione di test davvero semplice. Una così brutta che nemmeno il tuo dipartimento marketing vorrebbe averla intorno. Ma hey, è solo un tutorial.

';
  echo $_POST['command'];
  echo '
';
  system($_POST['command'], $retval); # necessario per i comandi 'ls'
  echo '

ls.php: Un piccolo script che è meglio rimuovere dal tuo sito mentre puoi.

L’esecuzione diretta di qualsiasi comando shell inviato sotto forma di parametro command rende ls.php un ospite indesiderato su quasi qualsiasi server web - o un perfetto caso di test per provare Remo al fine di proteggerti dai pericoli di questo script. Quindi, cos’è Remo? Su remo.netnea.com imparerai che è pensato come un modo semplice per configurare ModSecurity senza dover diventare prima un esperto di sicurezza. Il secondo aspetto è che Remo scrive regole di whitelist, mentre la maggior parte delle persone utilizza ModSecurity con un approccio di blacklist. La blacklist significa che dici a ModSecurity tutto sugli attacchi noti. La whitelist fa il contrario: si assicura che la tua applicazione riceva solo l’input che desideri davvero ricevere. In modo che ls.php riceva solo comandi ls come suo parametro di comando e inoltre ti assicurerai che non siano possibili trucchi sporchi utilizzando backticks e punto e virgola all’interno del parametro. Per dirla in breve: Remo aiuta a fare la validazione dell’input sul server senza toccare l’applicazione.

Installazione

Puoi provare Remo nella demo online sulla homepage. Quella funziona bene quando vuoi provare Remo senza installarlo prima. Anche l’installazione non è molto difficile, anche senza pacchetti di distribuzione pronti. Assicurati di avere ruby, irb e i binding ruby-sqlite3 installati prima di scaricare.

Ho fatto quanto segue sulla mia macchina di test Ubuntu; dovrebbe funzionare anche per Debian:

aptitude install ruby irb libsqlite3-ruby1.8

Per quanto riguarda Remo, puoi scaricare una release o prendere uno snapshot dell’ultimo albero di subversion. La pagina di download di Remo ti dice quali alberi hanno superato tutti i test unitari. Diciamo che scarichiamo e installiamo una release. Vai alla pagina di download e prendi la release beta 0.2.0. Estrai il tarball e avvia il server WEBrick rails. Dalla riga di comando questo si riduce a:

wget http://remo.netnea.com/files/remo-0.2.0.tar.gz  
tar xvzf remo-0.2.0.tar.gz  
cd remo-0.2.0  
ruby script/server  
direct browser to http://localhost:3000/main/index

Dovresti ottenere qualcosa di simile:

Remo come appare dopo l'installazione.

Siamo un po’ di fretta qui, poiché questo tutorial è pensato per essere breve. Quindi ti mostrerò solo le cose necessarie per proteggere l’applicazione di test. Una sorta di guida pratica. Hai tutto il tempo per esplorare Remo da solo.

Protezione dell’applicazione

Rimuovi tutte le richieste predefinite nella finestra e crea una nuova richiesta.

Aggiunta di una nuova richiesta a Remo.

Fai clic sul testo clicca per modificare e inserisci il percorso della tua applicazione: /ls.php, quindi cambia il metodo http in POST. Apri i dettagli della richiesta e aggiungi un nuovo parametro post utilizzando il pulsante p* accanto ai parametri post. Fai clic sul nome (clicca per modificare) e rendilo command. Questo è il parametro inviato dalla nostra applicazione di esempio ls.php.

A destra del nome c’è il dominio del valore del parametro. Questa è la parte centrale di Remo. Qui definisci quali valori sono accettabili per il parametro. Ricorda, questa è una whitelist: stiamo definendo esattamente cosa è accettabile. Ci sono un paio di valori predefiniti, ma in questo caso dovremo andare con Custom. Se apri i dettagli del parametro command, c’è un campo chiamato Custom regex. Qui Remo cerca l’espressione regolare quando il dominio del valore è Custom. Userò ls[0-9a-zA-Z-\x20_.]{0,64}. Questo è il comando ls seguito da un gruppo opzionale di caratteri costituiti da numeri, lettere, trattini, il carattere di spazio, underscore e punto. Nessun punto e virgola, nessun slash, nessun backtick, nessun umlaut tedesco, nessuna specialità unicode: Questo è il tuo server e non vuoi che ci siano stupidaggini qui.

La protezione per ls.php è in arrivo con la definizione del parametro POST command.

Una richiesta che non soddisfa questa condizione fallirà. Il comportamento predefinito di Apache per una richiesta fallita sarà restituire un codice di stato http 501: Metodo non implementato. Ma cerchiamo di essere gentili: come codice di stato (mancata corrispondenza del dominio) inserisci 302 per il reindirizzamento http e sotto a Location (mancata corrispondenza del dominio) inserisci l’URL della tua azienda come http://www.netnea.com. Quindi qualcuno che non fornisce il parametro corretto verrà reindirizzato al sito web della tua azienda. In realtà puoi rendere il parametro obbligatorio facendo clic su opzionale e sotto puoi impostare un comportamento speciale per la condizione obbligatoria fallita, anche. Ma nel nostro caso, il parametro non deve essere di carattere obbligatorio.

Se ti stai chiedendo come questo parametro di espressione regolare verrà trasformato in una regola ModSecurity, dai un’occhiata alla seguente grafica:

Questo è come una configurazione del parametro Remo viene tradotta in una regola ModSecurity.

Descrive come il tuo parametro Remo viene tradotto in una regola ModSecurity e cosa accadrà durante la valutazione. Si riduce a questo: Ogni parametro di richiesta http viene confrontato con il dominio del valore definito in Remo e se non si adatta, l’intera richiesta viene negata l’accesso.

Metterlo in pratica

Detto ciò, generiamo il set di regole ModSecurity. Fai clic sul pulsante genera nella barra degli strumenti e salva il file che otterrai. Questo è il file di regole nel linguaggio delle regole ModSecurity. Prendi questo file e salvalo in un luogo dove Apache possa trovarlo. Vale la pena dare un’occhiata, tra l’altro, per capire come Remo utilizza ModSecurity. Quindi devi assicurarti che ModSecurity sia abilitato sul tuo server web. Remo genera set di regole ModSecurity 2, poiché c’è stata una grande aggiornamento e estensione del linguaggio di configurazione tra 1.9 e 2.0 e Remo ha bisogno di queste nuove funzionalità. Nel caso in cui la tua distribuzione non fornisca pacchetti ModSecurity, puoi ottenerne la maggior parte da http://www.modsecurity.org. Altrimenti, puoi sempre compilarlo tu stesso. Non è troppo complicato.

È meglio includere il tuo file di regole nella configurazione di apache come segue:

    Include /etc/apache2/rulefile.conf

Quindi ricarica il tuo apache e prova (sto usando lo strumento da riga di comando curl nella dimostrazione, ma il tuo browser andrà bene):

curl --data "command=ls -l" http://localhost/ls.php

-rw-r--r--  1 sam    staff     353 Feb  7 13:05 index.html  
-rw-r--r--  1 sam    staff     248 Apr 23 05:35 ls.php  
...

Quindi questo funziona ancora. Che ne dici di un abuso di ls.php?

curl --data "command=ls -l; cat /etc/passwd" http://localhost/ls.php

  
  
  
  
Trovato
  
Il documento è stato spostato qui.
  
  
Apache/2.2.3 (Debian) PHP/5.2.0-8 Server at railsmachine Port 80
  

Preso l’attaccante! C’è un audit-log definito nel file di configurazione. Per impostazione predefinita, questo si trova in /var/log/apache2/modsec_audit.log. Leggerà come segue nel nostro caso:

...  
--2957a220-H--  
Messaggio: Accesso negato con reindirizzamento a http://www.netnea.com utilizzando stato 302 (fase 2).   
Corrispondenza di "rx ^(ls\x20[0-9a-zA-Z-_.]{0,64})$" contro "ARGS:command" richiesta. [id "1"]   
[msg "Postparameter command failed validity check. Value domain: Custom."] [severity "ERROR"]  
Azione: Intercettato (fase 2)  
...

Prima di passare alla modalità di produzione, assicurati che questo log non cresca troppo. In effetti, potresti voler disabilitare troppi log quando hai finito con la configurazione. Il logfile è configurato da Remo per fare il logging completo delle richieste per scopi di debug per impostazione predefinita. Questo include tutto, anche le password. Quando hai finito con i test, dovresti impostare il parametro SecAuditLogParts nel file di regole su un valore più ragionevole. ABHZ è un’opzione. In questo modo registra solo le intestazioni http e il riepilogo dell’audit di ModSecurity.

Quindi questa è stata una rapida panoramica di Remo. C’è di più da trovare sul sito web di Remo. ModSecurity.org ha una grande documentazione che ti dice tutto sul linguaggio di configurazione. Inoltre, c’è un core-ruleset che ti aiuterà in situazioni in cui non hai tempo per modellare la tua applicazione in Remo. Il core-ruleset è sempre un buon inizio poiché catturerà il 90% degli attacchi con molto poco sforzo.

Remo è lontano dall’essere maturo, ma è pronto per l’uso e, data una base utenti utile, potrebbe svilupparsi in uno strumento interessante per proteggere le applicazioni web. La tua applicazione non deve essere semplice come quella utilizzata in questo tutorial. Applicazioni più grandi con dozzine di URL e molti parametri funzionano bene anche.