preventing brute force against login

[matthewb...@gmail.com]

Hi just wondering about preventing brute force against the atom login.

There's a tool called rack attack which is used to prevent ddos attacks. It's completely open source. Here's an article I'm reading about it:

https://bigbinary.com/blog/how-to-mitigate-ddos-using-rack-attack

Do the atom team reckon this would be effective against login attempts?

Any adjustments needed to make it so?

[Dan Gillean]

Hi Matthew, 

I'm not personally familiar with Rack Attack, but it looks like it's a Ruby Gem, meaning you'd need to ensure that Ruby was installed and properly configured on your server to make use of this. As for integrating it with an AtoM site, I'm not sure. 

Perhaps a more fruitful way to explore this would be with Nginx, which AtoM already uses as its webserver. A quick search for "Nginx brute force" will reveal a lot of articles - many of which involve installing fail2ban, and using Nginx as a reverse proxy to ban users with repeated failed login attempts. It would likely take a bit of configuration and testing to configure it properly, but this is a widely used solution that employs the webserver you're likely already using with AtoM. 

Long term, it would be nice to see a login attempt limit built into AtoM itself, as well as perhaps an expiry timeframe that administrators can set so users have to change their passwords periodically. These security enhancements would require community support for us to implement in AtoM, either via code contributions or else paid development sponsorship. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/d5f2fc92-7141-4a45-978e-4f7e41c901a7n%40googlegroups.com.

[Monica Wood]

Hi Matthew,

 

I’d suggest looking into fail2ban.

You would use the access logs to determine failed log in attempts and you can set the configuration to determine how many failed log ins in a certain timeframe would equal an IP ban. 

You also set up how long a ban would last on that IP.

 

Fail2ban is also useful to catch bruteforce ssh logins and you can even whitelist IPs.

 

I can see if I can find our configuration and send it to you.

 

Cheers,

Monica Wood

Library Applications Administrator

Library | Academic Division

University of Tasmania

Private Bag 25, Hobart TAS 7001

--

You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/d5f2fc92-7141-4a45-978e-4f7e41c901a7n%40googlegroups.com.

University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.

[Monica Wood]

Here is a basic configuration that will work on the atom login. Ubuntu fail2ban configuration is kept at /etc/fail2ban/

 

In jail.local:  (Enter your IP in ignoreip and point the logpath to your nginx log access file.

 

[DEFAULT]

 

ignoreip = #ENTER YOUR IP HERE TO MAKE SURE YOU ARE NOT BANNED ACCIDENTILY

bantime  = 1h

findtime  = 30m

maxretry = 3

 

 

[sshd]

filter = sshd

maxretry = 2

enabled = True

port = ssh

 

#

# HTTP servers

#

 

[nginx-http-auth]

enabled = true

filter = nginx-http-auth

port    = http,https

logpath = /var/log/nginx/access.log

 

 

The filter file at filter.d/nginx-http-auth.conf:

 

# fail2ban filter configuration for nginx

 

[Definition]

# Match /index.php/user/login. 200 status code means it didn't successfully login and didn't redirect the user to the page they were just on.

# 302 redirect status code means the login was successful

failregex = ^<HOST> - - \[.*?\] "POST /index.php/user/login HTTP/1.\d" 200

 

ignoreregex =

 

 

 

hopefully this will help you and anyone else that would like to set it up for AtoM.

[Dan Gillean]

Thanks so much for sharing this helpful example, Monica!

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/F70ECA0B-C455-42F2-843A-3332171AD8F1%40utas.edu.au.

[matthewb...@gmail.com]

Hi guys,

Thanks so much for the responses. Yes I use fail2ban already and have great fun with it. I vaguely remember reading about this capability, but it seemed a bit complex at the time.

I'll get to installing this and if I have any problems, I will post them up.

Dan, do think that installing ruby might causes conflicts with nginx or atom? Is that why you are reticent?

As for building features like this into atom, it would be more user friendly, but only add to the bulk of it. So I'm happy doing it this way.

[Dan Gillean]

Hi Matthew, 

I don't think that installing Ruby will necessarily cause conflicts with AtoM - I just don't know enough about the gem you describe, or how it could be configured to cover AtoM. Since AtoM is a web-based application and all requests/responses are already routed via the webserver (Nginx), it just seemed easier to me to look for solutions involving existing components, rather than installing (and then having to maintain) new libraries and requirements and then trying to figure out how to get them to play nicely together. 

That said, if you do end up experimenting with Rack Attack, I'd love to hear how it goes!

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/225b39c0-3f11-4b4d-85d8-044e85271744n%40googlegroups.com.

[matthewb...@gmail.com]

Just for those interested. I am trying the above configuration in fail2ban and am not getting anywhere. I used hydra to attempt to brute force the login, and while this seems to be working, fail2ban is not picking it up.

Here is what I am using for hydra

sudo hydra -l d...@email.com -P passwords.txt <my IP address>  http-post-form "/index.php/user/login.php:next=&email=dfg%40email.com&password=^PASS^:Sorry, unrecognized email or password"

And attached is the output in the nginx acccess logs .

I will try to make some tweaks to the fail2ban properties. If I succeed I will write again.

[Dan Gillean]

Hi Matthew, 

I'm hoping that Monica might see your post and respond. I've checked with the Artefactual team, and we mostly use fail2ban to prevent SSH brute force attacks on the server, not application login attempts via HTTP or HTTPS. Because of this, our team didn't have many concrete recommendations we can offer at this time. That said, I believe it can be done if configured properly. 

These articles are older in some cases, and not an exact solution for AtoM, but they may help point you in the right direction?

• https://www.digitalocean.com/community/tutorials/how-to-protect-an-nginx-server-with-fail2ban-on-ubuntu-14-04
  
• https://snippets.aktagon.com/snippets/554-how-to-secure-an-nginx-server-with-fail2ban
  

Good luck!

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/01a6aa82-ed9f-4030-b07f-e1093f3eb512n%40googlegroups.com.

[Monica Wood]

Hi Matthew,

The access log shows that those access attempts are returning a 404 instead of 200 or 302... 404 means not found. The fail2ban regex I gave will only ban on failed log in attempts, so a page needs to be returned.   Are you running hydra on a different server to atom?  Check that it can reach the server by trying to curl to the full url of atom.  Make sure you use the correct protocol of https or http (depending on your settings).   If you'd like to ban on 404s too, you will need to add this to the regex.

If you can send me the full access log and fail2ban log of around the time you ran hydra, I can have a closer look.

Cheers,

Monica

Get Outlook for Android

---

From: ica-ato...@googlegroups.com <ica-ato...@googlegroups.com> on behalf of Dan Gillean <d...@artefactual.com>
Sent: Thursday, May 20, 2021 11:50:53 PM
To: ICA-AtoM Users <ica-ato...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2BMTs4zqCzm%3DETPNbPuA6Wodcqy890uur82SUcrBCu2tg%40mail.gmail.com.

[Karl Goetz]

Hi Matthew,

Looks like your hydra is running against login.php, which doesn't exist in atom. The route name is /user/login.

grep -r user/login
data/fixtures/menus.yml:    path: user/login
test/functional/qubit/dcTest.php:$browser->post(';user/login', array('login' => array('email' => $email, 'password' => $password)));
test/functional/qubit/loginTest.php:  ->post(';user/login', array('email' => 'te...@example.com', 'password' => 'test1234'))
test/functional/qubit/loginTest.php:  ->post(';user/login', array('email' => 'te...@example.com', 'password' => 'wrongpass'))
test/functional/qubit/loginTest.php:  ->post(';user/login', array('email' => 'te...@example.com', 'password' => 'test1234', 'next' => 'http://localhost/example'))
test/functional/qubit/loginTest.php:  ->post(';user/login', array('email' => 'te...@example.com', 'password' => 'test1234', 'next' => ''))
lib/task/migrate/QubitMigrate104.class.php:      'path' => 'user/login'

find . -name login.php
grep -r login.php

Karl.