Come indurire i compilatori (come suggerito da Lynis)?

La sicurezza è sempre un equilibrio tra facilità d'uso e protezione. Il sistema più sicuro che io possa immaginare è un computer spento che giace in una cassastrong della banca. Sfortunatamente è anche difficile da usare ... Rimuovere i compilatori o peggio restringendoli a root su un sistema di test o di sviluppo sarebbe assurdo: o non si può più usarlo, o si accederà sempre come root. Le cose vanno diversamente su un server di sola produzione in cui possono essere normalmente rimosse.

Ma non riesco a immaginare come rimuovere un compilatore possa proteggere un server Ubuntu. Come per tutti i sistemi di tipo Debian, i pacchetti sono generalmente installati in formato binario, il che significa che se un utente malintenzionato ha accesso in scrittura a una cartella, può depositare un programma creato sulla propria macchina e usarlo lì. E se non ha accesso in scrittura, non sarà neanche in grado di creare un file eseguibile.

Questo consiglio, come molti altri sulla sicurezza di offuscamento , assomiglia a olio di serpente . Ciò non dovrebbe causare molti danni, ma non sarà davvero sicuro di nulla ... Ma è qualcosa che è facile da implementare in strumenti di controllo automatico e può essere venduto

Se vuoi davvero proteggere un server di produzione, non concentrarti sui compilatori, ma rimuovi con cura tutti gli strumenti di rete (e generici) che non vengono utilizzati lì e configura i firewall per bloccare il numero di in entrata e in uscita connessioni possibili: se un server è stato compromesso, sarà davvero più difficile per l'attaccante rimbalzare su un altro. Ma questo non può essere fatto da uno strumento automatico perché deve essere adattato all'ambiente reale e al caso d'uso preciso del server. Una volta fatto, è possibile che i compilatori siano già andati via, ma sinceramente non mi interessa. Se vuoi fare un ulteriore passo avanti, crea anche un kernel personalizzato contenente solo i driver usati nel tuo ambiente - ok, non puoi costruire un kernel se hai rimosso i compilatori, ma dovrebbe essere costruito e testato su il sistema dev o pre-prod. In questo modo gli script kiddies che tentano di utilizzare gli soliti indirizzi del kernel non saranno in grado di trovarli.

TL / DR: il mio consiglio è che non si sa quale compilatore può essere rimosso in modo sicuro o come si potrebbe limitare a root, non provare nemmeno a farlo . Segui semplicemente le best practice comuni:

• non utilizzare mai l'account di root per tutto ciò che non lo richiede
• solo sudo singoli comandi o per un breve periodo
• non lasciare mai un server in esecuzione come root (eccetto il tempo di inizializzazione ...) e assicurarsi che lasci tutti i privilegi non necessari prima di accettare le richieste
• proteggi il tuo firewall il meglio che puoi e proibisci tutti gli accessi non necessari
• non installare software non necessario o non controllato

E non fidarti degli strumenti di controllo automatico per più di quello che possono fare. Un serio controllo di sicurezza costa davvero tempo e denaro ...

Da una prospettiva hacker / pentester, posso dire che avere un compilatore su una macchina target e / o python / ruby può essere molto molto utile. Quindi sono d'accordo con una delle risposte precedenti che la rimozione da un server di produzione aumenta la sicurezza. Tuttavia, quegli strumenti sono utili solo per gli attaccanti che hanno già una shell limitata sul tuo sistema. In tal caso, puoi rendere più difficile la loro vita non fornendo loro ulteriori strumenti utili di cui hanno bisogno per l'escalation dei privilegi. Ma questo non è un enorme vantaggio in termini di sicurezza. Si vorrebbe impedire loro di ottenere una shell in primo luogo e che non ha nulla a che fare con un compilatore o uno strumento di interpretazione. D'altra parte, la rimozione di gcc e python / ruby su un server di produzione non è probabilmente un grosso problema, quindi perché non farlo. Come detto in precedenza, non vedo perché un server di produzione abbia bisogno di un compilatore. Se ha bisogno di python / ruby dipende dal software eseguito su quella casella. Se nessun software dipende da python / ruby, puoi disinstallarlo senza problemi. Consentire a gcc solo per root contribuirebbe anche a impedire a qualcuno di utilizzarlo per l'escalation dei privilegi. Ma vorrei chiedermi qual è il vantaggio rispetto alla rimozione, o in altre parole: quale utente root ha bisogno?

Dovresti essere in grado di rimuovere in sicurezza i compilatori C e C ++. Fare ciò è relativamente semplice e normalmente indolore. È probabile un guadagno relativamente piccolo in sicurezza, ma per un ambiente server di produzione è improbabile che abbia bisogno di un compilatore C o C ++. Probabilmente mi chiedo perché qualcuno debba compilare un codice di produzione su un server di produzione. I guadagni di sicurezza probabilmente non sono eccessivamente alti, ma i costi sono anche generalmente molto bassi.

Rimuovere interpreti come Python o Ruby è potenzialmente un po 'più costoso, dal momento che gli strumenti di amministrazione sono spesso scritti in questi linguaggi, il che può costarti un po' di utilità e flessibilità. Il tuo caso d'uso particolare dovrebbe essere preso in considerazione.

Tieni presente che la rimozione di diversi compilatori e interpreti presenta uno spettro di utilità rispetto alla sicurezza. La rimozione dell'interprete bash, ad esempio, renderebbe il sistema difficile o impossibile da gestire poiché gli script di bash sono utilizzati ovunque per avviare / interrompere i servizi e mantenere il software.

La sicurezza è l'arte di fare le cose giuste, anche se di per sé non sempre sembrano avere un grande impatto. La più grande ragione per rimuovere o limitare l'uso dei compilatori sui sistemi di produzione è già data da kaidentity. L'articolo su escalation dei privilegi (nel link indicato), dà qualche idea su come funziona e su come puoi difendere rimuovendo il compilatore o limitandone l'utilizzo.