questions about firewall behavior??

MichaelJoseph01 · 06-06-2023, 01:01 PM

Hello all,

I have a new site up on a ubuntu/apache-nginx/plesk system on a cloud vps. It's a work in progress and I'm already seeing tons of malicious traffic. I went from relying on mod_security and fail2ban to installing imunify360 because of how much hype I saw online. Now, i'm seeing how different Imunify360 works compared to fail2ban and I'm not convinced its better, at least for my setup. It doesn't utilize "jails", so no matter how many times a malicious client tries to brute force into ssh, or wp-login, or probe for xmlrpc vulnerabilities, or any other clearly malicious behavior - they can come back again and again and I see all these requests in the logs drowning out legitimate traffic.

I emailed Imunify support about this:
----

I just installed Imunify360 and am trying to understand these filtering rules. I've attached a screenshot that shows I'm having dozens of malicious events in a span of minutes by a small number of IP's, yet there is not one IP in the blacklist yet? When using fail2ban, I could determine how many times an IP offended before they were totally banned for whatever length of time I choose. Where is the equivalent configuration here? It's still sapping server resources by handling these requests one by one, why are none of these bad actors ending up on a permanent drop list and able to come back again and again to probe different parts of the attack surface??

----

The response I got:
----

Hi Michael,

All of the IP addresses on your screenshot were blocked: the ones in a blue bubble were blocked by the active response feature on the fly, without adding to any lists due to the way how the feature works, and the ones in the gray bubble were graylisted, i. e. served captcha before allowing access to the actual sites.

Permanent blocking brings high risks of false-positives and we never do this automatically - we limit accesses in a smart and sophisticated ways with the help of gray list, heuristics on the central server, WAF, and the on-the-fly blocking features - active response and PAM.

Permanent list is available only for manual blocking, and the automatic blockings are implemented via the gray list, to avoid false-positives, as there has to be a balance between security and usability.
----

From my view, if I see someone with clearly malicious intent, I'm not going to continue to allow them to come back to probe other areas, or even the same area over and over and over again. I can totally see how this tradeoff would be necessary if you're running absolutely critical services, but for a website with no users yet this seems ludicrous to allow this resource-intensive firewall to keep sapping memory, cpu cycles and log entries dealing with the kind of traffic that in my eyes should be stopped at the front gate.

What do other people think, or use??? I can't be the only one fretting about malicious traffic, seeing how my site doesn't even have any backlinks yet and I'm already seeing the logs filling up with the probing of bad actors from china, russia, germany, iran, etc.

I appreciate any kind of input.

Turbocapitalist · 06-06-2023, 01:21 PM

Quote:

Originally Posted by MichaelJoseph01

[snip]
It doesn't utilize "jails", so no matter how many times a malicious client tries to brute force into ssh, or wp-login, or probe for xmlrpc vulnerabilities, or any other clearly malicious behavior - they can come back again and again and I see all these requests in the logs drowning out legitimate traffic.
[snip]
What do other people think, or use???
[snip]

You might also look at SSHGuard which, despite the name, does a lot with HTTP.

However, for several production systems I use a custom medium-size AWK script to monitor the web server's (and other services) logs real-time and trigger adding the offending addresses to a named set in NFTables. It did not take long to build out the regular expressions used to trigger the blocking. The downside is that there is not a timeout after a while where the addresses are cleared if they have not pestered the service for a period of time.

astrogeek · 06-06-2023, 02:05 PM

Quote:

Originally Posted by Turbocapitalist

You might also look at SSHGuard which, despite the name, does a lot with HTTP.

However, for several production systems I use a custom medium-size AWK script to monitor the web server's (and other services) logs real-time and trigger adding the offending addresses to a named set in NFTables. ... The downside is that there is not a timeout after a while where the addresses are cleared if they have not pestered the service for a period of time.

I have not worked much with nftables (still an iptables fan), but I was surprised to read the above.

The nft man page on my Slackware system indicates that nftables named sets can indeed be configured with a timeout parameter:

Code:

SETS
      ...
      The next section describes nft set syntax in more detail.

           add set [family] table set { type type | typeof expression ; [flags flags ;] 
                   [timeout timeout ;] [gc-interval gc-interval ;]
                   [elements = { element[, ...] } ;] [size size ;] [comment comment ;] 
                   [policy 'policy ;] [auto-merge ;] }
      ...
      timeout  time an element stays in the set, mandatory if set is added to from the 
               packet path (ruleset)

For what it is worth I make much use of ipsets with iptables, adding members both from rules and from external scripts and highly recommend it (i.e. dynamically managed sets) as a way to cope with maltraffic.

Turbocapitalist · 06-06-2023, 02:13 PM

Quote:

Originally Posted by astrogeek

The nft man page on my Slackware system indicates that nftables named sets can indeed be configured with a timeout parameter:

Thanks, I had missed that. I'll look into that part of the documentation and update my scripts.

I still prefer PF but that's not available for Linux, so NFTables it is. I'm quite new to NFTables but find it a breath of fresh air after having the misery of dealing with the incomplete and confusing aspects of IPTables since IPChains was deprecated.

astrogeek · 06-06-2023, 02:31 PM

I admit the learning curve for iptables was steep, even painful. But having reached the crest I enjoy the view and am in no hurry to move on.

By the way, my comment about managing maltraffic with ipsets and iptables was intended as encouragement for the general method of sets which would include nftables native sets - not about using iptables.

sundialsvcs · 06-06-2023, 06:54 PM

My approach is entirely different, whether it's a "cloud" server or a real one.

I first set up an OpenVPN server, and allow "direct outside traffic" only to connect to any HTTP server. Otherwise, nothing is available.

The OpenVPN server is configured to use only "certificate based" security – "PSKs = simple passwords" are not allowed. Furthermore, the tls-auth feature is employed to conceal the presence of the server. "Scanners" will find nothing of interest.

Authorized users are individually issued one-of-a-kind certificates as well as the "tls-auth" credential. All of this is neatly bundled into their client such that they merely need to "click on an icon at the top of the screen and wait for it to switch from gray to black." At this point, they can proceed to do other things – such as to use "ssh."

The "sshd" server, if there is one, is configured to only accept connections from the "OpenVPN internal subnet." Likewise "mysql" or any other server. All of these things are inside the "OpenVPN moat," reachable only by those who have found and crossed its hidden drawbridge.

Credentials, once issued, can be individually revoked without affecting any other credential. They can be "password protected" (encrypted ...) to prevent unauthorized use by someone who stole the laptop at the airport, but the password means nothing if the credential has been revoked. (As the company would swiftly do, as soon as they learned that the laptop had been stolen at the airport.)