Firewall logs (only ever one public port blocked)

[rainmakerraw 4]

I have a paid WireGuard VPN subscription which provides a static/public IPv4 address. This means I can open up a virtual interface on any local machine to the internet for whatever reason, and keep my main (real) network locked down. On my MacBook Pro I have the native BSD-derived pf set up as the firewall, and on my various Linux boxes I have netfilter (via Shorewall or UFW). When using my public IP VPN on any of those machines, the firewall logs show blocked connections from many random IP addresses hitting lots of random local ports. Mostly the usual suspects like 22, 23, 53, 80, 443, 8080, 3389 etc, with attempts from a multitude of IPs/countries. As you would expect.

On my Windows 10 box I have Eset IS v12 set up in policy mode, because it was much easier (and more 'native' to my usual pf/iptables way of thinking) to set up that way. I don't need any application specific rules except one allow in rule, so the 'interactive' mode was far too messy for me. The ruleset looks like this:

However, for some reason my Eset logs only ever show hundreds of attempts from dozens of random public IPs to my local port 3389 (RDP). There are never any exceptions to this, except one or two port scans a day (which is to be expected). Not a single other local port ever gets blocked, which is weird.

When I'm running the same virtual public IP on my Mac, Linux or BSD machines, the firewalls are always full of logs like this:

As you can see, many more port variations (that log shot was taken after literally a couple of minutes from empty). So, why is Eset apparently only blocking attempts on port 3389? If it's hiding the machine and ports from the wider internet, would they know it was a Windows machine? Surely at least one or two bots would be trying random ports like 22, 80 etc even if most did focus on 3389 (if, as I said, they knew it was a Windows host)? To switch the IP to a *nix machine and instantly see many blocks across the port range is a little concerning. Are hackers/bots really that clever now, which I doubt; or is Eset not set up correctly (or working improperly)?

Any feedback welcome, whether on my ruleset, the 'issue' or both. Thanks in advance.

Edited November 16, 2018 by rainmakerraw
Some words (to clarify local vs remote ports).

[itman 1,659]

Off the top of my head, I would say it has to do with the fact the Eset firewall is stateful. It will only monitor inbound Internet activity for which a previous outbound connection was made. In the absence of explicit firewall rules to allow select inbound non-stateful Internet traffic, the inbound connections will be automatically dropped. The previous is evidenced by looking at the default Eset firewall rules. Of note is there is no default rule at the bottom of the rule set that explicitly blocks all inbound traffic.

In my case, I use a router that deploys a stateful firewall. So all unsolicited inbound traffic is dropped at the network perimeter.

Edited November 17, 2018 by itman

[rainmakerraw 4]

54 minutes ago, itman said:

Off the top of my head, I would say it has to do with the fact the Eset firewall is stateful. It will only monitor inbound Internet activity for which a previous outbound connection was made.

That's not what stateful means. Both pf and netfilter are stateful too. I suspect what you were trying to say is not that Eset only monitors inbound traffic for which there is an originating outbound request, but rather that it only allows inbound traffic for which there was a corresponding outbound request? If you did indeed mean it how you said it, and was offering that as explanation for the lack of logs and blocking, then I'm afraid that's not correct. It would be a pretty useless firewall that could only block or monitor inbound traffic you'd already requested, no? hehe.

In the absence of explicit firewall rules to allow select inbound non-stateful Internet traffic, the inbound connections will be automatically dropped.

Unsolicited inbound traffic is still statefully managed, as 'stateful' simply relates to the behaviour of the firewall and has nothing to do with the traffic itself. It's just that its state is 'new' rather than 'established' or 'related'. In pf, for example, you can "allow in quick state 'related'" but "drop in quick state 'new'". Even so, that kind of proves my point. Since all inbound traffic lacking an originating outbound request should be blocked, surely my Eset log should have much more than just thousands of blocks for a single port; 3389?

The previous is evidenced by looking at the default Eset firewall rules. Of note is there is no default rule at the bottom of the rule set that explicitly blocks all inbound traffic.

One would assume that's because Eset's firewall is inherently default deny? Again, this should mean my Eset logs look the same as my pf and netfliter logs - not just containing entries for one port. In any case this is doubly so, as I wasn't sure how that would apply in policy mode (despite reading the entirety of the user guide). As you see, I added my own default drop rules for each interface (LAN/Ethernet, WireGuard and VPN) at the end of each policy subsection. This should be reflected in the logs, but isn't - hence the thread.

In my case, I use a router that deploys a stateful firewall. So all unsolicited inbound traffic is dropped at the network perimeter.

Given that WireGuard is a VPN protocol and deploys on a virtual interface on a per-machine basis, it doesn't even touch the edge router. It 'tunnels' past it. So all your edge router will see is an originating outbound request for traffic on port 51820 (in this case) and corresponding replies on 51820, which are then allowed due to matching 'state related' or 'state established'. The fact the local machine is set to use a virtual interface to branch that incoming traffic to local ports (similar to DNAT/port forwarding) is invisible to it. I also have a stateful firewall running on my edge router (self built and hand written), but if I open a WireGuard tunnel with a public IP endpoint every single port on my local machine is still open to the internet over that interface. The LAN/Ethernet interface (routed via 172.16.0.0/16 or 192.168.1.0/24 or whatever) is protected, and separate.

That's why my ruleset has profiles for Ethernet/Trusted, WireGuard and VPN - because all are separate networks as far as the firewall (and access to the machine) is concerned. For example my aforementioned edge router (2c4t G4560 @ 3.5GHz all core, 4GB DDR4, HardenedBSD, pf, btw) is set to block all inbound traffic and allow all outbound traffic. However, the moment I connect to the WireGuard endpoint, I can have a friend connect to $(my_vpn_IP):3389 using Windows Remote Desktop and boom, he's in my machine (assuming no local software firewall preventing this, of course - but that's the whole point of my thread, as Eset only seems to be blocking one thing!

My sincere apologies if you already knew all this and simply worded your reply badly (rushing or whatever), but just in case... Plus I hopefully made my query clearer for others too. Thanks for replying, and if you have any other insights I'd love to hear them as always. Nice chatting with you. 😀

 

Edited November 17, 2018 by rainmakerraw

[rainmakerraw 4]

I'd already edited my previous reply to tidy it up, and didn't want to do so again to add new information. Thinking more about it, I wonder whether the answer is not in the firewall per se, but rather in logging policy. It suddenly strikes me that perhaps the 3389/RDP blocks are defined by an Eset rule (and set to log) but my own policy rules are not logging by default, and hence not showing in the log? I'm going to remote back into the machine to have a look now (I'm on my MacBook Pro atm). If it turns out to be so simple I'll not be amused with myself lol.

Edit: Alas, no. I'd written the rules correctly the first time. Logging is indeed enabled (information, notify user) and the log currently has 4,924 entries from today - all on port 3389(!). They were blocked due to rule Deny IN on WireGuard from ANY to ANY. So it's not that.

Edited November 17, 2018 by rainmakerraw

[itman 1,659]

Eset's event logging has a few "quirks." Without getting into that, do this as a test. For one of your block rules that you feel you should be seeing Network log entries for, set the logging severity to "Warning." If you now start seeing Network log entries for that rule, set the logging severity likewise for your remaining block rules and your problem is solved.

[rainmakerraw 4]

Ah, I see. Thanks itman, I'll give that a try and report back.

[rainmakerraw 4]

No difference, unfortunately. In fact the log hasn't updated for over an hour. I finally got it to show something extra by initiating a port scan at grc.com/shieldsup - at which point Steve's IP was blocked temporarily and the log reflected a blocked TCP scan. It seems the logging with Eset is indeed... 'special'. *facepalm* It's a shame, because the app is absolutely great and I love the antimalware side also (I've used it on and off since NOD32 verson 2!). I'm tempted to move back to Comodo firewall and downgrade Eset IS back  to AV (I'm assuming my key will allow that).

[itman 1,659]

One last thing to check. See if Eset Troubleshooting wizard shows a non-zero count per the below screen shot:

[rainmakerraw 4]

It does indeed show a non-zero count, but on inspection it's mostly 3389 blocks with a few anomolies. The non-3389 entries relate to local processes (primarily dnscrypt-proxy and svchost.exe) outbound traffic. The error is no applicable rule, despite my policies having clear 'allow all out to anywhere from local addresses/lan subnet'. Weird, but everything still functions regardless. There are no troubleshooting entries for ports other than 3389. It's a headscratcher for sure. I did try to email Eset support (first via the app GUI itself and second via the website) and both times I got emails saying my ticket ID was invalid and to please use the app or the website form(!)... Not a great start to my first week back with Eset tbh lol.

[itman 1,659]

One more thing to check. Eset's firewall uses the Window Filtering Platform. Regardless of if the Network option to also use Windows firewall rules is enabled, elements of the Win Firewall are used.

In your Win Event log, check the Audit Failure log section for blocked network connections. My experience has been that anything blocked by the Eset firewall also shows in this log. Although I have also seen Win firewall blocks not related to Eset firewall blocks show there; especially at boot time. However, I also have the Eset option to use inbound Win firewall rules enabled.

Edited November 17, 2018 by itman

[rainmakerraw 4]

Interesting. No blocked ports or traffic mentioned but a few of these:

Code integrity determined that the image hash of a file is not valid.  The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.

File Name:    \Device\HarddiskVolume7\Program Files\ESET\ESET Security\ecmds.exe

The machine has an almost new Samsung Evo 970 Pro NVMe, scans clean for errors. I got the x64 installer .exe from Eset direct. I'll try a reinstall (my third as it happens) and see what happens.

[itman 1,659]

Ecmds.exe among other things is used to start the Eset GUI process. If that is not started or functioning properly, well a lot of things in Eset could be borked.

Another thing I strongly advise is you go to this web site: https://www.amtso.org/feature-settings-check-for-desktop-solutions/ and ensure Eset detects all the tests given there; especially the non-archive ones.

[rainmakerraw 4]

35 minutes ago, itman said:

Ecmds.exe among other things is used to start the Eset GUI process. If that is not started or functioning properly, well a lot of things in Eset could be borked.

Another thing I strongly advise is you go to this web site: https://www.amtso.org/feature-settings-check-for-desktop-solutions/ and ensure Eset detects all the tests given there; especially the non-archive ones.

I had removed Eset IS v12 completely and reinstalled NOD32 instead (as I was considering earlier). I added trusty old Comodo Firewall in custom ruleset mode (i.e. policy mode), with the benefit of its containment (auto sandbox) technology. Unfortunately one simply can't trust a firewall that fails to report it's working and doesn't log properly. Comodo is working perfectly and logging correctly, as always (for free, no less) and NOD32 blocked all the EICAR files in the link as you'd expect. Not the best solution (and not where I'll be spending my money next time) but at least now it works, and I get the benefit of Eset's antimalware engine. Thank you very much for your input, suggestions and tips. You are indeed a valuable member of this community. Have a good day/evening.

[rainmakerraw 4]

BTW here's five minutes of logs from Comodo Firewall to compare with a similar period from Eset IS in the OP:

[itman 1,659]

Well one issue with the Comodo firewall is it certainly isn't to specific in its source application identification. For me, Windows Operating System means possible two things. It's either what is referred to as "System;" i.e. ntoskrnl.exe or svchost.exe. Why you would be receiving that volume of blocked inbound connections from System is a mystery unless its NetBIOS related although the destination ports don't indicate that.

If you're satisfied with Comodo, by all means stay with it. 

[rainmakerraw 4]

2 minutes ago, itman said:

Well one issue with the Comodo firewall is it certainly isn't to specific in its source application identification. For me, Windows Operating System means possible two things. It's either what is referred to as "System;" i.e. ntoskrnl.exe or svchost.exe. Why you would be receiving that volume of blocked inbound connections from System is a mystery unless its NetBIOS related although the destination ports don't indicate that.

If you're satisfied with Comodo, by all means stay with it. 

That's true to a degree, but in my experience Comodo will give info down to application (or even component) level if something is there to be logged.

For example since there are no running servers or externally listening services on this box, the connection attempts are just random scans/spam/script kiddies trying their luck by knocking random ports. What application would you list for those 'empty' connection attempts, really? If I try to connect to your machine from the CLI on my BSD box over a random port, there's no receiving application on your end to be logged. 'Windows' is as specific as it needs to be. I've noticed that, for example, if I run Transmission (which has allow over $(wireguard_interface):55555 but deny all others type policy rules) I'll get logs showing blocks to C:\Program Files\Transmission\transmission-qt.exe from $(randomIP):1234 to $(banned_interface):55555, while the wg interface happily allows incoming connections from the wider network over its own public IP. So once there actually is a receiving service, it's logged appropriately. As another (shorter) example, 'Windows' becomes svchost.exe:3389 for RDP or whatever. That makes sense to me.

So far it seems that Comodo is the best of a bad bunch, imho, on Windows. There just aren't any truly powerful and fully functional firewalls like you'd find on Unix unfortunately (unlesss you know one I missed). Oh to have pf on Win! I'd happily stick to *nix only, which has far superior abilities and power for end-users; but I do need to maintain one Windows box (Enterprise 2019 LTSC in this case). So for now Comodo Firewall + NOD32 will have to suffice - but I'm always looking for the next improvement. If you have any suggestions (must have policy based abilities with network adapter level awareness and the ability to operate by zone/profile - i.e. multiple subnets/ranges with differing profiles simultaneously) then I truly am all ears. Thanks again!

[Marcos 5,074]

14 hours ago, rainmakerraw said:

BTW here's five minutes of logs from Comodo Firewall to compare with a similar period from Eset IS in the OP:

ESET does not log blocked communication by default. And in automatic mode, all non-initiated inbound communication is blocked.
Logging of blocked communication can be achieved by creating a general block rule with diagnostic logging severity that you put at the end of the rules list.

[rainmakerraw 4]

3 hours ago, Marcos said:

ESET does not log blocked communication by default. And in automatic mode, all non-initiated inbound communication is blocked.
Logging of blocked communication can be achieved by creating a general block rule with diagnostic logging severity that you put at the end of the rules list.

As per the OP Marcos, I'm in policy mode and diagnostic logging was already enabled. It was a clean install of Windows 10 x64 and I completely uninstalled and reinstalled Eset IS v12 three times to be sure.

[jun 0]

I apologise for posting here, but damn, I was about to post a topic for more info on eset firewall and I see this thread...

I was about to buy ESET Smart Security Premium and now I have doubts.
Currently I`m using eset antivirus with agnitum outpost firewall but as it`s being abandoned product for the last years I was hoping to replace it with already working combo in the face of ESSP.
What should I do now, face defeat and use comodo+ eset av or to jump on ESS...? I postponed this decision way too long and now I really need working solution.

Edited November 18, 2018 by jun

[itman 1,659]

18 minutes ago, jun said:

What should I do now, face defeat and use comodo+ eset av or to jump on ESS...? I postponed this decision way too long and now I really need working solution.

This thread pertains to a specialized and not the normal user run environment. The Eset firewall protection wise is more than adequate for the vast major of PC users including corp. endpoint users.