Le migliori pratiche per proteggere un server Web pubblico? [chiuso]

Naviga le tue risposte
5

Sto cercando di creare una lista di controllo "minima indispensabile" per proteggere un server Web Unix pubblico. Supponiamo che sia una pila LAMP (o simile). Questa lista dovrebbe essere il minimo da implementare. Ovviamente i requisiti aumenterebbero per i siti ad alto traffico (protezione DDoS, alta disponibilità, ecc.), Ma non me ne preoccupo. È sufficiente cercare un elenco di requisiti minimi per l'hosting di un singolo server Web che esegue Apache o NGINX e ha un database MySQL o MariaDB di base su server e una semplice applicazione PHP. Supponiamo che funzioni su AWS, DigitalOcean, ecc. Alcune idee includono:

  • Inserimento in black list / whitelist degli intervalli IP per paese
  • Disabilita il login remoto per root
  • Abilita fail2ban (disabilita gli IP dopo tanti tentativi di accesso falliti)
  • Configura il firewall per consentire solo porte rilevanti in ingresso (ad es. ssh, sftp, https)
  • Consenti solo HTTPS e verifica la validità del certificato e della configurazione del server utilizzando lo strumento di test Qualys SSL Labs ( link )
  • Abilita l'autenticazione a più fattori ovunque sia rivolta al pubblico come Amazon / Digital Ocean / ecc. account, le tue credenziali al server, ecc.
  • Modifica la password di root su almeno 16 caratteri, alfanumerici con caratteri speciali.
  • Che altro?
posta wubs 08.03.2017 - 17:15
fonte

2 risposte

2

Marcus Müller ha ragione, questa è una domanda molto ampia.

Le migliori politiche di sicurezza hanno un focus. Un famoso generale (Federico il Grande?) Disse una volta "proteggere tutto è proteggere nulla". Inizia creando un "profilo di minaccia" in modo che tu sappia cosa stai proteggendo, quindi identifica le best practice per proteggersi dalle minacce . Ovviamente, rivedi il profilo della tua minaccia ogni volta che riscontri attacchi specifici.

Per quanto è già stato detto, aggiungerei quanto segue:

  • Sposta il tuo sshd su una porta non standard. Gli script kiddies attaccano la porta 22, se il tuo sshd non c'è, solo gli aggressori più intelligenti lo troveranno.

  • Considera di mettere tutte le porte di ascolto non pubbliche (sshd, SNMP, rsyslogd ecc.) dietro una VPN. L'accesso (umano o inter-server) a tali servizi sarà un po 'più noioso da configurare, ma offre una protezione strong. Accesso solo per VPN particolarmente consigliato per server che non richiedono accesso pubblico diretto (come server di database o di coda messaggi).

  • Definisci le regole di uscita per il tuo firewall, non solo le regole in entrata. In particolare per i servizi a blackhats piace sfruttare una volta che hanno zombato il tuo server (come SMTP). Se in qualche modo il tuo server viene compromesso, ma il tuo dirottatore non può eseguire il ping o SMTP o SFTP in uscita ... questa è una linea di difesa aggiuntiva che ti fa guadagnare tempo per colpirli.

  • (ad alta intensità di manodopera, ma ne vale la pena) Considera l'upgrade dell'intera server farm a IPv6 (che comunque farà a fare comunque abbastanza presto). Tieni presente che fail2ban diventerà meno prezioso in quanto funziona solo su IPv4. IPSec è trasformato in IPv6.

risposta data 09.03.2017 - 11:51
fonte
3

Sicuramente aggiungerei che SSH non dovrebbe consentire l'autenticazione della password da solo, ma chiave pubblica (e / o qualche secondo token).

Personalmente aggiungo abilitando seLinux (o appArmor) alla lista, e abiliterei e configurerei anche auditd, e imposto l'uso di sudo.

C'è molto altro che potresti fare se volessi andare al di sopra del minimo, ma considererei queste tre cose parte della base che vorresti.

Se vuoi qualcosa di un po 'più formale, puoi consultare i benchmark CIS ( link ). Probabilmente non sono minimali, ma hanno qualche riconoscimento (qualunque sia la tua opinione sulla CSI).

CentOS (e ho il sospetto che i Mi piace a RedHat) ha anche alcuni strumenti per SCAP ( link ) è possibile controllare se si applicano.

    
risposta data 08.03.2017 - 20:14
fonte

Leggi altre domande sui tag

In che misura le collisioni SHA-1 hanno compromesso la verifica dell'applicazione? Qual è la differenza tra "Autorità di certificazione radice attendibili" e "Autorità di certificazione radice di terze parti" Archivio certificati Windows?