nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

how to prevent malicious use of jira login to cause account lockout in delegated directory?

Axel Joester1

Hello all,

we'd like to open up our jira instance to some external users (2 for starters). Our current users are authenticated via JIRA Delegated Authentication Directory, while those external users ( and a few jira-admins) are defined in JIRA Internal Directory.

The JIRA Delegated Authentication Directory connects to our central active directory, which holds all our users.

Now our security guru wants to stop us. He reckons "there are billions of people out there, that could enter some of our internal user names, use a wrong password three time and with this LOCK OUT our unsuspecting active directory users. I cannot allow this."

He's right, unsuccessful login-attempts DO in fact disable user-accounts in AD. Malicious use is possible.

Is there any way to prevent this?

(changing our current AD account lockout policy being not an option)

Cheers

Axel Joester

Accepted answers

Axel Joester1

Thanks for all the suggestions!

I think we go for BIG-IP-Programming.

Building two "iRules" for the published jira-url.

First iRule "Detection":

Scan each Jira-Response for unsuccessful logins. On detection, define Variable "lockout_until" in BIG-IP-Session, containing current time + 5 Minutes.

Second IRule "Shielding":

For each http-request headed for jira, check, if variable "lockout_until" is set, and if so, check, if current time is smaller than its value. If yes, redirect request so some static page "You have been blocked". Otherwise, let http-request proceed to jira.

Net effect: No external user can do more than one attempt during 5 minutes to lock an account . Windows sets back its failure count in its defined "Lockout Observation Window", which is less thean 5 minutes. No windows-account can ever be locked, as three unsuccessful attempts in a row would be needed for that.

Still not sure how to do the details, but BIG-IPs rule-language features seem sufficient.

All comments

Radu Dumitriu

Your security guy could restrict for the start the IP's from where the external users are allowed to connect. Or use any other security measures to work around this. For me, it sounds like : I'm not in the mood to do it, let's raise some reason for it and motivate my laziness.

Axel Joester1

thanks for answering!

We thought about restricting external access to the public jira-url by IP (we use f5 BIG-IP, which supports this). Unfortunately, those external users don't have fixed ip-addresses.

For me, it sounds like : I'm not in the mood to do it, let's raise some reason for it and motivate my laziness.

Well, our security guy's job is to pinpoint problems, not to solve them. That would be our server staffs job, who, while certainly not overeager, honestly see no solution.

David Yu

Maybe install fail2ban and have the password failure limit shorter than ADs? I suspect fail2ban can detect repeated requests from the same IP. You will probably need to work out a mechanism to unlock the banned IPs. Just one caveat, fail2ban detection may not be immediate since it scans access log files.

JamieA

Personally I don't think this is work avoidance and is actually a serious and real problem, particularly if you are exposing jira to the outside world, and use AD as a directory for internal users. It's not too hard to get a list of possible user names that have the AD account, eg the source of the contact admins page has it.

I saw this a lot at one place although it wasn't malicious. The AD logs just point you back to the jira server, then the jira logs just pointed us to one of the reverse proxies. Tracking down the times and the IP of the requests causing the lockout was hard, and as I say this was just accidental. (IIRC the user had put his credentials into an IDE integration, changed his password, and then was continually locked out).

Radu Dumitriu

How about VPNs? If this is such a big concern, VPNs with private keys for external users should fix it. There may be more solutions to this problem, even if there are no fixed IPs. In my world, security guys should come with solutions to security problems.

Radu Dumitriu

OpenVPN should help

Axel Joester1

Yes, we considered VPN and turned it down. We'd like a solution that is completely transparent to the (benevolent) external user. We would not want to require him to configure a VPN-connection. Besides, the VPN-product we are using constrains the client to use only that network connection. That means, he looses connection to his own network, while using VPN (no split tunneling option)

Axel Joester1

good idea! Considered. We use windows servers, Fail2ban needs linux. But the idea to have an internal limit just below the AD-limit is convincing. Jira actually has such a configurable limit, but reaching it doesn't block, jira only starts to display a captcha. Won't stop malicious use...

JamieA

What you somehow need is to enforce is that users that are not from within your company only authenticate against jira's internal directory, not your AD directory. Perhaps this can be done with a custom authenticator where you have the HttpRequest object so you can check the source IP.

You said that your customers don't have fixed IPs, but presumably you have a range of IPs that your company users, so anyone not in that range is external. Or, make sure external users go through a reverse proxy and you can check for that. Might be worth a look if you have the java skillz.

Axel Joester1

Thanks for all the suggestions!

I think we go for BIG-IP-Programming.

Building two "iRules" for the published jira-url.

First iRule "Detection":

Scan each Jira-Response for unsuccessful logins. On detection, define Variable "lockout_until" in BIG-IP-Session, containing current time + 5 Minutes.

Second IRule "Shielding":

Still not sure how to do the details, but BIG-IPs rule-language features seem sufficient.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

crowd

authentication

ldap