IDS use over 70% of CPU & too many attacks detected

[Nightowl 202]

I doubt so , once Windows Firewall is blocking properly , ESET should not be able to receive these attacks , because they were stopped in first place by the Firewall

[Marcos 5,070]

10 minutes ago, Nightowl said:

I doubt so , once Windows Firewall is blocking properly , ESET should not be able to receive these attacks , because they were stopped in first place by the Firewall

The question is which firewall gets the communication first. This is something that we cannot influence to my best knowledge.

[Nightowl 202]

12 minutes ago, Marcos said:

The question is which firewall gets the communication first. This is something that we cannot influence to my best knowledge.

1 year before I had a similiar attack to a Windows Server that was being constantly attacked in Port 445

Once that port was closed in Windows Firewall , ESET stopped showing any signs of attacks , If I would enable the port again in Firewall , ESET will start showing attacks again as the scripts didn't stop , they will just attack all the time.

Edited July 15, 2021 by Nightowl

[kamiran.asia 5]

26 minutes ago, Nightowl said:

1 year before I had a similiar attack to a Windows Server that was being constantly attacked in Port 445

Once that port was closed in Windows Firewall , ESET stopped showing any signs of attacks , If I would enable the port again in Firewall , ESET will start showing attacks again as the scripts didn't stop , they will just attack all the time.

Yes ,we agree with you. in many other project and servers when we block incoming port ( i.e 445 ) ESET did not report any attack from those blocked ports. But in this case we are confused ! how these traffic are received by ESET firewall driver. or may be these attacks are not TCP / UDP that cause IDS performance issue ! ( because we just Block TCP / UDP inbound protocol in WF) but while ESET IDS did not report any target port we can not realize how these black list ip are accessing the server.

[itman 1,659]

On 7/15/2021 at 5:28 AM, Nightowl said:

1 year before I had a similiar attack to a Windows Server that was being constantly attacked in Port 445

If NetBIOS is enabled and Win file and printer sharing enabled, one is vulnerable to port 445 attacks.

I have both NetBIOS disabled on my network adapter connection and LLMNR disabled via Win registry setting. I also have Eset Network services for file and printer sharing and LLMNR disabled. The result is Eset firewall rules as shown below:

I also question Eset's default outbound rule here since all inbound to these ports are blocked. Probably the rule should be disabled and a like block rule be created. Note that this would have to be placed after Eset's default ekrn.exe rule since Eset monitors network traffic using its hidden local proxy server using the NetBIOS port range.

Edited July 16, 2021 by itman

[itman 1,659]

I also don't understand the confusion with how Eset's firewall works in conjunction with the Win firewall since it's well documented.

Eset firewall rules take precedent over any existing Win firewall rules. That is, all Eset rules are executed first. By default, the Eset installer will also enable the firewall setting, "Also evaluate rules from the Win firewall." Mouse click on setting help to get a full explanation of what this setting does. First, it only applies to Eset Automatic firewall mode; i.e. all outbound traffic allowed unless specifically blocked by an existing Eset firewall rule. Next, it will also apply existing Win inbound firewall rules after all existing inbound Eset firewall rules have been evaluated. In other words, the Win firewall would only block some inbound traffic if it had not been previously blocked by the Eset firewall.

Edited July 16, 2021 by itman

[Marcos 5,070]

As I assumed, the performance issue is caused by too many attacks / IDS detections which invoke memory scanning. We will make certain optimizations to address the overhead.

[kamiran.asia 5]

8 hours ago, Marcos said:

As I assumed, the performance issue is caused by too many attacks / IDS detections which invoke memory scanning. We will make certain optimizations to address the overhead.

Thank you dear @Marcos ,

As we mentioned , We block all incoming TCP and UDP port in windows Server Firewall. So in this case ESET Firewall scan traffics before windows firewall. 

So we are waiting for any update to enable IDS again.

[Nightowl 202]

On 7/21/2021 at 10:51 PM, kamiran.asia said:

Thank you dear @Marcos ,

As we mentioned , We block all incoming TCP and UDP port in windows Server Firewall. So in this case ESET Firewall scan traffics before windows firewall. 

So we are waiting for any update to enable IDS again.

Attacks shouldn't reach ESET as they were stopped by the Firewall in first place , how could they reach if the Firewall blocked them in first place?

Something is weird or I just don't understand it.

If ESET is still showing things in Network Troubleshooting area and Blocked IP Addresses List area , then the Windows Firewall is not blocking properly.

When Windows Firewall is blocking properly , then ESET shouldn't see anything because it's already stopped before it can even see them by the Firewall.

Edited July 24, 2021 by Nightowl

[itman 1,659]

3 hours ago, Nightowl said:

When Windows Firewall is blocking properly , then ESET shouldn't see anything because it's already stopped before it can even see them by the Firewall.

Refer to what I posted above: https://forum.eset.com/topic/29183-ids-use-over-70-of-cpu-too-many-attacks-detected/?do=findComment&comment=136864 .

Again, by default Eset will only refer to Windows inbound firewall rules if the network activity being handled by existing Eset firewall rules has not been processed by one of these Eset rules. In this situation, the Eset firewall will pass control to the Windows firewall processing to determine if an existing allow inbound rule exists for the network activity. If such a rule exists, the Eset firewall will allow the inbound network traffic; otherwise the Eset firewall will block the inbound traffic.

Bottom line - Only Windows inbound firewall rules are referenced but at no time does the Windows firewall itself block or allow any network activity.

In the situation where the Windows firewall contains inbound block rules, the question is if the Eset firewall will process those rules or ignore them? My best guess is it ignores those rules since it is only looking for an allow rule for the network activity. The end result however is that the inbound network traffic is blocked; but always by the Eset firewall.

Finally and important, note the following. Win firewall rules are stored in clear text in the Win registry. This makes them not only easy to read but also to be modified by malware. As such, the Eset option to use Win inbound allow firewall rules does pose a potential risk.

Edited July 24, 2021 by itman

[Nightowl 202]

1 hour ago, itman said:

Refer to what I posted above: https://forum.eset.com/topic/29183-ids-use-over-70-of-cpu-too-many-attacks-detected/?do=findComment&comment=136864 .

Again, by default Eset will only refer to Windows inbound firewall rules if the network activity being handled by existing Eset firewall rules has not been processed by one of these Eset rules. In this situation, the Eset firewall will pass control to the Windows firewall processing to determine if an existing allow inbound rule exists for the network activity. If such a rule exists, the Eset firewall will allow the inbound network traffic; otherwise the Eset firewall will block the inbound traffic.

Bottom line - Only Windows inbound firewall rules are referenced but at no time does the Windows firewall itself block or allow any network activity.

In the situation where the Windows firewall contains inbound block rules, the question is if the Eset firewall will process those rules or ignore them? My best guess is it ignores those rules since it is only looking for an allow rule for the network activity. The end result however is that the inbound network traffic is blocked; but always by the Eset firewall.

Finally and important, note the following. Win firewall rules are stored in clear text in the Win registry. This makes them not only easy to read but also to be modified by malware. As such, the Eset option to use Win inbound allow firewall rules does pose a potential risk.

This is File Security , Server Security , it doesn't offer a Firewall at all

[Marcos 5,070]

15 minutes ago, Nightowl said:

This is File Security , Server Security , it doesn't offer a Firewall at all

It contains Network attack protection which is a kind of fifirewall.

[itman 1,659]

2 hours ago, Nightowl said:

This is File Security , Server Security , it doesn't offer a Firewall at all

OK. I looked at the Eset EFS documentation and its network protection contains all Endpoint features minus the Eset firewall. Relying on the Win firewall is a real bummer.

I assume EFS must interface with the Win firewall in some way? The blocked inbound traffic from Win firewall is what shows in Eset Network Troubleshooting detail? And selecting "Unblock" there will create a Win firewall inbound rule for connection?

On 7/14/2021 at 4:26 AM, kamiran.asia said:

What is the cause of this attack while all tcp and udp port are closed by Windows firewall !?

I only see one block rule for UDP and IP. Should there not be three rules for each; one for each profile; domain, public, and private?

 

Edited July 24, 2021 by itman