Vai al contenuto principale

​
È possibile bloccare o autorizzare indirizzi IP specifici, o limitare l’accesso a una pagina?

Sì, per singolo sito, dalla scheda Protezione della pagina di stato del dominio. Le modifiche le fa un Owner o un Security Officer; gli altri ruoli le vedono.
  • IP bloccati: rifiuta un indirizzo o una rete, per un giorno, una settimana, un mese o fino alla rimozione. Un pulsante Blocca è presente anche nelle tabelle Attaccanti, Richieste bloccate e Rilevamenti, e Sblocca toglie un blocco.
  • Whitelist: indirizzi che passano sempre, come quelli del tuo ufficio, così Cloud Defender non li rifiuta mai per errore.
  • Pagine riservate: apri una pagina di login o di amministrazione (per esempio /wp-admin/ e /wp-login.php su WordPress) solo agli indirizzi e ai paesi che indichi.
  • Regola paesi: rifiuta i paesi che il tuo sito non serve, oppure accetta solo quelli che serve.
Cloud Defender applica una modifica entro circa due minuti. Una nuova pagina riservata e una regola paesi partono in prova, senza rifiutare nessuno, finché non le applichi.

​
Perché nei miei IP bloccati c’è un indirizzo che nessuno ha bloccato?

È un blocco automatico, indicato come Blocco automatico. Una sorgente che continua a inviare attacchi noti al tuo sito viene bloccata su di esso per 24 ore, e il blocco si toglie da solo. Gli indirizzi dei servizi di Google non vengono mai bloccati in questo modo.

​
Da quali indirizzi deve accettare traffico la mia origine?

Per evitare un bypass del WAF, configura l’origine in modo che accetti traffico web solo dal Cloud Defender. Aegister ti comunica gli indirizzi da autorizzare al momento dell’attivazione del dominio: vedi il passaggio 4 della guida all’attivazione.

​
È possibile effettuare un downgrade da HTTPS a HTTP tra il WAF e il sito protetto?

Sì, puoi effettuare un downgrade della sessione da HTTPS a HTTP tra il WAF e il sito protetto, anche se questa scelta riduce la sicurezza e ne sconsigliamo l’uso.

​
Quali vantaggi offre il Cloud Defender rispetto ad altre soluzioni come AWS Cloudfront + WAF?

Il Cloud Defender offre mascheramento degli IP, protezione DDoS, caching, blocco dell’origine, blocco degli URL di attacco e controlli con l’OWASP Core Rule Set. Si distingue perché blocca automaticamente il traffico proveniente da fonti malevole grazie alla Threat Intelligence di Aegister, alimentata da OneFirewall. Se un attaccante viene identificato durante un attacco su un altro obiettivo, Cloud Defender blocca quella stessa sorgente anche sul tuo sito. È inoltre un servizio gestito: Aegister gestisce e mantiene le regole per te.

​
Perché il totale bloccato non torna con l’elenco delle sorgenti di attacco?

Le richieste bloccate prima che Cloud Defender iniziasse ad acquisire l’indirizzo del client portano l’indirizzo della nostra CDN e non quello del mittente. Rientrano nel totale, perché sono state davvero bloccate, ma non possono essere attribuite a una sorgente: per questo non compaiono nella tabella degli attaccanti e sono riportate a parte nella frase sotto il totale.

​
Il mio dominio risulta “Non attivo” ma il sito funziona. Perché?

Un dominio risulta Non attivo se la licenza non è valida o se i controlli di salute non passano. Decide prima la licenza: se è scaduta il dominio è Non attivo anche se il proxy risponde ancora, perché non siamo più incaricati di proteggerlo.

​
Chi riceve il report settimanale e gli avvisi?

Le notifiche nella console, il report settimanale e gli avvisi via email non sono ancora disponibili per i clienti. Quando partiranno, le notifiche saranno visibili a chiunque possa aprire l’organizzazione. Le email arriveranno solo alle persone selezionate per Cloud Defender in Organizzazioni → la tua organizzazione → Membri. Nulla viene inviato in base al ruolo, e un’organizzazione senza nessuno selezionato non riceve alcuna email. Un Owner può modificarlo. Le comunicazioni su licenze e rinnovi sono separate: vanno agli Owner e al punto di contatto amministrativo.

​
Cloud Defender blocca SQL injection e cross-site scripting?

Sì, quando attivi il blocco per il sito. Ogni richiesta viene confrontata con l’OWASP Core Rule Set, che copre SQL injection, cross-site scripting e altri schemi di attacco. Per impostazione predefinita questi controlli rilevano e non bloccano: le richieste corrispondenti vengono registrate come anomalie ed elencate nella scheda Rilevamenti della pagina di stato, dove segni una sorgente come Legittimo quando le sue richieste sono previste, oppure la blocchi con Blocca. Per bloccarle, un Owner o un Security Officer apre la scheda Protezione e porta SQL injection e XSS da In rilevamento a Blocco attivo. La conferma mostra quante richieste del periodo selezionato corrispondevano e sarebbero state rifiutate. Entro circa cinque minuti le richieste corrispondenti vengono rifiutate e compaiono in Richieste bloccate come Regola di firma. Tornare a In rilevamento lo annulla negli stessi tempi. Serve una licenza attiva.
Una firma può corrispondere anche a una richiesta di cui il tuo sito ha bisogno, e bloccarla può interrompere una parte del tuo servizio. Prima di attivarlo guarda Rilevamenti: ciò che elenca come non bloccato è ciò che il blocco rifiuterebbe. Dopo averlo attivato, prova le funzioni principali del sito (accesso, moduli, caricamenti, eventuali API) e controlla Richieste bloccate nei giorni successivi. Se una richiesta legittima viene rifiutata, torna a In rilevamento.
Gli altri livelli bloccano su ogni sito: il blocco dell’origine, la Threat Intelligence, la regola sugli URL di attacco, che valuta solo l’indirizzo e gli header di una richiesta, e le tue liste.