Jump to content
Sign in to follow this  
Uno

Spunti sull'hardening e la sicurezza (da grande faccio il sistemista)

Recommended Posts

Continuiamo il progetto descritto qui http://www.hostingtalk.it/forum/pannelli-di-controllo-e-hosting-software/11897-da-grande-faccio-il-sistemista-introduzione-ad-una-serie-di-collaborative-tutorial.html.

 

Per chi non volesse fare un minimo di fatica a leggere l'introduzione, questo non vuole essere un tutorial o un how to passo passo esaustivo sull'argomento. Vorrebbe essere solo una sorta di scaletta sulle cose più importanti da verificare per la sicurezza di un server in generale e nello specifico anche per l'hosting. Da questa traccia poi chi è interessato può fare ricerche o anche aprire dei thread con cui approfondire un determinato argomento.

 

MI danno i dati di accesso del server che ho noleggiato, che faccio?

 

Ci sono due scuole di pensiero sul primo passo (di solito, magari ne scopro una terza che non conosco).

Piallare tutto e installare dall'inzio il S.O. oppure controllare quello che già c'è e sistemarlo.

 

Io generalmente, salvo situazioni particolari sono per la seconda via. I sistemi operativi pronti con clic e install di solito sono adattati ai server, quanto meno il kernel. Può però servire di sostituire il kernel perchè si hanno esigenze particolari (che so virtualizzare).

Non ho manie dietrologiche nel pensare che la webfarm mi configuri un server con chissà che robe nascoste... tanto se vogliono hanno l'accesso fisico alla macchina e poi se mi serve per webhosting....

Se avessi altre esigenze userei crittografia tramite client e sul server depositerei solo dati criptati. Ma visto che per ora una banca non ce l'ho ancora.....

 

In ogni caso, quale che sia la via, le prime tre cose che faccio sono, nell'ordine, sistemare

SSHD io personalmente disabilito la password, cambio porta per evitare scanning prolungati e installo i certificati

IPTABLES cioè il firewall, appena cambiata la porta di ssh chiudo tutto lasciando aperta solo quella che ho appunto scelto per ssh. Poi man mano apro per gli altri servizi.

Chiudere tutti i servizi non usati che si usi l'installazione standard o una pulita il S.O. aggiunge servizi che magari a noi non servono, meglio chiuderli. Le porte saranno già chiuse dal firewall all'esterno, ma basta entrare in altro modo e poi dall'interno il firewall non controlla (a meno che non lo si imposti all'uopo, è non è il caso).

 

Dopo ci si può sbizzarrire su altri metodi di verifica, per esempio i sistemi che dopo X tentativi da parte di un certo IP lo bannano (per esempio Fail2ban) o quelli che non ti fanno passare se non "bussi" tipo Port Knock.

Ma questi vanno sempre (eventualmente, non sono necessari per forza) usati in più se li si vuole usare, non per rimediare ad una configurazione assurda di Iptables o alla password di root "paperino".

 

Spunti per i prossimi post in questo 3d:

 

I Log sono nostri amici... anche se pallosi

Entra nella testa del nemico, usa i suoi strumenti per primo

Al topolino lascia il formaggio sotto la molla non nel frigorifero

L'attaccante non può cancellare la traccia che non c'è già più sul server

 

E poi passando ai particolari cenni sui vari servizi che occorrendoci vanno messi in sicurezza.

 

 

Ovviamente gli interventi sono graditi nonchè necessari per farmi continuare :emoticons_dent2020:

 

N.B. finchè parlo da solo, descrivo il mio punto di vista sulla cosa, non è detto che sia perfetto, non mi assumo responsabilità su chi interpretando bene o male ciò che scrivo avesse danni. Per me e con me funziona, poi ognuno valuti con la propria testa.

Share this post


Link to post
Share on other sites

Magari più in la, se non opportuno adesso, iniziamo a parlare delle differenze che emergono a seconda che si lavori in remoto o locale, della presenza o meno di appliance dedicate e delle piccole differenze derivanti dalle distro.

Share this post


Link to post
Share on other sites

Mi sa che prenderò spunto per un articolo se mai mi verrà voglia di scriverlo.

Non mi pare che interessi a nessuno partecipare. Probabilmente ho scritto banalità che sanno in tanti (e questo era preventivato), quindi quelli che le sanno non ritengono di integrare e/o confrontarsi, quelli che non le sapevano (sanno?) non hanno interesse ad approfondire, preferiscono aprire il "post/ticket" quando avranno il problema, piuttosto che capire come prevenire il problema.

 

Io sarò pure grafoloico ma non a questi livelli :emoticons_dent2020:

Share this post


Link to post
Share on other sites

L'attaccante non può cancellare la traccia che non c'è già più sul server.

 

E' una cosa talmente stupida che però a me (a me) è capitato di vedere implementata solo su certi pannelli e/o di certi servizi.

 

Se uno riesce a bucare il server, se ha intenzione di usarlo a lungo, cercherà di mascherare le tracce del suo passaggio e della sua presenza. Darà una aggiustatina ai log e quando faremo i controlli non troveremo nulla.

Però se implemento due righe in bash con cui prendo i dati di accesso (IP, ora, data etc) e li mando immediatamente via mail su un indirizzo esterno al server, sbatto il tutto su .bashrc di root..... l'accesso diverso dal legittimo admin diventa un pò più complicato.

Certo poi se voglio fare le cose per bene devo anche automatizzare il log locale dei miei accessi sui vari server con tanto di ora e data. Magari posso anche configurare un alert quando arriva una mail con un accesso che non risulta sui miei log locali.

 

Questo è un esempio, stupido e poco faticoso da implementare quindi utile anche per il serverino amatoriale, ma in servizi critici si potrebbero trasferire i log (in tempo più o meno reale) e molte risposte dei vari software su altri server

 

Insomma per sintetizzare se sul server una cosa non c'è più non la si può toccare a meno che non si attacchi e buchi anche gli altri server su cui è stata trasferita.

Banale eh? Eppure....

 

 

 

A questo punto qualcuno si chiederà a che servono i log remoti residenti sul server (per la sicurezza).

Adesso io sto parlando di chi riesce effettivamente a bucare il server ed entrare, però ci sono tipi di attacco che non arrivano (e non lo hanno neanche come scopo) a questo. Io sono del parere che una volta bucato il server i log servono a poco a meno che non sia un incompetente entrato per sbaglio. Ma per attacchi esterni aiutano.

Share this post


Link to post
Share on other sites

Non posso che concordare su tutto. Ottiam l'idea dell'email appena uno si logga.

 

Attualmente per i miei server managed consiglio la stessa configurazione suggerita da Uno.

 

Per il resto che politiche adottare?

 

Per php , mysql e servizi simili?

Share this post


Link to post
Share on other sites

Prima di tutto ritengo buona cosa chrootare tutto quello che è chrootabile e che per forza di cose è soggetto a "contatti" diretti con l'esterno, per esempio un bind.

Altri servizi, a parte la difficoltà dell'operazione, se non vengono usati dall'esterno oggettivamente non hanno questa necessità, per esempio un mysql.

 

Altra questione potrebbe essere quante barriere mettere tra l'esterno e il servizio e quanto questo è utile.

Se ho un firewall esterno (hardware apposito o un server a tale scopo dedicato) è inutile avviare anche iptables sul server stesso?

Io dico di no (se ci sono più server interni a quel firewall), anche se... se l'attacco passa direttamente per le porte che devono essere aperte un firewall o 20 non cambia nulla.

 

Il backup: sicurezza passiva spesso trascurata. Non ci salva da eventuali danni, ma volendo in pochissimo tempo possiamo ripristinare tutto. E' importante studiare i backup da questo punto di vista. Una immagine completa del server è comoda e veloce, ma se ho in backup l'immagine del server già compromesso, se la ripristino sono da capo.

I backup vanno fatti su più livelli, quelli per problemi hardware, quelli per problemi di attacchi, quelli per i nostri errori umani.

 

 

Ok ho messo un pò di cose in ordine sparso, senza seguire tanto una logica di percorso, vediamo se stimola meglio un discorso insieme...

Share this post


Link to post
Share on other sites

La questione del chroot da molto da discutere perchè :

 

1. il concetto di chroot è stato esteso e superato dalla virtualizzazione

2. il chrooting risulta spesso molto complesso e presenta dei buchi concettuali di sicurezza

 

1. è vero che esiste la possibilità di far girare in chroot tutti i servizi che vogliamo,ma a fronte di una sufficiente disponibilità economica si può disporre di una vps per ogni demone,portando l'isolamento ad un'astrazione superiore

 

2. portando come esempio un chroot di apache,in alcuni casi è necessario montare la directory /usr/share/php con un bind all'interno della directory di chroot,ponendo ovvi problemi di sicurezza

Share this post


Link to post
Share on other sites

Per il discorso di 1 o più firewall mi viene da pensare che le varie possibili situazioni del tipo firewall hardware a donnine (anche se ridondato, non carica le ios, non trova le config, ecc) stacco e bypasso, o mi collego ad altre reti, ecc.

Poi politiche di log o di manutenzione più numerose per i firewall software.

Share this post


Link to post
Share on other sites
La questione del chroot da molto da discutere perchè :

 

1. il concetto di chroot è stato esteso e superato dalla virtualizzazione

2. il chrooting risulta spesso molto complesso e presenta dei buchi concettuali di sicurezza

 

1. è vero che esiste la possibilità di far girare in chroot tutti i servizi che vogliamo,ma a fronte di una sufficiente disponibilità economica si può disporre di una vps per ogni demone,portando l'isolamento ad un'astrazione superiore

 

2. portando come esempio un chroot di apache,in alcuni casi è necessario montare la directory /usr/share/php con un bind all'interno della directory di chroot,ponendo ovvi problemi di sicurezza

 

Cioè se per esempio fai hosting crei un vps per ogni servizio ed ogni utente?

Specialmente per un lowcost è l'ideale... se vuoi spendere più di quello che incassi :)

 

Il chroot può presentare lo stesso difetto di progettazione di ogni computer, cioè avere qualcuno che digita sulla tastiera

 

@2busy siamo d'accordo, magari se il firewall è doppio eviterei il logging spinto su entrambi a meno che non stia erogando dei servizi molto delicati

Share this post


Link to post
Share on other sites

@Uno colloco in una fascia medio/alta gli utenti che possono ottenere beneficio da una separazione dei servizi su diverse macchine,non intendo certo chi usa hosting lowcost.

 

 

"I Log sono nostri amici... anche se pallosi" qualcuno usa Splunk?Come vi trovate?Se no,quali sistemi alternativi di gestione dei log utilizzate?

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×