sviluppo-web-qa.it

Quali passi prendi per proteggere un server Debian?

Sto installando un server Debian che è collegato direttamente a Internet. Ovviamente voglio renderlo il più sicuro possibile. Vorrei che voi ragazzi/ragazze aggiungeste le vostre idee per proteggerlo e quali programmi utilizzate per esso.

Voglio che parte di questa domanda riguardi cosa usi come firewall? Solo iptables configurato manualmente o usi qualche tipo di software per aiutarti? Qual è il modo migliore? Bloccare tutto e consentire solo ciò che è necessario? Ci sono forse buoni tutorial per i principianti su questo argomento?

Modifichi la tua porta SSH? Usi software come Fail2Ban per prevenire attacchi bruteforce?

66
Thomaschaaf

Obbligatorio:

  • installazione di sistema con modalità esperto, solo i pacchetti di cui ho bisogno
  • firewall scritto a mano con politica di default sull'input di iptables: drop, che consente l'accesso a SSH, HTTP o qualsiasi altro server in esecuzione
  • Fail2Ban per SSH [e talvolta FTP/HTTP/altro - a seconda del contesto]
  • disabilitare gli accessi root, forzare l'uso dell'utente normale e Sudo
  • kernel personalizzato [solo vecchia abitudine]
  • aggiornamento programmato del sistema

A seconda del livello di paranoia in aggiunta:

  • elimina la politica in uscita tranne un paio di destinazioni/porte consentite
  • integrit per verificare se alcune parti degli articoli del file system non sono state modificate [con checksum esterno alla macchina], ad esempio Tripwire
  • scansione pianificata almeno con nmap del sistema dall'esterno
  • controllo log automatico per schemi sconosciuti [ma questo è principalmente per rilevare malfunzionamenti hardware o alcuni crash minori]
  • esecuzione programmata di chkrootkit
  • attributo immutabile per /etc/passwd quindi aggiungere nuovi utenti è leggermente più difficile
  • / tmp montato con noexec
  • port knocker o altro modo non standard per aprire le porte SSH [ad es. visitare la pagina Web "segreta" sul server Web consente la connessione SSH in arrivo per un periodo di tempo limitato da un indirizzo IP che ha visualizzato la pagina. Se ti connetti, -m state --satete ESTABLISHED si occupa di consentire il flusso di pacchetti fintanto che usi una singola sessione SSH]

Cose che non faccio da solo ma che hanno un senso:

  • grsecurity per il kernel
  • syslog remoto in modo che i registri non possano essere sovrascritti quando il sistema viene compromesso
  • avvisare di eventuali accessi SSH
  • configura rkhunter e impostalo per l'esecuzione periodica
50
pQd

Solo una nota sul firewalling della macchina ...

  • Usa una lista bianca, non una lista nera, ovvero blocca tutto e consenti solo ciò di cui hai bisogno, negando tutto il resto.
  • Non utilizzare GUI/ncurses o altri software che tentano di scrivere il firewall per te. In tal caso, consentirai al software di fare ipotesi per te - non devi correre questo rischio e non dovresti. Configuralo tu stesso, se non sei sicuro, disabilitalo - lo scoprirai abbastanza presto se è necessario. Se è già un sistema funzionante e non è possibile interrompere il traffico (bloccandolo accidentalmente), quindi eseguire tcpdump (dump su file) e prelevare campioni: studiarli in seguito, quindi capire cosa è valido e cosa no.
  • Personalmente non vedo alcun punto nell'esecuzione di un servizio su una porta non standard, gli strumenti non sono così stupidi in questi giorni da presumere che, poiché qualcosa è in esecuzione sulla porta 22 per esempio, allora deve essere ssh, e non altrimenti - per esempio amap e nmap 's -A opzione. Detto questo, puoi (e probabilmente dovresti preoccuparti) di modificare i tuoi servizi per nascondersi da occhi indiscreti, ad esempio, quanto segue consentirebbe all'attaccante di conoscere la versione esatta di OpenSSH che stai eseguendo, loro può quindi cercare exploit per quella versione esatta. Se nascondi queste cose, le renderebbe più difficile.
 [root @ ud-olis-1 uhtbin] # telnet localhost 22 
 Prova 127.0.0.1 ... 
 Connesso a localhost.localdomain (127.0.0.1). 
 Il carattere di escape è '^]'. 
 SSH-2.0-OpenSSH_3.9p1 
  • Mantieni aggiornati tutti i tuoi servizi pubblici e patchati con le ultime patch di sicurezza.
  • Non archiviare alcun DATO sul server gateway stesso, almeno ti farà guadagnare tempo quando riescono a entrare in questa macchina e perderai un servizio o due, e qualche volta, ma non i dati.

La linea di fondo è che non riuscirai mai a rendere nulla al 100% - questo non è possibile - quindi l'obiettivo è quello di rendere il più sicuro possibile - se è solo uno sforzo eccessivo per rompere il sistema, è abbastanza buono e la maggior parte dei lamenti gli script-kiddie passeranno al sistema successivo.

  • iptables è la strada da percorrere per qualsiasi sistema Linux, ma configuralo tu stesso.

Non usare mai alcun "software di sicurezza" che non sia basato su standard aperti - sono condannati a essere scritti male e verranno hackerati (non è una questione di "se", ma "quando"). I protocolli open source e open sono aperti al controllo pubblico e convergono per diventare un prodotto maturo e affidabile; il software a codice chiuso si basa principalmente sulla fiducia in se stessi degli autori di quanto sia grande/sicuro un prodotto loro pensano che sia - cioè un piccolo numero di occhi contro una terra piena di occhi.

Spero che aiuti :)

18
Xerxes
  • disabilita il login root
  • disabilita l'accesso tramite password (consenti solo l'accesso con chiave pubblica)
  • cambia porta SSH
  • usa denyhosts (o simili)

  • scrivi il tuo script iptbles (così controlli esattamente cosa consentire e puoi eliminare tutto il resto)

  • imporre l'uso di comunicazioni protette SSL/TLS e assicurarsi di disporre di certificati validi, non scaduti e firmati

  • attiva una rigorosa verifica del certificato per tutti i servizi esterni (ad esempio durante l'autenticazione di utenti con un server LDAP su un altro computer)
12
x-way
9
KPWINC

Come punto di partenza generale, seguo il benchmark/le guide del Center for Internet Security , che sono raccolte complete di best practice sulla sicurezza. Non sembra che il loro benchmark Debian sia stato aggiornato da qualche tempo, ma una panoramica generale dei passaggi è:

  • Applica le ultime patch/pacchetti del sistema operativo
  • Abilita la contabilità di sistema/kernel/processo.
  • Abilita MAC (ad es. SELinux o AppArmor).
  • Abilita firewall basato su host (iptables).
  • Verifica APT sources.list (le chiavi sono corrette, le fonti sono affidabili).
  • Ridurre al minimo i servizi di rete, disabilitare tutto ciò che non è necessario e firewall ciò che è.
  • Utilizzare TCPWrappers per limitare ulteriormente l'accesso al sistema.
  • Utilizzare solo protocolli di rete crittografati, disabilitare i servizi non crittografati (telnet, ftp, ecc.).
  • Configurare l'accesso remoto solo a SSH.
  • Disabilita le password di accesso dell'utente e richiede l'autenticazione basata su chiave.
  • Disabilita la condivisione del filesystem (NFS, SMB).
  • Abilita la registrazione del sistema remota/centralizzata (ed esamina regolarmente i registri!).
  • Impostare una password a livello di BIOS/firmware.
  • Imposta una password del bootloader.
  • Configura i backup di sistema, disponi di un piano di ripristino di emergenza e TEST che i backup siano validi e che il personale conosca le procedure di ripristino di emergenza!

Esistono molte risorse su tutte queste varie impostazioni, inclusi i comandi specifici e i file di configurazione da implementare sul sistema nei benchmark CISecurity.

6
jtimberman

Suggerirei di non collegare una macchina direttamente a Internet. Posiziona un qualche tipo di firewall tra la macchina e Internet. Ciò consente di eseguire il monitoraggio della sicurezza e della rete senza sovraccaricare il server. Personalmente, trovo che la segmentazione della rete e delle funzioni semplifichi spesso la risoluzione dei problemi di rete, sebbene a volte la complessità aggiuntiva renda l'analisi più difficile.

Il criterio firewall più sicuro, ma più fastidioso da gestire, è negare tutto e consentire esplicitamente solo il traffico che è necessario consentire. Questo è fastidioso, perché spesso è necessario aggiornare la politica del firewall poiché la rete deve essere modificata.

Vorrei anche suggerire di utilizzare una sorta di interfaccia firewall sul server: la chiave è la difesa in profondità. L'uso di porte non standard per i servizi correlati all'amministrazione non fa male. fail2ban va bene. Segui le domande più specifiche sulle applicazioni di sicurezza su Serverfault per trovare altre idee.

La sicurezza è come lo scherzo dei due escursionisti e dell'orso - mentre uno non può mai raggiungere una sicurezza perfetta, è utile essere un obiettivo più difficile rispetto agli altri ragazzi.

5
pcapademic

Alcune persone hanno indicato il Garantire Debian Manual . Questo dovrebbe essere perfettamente adeguato a tutto tranne che ai requisiti militari.

Molte persone pensano che essere ridicolmente paranoici sia bello o professionale o qualcosa del genere. È non , è solo fastidioso per gli altri amministratori e definitivo repressivo per i tuoi utenti. La maggior parte delle cose che vedrai raccomandate è solo un finto lavoro occupato per sentirsi utile per l'amministratore paranoico, ma in realtà non utile, poiché la vera violazione della sicurezza è probabilmente causata da un sistema non sufficientemente aggiornato e/o da una fonte interna.

Detto questo, considero uno dei miei principi non fidarmi di nulla sulla rete locale più di qualsiasi altra cosa da Internet. Pertanto, configuro tutto per richiedere l'autenticazione anche sulla rete locale. Cripto e autentico tutto il traffico tra tutti i computer usando IPsec.

Sono in procinto di convertire la crittografia dell'intero disco per tutti i miei server.

Installo solo i servizi che utilizzo. Non ho un firewall; Configuro i servizi che devo richiedere l'autenticazione o li limito (dalla configurazione del programma o dai wrapper TCP) a determinati IP. L'unica cosa che dovrei mai bloccare usando iptables era memcached, poiché non aveva un file di configurazione e non utilizzava i wrapper TCP.

Uso buone password generate casualmente per i miei account e mi fido del mio server SSH (e di tutti gli altri servizi) per tenere chi non conosce la password. fail2ban è solo per quelli con spazio limitato per i file di registro, IMO. (Dovresti avere abbastanza password per poterti fidare.)

4
Teddy

Segui questa bella guida su www.debian.org/doc/manuals/securing-debian-howto/

Personalmente cambio la porta ssh e utilizzo fail2ban + denyhosts. E blocco tutto ciò che non è necessario. Più blocchi, meno devi preoccuparti.

3
Vihang D