Excluding logging of blocked detections

[Sander de Cocq 0]

Hello,

 

ESET Security Management Center (Server), Version 7.1 (7.1.717.0)
ESET Security Management Center (Web Console), Version 7.1 (7.1.393.0)

Yesterday our ESMC crashed because the SQL database had grown beyond 10GB (SQL Express limit). 

We are protecting a lot of Windows Web Servers with File Security, which are obviously constantly under attack from many bot nets, therefore millions of (firewall) detections are logged that are actually blocked and that we are not particularly interested in. 

Is it possible to lower the logging level so only firewall detections that are not blocked are logged? Or any other suggestions to keep the database size under control?

I was also looking at the log retention settings, but these are already all set to 1 month or less.

 

 

 

[Marcos 5,074]

I assume that you are not using ESET's firewall since we provide only a personal firewall for clients, not for servers or gateways. We strongly recommend configuring the firewall on the gateway properly so that only desired inbound communication is allowed. Not sure what exactly is detected but I assume it's bruteforce RDP, SMB or SQL attempts to log into your network so ignoring the detection may result in compromise of the network. Attackers typically bruterorce RDP credentials, log in, disable antivirus, run ransomware and then extort money from the victim.

[MartinK 378]

Could you also provide us some example of most common detections? Asking because there is often confusion between firewall, filtered websites and webcontrol detections, where each of them has separate configuration.

[Sander de Cocq 0]

Thank you for your response. Yes it is mainly botnet RDP attacks. This causes an endless stream of detections, 10's per minute, since we are talking about 250+ internet facing servers with RDP enabled. This is by design and all have loooong complex passwords. The blocked detection logging really has no benefit for us, it actually turns into a liability when the growth of the era_db is limited and can take down the ESMC services. 

[Marcos 5,074]

You can disable Network protection and so allow brureforce attacks, however, from the security point of view I cannot recommend it.

Instead I would recommend adding a firewall and allowing only desired communication. RDP should be disabled for connections from outside; VPN or RDP with 2FA should be used.

[Sander de Cocq 0]

Hello,

I certainly don't want to disable Network Protection! I just don't want our database to explode with logging of the blocked attempts.

Is there perhaps a way to clean up the logging in the database through ESMC or SQL queries?

 

 

[itman 1,659]

25 minutes ago, Sander de Cocq said:

I certainly don't want to disable Network Protection! I just don't want our database to explode with logging of the blocked attempts.

You should be able to add or modify an IDS exception to continue to block but not log or alert?

Edited February 5, 2020 by itman

[Marcos 5,074]

From the security point of view you should use a firewall to prevent exploitation attempts from occurring at all. It could happen that due to a not yet known vulnerability in RDP attackers will eventually succeed and log in to machines in your network even if strong passwords are used. So why not to use a firewall and significantly reduce the attack surface instead of silencing ESET and not to report exploitation attempts? While it should be possible similarly to what itman showed, it's quite dangerous to ignore the actual security problem I'd say.

[itman 1,659]

22 minutes ago, Marcos said:

From the security point of view you should use a firewall to prevent exploitation attempts from occurring at all. It could happen that due to a not yet known vulnerability in RDP attackers will eventually succeed and log in to machines in your network even if strong passwords are used. So why not to use a firewall and significantly reduce the attack surface instead of silencing ESET and not to report exploitation attempts? While it should be possible similarly to what itman showed, it's quite dangerous to ignore the actual security problem I'd say.

This I do agree with since it indicates that attackers are accessing RDP ports via the border edge gateway and this is the point where the issue should be addressed.

[itman 1,659]

A few other comments

Eset's RDP brute force detection is a generic one. As such, it could cause a false positive detection. Disabling logging of it also effectively disables diagnostic capability if it is borking a critical internal network connection.

Sophos has a Group Policy recommendation to handle brute force RDP I thoroughly endorse which is very effective with minimal account lockout repercussions. This needs to applied to all devices where RDP is enabled:

Quote

 

• by a five-minute lockout, a crook can only try out 12 × 3 = 36 passwords an hour, which makes a brute force attack impractical.

 

 

[MartinK 378]

Could you please access database via SQL Server Management Studio and provide us basic sizing statistics (number of entries, overall size of table) for problematic DB tables (there are standard reports available for this). In case table taking most of the space is tblf_firewallagregated_event, could you also verify that oldest entry as stored in column "Occurred" is not older than ~1 month? Asking, because in case there is huge amount of entries in mentioned table, it might have resulted in daily cleanups to fail and thus not cleaning older entries.

Also in case there are many such event reported in a minute, are they all from different devices? Or clients are sending multiple identical events in a minute? If so, we might have to check whether event aggregation works correctly.

[Sander de Cocq 0]

17 hours ago, itman said:

You should be able to add or modify an IDS exception to continue to block but not log or alert?

 

This is indeed the answer I was looking for, it works great, thank you!

I agree with, and appreciate the other responses as well, those indicate more of an architectural issue however and will be addressed separately. My question was purely from an operational POV for the short term to keep our ESMC server operational.

 

[Sander de Cocq 0]

11 hours ago, MartinK said:

Could you please access database via SQL Server Management Studio and provide us basic sizing statistics (number of entries, overall size of table) for problematic DB tables (there are standard reports available for this). In case table taking most of the space is tblf_firewallagregated_event, could you also verify that oldest entry as stored in column "Occurred" is not older than ~1 month? Asking, because in case there is huge amount of entries in mentioned table, it might have resulted in daily cleanups to fail and thus not cleaning older entries.

Also in case there are many such event reported in a minute, are they all from different devices? Or clients are sending multiple identical events in a minute? If so, we might have to check whether event aggregation works correctly.

Hello,

I got the server operational again, and cleanup jobs that were indeed failing are now working again and I have 58% free space in the database. The  tblf_firewallagregated_event table was definitely the culprit. I'm going to keep an eye on the specifics you mention to see if we still have an issue.