Sign in with
Sign up | Sign in
Your question

Ok to let all ICMP traffic through firewall?

Last response: in Networking
Share
September 23, 2005 3:14:14 AM

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

My question is Should a firewall let all ICMP traffic through because
there is no real risk if they do?

+++++

Here is the thinking behind my question: Robin Walker's cable modem
webpages at
<http://homepage.ntlworld.com/robin.d.h.walker/cmtips/in...;
look to me as if they are technically sound. But they are a few
years old. I would like to know what people think about the advice
he gives about ICMP traffic and if it is still true these days.

He suggests that firewalls should let all ICMP traffic through and
that there is no real risk if they do that. At
http://snipurl.com/hvox he writes the following section. I have cut
it down a bit.


------------------- START QUOTE -----------------

STEALTH-MODE FIREWALLS CONSIDERED HARMFUL

Some firewalls have a hiding mechanism they call stealth. ... In
stealth mode, the firewall causes the PC just to ignore incoming
connection attempts, rather than rejecting them, as would be normal
for incoming connection attempts to closed ports.

.... causes some difficulties. For a start, Internet standard RFC 1122
states categorically about ICMP Echoes (ping):

"3.2.2.6 Echo Request/Reply: RFC-792. Every
host MUST implement an ICMP Echo server function
that receives Echo Requests and sends
corresponding Echo Replies."

So you are strongly advised not to apply stealth techniques to the
ICMP protocol.

A commonly heard objection to allowing ICMP Echo Replies is that it
gives away information to hackers that there is a live connection on
this IP address. Such objections are not well-founded, and can be
safely ignored.

There is no evidence in practice that any hacker has been aided by
the presence of an ICMP Echo Reply.

Hackers do not typically write code that tests an address with ICMP
Echo before launching a hostile probe: they always send the hostile
probe directly: either it works or it doesn't, and information from
ICMP adds nothing to the analysis.

------------------- END QUOTE -----------------

So Should a firewall let all ICMP traffic through? Is it ok to do
that?

More about : icmp traffic firewall

Anonymous
a b 8 Security
September 23, 2005 3:14:15 AM

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

In article <96D9EC61DFA1E71F3M4@66.250.146.159>, no_thanks@mail.com
says...
> My question is Should a firewall let all ICMP traffic through because
> there is no real risk if they do?

The common sense rule is to LET NOTHING IN that doesn't have a good
reason to be let in.

Why do you want to take a minimal risk if you don't have too?

--

spam999free@rrohio.com
remove 999 in order to email me
September 23, 2005 3:14:15 AM

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

Franklin <no_thanks@mail.com> wrote:
> My question is Should a firewall let all ICMP traffic through
> because there is no real risk if they do?

No, because some ICMP messages aren't useful. However blocking all
ICMP is throwing the baby out with the bathwater and will cause more
bother than not blocking anything.

I would suggest allowing ICMP Echo and Echo Reply (so ping works),
Destination Unreachable (which includes "fragmentation required",
essential for PMTUD to work) and Time Exceeded (so traceroute works.)
Everything else looks to be fair game to drop.

While I'm suggesting firewall rules, can people also not silently drop
SYNs to port 113 please? All sorts of servers try RFC1413 lookups and
stall while waiting for a response. The firewall user is usually the
first to complain that it's taking ages to connect to a certain remote
server.

--
PGP key ID E85DC776 - finger abuse@mooli.org.uk for full key
/:.*posting.google.com.*/HX-Trace:+j
Related resources
Can't find your answer ? Ask !
September 23, 2005 3:14:15 AM

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

Franklin wrote:

> My question is Should a firewall let all ICMP traffic through because
> there is no real risk if they do?
>
> +++++
>
> Here is the thinking behind my question: Robin Walker's cable modem
> webpages at
> <http://homepage.ntlworld.com/robin.d.h.walker/cmtips/in...;
> look to me as if they are technically sound. But they are a few
> years old. I would like to know what people think about the advice
> he gives about ICMP traffic and if it is still true these days.
>
> He suggests that firewalls should let all ICMP traffic through and
> that there is no real risk if they do that. At
> http://snipurl.com/hvox he writes the following section. I have cut
> it down a bit.
>
>
> ------------------- START QUOTE -----------------
>
> STEALTH-MODE FIREWALLS CONSIDERED HARMFUL
>
> Some firewalls have a hiding mechanism they call stealth. ... In
> stealth mode, the firewall causes the PC just to ignore incoming
> connection attempts, rather than rejecting them, as would be normal
> for incoming connection attempts to closed ports.
>
> ... causes some difficulties. For a start, Internet standard RFC 1122
> states categorically about ICMP Echoes (ping):
>
> "3.2.2.6 Echo Request/Reply: RFC-792. Every
> host MUST implement an ICMP Echo server function
> that receives Echo Requests and sends
> corresponding Echo Replies."
>
> So you are strongly advised not to apply stealth techniques to the
> ICMP protocol.
>
> A commonly heard objection to allowing ICMP Echo Replies is that it
> gives away information to hackers that there is a live connection on
> this IP address. Such objections are not well-founded, and can be
> safely ignored.
>
> There is no evidence in practice that any hacker has been aided by
> the presence of an ICMP Echo Reply.
>
> Hackers do not typically write code that tests an address with ICMP
> Echo before launching a hostile probe: they always send the hostile
> probe directly: either it works or it doesn't, and information from
> ICMP adds nothing to the analysis.
>
> ------------------- END QUOTE -----------------
>
> So Should a firewall let all ICMP traffic through? Is it ok to do
> that?

Some ICMPs are needed for proper TCP/UDP/IP functionality. I typically allow
icmp source quench and destination not reachables through and block
everything else (incoming)....

Imhotep
Anonymous
a b 8 Security
September 23, 2005 3:14:16 AM

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

On Thu, 22 Sep 2005 22:19:07 UTC, Leythos <void@nowhere.lan> wrote:

> In article <96D9EC61DFA1E71F3M4@66.250.146.159>, no_thanks@mail.com
> says...
> > My question is Should a firewall let all ICMP traffic through because
> > there is no real risk if they do?
>
> The common sense rule is to LET NOTHING IN that doesn't have a good
> reason to be let in.

In practice, you need to let a few ICMP messages through, then. For
example, source quench and destination unreachable.

--
[ 7'ism - a condition by which the sufferer experiences an inability
to give concise answers, express reasoned argument or opinion.
Usually accompanied by silly noises and gestures - incurable, early
euthanasia recommended. ]
Anonymous
a b 8 Security
September 23, 2005 3:14:16 AM

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

In article <433331d9$0$32652$da0feed9@news.zen.co.uk>,
Peter <abuse@dopiaza.cabal.org.uk> wrote:
:However blocking all
:ICMP is throwing the baby out with the bathwater and will cause more
:bother than not blocking anything.

"more bother" depends on whether you are being deliberately attacked
or not.


:I would suggest allowing ICMP Echo and Echo Reply (so ping works),

Typically, outsiders have no business mapping out exactly which
of your systems exist or are up right now, so dropping most incoming icmp
echo is a common security precaution. Whether to allow icmp echo
to public-facing servers varies with circumstance.

--
If you like, you can repeat the search with the omitted results included.
Anonymous
a b 8 Security
September 23, 2005 3:14:17 AM

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

In article <176uZD2KcidF-pn2-dTdiDpVF9eQ2@rikki.tavi.co.uk>,
Bob Eager <rde42@spamcop.net> wrote:
:In practice, you need to let a few ICMP messages through, then. For
:example, source quench and destination unreachable.

In practice, crackers will send you unsolicited source quenches,
either as a side effect of them DoS'ing the host with forged packets,
or else with the hope of DoS'ing you by interfering with your flow
of traffic to other locations.

In practice, you don't need to listen to source quench. If you
are sending data too quickly for a router, the router will drop
some of the traffic. If the traffic was TCP then the normal TCP
recovery mechanisms will kick in and will act to slow down your
rate of transmission. If the traffic was UDP or anything other
"unreliable" protocol, then by definition the transmissions are
expected to be unreliable so dropping the traffic should not be
important. [If it -was- important, then you shouldn't be using an
unreliable transmission protocol.]
--
Goedel's Mail Filter Incompleteness Theorem:
In any sufficiently expressive language, with any fixed set of
email filtering algorithms, there exists at least one spam message
which the algorithms are unable to filter out.
Anonymous
a b 8 Security
September 23, 2005 3:14:17 AM

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

In article <176uZD2KcidF-pn2-dTdiDpVF9eQ2@rikki.tavi.co.uk>, rde42
@spamcop.net says...
> On Thu, 22 Sep 2005 22:19:07 UTC, Leythos <void@nowhere.lan> wrote:
>
> > In article <96D9EC61DFA1E71F3M4@66.250.146.159>, no_thanks@mail.com
> > says...
> > > My question is Should a firewall let all ICMP traffic through because
> > > there is no real risk if they do?
> >
> > The common sense rule is to LET NOTHING IN that doesn't have a good
> > reason to be let in.
>
> In practice, you need to let a few ICMP messages through, then. For
> example, source quench and destination unreachable.

Wrong, you don't NEED to allow anything. You may FEEL that you do, but
we've got almost 100 networks that don't allow ICMP or anything else
inbound and they work just fine, and we'll not change them.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
a b 8 Security
September 23, 2005 3:17:15 AM

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

In article <433331d9$0$32652$da0feed9@news.zen.co.uk>,
abuse@dopiaza.cabal.org.uk says...
> Franklin <no_thanks@mail.com> wrote:
> > My question is Should a firewall let all ICMP traffic through
> > because there is no real risk if they do?
>
> No, because some ICMP messages aren't useful. However blocking all
> ICMP is throwing the baby out with the bathwater and will cause more
> bother than not blocking anything.
>
> I would suggest allowing ICMP Echo and Echo Reply (so ping works),
> Destination Unreachable (which includes "fragmentation required",
> essential for PMTUD to work) and Time Exceeded (so traceroute works.)
> Everything else looks to be fair game to drop.
>
> While I'm suggesting firewall rules, can people also not silently drop
> SYNs to port 113 please? All sorts of servers try RFC1413 lookups and
> stall while waiting for a response. The firewall user is usually the
> first to complain that it's taking ages to connect to a certain remote
> server.

There is NO BOTHER - you set the rules and then let them work. You don't
need to allow PING, in fact why the heck would you want to allow PING,
it's not like it's a valid test that your network is alive - we've got
tons of commercial networks that block PING and none of the users even
notice.

Allowing anything inbound, even to the firewall, that doesn't
specifically need to be let in is a bad move.

Allowing in minimal traffic that "might" not be a threat is like
trusting Windows Firewall with File/Printer sharing enabled on a
computer directly connected to the Internet with all of your financial
data stored on it in a text file that is name "ALL MY FINANCIAL
DATA.TXT" sitting in the root.

--

spam999free@rrohio.com
remove 999 in order to email me
September 23, 2005 3:23:16 AM

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

Leythos wrote:

> In article <433331d9$0$32652$da0feed9@news.zen.co.uk>,
> abuse@dopiaza.cabal.org.uk says...
>> Franklin <no_thanks@mail.com> wrote:
>> > My question is Should a firewall let all ICMP traffic through
>> > because there is no real risk if they do?
>>
>> No, because some ICMP messages aren't useful. However blocking all
>> ICMP is throwing the baby out with the bathwater and will cause more
>> bother than not blocking anything.
>>
>> I would suggest allowing ICMP Echo and Echo Reply (so ping works),
>> Destination Unreachable (which includes "fragmentation required",
>> essential for PMTUD to work) and Time Exceeded (so traceroute works.)
>> Everything else looks to be fair game to drop.
>>
>> While I'm suggesting firewall rules, can people also not silently drop
>> SYNs to port 113 please? All sorts of servers try RFC1413 lookups and
>> stall while waiting for a response. The firewall user is usually the
>> first to complain that it's taking ages to connect to a certain remote
>> server.
>
> There is NO BOTHER - you set the rules and then let them work. You don't
> need to allow PING, in fact why the heck would you want to allow PING,
> it's not like it's a valid test that your network is alive - we've got
> tons of commercial networks that block PING and none of the users even
> notice.
>
> Allowing anything inbound, even to the firewall, that doesn't
> specifically need to be let in is a bad move.
>
> Allowing in minimal traffic that "might" not be a threat is like
> trusting Windows Firewall with File/Printer sharing enabled on a
> computer directly connected to the Internet with all of your financial
> data stored on it in a text file that is name "ALL MY FINANCIAL
> DATA.TXT" sitting in the root.
>

LOL...

Imhotep
Anonymous
a b 8 Security
September 23, 2005 3:48:58 AM

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

"Leythos" <void@nowhere.lan> wrote in message
news:MPG.1d9d059680e4dd98a0fd@news-server.columbus.rr.com...
> In article <433331d9$0$32652$da0feed9@news.zen.co.uk>,
> abuse@dopiaza.cabal.org.uk says...
> > Franklin <no_thanks@mail.com> wrote:
> > > My question is Should a firewall let all ICMP traffic through
> > > because there is no real risk if they do?

<snip>

> You don't
> need to allow PING, in fact why the heck would you want to allow PING,
> it's not like it's a valid test that your network is alive - we've got
> tons of commercial networks that block PING and none of the users even
> notice.

Undoubtedly the case. Although one could quote lots of instances where it's
been damned useful.

Well, *I* certainly can - usually when the web server has had a bit of a
funny turn, and one needs to tell if it's the server behind the firewall
(fat chance of fixing something from an adjacent continent), or whether it's
the ISP playing silly buggers with the connection (marginally more hope of
getting something sorted).

As goes firewalls - I'm sure that most have already seen it, but:
http://www.dilbert.com/comics/dilbert/archive/images/di...

--

Hairy One Kenobi

Disclaimer: the opinions expressed in this opinion do not necessarily
reflect the opinions of the highly-opinionated person expressing the opinion
in the first place. So there!
Anonymous
a b 8 Security
September 23, 2005 4:24:41 AM

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

In article <KpHYe.4417$_56.2350@newsfe1-win.ntli.net>, abuse@[127.0.0.1]
says...
> "Leythos" <void@nowhere.lan> wrote in message
> news:MPG.1d9d059680e4dd98a0fd@news-server.columbus.rr.com...
> > In article <433331d9$0$32652$da0feed9@news.zen.co.uk>,
> > abuse@dopiaza.cabal.org.uk says...
> > > Franklin <no_thanks@mail.com> wrote:
> > > > My question is Should a firewall let all ICMP traffic through
> > > > because there is no real risk if they do?
>
> <snip>
>
> > You don't
> > need to allow PING, in fact why the heck would you want to allow PING,
> > it's not like it's a valid test that your network is alive - we've got
> > tons of commercial networks that block PING and none of the users even
> > notice.
>
> Undoubtedly the case. Although one could quote lots of instances where it's
> been damned useful.
>
> Well, *I* certainly can - usually when the web server has had a bit of a
> funny turn, and one needs to tell if it's the server behind the firewall
> (fat chance of fixing something from an adjacent continent), or whether it's
> the ISP playing silly buggers with the connection (marginally more hope of
> getting something sorted).
>
> As goes firewalls - I'm sure that most have already seen it, but:
> http://www.dilbert.com/comics/dilbert/archive/images/di...

Funny, I don't expose our servers to Ping, and I seem to be able to
monitor them all the time. If I need to expose PING to an external
source I expose it to a specific IP and block all others.

If I have to manage a server, I only allow VPN access inbound to the
firewall it self and use a different password/user than I use for the
server.

Ping is only good when you don't know what else is available and how to
secure it from the public. There is no reason to allow open access to
ICMP or anything else that doesn't have a specific business need (like
HTTP/SSL/FTP/etc...).

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
a b 8 Security
September 23, 2005 4:29:30 AM

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

On Thu, 22 Sep 2005 23:13:55 UTC, Leythos <void@nowhere.lan> wrote:

> > In practice, you need to let a few ICMP messages through, then. For
> > example, source quench and destination unreachable.
>
> Wrong, you don't NEED to allow anything. You may FEEL that you do, but
> we've got almost 100 networks that don't allow ICMP or anything else
> inbound and they work just fine, and we'll not change them.

You're wrong. But that's fine. You just carry on.

--
[ 7'ism - a condition by which the sufferer experiences an inability
to give concise answers, express reasoned argument or opinion.
Usually accompanied by silly noises and gestures - incurable, early
euthanasia recommended. ]
Anonymous
a b 8 Security
September 23, 2005 4:33:29 AM

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

In article <176uZD2KcidF-pn2-yKJP7XquDBiB@rikki.tavi.co.uk>, rde42
@spamcop.net says...
> On Thu, 22 Sep 2005 23:13:55 UTC, Leythos <void@nowhere.lan> wrote:
>
> > > In practice, you need to let a few ICMP messages through, then. For
> > > example, source quench and destination unreachable.
> >
> > Wrong, you don't NEED to allow anything. You may FEEL that you do, but
> > we've got almost 100 networks that don't allow ICMP or anything else
> > inbound and they work just fine, and we'll not change them.
>
> You're wrong. But that's fine. You just carry on.

Then, when we're running along for the last few years, blocking all ICMP
inbound and at the firewall, what are we denying ourselves?

It seems that our networks work, that we can VPN into the office just
fine, etc...

It seems that all of our dedicated IPSec tunnels to partners work fine,
it seems that our systems with web servers, OWA services, etc.. all work
just fine.....

--

spam999free@rrohio.com
remove 999 in order to email me
September 23, 2005 4:33:30 AM

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

<jameshanley39@yahoo.co.uk> wrote in message
news:1127439270.085843.66150@z14g2000cwz.googlegroups.com...
> and they'd still work fine if you allowed ICMPs. If allowing ICMPs
> were dangerous then alarms would've been sent off long ago. ICMP has
> been aroudn for ages, there are no new developments to the ICMP
> protocol. People that know all about how it works also know of no
> alarms saying it can be attacked. People that know ICMP presumably
> allow it because they know it's as dangerous as moving an icon slightly
> (which might be very scary for a middle aged woman). (though against
> me, perhaps an OS may rewrite teh part that repsonds to ICMP and there
> might be an exploit in their code, but similarly there may be an
> exploit in their code that is rejecting ICMP)
>
> As that article argued, besides breaking RFCs and breaking the
> protocols,
>
> Besides all those arguments in the article and the technical problems
> with not responding to ICMP (just because your setup doesn't include
> situations where you'll run into the problems, does not mean the
> problems do not exist).
>
> Suppose you want to know if a computer is online. A safe way is to ping
> it. you don't want to set up a service running on the computer and
> conect to it. ping tests that other comps can communicate with the
> comp. it's a necessary diagnostic test. What's the alternative?
> user makes an outgoing connection? suppose he can't for some reason.
> you want to know if he is online
>
> ping is a very convenient diagnostic tool.
>

Yes it is, ever heard of PING NMAP?

Google it and security and firewalls.
Anonymous
a b 8 Security
September 23, 2005 4:57:08 AM

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

Franklin wrote:

> My question is Should a firewall let all ICMP traffic through because
> there is no real risk if they do?
> [...]
> ------------------- START QUOTE -----------------
>
> STEALTH-MODE FIREWALLS CONSIDERED HARMFUL
> [...]
> So Should a firewall let all ICMP traffic through?

No.

> Is it ok to do that?

No. While the example you quoted from the web page is still correct and
there is nothing wrong with echo request and echo reply and the various
destination unreachable messages the are other icmp messages that should be
filted.

http://seclists.org/lists/bugtraq/2005/May/0122.html

Wolfgang
September 23, 2005 5:15:07 AM

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

Leythos wrote:

> In article <176uZD2KcidF-pn2-yKJP7XquDBiB@rikki.tavi.co.uk>, rde42
> @spamcop.net says...
>> On Thu, 22 Sep 2005 23:13:55 UTC, Leythos <void@nowhere.lan> wrote:
>>
>> > > In practice, you need to let a few ICMP messages through, then. For
>> > > example, source quench and destination unreachable.
>> >
>> > Wrong, you don't NEED to allow anything. You may FEEL that you do, but
>> > we've got almost 100 networks that don't allow ICMP or anything else
>> > inbound and they work just fine, and we'll not change them.
>>
>> You're wrong. But that's fine. You just carry on.
>
> Then, when we're running along for the last few years, blocking all ICMP
> inbound and at the firewall, what are we denying ourselves?
>
> It seems that our networks work, that we can VPN into the office just
> fine, etc...
>
> It seems that all of our dedicated IPSec tunnels to partners work fine,
> it seems that our systems with web servers, OWA services, etc.. all work
> just fine.....
>

Honestly, you CAN block all ICMP types, however, it is not optimal. Some
ICMPS are in fact needed for normal TCP/UDP/IP operations (well, efficient
anyway)....ie without flow control, it will appear that things are
"hanging" equating to those nasty users saying the "network is slow"...when
in fact the host has not been informed to slow itself down and as such will
keep on sending packets (which are only being dropped and retransmitted yet
all over again)


Summary: In my opinion, allow a few ICMPS (source quench, and the misc
unreachables) and deny everything else (incoming)....

Just my opinion though,
Imhotep
Anonymous
a b 8 Security
September 23, 2005 11:17:46 AM

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

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?

--
Consultants are mystical people who ask a company for a number and then
give it back to them.

MSN/Mail: pboosten at hotmail dot com
Anonymous
a b 8 Security
September 23, 2005 12:22:54 PM

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

Peter wrote:
> Franklin <no_thanks@mail.com> wrote:
>
>>My question is Should a firewall let all ICMP traffic through
>>because there is no real risk if they do?
>
>
> No, because some ICMP messages aren't useful. However blocking all
> ICMP is throwing the baby out with the bathwater and will cause more
> bother than not blocking anything.
>
> I would suggest allowing ICMP Echo and Echo Reply (so ping works),
> Destination Unreachable (which includes "fragmentation required",
> essential for PMTUD to work) and Time Exceeded (so traceroute works.)
> Everything else looks to be fair game to drop.

But a decent firewall will be stateful - so eg outbound ping will enable
the reply to be received. No-one 'out there' has any business pinging
me so they don't get to do it.

I am well aware it's against the rules, but I block all unsolicited
inbound icmp - never noticed any problems. I'm afraid the rfc's were
drawn up in a less dangerous internet age :-(

>
> While I'm suggesting firewall rules, can people also not silently drop
> SYNs to port 113 please? All sorts of servers try RFC1413 lookups and
> stall while waiting for a response. The firewall user is usually the
> first to complain that it's taking ages to connect to a certain remote
> server.
>
Agreed. A real pain for some smtp servers in particular. My firewall
just sends a reset.

--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk)
Anonymous
a b 8 Security
September 23, 2005 1:10:40 PM

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

In article <1127439270.085843.66150@z14g2000cwz.googlegroups.com>,
jameshanley39@yahoo.co.uk says...
> Leythos wrote:
> > In article <176uZD2KcidF-pn2-yKJP7XquDBiB@rikki.tavi.co.uk>, rde42
> > @spamcop.net says...
> > > On Thu, 22 Sep 2005 23:13:55 UTC, Leythos <void@nowhere.lan> wrote:
> > >
> > > > > In practice, you need to let a few ICMP messages through, then. For
> > > > > example, source quench and destination unreachable.
> > > >
> > > > Wrong, you don't NEED to allow anything. You may FEEL that you do, but
> > > > we've got almost 100 networks that don't allow ICMP or anything else
> > > > inbound and they work just fine, and we'll not change them.
> > >
> > > You're wrong. But that's fine. You just carry on.
> >
> > Then, when we're running along for the last few years, blocking all ICMP
> > inbound and at the firewall, what are we denying ourselves?
> >
> > It seems that our networks work, that we can VPN into the office just
> > fine, etc...
> >
> > It seems that all of our dedicated IPSec tunnels to partners work fine,
> > it seems that our systems with web servers, OWA services, etc.. all work
> > just fine.....
> >
> > --
>
> and they'd still work fine if you allowed ICMPs. If allowing ICMPs
> were dangerous then alarms would've been sent off long ago. ICMP has
> been aroudn for ages, there are no new developments to the ICMP
> protocol. People that know all about how it works also know of no
> alarms saying it can be attacked.
[snip]

So, you're saying that it doesn't break any functionality that we use to
block it, so we should allow it because the designers of it are almost
positive that there is no exploit for it, but, since it's not going to
hurt anything that even though I don't need it, I should allow it, even
though I don't need it......

If I don't need it I don't allow it - it's a very simple matter of
security - never expose anything that you don't need to expose.

--

spam999free@rrohio.com
remove 999 in order to email me
September 23, 2005 1:54:10 PM

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

On 22 Sep 2005 22:36:09 GMT, abuse@dopiaza.cabal.org.uk (Peter) wrote:

>I would suggest allowing ICMP Echo and Echo Reply (so ping works),


Be sure to deny Echo Request that is sent to the broadcast address for
your subnet (.255 and .0 for /24 subnets). If a malicious person
sends several hundred of those per second, you'll wind up with a lot
of ICMP traffic on your subnet as each host tries to send back the
reply.
Anonymous
a b 8 Security
September 23, 2005 4:27:46 PM

Archived from groups: comp.security.misc,comp.security.firewalls (More info?)

In comp.security.firewalls Franklin <no_thanks@mail.com> wrote:
> My question is Should a firewall let all ICMP traffic through because
> there is no real risk if they do?

It does not need to let _all_ ICMP traffic through. But it would be a
good idea not to deny every ICMP traffic.

It is a good idea to allow at least ICMP messages of the
types 0, 3, 4, 8, 11, 12, see RFC 792.

F'up2 comp.security.firewalls.

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"
September 23, 2005 6:11:11 PM

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

Mike Scott <usenet.9@spam.stopper.scottsonline.org.uk> wrote:
[...]
> But a decent firewall will be stateful - so eg outbound ping will
> enable the reply to be received. No-one 'out there' has any business
> pinging me so they don't get to do it.

That's your local policy, but not mine. I allow some remote sites to
ping me as part of mutual reachability testing.

> I am well aware it's against the rules, but I block all unsolicited
> inbound icmp - never noticed any problems. I'm afraid the rfc's were
> drawn up in a less dangerous internet age :-(

You block Destination Unreachable as well?

--
The poverty from which I have suffered could be diagnosed as "Soho" poverty. It
comes from having the airs and graces of a genius and no talent.
- Quentin Crisp
Anonymous
a b 8 Security
September 23, 2005 6:13:52 PM

Archived from groups: comp.security.misc,comp.security.firewalls (More info?)

In comp.security.firewalls jameshanley39@yahoo.co.uk wrote:
> it is my understanding that stealthing ports has absolutely nothing to
> do with ICMP.

Oh yes, it has. Please read RFC 792, or just read <43088aac@news.uni-ulm.de>

F'up2 comp.security.firewalls

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"
September 23, 2005 6:45:24 PM

Archived from groups: comp.security.firewalls (More info?)

On 23 Sep 2005 12:27:46 +0200, Volker Birk <bumens@dingens.org> wrote:

>In comp.security.firewalls Franklin <no_thanks@mail.com> wrote:
>> My question is Should a firewall let all ICMP traffic through because
>> there is no real risk if they do?
>
>It does not need to let _all_ ICMP traffic through. But it would be a
>good idea not to deny every ICMP traffic.
>
>It is a good idea to allow at least ICMP messages of the
>types 0, 3, 4, 8, 11, 12, see RFC 792.

Thank you. Finally a straight answer.
Anonymous
a b 8 Security
September 23, 2005 7:48:01 PM

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

Leythos sez:
> In article <176uZD2KcidF-pn2-yKJP7XquDBiB@rikki.tavi.co.uk>, rde42
> @spamcop.net says...
>> On Thu, 22 Sep 2005 23:13:55 UTC, Leythos <void@nowhere.lan> wrote:
>>
>> > > In practice, you need to let a few ICMP messages through, then. For
>> > > example, source quench and destination unreachable.
>> >
>> > Wrong, you don't NEED to allow anything. You may FEEL that you do, but
>> > we've got almost 100 networks that don't allow ICMP or anything else
>> > inbound and they work just fine, and we'll not change them.
>>
>> You're wrong. But that's fine. You just carry on.
>
> Then, when we're running along for the last few years, blocking all ICMP
> inbound and at the firewall, what are we denying ourselves?

Your 100 networks are not, strictly speaking, a part of the Internet
since they don't comply with the Internet standards.

HTH, HANL
Dima
--
All whitespace is equivalent except in certain situations
-- ANSI C standard committee
Anonymous
a b 8 Security
September 23, 2005 8:18:22 PM

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

Peter wrote:
> Mike Scott <usenet.9@spam.stopper.scottsonline.org.uk> wrote:
> [...]
>
>>But a decent firewall will be stateful - so eg outbound ping will
>>enable the reply to be received. No-one 'out there' has any business
>>pinging me so they don't get to do it.
>
>
> That's your local policy, but not mine. I allow some remote sites to
> ping me as part of mutual reachability testing.

Sounds like you're allowing them proper access. Fine by me :-)
>
>
>>I am well aware it's against the rules, but I block all unsolicited
>>inbound icmp - never noticed any problems. I'm afraid the rfc's were
>>drawn up in a less dangerous internet age :-(
>
>
> You block Destination Unreachable as well?
>
I believe (may be wrong though) that ipf is pretty clever about what it
lets through or not. Dest ureachable must match existing outbound
packets before it's useful, and I believe ipf will let appropriate (ie
implicitly "solicited") ones through. No doubt someone will correct me
if I'm wrong!

--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk)
Anonymous
a b 8 Security
September 23, 2005 8:30:33 PM

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

In article <slrndj88th.84j.dima@yellowtail.bmrb.wisc.edu>, dima@
127.0.0.1 says...
> Leythos sez:
> > In article <176uZD2KcidF-pn2-yKJP7XquDBiB@rikki.tavi.co.uk>, rde42
> > @spamcop.net says...
> >> On Thu, 22 Sep 2005 23:13:55 UTC, Leythos <void@nowhere.lan> wrote:
> >>
> >> > > In practice, you need to let a few ICMP messages through, then. For
> >> > > example, source quench and destination unreachable.
> >> >
> >> > Wrong, you don't NEED to allow anything. You may FEEL that you do, but
> >> > we've got almost 100 networks that don't allow ICMP or anything else
> >> > inbound and they work just fine, and we'll not change them.
> >>
> >> You're wrong. But that's fine. You just carry on.
> >
> > Then, when we're running along for the last few years, blocking all ICMP
> > inbound and at the firewall, what are we denying ourselves?
>
> Your 100 networks are not, strictly speaking, a part of the Internet
> since they don't comply with the Internet standards.

The there are many users/companies that are not part of the Internet as
many companies block many of the services provided for in the RFC's.
Blocking Ping is very common, as is blocking inbound 135~139, 445, FTP,
etc...

The net is more than your narrow definition, there is a Use side, a
Provide side, and a shared side.

While you may think we're not part of the internet, we are part of a
Narrow segment that provides ICMP only between our partners and block
the rest.

As a matter of fact, we offer web services at many locations, but we
have block lists that block most IP's outside our country, does that
means we're not part of the Internet, NO, it means we believe in
security.

No where in the RFC's does is say that it's mandated that I must offer
services in order to use the Internet networks.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
a b 8 Security
September 23, 2005 9:36:47 PM

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

In article <1127495215.932007.198450@f14g2000cwb.googlegroups.com>,
jameshanley39@yahoo.co.uk says...
>
> Leythos wrote:
> > In article <1127439270.085843.66150@z14g2000cwz.googlegroups.com>,
> > jameshanley39@yahoo.co.uk says...
> > > Leythos wrote:
> > > > In article <176uZD2KcidF-pn2-yKJP7XquDBiB@rikki.tavi.co.uk>, rde42
> > > > @spamcop.net says...
> > > > > On Thu, 22 Sep 2005 23:13:55 UTC, Leythos <void@nowhere.lan> wrote:
> > > > >
> > > > > > > In practice, you need to let a few ICMP messages through, then. For
> > > > > > > example, source quench and destination unreachable.
> > > > > >
> > > > > > Wrong, you don't NEED to allow anything. You may FEEL that you do, but
> > > > > > we've got almost 100 networks that don't allow ICMP or anything else
> > > > > > inbound and they work just fine, and we'll not change them.
> > > > >
> > > > > You're wrong. But that's fine. You just carry on.
> > > >
> > > > Then, when we're running along for the last few years, blocking all ICMP
> > > > inbound and at the firewall, what are we denying ourselves?
> > > >
> > > > It seems that our networks work, that we can VPN into the office just
> > > > fine, etc...
> > > >
> > > > It seems that all of our dedicated IPSec tunnels to partners work fine,
> > > > it seems that our systems with web servers, OWA services, etc.. all work
> > > > just fine.....
> > > >
> > > > --
> > >
> > > and they'd still work fine if you allowed ICMPs. If allowing ICMPs
> > > were dangerous then alarms would've been sent off long ago. ICMP has
> > > been aroudn for ages, there are no new developments to the ICMP
> > > protocol. People that know all about how it works also know of no
> > > alarms saying it can be attacked.
> > [snip]
> >
> > So, you're saying that it doesn't break any functionality that we use to
> > block it, so we should allow it because the designers of it are almost
> > positive that there is no exploit for it, but, since it's not going to
> > hurt anything that even though I don't need it, I should allow it, even
> > though I don't need it......
> >
> > If I don't need it I don't allow it - it's a very simple matter of
> > security - never expose anything that you don't need to expose.
> >
>
> and - as you said - if you did want ICMP responses, you could rsetrict
> ICMP responses to hosts of your choosing.
>
> but what if an ISP or non ISP telephone computer tech is diagnosing a
> non technical home user. The user doesn't have the ability to block
> ICMP on only certain hosts. The homse user isn't running any services
> either(may be behind a NAT device). Ping is ideal in this instance.
> what other option is there to see that he is online,. as a first step
> in diagnosing the problem?

Sorry, that's not a good reason. The ISP can see if the modem is on-
line, and the ISP can see if there is a connection between the modem and
the NAT device or PC at the hardware level. You don't have to allow ping
for any testing/reason, there are always ways around it.



--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
a b 8 Security
September 23, 2005 10:22:39 PM

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

Leythos sez:
> In article <slrndj88th.84j.dima@yellowtail.bmrb.wisc.edu>, dima@
> 127.0.0.1 says...
....
>> > Then, when we're running along for the last few years, blocking all ICMP
>> > inbound and at the firewall, what are we denying ourselves?
>>
>> Your 100 networks are not, strictly speaking, a part of the Internet
>> since they don't comply with the Internet standards.
....
> The net is more than your narrow definition, there is a Use side, a
> Provide side, and a shared side.

Which part of "standard" do you not understand? Here's hint: it
does not mean "flag" in this context.

Dima
--
Sufficiently advanced incompetence is indistinguishable from malice.
Anonymous
a b 8 Security
September 23, 2005 10:26:33 PM

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

On Fri, 23 Sep 2005 17:36:47 GMT, Leythos <void@nowhere.lan> wrote:

>> but what if an ISP or non ISP telephone computer tech is diagnosing a
>> non technical home user. The user doesn't have the ability to block
>> ICMP on only certain hosts. The homse user isn't running any services
>> either(may be behind a NAT device). Ping is ideal in this instance.
>> what other option is there to see that he is online,. as a first step
>> in diagnosing the problem?
>
>Sorry, that's not a good reason. The ISP can see if the modem is on-
>line, and the ISP can see if there is a connection between the modem and
>the NAT device or PC at the hardware level. You don't have to allow ping
>for any testing/reason, there are always ways around it.

I'm curious .... how does the ISP know?

In that vein, I noticed Sygate alerting on the kernel (I think it was)
calling out. Using the traffic log I found that the attempts were to
my ISP. Blocking the attempts has no effect on my internet activity,
as near as I can tell. I wonder what the purpose of this attempted
outbound might be. I don't use any software supplied by my ISP, so
it's not spyware (which some ISPs do use).

Art

http://home.epix.net/~artnpeg
Anonymous
a b 8 Security
September 23, 2005 10:43:23 PM

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

In article <jjh8j19cqprnk2k4ehdi0thckn8b1775aj@4ax.com>, null@zilch.com
says...
> On Fri, 23 Sep 2005 17:36:47 GMT, Leythos <void@nowhere.lan> wrote:
>
> >> but what if an ISP or non ISP telephone computer tech is diagnosing a
> >> non technical home user. The user doesn't have the ability to block
> >> ICMP on only certain hosts. The homse user isn't running any services
> >> either(may be behind a NAT device). Ping is ideal in this instance.
> >> what other option is there to see that he is online,. as a first step
> >> in diagnosing the problem?
> >
> >Sorry, that's not a good reason. The ISP can see if the modem is on-
> >line, and the ISP can see if there is a connection between the modem and
> >the NAT device or PC at the hardware level. You don't have to allow ping
> >for any testing/reason, there are always ways around it.
>
> I'm curious .... how does the ISP know?
>
> In that vein, I noticed Sygate alerting on the kernel (I think it was)
> calling out. Using the traffic log I found that the attempts were to
> my ISP. Blocking the attempts has no effect on my internet activity,
> as near as I can tell. I wonder what the purpose of this attempted
> outbound might be. I don't use any software supplied by my ISP, so
> it's not spyware (which some ISPs do use).

As with most ISP provided devices, you get a Cable or DSP modem when you
get service from them - or a router if a T1, but not many home users
have T1's.

The modem device has ports, it's easy to see if the port is active once
you connect to the device using the ISP's passwords and such. The ISP
can tell if you have a device (or more if your device has multiple
ports), how many bytes you've sent, how many you've received, when the
device was last power-cycled, and other status indicators (signal
levels).

While ping is a simple test, it does not clearly indicate the presence
of any device on the other end.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
a b 8 Security
September 23, 2005 11:01:45 PM

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

In article <slrndj8hvf.8cg.dima@yellowtail.bmrb.wisc.edu>, dima@
127.0.0.1 says...
> Leythos sez:
> > In article <slrndj88th.84j.dima@yellowtail.bmrb.wisc.edu>, dima@
> > 127.0.0.1 says...
> ...
> >> > Then, when we're running along for the last few years, blocking all ICMP
> >> > inbound and at the firewall, what are we denying ourselves?
> >>
> >> Your 100 networks are not, strictly speaking, a part of the Internet
> >> since they don't comply with the Internet standards.
> ...
> > The net is more than your narrow definition, there is a Use side, a
> > Provide side, and a shared side.
>
> Which part of "standard" do you not understand? Here's hint: it
> does not mean "flag" in this context.

I completely understand the standards, and I understand the idea of
networking, the idea of security, and that most of the RFC's didn't for
see many of the uses of the internet that we have today.

So, you've failed to show why I must allow ANY form of ICPM, other than
you whining about the RFC's - my network designs do not require any
public exposure of ICPM, don't break anything that our partners or our
network needs, and provide one less exposure (actually many less, ICMP
is just one example)....

So, show me where our decision to not allow ICMP hurts our ability to
provide the services we do, impacts our ability to use Internet
services, or our ability to share information with our business
partners, or stuff it.

Here is the RFC's introduction to the ICMP - and it even includes
statements that indicate that it's not foolproof, some datagrams may
still be lost, and that other protocols may not use it, that
communications can be unreliable.....

The internet protocol does not provide a reliable communication
facility. There are no acknowledgments either end-to-end or
hop-by-hop. There is no error control for data, only a header
checksum. There are no retransmissions. There is no flow control.

Errors detected may be reported via the Internet Control Message
Protocol (ICMP) [3] which is implemented in the internet protocol
module.

From another section:

The Internet Protocol is not designed to be absolutely reliable. The
purpose of these control messages is to provide feedback about
problems in the communication environment, not to make IP reliable.
There are still no guarantees that a datagram will be delivered or a
control message will be returned. Some datagrams may still be
undelivered without any report of their loss. The higher level
protocols that use IP must implement their own reliability procedures
if reliable communication is required.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
a b 8 Security
September 24, 2005 12:14:55 AM

Archived from groups: comp.security.firewalls (More info?)

In article <4333d8a2@news.uni-ulm.de>, bumens@dingens.org says...
> In comp.security.firewalls Franklin <no_thanks@mail.com> wrote:
> > My question is Should a firewall let all ICMP traffic through because
> > there is no real risk if they do?
>
> It does not need to let _all_ ICMP traffic through. But it would be a
> good idea not to deny every ICMP traffic.
>
> It is a good idea to allow at least ICMP messages of the
> types 0, 3, 4, 8, 11, 12, see RFC 792.
>
> F'up2 comp.security.firewalls.
>
> Yours,
> VB.
>
Which ones incoming and which ones outgoing?
Thanks, Casey
Anonymous
a b 8 Security
September 24, 2005 12:23:49 AM

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

On Fri, 23 Sep 2005 16:30:33 UTC, Leythos <void@nowhere.lan> wrote:

> > Your 100 networks are not, strictly speaking, a part of the Internet
> > since they don't comply with the Internet standards.
>
> The there are many users/companies that are not part of the Internet as
> many companies block many of the services provided for in the RFC's.
> Blocking Ping is very common, as is blocking inbound 135~139, 445, FTP,
> etc...

You are confusing two different layers. Blocking ICMP is one thing, but
not supporting an application protocol is quite another. It worries me
that you don't appear to understand the difference.

> No where in the RFC's does is say that it's mandated that I must offer
> services in order to use the Internet networks.

ICMP isn't a service, but part of the underlying protocol stack; a fact
which you ignore because you apparently don't know any better.

--
[ 7'ism - a condition by which the sufferer experiences an inability
to give concise answers, express reasoned argument or opinion.
Usually accompanied by silly noises and gestures - incurable, early
euthanasia recommended. ]
Anonymous
a b 8 Security
September 24, 2005 1:43:04 AM

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

On Fri, 23 Sep 2005 19:01:45 GMT, Leythos
<void@nowhere.lan> wrote:

> So, show me where our decision to not allow ICMP hurts our ability to
> provide the services we do, impacts our ability to use Internet
> services, or our ability to share information with our business
> partners, or stuff it.

How do you handle PMTU discovery - or do you prevent segments with the
DF bit set leaving your network, or do you mangle the headers and
remove the DF flag, or do you just accept that some sites on that
Internet may not be reachable from nodes on your network, or do you
rely on Windows rather inefficent "PMTU Blackhole discovery" feature
working ?

If you don't allow *any* inbound ICMP and don't implement effective
work arounds then you (or your network users) would have some problems
with all of my locally hosted servers - but then you don't have
access anyway, so you maybe you can live with the fact that your
implementation is broken ;-)

PS - You are not alone in your screwed up thinking - the company I
used to work for adopted a similar policy, and it effectively
caused all my VPN connections from work to home to fail. Easy
to 'fix' since I controlled the 'home' end of the VPN, but not
necessarily quite so easy to fix for an arbitary site on the
Internet.
Anonymous
a b 8 Security
September 24, 2005 2:19:09 AM

Archived from groups: comp.security.firewalls (More info?)

Casey Klc <casey@notspecified.net> wrote:
> > It is a good idea to allow at least ICMP messages of the
> > types 0, 3, 4, 8, 11, 12, see RFC 792.
> > F'up2 comp.security.firewalls.
> Which ones incoming and which ones outgoing?

Please read RFC 792, then you'll understand.

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"
Anonymous
a b 8 Security
September 24, 2005 3:49:14 AM

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

Leythos wrote:
> (or more if your device has multiple ports)

Are you telling me they can read your router's ARP table then?

Steve
Anonymous
a b 8 Security
September 24, 2005 3:54:32 AM

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

Leythos wrote:
>
> So, you've failed to show why I must allow ANY form of ICPM, other than
> you whining about the RFC's - my network designs do not require any
> public exposure of ICPM, don't break anything that our partners or our
> network needs, and provide one less exposure (actually many less, ICMP
> is just one example)....
>

I guess that you and your company would be quite happy then if your ISP,
and other up-line carriers decided not to route any traffic from a
network that was not RFC compliant?

Think not ;) 

Steve
Anonymous
a b 8 Security
September 24, 2005 4:29:59 AM

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

In article <MPG.1d9e1b2addd7c42198a107@news-server.columbus.rr.com>,
Leythos <void@nowhere.lan> wrote:
>Here is the RFC's introduction to the ICMP - and it even includes
>statements that indicate that it's not foolproof, some datagrams may
>still be lost, and that other protocols may not use it, that
>communications can be unreliable.....

The passages you refer to are talking about _IP_ and the use of ICMP
packets to report errors situations in IP. The words not foolproof etc
refer to IP not ICMP.

Mike
Anonymous
a b 8 Security
September 24, 2005 6:04:37 AM

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

In article <176uZD2KcidF-pn2-pu05rwv5JXnr@rikki.tavi.co.uk>, rde42
@spamcop.net says...
>
> ICMP isn't a service, but part of the underlying protocol stack; a fact
> which you ignore because you apparently don't know any better.

Sorry to have confused you with other things I block. You said that I
was breaking things by not allowing ICMP, I said that many security
types block most things, not just ICMP and also indicated some things I
block.

Nothing in the RFC indicates I have to permit ICMP of any type - please
show where it's mandated if you want to continue this, oh, and don't
quote the RFC since I've already read it, years ago, and it's not
mandated that I permit any ICMP inbound to my network.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
a b 8 Security
September 24, 2005 6:06:07 AM

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

In article <sxko52$mv7$r@ddka.demon.co.uk>, a031003
${dd}.nospam@ddka.invalid says...
> If you don't allow *any* inbound ICMP and don't implement effective
> work arounds then you (or your network users) would have some problems
> with all of my locally hosted servers - but then you don't have
> access anyway, so you maybe you can live with the fact that your
> implementation is broken ;-)
>
> PS - You are not alone in your screwed up thinking - the company I
> used to work for adopted a similar policy, and it effectively
> caused all my VPN connections from work to home to fail. Easy
> to 'fix' since I controlled the 'home' end of the VPN, but not
> necessarily quite so easy to fix for an arbitary site on the
> Internet.

I already said we allow ICMP with partners and have no problems with
VPN's, we do not allow ICMP with the world as a general rule, just with
approved partners.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
a b 8 Security
September 24, 2005 6:07:37 AM

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

In article <GdKdnSz458I0GqneRVnyug@eclipse.net.uk>, sjw@stevew.net
says...
> Leythos wrote:
> >
> > So, you've failed to show why I must allow ANY form of ICPM, other than
> > you whining about the RFC's - my network designs do not require any
> > public exposure of ICPM, don't break anything that our partners or our
> > network needs, and provide one less exposure (actually many less, ICMP
> > is just one example)....
> >
>
> I guess that you and your company would be quite happy then if your ISP,
> and other up-line carriers decided not to route any traffic from a
> network that was not RFC compliant?
>
> Think not ;) 

My ISP is in the business that requires they provide it - I don't see
how you can't understand that part. We don't offer services to the world
and have exceptions for our partners so that ICMP is not blocked to
them. Why can't you seem to grasp the simple concept of allowing for
business needs and blocking for all others?

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
a b 8 Security
September 24, 2005 6:08:27 AM

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

In article <dh26m7$rrh$1@lucy.duncodin.org>, mike@duncodin.org says...
> In article <MPG.1d9e1b2addd7c42198a107@news-server.columbus.rr.com>,
> Leythos <void@nowhere.lan> wrote:
> >Here is the RFC's introduction to the ICMP - and it even includes
> >statements that indicate that it's not foolproof, some datagrams may
> >still be lost, and that other protocols may not use it, that
> >communications can be unreliable.....
>
> The passages you refer to are talking about _IP_ and the use of ICMP
> packets to report errors situations in IP. The words not foolproof etc
> refer to IP not ICMP.

Which does not change the fact that I can limit ICMP to my non-partners
without impact on our communications.

--

spam999free@rrohio.com
remove 999 in order to email me
Anonymous
a b 8 Security
September 24, 2005 1:35:00 PM

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

On Sat, 24 Sep 2005 02:04:37 UTC, Leythos <void@nowhere.lan> wrote:

> In article <176uZD2KcidF-pn2-pu05rwv5JXnr@rikki.tavi.co.uk>, rde42
> @spamcop.net says...
> >
> > ICMP isn't a service, but part of the underlying protocol stack; a fact
> > which you ignore because you apparently don't know any better.
>
> Sorry to have confused you with other things I block. You said that I
> was breaking things by not allowing ICMP, I said that many security
> types block most things, not just ICMP and also indicated some things I
> block.

By bundling the two together, you indicated a lack of understanding of
the difference...

"Blocking Ping is very common, as is blocking inbound 135~139, 445, FTP,
etc..."

> Nothing in the RFC indicates I have to permit ICMP of any type - please
> show where it's mandated if you want to continue this, oh, and don't
> quote the RFC since I've already read it, years ago, and it's not
> mandated that I permit any ICMP inbound to my network.

As I said before...do what you like...it'll be your problem, not mine.
Oh, and I probably read the RFC long before you, anyway.

--
[ 7'ism - a condition by which the sufferer experiences an inability
to give concise answers, express reasoned argument or opinion.
Usually accompanied by silly noises and gestures - incurable, early
euthanasia recommended. ]
Anonymous
a b 8 Security
September 24, 2005 1:35:02 PM

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

On Sat, 24 Sep 2005 02:08:27 UTC, Leythos <void@nowhere.lan> wrote:

> In article <dh26m7$rrh$1@lucy.duncodin.org>, mike@duncodin.org says...
> > In article <MPG.1d9e1b2addd7c42198a107@news-server.columbus.rr.com>,
> > Leythos <void@nowhere.lan> wrote:
> > >Here is the RFC's introduction to the ICMP - and it even includes
> > >statements that indicate that it's not foolproof, some datagrams may
> > >still be lost, and that other protocols may not use it, that
> > >communications can be unreliable.....
> >
> > The passages you refer to are talking about _IP_ and the use of ICMP
> > packets to report errors situations in IP. The words not foolproof etc
> > refer to IP not ICMP.
>
> Which does not change the fact that I can limit ICMP to my non-partners
> without impact on our communications.

Well, you think you can.

--
[ 7'ism - a condition by which the sufferer experiences an inability
to give concise answers, express reasoned argument or opinion.
Usually accompanied by silly noises and gestures - incurable, early
euthanasia recommended. ]
Anonymous
a b 8 Security
September 24, 2005 4:27:15 PM

Archived from groups: comp.security.firewalls (More info?)

Volker Birk wrote:
> In comp.security.firewalls jameshanley39@yahoo.co.uk wrote:
> > it is my understanding that stealthing ports has absolutely nothing to
> > do with ICMP.
>
> Oh yes, it has. Please read RFC 792, or just read <43088aac@news.uni-ulm.de>
>
> F'up2 comp.security.firewalls
>

I agree that people stealth beause they think it makes them safer. And
it's pointless to stealth if they're not going to block ICMP too.
If they're trying to make themselves invisible, and they stealth their
ports, then blocking ICMP is very relevant. Fruthermore, perhaps
blocking ICMP makes more sense in terms of invisibility than stealthing
does. (I do not nkow how to check if one of my comps is online
remotely without pinging it)

is that what you meant? if so then you misunderstood me

My point is that technically they are totally different concepts.
Stealthing breaks TCP protocol. Blocking ICMP breaks ICMP protocol.
Differetn layers. Technically they have absolutely nothing to do with
each other. I'm sure I can set my firewall to stealth my ports(which
most PFWs do automatically), and respond to ICMP.


By the way. how can nmap test if a port is stealthed, whereas people
complain saying online scanners cannot say a port is stealthed? If
stealth gives no response whatsoever, then surely 'unable to determine'
is the best that either an onlien scanner or nmap can give. They can
only say "most likely it is stealthed".
and that assumes the comp exists, which if they can't ping it either ,
seems hard to tell
Anonymous
a b 8 Security
September 24, 2005 5:07:04 PM

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

"Leythos" <void@nowhere.lan> wrote in message
news:MPG.1d9d1560b23ca33698a0fe@news-server.columbus.rr.com...
> In article <KpHYe.4417$_56.2350@newsfe1-win.ntli.net>, abuse@[127.0.0.1]
> says...

<snip>

> > Undoubtedly the case. Although one could quote lots of instances where
it's
> > been damned useful.
> >
> > Well, *I* certainly can - usually when the web server has had a bit of a
> > funny turn, and one needs to tell if it's the server behind the firewall
> > (fat chance of fixing something from an adjacent continent), or whether
it's
> > the ISP playing silly buggers with the connection (marginally more hope
of
> > getting something sorted).
> >
> > As goes firewalls - I'm sure that most have already seen it, but:
> >
http://www.dilbert.com/comics/dilbert/archive/images/di...
>
> Funny, I don't expose our servers to Ping, and I seem to be able to
> monitor them all the time. If I need to expose PING to an external
> source I expose it to a specific IP and block all others.

I should have clarified (thought that it was clear from the context.. ah
well ;o)

This is monitorin my services from *outside* of the network.

Like most non-ISPs, I don't have a dedicated 24x7 staff to monitor systems
(this is a home network, before someone starts slinging companies that *do*
have this requirement).

On the Ping front, you'll find that the companies that you're hosting
(assuming that's what your part of the network does) are unlikely to appear
on many search engines - at least, that *used* to be the case - a "cheap"
PING before even attempting an HTTP GET.

Together, those made a pretty compelling case for me to switch ICMP back
on - I didn't (and still don't) see it as a major way threat to my firewall
(and, after all, that's as far as the packet's going to get, right?
Certainly not into the DMZ...)

H1K
Anonymous
a b 8 Security
September 24, 2005 5:45:19 PM

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

On Sat, 24 Sep 2005 02:06:07 GMT, Leythos
<void@nowhere.lan> wrote:

> I already said we allow ICMP with partners and have no problems with
> VPN's, we do not allow ICMP with the world as a general rule, just with
> approved partners.

I still can't understand why you would want to deliberately break a
valuable feature of IP - and do so in a way such that a user will have
no idea why their connection to a specific site on the Internet may
work in some cases but not in others. It's your choice how you
configure your network, of course, but it seems a rather idiotic
configuration to me.
September 24, 2005 6:36:18 PM

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

> By bundling the two together, you indicated a lack of understanding of
> the difference...
>
> "Blocking Ping is very common, as is blocking inbound 135~139, 445, FTP,
> etc..."
>

I think that it's a bit of a stretch to suggest that someone stating that
blocking ping is very common, as is blocking inbound traffic to "135~139,
445, FTP, etc..." shows a lack of understanding of the difference. I think
that you've missed his point.

I like Chinese food as well as the occasional Indian but just because they
are mentioned in the same sentence shouldn't lead anyone to the conclusion
that I don't understand the difference between the two.
!