Webserver hardening - come migliorare la sicurezza ?

[nanotek]

Aprire un webserver all'esterno è sempre un rischio (piccolo ma concreto), ora vista chè è arrivata in zona la fibra potrei farci un pensierino...
Quello che mi dà da pensare è però la sicurezza.
I servizi da esporre all'esterno sarebbero una comune cartella ftp e un'applicazione su webserver apache/php.
Prima cosa da fare è naturalmente controllare che l'applicazione php non sia un colabrodo in fatto di sicurezza (quindi un sistema di login sicuro).
Seconda cosa è difendersi da piccoli attacchi che possono buttare giù il server o fare tentativi di login massivi. Per questo scopo pare che il gold standard sia fail2ban. Non ho però capito come può funzionare.
Richiede iptable, giusto ? (Sul sito dice che è facoltativo ma non capisco come...)
Come rileva dal log di apache che è fallito un tentativo di login nell'applicazione php ?

[Tasslehoff]

Mai usato fail2ban, però imho la questione va ben al di la di un semplice servizio da installare o far girare sul server.

Anzitutto usare il protocollo ftp (liscio e in chiaro) è già di per se una possibile fonte di problemi, esistono alternative ben più comode e sicure (es webdav via https o sftp).

Per sistema di login sicuro cosa intendi?
L'uso del protocollo https è scontato (anche con certificato self signed o CA trustata) ma ciò non significa che sia sicura.
Dato che la action della form andrà necessariamente a interagire con il repository degli utenti va da se che è un punto molto delicato, occorre quindi essere certi che i campi passati dalla form siano correttamente validati per evitare attacchi sql injection.

La rilevazione di un fallito login dipende da come è fatta l'autenticazione.
Se si tratta di basic authentication allora ti basta cercare http response 403 nei log del webserver.
Se invece si tratta di una form applicativa la cosa va gestita a livello di codice, puoi redirigere l'utente ad una pagina in caso di errore e controllare le get http a quella pagina, oppure fare un modo che ad esempio ti invii una notifica.

Di certo una buona misura di sicurezza è cercare di mascherare il più possibile il prodotto che intendi usare (specialmente se si tratta di uno dei soliti cms php), tenerlo sempre aggiornato e limitare l'accesso alle pagine critiche.
Ad esempio puoi fare in modo che l'accesso alla form di login del backoffice venga permesso solo da determinati ip, oppure stabilendo un percorso di navigazione non standard e controllando la referer url.

[nanotek]

Il backoffice non può essere bloccato su certi ip.. gli ip di provenienza esterna sono dinamici..

Dato che la action della form andrà necessariamente a interagire con il repository degli utenti va da se che è un punto molto delicato, occorre quindi essere certi che i campi passati dalla form siano correttamente validati per evitare attacchi sql injection.

Questo è sicuramente da controllare..

Il mio dubbio è che un piccolo webserver è facile da "buttare giù".. basta fare un 100 - 200 connessioni ravvicinate/contemporanee.. e ha già mangiato il gigabyte di ram a disposizione e probabilmente va in crash.. inoltre è meglio bloccare tentativi continui fatti per provare login e password... per questo stavo valutando di mettere fail2ban.. ma effettivamente pare inutile/poco utile perchè rileva i tentativi di login falliti dal log di apache quindi solo se è un'autenticazione base di apache che non è il caso di un'applicazione php.

[Dane]

prima di tutto dovresti decidere da cosa proteggerti.

ddos, soluzioni quick&dirty...
sul firewall puoi limitare il numero delle connessioni in base all'IP sorgente. Se blocchi un po' di IP asiatici magari riduci un po' il problema dei ddos amatoriali.

Per farla più cattiva puoi giocare con il tcp tarpit (così all'attaccante passa la voglia di prendersela con te usando metodi barbari).

bruteforcing: per bannare ip che tentano accessi puoi usare fail2ban.

protezione dell'applicazione: autentica a livello di webserver (dato che le applicazioni non sempre vengono mantenute...)


Come sempre: dipende cosa devi fare...

[nanotek]

Direi che per ora la protezione si può limitare a bruteforcing e ddos.

Il problema nell'usare fail2ban è che l'applicazione PHP non notifica ad apache che il tentativo di login è fallito. Se un login fallisce non c'è traccia di ciò nei log di apache.

[Tasslehoff]

Originariamente inviato da nanotek

Il backoffice non può essere bloccato su certi ip.. gli ip di provenienza esterna sono dinamici..

Appunto, se è così puoi fare come ho suggerito, ovvero inserisci una semplice regola di rewrite nel virtualhost (o in un file .htaccess se preferisci e se li hai abilitati) dove controlli il referer url.
Stabilisci una pagina di accesso (es http://www.domain.tld/passaprimadaqui.html) e crea una regola di rewrite dove neghi l'accesso alla form di login (e alla action) se il client non ha la variabile HTTP_REFERER valorizzata con la url che hai deciso di utilizzare.
Come misura preventiva puoi anche bloccare le POST dirette senza referer, però questa è una misura che devi valutare in base al sito.

La totalità dei tentativi di bruteforce avviene facendo una post diretta alla action delle form di login, non certo navigandosi i siti per benino come farebbe un utente normale.
In questo modo le blocchi sul nascere, anzi nella regola di rewrite puoi scatenare degli http reponse code compatibili con fail2ban (es Forbidden).

[nanotek]

Adesso ho capito cosa intendevi
L'applicazione però non ha nessuna pagina pubblica (accessibile senza login). Sarebbe da aggiungere.. e sarebbe l'unica.. quindi si perderebbe l'efficacia di questa tecnica che però è molto interessante per la gestione di un normale sito.

[Tasslehoff]

Originariamente inviato da nanotek

Adesso ho capito cosa intendevi
L'applicazione però non ha nessuna pagina pubblica (accessibile senza login). Sarebbe da aggiungere.. e sarebbe l'unica.. quindi si perderebbe l'efficacia di questa tecnica che però è molto interessante per la gestione di un normale sito.

Giusto per capirci, l'applicazione è pubblica (=esposta a web), solo non ha pagine ad accesso anonimo, intendevi questo?
Anche in questo caso cmq la soluzione che ti ho suggerito è fattibilissima, già solo bloccare le POST che non hanno HTTP_REFERER proveniente dal vostro sito bloccherebbe la stragrande maggioranza dei tentativi di bruteforce (nel senso che quelli andrebbero diretti a fare una post sulla action della form di login senza alcuna referer url).

Cmq se anche esponessi una pagina statica non succederebbe nulla, un bot che cerca di fare bruteforcing non si metterebbe certo a fare get http a casaccio componendo url casuali, non avrebbe alcun senso (infatti di solito seguono schemi predefiniti con url corrispondenti alle pagine critiche dei soliti cms, piuttosto che altri pattern riconducibili a vulnerabilità grossolane e superate).

Va da se poi che il webserver deve girare con utenze non amministrative, non deve avere accesso a file critici del sistema operativo e idealmente dovrebbe essere chrootato (anche se oggettivamente quasi nessuno lo fa).

[nanotek]

Esatto, l'applicazione richiede il login per qualsiasi cosa. L'unica pagina a cui si accede senza il login è la pagina che richiede il login.

Non è basata su alcun cms.. è totalmente fatta da zero. In realtà poi consta di poche decine di script php. Fa' caricare dei file, fa' partire l'elaborazione degli stessi, visualizza la percentuale di elaborazione, quando finito fa' scaricare il file elaborato e produce un mini-report sul lavoro svolto e i tempi richiesti.

Documentandomi un po', leggevo che la tecnica di bloccare i POST senza referer del sito è poco usata perchè tipicamente i bot inviano come referer la pagina stessa del login. Però sarebbe comunque una sicurezza in più.

Il webserver come al solito gira con utente www-data del gruppo www-data che non è amministratore.