Project

General

Profile

Actions

Bug #15739

closed

User manager /Radius Auth/Local DB used after Access-Reject

Added by Eric Nguyen 3 months ago. Updated 3 months ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
Authentication
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.7.x
Affected Architecture:

Description

The user manager is set to use RADIUS for Authentication. There is UserA local with password 123 and UserA in Radius with password Password

When I try to log on from the GUI with UserA and password 123, a packet capture shows an Access-Reject from Radius which is correct, however PF proceeds with using the local DB and the user can login.

This is not the correct behaviour access to the GUI should not be granted. The Documentation states:

If the RADIUS or LDAP server is unreachable , the authentication will fall back to Local Database even if another method is chosen.

In our case the Radius server is reachable and a wrong password was supplied, therefore access should be denied regardless of the password's correctness in the local DB.

Eric

Actions #1

Updated by Jim Pingle 3 months ago

  • Status changed from New to Not a Bug

That is by design to prevent a non-functional auth server from locking an admin out of the firewall locally.

Actions #2

Updated by Eric Nguyen 3 months ago

Hello Jim,

You have have misread the ticket the Radius server is is fully functional....
What happens is you login with a wrong password and that password happens to be the same as on the local DB, you get in despite getting and access reject from Radius, this is terribly wrong. Let's say you disable the account in Radius, but forget to do it in the local DB, that user still has access.

The documentation is good, fallback to the local DB when the Radius server cannot be contacted, but in my case the Radius server issued an ACCESS-REJECT, and therefore the login process should NEVER proceed any further and fall back to the local DB.

Eric

Actions #3

Updated by Jim Pingle 3 months ago

No, I read it correctly. That is the expected behavior. You cannot reliably determine the difference between a broken authentication server and an authentication failure.

The server being down/unreachable is only one mode of failure. It may be rejecting valid attempts because it's broken in other, less obvious ways.

Actions #4

Updated by Eric Nguyen 3 months ago

So I will take it with netgate security. Please can you delete this ticket?

Thanks,

Eric

Actions #5

Updated by Jim Pingle 3 months ago

It's not a security issue, it is intended behavior.

Actions #6

Updated by Eric Nguyen 3 months ago

Intented is:

"If the RADIUS or LDAP server is unreachable , the authentication will fall back to Local Database even if another method is chosen."

Not if the authentication attempt is rejected by the Radius or LDAP server, the Local Database will be used as a fallback regardless.

Actions #7

Updated by Jim Pingle 3 months ago

Then the docs can be amended to reflect the actual, intended behavior.

Actions #8

Updated by Eric Nguyen 3 months ago

Hi again Jim,

Unfortunately,what is described in this behaviour is in security terms called an horizontal privilege escalation, hence why I am writing up my tests results and will take it on with Netgate Security team. There are others way to perform what you want to achieve.

1) if you use an external system for authentication, it has to be redundant. By they a second authentication server would be a very nice to have in the user manager.

2) if the ultimate goal is to allow the admin/root account to log in locally (if auth servers are down) then it should not be able to login from a remote auth server. Other ways is a superroot user with access to user manager only (password create ld during initial install) or better a private key giving access.

Eric

Actions

Also available in: Atom PDF