Cosa dovrebbe sapere ogni amministratore di sistema prima di amministrare un server pubblico?


10

Simile a questa domanda su StackTranslate.it, cosa dovrebbe sapere un amministratore di sistema che è abituato a situazioni private di tipo intranet prima di essere l'amministratore di un sito pubblico?

Questi potrebbero essere aspetti legati alla sicurezza come "non lasciare il congedo telnet" o cose pratiche come il bilanciamento del carico per un sito ad alto traffico.

Risposte:


12
  • Ogni app, ogni binario, ogni pacchetto esistente sul server è una responsabilità. Abbonati al principio "minimo bit"; se non è installato, non può essere compromesso.

  • Implementa il rilevamento delle intrusioni, come Tripwire o simili, e scansiona frequentemente.

  • Investi in un firewall hardware e apri solo le porte necessarie per la tua applicazione. Non consentire alle porte di amministrazione (ssh, rdp ecc.) Di essere visibili pubblicamente; limitarli agli indirizzi IP di gestione approvati.

  • Avere backup delle configurazioni del firewall / switch / router al momento dell'entrata in produzione. Se uno di questi dispositivi è compromesso, è molto più veloce recuperare recuperando il cervello del dispositivo e ricaricando la configurazione piuttosto che eseguire un controllo linea per linea della configurazione quando il tempo passa.

  • nmap il tuo ambiente dall'esterno frequentemente per assicurarti che non siano state aperte nuove porte.

  • Non fidarti mai di Internet; assicurati che tutto ciò che stai servendo fino alla rete sia sicuro come può essere (esegui la convalida dell'input sul lato server e la sanificazione per bloccare, ad esempio, gli attacchi SQL injection).

  • Tieni sotto controllo le tue patch.

  • In caso di compromissione, ricostruire da zero con i supporti appena scaricati. Non puoi più fidarti che i tuoi backup siano sicuri e che non siano stati compromessi (anche se tripwire può aiutarti in questo) per qualsiasi cosa diversa dai dati inerti e non eseguibili.


1
+1 per il backup della configurazione e la pulizia. Inoltre, quando possibile, prova a ottenere i dati archiviati "altrove", in modo da consentire la cancellazione senza compromettere l'integrità del server.
Avery Payne,

4

Uno strumento che ho trovato utile per la protezione della rete è nessus

Fondamentalmente, lo si imposta su un server esterno e si tenta di attaccare la propria rete con tutta una serie di exploit noti. Puoi impostarlo per la modalità provvisoria (dove nessuno degli attacchi dovrebbe bloccare il tuo server), o se sei abbastanza sicuro di avere tutto patchato, o puoi permetterti di riavviare i tuoi server se necessario, per la modalità non sicura .

Quindi fornirà un rapporto completo e completo per ogni macchina in grado di vedere quali sono le vulnerabilità / le debolezze che rileva e le classificherà in base alla gravità - e persino raccomanderà di intraprendere azioni per affrontare i problemi.


3

Dovrebbero sapere come funziona il loro sistema di backup e disaster recovery e come recupereranno il sistema quando / se viene compromesso.


1
Può sembrare sciocco, ma in realtà eseguire un ripristino del sistema dai backup una o due volte l'anno è prezioso per evidenziare i punti deboli della procedura (o un sistema del tutto rotto) che altrimenti non verrebbero rilevati fino a una situazione di emergenza, quando tutti gli occhi sono puntati tu
Brent,

3

Questo è un po 'contrario, ma per quanto riguarda la sicurezza non faccio distinzione tra un server interno e un server esterno. Prima o poi qualcuno commetterà un errore in un firewall, la direzione insisterà che un server venga esposto a causa di un client importante, Betty in contabilità otterrà in qualche modo un client VPN sul suo computer domestico infetto, ecc.

Detto questo, i livelli sono i tuoi amici e dovresti inserire la lista nera per impostazione predefinita.

Livelli: dovresti avere più livelli di sicurezza. Ad esempio, un firewall hardware e un firewall software. Questi hanno teoricamente lo stesso scopo, ma avere più livelli protegge dagli errori e mitiga le conseguenze dello sfruttamento di un singolo strato.

Un altro aspetto della stratificazione è "homeycombing", che è essenzialmente più DMZ. Ad un certo punto devi avere un certo livello di fiducia tra le tue macchine e le persone che accedono ai tuoi account. Se riesci a restringere quei punti di interazione, puoi controllare strettamente il tipo di traffico di cui ti fidi in qualsiasi momento. Ad esempio, se si separano i server di interfaccia / app dai server di database, si restringe il livello di affidabilità. Se i server delle tue app vengono compromessi, quegli aggressori ottengono un punto d'appoggio minimo per la tua infrastruttura (cioè, per continuare il loro attacco e tentare di sfruttare gli altri tuoi server, hanno solo quei punti di fiducia stabiliti da usare).

Per quanto riguarda la lista nera per impostazione predefinita, dovresti praticamente chiudere tutto e richiedere (anche se è solo te stesso) la giustificazione per ogni porta che apri, nome utente a cui consenti l'accesso, app che installi, ecc.


Ho sentito parlare (e usato) degli strati in difesa come strategia, ma mai favolosa, ottima idea. +1
Avery Payne,

3

Sui sistemi con QUALSIASI interfaccia pubblica, assicurati che i tuoi utenti dispongano di password sicure implementando una politica password sicura e testando il file password con un'utilità di cracking della password come john the ripper

Puoi inoltre proteggerti dagli attacchi di indovinare password con forza bruta bloccando gli indirizzi IP dopo diversi tentativi falliti. Un buon strumento per questo (su Linux) è Fail2ban


1

Il tuo interruttore può essere violato e qualcuno può manomettere i dati. Se non si possiede lo switch, impostare un VPN, poiché la restrizione dell'accesso al firewall per IP potrebbe non essere sufficiente.

Non lasciare aperte le porte tranne quelle a cui vuoi che accedano utenti e hacker. Analizza i tuoi server da altri siti ogni mese.

Non lasciare la porta predefinita di ssh aperta per gli hacker.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.