Domanda:
Rafforzamento del server Linux
Mark Davidson
2010-12-06 16:04:07 UTC
view on stackexchange narkive permalink

Abbiamo già ricevuto domande su protezione avanzata di Apache, protezione avanzata di PHP e protezione di SSH.

Per continuare questa tendenza, sono interessato a quali passi le persone intraprendono per rafforzare i server Linux. Come i passaggi che le persone eseguono sempre quando configurano un nuovo server, che non sono specifici dell'applicazione. Come impostare la partizione tmp su noexec, disinstallare / disabilitare alcuni servizi, ecc.

Ho aggiunto una taglia a questa domanda perché vorrei vedere alcune risposte più dettagliate, invece dei link ad altri elenchi. Alla ricerca di qualcosa come la risposta migliore alla domanda Hardening Apache - http://security.stackexchange.com/questions/77/apache-server-hardening/83#83
@Mark IMHO Mi fiderei dei collegamenti a benchmark come CIS, molto più di quanto mi fiderei di un elenco casuale di cose da fare per rafforzare un server Linux. Il CIS è molto più approfondito, sottoposto a revisione paritaria e provato di quello che qualcuno potrebbe inventare su questo sito.
@Josh Sono d'accordo con te per quanto riguarda la fiducia. Ma non è il punto centrale di tutti i siti di stackexchange sapere se una risposta è attendibile per il numero di voti positivi o negativi che ha. In ogni caso le persone dovrebbero fare riferimento ad altre risorse, ma a mio parere un riepilogo dei punti chiave della check-list a cui si fa riferimento sarebbe utile, poiché aiuta gli utenti a identificare più facilmente se la risorsa sarà loro utile.
Come ho notato nella mia risposta, lo spazio del "server linux" è troppo ampio e diversificato per ottenere una singola risposta utile. Quindi dividerlo per distro. Diverse distribuzioni hanno set di servizi molto diversi installati per impostazione predefinita e approcci alla protezione avanzata. Anche i telefoni Android possono essere visti come server Linux, che ascoltano le telefonate e la messaggistica da cloud a dispositivo (C2DM) e possono essere configurati per servire http ecc. Ma non usa nemmeno un tipico stack basato su GNU. Se qualcuno fornisse una risposta esauriente, sprecheresti tempo a controllare tutte le cose stupide che devono essere evitate in alcune distribuzioni.
Ecco perché ho mantenuto la mia risposta come un elenco di cose chiave che devono essere esaminate, ma abbastanza generali da essere appropriate per quasi tutti i server Linux.
Sembra una domanda wiki. Come sarebbe la risposta "giusta"? La persona che non è stata posseduta da più tempo? :)
@nealmcb Apprezzo la difficoltà di questa domanda ed è piuttosto ampia, se le persone vogliono essere specifiche per una distribuzione va bene. Personalmente uso i server Debian e Ubuntu, quindi le risposte su misura per loro sono ottime.
http://library.linode.com/security/basics
Per coloro che cercano uno strumento per controllare e controllare l'hardening di un sistema, dai un'occhiata al mio strumento [Lynis] (http://rootkit.nl/projects/lynis.html). Può essere una grande estensione dei benchmark / linee guida menzionati e aiuta con la convalida.
Nove risposte:
#1
+57
Rory Alsop
2010-12-06 18:51:31 UTC
view on stackexchange narkive permalink

Identifica le applicazioni e i processi richiesti e applica una lista di controllo per evitare di installarli o, nel peggiore dei casi, disinstallarli dopo la compilazione iniziale.

Qui penso a quei colpevoli comuni che sembrano ancora andare avanti troppe distribuzioni per impostazione predefinita!

  • Servizi NFS: nfsd, lockd, mountd, statd, portmapper
  • server telnet e server ftp
  • Servizi R : rlogin, rsh, rcp, rexec
  • BIND e server DNS a meno che non siano necessari
  • server di posta come sendmail
  • X11 (a meno che non sia necessario desktop)
  • finger daemon, ecc.

Il passaggio successivo è esaminare i potenziali servizi deboli e limitare l'accesso ad essi

  • utilizzare at.allow e cron.allow per limitare l'accesso a crontab
  • Assicurati che tutti i dispositivi siano illeggibili e non scrivibili dagli utenti ordinari (esclusi quelli come / dev / tty e / dev / null ecc.)
  • File chiave - permessi su questi dovrebbero essere di proprietà di root: / etc / fstab, / etc / password, / etc / shadow
  • Controlla attentamente hosts.equiv - un'ottima fonte di accesso qui :-)
  • Allo stesso modo, la configurazione di NFS è bloccata se è richiesta
  • Disabilita gli account di sistema non necessari.
  • Guarda il filesystem: bit permanenti per tutti gli eseguibili e le directory pubbliche.
  • Controlla tutti i requisiti di root (variabile d'ambiente PATH, nessun accesso remoto come root, appartenenza al gruppo, requisiti della password)
  • Controlla tutti i requisiti degli utenti (l'appartenenza a gruppi privilegiati, shell valide, umask, SUID, requisiti SGID
  • e ovviamente la guida SANS è davvero un'ottima fonte!
Probabilmente una domanda stupida, ma ... Perché gli utenti non dovrebbero essere autorizzati a scrivere / leggere da / dev / null? So che ci sono altri modi per ottenere la sua funzionalità (ad es. "Verboseprogram |:")? C'è mai stata un'implementazione non sicura di / dev / null?
** escluso **, parti
** googles un po 'di più ** Oh, giusto. Brutta poiana ...
* "Identifica le applicazioni e i processi richiesti e applica una lista di controllo per evitare di installarli" * Perché dovresti evitare di installare le tue * applicazioni obbligatorie *? Presumo che intendi "* applicazioni standard ma non richieste *"?
#2
+25
nealmcb
2010-12-07 08:27:13 UTC
view on stackexchange narkive permalink

Lo spazio "Linux Server" include una vasta gamma di distribuzioni, ciascuna 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 un'ampia gamma di scenari di distribuzione: rafforzare un server Web è molto diverso rispetto a rafforzare un router basato su Linux. Potresti ottenere consigli migliori chiedendo informazioni sulle distribuzioni e sui casi d'uso che ti interessano di più.

In questo senso, mi limiterò ad affrontare la sicurezza di Ubuntu qui indicando alcune fonti pertinenti , anche se molto di questo sarà utile per altre situazioni.

Una buona introduzione è qui: http://www.andrewault.net/2010/05/17/securing-an-ubuntu- server /

La community ha descritto alcune impostazioni predefinite più rigorose e suggerimenti per l'hardening qui che si orientano maggiormente verso la sicurezza anche se l'usabilità è compromessa: https://help.ubuntu.com/community/ StricterDefaults

Ecco una matrice e un riepilogo delle funzionalità di sicurezza di Ubuntu, per aiutare le persone a cercare le liste di controllo che trovi altrove: https://wiki.ubuntu.com/Security/Features

Per vedere come puoi eseguire alcuni dei test da solo, controlla la trascrizione in http://people.canonical.com/~kees/demo/ec2-session.log guidato dal codice demo in http://people.canonical.com/~kees/demo/

Un riepilogo di ciò che serve per fare w cappello è a: https://wiki.ubuntu.com/Security/Privileges

Il team di sicurezza di Ubuntu ha altre cose utili sul proprio wiki: https: //wiki.ubuntu.com/Security/

#3
+21
Tate Hansen
2010-12-07 00:11:07 UTC
view on stackexchange narkive permalink

Il rafforzamento temporaneo 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 qualsiasi delle liste di controllo della qualità (vedi link sotto) che descriva in dettaglio le modifiche di configurazione consigliate da fare per rafforzare la sicurezza dei tuoi server e applica quelle modifiche che hanno senso per la tua configurazione. Meglio ancora, codifica i consigli tramite Puppet ( http://www.puppetlabs.com/): questo è un vantaggio per tutti, distribuirai in modo più sicuro e " Ti darò la possibilità di combattere nel tempo le configurazioni consolidate.

Bonus : crea modelli di attacchi / minacce ( http://taosecurity.blogspot.com/2007/06/threat-model-vs-attack-model. html) per concentrare i tuoi sforzi difensivi. Ad esempio, poniti domande come:

In che modo un utente malintenzionato può accedere a questi server?
Cosa posso fare per ridurre le sue possibilità di successo?

Traduci la tua risposta alla seconda domanda in specifiche modifiche alla configurazione (hardening) o implementando controlli aggiuntivi. Il gioco, ovviamente, è ridurre al minimo la probabilità di successo di qualsiasi minaccia. Questo richiede tempo, ma ti sentirai meglio riguardo alle modifiche che hai apportato e perché invece di apportare modifiche a casaccio perché qualcuno ha detto che era bene farlo.

Diventa bravo a registrare e rivedere . 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 aumentare le difese e migliorare la registrazione su Linux è OSSEC ( http://www.ossec.net/). Trascorrere più tempo a personalizzare le regole incluse con OSSEC per osservare le cose che ti interessano di più è un'attività utile (ad esempio, elencare directory e file aggiuntivi su cui essere avvisati se vengono modificati, aggiungere regole o elevare la gravità delle regole esistenti per avvisarti di anomalie di autenticazione, l'aggiunta di regole per controllare le modifiche alla tabella utente mysql ( http://blog.rootshell.be/2011/01/07/auditing-mysql-db-integrity -with-ossec /), ad infinitum). Richard Bejtlich ha appena pubblicato un tempestivo post sul blog intitolato Sette fantastici progetti open source per difensori ( http://taosecurity.blogspot.com/2011/01/seven-cool-open-source-projects -for.html)

Per supportare la verifica continua delle difese del tuo server puoi eseguire Nessus ( http://www.nessus.org/ nessus /) su base continuativa con i modelli di controllo Linux del Center for Internet Security (CIS). Usa i risultati come base, osserva i cambiamenti e rimedia ai punti deboli scoperti.

Ricapitolando:

1) Attingi a elenchi di controllo per rafforzare la sicurezza esistenti e rispettati per aiutarti a redigere uno personalizzato che funzioni per il tuo ambiente (si spera dopo aver eseguito l'attacco / attività di modellazione delle minacce e scelta di un framework di gestione della configurazione)

2) Potenziare le capacità di osservazione: migliorare la registrazione (cioè ottimizzare il sistema per generare log sufficienti per le attività che si desidera osservare), distribuire HIDS (es. OSSEC), distribuire strumenti di analisi dei log (ad es. logwatch - http://sourceforge.net/projects/logwatch/), magari acquisire flussi di rete (ad es. tramite softflowd)

3) Affidare a qualcuno la responsabilità di essere un assiduo difensore dei sistemi

4) Controllare e testare continuamente per verificare che ciò che si pensa sia stato fatto

benchmark / risorse della lista di controllo :.

http://cisecurity.org/ Il Center for Internet Security (CIS) è un'impresa senza scopo di lucro la cui divisione Benchmarking and Metrics aiuta le organizzazioni a ridurre il rischio di interruzioni dell'attività e del commercio elettronico derivanti da controlli di sicurezza tecnica inadeguati. La Divisione fornisce alle aziende standard consensuali di best practice per le configurazioni di sicurezza, nonché risorse per misurare lo stato della sicurezza delle informazioni e per prendere decisioni razionali sugli investimenti in sicurezza.

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
Il National Checklist Program (NCP), definito dal NIST SP 800-70 Rev. 1, sono gli Stati Uniti archivio governativo di elenchi di controllo (o benchmark) di sicurezza disponibili pubblicamente che forniscono indicazioni dettagliate di basso livello sull'impostazione della configurazione di sicurezza di sistemi operativi e applicazioni.

#4
+17
symcbean
2010-12-06 17:49:39 UTC
view on stackexchange narkive permalink

Potresti fare molto peggio che iniziare con la lista di controllo Sans.

La mia unica critica a questo è che non pone abbastanza enfasi sulla gestione della sicurezza di un sistema - in particolare assicurando che le patch del fornitore siano aggiornate, pianificando un buon modello di permessi, gestendo la segnalazione delle eccezioni IDS ecc.

#5
+13
D.W.
2011-01-12 09:12:28 UTC
view on stackexchange narkive permalink

Per prima cosa, devi capire lo scopo del server e il modello di minaccia da cui stai tentando di difenderti. È un server monouso? Più utenti hanno accesso? Se più utenti hanno accesso, ti fidi di tutti loro o no?

Presumo che questo server sia utilizzato solo per i servizi di rete e che tu non debba affrontare la minaccia di attacchi da parte di qualcuno che ha un account sulla tua macchina. Ecco i passaggi che eseguo:

  • Abilita un firewall. Uso iptables per configurare un firewall locale. Uso una policy default-deny : tutte le connessioni in entrata sono bloccate per impostazione predefinita, a meno che non siano esplicitamente consentite nella policy firewall. Abilita le connessioni in entrata ai servizi che devono essere esportati nel mondo (ad esempio, porta 25 se questo è un server di posta, porte 80/443 se questo è un server web e così via). iptables ha un eccellente supporto per il filtraggio stateful, in modo che una volta stabilita una connessione, tutti i pacchetti sono associati a quella connessione sono consentiti.

  • Aggiorna tutti i pacchetti e abilita gli aggiornamenti automatici. Aggiorno la mia distribuzione Linux all'ultima versione di tutti i pacchetti ( yum upgrade su Fedora, ma uso tutto ciò che è appropriato per la tua configurazione). Ho anche impostato uno script cron per acquisire e installare automaticamente gli aggiornamenti una volta al giorno ( yum -y upgrade su Fedora). Mi rendo conto che alcuni amministratori di sistema esperti potrebbero sconsigliare gli aggiornamenti automatici, perché c'è il rischio che un aggiornamento interrompa alcuni servizi; dovrai valutare tale rischio rispetto al rischio di una violazione della sicurezza dovuta a un pacchetto obsoleto. Personalmente, trovo che la semplicità e la comodità 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 contro gli attacchi ai servizi esposti. A volte può essere un po 'fastidioso (occasionalmente mi ha causato problemi, interrompendo un servizio in un modo difficile da eseguire il debug), ma per un'impostazione critica per la sicurezza, penso che ne valga la pena.

  • Configurazione di SSH per l'amministrazione remota. È necessario configurare SSH, in modo da poter amministrare in remoto la macchina. Ti consiglio 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. Valuta la possibilità di disabilitare la PasswordAuthentication e di richiedere che le persone accedano 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 esseri umani spesso scelgono password indovinabili. Se sul tuo sistema sono presenti altri utenti sui quali non puoi fare affidamento per scegliere password di altissima qualità, potresti disabilitare la 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. Assegna a ciascuno di loro l'accesso sudo o imposta un account root separato per ogni 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 ove possibile, per ridurre il rischio di spoofing DNS.

Quindi, per ogni servizio esposto al mondo, prendo precauzioni per garantire quel servizio. Ad esempio, abilito la crittografia (ad esempio STARTTLS per i server di posta) e chroot o sandbox ove 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 ha già un ottimo affare di hardening applicato, posso consigliare vivamente Openwall Linux.

(Commento: se fornisci utenti non attendibili sul tuo server, diventa molto più difficile ridurre la sicurezza: il la superficie di attacco è molto maggiore. Se questa è una preoccupazione per te, ti suggerisco di porre una domanda separata su come bloccare il tuo server per proteggerti dagli attacchi degli utenti locali con account sul tuo server, poiché il set di tecniche per farlo è abbastanza diverso .)

#6
+6
Jerry Jacobs
2011-07-21 13:13:20 UTC
view on stackexchange narkive permalink

E per quanto riguarda le patch del kernel Grsecurity / PAX, queste includono funzionalità molto interessanti per rafforzare il server a livello di kernel.

Riepilogo:

  • Proteggi heap e stack overflow
  • Nascondi i processi di altri utenti
  • Elenco di controllo degli accessi basato sui ruoli
  • Protezione avanzata del chroot
  • Restrizioni / proc, FIFO e dmesg
  • Funzionalità di registrazione avanzate
#7
+4
nealmcb
2011-02-04 03:00:46 UTC
view on stackexchange narkive permalink

Per Red Hat , NSA offre consigli sull'indurimento. Vedi Guida alla configurazione per Red Hat Enterprise Linux 5 - NSA / CSS.

Dovrebbero essere utili anche per CentOS e altri derivati.

Grazie ad @graham-lee per aver segnalato il collegamento NSA in chat, per una domanda su Windows 2000. E vieni a unirti alla chat se vuoi uno scoop interno!
Il collegamento è morto.
Grazie @EvanTeitelman. Collegamento risolto tramite una semplice ricerca su Google.
#9
+2
Martin Vegter
2013-10-23 18:50:24 UTC
view on stackexchange narkive permalink

Se stai cercando di proteggere il tuo sistema disinstallando pacchetti / servizi non necessari, hai già un problema più grande. Questi pacchetti non avrebbero dovuto essere installati in primo luogo.

Dovresti installare un sistema minimalista e aggiungere solo i pacchetti di cui hai veramente bisogno. Lo stesso vale per il tuo kernel. Compila il tuo kernel con solo le funzionalità di cui hai bisogno. Non utilizzare il kernel di distribuzione con supporto per tutto (non ne avrai comunque bisogno al 95%)

Sebbene installare un sistema minimo e partire da lì sia una buona idea, eseguire il rollio del proprio kernel sarà rapidamente un esercizio di frustrazione. 1: Dovrai ricompilarlo da solo ogni volta che arriva una nuova correzione per la sicurezza. 2: i sistemi che eseguono kernel compilati dall'utente (specialmente quelli con `.config` personalizzato) sono in stato" non supportato "se stai usando RHEL o SLES. Tuttavia, inserire nella lista nera le mod che non usi è una buona idea.
Più piccolo è il kernel, minori sono le possibilità di bug di sicurezza. Se hai eliminato il 95% delle funzionalità non necessarie, hai anche eliminato il 95% della "superficie di attacco". Inoltre, se milioni di utenti usano un kernel identico, è più facile trovare exploit in quel particolare kernel.
Non sto affermando che non aiuterà dal punto di vista della sicurezza. Sto dicendo che questo richiede molto impegno da parte dell'amministratore e ha una maggiore possibilità che il server esegua un kernel obsoleto (perché l'amministratore ha dimenticato o non se ne è accorto o non ha avuto il tempo di preparare una nuova configurazione, ecc.). Il secondo problema è che, se dipendi dal supporto di terze parti, utilizzare la configurazione del kernel personalizzata potrebbe essere semplicemente impossibile.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...