NETworkManager icon indicating copy to clipboard operation
NETworkManager copied to clipboard

[New App] Firewall module/application

Open labre-rdc opened this issue 3 months ago • 3 comments

Introduction

Hi, we like and use the profile based IPv4 network address setup, however we are working in a context with multiple factory sites with isolated networks having static addresses without a default route. So the main issue we are having is that the NetworkCategory is Public due to the “Unidentified Network” in these environments and while we can set it to Private using powershell, we often have to reconnect ethernet cables, which resets the network category and firewall.

Some ports need to be open though due the network containing being production components (robots, SPS etc.), so it would be nice, if we could configure these per site instead of the broader NetworkCategory approach.

To be contributed

Since I am currently finishing my education as IT application specialist (German: Fachinformatiker für Anwendungsentwicklung), I have chosen with my superior to develop this (Sub-)Application/Extension as my project thesis/work. I can develop for around 50 to 60 hours and must be finished until 2025-12-15.

The idea is outlined in the following:

NetworkCategory

Store the NetworkCategory within the profile and set it, when the profile is applied. This will not be reliable, because the category is reset on reconnect. For that reason the interface state needs to be observed and the category must be reapplied, if a interface connect event happens. This could be done by putting NETworkManager in alert state or opening the window showing a prompt to reapply the category, such that the UAC request is not prompted out of nowhere (causing reasonable distrust in users). Similarly to group policies this wil have 3 states:

  • Not configured (Do not change)
  • Private
  • Public

If the active state is DomainAuthenticated the setting will be inactive and a category change won’t be attempted. This may still fail due to a local security policy.

Show an error in that case and also indicate domain networks.

Firewall rules

Store profile specific firewall rules within the profile. This would avoid the Category reset problem with its reoccurring UAC prompts and could be applied for Public networks within a specific customer profile, which then would only be set active on the factory site.

The naming of these rules should have the following scheme and users must not be able to control it for security reasons:

Nwm_<profile name>_<protocol (tcp/udp) or program as prog>_<direction (in or out)>_<program name or port/port range>

For example:

Nwm_Test Profile_tcp_in_443

Issues to handle

Handling these cases might be out of the scope of this project, if I run out of time, however I might add handling for them later in my free time.

  • The rules could be altered outside the scope of NETworkManager and we need to recognize this. If this is detected, the user needs to be prompted with the rules, that were found to either discard them and load from profile or accept them updating the profile.
  • Rules could be added in the system following the naming system. This might be malicious (but on the other hand, it requires elevation, so users have other concerns in that case). A use case might be, that a backup of old profiles has been restored, but the system still contains another set of rules. In that case, users need to confirm addition or deletion of rules from the system.
  • As a goodie we could allow importing the ruleset from the system firewall rule set, if rules with this naming scheme are detected, but no firewall rules are configured due to e.g., the loss of profile files. This is a rare use case though, so I will most likely omit it.

And that’s basically the project idea.

labre-rdc avatar Dec 02 '25 13:12 labre-rdc

Thanks for your contribution and good luck with your final exam.

I hope I have read and understood this correctly. The following are just ideas that came to me while reading (feel free to ignore them for your project if you want to implement something else).

You could start by expanding the profiles to include the network category (radio button/drop-down):

  • Not configured
  • Public
  • Private
  • DomainAuthenticated

and additionally corresponding firewall rules that can be added to the profile with +/- buttons (similar to other features like dns servers, host entries, etc.):

  • name/description/src ip/port, dest ip/port, etc. (also with input validation in the dialog/textbox)

When applying the profile (with admin rights), the corresponding values could then be set directly (the firewall rule will get the network category from above, or when not configured -> use the default from the profile).

There is a powershell cmdlet that can be used to set the category:

> Get-NetConnectionProfile

Name                     : IoT-Devices
InterfaceAlias           : vEthernet (Hyper-V_EXTERN)
InterfaceIndex           : 8
NetworkCategory          : Private
DomainAuthenticationKind : None
IPv4Connectivity         : Internet
IPv6Connectivity         : NoTraffic

> Set-NetConnectionProfile -InterfaceIndex 8 -NetworkCategory Public

However, I am not sure if this can/will be applied immediately after setting up an IP/DHCP configuration, as I believe Windows performs some network discovery operations. The powershell command doesn't need the network name (i think netsh requires it?). But that's something you can figure out and test 😄

For the firewall rules, it would make sense to use a prefix, as you already described... something like NETworkManager_xxx and when you switch profiles/apply a different profile, you could clean up all existing rules with that prefix and apply the new rules. Perhaps you could also add a button to remove all rules related to NETworkManager_...

If this is working, you could try to create some "automation", listen to network change events (interface up/down, unplug cable) and then re-apply the config (ask the user to apply again?).

Regarding the possible issues:

  • If rules with the prefix NETworkManager_ are altered outside of NETworkManager -> delete & re-apply the config (same as i would do when switching profiles) - maybe always delete them first and re-apply
  • Then someone has already admin access on the machine -> and the user has other problems... but if you delete everthing before re-apply, then also the malicious rules would be gone.
  • I don't know if you want to go to the trouble of importing rules... then it's better to regularly back up the profile file on OneDrive/Nextcloud/etc. It's a special use case.

But you could also store the rules in the group (and in the settings) to make them inheritable (similar to other settings).

  • Group: OOBM Rule: UDP 69 (TFTP)
    • Profile 1: Network 1 IP: 192.168.0.1
    • Profile 2: Network 2 IP: 10.0.0.10

The Information tab also doesn't show something like the network categoy or network name, so maybe it could also be added there... maybe also the current rules that are applied?


There is an open issue about binding a profile to a specific network interface: https://github.com/BornToBeRoot/NETworkManager/issues/146

It might be interesting to implement this as well, especially if you want to apply the configuration automatically (what if you are connected to two networks? Cable and Wi-Fi?).


This part of the code is a bit older and it's been a while since I wrote it... but if you have any questions, feel free to contact me here and I'll try to respond as soon as possible.

Greetings from a FiSi 😃

BornToBeRoot avatar Dec 03 '25 22:12 BornToBeRoot

Thanks for your contribution and good luck with your final exam.

You’re welcome and thank you.

You could start by expanding the profiles to include the network category (radio button/drop-down):

* Not configured

* Public

* Private

* DomainAuthenticated

This would most likely be inconsistent, because the firewall rules always apply to the network category, but do not care about network interfaces and the network category just applies to network interfaces. So, for an application containing settings for both this would not make much sense.

and additionally corresponding firewall rules that can be added to the profile with +/- buttons (similar to other features like dns servers, host entries, etc.):

* name/description/src ip/port, dest ip/port, etc. (also with input validation in the dialog/textbox)

Sure, the model for that is basically. I’m currently creating the view.

When applying the profile (with admin rights), the corresponding values could then be set directly (the firewall rule will get the network category from above, or when not configured -> use the default from the profile).

There is a powershell cmdlet that can be used to set the category:

Get-NetConnectionProfile

Name : IoT-Devices InterfaceAlias : vEthernet (Hyper-V_EXTERN) InterfaceIndex : 8 NetworkCategory : Private DomainAuthenticationKind : None IPv4Connectivity : Internet IPv6Connectivity : NoTraffic

Set-NetConnectionProfile -InterfaceIndex 8 -NetworkCategory Public

However, I am not sure if this can/will be applied immediately after setting up an IP/DHCP configuration, as I believe Windows performs some network discovery operations. The powershell command doesn't need the network name (i think netsh requires it?). But that's something you can figure out and test 😄

Yes, the network discovery operations always reset the network category. That is the issue, I outlined. ;) In contrary to IP/DHCP configuration the network category can not be set permanently by users for an interface, except for setting it in secpol.msc or certain registry keys. However you usually do not want to set an adapter to private for eternity (unless you like malware).

For the firewall rules, it would make sense to use a prefix, as you already described... something like NETworkManager_xxx and when you switch profiles/apply a different profile, you could clean up all existing rules with that prefix and apply the new rules. Perhaps you could also add a button to remove all rules related to NETworkManager_...

Sure, I can make the prefix more verbose, so that the source application is human readable. Thanks for the hint. Yes, that would have been my security by default approach.

If this is working, you could try to create some "automation", listen to network change events (interface up/down, unplug cable) and then re-apply the config (ask the user to apply again?).

Yes, that would be the full implementation. Not sure, whether I can make it happen within the time constraints, but I’ll definitely finish it between the years, if I have to skip some implementations. Another extension would be the search for installed applications for the program filter in Firewall rules. My implementation will just offer to select an exe manually (like Windows settings). After the project an extension for listing installed apps could be developed. Might be also useful for other new modules, e.g., VPN (finding command line tools).

Regarding the possible issues:

* If rules with the prefix `NETworkManager_` are altered outside of NETworkManager -> delete & re-apply the config (same as i would do when switching profiles) - maybe always delete them first and re-apply

Yes, I must do that anyway, because the program path can not be reset to all applications with the CLIs (tested netsh).

* Then someone has already admin access on the machine -> and the user has other problems... but if you delete everthing before re-apply, then also the malicious rules would be gone.

Sure, for above reasons I was going to do this anyway. I was just thinking about this, because it would be user-friendly to not just delete settings without asking, even though they clearly belong to us.

* I don't know if you want to go to the trouble of importing rules... then it's better to regularly back up the profile file on OneDrive/Nextcloud/etc. It's a special use case.

Yes, it is. And no, due to the remaining time, I will just skip it. ;)

But you could also store the rules in the group (and in the settings) to make them inheritable (similar to other settings).

* Group: OOBM
  Rule: UDP 69 (TFTP)
  
  * Profile 1: Network 1
    IP: 192.168.0.1
  * Profile 2: Network 2
    IP: 10.0.0.10

The Information tab also doesn't show something like the network categoy or network name, so maybe it could also be added there... maybe also the current rules that are applied?

Sounds like a good idea. Depends on my time constraints, but I’ll put it at least on my TODO list for the time between the years. For the rules I would rather indicate, whether rules are active and link to the firewall module instead. This avoids duplication of the view.

There is an open issue about binding a profile to a specific network interface: #146

It might be interesting to implement this as well, especially if you want to apply the configuration automatically (what if you are connected to two networks? Cable and Wi-Fi?).

Since the rules just depend on the network category as outlined above, it would not be that useful in this case. But maybe I look into it, if I get in coding mood.

However I either have to store the Interface list and a corresponding network category configuration within the profile or filter them by other means, e.g., internet connection or discovery state. I have to further think on it.

This part of the code is a bit older and it's been a while since I wrote it... but if you have any questions, feel free to contact me here and I'll try to respond as soon as possible.

Greetings from a FiSi 😃

Thanks, hopefully I can greet as a FiAe soon. 😄

labre-rdc avatar Dec 04 '25 11:12 labre-rdc

I have a strong feeling that the whole network category logic can be merged with the network interfaces application. I have to copy way too much code from the NetworkInterfaceViewModel for this to be unrelated from a OOP point of view. So for the sake of encapsulation, I’ll move the interface specific network category display and configuration into NetworkInterface.

The firewall module will then still hold the rules for each category. Creating it still makes sense, although we can provide a link within the NetworkInterface application and display, whether firewall rules are currently enabled.

Another useful extension for the NetworkInterface (outside of the scope of this project) would be multi-interface edits, by creating a 4th tab for configuring multiple interfaces “Configure (Multi)”, whereas the current 3rd tab would be named “Configure (Single)”. This could show a DataGrid with NetworkInterfaceInfo (including NetworkCategory) and allow to edit and apply multiple changes at once. We could also allow to rename the connections (DisplayName) if some CLI/CmdLet allows us to do that.

labre-rdc avatar Dec 05 '25 11:12 labre-rdc

Hi, I have about 25 minutes left for the project and will not finish it. However my boss gave clearance to finish it outside the scope of the exam.

Unfortunately I got significantly delayed due to a SSD drive failure and the thus necessary dev environment migration to my Luks encrypted PC. I developed in a Win11 VM and fortunately we chose a public project, such that I had this option. Otherwise non company hardware would have been out of question. Anyway, since this was necessary I've put it on project time, although the 7 hours more would not have been sufficient either.

I have created a proof of concept with the start of the module interface, and the start of the backend. I will put this state in a separate branch for reference and continue developing on firewall-dev starting on Tuesday. (Project documentation must still be written. ;)

I have created bidirectional Enum to string converters with localization, which could be of use for the project. Just wanted to leave a short update on the current state, before freezing my work state.

labre-rdc avatar Dec 12 '25 20:12 labre-rdc