Abbiamo già avuto domande su Hachting Apache , Hardening PHP e Securing SSH .
Per continuare questa tendenza sono interessato a quali passi le persone adottano per rafforzare i server Linux. Come in quali passaggi le persone prendono sempre quando configurano un nuovo server, non sono specifici dell'applicazione. Come impostare la partizione di tmp come noexec, disinstallando / disabilitando alcuni servizi, e.t.c.
Identifica le applicazioni e i processi richiesti e applica un elenco di controllo per evitare di installarli o, nel peggiore dei casi, per disinstallarli dopo la creazione iniziale.
Qui sto pensando a quei colpevoli comuni che sembrano ancora arrivare a troppe distro di default!
Il prossimo passo avanti è passare attraverso i potenziali servizi deboli e limitare l'accesso ad essi
Lo spazio "Server Linux" include un'enorme gamma di distribuzioni , ognuno con la propria strategia di aggiornamento della configurazione predefinita , toolchain di gestione dei pacchetti e approccio ai servizi predefiniti e alle porte aperte. Esiste anche una vasta gamma di scenari di implementazione: l'irrigidimento di un server Web è molto diverso dall'indurimento di un router basato su Linux. Potresti ricevere consigli migliori chiedendo informazioni sulle distribuzioni e sui casi d'uso che più ti interessano.
In questo senso, mi limiterò a indirizzare sicurezza Ubuntu qui puntando ad alcune fonti pertinenti, anche se molto di questo sarà utile per altre situazioni.
Una buona introduzione è qui: link
La community ha descritto qui alcune impostazioni di default più rigide e più rigide che si orientano maggiormente verso la sicurezza, anche se l'usabilità è influenzata: link
Ecco una matrice e un riepilogo delle funzionalità di sicurezza di Ubuntu, per aiutare le persone a cercare liste di controllo che trovi altrove: link
Per vedere come puoi fare tu stesso alcuni test, controlla la trascrizione in link guidato dal codice demo in link
Un riepilogo di ciò che serve per fare ciò che è: link
Il team di sicurezza di Ubuntu ha altre cose utili sul proprio wiki: link
Il rafforzamento puntuale del sistema è un'impresa vantaggiosa, ma ciò che definisce veramente la distribuzione sicura di un server è ciò che viene fatto per mantenere quello stato .
Scegli una delle liste di controllo della qualità (vedi i link di seguito) che descrivono in dettaglio le modifiche di configurazione consigliate per rafforzare la sicurezza dei tuoi server e applicare quelle modifiche che hanno senso per la tua configurazione. Meglio ancora, codifica i consigli tramite Puppet ( link ): si tratta di una soluzione vantaggiosa per tutti, si dispiega in modo più sicuro e ti darai una possibilità di combattere nel sostenere le configurazioni temprate nel tempo.
Bonus : modello di attacco / modellazione delle minacce ( link ) per concentrare i tuoi sforzi difensivi. Ad esempio, porsi domande come:
How could an attacker gain access to these servers?
What are things I can do to reduce their chances of succeeding?
Traduci la tua risposta alla seconda domanda a specifiche modifiche di configurazione (hardening) o implementando controlli aggiuntivi. Il gioco, naturalmente, è di minimizzare la probabilità del successo di una singola minaccia. Questo richiede tempo, ma ti sentirai meglio con i cambiamenti che hai apportato e perché contro i cambiamenti a casaccio perché qualcuno ha detto che è bello fare.
Migliora la registrazione e la revisione . La prevenzione fallisce sempre: per contrastare questa realtà, si desidera aumentare la registrazione in modo da poter identificare e reagire più rapidamente agli incidenti e recuperare più rapidamente. Il mio strumento preferito per potenziare le difese e migliorare la registrazione su Linux è OSSEC ( link ). Trascorrere più tempo a personalizzare le regole incluse con OSSEC per guardare le cose che ti preoccupano di più è un'attività utile (ad esempio elencare directory aggiuntive e file da avvisare se sono modificati, aggiungendo regole o elevando la severità delle regole esistenti per avvisare l'utente di anomalie dell'autenticazione, aggiungendo regole per controllare le modifiche alla tabella utente mysql ( link ), ad infinitum). Richard Bejtlich ha appena pubblicato un breve post sul blog intitolato Sette fantastici progetti open source per i difensori ( link )
Per supportare la verifica continua delle difese del tuo server puoi eseguire Nessus ( link ) su base continua con i modelli di controllo Linux di Center for Internet Security (CIS). Utilizza i risultati come riferimento, osserva i cambiamenti e rimedia ai punti deboli scoperti.
Per ricapitolare:
1) Attingi alle attuali e rispettate checklist di sicurezza rafforzate per aiutarti a redigere una versione personalizzata che funzioni per il tuo ambiente (eventualmente dopo aver svolto attività di modellazione di attacco / minaccia e scegliendo un framework di gestione della configurazione)
2) Amplificazione delle capacità di osservazione: migliorare la registrazione (ad esempio ottimizzare il sistema per generare registri sufficienti per le attività che si desidera osservare), distribuire HIDS (ad es. OSSEC ), distribuire strumenti di analisi dei log (ad esempio logwatch - link ), forse acquisisce i flussi di rete (ad es. tramite softflowd )
3) Rendi qualcuno responsabile di essere un assiduo difensore dei sistemi
4) Verifica e test continui per verificare cosa si sta facendo in quel momento.
risorse benchmark / lista di controllo :.
http://cisecurity.org/ The Center for Internet Security (CIS) is a non-profit enterprise whose Benchmarking and Metrics Division helps organizations reduce the risk of business and e-commerce disruptions resulting from inadequate technical security controls. The Division provides enterprises with consensus best practice standards for security configurations, as well as resources for measuring information security status and for making rational decisions about security investments.
http://iase.disa.mil/stigs/checklist/ Defense Information Systems Agency (DISA)
http://web.nvd.nist.gov/view/ncp/repository
http://csrc.nist.gov/fdcc/faq-common_security_configurations.html
The National Checklist Program (NCP), defined by the NIST SP 800-70 Rev. 1, is the U.S. government repository of publicly available security checklists (or benchmarks) that provide detailed low level guidance on setting the security configuration of operating systems and applications.
Potresti fare molto peggio che iniziare con la lista di controllo Sans .
La mia unica critica è che non pone abbastanza enfasi sulla gestione della sicurezza di un sistema distribuito, in particolare assicurando che le patch dei fornitori siano aggiornate, pianificando un modello di autorizzazioni valido, gestendo il reporting delle eccezioni IDS ecc.
Per prima cosa, devi capire lo scopo del server e il modello di minaccia che stai cercando di difendere. È un server monouso? Più utenti hanno accesso? Se più utenti hanno accesso, ti fidi di tutti loro, o no?
Supponiamo che questo server sia utilizzato solo per i servizi di rete e non devi affrontare la minaccia di attacchi da parte di qualcuno che ha un account sul tuo computer. Ecco i passaggi che prendo:
Abilita un firewall. utilizzo iptables per configurare un firewall locale. Uso una politica default-deny : tutte le connessioni in entrata sono bloccate per impostazione predefinita, a meno che non sia esplicitamente consentito nel criterio del firewall. Abilito le connessioni in entrata ai servizi che si intendono esportare nel mondo (ad esempio, la porta 25 se si tratta di un server di posta, le porte 80/443 se si tratta di un server Web e così via). iptables ha un eccellente supporto per il filtro stateful, in modo che una volta stabilita una connessione, tutti i pacchetti siano associati a quella connessione sono consentiti.
Aggiorna tutti i pacchetti e attiva gli aggiornamenti automatici. aggiorno la mia distribuzione Linux all'ultima versione di tutti i pacchetti ( yum upgrade su Fedora, ma usa quello appropriato per la tua configurazione) . Ho anche creato uno script cron per catturare e installare automaticamente gli aggiornamenti una volta al giorno ( yum -y upgrade su Fedora). Mi rendo conto che alcuni amministratori di sistema esperti potrebbero raccomandare contro gli aggiornamenti automatici, perché c'è il rischio che un aggiornamento interrompa qualche servizio; dovrai valutare questo rischio contro il rischio di una violazione della sicurezza dovuta a un pacchetto scaduto. Personalmente, trovo che la facilità d'uso e la convenienza degli aggiornamenti automatici valgano il rischio di servizi non funzionanti, ma questa potrebbe non essere la risposta giusta in tutte le impostazioni operative.
Abilita SELinux. SELinux fornisce un secondo livello di difesa dagli attacchi ai servizi esposti. A volte può essere un po 'un problema (occasionalmente mi ha causato problemi, interrompendo un servizio in un modo difficile da debugare), ma per un ambiente critico per la sicurezza, penso che ne valga la pena.
Imposta SSH per l'amministrazione remota. Dovresti configurare SSH, in modo da poter amministrare la macchina da remoto. Raccomando di generare una chiave privata DSA sul lato client, crittografarla con una passphrase, installare la chiave pubblica corrispondente nel file authorized_keys sul server e accedere utilizzando la chiave privata. Potresti voler personalizzare anche il file di configurazione sshd_config sul server. Prendi in considerazione la disabilitazione di PasswordAuthentication e richiede che gli utenti effettuino l'accesso utilizzando una chiave pubblica. L'autenticazione della password può essere un utile ripiego nel caso in cui qualcosa vada storto con la tua chiave privata, ma è anche un rischio maggiore, perché gli utenti spesso scelgono password indovinate. Se sul proprio sistema ci sono altri utenti a cui non si può fare affidamento per scegliere password di altissima qualità, è possibile disabilitare PasswordAuthentication. Se sei solo tu e hai molta fiducia in tutte le tue password, potresti lasciarlo abilitato. Non impedisco a root di accedere tramite SSH, ma potresti sentirti diversamente.
Se hai più amministratori di sistema, configura gli account per loro. O dai a ciascuno di loro sudo access o imposta un account root separato per ciascun amministratore di sistema.
Abilita DNSSEC. Configuro i miei server per eseguire un server DNS di memorizzazione nella cache locale che convalida i nomi host con DNSSEC laddove possibile, per ridurre il rischio di spoofing DNS.
Quindi, per ogni servizio che è esposto al mondo, prendo le precauzioni per garantire quel servizio. Ad esempio, abilito la crittografia (ad es. STARTTLS per i server di posta) e i server chroot o sandbox laddove possibile. Tuttavia, le specifiche variano da servizio a servizio. Pertanto, suggerisco di inviare una domanda separata per ogni servizio che intendi eseguire, chiedendo consigli su come bloccare quel servizio.
Se stai cercando una distribuzione Linux che abbia già applicato un notevole quantitativo, ti consiglio vivamente Openwall Linux .
(Commento: se offri utenti non fidati sul tuo server, diventa molto più difficile stringere la sicurezza: la superficie di attacco è molto più grande. Se questo è un problema per te, ti suggerisco di fare una domanda a parte su come blocca il tuo server per proteggerti dagli attacchi degli utenti locali con account sul tuo server, poiché l'insieme di tecniche per farlo è abbastanza diverso.)
E per quanto riguarda le patch del kernel Grsecurity / PAX, queste includono funzionalità molto interessanti per rafforzare il server a livello di kernel.
Sommario:
Per Red Hat , la NSA ha consigli sull'indurimento. Vedi Guida alla configurazione per Red Hat Enterprise Linux 5 - NSA / CSS .
Dovrebbero essere utili anche per CentOS e altri derivati.
Per RHEL, il benchmark CIS Red Hat Enterprise Linux 5 dal Center for Internet Security sembra una buona risorsa.
Se si sta tentando di proteggere il sistema disinstallando pacchetti / servizi non necessari, si ha già un problema più grande. Questi pacchetti non dovrebbero essere stati installati in primo luogo.
Dovresti installare un sistema minimalista e aggiungere solo pacchetti di cui hai veramente bisogno. Lo stesso vale per il tuo kernel. Compila il tuo kernel con solo le funzionalità che ti servono. Non usare il tuo kernel di distribuzione con supporto per tutto (non avrai comunque bisogno del 95% di esso)
Leggi altre domande sui tag operating-systems linux configuration hardening