Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


rainmakerraw last won the day on December 30 2018

rainmakerraw had the most liked content!

Profile Information

  • Location

Recent Profile Visitors

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

  1. Hello again Peter. It seems you replied to me twice today? I don't think OS X (as it was) ever had iptables; I think perhaps you meant ipfw? Alongside pf, that is also from *BSD. If the utun interface is not ignored, I would be interested in how a deny all in/out rule on the Public profile (to which the utun1 IP is assigned) can result in all ports being open to the internet over utun1. A bug perhaps? Interesting that Eset considers Mac users would find virtual interfaces too confusing, but they're visible in the Windows version haha. As for being more polite and diplomatic, I'm
  2. Hi Peter, I downloaded the latest version and installed it for testing as requested. With all due respect this is a brief ad-hoc test to check whether things have improved since my experience with the previous version. With that in mind this is just a quick note of my experiences, sans my usual fully referenced, stated-methodology and formatted results etc reporting. That said... Unfortunately, Eset Cyber Security Pro still has no fully manual/policy mode, unlike the Windows version, so I left the mode set to automatic with exceptions. Three zones were then set up: Pretty s
  3. 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.
  4. 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 speci
  5. BTW here's five minutes of logs from Comodo Firewall to compare with a similar period from Eset IS in the OP:
  6. 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
  7. 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.
  8. 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
  9. 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).
  10. 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 th
  11. 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,
  12. 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: - 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.
  13. 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 capa
  • Create New...