Come rintracciare le violazioni dei criteri MAC sulla richiesta HTTP?

Question

Come rintracciare le violazioni dei criteri MAC sulla richiesta HTTP?

#1 da (2 voti)

0

Supponiamo che ci sia un'applicazione web sotto carico pubblico che gira sotto un criterio MAC molto restrittivo (ad esempio, SELinux, TOMOYO, Grsecurity). Supponiamo di rilevare e registrare una violazione dei criteri MAC come un file letto o scritto dall'applicazione web che non dovrebbe essere.

Questa violazione dei criteri MAC può essere rintracciata in una richiesta HTTP che l'ha provocata? Come?

L'applicazione Web è sotto carico di oltre 100 richieste / s. Tutte le richieste sono legittime, tranne una, che è dannosa. La richiesta dannosa deve essere trovata in modo che possa essere analizzata per determinare come ha passato il filtro di sicurezza all'interno dell'applicazione.

webserver web-application appsec selinux

posta Matrix 14.10.2013 - 10:13

fonte

1 risposta

Leggi altre domande sui tag webserver web-application appsec selinux

DSA ha bisogno di padding? E 'possibile scansionare un host remoto in un'altra rete se conosco una porta che viene aperta?

score 2 · Accepted Answer

In termini molto generali, il tuo problema è mantenere le informazioni sul contesto. SE ipotizziamo quanto segue:

Ogni richiesta viene gestita da un codice nel server, con uno dei thread di esecuzione .
Ogni thread elabora una richiesta alla volta.
Il codice server registra ogni richiesta in entrata con un timestamp di alta precisione (millisecondi o inferiore) e l'identificatore per il thread di gestione.
Il motore della politica MAC, quando rileva una violazione, lo registra insieme a un marcatore temporale ad alta precisione e informazioni sul contesto, in particolare l'identificatore per il thread offendente.

Quindi diventa facile mappare le violazioni sulle richieste.

In pratica, a seconda della tecnologia coinvolta (codice del server, progettazione dell'applicazione, motore della politica ...), alcune delle informazioni di cui sopra potrebbero mancare. Ad esempio, il motore della politica può registrare solo l'ID processo e un processo può contenere diversi thread (ci sono "thread di sistema" gestiti dal sistema operativo, ma a livello di applicazione lì possono anche essere i cosiddetti "thread leggeri" di cui il sistema operativo non è a conoscenza). Alcuni motori di server possono eseguire più richieste contemporaneamente (progettazione della macchina di stato con poll() ). I log possono mancare di precisione al secondo. Nel server, gli accessi I / O possono essere centralizzati e condivisi, quindi il thread che ha ricevuto la richiesta non è necessariamente quello che accede al file.

Se non disponi di tutte le informazioni necessarie, dovrai analizzare tutte le richieste ricevute nel relativo intervallo di tempo, fino a trovare quello più funky. Potresti voler ricorrere alla simulazione : mantenere tutte le richieste in entrata in un buffer circolare, in modo che in qualsiasi momento tu abbia una copia del valore dell'ultimo minuto dei dati della richiesta o così; se il motore della politica rileva una violazione, crea uno snapshot (una copia delle richieste e lo stato del server pertinente). Successivamente, durante l'analisi, invia nuovamente tutte queste richieste a una copia del server, una alla volta, finché non trovi quella che attiva il problema.