You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I agree to follow the Code of Conduct that this project adheres to.
I have searched the issue tracker for an issue that matches the one I want to file, without success.
Problem Description
I am using Dex OIDC/LDAP with Apache, as part of OpenOnDemand installation. A portal like OpenOnDemand lets users to connect and run jobs and servers on (that is, arbitrary user code "inside") an HPC system, with obvious security implications. So it is customary to ban failed login attempts with tools like fail2ban, denyhosts and the like.
Looks like when using Dex, there is no clear place to match a failed attempt with the source IP, because users connect to Dex directly, after Apache had forwarded the call? So, Dex would report the failure in its log, but w/o IP information, and Apache would have the IP but wont report a failure at all.
Proposed Solution
Dex should have IP addresses at hand, because users connect to it directly. So the authentication routine should log not only username and the fact of the failure, but also IP. So fail2ban filter can be pointed to the log file and make existing, well known fail2ban to ban the offending IPs.
Alternatives Considered
There is an open issue for the same problem: #1869 , which proposes I think taking on fail2ban functionality inside Dex. Very quiet ticket, there.
It probably would be less effort to just log things and let fail2ban take care of the firewalls, rather than add extra functionality to deal with things.
Additional Information
No response
The text was updated successfully, but these errors were encountered:
Preflight Checklist
Problem Description
I am using Dex OIDC/LDAP with Apache, as part of OpenOnDemand installation. A portal like OpenOnDemand lets users to connect and run jobs and servers on (that is, arbitrary user code "inside") an HPC system, with obvious security implications. So it is customary to ban failed login attempts with tools like fail2ban, denyhosts and the like.
Looks like when using Dex, there is no clear place to match a failed attempt with the source IP, because users connect to Dex directly, after Apache had forwarded the call? So, Dex would report the failure in its log, but w/o IP information, and Apache would have the IP but wont report a failure at all.
Proposed Solution
Dex should have IP addresses at hand, because users connect to it directly. So the authentication routine should log not only username and the fact of the failure, but also IP. So fail2ban filter can be pointed to the log file and make existing, well known fail2ban to ban the offending IPs.
Alternatives Considered
There is an open issue for the same problem: #1869 , which proposes I think taking on fail2ban functionality inside Dex. Very quiet ticket, there.
It probably would be less effort to just log things and let fail2ban take care of the firewalls, rather than add extra functionality to deal with things.
Additional Information
No response
The text was updated successfully, but these errors were encountered: