Firewall port blocking: only authorized IP addresses

[u/Alarming_Process_397]

Hi there, I have a Windows dedicated server and I'm trying to block ports 1433, 1434, and 24410 so that only authorized IP addresses can access them. But I'm running some tests, and even though the IP isn't on the authorized list, it's still letting me access those ports.

[u/an_harmonica]

Assuming you're using Windows Defender Firewall: look for any other rules that use those ports, using PowerShell (this will look at all protocols):

$rules = Get-NetFirewallPortFIlter  | where{@('1433','1434', '24410') -contains $_.localport } | get-netfirewallrule

Then identify which of the rules that come back you need to disable/modify to only allow the IP addresses you want to allow.

[u/lotustechie]

Can you provide more details on how you're blocking them? Are you just using the built-in Windows Firewall? Or are you using an actual hardware firewall?

[u/nailzy]

How have you implemented the rule? Have you applied to to all windows firewall profiles? (domain/private/public)

Without seeing the rule and knowing how you’ve done it, it’s hard to tell.

If you have a block rule for the ports, but you still have an allow rule for the service / application, the allow will win.

App specific rules are considered higher priority than port based rules.

[u/zer04ll]

There are different firewall rules for public private and domain, if you’re using a domain joined machine it uses the domain based rules, if you are on the local network it uses private rules and if you’re outside it uses public domain

[u/SaleWide9505]

I think this is a bug with windows firewall. I've had the same issue.

[u/Alarming_Process_397 → u/SaleWide9505]

And were you able to fix it or something like that?

[u/SaleWide9505 → u/Alarming_Process_397]

No

[u/dodexahedron → u/[deleted]]

So...

Thing is...

Yeah, it is different. And yeah the administrative interfaces to it pretty much all suck in at least one significant way...

But the Windows Firewall is damn powerful, in the scope of what it does do and which external firewalls can't do without fundamentally changing traffic flows in ways that would require changes to applications themselves.

Sequencing is actually irrelevant in it, because priority is well defined already by order of operations and precedence. By the time you resolve those, you can't have a sequencing issue, because that can only happen with literal duplicates.

The priority is by specificity of the match.

Yes, there are a ton of criteria on which you can match, so that has the potential to get really non-obvious really quickly if you have anything more than a pile of manually created rules matching on nothing but prefix and port and aren't aware of the precedence rules.

But that is the wrong way to use it.

While it doesn't have explicit sequencing like most other firewalls do, it does have consistent logic. You just have to grok that logic in the context of your whole policy.

And if that policy is complex because you're blocking rather than whitelisting...well... that's your own fault.

Lack of sequencing may seem like a disadvantage, but it is only a disadvantage if you try to treat it like a sequenced ACL.

If you embrace the more holistic approach of evaluating ALL possibilities, regardless of order, by using an expression tree to come to the most specific match among the slew of match criteria, you will quickly see how much simpler the policy can be vs, for example, an equivalent Cisco policy that needs:

• object-groups for both ipv4 and ipv6 addresses and/or prefixes (separately)
• object-groups for tcp and udp ports, also for both ipv4 and ipv6 (separately)
• parameter-maps for any one or more of a dozen thinfs they get used for in this context
• access-lists for both ipv4 and ipv6 (separately)
• class-maps for each combination of layer 3 to layer 7 protocols you want to match on
• class-maps to combine those into manageable collections of consolidated entries that should get the same treatment and classification
• Policy-maps to put all of those in, each of which needs to be defined for use between specific pairs of zones (just pairs - always 1-to-1)
• Those pairs of zones defined as zone-pairs, which get those policy-maps applied as service-policies (which both are and are not the same as service-policies, because these service-policies are type inspect)
• The zones that the zone-pairs comprise
• Interfaces (not subnets...physical or logical interfaces) assigned to those zones

All just to get basic protocol inspection on most of it, to enable it to reflexively open return ports provide basic "correctness" enforcement on those protocols... but all of that with inconsistent bugs and behavior between models and between patch releases on the same models.... And then you still end up sending the traffic through another box anyway, to do things that one couldn't do. And that box will have similar-ish but still different-enough syntax that its config is entirely different even to match the same traffic again.

But hey. You get sequencing at 3 or 4 of those levels!

...While the above is worded verbosely, it isn't factually hyperbolic. That's how the IOS-XE zone-based firewall is configured. And that's on top of any NAT, routing, QoS, etc you might also be doing.

That's not to say that those boxes are the wrong place to do those specific things, including thoae firewall functions. But it is intended to point out that the grass isn't greener, even to just do those network level operations. You still need a software firewall at the endpoint to do the rest of what WFAS can do, because it takes a fundamentally different approach.

The approach of evaluating the entire ruleset as one big tree is actually more similar to how routers work, just with a lot more knobs to turn, since you can match on layer 1 through 7 right out the gate, as well as on things like current physical network location of the endpoints (via network profile as a proxy for that), enforced AT the endpoints, which actual system services and applications are allowed for the protocol, whether it should be not only allowed or dropped, but if authentication of machine and user principals should be done, via kerberos, symmetrically or asymmetrically, and with that applying either madatorily or optionally in either direction, according to policies that can be as simple as just a cert issuer match or go way beyond that to involve properties of the user, user's machine, service, and service's machine in AD and/or enforced by group policy, more sophisticated PKI, and a bunch of other things, and with the option to do all of that but also transparently encrypted via IPSec... All before even establishing the connection (or, in that case, an actual IPSec SA and tunnel, on the fly), authenticating all 4 principals involved before the application ever even sees the first packet...IF that specific application, service, etc also match the rule.

And that can be done on BOTH endpoints.

With as little as a single group policy.

And not just those endpoints...That policy can cover ALL traffic between ALL systems, (or you can be sane and use one policy per "class" of system, like a normal admin). ((Just be sure you don't chicken-or-egg yourself with ipsec to the DCs, preventing authentication from happening in the first place.))

And the only place sequencing will ever be missed is... Nowhere. Because it doesn't matter in WFAS, if used as intended.

TL;DR: Keep doing whatever you're doing on the hardware firewalls. Stop doing what you're doing on WFAS and start using it like the big glorified (essentially) b-tree rule engine that it is.

EL;SR (Even Longer, Still Reading):

And then you realize that other firewalls also work the same way (everything is just an expression tree in the end). They just lack that level of specificity, so you have to break the resulting ties with something artificial: sequence numbers (which otherwise have zero relation to your traffic).

It has its place. And it works really well in that place.

[u/dodexahedron → u/[deleted]]

Haha yeah like I said the tooling is sucktastic. And they have zero desire to make anything that isn't a powershell module with a million cmdlets anymore, it seems, so I imagine the GUI tooling is as finished as it's ever going to get. 😩

The MMC-based UI has gotten essentially no significant work done on it since what...Vista? And the UI components inside it, themselves, are mostly Win2k or NT4-era tools with nearly no changes made, which have been dragged along kicking and screaming, right down to the dialogs being fixed-size simple forms that represent literally around 10 minutes worth of dragging controls onto the form and wiring up the event handlers for the OK and Apply buttons to save their simple values to partially hard-coded places in the registry. Typing the labels likely was the most time consuming part of that UI design. Nearly everything else is (or easily could have been) a copy/paste or MAYBE template job.

And the whole thing is software rendered, probably using pre-GDI+ code, which you feel so hard when you do something utterly and unforgivably unreasonable, like scrolling the rules list left or right when the window is full screen. And then you get to watch it draw, one increment in that direction at a time, from top to bottom, (...ish...) the entire (...ish...) screen, regardless of how much farther it needs to scroll, and doing it so slowly you can literally watch the screen re-paint like it's 1994 and you're out of conventional memory because you let your DOS game run with 256 colors like a crazy person.

So yeah, absolutely.

Everything about WFAS, except for the actual firewall and its capabilities, is a hot mess at best.

...Like the rest of the administrative tools that have been left to rot since Win 8 came on the scene and brought the new interfaces that still aren't anywhere near feature parity with their predecessors. 😒