Adjust Firewall Rules to Disallow Connections from LAN on Public Networks by Default

[Kytech]

The default firewall rule created by usbipd-win is marked to be active for all network profiles, though it is constrained to only allowing access to devices on the local subnet. This still leaves it possible for a malicious actor on the LAN of a public network to make connections to the usbipd port, which is not an ideal default configuration.

This can be mitigated by making the firewall rule created by usbipd only active on domain and private profiles. The issue of the vEthernet (WSL) interface being given a status as an unknown network, thus always being assigned the public firewall profile and leading to a blocked connection with the public profile disabled in the rule, can be avoided by creating another firewall rule that is identical to the standard usbipd rule as it exists now (active for all profiles) with one adjustment. The WSL version of the rule can be restricted to only applying to traffic that comes from the WSL network interface. Restricting a rule to the wsl interface can be done with the following PowerShell command when a WSL distro is in a running state:

Get-NetFirewallRule -DisplayName "usbipd - WSL" | Get-NetFirewallInterfaceFilter | Set-NetFirewallInterfaceFilter -InterfaceAlias "vEthernet (WSL)"

The -DisplayName parameter could be replaced with -Name to reference the rule by it's GUID as well.

This adds an additional firewall rule, but it provides a more secure default, preventing access by untrusted devices on the LAN of a public network, without breaking the connectivity for WSL.

Thanks again for your work on this fantastic tool!

[Kytech]

Ideally, if we could just set the vEthernet (WSL) interface to be considered a private connection, this wouldn't even be needed, but there presently isn't a reliable method for doing this in WSL2 as of right now.

[dorssel]

@Kytech Thanks for the report/feature request.

But its more complicated than that: the same (default public) is true for Hyper-V internal switches, VMware networks, VirtualBox networks, etc. And then there is 3rd party firewalls, some of which (try to) follow the MS firewall rules (but never 100% accurately). And then there are 7000+ users, the majority of which have no clue and file an issue here like "it doesn't work".

Long story short: there is the generic comment in the README that you can tighten this down if you want to. Most people are probably in a private zone (behind a home or work firewall). Maybe if you want to use this in your hotel room "protected" only by the hotel WiFi without any sort of VPN. Oh well...

I will leave this issue open for others to find. Maybe it will end up in the wiki at some point. This is not going to change anytime soon.

PS: About security: I can tell you things about VBoxUsb (the driver from VirtualBox that this software uses), but it would not conform to "responsible disclosure". I am afraid that adding any further security features are in vain and would only provide a false sense of security...

[mitll-darby]

According to netstat, the server listens on 0.0.0.0:3240. Is there a way to constrain the IP address the server listens on to just use the WSL virtual ethernet adapter? If you only want to use this for the WSL use case, you probably don't really want the server listening on all interfaces.

[dorssel]

According to netstat, the server listens on 0.0.0.0:3240. Is there a way to constrain the IP address the server listens on to just use the WSL virtual ethernet adapter? If you only want to use this for the WSL use case, you probably don't really want the server listening on all interfaces.

No, but the recommended solution is to adapt the firewall rule. Just restrict the remote (and/or local) IP addresses to those used by WSL.