Quali passi prendi per proteggere un server Debian? [chiuso]

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 di bruteforce?

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 usando l'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
• integritper 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
• l'attributo immutabile per l' /etc/passwdaggiunta di 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 ESTABLISHEDsi occupa di consentire il flusso di pacchetti purché utilizzi 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
• configurare rkhunter e impostarlo per l'esecuzione di volta in volta

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 per supporre che, poiché qualcosa è in esecuzione sulla porta 22 per esempio, allora deve essere ssh, e non altrimenti - per esempio amape nmap's -Aopzione. Detto questo, puoi (e probabilmente dovresti preoccuparti) modificare i tuoi servizi per nascondersi da occhi indiscreti, ad esempio, ciò che segue farebbe sapere all'attaccante la versione esatta di OpenSSHquello che stai eseguendo, quindi potranno 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 ...
    Collegato 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 perderai tempo quando riusciranno 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; software closed-source si basa principalmente sulla fiducia in se stessi autori di quanto grande / un prodotto sicuro che pensano che sia - vale a dire un piccolo numero di occhi contro una terra piena di occhi.

Spero che aiuti :)

• 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)

Comincia qui:

http://www.debian.org/doc/manuals/securing-debian-howto/

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.

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, anche se a volte la complessità aggiuntiva rende 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.

Alcune persone hanno indicato il Manuale di protezione di Debian . 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 lo è , è solo fastidioso per gli altri amministratori e completamente 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 di cui ho bisogno per richiedere l'autenticazione o limitarli (dalla configurazione del programma o dai wrapper TCP) a determinati IP. L'unica cosa che ho mai memcachedavuto bisogno di bloccare usando iptables era , dato che 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.)

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.