Hacking attempts currently being logged

For the past couple of days my access and error logs are full of hacking attempts. I use a couple of non-standard ports for http and https interface, but it looks like the hacker has found these and is blasting away at them.

Having had a previous PBX 14 broken into, I am anxious to stop these. Obviously blocking the IP will have little effect, but I had thought the “intrusion detection” (Fail2Ban) would have identified and blocked these. However, the Fail2Ban blocked list is empty.

Any suggestions?

Many thanks

Andy Woolford

Fail2Ban might not be working - from the cli, iptables -L -v and you should see the jails listed.

Also, if you have persistent hacking attempts, can you limit the IP’s allowed to login - whitelist those IP’s and ban the rest.

2 Likes

Absolutely agree. You should always take the approach of “DENY ALL EXCEPT…”

So, for example, if you only do management from your local subnet (or better yet, from a single IP on your local subnet) you would block all logins except from that single IP.

If you don’t have any “remote” extensions (in other words, no phones logging into your system from outside / WAN side) then deny all logins, then permit the ones from the local subnet.

The rule of thumb should be “Take it ALL away… then give it to select few”

1 Like

Thanks for the suggestions.

I am using the FPBX firewall and the adaptive function is off. However Port 80 is open for the LetsEncrypt service (which only allows access to the .wellknown folder).

The other two (http / https) management ports are non standard, but I don’t see a way of restricting just those two ports without also blocking AWS needed for LetsEncrypt to function on port 80.

The other issue I have is that the server is in a data centre and my remote management location is on a dynamic IP address.

How would you suggest I configure the firewall to do what you suggest and allow LetsEncrypt to function?

There are two jails predefined in fail2ban , apache-nohome and apache_noscript that would likely help your situation if enabled

Hi,

In centos 7 where we can see the hacking attempts in the audit logs or somewhere else

Thanks

In the distribution, Fail2Ban is managed by the sysadmin module.

I can see no way of modifying the jails from there and in the console, I can see the jail.conf and jail.local files which do not contain any disabled jails.

The jail.local file also warns me that any mods will be overwritten by the sysadmin module.

You will find the logs in /var/log/httpd/access_log and
/var/log/httpd/error_log

If you want them back, Fail2ban will always load files in the jail.d ‘drop’ directory which would not be overwritten.

Ah that’s good to know.

Where would I find these preconfigured jails?

(jail.d directory is empty)

This is the output of iptables -L -v: (fail2Ban chains only shown below)

As you can see, nothing is banned, even though my logs are still full of errors and failed access attempts.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
1615K 2825M fail2ban-recidive  all  --  any    any     anywhere             anywhere
14900 2578K fail2ban-BadBots  tcp  --  any    any     anywhere             anywhere             multiport dports http,https
    5   204 fail2ban-FTP  tcp  --  any    any     anywhere             anywhere             multiport dports ftp
1615K 2825M fail2ban-apache-auth  all  --  any    any     anywhere             anywhere
   49  2184 fail2ban-SSH  tcp  --  any    any     anywhere             anywhere             multiport dports ssh
1615K 2825M fail2ban-SIP  all  --  any    any     anywhere             anywhere
1615K 2825M fail2ban-SIP  all  --  any    any     anywhere             anywhere
1655K 2896M fpbxfirewall  all  --  any    any     anywhere             anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 51014 packets, 91M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-BadBots (1 references)
 pkts bytes target     prot opt in     out     source               destination
14900 2578K RETURN     all  --  any    any     anywhere             anywhere

Chain fail2ban-FTP (1 references)
 pkts bytes target     prot opt in     out     source               destination
    5   204 RETURN     all  --  any    any     anywhere             anywhere

Chain fail2ban-SIP (2 references)
 pkts bytes target     prot opt in     out     source               destination
3229K 5650M RETURN     all  --  any    any     anywhere             anywhere
    0     0 RETURN     all  --  any    any     anywhere             anywhere

Chain fail2ban-SSH (1 references)
 pkts bytes target     prot opt in     out     source               destination
   49  2184 RETURN     all  --  any    any     anywhere             anywhere

Chain fail2ban-apache-auth (1 references)
 pkts bytes target     prot opt in     out     source               destination
1615K 2825M RETURN     all  --  any    any     anywhere             anywhere

Chain fail2ban-recidive (1 references)
 pkts bytes target     prot opt in     out     source               destination
1615K 2825M RETURN     all  --  any    any     anywhere             anywhere

You will likely find

fail2ban.org

to be authoritative, both the documentation as to how to use it and the currently distributed codebase, which includes common jail examples/workers (big hint, v 10 works much better than V 8 :wink: , 2nd big hint, add pyinotify to your system to significantly decrease response latency.)

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.