Ridurre il rischio dalla registrazione

1

Sto seguendo la metodologia del rischio OWASP e ho la minaccia "Implementazione del software installato". Ho creato questo rischio in base all'idea che si possa trovare un rischio nel phpMyAdmin che può essere sfruttato.

La mia domanda è: come si riduce praticamente il rischio nella sezione Fattori di vulnerabilità > Rilevamento delle intrusioni?

Il mio server esegue Ubuntu e ha UFW abilitato e porte severamente limitate. Tuttavia, se qualcuno dovesse trovare un'opportunità di caricamento per esempio e sfruttarlo e hackerare il server, sicuramente anche un IDS non lo impedirebbe l'esecuzione e / o registrerebbe l'effetto.

Apprezzo che ci siano più vulnerabilità possibili, ma mi chiedevo solo se esistessero soluzioni generiche?

    
posta Antony 17.02.2017 - 10:08
fonte

1 risposta

2

Come per molte cose, assicurarti di rilevare un exploit di successo richiede una difesa approfondita e un po 'di preparazione.

Partiremo dal presupposto che un utente malintenzionato in qualche modo interrompa il "software di destinazione" e lo possiede o l'account che esegue in esecuzione di codice arbitrario fornito dall'attore. Il nostro obiettivo è essere in grado di rilevare che ciò si è verificato.

Innanzitutto, dal punto di vista della prevenzione, è necessario assicurarsi che qualunque software di destinazione venga eseguito con un account separato con privilegi minimi. Ciò implica che anche un attacco riuscito non avrà accesso al resto del sistema. Dovrai anche assicurarti che il sistema ottenga aggiornamenti regolari della sicurezza, ecc. Questo riduce il rischio che l'aggressore possa elevare i privilegi dall'account che ha fatto l'accesso a root o qualcos'altro di interessante. Infine, avere solo il software minimo necessario, idealmente solo per un singolo scopo. (Non importare web / app / database nella stessa casella.)

Ora una volta che hai finito, puoi iniziare a cercare di rilevare l'exploit. Per questo, si dovrebbe iniziare con la registrazione degli eventi del sistema operativo. Sono iniziati o fermati alcuni processi insoliti. Presumibilmente, ci sarà un modello di utilizzo "normale" e se l'autore dell'attacco esegue il proprio codice, potrebbe essere in un processo separato. Un IPS / IDS dovrebbe fornire molte informazioni su questo - molto meglio trovarne uno buono e configurarlo piuttosto che provare a farlo da solo. Qualsiasi IPS / IDS degno di questo nome dovrebbe inviare i dati dell'evento a un host separato (come suggerisce @ user400344).

Sul lato del firewall del sistema operativo, la maggior parte del software server non avvia connessioni TCP ad endpoint casuali, quindi è possibile configurare il firewall in modo da consentire solo il traffico in uscita verso destinazioni note. Ciò renderebbe anche un po 'più difficile per un utente malintenzionato estrarre dati. A monte del server, puoi monitorare il traffico TCP per assicurarti che corrisponda a quello che ti aspetti.

Tenere un registro di tutti i processi avviati. Esistono vari programmi che possono aiutarti a farlo. (Tira anche via l'host.)

Successivamente, a livello di applicazione, dovrai scrivere su syslog o su un altro servizio che viene eseguito separatamente dal software di destinazione. Durante l'exploit, l'utente malintenzionato potrebbe scrivere su syslog, ma non modificarlo.

Se il software di destinazione pianifica i lavori, accetta i comandi, ecc., quindi verifica che non vengano modificati, eccetto che attraverso un flusso di lavoro previsto.

Potresti eseguire un IPS / IDS anche a livello di applicazione (firewall di app web, se il software di destinazione è un server web), nel qual caso dovrebbe fornire una difesa aggiuntiva.

    
risposta data 20.02.2017 - 06:07
fonte