Il server hardening con grsecurity è davvero necessario nell'ambiente CentOS 6.3?

12

Mi considero abbastanza bravo con l'IT, tuttavia sono relativamente fresco nell'amministrazione di server e di sistema. Sono uno sviluppatore web per la mia azienda e mi è stato addebitato l'avvio e la migrazione a un nuovo VPS per allontanarmi dall'host condiviso in cui la mia azienda è presente da anni.

In questo processo, ho trascorso quasi una settimana a indurire il server (la sicurezza è diventata un problema, motivo per cui ci stiamo muovendo in primo luogo) e sono andati oltre e per rendere più rigido il server. Ho installato e configurato ConfigServer Firewall, SSH rinforzato, solo chiavi private, tutte le cose buone. Ma ho trovato un programma chiamato grsecurity che sembra promettente, ma suppongo di essere solo curioso di sapere se è eccessivo o no ?

Ci sono cose che la grsecurity offre di cui ho veramente bisogno? O è qualcosa di cui posso fare a meno? Ho letto qualcosa su come impedisce il buffer overflow e altre cose, tuttavia sono solo curioso di sapere se valga la pena, visto che non voglio aggiungere così tante parti in movimento alla sicurezza di questo server che finisco per cadere sul mio faccia.

Apprezzo qualsiasi feedback tu possa darmi o link a tutorial / informazioni che potresti avere!

Per quello che vale, l'ambiente del server è il seguente:

  • Linode VPS 2048
  • CentOS 6.3
  • PHP 5.4.5
  • Firewall di ConfigServer

Ancora una volta, apprezzo il feedback che mi puoi offrire! Ho fiducia in questa comunità implicitamente, e so che voi ragazzi sapete di cosa state parlando!

    
posta Pierce 20.08.2012 - 17:34
fonte

2 risposte

15

grsecurity (a.k.a. grsec) non è in realtà un programma - è una suite di hardening per Linux.

Include quanto segue:

  • Un sistema completo RBAC (Role-Based Access Security) .
  • patch del kernel grsec-hardened.
  • Implementazione avanzata PaX .
  • chroot restrizioni (funzionalità varie per impedire al malware di sfuggire a una prigione chroot)
  • Miglioramenti alla sicurezza del sistema generale.

Queste funzionalità sono progettate per impedire che lo shellcode abbia esito positivo sul sistema. Le restrizioni in chroot e altre funzionalità di sistema aiutano a prevenire processi non attendibili (ad es. Httpd) dall'esecuzione di attività che non dovrebbero.

Ecco alcuni esempi di miglioramenti pratici:

  • Prevenzione di ptrace e di altri meccanismi IPC tra processi che non dovrebbero parlare tra loro.
  • Funzionalità forense tramite /proc/[pid]/ipaddr
  • link
  • Controllo completo a grana fine di processi, utenti, gruppi e altre entità.
  • Possibilità di nascondere completamente i processi in modalità kernel dalla modalità utente.

La parte più difficile e potente della configurazione di grsec è il sistema RBAC. Si basa su di te per configurare correttamente e pienamente i privilegi e le abilità di determinati processi. Per impostazione predefinita, questo è un set abbastanza restrittivo. Questo può spesso bloccarsi e uccidere determinati processi, spesso senza una ragione ovvia. Tuttavia, se lo sintonizzi correttamente, è un'incredibile misura di sicurezza.

È ottimo per gli scenari di alta sicurezza e consiglio vivamente di installare grsec con RBAC disabilitato per primo. Imposta un chroot appropriato per i tuoi servizi (almeno httpd, preferibilmente demoni SQL / mail) in modo che l'intero sistema non venga impiantato a causa di una vulnerabilità in un singolo daemon.

C'è molto da coprire in una sola risposta, quindi ti suggerisco di leggere il grsec wikibook .

A seconda che tu ne abbia bisogno - dipende. È complicato da configurare (include un kernel ricompilabile dal sorgente, oltre a un sacco di auto-allenamento e modifica manuale della configurazione) e impiegherà una notevole quantità di tempo per essere completamente configurato, ma il risultato è che ottieni una quantità enorme di resistenza contro vulnerabilità nell'esecuzione di codice in modalità remota nei daemon di servizio e nel kernel stesso. Scopri quanto tempo vuoi dedicare a proteggerti da tali attacchi, e vai da li.

    
risposta data 20.08.2012 - 23:25
fonte
-2

Argomento correlato ma importante:

Secondo questa pagina ospitata da CentOS che riguarda l'uso di kernel personalizzati, "CentOS è progettato per funzionare come un ambiente completo.Se si sostituisce un componente critico, ciò potrebbe influire molto sul comportamento del resto del sistema.":

link

Vedi anche questa risposta relativa a Stackexchange alla domanda "Perché Centos non usa ancora il kernel più recente":

link

    
risposta data 06.08.2014 - 20:29
fonte

Leggi altre domande sui tag