Prendendo in prestito le altre risposte e amp; commenti perchè sono d'accordo con loro:
Deflect = Not-the-same-as reflect back to the attacker.
La pratica comune che viene in mente in questo contesto è questa:
Your assets can be protected using deflection to a honeypot.
...the armor is between the targets body and the bullet and the bullet
has to go through the armor.
Non riesco a pensare a molte situazioni in cui un honeypot si trova tra l'attaccante e le risorse sotto protezione. Di solito è il ruolo di un firewall (firewall di rete o firewall di un'applicazione Web di qualche tipo).
Honeypot in pratica - in che modo proteggono con distrazione.
Può essere un honeypot a bassa interazione (il caso più comune perché è più facile da configurare e mantenere) che viene posizionato in modo tale da distogliere l'attenzione dell'attaccante dall'apparente facilità di hacking e impostazione della protezione per principali attività.
Ad es., per proteggere x.yourasset.com, puoi impostare x-be.yourasset.com e x-private.yourasset.com come honeypot a cui normalmente non dovrebbe connettersi un cliente legit. Quando qualcuno si connette a loro, si utilizza una forma di automazione basata su script che impedisce loro di raggiungere * .yourasset.com. Qui il ban-trigger si collega semplicemente all'honeypot. Non è necessaria alcuna interazione profonda.
Un honeypot dell'interazione intermedia (ancora abbastanza comune) consentirebbe a un utente malintenzionato di connettersi e fornire loro un percorso a ciclo infinito, ad esempio, consentire a SSH di connettersi con un account e una password inesistenti; quindi presenta un file system fittizio con traiettorie senza fine. Questo spreca tempo di attacco e potrebbe o meno aiutare direttamente la sicurezza delle risorse, a meno che non lo usi anche con qualche forma di divieto.
In both the above cases, the honeypot is not "placed in front of" the asset.
Un'altra possibilità è usare honeypot ad alta interazione (non comune). Ciò richiede un certo sforzo per l'installazione e la gestione. Qui, permetti all'utente di interagire con la risorsa principale, ma se vedi qualcosa di insolito, passa la sessione a Honeypot.
per esempio. Il tuo modulo web potrebbe avere campi segreti nascosti legittimi (ad es. Spl-discount, secret-auth) che il flusso normale non sarebbe mai popolato. Sul tuo server controlli prima quei campi e se sono popolati invii un reindirizzamento a un honeypot. Puoi farlo anche utilizzando qualcosa come il progetto AppSensor OWASP .
- sembra un normale invio riuscito - "grazie ... elaborazione ..."
- che impiega diversi secondi per ogni aggiornamento dello schermo e spreca più tempo - "grazie per la tua pazienza ..."
- che potrebbe continuare a chiedere maggiori informazioni - "abbiamo solo bisogno di ulteriori informazioni prima di completare l'elaborazione" "ti abbiamo inviato un codice di sicurezza aggiuntivo al tuo indirizzo email ... per favore inseriscilo per verificare il tuo account per maggiore sicurezza" ( ovviamente potresti non aver inviato alcun codice)
- e alla fine si spegne con qualcosa del tipo "ci dispiace, riprova più tardi".
Questo può o non può essere combinato con il bando ma aiuta in molti modi, inclusa la raccolta di dati sull'attaccante e le TTP (Strumenti, Tecniche e Procedure) - che saranno utili in altre misure difensive.