I have only 1 Incoming Firewall Access rule, which is:
Protocol (All/Drop), Source (Any), Destination (Red)
Below that is a line that says, “Policy: Blocked.”
Why is the red0 interface still pingable on its public IP?
Every known interface is pingable. A ping is just calling the name of someone. You cannot suppress this.
On the other hand ping is an essential operation for routing ( see ping (networking utility) - Wikipedia ). Therefore your red0 interface must be pingable.
Your firewall rule defines the operation on incoming packets, not belonging to an established connection ( i.e. initiated by a local client ).
Thanks, Bernhard. For context, I am a network engineer with 30+ years of experience using Cisco, Juniper, FortiGate, and others, but I’m brand new to ipfire. I understand what ICMP is for, and it is very common to prohibit most of the outside world from being able to ping the Internet-facing interface, and only allow it for known and trusted endpoints (like remote admins).
for me it makes not sense disable ICMP
it would create at least some Problems with IPsec and gives not a additional security Layer
1 Like
And, FWIW, it breaks RFCs.
1 Like
The internet-facing interface is connected to WAN with a huge amount of devices connected to it. You can’t control at one endpoint of this network other endpoints.
IPFire is a device to to control the communication of your local network with the outside world.
This is done with two basic policies:
- all traffic received on the WAN interface ( red0 ) is not forwarded to the LAN ( traffic ends at this point )
- if a device in the local network(s) initiates a connection with a device in the WAN, this is remembered by the firewall and packets belonging to this connection are forwarded to the associated local device.
Part of the incoming traffic are ICMP packets ( aka ping ). These are answered by IPFire to be a member of the internet community. There are discussions here in the community and in IPFire’s blog about possible reactions on ICMP packets.
If you want to allow trusted communications partners only to send to your IPFire appliance, you must install another gateway/firewall in front of it. But this imposes other problems, possibly.
I suppose there are trade-offs. For me, I would rather be mostly invisible to much of the world. most nmaps terminate if the host does not respond to ping.
This isn’t really true.
No answer to an ICMP packet means there is a device with this IP! Otherwise the gateway in front would have answered ‘IP not reachable’.
About ‘invisibility’: Your IPFire device must be visible to be a gateway for your local network.
You can hide your local devices, if you control their connections. With firewall rules you can force only to communicate with trusted, well known endpoints.
But this is another story. 
2 Likes
found this Thread → ICMP is enabled by default on red
scroll down, there is a cmd - add this to /etc/sysconfig/firewall.local
You can’t control at one endpoint of this network other endpoints.
Of course not. Disabling ICMP simply helps you stay off the radar. Many probes terminate if the host does not respond to ping. Others do not, but I would still rather stay off the radar as much as possible. I see no benefit in responding to echo requests from the world.
If you want to allow trusted communications partners only to
send to your IPFire appliance, you must install another
gateway/firewall in front of it.
That weird, but okay. All I can say is that Juniper, FortiGate, Cisco, and others all have the ability to disable ICMP response without having another firewall in front of them. Heck, so does iptables.
That’s a great thread, thanks! I agree with the poster. In most cases, disabling ping from the outside world is considered good security practice. Unfortunately, I think the solution presented in the thread does not allow granularity. I do want to allow ping from remote admins.
Better read whole the thread!
This isn’t really true. No answer to an ICMP packet means
there is a device with this IP! Otherwise the gateway in front
would have answered ‘IP not reachable’.
That is not inaccurate. Here’s an example of me pinging an IP that does not exist:
[root@jump01 scripts]# ping .141
PING .141 (.141) 56(84) bytes of data.
From .133 icmp_seq=1 Destination Host Unreachable
From .133 icmp_seq=2 Destination Host Unreachable
From .133 icmp_seq=3 Destination Host Unreachable
In this case, .133 is the last hop before the IP in question. “Destination host unreachable” means the router at .133 did not get a response to its arp request. The reason could be because there is no device with that IP, or it also could be because the device with that IP ignored the arp request. It’s not easy for a prober to know which is the real reason.
‘Destination Host Unreachable’ means the last router ( which is part of the network of the endpoint ) doesn’t know the host.
A host not responding is reachable, traffic can forwarded to it.
BTW: I really recommend to read the thread cited ( including the links ).
2 Likes
In your earlier response, you said,
No answer to an ICMP packet means there is a device
with this IP! Otherwise the gateway in front would have
answered ‘IP not reachable’.
Since “IP not reachable” is not an official ICMP message, I assumed you meant “Host unreachable.” That message means the host did not respond to an ARP query. Like I said, the reason could be that the host does not exist, but the other reason could be that the host ignored the ARP query. The last router would send a “host unreachable” message either way.
If an IP exists but does not respond to pings, the last router would get an ARP response. It would therefore not respond with “Host unreachable” (or “IP not reachable”). The request would just timeout at the client side. There can be many reasons for timeouts. It doesn’t necessarily mean there is an IP at that address.
I did, and I read the comments from the blog post. I tend to agree with pmeuller on some of his points but not others. He’s right that ICMP-based attacks were big in the late 90’s and early 2000’s, but not so much anymore. They may still sometimes be used as covert channels, I’m not sure. He’s right that filtering ICMP does not perfectly hide you from scans and probes because it is easy to scan for open ports while ignoring ICMP; however, it takes longer, and I think probers tend to focus on targets that are responsive to ICMP because they are looking for easy targets of opportunity, and doing full port scans takes time. I think disabling ICMP reduces the number of probes. I think it’s funny when people complain about “security by obscurity” because everyone who makes fun of it still practices it in multiple ways: passwords, NAT, non-default ports, renaming system accounts from “Administrator” to something else… all those things and many more are “security by obscurity” but are still part of good security practices. Security by obscurity is not acceptable when it is the only layer of defense, but it is still useful as one of the layers.
I would also like to have an option in the WUI to drop unsolicited ICMP requests from the WAN. Every consumer router I’ve ever owned prior to switching to IPFire has had a way of disabling unsolicited pings from WAN in the user interface. Does anyone know if pfSense does this?
From what I’m reading, pfSense does it. Every firewall I’ve ever worked with except ipfire has that feature, and many have ICMP blocked on the WAN interface by default… From what I can tell, ipfire does not have it because the developers believe it does not help, since you can still do TCP port-scans. I don’t think they realize how much it cuts down on probes just by not responding to ICMP.
Each user of IPFire can be a developer or even support development.
This is the nature of open source projects.
If someone knows a solution to problem he has, he is invited to do the step. See www.ipfire.org - Development
A good start point is to post to the development mail list.
5 Likes