Jump to content

rainmakerraw

Members
  • Content Count

    13
  • Joined

  • Last visited

Profile Information

  • Location
    U.K.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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!
  3. BTW here's five minutes of logs from Comodo Firewall to compare with a similar period from Eset IS in the OP:
  4. 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.
  5. Interesting. No blocked ports or traffic mentioned but a few of these: 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.
  6. 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.
  7. 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).
  8. Ah, I see. Thanks itman, I'll give that a try and report back.
  9. 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.
  10. 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.
  11. rainmakerraw

    Firewall engine

    Never mind. I tested it anyway and unfortunately the firewall has more holes than Swiss cheese. It doesn't recognise virtual interfaces (eg utun), so even when connecting to a WireGuard VPN interface/server (for example), Eset doesn't notice. Even when manually setting the rules and zones like this: 10.0.0.0/16 - Public - Block all incoming {Public IP} - Public - Block all incoming Once the tunnel is established (with a static public IPv4 address at the server end), all ports on the local machine are open to the internet, even with Eset running and configured to block everything. Seriously, seriously bad. I'll stick to Murus/pf then.
  12. rainmakerraw

    Firewall engine

    I'm a long time user of pf on BSD and macOS, and iptables on Linux. I get very frustrated by the firewall availability on Windows machines, as they're generally nowhere near as fine-grained or powerful as *nix offerings. Eset's Internet Security finally gave me the control I desired; namely per-interface/IP zones and rules, to easily allow application-specific traffic over VPN interfaces but not the LAN/ISP etc. It even now has a top-to-bottom ruleset like pf. Nice! On my MacBook Pro I currently use the excellent built-in pf firewall, with Murus Pro acting as front-end. I'm more than capable of writing pf rulesets/conf files by hand, and always double-check the resulting pf.conf before pushing it into production, but a GUI is quicker to generate the initial config so whatever. My question is, does Eset's Cyber Security Pro for Mac utilise macOS' underlying pf, or does it use a custom engine? I'm really hoping it just acts as a GUI front-end for pf, as it's such a feature rich, powerful and battle-tested firewall there's no real reason to change it. Eset do make a nice GUI (and excellent AV) though, so that'd be icing on the cake. I did do a search before posting, but the one topic I saw asking this and a few other questions had all questions answered but this (most important!) one. Thanks in advance.
×