Domanda:
Eseguire "apt-get upgrade" ogni tanto abbastanza spesso da mantenere un server Web sicuro?
MPS
2017-02-20 13:22:00 UTC
view on stackexchange narkive permalink

Presupposti:

  • Server Web LAMP normale che esegue l'app Web. (Es. AWS EC2 + Apache2 + MySQL + Php7)
  • Non direttamente preso di mira da qualche super hacker o organizzazione governativa, ecc.
  • Relativo al punto precedente, nessun social engineering e il web l'app stessa è sicura.

Destinata a chi?

Scansioni automatizzate ed exploit. Ce ne sono altri?

apt-get update && apt-get upgrade ogni tanto abbastanza da mantenere sicuro un server web?


In caso negativo

Cos'altro dovrebbe fare il programmatore di applicazioni web "medio", che si occupa anche del server, per mantenere il server web ragionevolmente sicuro per una società in fase di avvio.

Dipende ...

Sì, dipende sempre da molte cose. Includi ipotesi per i casi più comuni (principio di pareto) di cui il programmatore di app web comune potrebbe o meno essere a conoscenza.

sono i compiti?
@Purefan No, non lo è.Ho cercato di inquadrare la domanda in modo da ricevere risposte abbastanza ampie da aiutare me e altri principalmente programmatori che allo stesso modo devono occuparsi anche del server.
Hai considerato gli aggiornamenti automatici?
Ubuntu può eseguire automaticamente i suoi aggiornamenti con pochi problemi.Quasi sicuramente li installerebbe prima di te.
@Calimo No, non l'avevo fatto.Grazie per avermi indicato quel pacchetto.Dopo aver letto [questa domanda correlata] (http://askubuntu.com/questions/9/how-do-i-enable-automatic-updates) un breve follow-up: Il rischio che questi aggiornamenti automatici incorrano in errori e interrompano il web-app trascurabile?
@MPS che non mi è mai successo, tutto è sempre riavviato e lo utilizzo su diversi server da molti anni.Ma sicuramente chiuderà l'applicazione durante l'aggiornamento.Se non diversamente indicato, interromperà mysql ma non apache, e solo tu sai cosa succede dopo.
@Calimo Ok, grazie per l'avvertimento.Approfondirò ulteriormente questa opzione.
Esegue un'app PHP scadente?La maggior parte delle violazioni del server web che ho visto provengono dalle app che esegui su di esse, non dal software del server o dal sistema operativo stesso.
Questa domanda non è formulata molto bene perché stai chiedendo come "mantenere sicuro un server web", che è troppo ampio per un sito di domande e risposte e impossibile rispondere nello spazio fornito.Dovresti porre una domanda più ristretta, come "come devo fare la gestione delle patch su Debian Linux?"Se questa è la tua domanda, tieni presente che apt-get update scaricherà un kernel con patch, ma devi riavviare per eseguire effettivamente il kernel con patch.Quindi il riavvio / i tempi di inattività pianificati sono un fattore importante nella gestione delle patch.
@AndréBorie L'OP ha espressamente escluso l'app dalla considerazione, "e l'app web stessa è sicura".Solo il sistema operativo e l'ambiente e la configurazione del server si riferiscono a Q. Sì, le app PHP possono essere un enorme buco in una configurazione altrimenti sicura, ma OP non lo chiede.Mantenere l'ambiente sicuro, esclusa l'app, è l'obiettivo dell'OP
Hai menzionato LAMP.I componenti di LAMP sono gestiti da apt?
@JonasWielicki Bene notato che potrebbero non farlo.Nel mio caso lo sono.Altri dovranno pensare anche a questo.Grazie.
@MPS Nella mia esperienza, il 99% dei compromessi sfrutta direttamente i difetti nell'app, non i pacchetti del server web.Sto usando aggiornamenti automatici per anni senza problemi (a parte il piccolo / avvio che si riempie di kernel) e lo consiglio.
Dipende dalla distribuzione e dal repository Linux aggiunti.Ad esempio, con Ubuntu LTS solo un numero limitato di pacchetti è in manutenzione, per un po 'di tempo.Prima o poi è necessario eseguire l'upgrade e seguire attentamente gli avvisi di sicurezza, alcuni consigliano azioni manuali.
È necessario assicurarsi che i componenti vengano riavviati o ricaricati in altro modo in modo che utilizzino effettivamente le versioni aggiornate.
Otto risposte:
#1
+76
Xiong Chiamiov
2017-02-20 14:08:35 UTC
view on stackexchange narkive permalink

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 poiché ne sei a conoscenza, hai alcune misure protettive in atto. Parliamo del resto, quindi.

Per cominciare, probabilmente non dovresti eseguire un aggiornamento "ogni tanto". La maggior parte delle distribuzioni gestisce le 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 e aggiornare quando ricevi notifiche da essa.

Spesso, un server gestito casualmente può essere forzato o aggredito dal dizionario per un lungo periodo di tempo, dal momento che il manutentore non sta davvero cercando i segni. È quindi una buona idea applicare le solite contromisure - nessuna autenticazione con password ssh, fail2ban su ssh e apache - e idealmente impostare avvisi di monitoraggio quando si verificano attività sospette. Se non rientra nel tuo budget di manutenzione (tempo), prendi l'abitudine di accedere regolarmente per controllare manualmente queste cose.

Sebbene non sia tradizionalmente considerato parte della sicurezza, devi assicurarti di poter portare creare 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.

La ringrazio per la risposta. Sembra che ci siano molte mailing list.Ad esempio per [Ubuntu Server] (https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce).Sono queste le mailing list di cui parli?
+1 per considerare un server violato un mattone.Se non hai un buon piano di riserva e lo usi, è meglio che tu abbia un buon curriculum.
@MPS Sì, questo è quello (per Ubuntu).
Oltre a fail2ban, trovo che un [logcheck] (http://www.logcheck.org/) configurato correttamente sia inestimabile per il monitoraggio di un gran numero di sistemi.Con esso, si impostano whitelist di attività normale e qualsiasi cosa al di fuori del normale che si presenti nel (set configurabile di) file di registro di sistema viene automaticamente inviata via e-mail a un destinatario di propria scelta (idealmente finisce rapidamente su un diverso, minimo, sistema sicuro).Non è * perfetto *, ma fa * molta strada * per catturare cose insolite molto prima che quelle cose insolite diventino un problema.
Vorrei andare oltre e seguire la filosofia di Unix ... servizi minimi.In quanto tale, non c'è posto per esporre i servizi SSH a Internet in generale.Prova a cercare la porta 22 di uno dei server di Google, ad esempio.
Con Debian, mi piace avere apticron in esecuzione sul server.Ti invia e-mail quando sono disponibili nuovi aggiornamenti per qualsiasi pacchetto installato.Questo aiuta nei casi in cui i pacchetti ottengono aggiornamenti di sicurezza di cui potresti non essere a conoscenza del fatto che li hai installati.Combina con apt-listchanges e apt-listbugs per evitare brutte sorprese (anche se è raro con Debian stable che apt-list {bugs, changes} restituisca qualcosa).
"Sebbene non sia tradizionalmente considerato parte della sicurezza, vuoi assicurarti di poter aprire rapidamente un nuovo server."- Direi che è una questione di [Disponibilità] (https://en.wikipedia.org/wiki/Information_security#Availability), mentre gli strumenti moderni lo rendono molto più facile da implementare.
#2
+27
Oli
2017-02-21 02:11:52 UTC
view on stackexchange narkive permalink

No. Questo non è sufficiente 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 buono sufficiente per la sicurezza a lungo termine . Se tutti facessero le stesse ipotesi che stai facendo 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 abbia un'idea di quanti pezzi mobili ci sono davvero.

  • 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 questa non è controllata dal repo, devi aggiornare anche quella. I framework più grandi hanno meccanismi per automatizzarlo, ma assicurati di eseguire backup e monitorare lo stato del servizio perché non sempre vanno bene.

  • Hai scritto tutto da solo, quindi pensi di essere al sicuro dagli script kiddies? Ci sono SQL injection automatizzate e bot di exploit XSS in giro, che colpiscono ogni stringa di query e ogni modulo allo stesso modo.

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

  • PHP (o Python, o qualunque cosa tu stia utilizzando) ha davvero bisogno di essere in grado di scrivere ovunque? Rafforza la tua configurazione e mitigherai molti attacchi. Idealmente gli unici posti in cui una webapp è in grado di scrivere sono un database e luoghi in cui lo scripting non verrà mai eseguito (ad esempio una regola nginx che consente solo di servire file statici).

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

    Nota: se blocchi l'accesso in scrittura, cose come WordPress non saranno in grado di aggiornarsi automaticamente. Cerca strumenti come wp-cli e falli funzionare in base a una pianificazione.

  • E la tua pianificazione degli aggiornamenti è attivamente dannosa. Cosa diavolo è "ogni tanto"? I bug critici per la sicurezza remota hanno una breve emivita, ma c'è già un ritardo tra 0 giorni e la disponibilità delle patch, e alcuni exploit sono anche invertiti ingegnerizzati dalle patch (per catturare gli slow-pokes).

    Se tu stai applicando gli aggiornamenti solo una volta al mese, c'è una forte possibilità che tu stia eseguendo software sfruttabile in natura. TL; DR: utilizza 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 dal rilascio iniziale. Altre due versioni di LTS usciranno entro quel lasso di tempo e questo ti darà delle opzioni.

    Se eri su una furia "PIÙ NUOVO È MEGLIO" e sei andato con la 16.10 quando hai impostato il tuo server, hai 9 mesi . Si. Quindi devi aggiornare fino al 17.04, 17.10 prima di poter rilassarti su 18.04 LTS.

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

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

    • Tu è necessario rafforzare la configurazione SSH: solo utilizzare chiavi SSH, disabilitare le password, deviare la porta, disabilitare gli accessi root, monitorare i tentativi bruti e bloccarli con fail2ban .
    • Firewall per disattivare qualsiasi altro servizio con ufw (et alii).
    • Non esporre mai il database (a meno che non sia necessario a, quindi blocca l'IP in entrata nel firewall).
    • Non lasciare script PHP casuali installati o li dimenticherai e vieni violato.
  • Non c'è monitoraggio nella tua descrizione. Sei cieco. Se succede qualcosa e inizia a pompare spam, infettare le tue pagine web e così via, come puoi sapere che è successo qualcosa di brutto? Monitoraggio del processo. Confronto pianificato dei file con git (assicurati che sia un accesso di sola lettura dal server).

  • Considera la sicurezza (fisica e remota) del tuo ISP. Gli "host" da una dozzina di centesimi (noti anche come pirati CPanel) - che stanno cercando piani di hosting illimitati da $ 2 al mese - stanno investendo le stesse risorse in sicurezza di una struttura server dedicata? Chiedere in giro e indagare sulla cronologia delle violazioni.

    Nota: una violazione pubblicizzata non è necessariamente una cosa negativa. I piccoli host tendono a non avere alcun record e quando le cose vengono violate, non ci sono "post-mortem" pubbliche eseguite da molti host e servizi affidabili.

  • E poi ci sei tu . La sicurezza del computer su cui codifichi 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 è qualcosa che puoi impara sul lavoro, ma in realtà basta una sola violazione, un adolescente, un bot, per rovinare un intero server e causare settimane di lavoro nella disinfezione del prodotto di lavoro.

Solo consapevole 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 auditing del proprio server.

Ma se tu, il programmatore medio di applicazioni web, non sei disposto a scavare in questo genere di cose, dovresti anche gestire un server? Questa è una domanda seria. Non ti dirò che non dovresti assolutamente, ma cosa ti succede quando ignori tutto questo, il tuo server viene violato, il tuo cliente perde denaro ed esponi le informazioni personali del cliente (es. Dati di fatturazione) e sei 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.


In virtù di backup ...

Un backup completo del sistema è forse la cosa peggiore che puoi tenere in giro - per sicurezza - perché sarai tentato di usarlo se vieni hackerato. Il loro unico posto è il ripristino da un guasto hardware.

Il problema con il loro utilizzo negli hack è che si resetta a un momento ancora precedente. Ancora più difetti nel tuo stack sono evidenti ora, esistono ancora più exploit per il buco che ti ha colpito. Se rimetti il ​​server online, potresti essere violato all'istante. Potresti isolare il traffico in entrata con un firewall ed eseguire un aggiornamento del pacchetto e questo potrebbe aiutarti, ma a questo punto ancora non so 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 mailq). L'hacking avrebbe potuto essere mesi prima.

Ovviamente sono meglio di niente e vanno bene nel caso di un disco che muore, ma ancora una volta, sono spazzatura per sicurezza .

I buoni backup sono ricette

Vuoi qualcosa, solo un documento in linguaggio semplice o qualcosa di tecnico come una routine Ansible / Puppet / Chef, che possa guidare qualcuno attraverso il ripristino dell'intero sito a un nuovo server. 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 controllare la versione.

Più puoi essere verboso qui, meglio è perché anche questo funge da backup personale . I miei clienti sanno che se io muoio, hanno un piano testato per ripristinare i loro siti sull'hardware che controllano direttamente.

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

* Nota : anche i dump del database devono essere controllati. Assicurati che non ci siano nuovi utenti amministratori nel tuo sistema o blocchi di script casuali. Questo è importante quanto controllare i file sorgente o verrai semplicemente violato di nuovo.

Se non hai creato l'infezione, non puoi mai _essere sicuro_ di aver eliminato tutta l'infezione, anche dopo settimane di lavoro per disinfettarla.Ecco perché __devi__ avere dei backup.Backup del tuo prodotto di lavoro, del tuo database, delle configurazioni del tuo server e di tutto ciò che puoi sostituire.Se, come OP, controlli il server, dovresti avere un backup dell'intero sistema, dal kernel in su.
Non credo che potrei essere più in disaccordo con i backup del kernel.Sono una dannosa perdita di tempo che si presta a essere restaurata ciecamente e pensare che ha risolto il problema.I backup dovrebbero essere ricette descrittive su come assemblare cose uniche per te.E come ogni ricetta, dovrebbero essere testate e perfezionate.È probabile che solo scrivendolo migliorerà la tua configurazione.I backup completi dovrebbero essere usati solo per guasti hardware, e anche in questo caso, una ricetta con script sarebbe quasi altrettanto veloce.
#3
+20
Steffen Ullrich
2017-02-20 14:01:57 UTC
view on stackexchange narkive permalink

La probabilità che tu mantenga il server per lo più sicuro è alta se esegui gli aggiornamenti spesso (cioè almeno giornalmente, invece che solo "ogni tanto").

Tuttavia, di tanto in tanto si verificano bug critici, come Shellshock o ImageTragick. Anche una configurazione insicura del server potrebbe rendere possibili attacchi. Ciò significa che dovresti anche intraprendere più azioni oltre alla semplice esecuzione di 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 di 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
  • registrano eventi importanti come accessi non riusciti, comprendere i log e analizzare effettivamente i log

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

Grazie per la tua risposta con ulteriori azioni da considerare. Controllerò i log e imposterò un sistema per controllarli.
+1 per indicare che il vettore di attacco può essere app Web non sicure
#4
+6
Calimo
2017-02-20 15:52:38 UTC
view on stackexchange narkive permalink

La maggior parte delle moderne distribuzioni Linux viene fornita con una sorta di soluzione di aggiornamento automatico. Dovresti considerare di accenderlo sui tuoi server. Ciò ridurrà notevolmente il tempo in cui il tuo server è vulnerabile agli attacchi.

Dato che stai menzionando Debian, dovresti considerare la possibilità di impostare aggiornamenti automatici. RedHat ha yum-cron e Suse può ottenerli tramite YaST.

Questi aggiornamenti sono normalmente limitati alle patch di sicurezza ed è improbabile che danneggino il tuo sistema, tuttavia non è del tutto impossibile. Alla fine spetta a te valutare il rischio e i benefici di questo approccio.

#5
+3
Neith
2017-02-20 17:01:02 UTC
view on stackexchange narkive permalink

apt-get upgrade installa solo versioni più recenti di pacchetti già installati. Non installa pacchetti che non sono attualmente installati e non aggiornerà un pacchetto già installato se la versione più recente dipende da un pacchetto che non è attualmente installato.

In Debian e Ubuntu, ogni versione del kernel è messo in un pacchetto separato, con la versione inclusa nel suo nome. Inoltre, c'è un pacchetto virtuale che dipende sempre dall'ultimo kernel disponibile, la dipendenza viene modificata con ogni versione. Ad esempio, poiché per ora linux-image-generic in xenial dipende da linux-image-4.4.0-63-generic . Questo schema consente di mantenere installate le vecchie versioni dei kernel e, nel caso in cui la più recente risulti incompatibile con il tuo hardware.

Tuttavia, questo significa che apt-get upgrade non verrà installato kernel più recenti: è necessario apt-get dist-upgrade per questo. Tuttavia, molte persone evitano di usarlo automaticamente poiché può anche rimuovere i pacchetti. Nelle versioni più recenti di Ubuntu, puoi usare apt upgrade , che installa nuove dipendenze, ma non rimuove mai alcun pacchetto.

Inoltre, quando aggiorni OpenSSL devi almeno ricaricare il servizi che utilizzano quella biblioteca; in Ubuntu il sistema chiede solo il riavvio per stare al sicuro, e molte persone hanno anche riserve contro i riavvii automatici.

Credo che apt-get upgrade per installare i pacchetti e che tu lo stia confondendo con apt-get update.
Da `man apt-get`:" I pacchetti attualmente installati con le nuove versioni disponibili vengono recuperati e aggiornati; in nessun caso i pacchetti attualmente installati vengono rimossi, né i pacchetti che non sono già installati vengono recuperati e installati. Le nuove versioni dei pacchetti attualmente installati che non possonoessere aggiornato senza modificare lo stato di installazione di un altro pacchetto verrà lasciato alla versione corrente. "Chiarirò la risposta.
apt-get autoclean && apt-get autoremove ti aiuterà in questo.
#6
+2
Tim X
2017-02-24 06:17:13 UTC
view on stackexchange narkive permalink

Ci sono già alcune buone risposte qui. Tuttavia, volevo colmare alcune lacune e sottolineare un paio di cose che non sembrano essere affrontate in alcune delle risposte esistenti.

Non preso di mira direttamente da qualche super hacker o organizzazione governativa ecc

Questa è una prospettiva pericolosa. Molte piccole organizzazioni sono state costrette a dichiarare bancarotta sulla base di variazioni di questa idea centrale. Non puoi davvero prevedere chi potrebbe trovare un uso o una ragione per hackerare il tuo server. È proprio a causa di questo tipo di presupposto sottostante che un governo o un super hacker possa prendere di mira il nostro sistema. Potrebbero non essere interessati alla tua applicazione o ai tuoi dati, potrebbero semplicemente desiderare un innocente punto di "salto di qualità" da utilizzare come parte di un hack più grande o più complesso su un obiettivo più prezioso.

Web LAMP normale -server che esegue l'app web. (Es. AWS EC2 + Apache2 + MySQL + Php7)

Fai attenzione al "normale". La tua configurazione potrebbe non essere normale come pensi. Molto dipende da cosa hai installato e da quali repository proviene il pacchetto. Alcune delle variazioni di cui essere a conoscenza includono:

  • Tipo di distribuzione. Ad esempio, c'è una grande differenza tra le distribuzioni Ubuntu LTS e non LTS. Come regola pratica, le distribuzioni non LTS avranno tipicamente aggiornamenti più frequenti e sarà importante eseguire gli aggiornamenti (o rivedere gli aggiornamenti - vedi sotto) più frequentemente.

  • Tipo di repository. La maggior parte delle distribuzioni, incluso Ubuntu, ha diversi tipi di repository. Ci sono i repository principali gestiti da Ubuntu che in genere passano attraverso cicli di test abbastanza robusti e che ricevono aggiornamenti in modo abbastanza tempestivo. Poi ci sono repository di tipo "contrib" che non sono mantenuti dal team di distribuzione principale. Questi possono essere partner di terze parti o altri utenti o gruppi di sviluppo. L'enfasi posta su questi repository può variare notevolmente. A volte, avranno un'attenzione particolare sicurezza e una minore attenzione alla stabilità, altri si concentreranno sulla stabilità e l'eccesso di sicurezza. Conoscere / comprendere i repository dai quali è stato installato il software è importante.

  • Sapere cosa è installato. Troppo spesso si sente parlare di un sistema che è stato compromesso solo per scoprire che il compromesso si è verificato in un pacchetto trascurato, installato di default o richiesto dallo stack LAMP, ma è una dipendenza profondamente sepolta o sottile di cui non eri a conoscenza di. Assicurati di aver rimosso tutti i pacchetti non necessari (cosa che può essere difficile da determinare soprattutto perché alcuni pacchetti hanno delle dipendenze insolite).

  • Librerie ausiliarie. È comune trascurare librerie aggiuntive che sono state installate, ma che non sono gestite dall'ecosistema apt. Ad esempio, una libreria PHP era necessaria per uno scopo speciale che non era nel carico standard delle distribuzioni o che doveva essere compilata sul sistema a causa di altre dipendenze. Un esempio comune sono i driver di database PHP per database commerciali. Sebbene le cose siano probabilmente migliorate dall'ultima volta che ho dovuto gestire uno stack basato su PHP, posso ricordare una volta in cui dovevi creare il driver PHP per Oracle. Sebbene il processo fosse relativamente semplice, era necessario ricordare di ricostruire quel driver dopo l'aggiornamento delle librerie dipendenti per garantire che la libreria fosse collegata alla versione con patch. Questo può anche essere un problema con cose come openSSL. Una distribuzione potrebbe installare una versione aggiornata della libreria condivisa, ma potrebbe essere necessario intraprendere azioni aggiuntive per garantire che l'applicazione stia effettivamente utilizzando la libreria aggiornata e non la vecchia libreria con una vulnerabilità nota.

È necessario verificare la presenza di aggiornamenti su base giornaliera e quindi rivedere questi aggiornamenti per valutarne l'importanza e il potenziale per danneggiare il sistema. Mentre il processo di aggiornamento apt di Ubuntu è abbastanza robusto e raramente interrompe le cose, succede di tanto in tanto. A causa dell'enfasi sulla stabilità, specialmente per LTS versioni, il processo di aggiornamento tenderà ad essere conservativo, quindi è necessario rivedere e non solo eseguire apt-get upgrade. Ad esempio, a causa di possibili problemi di dipendenza e la possibilità di introdurre instabilità o rotture, a volte, sarà necessario eseguire un "dist-upgrade". Ubuntu lo farà deliberatamente come un modo per chiarire che è necessario fare attenzione, ad esempio l'aggiornamento di apt-get può essere considerato affidabile per non rompere le cose, ma potrebbe non installare tutte le correzioni di sicurezza. apt-get dist-upgrade lavorerà più duramente per garantire che tutti gli aggiornamenti di sicurezza vengano applicati, ma potrebbe rompere le cose, quindi l'amministratore deve fare più attenzione.

La cosa sfortunata è che qui non ci sono scorciatoie reali. La realtà è che sei in una situazione imperfetta in cui sei uno sviluppatore che lavora per una piccola impresa che non può permettersi di assumere sia uno sviluppatore che un amministratore dedicato. Devi utilizzare le tue risorse limitate in modo da ridurre al minimo i rischi per l'azienda e assicurarti che l'azienda sappia quali sono questi rischi e comprenda le probabilità e le conseguenze: devono essere in una posizione informata e sapere di aver preso la decisione su base informata. Spero per il meglio, ma assicurati di aver pianificato per il peggio. Avere backup affidabili e testati. Sapere cosa farà un aggiornamento prima di applicare l'aggiornamento. Monitora gli elenchi di sicurezza per essere a conoscenza di minacce nuove ed emergenti ed essere in grado di valutare qual è la tua esposizione e rivedere i registri per confermare le tue ipotesi. Controlla gli aggiornamenti ogni giorno. È del tutto legittimo decidere di non applicare gli aggiornamenti quotidianamente, ma solo dopo aver valutato cosa sono e cosa patchano ed essere in grado di prendere la decisione su base informata.

In relazione al punto precedente, nessuna ingegneria sociale e l'app web stessa è sicura.

Credere di sapere e conoscere può essere un mondo a parte. Ho perso il conto del numero di volte in cui una valutazione della sicurezza ha rivelato vulnerabilità di cui non ero a conoscenza. È molto probabile che ci siano vulnerabilità in PHP (o in qualsiasi altro strato coinvolto) che non sono stati ancora scoperti o, peggio, sono stati scoperti dalle persone sbagliate e non sono ancora diventati ampiamente conosciuti. Quando i professionisti della sicurezza valutano una domanda, non la dichiareranno mai sicura. Diranno che non sono state rilevate vulnerabilità, ma questo non significa che non esistono.

#7
  0
Thomas Carlisle
2017-02-21 00:11:56 UTC
view on stackexchange narkive permalink

Questa è sicuramente una buona pratica e dovrebbe far parte della routine di sicurezza del tuo server. È difficile dire se il tuo piano di sicurezza abbia bisogno di più di questa pratica, ma non ho mai visto né riesco a pensare a nessun buon piano di sicurezza che non abbia questo come base.

La mancata applicazione di patch al software e ai servizi installati rappresenta un rischio elevato per la sicurezza perché i bug e le vulnerabilità scoperti in quei pacchetti spesso possono portare a un accesso completo alla scatola sfruttando. Questa è una delle prime azioni, se non la prima, che un attaccante tenterà.

Ma anche le configurazioni errate del sistema sono uno dei principali modi in cui gli aggressori compromettono i sistemi. Applicare la patch al software da solo non correggerà necessariamente le configurazioni errate. A volte ciò accade, ma sarebbe perché l'errore di configurazione è nato dall'installazione originale dell'app.

Una cosa da considerare è se uno dei tuoi servizi viene eseguito come root. Non ci sono molti casi in cui questa sia una buona idea, ma succede che un servizio sia in esecuzione come root perché la persona che lo ha installato non ne sapeva niente di meglio, o non poteva farlo funzionare come non- utente root. Questo è solo un esempio.

Qualunque sia il sistema operativo in uso, ci saranno le migliori pratiche là fuori su come rafforzare il sistema operativo. Inizia da lì, quindi rinforza in modo specifico tutti i servizi / pacchetti installati, come MySql, apache, ecc.

Se durante la distribuzione il sistema operativo e tutti i servizi sono stati eseguiti specificatamente secondo le migliori pratiche, dopo di che potrebbero essere applicate le patch l'unica cosa che devi fare.

Dico potrebbe perché ancora non è una certezza. Dipenderà dai processi di modifica e dal fatto che i processi coprano il mantenimento di una protezione adeguata. Le modifiche proposte sono esaminate per motivi di sicurezza? I checkout includono test specifici per la sicurezza? La risposta a queste domande di solito è no e quindi gli errori di un amministratore possono verificarsi e non essere scoperti.

#8
  0
Klaws
2017-02-21 23:01:22 UTC
view on stackexchange narkive permalink

Fondamentalmente, non puoi mantenere sicuro un server web. Esistono exploit 0-day, che potrebbero essere risolti entro poche ore dalla scoperta, ma sono già stati sfruttati a quel punto. Una buona società di hosting potrebbe essere in grado di agire in modo molto tempestivo contro tali minacce. Tuttavia, un server gestito è costoso (supponendo che il personale di gestione dell'hoster valga qualcosa). Potrebbero tuttavia decidere di mettere il server offline nel caso in cui decidano che ciò è necessario per eliminare una minaccia attuale, dando priorità alla sicurezza , non alla disponibilità - che potrebbe essere sbagliata tipo di sicurezza se hai bisogno della scatola e reattiva in ogni momento. Quanti soldi e quante vite perdete in ogni ora di interruzione?

La fuga di dati potrebbe verificarsi anche altrove. I backup sono archiviati in modo sicuro? (protetto contro l'accesso fisico e remoto; in un caso, sono stato in grado di dimostrare l'esfiltrazione di dati non dal sito Web live, ma dai backup) Con quale facilità qualcuno può entrare nella sala server? Non è necessario che un super criminale come Lex Luthor ti attacchi direttamente (dopotutto, è solo dopo le 40 torte), ma puoi essere un danno collaterale. E sì, ho visto server farm segrete (caso 1: ha aperto accidentalmente la porta sbagliata, che a quanto pare qualche idiota si era dimenticato di chiudere a chiave e qualche altro idiota aveva deciso di avere una maniglia della porta all'esterno, caso 2: volevo scoprirlo perché c'era così tanto calore fottuto proveniente da dietro il truciolato, in qualche magazzino condiviso dove si poteva spaziare al metro quadrato). In teoria, gestito da società professionali, in pratica ... beh. Si potrebbe cogliere l'opportunità, sollevare alcuni server o unità, venderli su eBay e poi buona fortuna.

Spesso vengono trascurati anche gli attacchi remoti contro l'infrastruttura. A rigor di termini, questo non ha nulla a che fare con il livello di sicurezza del server, ma se qualcuno attacca l'infrastruttura di gestione o il proxy che serve i pacchetti software per gli aggiornamenti di apt-get, la sicurezza viene comunque in qualche modo ... degradata. Sì, alcune persone fanno queste cose per divertimento.

Presumo che AWS EC2 sia ragionevolmente sicuro rispetto a tali scenari, ma AWS EC2 viene fornito solo come esempio, non come un dato di fatto negli OP domanda (a differenza dell'affermazione che l'applicazione web stessa è sicura - questo probabilmente ci impedisce di discutere tutte le nostre storie di guerra sull'iniezione SQL e così via).



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...