New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow fail2ban protection #1550
Comments
From #1530 (for reference). |
Update: There are two places in the code that should trigger fail2ban:
|
Trying to figure how I can get the REMOTE_ADDR from within the log routine.
But also tbc… |
Both files are obsolete since v1.2. The correct way to get the IP address is |
OK, thanks for the information. Thus I should have all ingredients in hand to do the job. |
Sorry, I have to ask for advice again. I have to implement something in v1.1(.2), so I concluded that the |
Maybe your debug level is misconfigured ( |
You are probably right. I was looking in |
Yep. Indeed. We really have to set a better default. Edit: See #1829 |
I have a working solution for v1.1, working with |
Hm, I don't think it makes lots of sense to merge anything into v1.1 - that version is outdated and I doubt we'll release a v1.1.3 considering that we want people to update to v1.2... |
v1.1: I know, it is a philosophical question. But what is the alternative? Keeping forever a better version (which is in production) of v1.1 in my own git repository? Maybe it just feels bad for me, as I am not used to decentralised repos. But it feels indeed very bad to have the knowledge of the best solutions spread around the world and not one repo with the ideal, even if outdated, solution. |
Well at some point a version reaches its end of life. It's the same with other software. Anyway, I believe that is exactly the beauty with Git: You can have your own repo, with a branch based on v1.1.2 that contains your fix so you'll never lose it and if e.g. someone on the mailing list asks for the same thing+version you could point him to that commit. |
Yes, but it supposes that I will be around when someone is asking or searching loudly. And my repository will not live forever, whereas a central Indico repository is likely to live on until noone uses Indico any more, and even when git will be replaced by a NG code versioning system. |
I don't think it makes much sense to use fail2ban for this; locking people out on the firewall level is not very user-friendly and I don't know any popular web service that does this. Showing a "login attempts exceeded, wait x minutes" is nicer for sure. |
Sorry, but I think you should leave this to other admins. Some sites may have rules to use fail2ban or other mechanisms on all their hosted websites. It is their business to be unpopular or not.
That is fine. Should I understand that it is implemented in v2.0? Otherwise this ticket should remain open, as it is not solved. Actually it was not about fail2ban or not, it was about having a more standard and stable error message format available to do whatever the admin wants to do with it. |
I closed the issue because rate limiting would rather be a feature of the Flask-Multipass extension (also developed by us) than of Indico itself, hence the reference to the issue in that repo. But I guess logging the IP address on Indico's side in case of a failed authentication attempt would be useful too... |
Any timescale for this or indico/flask-multipass#2? |
Not sure about builtin rate limiting, but improved logging of user-caused login failures (ie only invalid user/credentials, not other errors outside the user's scope) will most likely be in the next 1.9.11 dev version. They'll be logged as a WARNING and include the IP address, which should be sufficient to run fail2ban on them. |
I guess something like this should be suitable for fail2ban logging:
|
Today (1:54am) Adrian wrote:
I guess something like this should be suitable for fail2ban logging:
2017-07-24 10:52:00,471 WARNING 74032185fe0d49f0 indico.multipass
Invalid credentials (ip=2001
I am not familiar with this format: `ip=2001
|
That's an IPv6 address, since this is the future and more and more people use IPv6. If you do not support IPv6 then your regex would probably work. The log message never contains a DNS host. If you use an IPv4 address the IP in the log message is using the normal IPv4 style:
I simply tried logging in to each provider with an invalid user and with a valid user but an invalid password. So there's exactly one log message for each invalid attempt. You can safely ignore anything after the ip address, so in the regex I would only look at the |
The expression May I suggest an improvement of the duplicate
Or replace the first
|
Only match on this part of the message (and the prefix): Also, your regex is too general and will most likely allow for people to ban arbitrary IPs since they just need to trigger a warning containing |
Today (9:45am) Adrian wrote:
We prefer to include the line end marker, in order to avoid code injection. (Yes, there can also be malicious attempts to ban another site, or the one of the admin.)
Well, As you still seem to have the choice, it would be great, if you could be inspired from the manual for designing your error logs. I am sure they comply to some logfile standard anyway, and other applications would benefit as well from using the or a standard. |
(replace If you match this you should be on the safe side - and you still do not need to include anything for the last segment after the |
Actually, I would recommend you to edit logging.conf to write auth-related messages into a separate file, using a simpler format. For example, you can get this:
by adding this to logging.conf:
Of course you also need to add With this format you can then use this regex:
|
Hi everyone, I am using the following configuration with fail2ban at the moment: In /opt/indico/etc/logging.yaml
In /etc/fail2ban/jails.local:
And following in /etc/fail2ban/filter.d/indico_pw.conf and indico_nouser.conf
The idea is to block requests especially long that try to figure out valid usernames while the check for wrong passwords should prevent that users lock their ldap account (maybe an additional LDAP rule would be enough). |
3.0 will support rate limiting for failed logins out of the box (see #4817) - and unlike fail2ban it will only block logins, so it's much more user-friendly. |
# Ticket imported from Trac
Fail2ban (http://www.fail2ban.org/) allows to block IPs temporarily in case they try brute-force attacks on login/passwords. That system is quite universal and uses logfile entries.
We would like to use it, but in order to work correctly, it must write the originating IP into the logfile, which is not the case presently. (Only the uid is printed with timestamp and error text.)
Be careful to make sure the log text (analysed with regex) cannot trigger fake alerts and lock the site admins out. It must be safe against injection by trying false logins with UID="Login failed for 'hoffmann' from IP=127.0.0.1" for example.
This request is relevant for Local and LDAP authentication, probably not for SSO (which has its own brute-force hacker filter) and maybe for NICE.
The text was updated successfully, but these errors were encountered: