If you setup LUCY within your own infrastructure you don't want users from the internet to access the phishing simulation directly within your intranet. If the server gets compromised, the attacker would have an entry point to the internal network:
A secure design requires that the web service which is accessible from the internet (untrusted network) can be segregated from the internal network (trusted network) and moved to a DMZ. If you do so, please keep in mind that LUCY has different communication channels that depend on the specific use:
LUCY's master/slave configuration enables the administrator to create such segregation by associating a "slave" role to a LUCY instance.
Please note: There is a caveat with HTTPS - if you generate SSL on master, you have to put it to proxy by hands, as the proxy doesn't automatically interact with master in any way and doesn't exchange information with it.
The Master/Slave can be configured admin/settings/proxy. If you run LUCY as an external proxy within the DMZ (facing the internet) then you need to choose "the instance type "proxy" and define LUCY's master system domain name:
Please contact our support for further help on this topic (firstname.lastname@example.org).
Both master-slave approaches (reverse proxy and DMZ-based) use only HTTPS port (443). A "recipient" is an end user. For a proxy, the firewall configuration would be:
For "reflective scheme", the firewall should be configured as follows:
Updates: both workstations are updated separately and should have access to Lucy Update/License Server.
The following is applicable for both type of Web Proxy configuration (Master \ Proxy configuration and Reflection Master \ Reflection Slave configuration):
There are known issues. Please contact support in case if you have any questions.