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

[cxcs]

@2busy saranno chiacchiere per te.Ogni discussione sul forum prende la piega "del chi ce l'ha più lungo" come diceva Rebel in un altro post.Tanti saluti

[Uno]

Ogni discussione sul forum prende la piega "del chi ce l'ha più lungo"

Oggettivamente hai iniziato tu, comunque non serve che litighiamo.
E' un peccato che ogni discorso che potrebbe farci uscire dal "cerco hosting a 5 euro" debba morire. Possiamo fare un piccolo sforzo per dialogare senza "tirarlo fuori per misurarlo"


Io personalmente più che per il budget dico che chroot o vps sono proprio due sistemi con finalità diverse anche se alla base hanno lo stesso principio.
All'inizio si usava il chroot anche come vps, si installava un intero sistema in chroot (ovviamente Linux su Linux) per fare esperimenti, una sandbox.
Ma il vps è una evoluzione per l'uso di un S.O. completo e il chroot è rimasto buono per separare singoli servizi su un sistema.
Come detto sopra se creo più sistemi (vps o dedicati a parte) per dividere i servizi ciò non toglie che quei sistemi sono soggetti agli stessi pericoli che aver tutti i servizi sullo stesso sistema.
Ok mi fanno fuori il vps o il dedicato con bind (esempio eh) e non toccano gli altri vps con altri servizi, ma pur sempre quel vps o quel dedicato possono essere usati dall'attaccante che è la cosa che più mi interessa nel discorso sicurezza... altrimenti i backup sarebbero più che sufficienti per non farmi fare tanta fatica.

Discutiamone...

[2busy]

Mi scuso per i modi, evidentemente non adeguati, ma per piacere non dite che si fa tutto per fare a gara dai...

Volevo semplicemente dire che per esempio Seeweb per i suoi hosting high-end non utilizza assolutamente un vps per ogni cliente, figuriamoci per ogni servizio di ogni cliente; molto più probabilmente chroota (che brutta espressione ) i servizi accoppiati sulle macchine (ns/web/ftp, db/mail).
Come io, io vincenzo non io discorsivo, per separare i miei servizi di gran lunga infimi se confrontati a Seeweb uso tranquillamente vps.
Senza poi contare il discorso di Uno di separare completamente l'ambiente del servizio dall'os a prescindere...

[AndDM]

Salve, scrivo qui in quanto il post non mi pare troppo vecchio. Ho visto che le mie richieste potrebbero sfociare in un'altra discussione, mi rimetto ai moderatori per le modifiche eventuali.
Ho dei dubbi sui test da eseguire per validare le politiche di iptables e della sicurezza in generale, volevo qualche consiglio sulle tecniche di security scanner da adottare.
Dato che un attaccante potrebbe mettere mano ai log o ai comandi di monitoraggio, è consigliato affidarsi a sistemi come nagios e simili?
L'uso di aide è pratico dal punto di vista della manutenzione?
Dal punto di vista degli aggiornamenti, è sempre bene farli o scegliere un approccio selettivo?
Volevo riaprire la discussione dato che la trovo molto interessante.
Saluti.

[Valeriano Manassero]

Ho dei dubbi sui test da eseguire per validare le politiche di iptables e della sicurezza in generale, volevo qualche consiglio sulle tecniche di security scanner da adottare.

Puoi partire da Nessus per fare qualche scansione e farti un idea con qualche report. Poi i report vanno interpretati, non esiste tool che sostituisca la procedura di hardening.

Dato che un attaccante potrebbe mettere mano ai log o ai comandi di monitoraggio, è consigliato affidarsi a sistemi come nagios e simili?

Il monitoring è cosa buona, ovviamente gli host che fanno montoring devono essere hardenizzati a loro volta.

L'uso di aide è pratico dal punto di vista della manutenzione?

Che sappia io non ha nulla a che vedere con la manutenzione, ma con l'integrità.

Dal punto di vista degli aggiornamenti, è sempre bene farli o scegliere un approccio selettivo?

Un sistema deve essere costantemente up to date ma gli aggiornamenti non si tirano a caso. Prima di aggiornare ogni pacchetto è buona norma vedere che cosa è stato implementato nella nuova versione per evitare conflitti e/o variazioni di struttura dipendenze.
So che molte distro lnx oggi automatizzano tutto ciò e *teoricamente* sei sempre a posto, ma sulle tue macchine devi essere tu ad essere certo che non succedano casini e ne ho viste di cose undocumented (del resto il software open è AS IS, le responsabilità, giustamente sono tue).

[AndDM]

@Valeriano Manassero: per aide mi sono espresso male, infatti è un controllo integrità che, da quel che ho capito, permette anche di monitorare cambiamenti sui file ed i comandi. Ne leggevo l'utilità relativa all'individuazione di eventuali cambiamenti apportati dai rootkit.
Quindi in definitiva, meglio prevenire con hardening e iptables che mettere mano a log e sistemi di monitoraggio che a server compromesso potrebbero essere di fatto inutili a ricostruirne il reale stato.
Che i report vadano interpretati me ne ha dato dimostrazione rkhunter che in locale mi segnalava la presenza di rootkit seppur non ci fossero.

[Valeriano Manassero]

@Valeriano Manassero: per aide mi sono espresso male, infatti è un controllo integrità che, da quel che ho capito, permette anche di monitorare cambiamenti sui file ed i comandi. Ne leggevo l'utilità relativa all'individuazione di eventuali cambiamenti apportati dai rootkit.

Personalmente non ho mai amato molto questo approccio per vari motivi.
Uno su tutti è la praticità, se un host comincia ad essere usato in maniera intensiva, dovresti passare la giornata solo a capire modifiche ed aggiornamenti del tuo filesystem e comunque non ne verresti a capo poichè, se succede qualcosa di sospetto, prima di capire esattamente cosa succede il sistema potrebbe essere totalmente compromesso.
In secondo luogo, vige regola assoluta, se la macchina è compromessa, la si pialla, si restorano i dati in locale, si trova la falla, si corregge e si rifa la macchina in produzione, è l'unico sistema che ti garantisce di non essere in cacca dopo due giorni con lo stesso problema.

Quindi in definitiva, meglio prevenire con hardening e iptables che mettere mano a log e sistemi di monitoraggio che a server compromesso potrebbero essere di fatto inutili a ricostruirne il reale stato.

Qui hai messo insieme più procedure contemporaneamente. Per ripristinare lo stato della macchina serve una procedura di disaster recovery. Per un versioning dei dati serve una procedura di backup.
Il monitoring è una procedura a sè.
La gestione dei log è una procedura a sè (meglio se affiancata da una voce specifica della procedura di backup dati in modo da avere un versioning pure di quelli, si sa mai).

Per quanto riguarda hardening ed iptables, non ci vedo grosse difficoltà (ma nemmeno grossi benefici), l'hardening vero lo fai nella configurazione dei servizi che sono preposti all'interfaccia pubblica e non solo, poi lavorerei molto a livello di utenze per mantenere il più possibile separate le credenziali.

Per finire, è utile un sistema di monitoring (anche un semplice script) che segnali in qualche modo l'accesso ad un sistema, il risultato è che, seppur possano ripurlirti i log, tu avrai tale segnalazione su macchina esterna e quindi avrai le prove anche se il wannabe di turno è lesto a farti fuori i log.

Che i report vadano interpretati me ne ha dato dimostrazione rkhunter che in locale mi segnalava la presenza di rootkit seppur non ci fossero.

I report di Nessus sono più veritieri in genere, ma poi devi applicarli all'ecosistema dove i warning sono avvenuti perchè spesso ti ritrovi con funzionalità volute segnalate come problemi.

[AndDM]

@Valeriano Manassero: grazie, mi hai dato degli spunti interessanti su cui documentarmi e lavorare. Mi faccio vivo eventualmente per ulteriori delucidazioni.