Jump to content

rainmakerraw

Members
  • Content Count

    15
  • Joined

  • Last visited

  • Days Won

    1

rainmakerraw last won the day on December 30 2018

rainmakerraw had the most liked content!

Profile Information

  • Location
    U.K.

Recent Profile Visitors

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

  1. rainmakerraw

    Firewall engine

    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 an autistic person and didn't realise I wasn't being so. I went to considerable trouble to test this issue for you on my own time and my own machines, with nothing to gain from it except to help you. That was my only intention and I apologise for any offence or inconvenience. I stand by my comments that enabling file sharing et al. on a public interface is very bad policy, however. I think perhaps I've outlived my usefulness on the forum in that case. I will just stick to pf. Best wishes with your future versions.
  2. rainmakerraw

    Firewall engine

    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 self-explanatory. 'Home' zone for the physical ethernet LAN subnet, 'WireGuard' zone to cover the VPN tunnel on utun1 (which brings a public ipv4 address to the local machine, hence the need for strict local firewalling), and 'VPN' as a catch-all for any other VPN address (IKEv2, WireGuard, OpenVPN) which all providers I use issue in the 10.0.0.0/8 range. As with the previous version, the zones required explicitly specifying as Eset still doesn't pop up a network detection dialogue when a PAN interface (eg utun1) makes a connection. Indeed, even with these zones specified and the interface being up, the app still doesn't know it's there: Alas, this could just be a GUI quirk. That said I noted that in the firewall settings under Interfaces only physical interfaces (Ethernet, Bluetooth, Wireless etc) are listed. We'll go on to the rules, set them as desired and test: The first annoyance is that default profiles can't be deleted. I only want Home and Public as I either trust a network or I don't - and if any other situation ever presented (eg in a hotel with my MacBook Pro) I'd make a custom profile for it to suit. So I pretend Work doesn't exist and go to modify the Public rules to allow specified traffic inbound on the utun1/WireGuard (public IP) interface. All traffic is allowed outbound by default (which is fine), so it's not much of a test if we don't add more rules and see how they perform. I was shocked to see that the Public profile, by default, allows inbound traffic for all pre-existing rules including file sharing, screen sharing and so on. Seriously? On a public network? 🤪 That's purely idiotic opsec, and honestly you ought to find the person responsible and give them a shoeing. Those rules were summarily unchecked (it's impossible to delete them). I added a rule for Transmission (torrent client), to allow inbound traffic on port 26968 for the Public profile only. The app itself confirms the port is now open, and canyouseeme.org also confirms it can see the service (via my WireGuard public IP on utun1). 'Great', I think, 'the firewall must work properly now!'. Not quite. You see, changing the incoming port in Transmission to any random number also shows the port is open on the public (WireGuard/utun1) interface. In fact, all ports. That's weird, maybe I borked something adding the rule. So I even went so far as to delete the Transmission rule add then add a total deny all (in and out) rule for the Public profile. I confirmed the changes, exited from the Eset GUI and restarted Transmission. Guess what? It's still accepting traffic on any port. In fact on further inspection the whole machine was open over utun1 via its public IP to the entire internet. That is beyond serious. NB: In the above image I'd simply incremented the port used by 1. At first glance they may look the same - 26968 vs 26969. There was NO rule in Eset's list to allow this traffic, on any profile. In fact at the time this screenshot was taken, the 'deny all in and out' rule was in force! I'd also checked the option to log all blocked connections. The physical LAN (192.168.0.1/24 on en0) is of course protected by a hardware edge router and firewall (self-built), so no incoming connections reach that interface. The virtual/PAN interface utun1 is - as discussed above - wide open to the internet with a public IPv4 address. Despite this, and the deny all in and out rule, only two log entries ever showed up in the Eset Log Viewer - both random ICMP blocks. No other traffic was blocked, or logged. Port scans confirmed the machine was open to the internet despite Eset having a rule to deny all in/out (all traffic types) from the entire internet. Once this was confirmed and repeated (to verify), I quickly enabled pf again. Instantly my pf logs started filling with blocks from public IPs all around the world hitting my machine over utun1 (as you'd expect for any public facing node on the internet). So it's not as if there was no inbound traffic to block - Eset just couldn't see it. This is an extrapolation from my pf log after just a minute of it being re-enabled: In summary, in its present form the firewall is unusable at best, and misleading and dangerous at worst. It proclaims protection and displays reassuring green checkmarks, accepts lists of in-use subnets and IPs to be protected, but then silently doesn't actually obey rules because it either can't see or doesn't filter PAN/virtual interfaces. This would leave a less savvy user wide open to rootkits, local network penetration, or worse. Especially with the recent explosion in popularity of VPN services with worried every-day internet users and consumers. I respectfully suggest you make end-users aware of this issue and issue a fix pdq. Best wishes, Lee
  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 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!
  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 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.
  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 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.
  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. Ah, I see. Thanks itman, I'll give that a try and report back.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
×