FYSA - ICMP Ping is allowed from any non-wan to wan as default

[erasedhammer]

I recently noticed that despite there being no firewall rules permitting it (and my own deny any->any rule at the bottom in the firewall app), ICMP ping requests from any non-wan client can route right accross the firewall to anywhere on the internet.
I even tried adding a firewall rule at the top just blocking all protocol ICMP, but devices could still ping anything on the internet.

I had to add a filter rule in Network->Config blocking all Protocol ICMP from any non-wan to any wan.

This should not be the default. No one in their right mind would want a firewall that indescriminately allows TCP/443 to anywhere on the internet from any client by default (emphasis on the any client). The protocol ICMP should not be an exception to this. The ICMP protocol can carry data just like TCP and UDP.

Malware can and does use ICMP as a C2 (Command and control) path to bypass firewall filtering. It should not be the default to allow any LAN client ICMP access to anywhere on the internet. The only exception I can see is allowing ICMP LAN to LAN.

Not sure if this was an oversight on Untangle's side (maybe they did only intend for ICMP to be LAN to LAN unrestricted), but regardless I would urge the Untangle team to seriously consider removing this behavior as default.

[ccdmnk]

I've never been on a network, home or company, that doesn't allow ICMP to WAN. Apart from the secured separate internal-only lans.

You do realize the base config allows basically anything, anywhere, right? Firewall doesn't block anything by default. See: Firewall - Edge Threat Management Wiki - Arista (untangle.com)

[erasedhammer]

The main issue I am concerned with is that ICMP continued to be allowed with an explicit firewall rule blocking ICMP.

To be clear, I don't think that they should block LAN to WAN traffic by default, its just weird that ICMP bypasses traffic filtering in the Firewall app.
Why even have the option for a rule in the Firewall app to select "Protocol: ICMP" if it doesn't do anything?

Straight from the Firewall app Wiki page:

I want to lock-down my network but for a few exceptions. What is the best way to do this?

Simply add a rule with no qualifiers, set it to Block, and put it at the bottom of the list. This will match all traffic, so anything not explicitly passed in a rule above it will be blocked.

I would consider that untrue, if a blank "Block all" rule in the firewall app doesn't stop ICMP.

[sky-knight]

This is a failure to understand NGFW fundamentals.

The Untangle Virtual Machine, otherwise known as the UVM is a Java based application that runs on Linux and provides the heart of the NGFW filtration environment. This environment only processes UDP and TCP packets, no other protocols are ever sent there.

The Firewall App therefore cannot control anything but TCP and UDP packets. It however will appear to allow you to make rules regarding these other protocols in what I can only define as a catastrophic user interface bug. And therein lies the confusion!

Just know that all of the Policy Apps you see in Untangle only handle TCP and UDP.

Now, how do you control other protocols? You configure the Linux Kernel to do things. Where do you do that? You do that under config->networking.

Access Rules are an advance mode feature that control all protocols by configuring IP tables to define what can and cannot access the Untangle platform itself. BEWARE screw up in here and you can disable your own web UI entirely. It's advanced for a reason!

Filter Rules configure IPTables relative to what transits the NGFW. It is here where you can safely define rules that control all traffic types, including ICMP. However you do not get the logging and policy controls you get from the Firewall App. I use Filter Rules for everything that isn't TCP or UDP, and the Firewall App for the rest. Filter rules also always process for all traffic, even bypassed traffic.

Understanding the difference between the two "firewalls" is essential when deploying NGFW.

https://wiki.untangle.com/index.php/Filter_Rules

https://wiki.untangle.com/index.php/Firewall

You will note the second link clearly states this limitation, but doesn't explain the why I've put above.

The "Firewall" app itself is a traditional firewall used to block and/or flag TCP and UDP sessions passing through NG Firewall using rules.

The rest of the comments I'll only classify as opinions, as no sane admin controls HTTPs egress via firewall rules. That is what we have Web Filter, and Threat Prevention for, there's no reason to change the default behavior of the way Untangle handles HTTPS, ICMP, or any other protocol when the full power of the platform is properly understood.

[erasedhammer]

Understandable. I have already placed a block ICMP filter rule for certain locked down subnets.
There are also other non TCP and UDP protocols listed as available in the Firewall app. GRE, ESP, AH, SCTP, and OSPF.

It might be worth while to make a UI change in a future update so theres no confusion when configuring rules. Also, it would be a good idea to reword the Firewall app wiki page to say the app only receives TCP and UDP traffic. The current wording does make it easy to gloss over (I believe the only other reference is in the Bypass and Filter rules page of the wiki). I think its important for admins to understand that they need filter rules to truly lock down all communication of a subnet, not just the Firewall app.

Although I would be hesitant to group HTTP and ICMP into the same boat there. ICMP is layer 3, HTTP is layer 7.

A sane admin wouldn't control HTTPs in a firewall, but they would control the layer 3 and 4 carrying the HTTPs session in a firewall.
Personally, I use the Firewall app to control traffic Layer 4 and down, and only use web filter for filtering on layer 7, but thats just me.

[sky-knight]

Technically speaking that's what the Firewall app does, layer 4. But it runs within the UVM which is more layer 7. The OSI model doesn't really apply anyway, it's just a means of thinking about how the traffic moves around. The UI bug that causes this confusion has been around for decades, so I don't see it being fixed anytime soon sadly.

I'm not a fan of controlling ICMP, yes it's an information source but it's AN INFORMATION SOURCE! By limiting its use, you take a troubleshooting tool out of the hands of the admin. This extends investigation times, which extends resolution times. Longer resolution times mean longer down times, and longer down times mean more money was spent fixing the issue. Every organization has to define what they're going to do in this space. NGFW also provides a ton of knobs allowing an admin to put the thumb screws on the network in all sorts of ways. Everyone is free to tighten or not driven by their own needs.

NGFW was designed to "fail open" as much as possible to make the platform easier to use. So yes, it allows egress ICMP. For that matter so does Azure by default, heck Azure allows everything egress by default. So NGFW is far from alone here, and no I do not believe we gain any real security by limiting it on egress. (Note, Sonicwall, Threatwall, Firebox, Watchguard, and Checkpoint firewall all allow egress ICMP by default too)

Now, if I have Threat Prevention and Web Filter running, one of the two modules the former in particular is going to get VERY VOCAL if there's malware traffic exiting any of my LANs and further it's going to block much of that traffic regardless of protocol. Because that's what an IP reputation system does! Until such time as we can mTLS everything, this is good enough for me.

[erasedhammer]

I can completely understand the design intention here. And I don't expect it to change.

All I'm saying is, if I want to completely lock down communication to and from a subnet, ICMP is not going to be excluded from the filtering.

Does the Intrusion prevention (Suricata) receive other protocols other than TCP/UDP? Because I do see Suricata signatures for malicious ICMP behavior. I assume it receives everything since its listed as a service app and not built into UVM?

As for threat prevention, malware doesn't always use previously flagged or known "bad" public addresses. I'll admit a malicious ICMP communication channel to a good reputation public IP is a fringe case. But for a properly secured network, I don't think permitting certain entire protocols as unfilter/not inspected is a good practice (this is my personal opinion, I'm sure there are plenty of cases where availability is a much higher priority).

[sky-knight]

If you look at your Apps tab in your NGFW's UI, there are two categories of apps. "Apps" and "Service Apps".

The former are inside the UVM and as such only handle TCP and UDP. The latter are outside the UVM and integrate with the product in various ways. They may even actually run inside the UVM, but they're special in some way that means you can only have 1 instance per platform. Intrusion Prevention is a Service App for this reason, and yes it receives all packet types and protocols from the kernel, if you install the module and let it run with default rules for a short while you should see ICMP events popping up very quickly.

The choice to limit primary filtration to TCP and UDP was made ages ago for performance reasons. NGFW is still to this day quite heavy on the system even with most filtration being limited in the UVM. It's better now than it was ten years ago, but compared to other products it's brutal on the local hardware. Of course it's also not hopelessly dependent on some cloud service to be useful like most thing either. It does lose functionality of course, but not to the degree of the other options in this space.