Ok to let all ICMP traffic through firewall?

Page 2 - 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?)

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
 
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)
 
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
 
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
 
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.
 
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
 
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
 
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
 
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
 
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. ]
 
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.
 
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"
 
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
 
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
 
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
 
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
 
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
 
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
 
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
 
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. ]
 
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. ]
 
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
 
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/dilbert2813960050912.gif
>
> 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
 
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.
 
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.