RELIANOID Firewall dell'applicazione Web #

Migliori Firewall per applicazioni Web (WAF) funziona come uno strumento cruciale per identificare e prevenire il traffico HTTP dannoso all'interno delle farm HTTP(S). Analizzando i modelli, applica policy di sicurezza avanzate su insiemi organizzati di regole, che vengono poi applicate alle farm HTTP. Dopo aver decrittografato i pacchetti SSL, le regole WAF vengono esaminate attentamente, consentendo l'applicazione di modelli al corpo HTTP all'interno del traffico SSL.

Migliori RELIANOID IPDS il pacchetto incorpora il Set di regole principali OWASP ModSecurity, precaricato e pronto per l'uso, mentre gli utenti mantengono la flessibilità di creare set di regole personalizzate per una protezione completa del sistema contro diversi attacchi. Per esplorare ulteriori dettagli sulle regole OWASP, gli utenti possono fare riferimento al progetto OWASP Modsecurity. Inoltre, vale la pena notare che il RELIANOID Il modulo WAF estende le sue funzionalità oltre la protezione HTTP per comprendere manipolazione avanzata dei contenuti HTTP, di cui redirect and riscritture.

Visualizzazione dei set di regole WAF #

La visualizzazione dei set di regole WAF mostra una panoramica dei set di regole disponibili e dei servizi della farm assegnati:

Nome. Un nome descrittivo per identificare un set di regole. Fare clic su di esso per accedere al modulo di modifica.
Farms. Le Fattorie a cui si applica la norma. È possibile espandere l'elenco delle aziende utilizzando una freccia rivolta verso l'alto posizionata accanto a FARMS intestazione di colonna alla sua destra. Per impostazione predefinita è limitato a 20 caratteri.
STATUS. Lo stato del set di regole è rappresentato dai seguenti codici colore di stato:

• Verde. Significa ABILITATO. È in corso il controllo del set di regole per le farm che lo utilizzano.
• Rosso. Significa DISABILI. Il set di regole non è abilitato, quindi non ha alcun effetto sulla farm.

Azione. Azioni consentite per lo stato delle regole WAF:

• Modifica. Modifica le impostazioni del set di regole o assegna un servizio farm, se necessario.
• Restart. Reinizializzare una regola WAF.
• Inizio. Applicare il set di regole WAF.
• Elimina. Rimuovi un set di regole.

Comprensione del sistema di regole OWASP CRS #

Migliori OWASP CRS i set di regole comprendono regole generiche di rilevamento degli attacchi, offrendo un livello fondamentale di protezione per qualsiasi applicazione web.

Modalità di funzionamento #

Le regole precaricate OWASP CRS funzionano in due modalità:

Modalità punteggio anomalia (impostazione predefinita): questa modalità è consigliata per le informazioni di registro precise e le politiche di blocco flessibili. Conosciuta anche come "modalità di rilevamento collaborativo", assegna un "punteggio di anomalia" a ciascuna regola corrispondente. Al termine delle valutazioni delle regole in entrata e in uscita, il punteggio di anomalia attiva azioni di blocco, che in genere generano un errore 403 predefinito.

Modalità autonoma: questa modalità applica le azioni istantaneamente. Riducendo l'utilizzo delle risorse, sacrifica la flessibilità nelle policy di blocco e nei registri di controllo dettagliati (viene registrata solo la prima minaccia rilevata). Le regole seguono l'azione di disturbo specificata (ad esempio, nega, elimina). La prima regola di corrispondenza esegue questa azione, spesso portando alla cessazione della valutazione dopo la corrispondenza iniziale, in modo simile a molti IDS.

Set di regole CRS OWASP di base #

Queste regole di protezione precaricate sono organizzate in base alle preferenze. Se decidi di utilizzarli, ti preghiamo di considerarli e applicarli nel modo seguente:

RICHIESTA-90-CONFIGURAZIONE RICHIESTA-901-INIZIALIZZAZIONE
# Applica qualsiasi altro set di regole OWASP in base a ciò che desideri proteggere
RICHIESTA-949-RISPOSTA-VALUTAZIONE-BLOCCANTE-959-RISPOSTA-VALUTAZIONE-BLOCCANTE-980-CORRELAZIONE # per scopi di registrazione, abilitalo solo per la risoluzione dei problemi.

All'interno del set di regole principali OWASP, il RICHIESTA-901 inizializzazione ruleset funge da elemento fondamentale, offrendo una vasta gamma di opzioni per configurare il comportamento generale delle regole di sicurezza. Fornisce agli utenti la flessibilità necessaria per ottimizzare le impostazioni per allinearle a specifiche esigenze di sicurezza, costituendo la spina dorsale del processo di configurazione delle regole. Trasferirsi a RICHIESTA-949-BLOCCO-VALUTAZIONE and RISPOSTA-959-BLOCCO-VALUTAZIONE set di regole, questi svolgono un ruolo fondamentale nella strategia di sicurezza proattiva valutando ed eseguendo azioni di blocco in base ai punteggi di anomalia. Contribuiscono in modo significativo alla capacità dell'OWASP Core Rule Set di identificare e prevenire potenziali minacce in tempo reale. A complemento di questi, RISPOSTA-980-CORRELAZIONE il set di regole si concentra sulla correlazione e sull'analisi delle risposte, migliorando la capacità complessiva del set di regole principali OWASP di rilevare e rispondere in modo efficace alle sfide di sicurezza in evoluzione. Insieme, questi set di regole consentono agli utenti di implementare un quadro di sicurezza robusto e adattabile per le loro applicazioni web.

Comprensione dei livelli di paranoia, campionamento e punteggio di anomalia #

L'impostazione Livello paranoia ti consente di specificare l'intensità dei controlli delle regole, influenzando i punteggi di anomalia. Livelli di paranoia più elevati migliorano la sicurezza abilitando più regole ma possono aumentare il rischio di bloccare il traffico legittimo a causa di falsi positivi. Raccomandazioni per ogni livello:

Paranoia livello 1 (impostazione predefinita): adatto a principianti, installazioni diverse e configurazioni di sicurezza standard, con rari falsi positivi.
Paranoia livello 2: Consigliato per utenti da moderati a esperti che cercano una copertura completa e una maggiore sicurezza. Aspettatevi alcuni falsi positivi.
Paranoia livello 3: Rivolto a utenti esperti nella gestione dei falsi positivi, per installazioni con elevate esigenze di sicurezza.
Paranoia livello 4: Consigliato per utenti esperti che proteggono installazioni con requisiti di sicurezza molto elevati, ma che potrebbero produrre un numero elevato di falsi positivi che richiedono una risoluzione prima della messa in funzione.

Per aumentare il bloccando il livello di paranoia, vai al RICHIESTA-901 inizializzazione Regole, quindi Modifica in modalità raw e modificare l'ID della regola 901120. Sostituire setvar:'tx.blocking_paranoia_level=1′ con il tuo livello preferito.

Utilizzando il livello di paranoia di rilevamento, è possibile eseguire regole da un livello di paranoia più elevato senza tenerle in considerazione nel punteggio dell'anomalia. Questa flessibilità consente l’incorporazione di regole dal livello di paranoia 2 in un sistema finemente sintonizzato al livello di paranoia 1, mitigando le preoccupazioni su potenziali falsi positivi che potrebbero aumentare il punteggio oltre la soglia stabilita. Come configurazione predefinita, il livello di paranoia di rilevamento si allinea al livello di paranoia di blocco. Per aumentare il livello di paranoia di rilevamento, vai al RICHIESTA-901 inizializzazione Regole, quindi Modifica in modalità raw e modificare l'ID della regola 901125. Sostituire setvar:'tx.detection_paranoia_level=%{TX.blocking_paranoia_level}' con il tuo livello preferito (es. setvar:'tx.detection_paranoia_level=2′).

A ciascuna regola nel CRS viene assegnato un livello di gravità, con impostazione predefinita segnare punti indicando l'impatto sul punteggio di anomalia quando una regola corrisponde. I livelli di gravità e i relativi punteggi sono i seguenti:

CRITICA: Punteggio di anomalia pari a 5, principalmente derivante dalle regole di attacco delle applicazioni (file 93x e 94x).
ERRORE: Punteggio di anomalia pari a 4, generato prevalentemente da regole di leak in uscita (file 95x).
AVVERTIMENTO: Punteggio di anomalia pari a 3, attivato principalmente da regole client dannose (file 91x).
AVVISO: Punteggio di anomalia pari a 2, derivante principalmente dalle regole del protocollo (file 92x).

In modalità anomalia, questi punteggi si accumulano, consentendo a una singola richiesta di attivare più regole. Le modifiche a questi punti predefiniti generalmente non sono necessarie ma possono essere personalizzate in base a requisiti specifici.

Si può definire l' punteggio cumulativo di anomalia al quale un richiesta in entrata or risposta in uscita verrà bloccato. Per impostazione predefinita, la maggior parte delle minacce in entrata rilevate ricevono un punteggio critico pari a 5, mentre le violazioni più piccole portano punteggi inferiori. Alle soglie di blocco predefinite, il CRS si comporta in modo simile alle versioni precedenti, bloccando e registrando le richieste con una singola corrispondenza di regola critica. La regolazione delle soglie di blocco su valori più alti, come 7 o 10, può rendere il CRS meno sensibile, richiedendo più corrispondenze di regole prima del blocco. Tuttavia, si consiglia cautela, poiché l’aumento delle soglie potrebbe consentire ad alcuni attacchi di aggirare regole o politiche. In alternativa, una strategia di distribuzione consigliata prevede inizialmente l’impostazione di soglie elevate di punteggio di anomalia (>100) e il loro graduale abbassamento man mano che aumenta la fiducia nel sistema, offrendo un approccio proattivo per migliorare la sicurezza nel tempo.

Per impostazione predefinita, la soglia del punteggio di anomalia in entrata è impostata su 5 e la soglia del punteggio di anomalia in uscita è impostata su 4. Per modificare il Soglia del punteggio di anomalia in entrata, vai al RICHIESTA-901 inizializzazione Regole, quindi Modifica in modalità raw e modificare l'ID della regola 901100. Sostituire setvar:'tx.inbound_anomaly_score_threshold=5′ con il tuo livello preferito (es. setvar:'tx.inbound_anomaly_score_threshold=4′). Allo stesso modo per il Soglia del punteggio di anomalia in uscita con l'ID della regola 901110 sostituzione setvar:'tx.outbound_anomaly_score_threshold=4′.

Migliori Blocco della modalità di punteggio anomalia anticipata consente una valutazione anticipata dei punteggi di anomalia della richiesta e della risposta al termine rispettivamente della fase:1 e della fase:3, invece di attendere fino alla fine della fase:2 e della fase:4. L'abilitazione di questa modalità permette il blocco immediato nel caso in cui venga raggiunta la soglia di anomalia durante la valutazione anticipata, bypassando rispettivamente l'esecuzione della fase 2 (e della fase 4). Per attivare il blocco anticipato, abilita l'ID regola 901115 entro RICHIESTA-901 inizializzazione set di regole, che imposta la variabile tx.early_blocking a 1 (disabilitato per impostazione predefinita). È fondamentale notare che il blocco anticipato può nascondere potenziali avvisi, poiché i payload che attivano gli avvisi di fase 2 (o fase 4) non verranno valutati se viene attivato il blocco anticipato. Disabilitare il blocco anticipato in futuro potrebbe rivelare nuovi avvisi dalla fase 2.

Migliori Easing-in/percentuale di campionamento La funzionalità è progettata per mitigare potenziali problemi durante l'integrazione del CRS in un sito live esistente, come falsi positivi e impatti imprevisti sulle prestazioni. Per introdurre con cautela il CRS, è possibile abilitarlo inizialmente per un numero limitato di richieste. Una volta risolti tutti i problemi e stabilita la fiducia nella configurazione, è possibile aumentare gradualmente la percentuale di richieste soggette al set di regole. Regola la percentuale di richieste elaborate dalle Regole principali mediante l'impostazione tx.sampling_percentage all'ID regola 901130 entro RICHIESTA-901 inizializzazione insieme di regole; il valore predefinito è 100, il che significa che ogni richiesta viene sottoposta a controlli CRS. La selezione delle richieste controllate si basa su un numero pseudo-casuale generato da ModSecurity. Se una richiesta può passare senza il controllo CRS, non avrà una voce nel registro di controllo per motivi di prestazioni, ma verrà registrata una voce nel registro degli errori. Per disabilitare la voce del log degli errori, emettere la direttiva specificata dopo aver incluso il CRS.