L'esecuzione di apt-get upgrade ogni tanto è sufficiente per mantenere sicuro un server Web?

Hai rimosso molti problemi che normalmente ti mettono nei guai (vale a dire, supponendo che l'app che stai ospitando sia completamente sicura). Da un punto di vista pratico, devi assolutamente considerarli.

Ma presumibilmente dal momento che ne sei a conoscenza, hai messo in atto alcune misure protettive. Parliamo del resto, allora.

Per cominciare, probabilmente non dovresti eseguire un aggiornamento "ogni tanto". La maggior parte delle distribuzioni gestisce mailing list di annunci di sicurezza e non appena viene annunciata una vulnerabilità, è piuttosto pubblica (beh, spesso lo è prima, ma nella tua situazione non puoi davvero monitorare tutte le liste di sicurezza nel mondo). Questi sono elenchi a basso traffico, quindi dovresti davvero iscriverti alla tua distribuzione ed eseguire l'upgrade quando ricevi notifiche da essa.

Spesso, un server gestito casualmente può subire un attacco forzato o un dizionario per un lungo periodo di tempo, poiché il manutentore non sta realmente cercando i segnali. È una buona idea quindi applicare le solite contromisure - nessuna autenticazione con password ssh, fail2ban su ssh e apache - e idealmente impostare avvisi di monitoraggio quando si verifica un'attività sospetta. Se è fuori dal tuo budget (tempo) di manutenzione, prendi l'abitudine di accedere regolarmente per controllare queste cose manualmente.

Sebbene non sia tradizionalmente considerato parte della sicurezza, vuoi assicurarti di poter aprire rapidamente un nuovo server. Ciò significa che gli script di configurazione del server (strumenti come Ansible, Chef, ecc. Sono comunque utili nell'amministrazione del sistema) e un sistema di backup automatico che hai testato. Se il tuo server è stato violato, devi presumere che sia compromesso per sempre e semplicemente cancellarlo, e questo fa schifo se non hai eseguito backup regolari dei tuoi dati.

No. Questo non abbastanza per tenerti al sicuro.

Probabilmente ti manterrà al sicuro per un po' di tempo, ma la sicurezza è complessa e veloce, quindi il tuo approccio non è davvero abbastanza buono per la sicurezza a lungo termine . Se tutti facessero le stesse ipotesi che stai facendo tu nella tua domanda, Internet sarebbe ormai una grande botnet.

Quindi no, non limitiamo questa domanda ai pacchetti. Diamo un'occhiata alla sicurezza del server in modo olistico in modo che chiunque legga questo articolo abbia un'idea di quanti pezzi in movimento ci siano realmente.

• APT (ad esempio i repository di Ubuntu) copre solo una parte del tuo stack software. Se stai usando (ad esempio) Wordpress o un'altra popolare libreria PHP e non è controllata da repository, devi aggiornare anche quella. I framework più grandi hanno meccanismi per automatizzare questo, ma assicurati di eseguire backup e monitorare lo stato del servizio perché non sempre vanno bene.

• L'hai scritto tutto da solo, quindi pensi di essere al sicuro dai bambini del copione? Ci sono SQL injection automatizzate e bot di exploit XSS in giro, che colpiscono allo stesso modo ogni stringa di query e modulo.

  Questo è in realtà uno dei luoghi in cui un buon framework aiuta a proteggere da programmatori inadeguati che non apprezzano le sfumature di questi attacchi. Avere un programmatore competente che verifica il codice aiuta anche a dissipare i timori qui.

• PHP (o Python, o qualunque cosa tu stia eseguendo) deve davvero essere in grado di scrivere ovunque? Rafforza la tua configurazione e mitigherai contro molti attacchi. Idealmente, gli unici posti in cui una webapp è in grado da scrivere sono un database e luoghi in cui gli script non verranno mai eseguiti (ad esempio una regola nginx che consente solo di servire file statici).

  Le impostazioni predefinite di PHP (almeno come le persone le usano) consentono a PHP di leggere e scrivere PHP ovunque nella webroot. Ciò ha gravi implicazioni se il tuo sito web viene sfruttato.

• E il tuo programma di aggiornamento è attivamente dannoso. Cosa diavolo è "ogni tanto"? I bug di sicurezza remota critici hanno un breve tempo di dimezzamento, ma c'è già un ritardo tra 0 giorni e la disponibilità delle patch, e alcuni exploit sono anche decodificati dalle patch (per catturare gli slow-poke).

  Se applichi gli aggiornamenti solo una volta al mese, c'è una possibilità molto forte che eseguirai software sfruttabile in natura. TL;DR:usa gli aggiornamenti automatici.

• Le versioni delle distribuzioni non durano per sempre. Se sei stato ragionevole e hai scelto una versione LTS di Ubuntu, hai 5 anni dalla versione iniziale. Entro quel tempo usciranno altre due versioni LTS e questo ti darà delle opzioni.

  Se eri su tutte le furie "NEWER IS BETTER" e hai scelto la 16.10 quando hai configurato il tuo server, hai 9 mesi . Sì. Quindi devi eseguire l'upgrade tramite 17.04, 17.10 prima di poterti rilassare su 18.04 LTS.

  Se la tua versione di Ubuntu scade, puoi eseguire il dist-upgrade per tutto il giorno, ma non riceverai alcun aggiornamento di sicurezza.

• E lo stesso stack LAMP non è l'unico vettore di attacco a un server web standard.

  • Sei necessario rafforza la tua configurazione SSH:solo usa le chiavi SSH, disabilita le password, devia la porta, disabilita gli accessi root, monitora i tentativi bruti e bloccali con fail2ban .
  • Escludi qualsiasi altro servizio tramite firewall con ufw (et alii).
  • Non esporre mai il database (a meno che tu non abbia bisogno a, quindi bloccare l'IP in entrata nel firewall).
  • Non lasciare installati script PHP casuali o lo farai dimenticali e loro lo faranno fatti hackerare.

• Non c'è monitoraggio nella tua descrizione. Sei cieco. Se succede qualcosa e inizia a pompare spam, a infettare le tue pagine web, ecc., come puoi dire che è successo qualcosa di brutto? Monitoraggio del processo. Confronto file pianificato con git (assicurati che sia un accesso di sola lettura dal server).

• Considera la sicurezza (fisica e remota) del tuo ISP. I dieci centesimi di "host" (noti anche come pirati di CPanel) — che pagano $ 2 al mese di piani di hosting illimitati — stanno investendo le stesse risorse in sicurezza di una struttura server dedicata? Chiedi in giro e indaga sulla cronologia delle violazioni.

• E poi ci sei tu . La sicurezza del computer su cui si codifica tutta questa roba è importante quasi quanto il server. Se usi le stesse password, sei una responsabilità. Proteggi le tue chiavi SSH con una chiave fisica FIDO-UF2.

Faccio devops da circa 15 anni e lo è qualcosa che puoi imparare sul posto di lavoro, ma in realtà basta solo una violazione, un adolescente, un bot, per rovinare un intero server e causare settimane di lavoro per la disinfezione del prodotto di lavoro.

Basta essere coscienti su ciò che è in esecuzione e ciò che è esposto, ti aiuta a prendere decisioni migliori su ciò che stai facendo. Spero solo che questo aiuti qualcuno ad avviare il processo di controllo del proprio server.

Ma se tu, il programmatore di app web medio di tutti, non sei disposto a scavare in questo genere di cose, dovresti persino eseguire un server? Questa è una domanda seria. Non ho intenzione di dirti che non dovresti assolutamente, ma cosa ti succede quando ignori tutto questo, il tuo server viene violato, il tuo cliente perde denaro e tu esponi le informazioni personali del cliente (es. dati di fatturazione) e vieni citato in giudizio ? Sei assicurato per quel livello di esposizione a perdite e responsabilità?

Ma sì, questo è il motivo per cui i servizi gestiti costano molto di più dei server stupidi.

Sulla virtù dei backup...

Un backup completo del sistema è forse la cosa peggiore che potresti tenere a portata di mano, per sicurezza - perché sarai tentato di usarlo se vieni violato. Il loro unico posto è il recupero da un guasto hardware.

Il problema con il loro utilizzo negli hack è che ti reimposti a un momento ancora precedente. Eppure ora sono evidenti più difetti nel tuo stack, esistono ancora più exploit per il buco che ti ha preso. Se rimetti online quel server, potresti essere hackerato all'istante. Potresti bloccare il traffico in entrata con un firewall ed eseguire un aggiornamento del pacchetto e questo potrebbe aiutarti, ma a questo punto non sai ancora cosa ti ha preso, o quando ti ha preso. Stai basando tutte le tue supposizioni su un sintomo che hai visto (iniezione di annunci sulle tue pagine, spam rimbalzato nella tua postaq). L'attacco potrebbe essere avvenuto mesi prima.

Sono ovviamente meglio di niente, e vanno bene nel caso in cui un disco muoia, ma ancora una volta, sono spazzatura per la sicurezza .

Buoni backup sono ricette

Vuoi qualcosa, solo un documento in un linguaggio semplice o qualcosa di tecnico come una routine Ansible/Puppet/Chef, che possa guidare qualcuno a ripristinare l'intero sito su un server nuovo di zecca. Cose da considerare:

• Un elenco di pacchetti da installare
• Un elenco di modifiche alla configurazione da apportare
• Come ripristinare l'origine del sito Web dal controllo della versione.
• Come ripristinare il dump del database* e qualsiasi altro file statico di cui potresti non avere il controllo di versione.

Più prolisso puoi essere qui, meglio è perché questo serve anche come backup personale . I miei clienti sanno che se io muoiono, hanno un testato prevedono di ripristinare i loro siti su hardware che controllano direttamente.

Un buon ripristino con script non dovrebbe richiedere più di 5 minuti. Quindi anche il delta temporale tra un ripristino tramite script e il ripristino di un'immagine disco è minimo.

È molto probabile che tu mantenga il server principalmente sicuro se esegui spesso gli aggiornamenti (ad esempio almeno ogni giorno, invece che solo "ogni tanto").

Ma di tanto in tanto si verificano bug critici, come Shellshock o ImageTragick. Anche la configurazione del server non sicura potrebbe rendere possibili attacchi. Ciò significa che dovresti anche intraprendere più azioni oltre a eseguire aggiornamenti regolari, come:

• ridurre la superficie di attacco eseguendo un sistema minimo, ovvero non installare alcun software non necessario
• ridurre la superficie di attacco limitando qualsiasi servizio accessibile dall'esterno, ad esempio non consentire l'accesso SSH basato su password (solo basato su chiave), non eseguire servizi non necessari ecc.
• assicurati di comprendere l'impatto degli aggiornamenti critici
• aspettarsi che il sistema venga attaccato e cercare di ridurre l'impatto, ad esempio eseguendo servizi accessibili dall'esterno all'interno di chroot, jail o container
• registra eventi importanti come accessi non riusciti, comprendi i log e analizzali effettivamente

Tuttavia, il vettore di attacco iniziale più utilizzato sono probabilmente le applicazioni Web non sicure come Wordpress o altri CMS. Ma la tua supposizione era che l'applicazione web fosse completamente sicura, quindi si spera che lo sia davvero.