3 ms·

> No, it's pretty bad. :-) Not even a screenshot. I KNOW, RIGHT?!? ;_; > > Does WF allow you to restrict which programs can be bind to a given port? > Yes.

> No, it's pretty bad. :-) Not even a screenshot. I KNOW, RIGHT?!? ;_; > > Does WF allow you to restrict which programs can be bind to a given port? > Yes. So, I remembered that I had a Win 7 (Home Premium) VM lying around and spun that up and played around a bit with a server adapted from the server code found at [0]. It doesn't work as expected. It doesn't look like Windows does anything at all regarding preventing programs from binding to a particular port, and it also doesn't look like an Allow rule that points to a particular executable overrides a general Deny rule. [1] In brief: * Allow TCP/9999: OK. * Deny TCP/9999: Can bind, but don't get packets. Ok. * Deny TCP/9999, but Allow TCP/9999 when it's this particular program: Can bind (both the named executable and the same code with a different name), but don't get packets. Not Good. Regardless of Windows firewall settings, the first executable I start is the one that shows up as bound to the given socket in (Windows) netstat. Because of my inability to figure out why Windows's executable-based inbound per-port connection filtering wasn't working, [2] I can't test to see if I could DoS a legit daemon with this. Have you personally successfully used application-based inbound port filtering? [0] https://www.akkadia.org/drepper/userapi-ipv6.html https://www.akkadia.org/drepper/userapi-ipv6.html [1] Maybe this has something to do with the fact that I'm using Cygwin to compile straight C code into Windows executables, but it would be... somewhat amusing if you had to do something particularly special that the Cygwin shim wasn't doing in order to make Windows Firewall link up a particular .EXE to a particular bound port. (After all, netstat has no trouble figuring it out!) [2] And yeah, I made sure to cancel the Windows Firewall "This program is a server!" dialog and deactivate the automatic rules that got put into the Inbound Rules list once I started the little server for the first time.

useerup 11y ago
> It doesn't look like Windows does anything at all regarding preventing programs from binding to a particular port Correct. By default a program may bind, but inbound traffic is blocked. > and it also doesn't look like an Allow rule that points to a particular executable overrides a general Deny rule Correct. That's not how the fw is designed. By design a "block" rule are processed before "allow" rules [0] (although authenticated bypass rules are processed before block rules). There's an overall setting to allow or deny traffic not matching any rules. By default it is "block" for inbound and "allow" for outbound traffic. > I can't test to see if I could DoS a legit daemon with this I don't think you can. Perhaps if you could get in before the daemon (service)? > Have you personally successfully used application-based inbound port filtering? Yes. And I tested it with a small UDP server before I wrote my first post in this thread. When the server started I got a FW prompt that the program was trying to communicate. I canceled the dialog. The FW had now created a "block" rule for the server, blocking all inbound traffic. Yes, it showed up a bound to the port in netstat, but all traffic was blocked. [0] https://technet.microsoft.com/en-us/library/dd421709(v=ws.10).aspx https://technet.microsoft.com/en-us/library/dd421709(v=ws.10...

useerup 11y ago

> It doesn't look like Windows does anything at all regarding preventing programs from binding to a particular port Correct. By default a program may bind, but inbound traffic is blocked. > and it also doesn't look like an Allow rule that points to a particular executable overrides a general Deny rule Correct. That's not how the fw is designed. By design a "block" rule are processed before "allow" rules [0] (although authenticated bypass rules are processed before block rules). There's an overall setting to allow or deny traffic not matching any rules. By default it is "block" for inbound and "allow" for outbound traffic. > I can't test to see if I could DoS a legit daemon with this I don't think you can. Perhaps if you could get in before the daemon (service)? > Have you personally successfully used application-based inbound port filtering? Yes. And I tested it with a small UDP server before I wrote my first post in this thread. When the server started I got a FW prompt that the program was trying to communicate. I canceled the dialog. The FW had now created a "block" rule for the server, blocking all inbound traffic. Yes, it showed up a bound to the port in netstat, but all traffic was blocked. [0] https://technet.microsoft.com/en-us/library/dd421709(v=ws.10).aspx https://technet.microsoft.com/en-us/library/dd421709(v=ws.10...