Ok to let all ICMP traffic through firewall?

Page 4 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Archived from groups: comp.security.firewalls,uk.telecom.broadband,comp.security.misc,alt.computer.security (More info?)

In article <sxodvi$bk9$r@ddka.demon.co.uk>, a031003
${dd}.nospam@ddka.invalid says...
> On Sun, 25 Sep 2005 20:09:12 GMT, Leythos
> <void@nowhere.lan> wrote:
>
> > Errors are not fixed by ICMP and are not going to cause a failure in
> > communications. You can still get the data.
>
> Errors may not be "fixed" by ICMP but ICMP may just tell you what you need to
> do in order to fix something - e.g. ICMP type 3 codes 4, 11 and 12. If you
> trash the ICMP response then you may end up with a failed connection which
> would have otherwise worked without any problem - so no - ignoring ICMP does
> not mean that you still get the data in all circumstances.

I agree, but since we allow ICMP to approved sites/connections, but
block it to the rest of the world, it doesn't really matter if there is
a problem for the blocked ones - see the point now?

--

spam999free@rrohio.com
remove 999 in order to email me
 
Archived from groups: comp.security.firewalls,uk.telecom.broadband,comp.security.misc,alt.computer.security (More info?)

In article <MPG.1da0ce0767ee57f198a124@news-server.columbus.rr.com>,
Leythos <void@nowhere.lan> wrote:
>Errors are not fixed by ICMP and are not going to cause a failure in
>communications. You can still get the data.

What the hell are you talking about, or are you being deliberately
obtuse? At some time in the future your company may be in a position
where data isn't getting through because of a problem in the intervening
path, and the the only way an intermediate device can advise you of the
reason is by sending ICMP. Which it sounds like you are filtering out.

Mike
 
Archived from groups: comp.security.firewalls,uk.telecom.broadband,comp.security.misc,alt.computer.security (More info?)

In article <dh77ma$odf$1@lucy.duncodin.org>, mike@duncodin.org says...
> In article <MPG.1da0ce0767ee57f198a124@news-server.columbus.rr.com>,
> Leythos <void@nowhere.lan> wrote:
> >Errors are not fixed by ICMP and are not going to cause a failure in
> >communications. You can still get the data.
>
> What the hell are you talking about, or are you being deliberately
> obtuse? At some time in the future your company may be in a position
> where data isn't getting through because of a problem in the intervening
> path, and the the only way an intermediate device can advise you of the
> reason is by sending ICMP. Which it sounds like you are filtering out.

If that happens, then "at some time in the future" I will adjust the
settings. Until a time when it causes a problem we will leave it
unavailable.


--

spam999free@rrohio.com
remove 999 in order to email me
 
Archived from groups: comp.security.firewalls,comp.security.misc,alt.computer.security (More info?)

You totally missed the point of what Dave Civil was trying to say!!

Leythos wrote:
> In article <sxodvi$bk9$r@ddka.demon.co.uk>, a031003
> ${dd}.nospam@ddka.invalid says...
>
>>On Sun, 25 Sep 2005 20:09:12 GMT, Leythos
>><void@nowhere.lan> wrote:
>>
>>
>>>Errors are not fixed by ICMP and are not going to cause a failure in
>>>communications. You can still get the data.
>>
>>Errors may not be "fixed" by ICMP but ICMP may just tell you what you need to
>>do in order to fix something - e.g. ICMP type 3 codes 4, 11 and 12. If you
>>trash the ICMP response then you may end up with a failed connection which
>>would have otherwise worked without any problem - so no - ignoring ICMP does
>>not mean that you still get the data in all circumstances.
>
>
> I agree, but since we allow ICMP to approved sites/connections, but
> block it to the rest of the world, it doesn't really matter if there is
> a problem for the blocked ones - see the point now?
>
 
Archived from groups: comp.security.firewalls,comp.security.misc,alt.computer.security (More info?)

In article <DOidnXTOtsjWvKreRVnyuw@eclipse.net.uk>, sjw@stevew.net
says...
> You totally missed the point of what Dave Civil was trying to say!!

No I didn't, we are just talking about two different methods/needs. My
needs require that I provide ICMP responses to the world, and in many
cases, neither do most that don't provide public services to the world.

If I had a website I would allow "some" forms of ICMP, but you have to
ask yourself why you need to provide communications with people you
don't want to communicate with.


--

spam999free@rrohio.com
remove 999 in order to email me
 
Archived from groups: comp.security.firewalls,uk.telecom.broadband,comp.security.misc,alt.computer.security (More info?)

In article <dh77ma$odf$1@lucy.duncodin.org>,
Mike Civil <mike@duncodin.org> wrote:
:What the hell are you talking about, or are you being deliberately
😱btuse? At some time in the future your company may be in a position
:where data isn't getting through because of a problem in the intervening
😛ath, and the the only way an intermediate device can advise you of the
:reason is by sending ICMP. Which it sounds like you are filtering out.

If the routing infrastructure he is using enters a routing loop, then

a) there is a substantial chance that the ICMP TTL Exceeded won't
get back either; and

b) the NOC for the intrastructure is likely going to find out and act on it
faster than he would get a page saying "TTL exceeded" and log in
and track down the cause and call the NOC.

If the routing infrastructure does not enter a routing loop, but loses
the route, then if he has multiple routes then his routing protocol
is going to notice the problem and adjust automatically. There are no
routing protocols that I can think of that use icmp to determine whether
the routing is working or not.

If the route is lost and he has only a single route, then his monitoring
software is going to stop hearing back from the other side, and he
will get an appropriate notification and will investigate. That
investigation might be helped by the availability of icmp; if so
then he can turn reception of icmp on at the time.
--
When Love is gone, there's always Justice.
When Justice is gone, there's always Force.
When Force is gone, there's always Mom. -- Laurie Anderson
 
Archived from groups: comp.security.firewalls (More info?)

In article <433635a6@news.uni-ulm.de>, Volker Birk <bumens@dingens.org> wrote:
>jameshanley39@yahoo.co.uk wrote:

>> If
>> stealth gives no response whatsoever, then surely 'unable to determine'
>> is the best that either an onlien scanner or nmap can give.

>Because there will come an ICMP type 3 with code 0 or 1, if there is no
>host, and there is coming no such packet, there is a host. Because there
>is no TCP RST and no ICMP type 3 with code 3 coming back, the port is
>"stealthed".

If you get no answer, all you know is that -something- along the way
either did not generate a response or else that something dropped
the response. That "something" is not necessarily the end host.

Our firewall drops icmp echo packets to hosts we don't permit echo
to. No response is generated at all. That doesn't tell you whether
the host exists or not.
--
University of Calgary researcher Christopher Auld has found that
milk is the most "rational addiction" amongst the several studied.
 
Archived from groups: comp.security.firewalls (More info?)

Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:
> If you get no answer, all you know is that -something- along the way
> either did not generate a response or else that something dropped
> the response. That "something" is not necessarily the end host.

Yes, of course. And if I send IP packets over a line, where the other
hosts only understand IPX, then I will not get a response either. But
what should that explain?

We're talking about the TCP/IP protocol family here, aren't we?

> Our firewall drops icmp echo packets to hosts we don't permit echo
> to. No response is generated at all. That doesn't tell you whether
> the host exists or not.

And we're not talking about ICMP echo.

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"
 
Archived from groups: comp.security.firewalls,uk.telecom.broadband,comp.security.misc,alt.computer.security (More info?)

Art <null@zilch.com> wrote:
[...]
> Speaking of pinging:
> http://www.worldnetdaily.com/news/article.asp?ARTICLE_ID=46501

Where does it say that the NSA's patent requires ICMP pings?

Without reading the patent, I'd put money on it using all forms of IP
traffic rather than just a specific protocol.

--
PGP key ID E85DC776 - finger abuse@mooli.org.uk for full key
/:.*posting.google.com.*/HX-Trace:+j
 
Archived from groups: comp.security.firewalls,comp.security.misc (More info?)

Peter Boosten wrote:

> In comp.security.firewalls Mark <nothere@notthere.com> wrote:
>
>>
>>Yes it is, ever heard of PING NMAP?
>>
>>Google it and security and firewalls.
>>
>
>
> or PING of Death?
>
My (hazy) memory seems to recall that the POD only affected the stack on
certain Win95 clients.
E.
 
Archived from groups: comp.security.firewalls,comp.security.misc (More info?)

Mike Civil wrote:

> In article <MPG.1da0ce0767ee57f198a124@news-server.columbus.rr.com>,
> Leythos <void@nowhere.lan> wrote:
>
>>Errors are not fixed by ICMP and are not going to cause a failure in
>>communications. You can still get the data.
>
>
> What the hell are you talking about, or are you being deliberately
> obtuse? At some time in the future your company may be in a position
> where data isn't getting through because of a problem in the intervening
> path, and the the only way an intermediate device can advise you of the
> reason is by sending ICMP. Which it sounds like you are filtering out.
>
> Mike

A problem with an upstream route or router is in what is called an SEP
field: Someone Else's Problem. There is no way you could do anything
yourself to fix it as you don't have access. I have been in exactly the
situation you describe (random routing dropouts in a VPN path) and the
SEP rule applied. The solution was to contact the ISP that owned the box
(the E in SEP) and have them fix it.

The cause in this instance was a box on the border of 2 network types
(ADSL and VDSL) stopping routing properly between the 2 networks
whenever a techo from the VDSL backbone provider logged in to it.

The diagnosis for this obviously required echo replies back in. Also
having traceroute data for the path most traffic would take under normal
circumstances recorded to enable future diags. I basically rang the ISP
involved and said traffic from A to B is failing between boxes X and Y.

My understanding of Leythos' statements is that ICMP is allowed between
those he trusts, outbound is allowed, but unsolicited inbound from every
other sod on the planet is dropped. Which seems normal to me.

Interestingly enough, after the Welchia type worms that came out most,
if not all, ISP's blocked pings going into and out of their network
ranges in this country. Tracert is also badly affected, which makes
diagnostics a nightmare at times.
E.