No, I’m not using any VPN connections.
I don’t agree that ping is supposed to be open. Some people or organizations might have a specific use case that necessitates it, but otherwise all it does is invite a portscan or vulnerability probe. Silently dropping pings is a good security practice.
Dave, try this and report back …
echo "net.ipv4.icmp_echo_ignore_all = 1" >> /etc/sysctl.conf
sysctl -pThat did the trick - thanks!
How do you set RED to not respond but allow GREEN to respond? This is not working.
To accomplish this I believe you need to write iptables rules directly using firewall.local. Maybe this could give you a starting point, but be aware that you could have unexpected consequences if you do not know what you are doing. Just to give you an idea, these are all the ICMP types and 0, 3, 8 and 11 should never be blocked.
Indeed, cfusco is correct firewall.local is the place to put such a rule. If you really wish to stop a reply to ping on the red but keep it available on the everywhere else. In teaching myself iptables, I played around with some of this, so here is a suggestion. In /etc/sysconfig/firewall.local under the start section on could put the following:
iptables -A CUSTOMINPUT -p icmp --icmp-type 8 -i red0 -j DROP
and then under the stop section put:
iptables -F CUSTOMINPUT
This will stop any ping responses from your ipfirebox back to the internet and allow ping on green and allow you to ping out to the internet. I have tested such a firewall rule and it seems to work.
It seems to me that there is some debate about whether turning off ping replies are good or bad. Maybe someone with more knowledge could weight in on the merits of one verses the other. Such an argument might also depend on how you are geo-located, that is some areas might be more prone to attack than others. Hope this helps. PZ
This is what @pmueller wrote in a blog post:
[…] Thanks to connection tracking, IPFire will permit those ICMP messages by default if they belong to a previously established connection.
However, since IPFire measures the latency to its gateway, manually permitting outgoing ICMP type 8 messages is required. Depending on your uplink setup, this can or cannot be limited to certain IP networks or countries.
To me it sounds like blocking the outgoing ICMP type 8 traffic to the gateway (red interface) will interfere with IPFire functionality. I would assume, at least those packets should always be allowed and, as @pmuller says in the last part of the quote (if I understood correctly), this might or might not be enough.
Hi,
to my knowledge, the benefits of preventing a system to respond to ICMP echo-requests (type 8) are questionable indeed.
However, blocking any ICMP traffic is indeed not a good idea, since this blocks signaling of messages such as “packet too big” and “destination host unreachable”. While IPv4 can be operated completely without ICMP, IPv6 cannot - there, one will have to permit some types of ICMPv6 if things should be operational.
If I understood threads like this correctly, people commonly try to drop responds to ping to hide themselves from scanners or attackers. First of all, this won’t work if there is any port exposed to the internet on IPFire - if a destination does not respond to a ping, but to a TCP connect on a certain port, it is online indeed. There would be no sense in dropping the ping in the first place.
Second, “hiding” a system or making it “stealthy” (as some CPE configuration interfaces name this functionality) reminds me of “security by obscurity”, which neither is secure nor obscure in the end.
Yes, back in the 2000s, there were some nasty ICMP-based attacks. However, we can now deal with them (IPFire certainly can 
), and I believe the benefits of permitting ICMP replies to type 8 outweigh the security implications.
Thanks, and best regards,
Peter Müller
P.S.: IPFire tries to ping its configured gateway, for example. I believe it is for statistical purposes only, and some mechanisms such as PPPoE bring their own ping-alike functionality to detect connection loss.
Thank you. Should I write a wiki page summarizing this thread?
I believe the following nmap command will do exactly what @pmueller is describing here:
nmap -sT -PN -vv <target ip>
Hi,
yes, that’s it; many scanners implement techniques to deal with destinations blocking pings.
To determine whether there is a machine running behind an IP address, adversaries could also try to find network traffic recently caused by this IP address, such as DNS requests, mails or HTTP(S) requests originating from there. However, I believe this would be only worth the effort during a targeted reconnaissance, not during mass scans against the entire IP(v4) space.
Thanks, and best regards,
Peter Müller
Since removing ICMP echo from RED my IPS logs have went to nearly zero. Security through obscurity appears to work well.
This is strange because If you ping a really not existing IP you got an answer from the router before this IP that the IP could not reached. So if you get no answer to ping it means that there is a firewall that drop the ping request. So a smart attacker know that there is something intresting…
Hi @arktex54
Would you be willing to share the Core Update version and IPS ruleset you are currently using – now that IPS hits have gone to zero?
“nearly zero”. There are still some scan hits and IPS is working.
Most are connect scans on 22, 3389, and the Hauwei security vulnerability port. I imagine when looking to takeover a system 22 and 3389 and the primary targets regardless of ping response.
I’m not much of a networking security I.T. guy, but I hear what John is saying.
Yes, you can use nmap to poke at the ports and discover what’s open even with ping disabled. But you need an IP address as the target (or maybe a range ?). If I was a bad actor I think i would want to first find out via “quick and dirty” (aka ICMP ping/echo) what devices within a IP range were online before attempting specific port scan instead of wasting port scans on a non-existing device.
Is it possible to firewall “allow” ICMP echo for specific IP’s and block unknowns ?
Again, this is all a “work in progress” learning experience for me, most of it from using ipFire for so many years and reading blog comments such as these.
Thanks folks !
I seriously doubt that a successful attacker just uses a quick and dirty method to really gain access or searching for ip adresses. For such „script kiddies“ the default security should be enough - unless you open ports on RED. Then you have to think about securing these ports - not about icmp echo replies.
In the end I think it all boils down to your threat model. What do you want to defend against? On the low end are the aforementioned script kiddies. On the other end are state level actors which I‘m sure you can‘t really defend against as a private person or small/medium business. The more you move towards the high end the less important are icmp replies.
Yes, the defense in depth approach seems to favor going dark as a first step. But as you make outbound connections your ip will get published (google shodan and ntp for example). So think about securing open ports - if any. And ignore icmp echo replies. Your system will get hit anyway - and is fine with it!
(Sorry for drifting away a bit. If mods think it should be moved/deleted - feel free to do it!)
@dal8moc
Thanks for your input Hagen.
Not drifting away really.
A lot of folks like me like to better understand the reasoning behind some things.
Installing firewalls like ipFire gives us a chance to learn and better ourselves with the knowledge that other more experience folks have to offer.
Thanks
Speaking as someone who works in information security, yes, dropping ICMP can improve your attack surface. The argument that “if you have any ports open they’ll just find you anyway” is an example of a technically correct but practically wrong observation.
Script kiddies generally aren’t scanning thousands of ports on every IP in whatever subnet they’re targeting. That would take a staggering amount of time spent probing a single /16 (over 65k usable IPs), let alone any significant chunk of the internet. A far more common approach is to ping an IP and then proceed with probing only if the IP responds. This not only saves a monumental amount of time but also reduces the risk of the scanning IP(s) being blacklisted by IDSes.
Blocking ICMP will render that style of scanning useless. It’s been pointed out above that this won’t stop ALL attacks, which is technically correct. So why not let us shut down SOME attacks? Contrary to what’s been suggested above, most users (residential AND enterprise) will not be negatively impacted by blocking ICMP. If the option is presented in the GUI, then those who do have a need can simply turn it back on.
There’s simply no good reason to force ICMP on for everyone, and plenty of good reasons to give us the option to disable it.
There is an option to block ICMP with a firewall rule that any user can create. It is not recommended but it does exist.
I created one (long ago) but I noticed it did cause problems with OpenVPN. So I deleted the rule. I am not sure if there are other issues with an ICMP firewall rule block