it is possible to receive the send-proxy header correctly. or where is the best setting for the apache Nethserver. so that the fail2ban rules from nethserver work and recognize the original ip behind reverseproxy haproxy.
This is a corner case we did not take in consideration (yet), each service must be adapted to make visible the real IP in your reverse proxy, else fail2ban will ban the proxy
We talked of this here : Fail2ban and webmail roundcube
After the IP of the attacker is made visible in log, we have to make a custom regex to catch the IP attacker. What is the most used scenario for proxy, apache I wonder.
hi
thx 4 reply …
i’m not sure, but regex could be the solution. i now have behind the haproxy the following log entry at the nethserver sogo log.
first is the external ip and after a sepperatotor “,” the internal route ip, but fail2ban doesnt ban.
why ?
sogod [20745]: 93.230.x.x, 192.168.x.x "POST /SOGo/Microsoft-Server-ActiveSync? SOGoRootPage Login from '93.230.x.x, 192.168.x.x' for user 'test' might not have worked - password policy: 65535 grace: -1 expire: -1 bound: 0 ERROR(-[NGLdapSearchResultEnumerator nextObject]): does not support result references yet . <0x0x55bee51f9c50[LDAPSource]> <NSException: 0x55bee5db2c10> NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31) INFO:{"error_code" = 49; login = "samaccountname=test,dc=ad,dc=domainname,dc=offline"; }
if it’s just a regex change, can you tell me the right place and regex entry? i don’t have that much experience with it yet.
but i see orginal ip first ! and what does the sogo error log want to tell me with the samba ?
For samba it’s because you use nethserver-dc (samba4).
Fail2ban find attackers with a regex matching the bad login and extract the ip from it. Of course with the reverse proxy, the log line is probably different
I am the guilty here, i made the reverse - proxy feature, we probably will have more and more issues like this. Fail2ban could be adapted to the reverse proxy case
Cc @dev_team
This is the documentation of fail2ban
in /etc/fail2ban/filter.d/sogo-auth.conf
failregex = ^ sogod \[\d+\]: SOGoRootPage Login from '<HOST>' for user '.*' might not have worked( - password policy: \d* grace: -?\d* expire: -?\d* bound: -?\d*)?\s*$
^ sogod \[\d+\]: SOGoRootPage Login from '<HOST>, .*' for user '.*' might not have worked( - password policy: \d* grace: -?\d* expire: -?\d* bound: -?\d*)?\s*$
then restart fail2ban
systemctl restart fail2ban
this change will be overwritten by the next fail2ban update
Thank you very much for the manual.
my misstake, I pressed the update button in the software center (from version 7.5 to 7.6 final).
I wanted to configure the reverse proxy correctly, but found out that update did not work.
or better said the mail server service imap doesnt work.
in the sogo log is the following:
Jan 02 14:48:04 sogod [3133]: <0x0x55ebf7405580[NGImap4Client]> ERROR(-[NGImap4Client _handleShutdownDuringCommandException:]): IMAP4 socket was shut down by server NGSocketShutdownDuringReadException: the socket was shutdown
Jan 02 14:48:04 sogod [3133]: [ERROR] <0x0x55ebf6f4dab0[NGImap4ConnectionManager]> IMAP4 login failed:
host=localhost, user=username@domain.com, pwd=yes
url=imap://username%40domain.com@localhost/
base=(null)
base-class=(null))
= <0x0x55ebf7405580[NGImap4Client]: login=username@domain.com(pwd) address=<0x0x55ebf71596e0[NGInternetSocketAddress]: host=localhost port=143>>
Jan 02 14:48:04 sogod [3133]: [ERROR] <0x55ebf72849f0[SOGoMailAccount]:0> Could not connect IMAP4
in the Imap log is the following:
dovecot: imap: Fatal: Plugin ‘imap_sieve’ not found from directory /usr/lib64/dovecot
can you tell me the safest way to make the mail server functional again with SOGo ?
i have try " yum install dovecot-pigeonhole " but my system say its installed.
ok i have fixed with
yum clean all && yum makecache
and
yum update
and everything works
thx
Please, try to open one thread for one issue, it is better to understand
else you could try also : yum clean all --enablerepo=* ; yum update
I’d prefer to handle this specific scenarios with a custom configuration of fail2ban rather than adding such feature in the package.
Each regex, principally for web services, must be modified, so yes it is a real work. However it could become a common scenario due to the remote ldap authentication and the powerful nethserver modularity.