Sicurezza web for dummies

Voglio parlarvi 5 minuti della sicurezza delle applicazioni con interfaccia web. E lo faro` con qualche semplice suggerimento atto ad evitarvi gli attacchi “casuali”, cioe` non quelli diretti proprio a voi, ma quelli portati avanti da ragazzini annoiati o da botnet. Il senso del titolo dell’articolo, infatti, e` che i “dummies” non siete voi, ma chi vi attacca. Se chi vi attacca e` determinato ad attaccare proprio voi, tutto questo non servira` a nulla (o quasi).

Qualsiasi applicazione ha dei bug, alcuni dei quali potenzialmente sono disastrosi a livello di sicurezza. Moltissime applicazioni web sono scritte con i piedi, e quelle closed source, che a sentire chi le vende sono “sicure” proprio perche` sono closed, sono tipicamente quelle meno sicure di tutte.

Poniamo quindi che abbiate installato una bella applicazione che si e` rivelata un colabrodo, e che sia in atto un attacco a tappeto (worm, botnets o script kiddies). Voi siete  vulnerabili, o perche` non sapete ancora dell’attacco, o perche` non passate il tempo a leggere gli advisory di sicurezza, o perche` e` un zero-day, o magari perche` avete 50 server con la stessa applicazione e vi occorrono un paio di giorni per patcharli tutti.

Vediamo come ridurre il rischio di essere attaccati.

Se e` possibile (se non crea troppo disagio agli utenti) potete proteggere l’applicazione con una password di Apache (o del vostro web server) che dovrete inserire PRIMA del login dell’applicazione stessa. In pratica, anche una password mediamente banale e uguale per tutti gli utenti (legittimi) vi salvera` molto bene dall’attacco casuale, e anche da quello piu` diretto, in effetti.

Se e` possibile, limitate l’accesso solo ad alcuni indirizzi IP (ha senso solo in casi molto rari, pero`)

Se i primi due sistemi sono sono applicabili (ad esempio per una webmail di una azienda con 100 utenti) allora potete sempre ricorrere alla tecnica di difesa piu` vecchia del mondo: nascondervi. Chi attacca non ha tempo da perdere, prende una subnet alla volta e “scanna” gli indirizzi a caccia di uno che risponda sulla 80. Se risponde, allora provera` ad attaccare l’applicazione di suo interesse in modo molto semplice, cioe` con una serie di get http rivolte alle pagine “giuste”. Un esempio banale e` l’attacco che e` stato portato l’anno scorso a RoundCube. Lo script di attacco si connetteva al mio ip, e poi tentava una serie di get a quelle che potevano essere ovviamente le pagine “giuste”, tipo:

  • get /paginabacata.php
  • get /roundcube/paginabacata.php
  • get /RoundCube/paginabacata.php
  • get /mail/paginabacata.php
  • get /webmail/paginabacata.php
  • get /rc/paginabacata.php

Eccetera. Dopo una trentina di tentativi con nomi e percorsi piu` o meno sensati, mollava.

E` quindi evidente che il trucco per non essere attaccati e` semplice: non essere li` dove lui vi cerca.

Per farlo, potete usare queste tecniche:

  • Mettete la vostra applicazione sotto una directory con un nome non ovvio: Roundcube non va sotto “roundcube” o “webmail” o “mail” o “rc” o “round”, ma, per dire, sotto “Posta”. (l’italiano aiuta a non essere presi) Se siete paranoici, sotto “cammello”, cosi` non vi beccano sicuro.
  • Mettete la vostra applicazione in un named virtual host, cosi` gli attacchi (che vanno per IP e non per nome) faranno una get che non verra` mai servita dal named virtual host, ma da una webroot tipicamente vuota.
  • Mettete la vostra applicazione sotto https e NON sotto http. Tutti gli attacchi a tappeto che ho visto in vita mia non usano https.

Usate tutte e tre le tecniche assieme, e sarete ragionevolmente sicuri di non essere vulnerabili ad uno scan a tappeto, quindi di fatto potete vivere un minimo piu` sereni. Il che, per un sysadmin, significa comunque “molto preccupati”.

PS: Questi suggerimenti possono essere messi in atto anche da chi ha un sito hostato da un provider di quelli da due soldi, non solo da chi ha un server personale.

Autore: Kurgan

Sistemista Linux con la fissa della sicurezza

2 pensieri riguardo “Sicurezza web for dummies”

  1. HTTPS senza un certificato emesso da una CA nota ha lo svantaggio che i browser di ultima generazione spaventano a morte l’utente. Qui si ricade nell’esempio dell’organizzazione con tante persone: se sono tante spiegare a tutti che l’errore del browser non e’ un errore e’ un delirio. Se sono quattro gatti, HTTPS vale la pena, posto che il server lo regga come carico.

Spazio per un commento