4 ms·

> Does WF allow you to restrict which programs can be bind to a given port? Yes. > This [0] doesn't make it seem like it can Indeed. Also check out the cmdle

by useerup 11y ago

> Does WF allow you to restrict which programs can be bind to a given port? Yes. > This [0] doesn't make it seem like it can Indeed. Also check out the cmdlets of the PowerShell NetSecurity module: gcm -mod netsecurity Basically a rule can filter on any combination of local/remote IP/port, user/account/group, program/path, service, interface type (wireless/wired...), profile (domain/public/private/...), protocol and and more. > [1] Though -frankly- it's not the best intro to that UI that I've ever seen No, it's pretty bad. :-) Not even a screenshot.

mschuster91 11y ago
Hate to say it, but out of the box Windows has the most flexible firewall compared to OS X and Linux. Neither platform can deny/allow traffic by the process full path (a Unix app can spoof its process name shown in ps/top) or in a GUI... at least one thing Windows got right.
- simoncion 11y ago
  > Hate to say it, but out of the box Windows has the most flexible firewall compared to OS X and Linux. 1) Why would you hate to say it? If a tool is good, it's good. :) 2) Maybe the Windows Firewall GUI only exposes a tiny sliver of the functionality, but it's reasonably possible [0] to make really complex iptables rules. :) [0] "Reasonably possible" as in, iptables provides the tools required to manage a fair bit of complexity.
  - simoncion 11y ago
    Ugh. 16-hours later follow up comment (because I accidentally a couple of entire sentences): Maybe the WF GUI only exposes a tiny sliver of what you can do with WF, but WF seems really limited when compared to iptables. It seems that the only thing you can do in WF that you can't do in stock iptables is refuse to direct IP traffic to (or from) a given program on the system.
    - mschuster91 11y ago
      Actually my usecase is to deny all traffic except for special applications - I'm often on mobile/tethered connections so I only want my browser but not crap like automatic updates or other background tasks to eat up my bandwidth. Impossible on OS X and Linux without shelling out $$$.
      - simoncion 11y ago
        > Impossible on OS X and Linux without shelling out $$$. I've never used it, so I can't endorse it, but this was among the first results in a google search for "linux per application firewall": http://douaneapp.com/ http://douaneapp.com/ I guess there has been progress in this space since you last looked. There is also SELinux controls that can be used... so -IIRC- you could create a per-app firewall with that. :) I would be slightly surprised if there weren't pretty reasonable GUIs for managing such SELinux rules.
simoncion 11y ago
> 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...

by useerup 11y ago

mschuster91 11y ago

Hate to say it, but out of the box Windows has the most flexible firewall compared to OS X and Linux. Neither platform can deny/allow traffic by the process full path (a Unix app can spoof its process name shown in ps/top) or in a GUI... at least one thing Windows got right.

simoncion 11y ago
> Hate to say it, but out of the box Windows has the most flexible firewall compared to OS X and Linux. 1) Why would you hate to say it? If a tool is good, it's good. :) 2) Maybe the Windows Firewall GUI only exposes a tiny sliver of the functionality, but it's reasonably possible [0] to make really complex iptables rules. :) [0] "Reasonably possible" as in, iptables provides the tools required to manage a fair bit of complexity.
- simoncion 11y ago
  Ugh. 16-hours later follow up comment (because I accidentally a couple of entire sentences): Maybe the WF GUI only exposes a tiny sliver of what you can do with WF, but WF seems really limited when compared to iptables. It seems that the only thing you can do in WF that you can't do in stock iptables is refuse to direct IP traffic to (or from) a given program on the system.
  - mschuster91 11y ago
    Actually my usecase is to deny all traffic except for special applications - I'm often on mobile/tethered connections so I only want my browser but not crap like automatic updates or other background tasks to eat up my bandwidth. Impossible on OS X and Linux without shelling out $$$.
    - simoncion 11y ago
      > Impossible on OS X and Linux without shelling out $$$. I've never used it, so I can't endorse it, but this was among the first results in a google search for "linux per application firewall": http://douaneapp.com/ http://douaneapp.com/ I guess there has been progress in this space since you last looked. There is also SELinux controls that can be used... so -IIRC- you could create a per-app firewall with that. :) I would be slightly surprised if there weren't pretty reasonable GUIs for managing such SELinux rules.

simoncion 11y ago

> 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...