Snort Package HOME_NET - Your opinion on its automatic generation
-
Snort Package users, here is your chance to contribute your view on how the automatic generation of the HOME_NET variable and default whitelist should work in the Snort package.
I will kick it off with my view. The current process works pretty well, but needs a few tweaks. To illustrate my vision of how it could work better, I've attached three images to go along with my explanation.
One image is a very simple network showing a pfSense firewall with three interfaces and the associated IP networks: (1) LAN, (2) DMZ, and (3) WAN. The other two images show pfSense screenshots. Note that the Whitelist Edit screen is a prototype from my testing environment and includes a GUI option not currently available in the production release of the Snort package.
A new GUI option is shown on the Whitelist Edit page. The option is called Local Networks, and is checked by default. When checked, this causes all the local IP network interfaces on the firewall (except for the WAN) to be collected and stored in the HOME_NET variable and the whitelist. Referring to the sample network diagram, this results in the following networks being included in HOME_NET because they are defined on local firewall interfaces: 192.168.1.0/24 and 192.168.2.0/24. Additionally, because the boxes for WAN IPs and Gateways are also checked on the Whitelist Edit page, HOME_NET will also contain IP addresses 65.120.20.59 and 65.120.20.1 (the WAN interface and default gateway).
I had other non-connected networks I wanted to also include in HOME_NET, so I created an Alias on the firewall containing those networks. I then added that Alias to the list under Whitelist Edit. As illustrated in the attachments, I created an Alias called Friendly_Nets and included two additional subnets in it: 10.110.13.0/26 and 192.168.10.1/24. A screenshot of the Firewall : Aliases screen is attached where you can see the additional networks defined in the Alias.
My example does not include Virtual IPs or VPNs, but they operate in a similar manner.
Does this functionality as described and explained above meet the expectations for how automatic HOME_NET and whitelist generation should work in the Snort package? Is there a need for the entire WAN subnet to be part of the default HOME_NET variable and whitelist, or is it sufficient to only include the actual WAN interface IP and far-end gateway? For reference, the Snort package currently includes the entire WAN subnet in HOME_NET and the whitelist.
Bill
-
Looks great to me. Default config seems to add everything any standard configuration might use, and it makes tweaking it straight forward as well.
Just an idea: would it be possible to show what $home_net ends up being so we don't have to look in the snort.conf?
-
Just an idea: would it be possible to show what $home_net ends up being so we don't have to look in the snort.conf?
Yep, that should be possible. Just need to find a good place to show it in the GUI.
Bill
-
I think this is sufficient for me and most users. I have a separated WLAN that cannot access my LAN and I don't want this WLAN on my local IP network, but this can be solved by unchecking this and using an alias.
-
I think this is sufficient for me and most users. I have a separated WLAN that cannot access my LAN and I don't want this WLAN on my local IP network, but this can be solved by unchecking this and using an alias.
Yes, in this case you would uncheck the proposed new Local Networks option and instead create your own custom Alias containing the local networks you wanted in HOME_NET.
-
Just to verify … Would HOME_NET also capture the IPv6 LAN address?? Specifically, DHCP-PD assigned addressing from the ISP.
Thanks
-
In terms of UI, it seems like it would be ideal to define your networks in the same area in Snort where you define/config your interfaces. This field could have the option to point to the Whitelist or Alias list, similar to the way we do it today for firewall rules. In addition, you could make it a free form for the "admin" to define the networks they wish to monitor. Again, this is more of a UI recommendation.
-
Just to verify … Would HOME_NET also capture the IPv6 LAN address?? Specifically, DHCP-PD assigned addressing from the ISP.
Thanks
Yes, any IPv6 addresses associated with a given interface would be captured as well.
Bill
-
In terms of UI, it seems like it would be ideal to define your networks in the same area in Snort where you define/config your interfaces. This field could have the option to point to the Whitelist or Alias list, similar to the way we do it today for firewall rules. In addition, you could make it a free form for the "admin" to define the networks they wish to monitor. Again, this is more of a UI recommendation.
The paradigm the pfSense Core Team prefers is to use Aliases and move away from direct entry of IP addresses all over the place. The idea is Aliases drive some measure of consistency and also make edits in the future much easier. I agree with this approach as well. I know some folks want to just have an open text field and type in addresses or networks directly, but long-term this can become unwieldy. I regularly use Check Point at work, and they enforce the same paradigm. They call them Objects instead of Aliases, but the idea is the same. You create an Object for a host, a network or a group; and then you use that Object in all the rules. Using Objects in Check Point or Aliases in pfSense makes it easy when you need to change something in the future. For example, assume you change the subnet mask on a network. If you have direct-typed that network into a half-dozen places such as a few whitelists, HOME_NET and several firewall rules, then you have a lot of edits to make and can easily miss one. On the other hand, using a Alias means just one edit on one screen and your change is propagated everywhere.
So a long explanation to say I'm not in favor of allowing direct text edits on all the Snort screens. I prefer to endorse the use of Aliases for this purpose. Once you become accustomed to using them, they really are a great thing.
Bill
-
I like this. But WAN VIP is important to have in my view as HOME NET!
-
I like this. But WAN VIP is important to have in my view as HOME NET!
It should get picked up in the list of other VIPs and be included. I will send you a copy to test via e-mail.
Bill
-
In terms of UI, it seems like it would be ideal to define your networks in the same area in Snort where you define/config your interfaces. This field could have the option to point to the Whitelist or Alias list, similar to the way we do it today for firewall rules. In addition, you could make it a free form for the "admin" to define the networks they wish to monitor. Again, this is more of a UI recommendation.
The paradigm the pfSense Core Team prefers is to use Aliases and move away from direct entry of IP addresses all over the place. The idea is Aliases drive some measure of consistency and also make edits in the future much easier. I agree with this approach as well. I know some folks want to just have an open text field and type in addresses or networks directly, but long-term this can become unwieldy. I regularly use Check Point at work, and they enforce the same paradigm. They call them Objects instead of Aliases, but the idea is the same. You create an Object for a host, a network or a group; and then you use that Object in all the rules. Using Objects in Check Point or Aliases in pfSense makes it easy when you need to change something in the future. For example, assume you change the subnet mask on a network. If you have direct-typed that network into a half-dozen places such as a few whitelists, HOME_NET and several firewall rules, then you have a lot of edits to make and can easily miss one. On the other hand, using a Alias means just one edit on one screen and your change is propagated everywhere.
So a long explanation to say I'm not in favor of allowing direct text edits on all the Snort screens. I prefer to endorse the use of Aliases for this purpose. Once you become accustomed to using them, they really are a great thing.
Bill
Right and I don't disagree with that approach. I've used many firewalls over the years and I also prefer using "aliases" (going all the way back to before PF days with ipfilter) as it is a cleaner method.
-
Right and I don't disagree with that approach. I've used many firewalls over the years and I also prefer using "aliases" (going all the way back to before PF days with ipfilter) as it is a cleaner method.
I have put three new View buttons on the If Settings tab where you configure a Snort interface (the tab where you choose whether to enable blocking of offenders, the Search Performance profile, whitelist, etc.). These new buttons let you click and see the current contents of the chosen HOME_NET, Whitelist and Suppression List selected in the associated dropdown box. I have those new buttons working now in my prototype code. They should come out with the 2.5.8 package. They open the same style pop-up window as the new View Rules Update Log window.
So on the screen where you do the HOME_NET and Whitelist selection, you will have a quick way to view the contents of your choice. If a user needs to do something really fancy or outside the box, then the Alias choice under the Firewall menu is where to start. Once the Alias is defined, then it can be chosen for the HOME_NET or whitelist.
Bill
-
Right and I don't disagree with that approach. I've used many firewalls over the years and I also prefer using "aliases" (going all the way back to before PF days with ipfilter) as it is a cleaner method.
I have put three new View buttons on the If Settings tab where you configure a Snort interface (the tab where you choose whether to enable blocking of offenders, the Search Performance profile, whitelist, etc.). These new buttons let you click and see the current contents of the chosen HOME_NET, Whitelist and Suppression List selected in the associated dropdown box. I have those new buttons working now in my prototype code. They should come out with the 2.5.8 package. They open the same style pop-up window as the new View Rules Update Log window.
So on the screen where you do the HOME_NET and Whitelist selection, you will have a quick way to view the contents of your choice. If a user needs to do something really fancy or outside the box, then the Alias choice under the Firewall menu is where to start. Once the Alias is defined, then it can be chosen for the HOME_NET or whitelist.
Bill
Very cool! I am looking forward to trying that out!!
-
-
Is there any reason why alias with URL type could not be used in snort whitelists ?
-
Is there any reason why alias with URL type could not be used in snort whitelists ?
Well, at the moment the Snort code is only expecting hosts or networks. I can look at including URLs in the update I'm working on.
Bill
