rainmakerraw 4 Posted November 5, 2018 Share Posted November 5, 2018 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. Link to comment Share on other sites More sharing options...
rainmakerraw 4 Posted November 6, 2018 Author Share Posted November 6, 2018 (edited) 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. Edited November 6, 2018 by rainmakerraw Link to comment Share on other sites More sharing options...
ESET Moderators Peter Randziak 1,152 Posted November 22, 2018 ESET Moderators Share Posted November 22, 2018 Hello @rainmakerraw we have our own implementation of the Personal firewall feature. The latest version released has the Personal firewall refactored, you can download it here: https://forum.eset.com/topic/17531-eset-cyber-security-pro-and-eset-cyber-security-hotfix-version-673000-have-been-released/ Can you please try it with it and share your feedback with us? Thank you, P.R. Link to comment Share on other sites More sharing options...
rainmakerraw 4 Posted November 23, 2018 Author Share Posted November 23, 2018 12 hours ago, Peter Randziak said: Can you please try it with it and share your feedback with us? Thank you, P.R. 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 Link to comment Share on other sites More sharing options...
ESET Moderators Peter Randziak 1,152 Posted November 23, 2018 ESET Moderators Share Posted November 23, 2018 Hello Lee, thank you for your very detailed and technical-wise feedback. I consulted it with our macOS support specialist and I will open a ticket with the devs to check it. Thank you, Peter Tracking note for us: P_ECS6M-2686 Link to comment Share on other sites More sharing options...
ESET Moderators Peter Randziak 1,152 Posted November 23, 2018 ESET Moderators Share Posted November 23, 2018 Hello Lee/ @rainmakerraw, GUI configuring system firewall vs. own implementation: we implemented our firewall on OS X 10.6 which did not contain yet "pf", it has "iptables" as well as BSDs so that's why our firewall is ours. When it comes to VPN, the main priority in FW implementation were always the local processes. Interface "utun" is not ignored, but hidden in GUI and that's because common mortal users would be confused by such interface in our GUI. Btw. the development continues so we will for sure introduce further improvements, in case you have any ideas how to improve it, just share them with us. P.S. Please try to be more polite / diplomatic in the future posts. Thank you, P.R. Link to comment Share on other sites More sharing options...
rainmakerraw 4 Posted November 23, 2018 Author Share Posted November 23, 2018 2 hours ago, Peter Randziak said: Hello Lee/ @rainmakerraw, GUI configuring system firewall vs. own implementation: we implemented our firewall on OS X 10.6 which did not contain yet "pf", it has "iptables" as well as BSDs so that's why our firewall is ours. When it comes to VPN, the main priority in FW implementation were always the local processes. Interface "utun" is not ignored, but hidden in GUI and that's because common mortal users would be confused by such interface in our GUI. Btw. the development continues so we will for sure introduce further improvements, in case you have any ideas how to improve it, just share them with us. P.S. Please try to be more polite / diplomatic in the future posts. Thank you, P.R. 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. Link to comment Share on other sites More sharing options...
ESET Moderators TomasP 317 Posted December 10, 2018 ESET Moderators Share Posted December 10, 2018 On 11/23/2018 at 3:54 PM, rainmakerraw said: 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. Hello, Not at all - actually, your observations and comments helped us find and fix a bug in our product. We do value the efforts you put in this and our development team is sending their thanks. Also, sorry for such delayed response, Peter was out of office for the past two weeks and I did not get to this sooner. Regards, Tomas Link to comment Share on other sites More sharing options...
Recommended Posts