[pfSense] icmp best practices

[Ugo Bellavance]

Hi,

The system I inherited of denies all ICMP requests by default, even
internally. Is that a good idea? I think that echo/reply should at
least be allowed internally. Opinions?

Thanks,

Ugo

[David Burgess]

Post by Ugo Bellavance
Hi,
The system I inherited of denies all ICMP requests by default, even
internally. Is that a good idea? I think that echo/reply should at least
be allowed internally. Opinions?

I'm probably wrong, but I'm not aware of any common ICMP exploits, and it
has proven handy many times while troubleshooting. I have it enabled on all
my interfaces. You'll note that some big players (Google), and some very
security-minded people (grc.com, kaspersky.com) leave it enabled, while
others (microsoft.com, pfsense.org) do not.

db

[David Burgess]

I have it enabled on all my interfaces

I should clarify by saying that I allow ICMP echo requests on all
interfaces, not all ICMP. This does not appear to prevent me from receiving
other types of ICMP packets, as I can successfully ping other host, perform
traceroute, etc, despite the fact that I don't explicitly allow echo reply
or time exceeded packets on those interfaces.

db

[Adam Thompson]

Denying ICMP is mainly only useful in the Security By Obscurity model.
There are many valid reasons to allow ICMP, especially from the inside, and in my opinion we all may as well get used to allowing it, since blocking ICMPv6 will effectively not be possible.
-Adam

Post by Ugo Bellavance
Hi,
The system I inherited of denies all ICMP requests by default, even
internally. Is that a good idea? I think that echo/reply should at
least be allowed internally. Opinions?
Thanks,
Ugo
_______________________________________________
List mailing list
http://lists.pfse

[Seth Mos]

Hi,

Post by Adam Thompson
Denying ICMP is mainly only useful in the Security By Obscurity model.
There are many valid reasons to allow ICMP, especially from the inside, and in my opinion we all may as well get used to allowing it, since blocking ICMPv6 will effectively not be possible.

in 2.1 we allow echo for link-local always on all interfaces. It is also impossible to block a few other ICMPv6 types in 2.1 because it would cause general network issues.

We don't allow echo requests for global addresses per default though.

But blocking ICMPv6 outright is bad m'kay

It never worked properly in v4 either. I have a rather large LAN but I have a blanket icmp allow rule as well. If your network is larger then a few nets it's not worth the effort.

I do have icmpv6 block echo rules for incoming traffic though. But that's about it.

Cheers,

Seth

Post by Adam Thompson
-Adam

Post by Ugo Bellavance
Hi,
The system I inherited of denies all ICMP requests by default, even
internally. Is that a good idea? I think that echo/reply should at
least be allowed internally. Opinions?
Thanks,
Ugo
_______________________________________________
List mailing list
http://lists.pfsense.org/mailman/listinfo/list

_______________________________________________
List mailing list
http://lists.pfsense.org/mailman/listinfo/list

[Moshe Katz]

Post by Adam Thompson
Denying ICMP is mainly only useful in the Security By Obscurity model.
There are many valid reasons to allow ICMP, especially from the inside,
and in my opinion we all may as well get used to allowing it, since
blocking ICMPv6 will effectively not be possible.
-Adam

Post by Ugo Bellavance
Hi,
The system I inherited of denies all ICMP requests by default, even
internally. Is that a good idea? I think that echo/reply should at
least be allowed internally. Opinions?
Thanks,
Ugo

I have ICMP blanket allowed on both pfSense installations that I have (home
and work).

We use it for easy troubleshooting - if a service from our network is down,
the first thing we check is whether we can ping the pfSense and the
1:1-NAT'ed box from outside. Then, based on whether it is down or up, we
can continue to troubleshoot.

As a byproduct, I can troubleshoot internet connectivity for my relatives
and friends by pinging my servers in addition to publicly available servers
like google.com.

I have heard that the reason Google keeps ICMP open is for marketing. If
you know that you can ping Google to help troubleshoot your internet
connectivity, you just remember Google for one more thing they can help you
with.

Moshe

--
Moshe Katz
-- ***@ymkatz.net
-- [phone]

[Chris Bagnall]

Post by Moshe Katz
I have ICMP blanket allowed on both pfSense installations that I have (home
and work).

+1. We have an ICMP Echo blanket allow rule on all our pfSense
deployments (several dozen).

As others have indicated, it's a useful troubleshooting tool, and also a
useful performance indicator: we run periodic pings to the pfSense boxes
from Zabbix to monitor uptime and connection latency (particularly
useful for clients who don't use us as their ISP - so we can't get
connection stats from RADIUS logs and the like).

As most connections in the UK are PPPoA, and there's an ADSL modem in
front of the pfSense box, it's also useful to be able to monitor both
independently: if the modem is up, but pfSense is down, we can tell the
end user to reboot the pfSense box; if both are down, then restart the
ADSL modem, and if they're still down, it's probably the connection.

Kind regards,

Chris

[Ugo Bellavance]

Post by Moshe Katz
I have ICMP blanket allowed on both pfSense installations that I have (home
and work).

By blanket rule, you mean a floating rule allowing icmp echo/reply?

[Moshe Katz]

Post by Ugo Bellavance

Post by Moshe Katz
I have ICMP blanket allowed on both pfSense installations that I have (home
and work).

By blanket rule, you mean a floating rule allowing icmp echo/reply?

We've been doing this since before Floating Rules existed so we have a rule
on each interface - but a floating rule should probably work.

Moshe

--
Moshe Katz
-- ***@ymkatz.net
-- [phone]

[Nachtfalke]

Von: list-***@lists.pfsense.org [mailto:list-***@lists.pfsense.org] Im Auftrag von Moshe Katz
Gesendet: Dienstag, 20. März 2012 16:43
An: pfSense support and discussion
Betreff: Re: [pfSense] icmp best practices

On Tue, Mar 20, 2012 at 8:05 AM, Ugo Bellavance <***@lubik.ca> wrote:
On 2012-03-20 07:25, Chris Bagnall wrote:
On 19/3/12 11:54 pm, Moshe Katz wrote:
I have ICMP blanket allowed on both pfSense installations that I have
(home
and work).

By blanket rule, you mean a floating rule allowing icmp echo/reply?


We've been doing this since before Floating Rules existed so we have a rule on each interface - but a floating rule should probably work.

Moshe


--
Moshe Katz
-- ***@ymkatz.net
-- [phone]



For security issues you should think about "Tunneling IP traffic over ICMP". So allowing ping top the world could be a risk but probably ping the GW/pfsense is not a big problem.

http://en.wikipedia.org/wiki/ICMP_tunnel

Nachtfalke

[Chris Bagnall]

Post by Nachtfalke
For security issues you should think about "Tunneling IP traffic over ICMP". So allowing ping top the world could be a risk but probably ping the GW/pfsense is not a big problem.
http://en.wikipedia.org/wiki/ICMP_tunnel

I've only skim-read it, but doesn't that rely on the cooperation of both
the source and destination machines?

I suspect that if a machine in your local network has been compromised
to that extent, you've got bigger fish to fry than rogue ICMP tunnels :-)

Kind regards,

Chris

[Andy Holzrichter]

Most networks have been compromised to that extent if you have users. From what I've read it'd be easy enough for a talented user to setup a connection to an outside machine w/ that. They could then send data/surf/whatever through the tunnel. Of course large amounts of ICMP traffic to one machine in the outside world would be a giveaway, but most small office environments would never detect that.



-----Original Message-----
From: list-***@lists.pfsense.org [mailto:list-***@lists.pfsense.org] On Behalf Of Chris Bagnall
Sent: Tuesday, March 20, 2012 2:00 PM
To: ***@lists.pfsense.org
Subject: Re: [pfSense] icmp best practices

Post by Nachtfalke
For security issues you should think about "Tunneling IP traffic over ICMP". So allowing ping top the world could be a risk but probably ping the GW/pfsense is not a big problem.
http://en.wikipedia.org/wiki/ICMP_tunnel

I've only skim-read it, but doesn't that rely on the cooperation of both the source and destination machines?

I suspect that if a machine in your local network has been compromised to that extent, you've got bigger fish to fry than rogue ICMP tunnels :-)

Kind regards,

Chris

[Nachtfalke]

I an environment where you can control all hosts there will be probably no
problem with ICMP tunnels but think about environments where people are
allowed to use their own hosts, laptops (hotel, hotspot, ...)

That's why I said:
ICMP from host to GW is OK
ICMP from host to the world - should be blocked - or just allowed for the
administrator's host

That's the same I do with DNS (53). Just allow my pfsense as DNS but not to
the world for every host.
That would be DNS Tunneling ;-)
http://dnstunnel.de/

But I think this depends on how paranoid you are ;-)

Nachtfalke

-----Ursprüngliche Nachricht-----
Gesendet: Dienstag, 20. März 2012 21:22
An: pfSense support and discussion
Betreff: Re: [pfSense] icmp best practices
Most networks have been compromised to that extent if you have users.

[Nathan Eisenberg]

Post by Nachtfalke
ICMP from host to GW is OK
ICMP from host to the world - should be blocked - or just allowed for
the
administrator's host

So you break PMTUd and basic diagnostic functionality for your users? That seems mean, and utterly pointless. If you *really* think there's a security issue, rate limit ICMP, but don't block it.

Nathan Eisenberg

[Chris Buechler]

On Tue, Mar 20, 2012 at 7:37 PM, Nathan Eisenberg

Post by Nachtfalke
ICMP from host to GW is OK
ICMP from host to the world - should be blocked - or just allowed for
the
administrator's host

So you break PMTUd and basic diagnostic functionality for your users?  That
seems mean, and utterly pointless.  If you *really* think there's a security
issue, rate limit ICMP, but don't block it.

Depends on what you're blocking it with and how it handles things.
Throwing a block all icmp in on PF it will still let ICMP messages
associated with a permitted connection through, so it doesn't break
things.

[Frank Heydlauf]

Hi Chris,

On Tue, Mar 20, 2012 at 10:14:54PM -0400, Chris Buechler wrote:
...

Post by Chris Buechler

So you break PMTUd and basic diagnostic functionality for your users?  That
seems mean, and utterly pointless.  If you *really* think there's a security
issue, rate limit ICMP, but don't block it.

...

Post by Chris Buechler
Depends on what you're blocking it with and how it handles things.
Throwing a block all icmp in on PF it will still let ICMP messages
associated with a permitted connection through, so it doesn't break
things.

A PMTUD icmp packet is not associated with any outgoing connection.
You will have to explicitly allow incoming icmp type 3 code 4.

Backing Nathan I have to say: yes, PMTU is a relevant topic.
Especially for DSL (or mobile) users where the MTU is commonly
<1500 (often 1492 or even 1452 for DSL).
And: this is not only for outgoing connections but also for
incoming connections if you provide any service as i.e. a mail- or
webserver. Every Client sitting outside behind a tunnel which
sets DF bit will get problems.
Typical example: small test-mails work, bigger not. Very nice to
debug :-/