Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Gentoo profilo hardened
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page 1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Forum italiano (Italian)
View previous topic :: View next topic  
Author Message
stifler83
Apprentice
Apprentice


Joined: 22 Oct 2010
Posts: 161
Location: Rome

PostPosted: Wed Jan 12, 2011 3:25 am    Post subject: Gentoo profilo hardened Reply with quote

Ho installato sul mio server di casa gentoo hardened se qualcuno ha qualche tips and trick da passarmi o comunque si è già cimentato nella sua configurazione e vuole darmi una mano l'accetto volentieri :) sopratutto per quanto riguarda pax ed rbac ;)
Back to top
View user's profile Send private message
ago
Developer
Developer


Joined: 01 Mar 2008
Posts: 1521
Location: Milan, Italy

PostPosted: Wed Jan 12, 2011 2:26 pm    Post subject: Reply with quote

allora...puoi iniziare a capire cosa stai facendo, leggendo qui

Successivamente puoi dare uno sguardo a un quickstart su pax e come puoi ben vedere, sul sito upstream c'è la doc su pax

Per quanto riguarda grsecurity: trovi una guida qui

Per la scrittura di policy rbac, oltre alla documentazione, se vuoi un parere tecnico, puoi sempre fare un salto su #gentoo-it ( freenode ) troverai utenti preparati in merito.



P.S. Devo cmq segnalarti che le documentazioni che ti ho linkato, prodotte dal team gentoo, sono un tantino obsolete e anche in fase di "ristrutturazione" come puoi vedere sul bugzilla


Spero di essere stato esaustivo :)
Back to top
View user's profile Send private message
Pes88
Apprentice
Apprentice


Joined: 06 May 2009
Posts: 243

PostPosted: Wed Jan 12, 2011 6:11 pm    Post subject: Reply with quote

Colgo l'occasione di questo thread per porre anche io una domanda, gentoo-hardened + selinux potrebbe essere una buona soluzione per un server virtuale??? Un buon compromesso tra sicurezza è prestazioni?
O le altre distribuzioni ( mi riferisco principalmente a debian e redhat ) mi danno un livello di sicurezza migliore ?

E secondo voi il fatto di dover compilare ogni cosa è troppo impegnativo per un server di piccole dimensioni???
_________________
Pygoscelis papua, chiamato Gentoo dagli abitanti delle isole Falkland/Malvinas, noto per essere il pinguino più veloce!!! XD
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Thu Jan 13, 2011 1:37 pm    Post subject: Reply with quote

PAX serve (detto in modo molto riduttivo) a proteggersi dagli exploit e lo si può utilizzare indipendentemente da grsec/selinux/appaarmour (nelle ultime versioni è comparso anche questo). L'impatto sulle prestazioni non è drammatico ma lo si avverte, soprattutto in fase di build e se vuoi usare java o mono saltano fuori diversi fastidi (basta vedere OOo ed il bug per la compilazione irrisolto da almeno due anni).

grsec è meglio se segui il wiki ufficiale del progetto.

Selinux... premesso che è rognoso, premesso che ha un impatto sulle prestazioni ed in particolare sull'IO (l'unico trucco è montare i filesystem preimpostando gli attributi in certi casi), premesso che una cosa partorita dalla NSA non può essere utile, premesso che mi ricorda troppo le policy del piffero di quell'altro... se vuoi farti del male usalo. Di buono ha solo che è l'unico sistema di sicurezza che ha già un nutrito pacchetto di policy predefinite.

@Pes88 vedi che esiste anche il crossbuild od il banale chroot e pacchetti binari (soluzione che ho applicato per anni, compilo, verifico le dipendenze e poi aggiorno). Non devi compilare sul server (anzi sarebbe meglio evitarlo).

Debian è debian (non mi piace, a causa di certi loschi figuri tendo sempre ad associare la definizione di debianista a solone del piffero, ma è apprezzabile, aggiornamento più lento rispetto a gentoo ma molto solido e ben verificato) ma quanto a RH (che schifo dalla rel 4, per gravi mancanze) è come usare M$ senza il supporto hardware di M$, stessi costi, stesse assurde limitazioni, stessa impostazione del "reinstalla al minimo problema", stesso divieto implicito a personalizzare. Stai parlando di un prodotto commerciale ottuso a misura del tecnico bimbominkia buono solo a metter il dvd nel computer e reinstallare ma con il software commerciale lo impongono, è solo grazie a questo ed all'idiota tendenza a pensare che più una cosa costa meglio deve essere che si mantiene in piedi IMHO (ok hanno provato ad impormelo e sono un tantino storto in materia).

ago wrote:
puoi sempre fare un salto su #gentoo-it ( freenode ) troverai utenti preparati
a farti venire il mal di testa... :lol:
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
ago
Developer
Developer


Joined: 01 Mar 2008
Posts: 1521
Location: Milan, Italy

PostPosted: Thu Jan 13, 2011 10:50 pm    Post subject: Reply with quote

Pes88 wrote:
Colgo l'occasione di questo thread per porre anche io una domanda, gentoo-hardened + selinux potrebbe essere una buona soluzione per un server virtuale??? Un buon compromesso tra sicurezza è prestazioni?
O le altre distribuzioni ( mi riferisco principalmente a debian e redhat ) mi danno un livello di sicurezza migliore ?


Allora..andiamo con ordine...con gentoo-hardened hai la particolarità di compilare il tutto avendo poi dei binari in posizione random in memoria...e in questo modo aiuti pax a svolgere il suo lavoro.

djinnZ wrote:
PAX serve (detto in modo molto riduttivo) a proteggersi dagli exploit e lo si può utilizzare indipendentemente da grsec/selinux/appaarmour


Forse è stato troppo riduttivo..pax non protegge da tutti i tipi di exploit ma diciamo buffer overflow e roba annessa...

Pes88 wrote:
E secondo voi il fatto di dover compilare ogni cosa è troppo impegnativo per un server di piccole dimensioni???


No, ovviamente non settando un makeopts molto alto qualsiasi pc riesce a compilare..ovviamente ognuno ha la sua tempistica, ma se l'hardware è sano ( disco , ram, cpu ) va a buon fine..

Cmq tornando al punto che chiedevi...usare gentoo-hardened + selinux può essere una buona soluzione ma specifichiamo meglio:
nella maggior parte dei casi dire di usare gentoo hardened comprende l'uso di pax/grsec, e in base a quello che so, è molto difficile far funzionare insieme grsecurity + selinux se non addirittura praticamente impossibile
Detto questo non ti resta che usare tutta la toolchain hardened senza grsecurity e usare selinux. A questo punto visto che selinux è un software che ti permette di scrivere/utilizzare policy mac mi sento obbligato di informarti che anche grsecurity ha il suo sistema mac chiamato rbac.
In sintesi se vuoi gentoo-hardened + della policy mac puoi scegliere l'ultima soluzione postata.

N.B. usare selinux come è stato già detto significa usare al 90% delle policy già fatte, mentre con rbac crei la tua policy con poca fatica ma perfettamente adatta al tuo sistema.




djinnZ wrote:
@Pes88 vedi che esiste anche il crossbuild od il banale chroot e pacchetti binari (soluzione che ho applicato per anni, compilo, verifico le dipendenze e poi aggiorno). Non devi compilare sul server (anzi sarebbe meglio evitarlo).


Come mai evitare di compilare?

su red hat e debian se ne potrebbe parlare diversamente ma si rischia di andare OT ;)
Back to top
View user's profile Send private message
Pes88
Apprentice
Apprentice


Joined: 06 May 2009
Posts: 243

PostPosted: Fri Jan 14, 2011 11:14 am    Post subject: Reply with quote

ok!!
Quindi diciamo che la soluzione migliore è gentoo-hardened + grsecurity, cosi mi faccio un bel po di esperienza nello scrivere le policity !! :)

Io avevo scelto selinux, perché ho visto che è quello più diffuso, è ho pensato che fosse il migliore!

La mia unica preoccupazione per questo server è di ottenere un buon livello di sicurezza , prima di tutto la sicurezza dipende principalmente da chi configura il software, quindi una configurazione scadente mi pregiudica tutto il sistema, però una gentoo-hardenden+grsecurity+firewall è buona soluzione??
O si possono trovare soluzioni software migliori???
_________________
Pygoscelis papua, chiamato Gentoo dagli abitanti delle isole Falkland/Malvinas, noto per essere il pinguino più veloce!!! XD
Back to top
View user's profile Send private message
ago
Developer
Developer


Joined: 01 Mar 2008
Posts: 1521
Location: Milan, Italy

PostPosted: Fri Jan 14, 2011 12:34 pm    Post subject: Reply with quote

Imho puoi sempre valutare soluzioni tipo bsd ;)
Back to top
View user's profile Send private message
Pes88
Apprentice
Apprentice


Joined: 06 May 2009
Posts: 243

PostPosted: Fri Jan 14, 2011 1:56 pm    Post subject: Reply with quote

Quote:

Imho puoi sempre valutare soluzioni tipo bsd


Perchè usare un sistema tipo FreeBSD dovrebbe garantire un miglior livello di sicurezza??

Ho visto che le politiche di sicurezza più o meno sono uguali...
_________________
Pygoscelis papua, chiamato Gentoo dagli abitanti delle isole Falkland/Malvinas, noto per essere il pinguino più veloce!!! XD
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Fri Jan 14, 2011 2:16 pm    Post subject: Reply with quote

PAX è indipendente da grsec e può convivere con selinux (ma a questo punto andrei più su apparmour o se vuoi farti del male vai su rsbac che resta il top in termini di possibilità ma anche di rogne). Per certi versi è il giusto completamento dell'hardening ma opera a livello kernel.

grsec con selinux è possibile ma sarebbe una inutile duplicazione dei controlli, fanno entrambi pressapoco le stesse cose. Diciamo che se devi installarti il tipico server smb+web+sql+php+java selinux ti offre un buon livello di protezione già pronto, grazie al lavoro di pebenito&c ed alla diffusione della soluzione (puoi anche andarti a scopiazzare le policy da centos per dirne una). Però è lento (soprattutto con moti piccoli file, ti ho già indicato il tip per aggirare ma richiede un partizionamento estremamente complesso), non è questa gran cosa e gli attributi occupano spazio.
grsec +pax è un buon compromesso per un sistema su misura, senza dipendenze e servizi inutili.
rsbac ti consente anche di decidere cosa può scrivere e cosa no il singolo processo in base alla porta ip alla quale si è connesso, all'utente proprietario ed all'ora in cui viene eseguito per dirne una ma è qualcosa di mostruoso da configurare (d'altro canto l'estrema granularità dovrebbe essere il suo punto di forza).
Ed almeno nella mia esperienza è facile che policy ed attributi vadano in malora (backup necessario) o che perdi l'accesso all'amministratore, che è realmente distinto rispetto agli altri sistemi.

Caveat: rsbac non brilla per stabilità, è estremamente complesso ed articolato e per scrivere le policy devi partire praticamente da zero e persino la documentazione ufficiale del progetto ha dei buchi (nel senso che ci sono funzioni completamente non documentate). Predisporre le policy è realmente una fatica immane. Ti sconsiglio vivamente il cimento a meno che non hai molto tempo da perdere e certo non su una macchina per lavoro.

Con le applicazioni bytecode il problema essenziale è che non puoi impostare i permessi speciali per accedere a memoria o device su un codice generato al momento, dovresti attribuire al runtime i privilegi di amministratore ed a questo punto rendi il sistema vulnerabile a tutti gli exploit possibili. Ovviamente puoi anche decidere di utilizzare parzialmente le opzioni di pax e grsec.

Tip importante che ora mi sovviene: abilita tutte le opzioni grsec per logging, chroot jail etc (compresa la flag per abilitarle tutte di default) e poi te le disabiliti tramite sysctl.conf. Decisamente meglio anche se non potrai fare a meno di avere una sfilza di log di violazione ad ogni avvio.

Attenzione che qualche incompatibilità con xen/kvm c'è (virtualbox crasha che è un piacere ma non mi sono ancora neppure applicato a vedere se riporta un qualche errore e se non dipende da un errore di configurazione).

@ago: vero che il revdep-rebuild non è più così necessario ma non mi pare utile utilizzare su una macchina di lavoro una distribuzione che può richiedere ore per il ripristino di una funzione durante l'aggiornamento.

Compili su un'altra macchina, al massimo usi un chroot, quando sei certo che tutto sia stato aggiornato e le dipendenze risolte aggiorni con i binari.

Te lo immagini un webserver che resta fermo per due ore perchè dopo aver aggiornato la libc devi attendere che siano ricompilati apache, java, php e server sql. O che si schianti apache e solo dopo un giorno ti rendi conto che lo dovevi ricompilare?

Meglio evitare. Lo dico perché mi è successo ai tempi della prima gentoo o forse quando ancora andavo di LFS, ho aggiornato, me ne sono andato, ma non mi sono accorto che il demone di stampa (forse era ancora lpd) si schiantava. Mezza giornata di lavoro persa ed il pomeriggio a lavorare a rilento mentre ricompilavo mezzo mondo.

Perché complicarsi la vita inutilmente?

Un'ultima considerazione: le distribuzioni binarie, in particolare RH, richiedono policy estremamente severe che su gentoo non sono così indispensabili come sembra dato che (sempre che non sei così scemo da abilitare ed installare l'impossibile) non hai altro che quel che ti serve ed hai deciso di installare, non ci sono potenziali pacchetti vulnerabili autoconfigurati in automatico. Mi pare che fosse proprio RH o suse che in automatico ti installava nis bind e telnet ad ogni aggiornamento e li lasciava attivi e malconfigurati (tanto le impostazioni di default del firewall prevedevano i rifiuto di tutte le connessioni... che str******).


Last edited by djinnZ on Fri Jan 14, 2011 7:09 pm; edited 1 time in total
Back to top
View user's profile Send private message
lavish
Bodhisattva
Bodhisattva


Joined: 13 Sep 2004
Posts: 4296

PostPosted: Fri Jan 14, 2011 2:50 pm    Post subject: Reply with quote

Ciao stifler83, Pes88, etc :)

Sono l'"utente preparato in merito" a Grsecurity RBAC, con vaghe nozioni anche sugli altri sistemi MAC... e no, sono qui non per farvi venire il mal di testa.

Tralasciando un attimo le varie considerazioni piu' o meno corrette gia' fatte dagli altri, la cosa principale che dovete capire su un sistema in cui implementare una policy di sicurezza e' "cosa voler proteggere da chi". Rispondere a questa domanda in modo esaustivo non e' per nulla banale, ma farlo vi condurra' sicuramente verso la soluzione migliore per voi. Ricordate in ogni caso che nell'ambito della sicurezza non esiste una panacea e ogni sistema soddisfa un determinato set di esigenze.

Ci tengo a precisare alcune cose, riguardo a quanto detto da prima:
  • PaX non e' indipendente da Grsecurity, ma ne fa parte;
  • Grsecurity e' utilizzabile con SELinux, ma usare i sistemi di controllo degli accessi delle 2 soluzioni penso sia da folli;
  • le policy di SELinux non ben testate su gentoo, non sono l'unico a ritenere che SELinux sia per ora usabile in produzione solo su Fedora/RH,
  • visto il suo utilizzo su Ubuntu, penso che il sistema MAC piu' diffuso sia AppArmor, non SELinux anche se sicuramente e' di quest'ultimo che si sente parlare maggiormente.


Inoltre aggiungo qualche considerazione personale:
  • Usare chroot per proteggere le applicazioni, a meno di non farne hardening dei chroot tramite Grsecurity, e' non solo inutile, ma anche dannoso;
  • dei sistemi *BSD, l'unico che implementa un sistema MAC e' FreeBSD, ma a parte alcuni aspetti teorici non ne so molto.


Ciao :)
_________________
minimalblue.com | secgroup.github.io/
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Fri Jan 14, 2011 5:59 pm    Post subject: Reply with quote

lavish wrote:
PaX non e' indipendente da Grsecurity, ma ne fa parte;
a livello di codice e progetto, nelle opzioni di configurazione puoi lasciare anche la sezione grsec del tutto disabilitata (impostare mac integration a none, ovviamente). Chiaramente la protezione è estremamente parziale e si pone qualche problema in più ma ... se non ritieni necessario e vuoi solo evitare buffer overflow ed isolare i processi kernel basta ed avanza ( quanto sia utile poi è una questione di ... risultati :lol: ma val la pena di tenerlo presente).
A queste condizioni non incasina troppo selinux, lo ho usato ed andava (era selinux il problema). gradm non dovrebbe poter proprio funzionare con selinux attivo per dirne una.

Tanto per discorrere della cosa, considera che i tempi d'accesso (copia sequenziale in scrittura o lettura dell'intera dir, in scrittura sia creando che riscrivendo) su una partizione da 20GB con più 16GB di roba in file della dimensione media di mezzo kB (quindi ho specificato che ero di fronte ad un filesystem saturo) si dimezzavano al mount con context=... (non ho mai verificato la differenza di prestazioni tra selinux con context ed un sistema normale ma credo che ci sia comunque una differenza notevole). A livello di filesystem solo ext3 mi è parso gestirlo bene (xfs i problemi li dovrebbe aver risolti da tempo, reiser 3 continuava ad andar male per quel che so e le versioni successive... boh.
Vero anche che sono passati diversi annetti da quando usavo selinux ma non credo che lo abbiano migliorato più di tanto.
Adesso non posso ripescare la configurazione del vecchio server ma problemi non me ne ha dati.

lavish wrote:
Usare chroot per proteggere le applicazioni
Dipende da cosa vuoi proteggere. Se vuoi proteggere il sistema dalle applicazioni concordo che resta una str... (che poi se ti ricordi da quale ambito è partita...); se vuoi proteggere le applicazioni dal sistema (principalmente per superare le incompatibilità di path e libreria di applicativi proprietari, come capita a me) non è che ci siano molte alternative a parte la virtualizzazione, che comunque pone altri limiti in ordine al partizionamento soprattutto.

Se poi vuoi proteggere la funzionalità delle applicazioni dagli upgrade l'unica strada alternativa (e certamente migliore, la compilazione è un carico pesante) è il crossbuild.
Per me gli upgrade diretti, su un sistema "in produzione", restano una soluzione pericolosa.

Che poi molti usino il chroot per ragioni di sicurezza dipende anche dalla presenza di pacchetti come chroot-bind e dalla completa assenza di qualsiasi documentazione in tal senso.

@ago: quale bsd? net, free, open o cosa?

@stifler83 & pes88: ora dovresti avere un'idea delle possibilità. Chiaramente se tutto il tuo problema è impedire che da un ambiente virtualizzato si possa influire sull'host senza badare alle cavolate che gli uttenti delle macchine virtuali possono fare mi orienterei prima di ogni cosa sulla costruzione di una immagine totalmente read only del sistema, a kernel assolutamente monolitico.
Considera anche che con il patchset hardened il kernel gradisce poco eventuali altre patch ed il suo aggiornamento è leggermente più lento rispetto ai kernel "normali" (i driver proprietari possono essere un autentico incubo da gestire per dirne una).
bada che i profili hardened, hardened+selinux ed selinux sono diversi e non puoi passare allegramente dall'uno all'altro.
Per esempio sul mio sistema attuale uso solo le impostazioni base per pax e grsec solo per il chroot jail in pratica.
Di più non credo proprio che mi serva per l'uso che ne faccio. Ma questa è la mia esigenza visto che tutto quello che posso temere è qualche script kiddie che tenti di bucare il server acceso quattro/otto ore al giorno, su ip dinamico o che tentino di entrare nel wifi che attivo manualmente solo quando devo connettermi.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:


Last edited by djinnZ on Sat Jan 15, 2011 1:17 pm; edited 1 time in total
Back to top
View user's profile Send private message
Pes88
Apprentice
Apprentice


Joined: 06 May 2009
Posts: 243

PostPosted: Fri Jan 14, 2011 7:57 pm    Post subject: Reply with quote

Grazie mille per le risposte, mi avete dato un bel po di informazioni! :P :P :P :P
Penso che metterò su gentoo-hardened + grsecurity .... :lol: :lol: :lol:
_________________
Pygoscelis papua, chiamato Gentoo dagli abitanti delle isole Falkland/Malvinas, noto per essere il pinguino più veloce!!! XD
Back to top
View user's profile Send private message
ago
Developer
Developer


Joined: 01 Mar 2008
Posts: 1521
Location: Milan, Italy

PostPosted: Sat Jan 15, 2011 12:03 am    Post subject: Reply with quote

Mi secca fare diversi quote...rispondo in maniera veloce:

@djinnz intendevo freebsd
Per quanto riguarda la compilazione, non ho mai avuto problemi simili e certamente non escludo che li possa riscontrare in futuro, ma se si presta poco poco di attenzione non succede mai nulla di tragico. Certo che se per un minuto che il server va giù ti levano mezzo stipendio, ci pensi due volte :D

@pes
Siccome si è parlato di linux, hardening e altro, e tu chiedevi ancora più sicurezza, ti suggerivo di provare il sistema bsd, qualora non l'avessi già fatto, e fare successivamente dei test con cui puoi stabilire qual'è più affidabile...il senso era più o meno questo.
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Sat Jan 15, 2011 1:13 pm    Post subject: Reply with quote

ago wrote:
se si presta poco poco di attenzione
dato che l'errore di distrazione o la riscrittura frettolosa di una intera configurazione capita facilmente ed il costo, in termini di risorse, di un chroot è veramente minimo... più che altro non mi sono mai fatto il problema di farne a meno.

Poiché una gentoo hardened con kernel grsec qualche problema in più lo comporta (anche una acl personalizzata e dimenticata in fase di aggiornamento può bloccare qualcosa) sconsiglio di fare a meno del chroot se non si è più che scafati e non su una macchina di lavoro.

In generale mantenere uno snapshot pre-update del portage e generare i pacchetti binari (gestione implicita nel chroot) potrebbe essere un'alternativa ma sono troppo sfaticato per andare a pensare di ripristinare.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
mack1
Guru
Guru


Joined: 18 Mar 2006
Posts: 315

PostPosted: Thu Jan 20, 2011 11:00 am    Post subject: Reply with quote

Ciao volevo solo aggiungere un paio di link che ti possono aiutare:

1-uno script che ti mostra le varie features di pax/grsecurity attive sul tuo sistema:

http://www.trapkit.de/tools/checksec.html

2-una comparazione dell'uso di alcune tecniche di hardening (grsec/pax con relro,ssp,alsr, bit nx,etc) da parte di alcune distro linux (gentoo hardened,opensuse,ubuntu,fedora e debian):

http://labs.mwrinfosecurity.com/notices/security_mechanisms_in_linux_environment__part_1___userspace_memory_protection/

http://labs.mwrinfosecurity.com/notices/assessing_the_tux_strength_part_2_into_the_kernel/

Ciao
Back to top
View user's profile Send private message
theroot
n00b
n00b


Joined: 24 Dec 2010
Posts: 12

PostPosted: Mon Mar 28, 2011 9:16 pm    Post subject: Reply with quote

Ciao a tutti,
ho letto con interesse la vostra discussione, sto infatti pensando di fare un installazione di Gentoo Hardened nella speranza di rendere più sicure le macchine che gestisco, visto che mi è già successo di trovarmi qualche rootkit (difficile sempre capire quale da quale servizio entrano). Devo ammettere che qualche dubbio mi è rimasto...

Sono dell'idea di utilizzare Pax + Grsec e, se ho capito bene, anche PIE che va a braccetto con Pax. Mi viene un primo dubbio sul fatto che l'utilizzo di Pax+Pie potrebbe appesantire la macchina diminuendo sensibilmente le prestazioni. Avete esperienza in merito?

Sulla mia Gentoo, lanciando
Code:
eselect profile list

vedo che ci sono più profili 'hardened'. Volendo usare Pax + Grsec, il profilo che dovrei scegliere è il numero 8?
Code:

Available profile symlink targets:
  [1]   default/linux/amd64/10.0
  [2]   default/linux/amd64/10.0/desktop
  [3]   default/linux/amd64/10.0/desktop/gnome
  [4]   default/linux/amd64/10.0/desktop/kde
  [5]   default/linux/amd64/10.0/developer
  [6]   default/linux/amd64/10.0/no-multilib
  [7]   default/linux/amd64/10.0/server
  [8]   hardened/linux/amd64
  [9]   hardened/linux/amd64/no-multilib
  [10]  selinux/2007.0/amd64
  [11]  selinux/2007.0/amd64/hardened
  [12]  selinux/v2refpolicy/amd64
  [13]  selinux/v2refpolicy/amd64/desktop
  [14]  selinux/v2refpolicy/amd64/developer
  [15]  selinux/v2refpolicy/amd64/hardened
  [16]  selinux/v2refpolicy/amd64/server


La scelta del filesystem può indicere sulla sicurezza della macchina? Io sono un afecionados reiserfs.

Quote:
@Pes88 La mia unica preoccupazione per questo server è di ottenere un buon livello di sicurezza , prima di tutto la sicurezza dipende principalmente da chi configura il software, quindi una configurazione scadente mi pregiudica tutto il sistema, però una gentoo-hardenden+grsecurity+firewall è buona soluzione??


Sul discorso firewall si potrebbe aprire una discussione che finirebbe per essere OT. In realtà il firewall è un buon compromesso ma non è la soluzione: se infatti sono attivi solo i servizi necessari e il bind sull'ip pubblico viene fatto solo dai servizi che devono essere visti dal mondo, il firewall non è necessario ma utile. In caso di attacco alla macchina è probabilissimo trovarsi le regole di fw cambiate :-(
E' sicuramente un 'in più' avere un firewall davanti ai server.

Quote:
@djinnZ Compili su un'altra macchina, al massimo usi un chroot, quando sei certo che tutto sia stato aggiornato e le dipendenze risolte aggiorni con i binari.


Io tengo una macchina o hard disk uguale all'altra, compilo su quella di backup e se vedo che tutto si è aggiornato correttamente e continua a funzionare, replico l'aggiornamento sull'altra; non è proprio la soluzione 'più comoda' ma in diverse occasioni mi ha salvato da restart falliti dopo un emerge.

Quote:
@djinnZ Dipende da cosa vuoi proteggere. Se vuoi proteggere il sistema dalle applicazioni concordo che resta una str... (che poi se ti ricordi da quale ambito è partita...); se vuoi proteggere le applicazioni dal sistema (principalmente per superare le incompatibilità di path e libreria di applicativi proprietari, come capita a me) non è che ci siano molte alternative a parte la virtualizzazione, che comunque pone altri limiti in ordine al partizionamento soprattutto.


Quote:
lavis Usare chroot per proteggere le applicazioni, a meno di non farne hardening dei chroot tramite Grsecurity, e' non solo inutile, ma anche dannoso.


Mi aiutate a capire meglio? Ho sempre pensato che chrootare i servizi esposti in rete (esempio: bind, postfix, ecc ecc) servisse da un lato per replicare l'ambiente minimo che serve al servizio, dall'altro a fare in modo che un attaccante veda come root la directory chroot del servizio e non tutto il filesystem. Non è così?

Ho ancora qualche domanda in mente, continuo a documentarmi e leggere, leggere...e magari trovo la risposta da solo :-)
Ciao a tutti.
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Tue Mar 29, 2011 2:32 pm    Post subject: Reply with quote

Beh le prestazioni calano per forza ma nulla di preoccupante (sarà la millesima volta che lo ripeto, va a finire che dovrò editare la signature).
I profili sono 8 o 9 secondo se vuoi multilib o meno.
reiserfs 3.6 mi ha dato problemi solo con selinux.

Una volta acquisiti i privilegi di root ci sono diversi modi di tirarsi fuori dal chroot ed andare a romper le scatole al sistema host od ai suoi servizi, grsec ha delle opzioni apposite per evitare seccature di questo genere (come CHROOT_SHMAT, FINDTASK, SYSCTL E UNIX, anche se al momento proprio lo ho disabilitato).

Usando il chroot su un sistema "normale" hai un minimo di protezione in più ma... non è questa gran garanzia e proprio un minimo in più.
Premesso che ormai nessuno più si sogna di andare ad impostare adeguatamente i permessi nel chroot ed il primo vecchio trucco era crearsi un eseguibile suid (CONFIG_CHROOT_CHMOD) per lanciare una shell superuser da utente normale e legittimo.

Come ho detto io lo trovo comodissimo al contrario, per poteggere i servizi "chrootati" (che orrido barbarismo) dagli aggiornamenti del sistema, non per proteggere il sistema dalle loro eventuali vulnerabilità.

Lasciando perdere le implicazioni del codice ricorda che PAX non implica grsec e viceversa e che pie è una cosa del compilatore. Vedi a cosa serve ogni cosa e decidi se abilitarlo.
Per esempio se usi il chroot solo per compilare le protezioni servono solo a crearti problemi.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
ago
Developer
Developer


Joined: 01 Mar 2008
Posts: 1521
Location: Milan, Italy

PostPosted: Tue Mar 29, 2011 6:38 pm    Post subject: Reply with quote

djinnZ wrote:
ricorda che PAX non implica grsec e viceversa

Sul viceversa io direi di no, di fatti abilitando grsec ti trovi abilitato forzatamente PaX..se poi c'è qualche trucchetto per disabilitarlo me lo sto perdendo :D


theroot wrote:
Mi viene un primo dubbio sul fatto che l'utilizzo di Pax+Pie potrebbe appesantire la macchina diminuendo sensibilmente le prestazioni. Avete esperienza in merito?

Pax+pie+ssp etc. non rallentano..forse grsec potrebbe appesantire ( io non ho mai notato particolari rallentamenti )

theroot wrote:
vedo che ci sono più profili 'hardened'. Volendo usare Pax + Grsec, il profilo che dovrei scegliere è il numero 8?

pax+grsec li puoi usare anche su ubuntu, se ha senso o meno è un'altro discorso, ma il punto è che basta patchare i sorgenti del kernel.

theroot wrote:
Sul discorso firewall si potrebbe aprire una discussione che finirebbe per essere OT. In realtà il firewall è un buon compromesso ma non è la soluzione: se infatti sono attivi solo i servizi necessari e il bind sull'ip pubblico viene fatto solo dai servizi che devono essere visti dal mondo, il firewall non è necessario ma utile. In caso di attacco alla macchina è probabilissimo trovarsi le regole di fw cambiate :-(
E' sicuramente un 'in più' avere un firewall davanti ai server.

Il firewall nel tuo caso non serve a nulla...a limite qualche regola particolare ti evita qualche possibile piccolo DoS ma nulla di più
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Fri Apr 01, 2011 5:00 pm    Post subject: Reply with quote

ago wrote:
se poi c'è qualche trucchetto
8O giuro che alle volte... mi trattengo a stento. basta usare il profilo custom come tuitte le persone normali.
ago wrote:
Pax+pie+ssp etc. non rallentano
come ho detto non val la pena di curarsene, non con gentoo e non su una cpu attuale ma puoi sempre provare a compilare OOo su un vecchio athlon per vedere
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
ago
Developer
Developer


Joined: 01 Mar 2008
Posts: 1521
Location: Milan, Italy

PostPosted: Fri Apr 01, 2011 9:04 pm    Post subject: Reply with quote

djinnZ wrote:
basta usare il profilo custom come tuitte le persone normali.


pardon..non ci avevo fatto caso usando sempre altri profili
Back to top
View user's profile Send private message
theroot
n00b
n00b


Joined: 24 Dec 2010
Posts: 12

PostPosted: Sat Apr 02, 2011 3:03 pm    Post subject: Reply with quote

La prima installazione di Gentoo Hardened è riuscita con successo, devo solo prendere praticità con pax e grsec, per ora sono ancora 2 entità non pienamente sotto il mio controllo; dopodiché posso mettere gli hard disk nel pc di destinazione.

Come faccio solitamente, ho messo l'hard disk da installare nel mio pc e ho avviato il mio sistema operativo Gentoo: dopo aver formattato e copiato stage e portage hardened mi sono chrootato e ho compilato il kernel. Una volta terminato e configurato grub, posso partire con il gentoo hardened...
Domanda leggermente OT: invece di fare il boot sul sistema hardened che non ha ambiente grafico, è fattibile lanciare il mio sistema Gentoo e poi chrootarmi per poi installare i pacchetti mancanti? Il mio dubbio principale è se può cambiare qualcosa visto che il mio sistema Gentoo non è hardened e non ha la stessa versione del kernel.

Tornando al discorso sicurezza, districandomi nella documentazione Gentoo, non aggiornatissima, viene consigliato di emergere chpax e paxctl se si usano alcuni pacchetti tipo x11, java... Non essendo il mio caso ho lasciato stare: avete notato problemi su macchine server senza averli installati?

Mi rimetto a configurare la macchina, prossimo passo e creare delle regole (simili a quelle di Selinux) per qui se provo a lanciare un servizio non nella sua porta standard non ci riesco :-)
Per testare pax e grsec avete suggerimenti?

A presto

P.S: ho lasciato il syslog con la configurazione di default di Gentoo Hardened, grsec.log e kern.log hanno delle dimensioni stratosferiche... a breve non li loggo più.
Back to top
View user's profile Send private message
ago
Developer
Developer


Joined: 01 Mar 2008
Posts: 1521
Location: Milan, Italy

PostPosted: Sat Apr 02, 2011 4:03 pm    Post subject: Reply with quote

theroot wrote:
invece di fare il boot sul sistema hardened che non ha ambiente grafico, è fattibile lanciare il mio sistema Gentoo e poi chrootarmi per poi installare i pacchetti mancanti? Il mio dubbio principale è se può cambiare qualcosa visto che il mio sistema Gentoo non è hardened e non ha la stessa versione del kernel.

chrootandoti usi gcc hardened

theroot wrote:
Tornando al discorso sicurezza, districandomi nella documentazione Gentoo, non aggiornatissima, viene consigliato di emergere chpax e paxctl se si usano alcuni pacchetti tipo x11, java... Non essendo il mio caso ho lasciato stare: avete notato problemi su macchine server senza averli installati?

vedi a cosa servono e se fanno al tuo caso

theroot wrote:
Per testare pax e grsec avete suggerimenti?

Code:
paxtest blackhat
o mettiti a fare pentest

theroot wrote:
P.S: ho lasciato il syslog con la configurazione di default di Gentoo Hardened, grsec.log e kern.log hanno delle dimensioni stratosferiche... a breve non li loggo più.

Male, ad occhio direi che c'è qualche problema
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Mon Apr 04, 2011 8:28 am    Post subject: Reply with quote

theroot wrote:
è fattibile lanciare il mio sistema Gentoo e poi chrootarmi per poi installare i pacchetti mancanti?
Il problema è nelle use e nella configurazione dei kernel. Di norma al profilo e kernel hardened si accompagnano acl ed xattr. Non so qual è la tua configurazione ma nel caso verifica e provvedi ad attivare le stesse cose anche nell'host non-hardened.
Guarda che una cosa è fare a meno di X altra fare a meno della grafica. Puoi benissimo pensare di installare solo i pacchetti grafici ma non X ed usarli "da remoto", come si è sempre fatto sui server dai lontani anni '70 in cui X è nato.
theroot wrote:
chpax e paxctl
la questione è: se hai X o java senza non puoi proprio far funzionare il sistema ma non è che altri pacchetti non ne abbiano necessità quindi almeno paxctl ci vuole, chpax è utile se hai binari legacy ed hai abilitato PAX_EI_PAX invece e non è detto che ti serva per forza.
theroot wrote:
grsec.log e kern.log
Verifica NETFILTER_XT_MATCH_GRADM=n tra le tante, azzera i log, avvia il sistema senza nulla, dopo avvii l'autolearn e fai partire i servizi uno alla volta e configuri le eccezioni.

Bada che per default, se non erro, i processi anonimi non possono usare nessuna porta piuttosto. Controlla quale utente lo esegue.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
theroot
n00b
n00b


Joined: 24 Dec 2010
Posts: 12

PostPosted: Wed Apr 06, 2011 5:48 pm    Post subject: Reply with quote

djinnZ wrote:
theroot wrote:
è fattibile lanciare il mio sistema Gentoo e poi chrootarmi per poi installare i pacchetti mancanti?
Il problema è nelle use e nella configurazione dei kernel. Di norma al profilo e kernel hardened si accompagnano acl ed xattr. Non so qual è la tua configurazione ma nel caso verifica e provvedi ad attivare le stesse cose anche nell'host non-hardened.

Avevo il sospetto che non fosse così semplice; per non rischiare di lasciare qualche pezzo per strada mi fido di più riavviare sul SO hardened e lavorarci direttamente.

ago wrote:
paxtest blackhat o mettiti a fare pentest

Oh caspita, paxtest è masked (almeno su amd64).

djinnZ wrote:

Guarda che una cosa è fare a meno di X altra fare a meno della grafica. Puoi benissimo pensare di installare solo i pacchetti grafici ma non X ed usarli "da remoto", come si è sempre fatto sui server dai lontani anni '70 in cui X è nato.

Senza installare le librerie di X non credo di riuscire ad installare, ad esempio, wireshark con il flag gtk.

djinnZ wrote:

.....almeno paxctl ci vuole, chpax è utile se hai binari legacy ed hai abilitato PAX_EI_PAX invece e non è detto che ti serva per forza

Ok, paxctl l'ho installato, PAX_EI_PAX l'ho abilitato, mentre NETFILTER_XT_MATCH_GRADM è disabilitato (ho lasciato il valore originario) anche se non mi dispiace abilitarla, per ora la lascio così alla fine dell'installazione la provo.

Sul discorso kern.log e grsec.log:
djinnZ wrote:
azzera i log, avvia il sistema senza nulla, dopo avvii l'autolearn e fai partire i servizi uno alla volta e configuri le eccezioni.

ago wrote:
Male, ad occhio direi che c'è qualche problema

Ho riletto con attenzione la quickstart di grsec (http://grsecurity.net/quickstart.pdf) ed ho trovato la soluzione al problema dei log enormi, praticamente loggavo tutto l'impossibile: ho seguito i suggerimenti del paragrafo Kernel Auditing (settando i vari OFF, tranne (Un)Mount logging che è ON e non modificabile da make menuconfig).

Ho trovato interessante CONFIG_GRKERNSEC_BLACKHOLE che ho abilitato, anche sbagliando a configurare il firewall sono sicuro che la macchina non manda pacchetti RST a seguito di richieste su porte non attive.

Nella mia conf è abilitata (non modificabile da make menuconfig) CONFIG_GRKERNSEC_SYSCTL_ON
Code:
CONFIG_GRKERNSEC_SYSCTL_ON:                                             
   If you say Y here, instead of having all features enabled in the                                       
   kernel configuration disabled at boot time, the features will be                                       
   enabled at boot time.  It is recommended you say Y here unless                                         
   there is some reason you would want all sysctl-tunable features to                                     
   be disabled by default.  As mentioned elsewhere, it is important                                       
   to enable the grsec_lock entry once you have finished modifying                                         
   the sysctl entries.

vediamo se ho capito bene: questa config va a braccetto con kernel.grsecurity.grsec_lock.
Configuro il mio sistema attivando in /etc/sysctl.conf i parametri kernel che mi servono; una volta completato aggiungo nel file kernel.grsecurity.grsec_lock = 1 e al prossimo boot non riuscirò più a modificare niente con sysctl.

djinnZ wrote:
...dopo avvii l'autolearn e fai partire i servizi uno alla volta e configuri le eccezioni

Ora installo tutti i pacchetti server che mi servono, li configuro e poi lancio l'autolearn subito prima di farli partire (spengo prima anche vixie-cron, syslog, ssh, iptables e la rete?)
Back to top
View user's profile Send private message
ago
Developer
Developer


Joined: 01 Mar 2008
Posts: 1521
Location: Milan, Italy

PostPosted: Wed Apr 06, 2011 11:11 pm    Post subject: Reply with quote

theroot wrote:
Oh caspita, paxtest è masked (almeno su amd64).


Non è stabile, è testing, c'è una bella differenza con masked
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Forum italiano (Italian) All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum