In pf, for example, you can "allow in quick state 'related'" but "drop in quick state 'new'". ![]() It's just that its state is 'new' rather than 'established' or 'related'. 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. ![]() In the absence of explicit firewall rules to allow select inbound non-stateful Internet traffic, the inbound connections will be automatically dropped. It would be a pretty useless firewall that could only block or monitor inbound traffic you'd already requested, no? hehe. 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 will only monitor inbound Internet activity for which a previous outbound connection was made. Off the top of my head, I would say it has to do with the fact the Eset firewall is stateful. Some words (to clarify local vs remote ports). Are hackers/bots really that clever now, which I doubt or is Eset not set up correctly (or working improperly)?Īny feedback welcome, whether on my ruleset, the 'issue' or both. 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. 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:Īs you can see, many more port variations (that log shot was taken after literally a couple of minutes from empty). Not a single other local port ever gets blocked, which is weird. ![]() There are never any exceptions to this, except one or two port scans a day (which is to be expected). 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). I don't need any application specific rules except one allow in rule, so the 'interactive' mode was far too messy for me. 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. ![]() Mostly the usual suspects like 22, 23, 53, 80, 443, 8080, 3389 etc, with attempts from a multitude of IPs/countries. 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. 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). 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. I have a paid WireGuard VPN subscription which provides a static/public IPv4 address.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |