JIRA has brute force password look up protection for its Web UI with Captchas.
But what is there for its REST API? Is there any protection of any kind analogous to the Catpchas?
Hello Jiri,
CAPTCHA is not going to be useful because REST is supposed to connect services without manual input required.
External software/hardware for a secure service. Why ? The reason is simple, you want to protect your service from too much unnecessary workload, and when the checks are done by your service you are not protecting it, you're just making it worse. So DDoS attacks should be stopped before they reach your service, because when they do they eat up resources.
A common technique used with iptables is to limit the request rate from a single source to a few times per minute, but this is not an obvious solution if many users are coming in from the same IP address such as a forward proxy or other NAT-routed location.
iptables is too crude.
I am using JIRA via Apache reverse proxy.
I was thinking of mod_qos (mod_security is slowing the entire the entire server) or something along those lines.
Even better an Atlassian apache module which would take care of blocking the IP addresses which fail to log in - we do not care about the number of requests after the user logs in either in REST or the UI.
I have seen some Python code doing this by parsing logs but doubt that's the most elegant solution.
Is there any way to to configure mod_qos or something similar to do the IP address blocking / DoS prevention just on the login screen?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Fail2ban is what we recommend in our docs:
Don't know mod_qos, and as a sysadmin I would avoid parsing logs for the obvious reasons.
However mod_security should work well if configured correctly. There are examples given for IP-based blocking and username-based blocking will only deny requests on specific URL after multiple failed attempts. Search for "Brute-Force Authentication Protection with ModSecurity", it yields a very useful page at the top. We don't have any in-house solutions that I am aware of.
There's also a mod_security implementation with nginx that is discussed on their blog, but it's mostly about logging configuration. The nginx cookbook has some good info on mod_sec and rate-limiting. Hope this helps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm not a fail2ban fan, I know it is recommended as a do-it-yourself project, but I would much prefer to have external management of endpoint security than by relying on log parsing / dynamic policy updating. Enterprise security solutions are usually implemented on a dedicated firewall.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.