MFA Proxy — access protection for web applications
MFA Proxy sits in front of a web application and lets a user through only after checking a one-time code from an authenticator app. The application itself does not need to be changed: to the application, the proxy looks like an ordinary visitor, and for the employee the service address stays the same.
It fits administration panels, vCenter, mail, CRM, cameras, internal portals, and any web system that has no two-factor protection of its own.
What it covers
A company often has services that are already published to the network or available from the office, but that only support a username and password. Adding a second factor to them is impossible: it is someone else’s product, an old version, or a system that cannot be modified.
MFA Proxy takes that task on.
- One entry point for several sites. Each service has its own name, its own destination address, and its own list of people who are allowed in.
- An employee is granted access to the systems they need, rather than to the whole network. People can be gathered into groups, and a group can be assigned to a service in one action.
- An administrator sees who is inside now, from which address the session was opened, and can close it immediately.
- Site certificates are issued here as well: your own certificate, a Let’s Encrypt certificate, or a certificate signed by the proxy’s shared root certificate.
How it stops an attacker
Passwords leak. They are shoulder-surfed, guessed, taken from an old database, or copied from an employee’s computer. If only a password stands in front of the application, that is enough to get in.
With MFA Proxy, a stolen password is not enough. A one-time code is also required. It lasts about thirty seconds and exists only on the employee’s phone. The code can be required together with a password, or on its own if the application already has a password.
Access is then narrowed further.
- A session is tied to the address from which the person signed in. A stolen cookie from another address does not open the system: the proxy asks for the code again. The real employee’s session is left in place.
- Several wrong attempts in a row block sign-in for a set time. Guessing the password and the code stops, instead of continuing all night.
- An address allow list admits only your own networks. A deny list cuts off known sources immediately, even with a valid code.
- The journal records sign-ins, rejections, and administrator actions. It shows who tried to sign in and to which service.
- One-time code secrets are stored encrypted in the database.
- The proxy management panel is on a separate port and, by default, listens only on the server itself. It is not published next to the protected sites.
The proxy does not replace antivirus software or a firewall. It closes a different path: signing in to a web application with a password alone.
What the employee sees
The employee opens the service’s usual address. The proxy shows a sign-in page. The person enters the code from Authenticator and, if required, a password, and reaches the familiar system. They can sign out through a separate sign-out link. While the session is alive, the code does not need to be entered again. The session lifetime is set for each service.
What the administrator gets
A web console: users, groups, sites, sessions, the journal, and lockout settings. The service is installed as a single file on Ubuntu, Debian, AlmaLinux, or CentOS. Data lives in a local database, and a separate database server is not required. Settings go into an environment file, and the state can be saved and restored from a backup.
Запросить КП