Privilegi dell'utente per codice non personalizzato

whether or not sandboxing and lowering privileges is a good idea

SEMPRE !!! Ogni volta, ovunque (l'inglese è strano), isola i tuoi processi. In un mondo ideale, potremmo escludere SELinux da ogni applicazione, utente, file, ecc.

Un controllo di accesso obbligatorio correttamente stabilito fornisce sia protezione contro gli exploit che rilevamento di compromessi quando si vedono i pattern nei log di controllo che non dovrebbero essere lì, che ovviamente si stanno sempre rivisti per correggere le regole errate o notare qualcosa di indesiderato è successo.

WAF, MAC, firewall, ecc. sono armature per il tuo server web. Ti rendono più pesante e più lento, e l'armatura pettorale non ti impedisce di essere colpito al braccio, ma migliora le tue probabilità di sopravvivenza.

AppArmor è un'interfaccia più semplice per i moduli di sicurezza Linux e un sostituto decente per il corralling di applicazioni specifiche considerate ad alto rischio se SELinux sta sciogliendo il cervello.

whether or not protecting the additions to a site before protecting the site overall is a good idea

Sì di nuovo! Più compartimenti puoi fare le cose, meglio è. Se un modulo ha solo bisogno di accedere alla tabella dei post, forniscigli un contesto in cui non può accedere alla tabella delle credenziali, ecc. È molto più difficile perdere l'accesso che non hai rispetto all'accesso che hai.

Di sicuro ci sono buone informazioni in alcune delle altre risposte. Aggiungo che puoi sconfiggere quasi tutte le iniezioni di codice di basso livello con un semplice trucco: usa un processore non x86. Il malware o il carico utile scritto per x86 semplicemente non funziona su un processore non x86. Linux e alcuni BSD sono stati portati su molte architetture di processori. Se si utilizza uno stack Web portatile, è sufficiente compilarlo per tali architetture e distribuire un'applicazione Web su di esso. Configura le cose correttamente e ora ti preoccupi solo degli attacchi a livello di applicazione.

Alcuni lo accuseranno di essere sicurezza per oscurità. Non vero. Questo è offuscamento e ha dimostrato valore. Funziona a patto che non sia largamente adottato al punto che gli hacker mettono un sacco di impegno nella tattica. Ha funzionato per me e molti altri, compresi gli enormi mercati NUMA / mainframe, per quasi dieci anni. Sta dicendo qualcosa. La maggior parte degli attaccanti usa kit premade. E quasi tutte le persone che fanno i kit scrivono x86 desktop / server o ARM mobile. Semplicemente non c'è una forza lavoro considerevole disponibile per sfruttare facilmente i tuoi contenuti in esecuzione su POWER, Alpha, MIPS, SPARC, ecc. Quindi, è una sorta di economia + offuscamento che funziona a tuo vantaggio.

Ricorda, tuttavia, di combinare questo trucco con buone pratiche di sicurezza nell'area di scelta del software, configurazione, permessi, monitoraggio, ecc. L'offuscamento da solo non è sufficiente per prevenire tutti i problemi. Solo un mucchio di loro. ;)

Nota: cercherò anche di evitare l'uso di piattaforme facili da aggirare o inserire codice. PHP ha una brutta storia con quel genere di cose. I runtime statici, di tipo sicuro e gestito sono solitamente i più facili da proteggere dal codice problematico. Hai solo meno preoccupazioni con loro e abbiamo trucchi come SFI e Native Client per gestire il codice nativo su quelle piattaforme se uno è così inclinato.