Sto usando un'istanza di Amazon Linux EC2 come server web. La mia app Web utilizza ImageMagick. Poiché il repository Amazon Linux (CentOS) non include una versione aggiornata di ImageMagick, lo sto compilando dal sorgente. Per farlo corro:
yum groupinstall 'Development Tools'
L'installazione di strumenti di sviluppo su un servizio di produzione comporta un rischio per la sicurezza? In tal caso, come faccio a rimuovere in modo sicuro ciò che non avrei dovuto installare?
La regola generale per i sistemi è: se non ne hai bisogno, non installarlo. Forse dovremmo modificarlo per: se non ne hai più bisogno, disinstallalo.
Perché? Ridurre la "superficie di attacco" disponibile sul sistema, ovvero programmi e utilità che possono essere compromessi o utilizzati come parte di un compromesso. Questa è la giustificazione generale.
Il rischio specifico per gli strumenti di sviluppo è che se un utente malintenzionato ottiene l'accesso a un utente non privilegiato, è probabile che possano usare say gcc per compilare un codice arbitrario sulla tua casella. Detto questo, è anche possibile che tu stia eseguendo un interprete come Python o che abbia javac in giro per le applicazioni Web o alcune di esse, quindi l'impatto materiale effettivo potrebbe non essere molto diverso.
Personalmente non vedo nulla di sbagliato nell'installare gli strumenti di sviluppo (li inserirò manualmente con yum install <tool> in modo che possano essere poi yum remove 'd successivo) e quindi rimuoverli dopo che il loro scopo è stato soddisfatto. Dopotutto, tutto questo discorso sulla compilazione di codice abrary in utenti non privilegiati manca davvero il punto: in quel momento qualcuno ha già preso piede sul tuo sistema e che è ciò che vuoi impedire.
Per quanto riguarda le politiche, non avere strumenti di sviluppo su un server web è nella mia mente una buona idea - scoraggia gli sviluppatori dal "farlo live". Non che vorremmo, bada, ma bene ... probabilmente lo faremmo:)
Oltre alla risposta corretta di @ Karrax, per quanto riguarda l'aumento della superficie di attacco, i possibili exploit e l'ambiente di attacco più semplice per un potenziale hacker, volevo segnalare un altro problema che dovrebbe essere ovvio, ma è spesso dolorosamente no.
Questi sono strumenti sviluppo . Su un server produzione .
Ne deduco che non solo gli sviluppatori hanno accesso al server di produzione, ma a quanto pare intendono svilupparlo .
Questo di per sé ha un sacco di rischi associati ad esso, vale a dire:
.bak , che consente a qualsiasi utente di scaricare e rubare password ecc. Il mio punto è che il problema non è solo installare gli strumenti di sviluppo, ma il problema maggiore è il processo e l'ambiente che lo circonda e che in un primo momento causerebbe un tale piano.
Sì , qualsiasi aggiunta al software che installi sul tuo ambiente aumenterà la superficie di attacco che un utente malintenzionato potrebbe utilizzare per compromettere te e i tuoi sistemi.
Gli strumenti in questo pacchetto possono contenere exploit noti o altri exploit non ancora scoperti che possono ulteriormente compromettere il tuo sistema.
In generale, direi che è la migliore pratica per mantenere lo sviluppo e la produzione come separati il più possibile, tuttavia ogni azienda può avere il proprio rischio / conseguenze e analisi dei costi forse nel tuo caso specifico potrebbe essere un rischio accettabile.
Nota che nel tuo caso stai installando gli "strumenti di sviluppo"! Questo può rappresentare un ulteriore rischio per la sicurezza dato che stai essenzialmente lasciando un ottimo compilatore (e altri strumenti) progettato per questo specifico sistema, sul tuo sistema. In molti casi questo rende semplicemente più semplice per l'hacker compilare ed eseguire più codice di exploit una volta che sei stato compromesso, tuttavia in alcuni casi speciali (dove forse hai bisogno di un compilatore speciale) renderà troppo facile per l'attacker una volta sei stato compromesso
EDIT: mentre Gilles commenta, l'ultimo esempio è altamente improbabile nel tuo caso specifico. Vorrei citare Gilles perché è esattamente ciò che intendevo portare nel mio esempio:
on a system where the attacker has limited bandwidth or can only inject printable characters, or on an exotic system for which obtaining a compiler or building one's own is expensive. But here we're talking about a system with a fast network connection and that the attacker can reproduce for a few dollars