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

[Uno]

Continuiamo il progetto descritto qui Da grande faccio il sistemista, introduzione ad una serie di collaborative tutorial.

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

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.

[2busy]

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.

[Uno]

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

[Uno]

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.

[matrix845]

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?

[Uno]

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...

[cxcs]

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

[2busy]

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.

[Uno]

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

[cxcs]

@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?

[2busy]

@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.

Che cosa vuol dire questa cosa?
Se fornisci lowcost non garantisci la sicurezza agli utenti perchè non potrebbero trarne beneficio???

[cxcs]

@2busy se hai clienti che non sono alla ricerca di roba economica puoi lavorare più largo,se devi fare lowcost devi stringere la cinghia un attimino.Mi sa che parlo tedesco su questo forum.

[Uno]

@2busy se hai clienti che non sono alla ricerca di roba economica puoi lavorare più largo,se devi fare lowcost devi stringere la cinghia un attimino.Mi sa che parlo tedesco su questo forum.

Non parli tedesco ma se rileggi hai scritto che vps è meglio di chroot a prescindere.
Era ovvio che parlavo di determinati casi, come è ovvio che a parte il low cost se ho un unico server aziendale (piccola azienda) non è detto che faccia tutti vps per dividere e rendere sicuri i vari servizi, un bel chroot ben fatto aiuta senza appesantire più di tanto.

Tra l'altro stavo parlando più che altro di un singolo server, cosa che mi aspetto più comune tra chi forse sarà interessato a questi 3d.
E' sicuramente un mio errore, non avendolo specificato si parla di sistemi anche composti da più server (reali o virtuali) però comunque non metto su un vps per bindare 10 domini...
Se parliamo di provider con un certo lavoro probabilmente avrà un dedicato solo per quello, non certo un vps.

Però.... ok metto (per esempio) bind su un vps ( o su un dedicato) per conto suo ma se mi bucano bind non si impadroniscono comunque di tutto il vps?
Il chrootare dovrebbe prevenire questo, quindi il paragone proprio non riesco a vederlo ragionandoci un momento, non mi pareva di aver scritto una boiata dicendo che tutto quello che è chrootabile non è male farlo.

[cxcs]

Ma infatti non ho detto che è una boiata.Ci sono questi due filoni di ragionamento,che si adattano al tipo di budget e di volume d'affari,il chroot non esclude altre soluzioni,così come altre soluzioni non escludono il chroot.

[2busy]

Se non intendevi che per isolare i servizi la scelta di chroot o vps sia legata al budget allora ho capito francese, non tedesco, altrimenti più semplicemente stai dicendo chiacchiere