AJ777 0 Posted January 19, 2022 Share Posted January 19, 2022 Hi I keep getting "Security vulnerability exploitation attempt" events in my Network Protection log files. However all of these ports are blocked by my Windows Firewall. Even if I do port scans to my public IP they come back as "filtered". Why would ESET still log these if they are being blocked by the firewall? Or are they? Link to comment Share on other sites More sharing options...
Administrators Marcos 5,392 Posted January 19, 2022 Administrators Share Posted January 19, 2022 That's because the communication was not blocked before it reached the server. Exploitation attempts are performed regardless of whether the appropriate Windows updates are installed or not. Link to comment Share on other sites More sharing options...
AJ777 0 Posted January 19, 2022 Author Share Posted January 19, 2022 I understand the attacks reached the server. However I thought the Windows Firewall would block / allow, then only would the traffic reach the ESET services. Id like it if ESET only reported on entries that made it through the WIndows Firewall. That way if the attempt was blocked, we would not get notified by ESET and do not need to worry about it. If it does get through and then logged by ESET, we can then be notified and respond accordingly. Now it seems we get 100s of false alarms every day? Link to comment Share on other sites More sharing options...
Administrators Marcos 5,392 Posted January 19, 2022 Administrators Share Posted January 19, 2022 It is not a false alarm, the attack attempts are real. Currently it is not possible to have the communication evaluated by Windows firewall, however, we will consider improving this and allow and admin to create exceptions to reduce logging. Peter Randziak 1 Link to comment Share on other sites More sharing options...
kapela86 11 Posted February 7, 2022 Share Posted February 7, 2022 (edited) @Marcos This is definitely a BUG! It used to be that when I saw in ESMC that some IP was blocked by ESET then I immediately blocked it in Windows Firewall so it won't clobber ESMC Detections page. And it was working fine. BUT, some time ago on, maybe after I migrated to ESET Protect and updated ESET File Security to ESET Server Security, or maybe after a Windows Update, I don't know what changed, but now it looks like eset filtering mechanism is "before" windows firewall and it doesn't matter if I block ip in firewall, eset will still detect connection and block it and now my Detections page is garbage filled with EsetIpBlacklist entries. I confirmed that Windows firewall is working (I added my home ip to test and it blocked connection right away). Can you take a look at it and fix it? Edited February 7, 2022 by kapela86 Link to comment Share on other sites More sharing options...
Administrators Marcos 5,392 Posted February 7, 2022 Administrators Share Posted February 7, 2022 What about creating and IDS rule that will suppress logging of blocked communication from blacklisted IP addresses as follows? This would prevent the log from being clobbered by ESETIPBlacklist records if such communication is blocked by ESET. Link to comment Share on other sites More sharing options...
kapela86 11 Posted February 7, 2022 Share Posted February 7, 2022 I don't really want to use this kind of workaround, it's not like I don't want any logs from EsetIpBlacklist. Can you ask the devs if they changed anything regarding this? What I mean by that is did they change ESET IP Blacklist filtering/detection so it happens before network traffic hits Windows Firewall? I'm pretty sure that is the problem. Link to comment Share on other sites More sharing options...
Administrators Marcos 5,392 Posted February 7, 2022 Administrators Share Posted February 7, 2022 1 minute ago, kapela86 said: I don't really want to use this kind of workaround, it's not like I don't want any logs from EsetIpBlacklist. Can you ask the devs if they changed anything regarding this? What I mean by that is did they change ESET IP Blacklist filtering/detection so it happens before network traffic hits Windows Firewall? I'm pretty sure that is the problem. They haven't changed recently anything with regard to the order of filtering. In the past we had to make some changes for compatibility reasons. This is also a reason why we don't plan to change the order back which would likely cause compatibility issues to return. Link to comment Share on other sites More sharing options...
kapela86 11 Posted February 7, 2022 Share Posted February 7, 2022 But something did change recently, here's probably another recent post related to this problem: Can you escalate this somewhere higher so we can know what is going on? Link to comment Share on other sites More sharing options...
Administrators Marcos 5,392 Posted February 7, 2022 Administrators Share Posted February 7, 2022 Please open a support ticket then. I received the information from the firewall developer directly, Link to comment Share on other sites More sharing options...
kapela86 11 Posted February 7, 2022 Share Posted February 7, 2022 For the time being I created that IDS rule and created a ticket on polish eset website (01001217) Link to comment Share on other sites More sharing options...
kapela86 11 Posted February 22, 2022 Share Posted February 22, 2022 I have received response from devs Quote Our developers have already provided us with a response: To better explain why this is happening:EES filters network traffic at various points: 1. - when a connection is being established (this is evaluated before windows firewall) 2. - when there are some data being transmitted over already established connection (this is evaluated after windows firewall) We are not going to change order of those filters with regard to windows firewall, since it could cause compatibility issues. I'm still trying to make them change their mind or add some form of fix. Link to comment Share on other sites More sharing options...
Administrators Marcos 5,392 Posted February 22, 2022 Administrators Share Posted February 22, 2022 ESET filters network traffic at various points: 1. - when a connection is being established (this is evaluated before Windows firewall) 2. - when there are some data being transmitted over already established connection (this is evaluated after Windows firewall) We used to have only the (2) and decided to add (1) later. We are not going to change order of those filters with regard to windows firewall, since it could cause compatibility issues (we already had issues regarding IPSEC connections because of the order of evaluation). However we'd like to understand your scenario. a) It looks like that you don't want additional protection at layer (1). Is this correct? b) Currently there is no way to distinguish if an event is from layer (1) or (2). Are you willing to give up using protection from layer (1)?. If yes, then we might consider providing a way how to distinguish events from layer (1) and (2), so that you could allow/not log those from layer (1). c) If you want to be just protected, you can set an IDS exception to stop logging EsetIpBlacklist detections. The detections will be blocked anyway, so you will be protected. Is this a viable solution? d) You want to create a MS firewall rule for each IP address that Eset blocks and you don't want to see those IP addresses in Eset logs. We propose a workaround, to create Eset IDS exception for each IP address that you block in MS firewall. Is this a viable solution? Link to comment Share on other sites More sharing options...
kapela86 11 Posted February 22, 2022 Share Posted February 22, 2022 Thanks, now I know why this is happening, why didn't you say so from the start? a) Not correct, I want it. b) I'm not willing to give up protection from layer 1, but if you could add some way to distinguish them and configure logging options for them, then that would be a possible solution. c) I'm using this solution when you provided it February 7-th d) Well it doesn't matter for me if it's Windows Firewall or Eset Firewall (I know there is no such thing in Server Security) so I could use that. You are talking about adding those IP here: Link to comment Share on other sites More sharing options...
Recommended Posts