Brute force protection with fail2ban

Is there a way to protect the admin login with fail2ban to prevent brute force attacks? Has someone ever tried/think about this? If you have a lot of personal related data inside phplist, I think its worth putting some energy into system hardening …

I think it´s going to be difficult without creating a way to log loging attempts to a file. But if you want you can create a little hardening.

  1. Rename the default installation folder (lists) and change the location of the admin folder. Remember to edit the config.php

     $pageroot = '/lists';
     $adminpages = '/lists/admin';
    
  2. Add this lines to the admin .htaccess so only you can log in…

     order allow,deny
     allow from xxx.xx.xxxx
     deny from all
1 Like

2 points about @Angel’s suggestions, you no longer need to specify $adminpages in phpList 3.3.x and where xxx.xx.xxxx shows for the .htaccess file, this should point to your own IP address.

To find your IP address, visit Lookup IP Address Details and remember this will only work if you have a static IP address. If your IP address changes everytime you connect to the internet, this won’t work.

2 Likes

In these days it would be really nice to have features like 2-factor-authentication and an option for brute force protection, especially if systems handle a lot of personal related data.
Static IPs: Not applicable because of dynamic IPs. Moving the admin login URL is some sort of security, but security by obscurity is no real security – maybe you understand what I mean. :wink:

I have a new idea: Would it be possible to redirect the user to another page than the normal login page after a failed authentication which can then be be tracked by fail2ban for example with n hits on this page within m time – > banned.
At the moment a failed login just ends on the same login page with no possible way to see in the logs if the login was successful or if the page was simply reloaded.

@sd3pk3 I had a quick look at the fail2ban documentation and it appears to work by scanning log files. One approach could be to develop a phplist plugin that periodically dumps the phplist eventlog table, or just selective rows, to a file that fail2ban can access.

Or even simpler, just automate the mysqldump command.

When a login attempt is rejected there is a row in the event log

image

Interesting idea! A cronjob with mysqldump exporting the phplist eventlog table export should be fine.
Fail2ban can analyze any logfile, so the mysql dump has to be converted to a log format which is readable by fail2ban, sed with search and replace to insert linebreaks after each log entry should do the job combined with the cronjob output.

Problem: The eventlog is written in the database in the user langage. So if you have users with a lot of different browser languages, you might have to write regular expressions for every single translation – but the log might show you which langauge string is sent by bots :smiley:

@sd3pk3 Using the --tab parameter, mysqldump will output a csv-type file that I expect can be processed directly by fail2ban.

mysqldump --tab=/tmp -u phpmyadmin  --password=xxxxx phplist phplist_eventlog

The results of running

fail2ban-regex /tmp/phplist_eventlog.txt 'invalid login from <HOST>'

Running tests
=============

Use   failregex line : invalid login from <HOST>
Use         log file : /tmp/phplist_eventlog.txt
Use         encoding : UTF-8


Results
=======

Failregex: 55 total
|-  #) [# of hits] regular expression
|   1) [55] invalid login from <HOST>
`-

Regarding Angels suggestion. I’ve put:

order allow,deny
allow from xxx.xx.xxxx <----- my ip address
deny from all

in the admin’s folder .htaccess, yet I get errors accessing. When I remove those three lines I regain access.

Are there any other qualifiers that are required in the .htaccess file? Or is it just those three lines?

Also I believe this may prevent captcha from working. . .