È sicuro che un server di produzione sia installato?

42

Durante l'installazione delle istanze del mio server virtuale ho bisogno di compilare alcune applicazioni usando make. Ci sono dei rischi per la sicurezza associati makeall'installazione? O dovrei ripulirlo prima che l'istanza venga distribuita?

Ho anche il gcccompilatore sul server che utilizzo per creare applicazioni prima della distribuzione.

security make gcc

— SK'
fonte

4

Se ti fa sentire meglio, qualsiasi pezzo di software installato ovunque crea una vulnerabilità.

— MDMoore313,

1

E uno con accesso shell non root a un server potrebbe scaricare un pacchetto compilatore "distro indipendente" (.tar.gz) che non dovrà essere installato quindi ...

1

Sono io, o è la combinazione di "è sicuro?" e "accesso root" piuttosto scomodo ?

— DNA,

2

Se hai già installato gcc, non c'è praticamente alcun modo che possa peggiorare qualsiasi potenziale problema di sicurezza.

— Shadur,

1

@Shadur Che differenza fa avere GCC? Se l'utente ha già accesso alla macchina, può caricare banalmente qualsiasi copia di gcc. Comunque, gcc può essere utile per utenti non privilegiati e non un rischio per la sicurezza, a condizione che nessun utente privilegiato lo esegua.

— Valità,

50

Alcune persone sostengono che la presenza di strumenti di sviluppo su una macchina di produzione renderà la vita più facile per un aggressore. Questo tuttavia è un ostacolo così piccolo per un aggressore, che qualsiasi altro argomento che puoi trovare a favore o contro l'installazione degli strumenti di sviluppo avrà un peso maggiore.

Se un utente malintenzionato è riuscito a penetrare nel sistema finora, da poter invocare qualsiasi strumento presente sul server, allora hai già una grave violazione della sicurezza. Senza strumenti di sviluppo ci sono molti altri modi per scrivere dati binari in un file e quindi eseguire un chmod su quel file. Un utente malintenzionato che desidera utilizzare un eseguibile di build personalizzato sul sistema a questo punto potrebbe anche crearlo sul proprio computer e trasferirlo sul server.

Ci sono altre cose molto più rilevanti da cercare. Se un software installato contiene un bug di sicurezza, ci sono alcuni modi in cui potrebbe essere esposto a un utente malintenzionato:

Il pacchetto potrebbe contenere un eseguibile suid o sgid.
Il pacchetto potrebbe essere l'avvio di servizi sul sistema.
Il pacchetto potrebbe installare script che vengono richiamati automaticamente in determinate circostanze (questo include processi cron, ma gli script potrebbero essere richiamati da altri eventi, ad esempio quando cambia lo stato di un'interfaccia di rete o quando un utente accede).
Il pacchetto potrebbe installare inode dispositivo.

Non mi aspetto che gli strumenti di sviluppo corrispondano a uno dei precedenti, e come tali non è un pacchetto ad alto rischio.

Se disponi di flussi di lavoro in cui faresti uso degli strumenti di sviluppo, devi prima decidere se si tratta di flussi di lavoro ragionevoli e, se lo sono, devi installare gli strumenti di sviluppo.

Se scopri che non hai davvero bisogno di quegli strumenti sul server, dovresti evitare di installarli per diversi motivi:

Risparmia spazio su disco, sia sul server che sui backup.
Un software meno installato semplifica il monitoraggio delle dipendenze.
Se non è necessario il pacchetto, non ha senso assumersi il rischio per la sicurezza aggiuntivo di averlo installato, anche se tale rischio per la sicurezza è minimo.

Se lo decidi per motivi di sicurezza, non consentirai agli utenti privi di privilegi di inserire i propri eseguibili sul server, quindi ciò che dovresti evitare non sono gli strumenti di sviluppo ma piuttosto le directory scrivibili a quegli utenti su file system montati con autorizzazioni di esecuzione. Potrebbero essere ancora utili gli strumenti di sviluppo anche in tali circostanze, ma non è molto probabile.

— kasperd
fonte

6

Aggiungo a questo che un certo numero di sistemi di produzione si basa su codice interpretato (ad esempio PHP, Perl, Python, ...). Vietare gli strumenti di sviluppo in questo contesto non avrebbe senso. Considererei i compilatori come gccnon presentare un rischio più elevato di questi. Come dici tu, un utente malintenzionato in grado di utilizzare i compilatori installati su un sistema sarebbe generalmente in grado di fare comunque cose peggiori, come caricare il proprio eseguibile (possibilmente collegato staticamente).

— Bruno,

3

Rilevante: una versione minuscola di wget (51 byte?) . Un esempio di vita reale di un utente malintenzionato che sposta un file binario sul server utilizzando le echoistruzioni successive in un file. L'intero processo è automatizzato con uno script trovato nello stesso link.

— Adi,

2

@Adnan, interessante. Per quanto ne so, il principale difetto di sicurezza in questo esempio di DVR è il fatto che l'aggressore può telnet su di esso come root con la password 123456 in primo luogo. Avere o non avere wget o altri strumenti (prima dell'attacco) è quindi poco rilevante.

— Bruno,

15

makeè una shell che ha una sintassi diversa da bash.

Un compilatore come gccè un potente awkconfigurato con una serie di sostituzioni che lo standard awknon supporta. È un prodotto non conforme a POSIX sorto catche inietta immondizia nell'output. È un editor di testo interattivo (pensa vi) che è configurato per eseguire alcune modifiche all'avvio, quindi esce prima di visualizzare l'interfaccia utente.

Non c'è nulla di intrinsecamente insicuro in loro, non rendono la tua macchina più insicura di quella in cui hai il catreindirizzamento della shell bash + +.

— ignis
fonte

2

Una risposta così zen che non so come valutarla.

— Kasperd,

4

@kasperd Questa risposta vuole essere seria. Ho pensato che portare il punto di vista di un programmatore potesse essere utile. Una funzione che traduce un input in un output non introduce una vulnerabilità solo perché il suo output è in un formato comprensibile dalla CPU.

— ignis,

1

Sono d'accordo con il punto che stai sollevando. Penso che la tua risposta sia un'ottima lettura per chiunque sia già d'accordo. Sono solo preoccupato che la tua risposta possa apparire come uno scherzo a qualcuno che non è d'accordo.

— Kasperd,

Mi piace questa risposta molto più di quella accettata :)

— Ruslan,

15

makedi per sé va bene. makeè semplicemente un framework di tracciamento e automazione delle dipendenze. Tuttavia, in genere viene utilizzato insieme ai compilatori e quelli preferibilmente non dovrebbero essere disponibili su un sistema di produzione, poiché sono completamente non necessari. Lo stesso vale per tutti i pacchetti non necessari, siano essi librerie condivise, interpreti, ecc. Il software installato sui sistemi di produzione deve essere rigorosamente controllato e dovrebbero essere presenti solo i pacchetti richiesti dall'applicazione.

Dovresti creare la tua applicazione su un server di compilazione, impacchettarla e quindi distribuire il pacchetto binario sui tuoi sistemi di produzione.

Nota: gli strumenti di imballaggio nativi fanno schifo . Non preoccuparti nemmeno di cercare di farli brontolare. Invece, controlla Jordan Sissel's fpm. Rende l'imballaggio una gioia assoluta.

— EEAA
fonte

8

Sto chiedendo per curiosità e ignoranza qui: perché dici che la presenza di compilatori è un "problema di sicurezza significativo?" Qual è il problema di sicurezza con l'installazione di un compilatore? È solo una questione di te non dovresti costruire il tuo codice su un server di produzione in primo luogo e quindi il compilatore è superfluo o c'è davvero un problema di sicurezza significativo con la presenza del compilatore stesso?

— reirab del

11

Sebbene sia una buona idea costruire le tue applicazioni su un server separato, dire che la presenza di compilatori su un sistema di produzione è un problema di sicurezza significativo non ha senso. Che dire dei linguaggi di scripting e dei sistemi compilati JIT (Perl, Python, Java, ...)?

— Bruno,

3

La presenza di compilatori in un ambiente di produzione non costituisce un "rischio di sicurezza significativo". Io stesso ho spostato i file binari in scatole compromesse usando echoe base64. In effetti, puoi persino farlo con una serie di echoaffermazioni e nessun altro strumento .

— Adi,

1

Buoni punti, tutto. Ho modificato la mia risposta per chiarire.

— EEAA

9

Al contrario, il potenziale problema non è con l'avere makesul server di produzione, il potenziale problema è con la costruzione delle applicazioni sul server di produzione invece di distribuire immagini pre-costruite testate. Potrebbero esserci validi motivi per questa metodologia, ma è una contro la quale vorrei contestare faticosamente se mi chiedessero di adottarla.

— John
fonte

4

Stai chiedendo se makedebba essere installato su un server di produzione, ma la mia vera domanda sarebbe: chi ha accesso a quel server di produzione e quali garanzie hai in atto per affrontare un'incursione? Se makenon è stato installato ma qualcuno ha rootaccesso, indovina? Possono installare manualmente makee tutto ciò che vogliono.

La dura realtà della sicurezza informatica è tanto quanto si desidera impedire l'accesso indesiderato, essere ossessionati dal blocco dell'accesso non è importante quanto:

Chi ha accesso al server?
Cosa si può fare per ripristinare le conseguenze di una pausa?

Tutto dipende dal tipo di lavoro che fai. Lavoro principalmente nel mondo dei web server e il mio atteggiamento è fondamentalmente, chiunque ottenga da me l'accesso al server di produzione deve dimostrare abilità, conoscenza e maturità. Questo è tutto. A volte ci vogliono alcuni giorni. A volte ci vogliono mesi. Ma fondamentalmente, la tua migliore linea di sicurezza sui server di produzione sta controllando l'accesso oltre alle varie altre cose che facciamo per rafforzare i server.

— JakeGould
fonte

1

makedi per sé è innocuo. Tutto ciò che fa è eseguire le applicazioni in un ordine prestabilito, a seconda delle dipendenze specificate e dei file già esistenti nel sistema. Può anche essere utile come parte del processo di installazione: puoi usarlo per mettere i file predefiniti dove devono andare, o eseguire unit test o altre cose.

Tuttavia, devi considerare per cosa vuoi usarlo esattamente . Viene spesso utilizzato insieme a compilatori e altri strumenti per la creazione di applicazioni e questi potrebbero essere utilizzati per annullare alcune delle tue linee di difesa. Ma makenon è possibile eseguire queste operazioni se gli strumenti non sono disponibili.

— The Spooniest
fonte