Sicurezza e architettura

• Il sensore gira sul vostro hosting, dallo schedulatore, fuori dalla cartella pubblica. Non ha regole proprie. Raccoglie impronte e le invia.
• Il server centrale custodisce le regole, confronta ogni rapporto con l'ultimo stato pulito e decide. L'elenco dei file da sorvegliare è stabilito qui, non dal sensore.
• Le copie pulite dei vostri file critici sono conservate sulla nostra infrastruttura, non sul vostro hosting. Chi entra nel vostro account di hosting non può sostituirle.

• Gira con il vostro stesso utente di hosting. Non ha bisogno di accesso root e non installa nulla sul server.
• Legge i file di codice e, dal database, solo i record degli amministratori, le impostazioni di pagamento e poche impostazioni della piattaforma, come l'indirizzo del sito e l'elenco delle estensioni.
• Scrive in un solo caso: quando il server centrale ordina il ripristino di un file di pagamento.
• Non cancella mai un file. Prima di sostituirne uno, conserva la versione sostituita in una cartella privata.

• Vengono inviati: le impronte dei file, il contenuto dei file di codice critici che sono cambiati, i nomi utente degli amministratori e le impronte (non i valori) di e-mail e password degli amministratori e delle impostazioni di pagamento.
• Non vengono mai inviati: ordini, clienti, numeri di carta, né alcuna pagina vista dai vostri visitatori.
• Ogni messaggio è firmato in entrambe le direzioni e porta un'indicazione oraria e un numero monouso, così non può essere alterato né ripetuto.

La decisione è presa da regole fisse, non da un'IA. Così gli stessi fatti danno sempre la stessa decisione e ciascuna può essere spiegata. Devono valere tutte le condizioni seguenti:

• il file è un file di pagamento o di checkout,
• la modifica aggiunge una destinazione di pagamento che non riconosciamo,
• non è in corso un aggiornamento della piattaforma o di quell'estensione,
• esiste una copia pulita verificata.

Ogni altra modifica viene segnalata e attende la vostra approvazione. Non viene annullata.

Prima di scrivere, il sensore controlla che il file su disco sia ancora esattamente quello analizzato, che non sia un collegamento verso un altro punto e che si trovi dentro il vostro sito. La scrittura avviene in un solo passaggio, così non può restare un file scritto a metà. Poi il sensore conferma il risultato al server centrale.

La versione modificata viene conservata come prova. Se la modifica era vostra, la rimettete al suo posto dal pannello con un pulsante. Ogni ripristino automatico è accompagnato da un registro della decisione: la regola, il file, la destinazione, se era in corso un aggiornamento e le impronte prima e dopo.

Test controllati su negozi di prova, versione 1.12:

• Tempo dalla manomissione al ripristino, con un controllo ogni minuto. Abbiamo cambiato l'indirizzo di pagamento in un file di pagamento 8 volte, in momenti casuali all'interno del minuto. Tutte le 8 volte la modifica è stata trovata e il file pulito rimesso al suo posto al controllo immediatamente successivo: tra 8 e 57 secondi dopo la manomissione, 33 in media. Una volta partito il controllo, rilevamento e ripristino richiedono meno di un secondo, quindi l'attesa dipende dall'intervallo del vostro piano.
• 100 modifiche controllate di sei tipi, su negozi di prova OpenCart e WooCommerce. Tutte le 100 sono state trovate e il file pulito è stato rimesso al suo posto. Nella stessa serie abbiamo fatto 100 normali modifiche da sviluppatore: nessuna è stata annullata e nessuna ha fatto scattare un allarme.
• Il file cambia di nuovo tra l'analisi e il ripristino. Il ripristino non è stato applicato, la versione più recente è rimasta al suo posto ed è stata controllata al passaggio successivo.
• Il file viene sostituito da un collegamento (symlink) prima del ripristino. Il sensore si è rifiutato di scrivere ed è stato inviato un avviso critico.
• Lo stesso messaggio viene inviato due volte, o alterato lungo il percorso. Il secondo è stato respinto come ripetizione, quello alterato per firma non valida.
• Il server centrale non è disponibile. Il sensore non ha cambiato nulla sul sito. Quando il server è tornato, la modifica fatta nel frattempo è stata trovata e il file ripristinato. Finché il server non risponde, non avvengono controlli.
• Una password del pannello rubata. L'accesso era possibile, l'approvazione di una modifica no: serve il codice inviato all'e-mail del titolare. Sei codici tirati a caso sono falliti e il titolare è stato avvisato.
• Annullamento di un ripristino dal pannello. Con il codice ricevuto per e-mail, la modifica è stata rimessa al suo posto al controllo successivo.
• Viene modificato il file del sensore stesso, oppure il sensore segnala all'improvviso molti meno file. Avviso critico al controllo successivo.
• Sulla pagina pubblica compaiono uno script da un dominio simile a uno autentico e un modulo che invia dati altrove. Il controllo esterno ha fatto scattare un avviso critico.
• Sono nostri test controllati su negozi di prova, sulla stessa macchina del server centrale. Non sono una verifica indipendente, e un'installazione reale aggiunge il ritardo di rete.

• Rapporti e approvazioni sono disponibili solo dopo l'accesso. Non esistono link di rapporto aperti.
• Le password sono conservate in forma di hash. Dopo cinque tentativi errati l'account si blocca per quindici minuti.
• Per approvare una modifica o annullare un ripristino serve anche un codice inviato in quel momento alla vostra e-mail. Una password del pannello rubata non basta.
• Ogni approvazione e ogni annullamento viene registrato con l'utente e l'indirizzo da cui proviene, e inviato per e-mail al titolare e al nostro team.

Ogni sei ore il nostro server apre anche le vostre pagine pubbliche come farebbe un visitatore e confronta i domini esterni che caricano con la volta precedente. Un nuovo script da un dominio simile a uno autentico o da un servizio aperto di hosting del codice, o un modulo che inizia a inviare dati altrove, fa scattare un avviso. Questo controllo non dipende dal sensore.

• Lo storico degli eventi è conservato per 90 giorni.
• Le copie pulite sono conservate finché l'abbonamento è attivo e vengono eliminate alla sua scadenza.

• HachiGuard non sostituisce un firewall, un antivirus o una scansione PCI. È il livello che nota e annulla una modifica dopo che qualcuno è entrato.
• Uno script che il vostro checkout carica dal server di un terzo può essere modificato su quel server senza che cambi alcun vostro file. Notiamo un nuovo dominio esterno, ma non una modifica dentro uno script che c'era già.
• Se l'intero account di hosting viene preso, un sensore che gira al suo interno non può più essere considerato del tutto affidabile. Per questo le copie pulite, le regole e le decisioni stanno fuori, e per questo un sensore che tace o è stato alterato fa scattare l'allarme.
• I file codificati non possono essere letti. Li seguiamo tramite l'impronta e segnaliamo ogni modifica, ma non li ripristiniamo automaticamente.
• Il primo controllo considera pulito lo stato attuale. Verificate amministratori e indirizzi di pagamento prima che venga eseguito.
• Il rilevamento avviene con l'intervallo del vostro piano. Una modifica fatta subito dopo un controllo viene vista al successivo.