I found an issue or “bug” in the SonicOS platform (the firmware controlling SonicWALL security appliances) that has to do with renaming Default Service Objects, which then causes a portion of the system to become uncontrollable and unstable.
SonicOS separates Service Objects into three different views or groupings: “All Services”, “Custom Services” & “Default Services”. Within each view there are two sections called “Service Groups” & “Services”. Service Groups are simply just Services grouped together for related purposes. Default Services are a list of system-created, commonly used, services that you can utilize to create many different networking policies and rules. They are not only created for convenience but they also play a key role in how default Access Rules function, which I’ll discuss later. For all intents and purposes Default Services Objects and Default Services are synonymous here and I’ll be focusing this discussion on the “Ping” Service Group within Default Services. Ping is just an example, but this bug occurs when renaming any Default Service Object. Some customers of SonicWALL security appliances will rename Default Services under the Service Groups section like Ping and rename it to “Ping Group” or “Group: Ping”, etc. to denote that it is in fact a group, which actually includes both Ping 0 (ICMP - reply) and Ping 8 (ICMP - request) rather than a single Service Object, e.g. Ping 8 (ICMP - request).
When Default Access Rules are created they function together with Default Services to either allow or deny traffic running on that Service or port. For example, when you enable ping on an Interface it will then create a Default Access Rule and associate the Ping Default Service Object to allow traffic to pass-through on ports 0 and 8 to the selected Interface.
When you rename Default Service Objects they will produce the following results:
When used in connection with Default Access Rules they will allow traffic to pass through uncontrollably (meaning you cannot stop the traffic for that service even after disabling it).
The SonicOS platform may become unstable.
This potentially allows vulnerabilities to exist without being able to prevent them, especially in hardening or compliance situations.
Once you rename a Default Service Object such as ping from Ping to Ping Group or any other name you desire everything appears OK at first, but as soon as a reboot or a power outage occurs the firmware performs a routine system check to make sure everything is in order and discovers that the Ping Default Service Object name is missing from the Default Service Objects List and therefore creates a new one named Ping. This creates two sets of Default Service Objects under the Service Group section:
1. Ping Group, original named Ping, and
2. Ping, the newly, system-created one.
This result is repeated for every Default Service Object, which has been renamed. On the surface it looks harmless until you realize the special characteristics of Default Services, which are:
they cannot be deleted; and
they are inextricably connected to Default Access Rules and other default system functions.
Additionally, Default Access Rules cannot be deleted. As mentioned before, when you enable ping on an Interface a Default Access Rule is created with the association to the Ping Default Service Object, but now since it has been renamed to the Ping Group, the SonicOS has created a new association to the newly created Ping Default Service and will therefore create an additional Default Access Rule to maintain the previous configuration of allowing ping on that Interface. Hence, there are two Default Access Rules:
1. the original Access Rule associated to the Default Service Object named Ping Group, originally named Ping, and
2. the new Access Rule associated to the newly created Default Service Object named Ping.
This brings us to the core of the issue because the SonicOS has orphaned or dissociated itself from the Default Service Object named Ping Group along with the corresponding Default Access Rule because it does not recognize the Service Object’s name as it relates to the Default Service Object list. This essentially orphans both the Rule and Service allowing it to persist and operate independently from the control of the SonicOS. Remember the characteristics of the Default Service Objects & Default Access Rules…they cannot be deleted! This allows the Firewall to be in a compromised state in the sense that now there is no way to disable ping on the WAN interface for hardening or compliance situations. Understandably, ping is more of an innocuous example here, but other services can be far more compromising.
NOTE: you will *not* be able to import a Settings Backup because the Settings will contain the bug unless you have a Settings Backup previous to renaming any Default Service Object.
I have brought this to the attention of the SonicWALL development team and they are working on a Hotfix.
I have proposed two simple fixes for this, either: A) remove the ability to rename Default Services altogether or B) create a hidden unique identifier to each Default Service Object which then does not rely on unique name sets (obviously much more involved). I suspect they will move forward with option A.