Ok to let all ICMP traffic through firewall?

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

In comp.security.misc Dave Dowson <a031003${dd}.nospam@ddka.invalid> wrote:
> 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.

Of course, it is.

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

In article <sxlxpt$u55$m@ddka.demon.co.uk>, a031003
${dd}.nospam@ddka.invalid says...
> 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.

You may thing that it breaks things for "users on the internet", but
since we don't really care about "users" on the internet, since we only
care about partners being able to connect with our public facing
services, we're not really breaking anything as they (partners) don't
have ICMP blocked - so, back to reality, we're not breaking anything for
our accepted/targeted audience, we're closing possible security holes
that may or may not be a threat.

Now do you understand - it's actually rather simple - the "users" that
need to have ICMP responses form our networks get it, ones that don't do
not get it.

--

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

In article <YbcZe.11$K77.9@newsfe2-gui.ntli.net>, abuse@[127.0.0.1]
says...
> 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).

Like I've said many times before - ICMP is exposed to partner
sites/companies, blocked to the rest of the world. If we have no
communications need with you then we don't expose anything to you.

Your example of Ping would fall into a business need - so there would be
a rule exception allowing PING from your designated monitoring service.

--

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

On 24 Sep 2005 12:27:15 -0700, jameshanley39@yahoo.co.uk
<jameshanley39@yahoo.co.uk> wrote:

> 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.

So even if you are ignorant enough to believe that "stealthing" your
machine provides some sort of additional security then what do you
gain by blocking inbound ICMP messages which don't require a response
(i.e. the majority of them) and so provide no information back to the
originator?

> 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.

If a TCP connection cannot be routed to its destination then the
response will be an ICMP message, so you cannot say they have
"absolutely nothing to do with each other". Stealthing TCP (i.e. not
sending an RST) has an impact on the originator, not you (although you
may receive retries as a result of not responding) - blocking ICMP
generally impacts on you, not the sender - so why would anyone want to
impair their system by blocking informative inbound ICMP messages,
particulary as such messages don't require a response and so provide
no information back to the originator?

> 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

If your IPS's upstream router returns an ICMP host unreachable if you
are offline then stealthing is completly pointless anyway since "no
response" simply means that you are online.
 
Archived from groups: comp.security.firewalls (More info?)

In article <1127590035.024362.202660@g14g2000cwa.googlegroups.com>,
jameshanley39@yahoo.co.uk says...
> 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.

Which goes back to the simple security concept -if you don't have a need
to provide the service, then you don't provide it.

In our case, we only provide exposure for services that our clients,
business partners, etc... need, we don't allow exposure to the world
just because it might not be a current threat - we block ALL except that
with a business need.

--

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

On Sat, 24 Sep 2005 21:21:52 GMT, Leythos
<void@nowhere.lan> wrote:

> Now do you understand - it's actually rather simple - the "users" that
> need to have ICMP responses form our networks get it, ones that don't do
> not get it.

Hang on a minute, so now you are saying that you block outgoing ICMP
(i.e. responses) ito selected parties - earlier you said you blocked
incoming ICMP. So maybe you block both.

Tell me - what is the risk of sending an ICMP packet to anyone?
You've said that you block such responses - but why? What is the risk
you perceive in sending a messages which (in general) does not require
a response and so cannot have any impact on your network? Or are you
suggesting that your networks are so insecure that you need to protect
them from things that would not even be a threat to the clueless
newbie home computer user? I haven't a clue what services you
provide, but please let me know - just so I can make sure I never use
them.

And no, I don't understand your screwed up interpretation of the risks
associated with what is a relatively simple out-of-band signalling
protocol.
 
Archived from groups: comp.security.firewalls,uk.telecom.broadband,comp.security.misc,alt.computer.security (More info?)

In article <sxmo84$rdt$n@ddka.demon.co.uk>, a031003
${dd}.nospam@ddka.invalid says...
> And no, I don't understand your screwed up interpretation of the risks
> associated with what is a relatively simple out-of-band signalling
> protocol.

This is the easy part for you - you don't have to understand my
reasoning. I block all traffic not needed for the business. By blocking
all traffic not needed for the business I EXPOSE LESS, which puts me one
step closer to not having to worry about some unknown exploit. That's
all the reason for it, nothing else, simple concept - block what you
don't need.

Here's another thing, and don't confuse this with my blocking ICMP, I
also block all access from IP lists that resolve to various countries
for other networks - for instance, if we have a mail server, in-bound
SMTP is filtered for content and a master block list is also applied
against it for filtering email from lots of IP ranges that resolve to
known geographical locations.

It's all about exposing ONLY WHAT YOU NEED and ONLY WHAT YOUR TARGET
NEEDS - if you expose more than what's needed you expose yourself to
exploits that you may or may not already know about.

--

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

"Leythos" <void@nowhere.lan> wrote in message
news:MPG.1d9f8e2789e1e72a98a110@news-server.columbus.rr.com...
> In article <YbcZe.11$K77.9@newsfe2-gui.ntli.net>, abuse@[127.0.0.1]
> says...
> > 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).
>
> Like I've said many times before - ICMP is exposed to partner
> sites/companies, blocked to the rest of the world. If we have no
> communications need with you then we don't expose anything to you.
>
> Your example of Ping would fall into a business need - so there would be
> a rule exception allowing PING from your designated monitoring service.

Actually, it's not that simple (I'll stress again that this is *my*
particular need, but not one that is particularly uncommon)

My monitoring service is me, with either my phone or a laptop.

I need to be able to connect from a variety of countries, and a (for my
purposes) essentially random series of ISPs and routing networks.

I understand completely that this isn't the same as /your/ need - you are
obviously providing a specific service to a very geographically limited set
of known users. Although I'd be wary, once one of them attempts DR. 'Tis
amazing what comes out of the woodwork when that happens... I've had to do
it for real, courtesy of the PIRA.

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

In article <sxmo84$rdt$n@ddka.demon.co.uk>,
Dave Dowson <r030102${dd}.nospam@ddka.demon.co.uk> wrote:
:Tell me - what is the risk of sending an ICMP packet to anyone?
:You've said that you block such responses - but why? What is the risk
:you perceive in sending a messages which (in general) does not require
:a response and so cannot have any impact on your network? Or are you
:suggesting that your networks are so insecure that you need to protect
:them from things that would not even be a threat to the clueless
:newbie home computer user?

There was an attack publicized within the last few years, in
which attackers sent ICMP Network Redirect and Host Redirect
(which don't require responses...) specifying IP addresses
of major banking sites. Networks whose administrators were not
blocking ICMP Redirects had their users redirected to clone
sites made to -look- like the banking sites, but which copied
the username and passwords entered; the perpetrators then
proceeded to steal from peoples' bank accounts and credit cards.
--
If you like, you can repeat the search with the omitted results included.
 
Archived from groups: comp.security.firewalls,uk.telecom.broadband,comp.security.misc,alt.computer.security (More info?)

In article <MPG.1d9e7f311cb8f5db98a10b@news-server.columbus.rr.com>,
Leythos <void@nowhere.lan> wrote:
>Which does not change the fact that I can limit ICMP to my non-partners
>without impact on our communications.

I'm sorry but I don't think you know what you're talking about. As
you've previously quoted, without apparently understanding it, ICMP is
predominantly a mechanism for reporting an error in IP. If you block it,
and don't (or rarely) have an error at the IP level, then your setup
will work - beacause there are no errors and ICMP simply isn't
involved. If an error should occur then your blocking of ICMP could
then prevent you from detecting and diagnosing faults, or allowing your
application(s) to handle them.

But it's your setup, and I think we'll just have to agree to differ.

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

In article <ewlZe.2885$3q4.1333@newsfe5-gui.ntli.net>, abuse@[127.0.0.1]
says...
> Actually, it's not that simple (I'll stress again that this is *my*
> particular need, but not one that is particularly uncommon)
>
> My monitoring service is me, with either my phone or a laptop.
>
> I need to be able to connect from a variety of countries, and a (for my
> purposes) essentially random series of ISPs and routing networks.

Are you unable to connect via VPN of some form?

--

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

Dave Dowson wrote:
> On Sat, 24 Sep 2005 21:21:52 GMT, Leythos
> <void@nowhere.lan> wrote:
>
>
>>Now do you understand - it's actually rather simple - the "users" that
>>need to have ICMP responses form our networks get it, ones that don't do
>>not get it.
>
>
> Hang on a minute, so now you are saying that you block outgoing ICMP
> (i.e. responses) ito selected parties - earlier you said you blocked
> incoming ICMP. So maybe you block both.
>
> Tell me - what is the risk of sending an ICMP packet to anyone?
> You've said that you block such responses - but why? What is the risk
> you perceive in sending a messages which (in general) does not require
> a response and so cannot have any impact on your network?

Hopefully I'm not going to stray too far from the subject of ICMPs, but
I feel there could be a risk in allowing any IP packet to be sent to
anyone. No, it's not a general risk to your network because they
couldn't infect a machine on your network. But, they could be a
liability risk or just a risk of embarrassment.

For instance, what if a user on your internal network has knowledge of
malware that used covert channels to receive it's instructions about
what to do? Then, that user used that knowledge to attack someone
else's network. Or, a machine on your network is infected with this
type of malware and is used in an attack because it received
instructions over a covert channel.

> Or are you
> suggesting that your networks are so insecure that you need to protect
> them from things that would not even be a threat to the clueless
> newbie home computer user?

That sounds like layered security to me. Why expose one thing just
because you think everything behind it is secured?

>
> And no, I don't understand your screwed up interpretation of the risks
> associated with what is a relatively simple out-of-band signalling
> protocol.

There are ways to send information or instructions to processes
listening on systems that allow any IP packet. It could be in an ICMP
or TCP or UDP or ESP or GRE (doesn't matter) payload. But, it doesn't
have to be in the payload. It could just be the timing between the
packets. It could be a particular sequence of IP IDs. Or, the use of
still undefined or experimental IP options.

But on a practical note, when it comes to ICMPs, I tend to block
everything except errors that are related to established connections.
But, that's just me. Obviously, there are many opinions on this subject.

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

jameshanley39@yahoo.co.uk wrote:
> And
> it's pointless to stealth if they're not going to block ICMP too.

It's pointless to "stealth" anyway. nmap -P0 exists.

> If they're trying to make themselves invisible, and they stealth their
> ports, then blocking ICMP is very relevant.

No.

> By the way. how can nmap test if a port is stealthed, whereas people
> complain saying online scanners cannot say a port is stealthed?

Because people are complaining wrong things.

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

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

The ICMP packages are not send by the host itself, but by the router
before.

Please read RFC 792.

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 (More info?)

In comp.security.firewalls Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:
> There was an attack publicized within the last few years, in
> which attackers sent ICMP Network Redirect and Host Redirect
> (which don't require responses...) specifying IP addresses

Yes. This is the reason to filter redirects.

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

"Leythos" <void@nowhere.lan> wrote in message
news:MPG.1d9e1b2addd7c42198a107@news-server.columbus.rr.com...
> 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?

You just make diagnosis more difficult when things go wrong obviously, since
you can't ping. Also some devices that use ping for link monitoring will be
unhappy and need to be reconfigured or will have reduced functionality. If
you can live with this, and many people can, there is no big cost to you, to
block all ping at the firewall.

For example when ISP's block ping, it drives me crazy because when I deploy
NetScreens in the field with failover internet connections, they need to use
ping to determine if the link is up. So I can't enable failover when the
ISP blocks ping. Inevitably somebody re-enables auto failover detection and
it immediately fails over to dialup because it thinks the highspeed link is
down...

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

In article <dh4pv0$ai7$1@lucy.duncodin.org>, mike@duncodin.org says...
> I'm sorry but I don't think you know what you're talking about. As
> you've previously quoted, without apparently understanding it, ICMP is
> predominantly a mechanism for reporting an error in IP. If you block it,
> and don't (or rarely) have an error at the IP level, then your setup
> will work - beacause there are no errors and ICMP simply isn't
> involved. If an error should occur then your blocking of ICMP could
> then prevent you from detecting and diagnosing faults, or allowing your
> application(s) to handle them.

If you understand this simple fact: If I block ICMP to non-partners,
then I don't really care if they get ICMP messages, which means I don't
care what NON-PARTNERS SEE.

If we allow ICMP with Partners then there is no issue with ICMP, so,
we're back to you seeming to miss that we block EVERYTHING TO NON-
PARTNERS, but we secure the network according to partner needs.

What parts are you missing about ICMP being permitted for PARTNERS?

--

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 <ZKwZe.12844$p5.741@nnrp.ca.mci.com!nnrp1.uunet.ca>,
somebody.@spamout.russdoucet.com says...
>
> "Leythos" <void@nowhere.lan> wrote in message
> news:MPG.1d9e1b2addd7c42198a107@news-server.columbus.rr.com...
> > 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?
>
> You just make diagnosis more difficult when things go wrong obviously, since
> you can't ping.

But it's never made anything more difficult for our businesses or
support methods - we've never counted on PING working in the first
place. To many places and firewall setups block even the simple PING (as
they should).

> Also some devices that use ping for link monitoring will be
> unhappy and need to be reconfigured or will have reduced functionality. If
> you can live with this, and many people can, there is no big cost to you, to
> block all ping at the firewall.

Since we don't use PING to monitor the firewalls or the web servers or
the email servers, or anything, we are not missing anything. At any time
a ISP could block ping and where would you be if you relied on PING as a
means to determine alive or not?

> For example when ISP's block ping, it drives me crazy because when I deploy
> NetScreens in the field with failover internet connections, they need to use
> ping to determine if the link is up. So I can't enable failover when the
> ISP blocks ping. Inevitably somebody re-enables auto failover detection and
> it immediately fails over to dialup because it thinks the highspeed link is
> down...

So why don't you have PING setup to ping the default gateway on the
ISP's side outbound from your firewall? - I've not seen a single isp
that doesn't allow their default gateway to ping. Maybe you need to stop
using residential networks for business if you're seeing ping being
blocked to the gateway.


--

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

On Sun, 25 Sep 2005 00:10:30 +0000 (UTC), Walter Roberson
<roberson@ibd.nrc-cnrc.gc.ca> wrote:

> There was an attack publicized within the last few years, in
> which attackers sent ICMP Network Redirect and Host Redirect
> (which don't require responses...) specifying IP addresses
> of major banking sites. Networks whose administrators were not
> blocking ICMP Redirects had their users redirected to clone
> sites made to -look- like the banking sites, but which copied
> the username and passwords entered; the perpetrators then
> proceeded to steal from peoples' bank accounts and credit cards.

We were talking bout outgoing ICMP messages, not incoming ones, but
never mind.

As far as ICMP redirects are concerned they provide a facility to
inform a network node of the 'best' local gateway, i.e. which next hop
router to use for a particular desinstation. If you sent a spoofed
ICMP redirect to a workstation on my local network then (a) it would
have to appear to come from the default gateway (easy to spoof if you
know the internal network configuration, although maybe a little
difficult to inject if ingress filtering is employed on external
interfaces), (b) it would need to contain the first 8 bytes of the
outgoing IP message it related to (not quite so easy to spoof unless
you can monitor the traffic on my local network), and (c) it could
only specify an IP address of a different node on the same LAN segment
for the 'new' next hop router for that destination.

So god only knows how the compromise you mentioned above worked, but I
can only assume that either the 'attack' was internal (i.e. the bogus
servers were on the same LAN as the victims) or that the network was
already compromised and that the ICMP redirects were of little
significance to the true nature of the attack.
 
Archived from groups: comp.security.firewalls,uk.telecom.broadband,comp.security.misc,alt.computer.security (More info?)

jameshanley39@yahoo.co.uk said:
>Peter Boosten wrote:
>> In comp.security.firewalls Mark <nothere@notthere.com> wrote:
>> >
>> >
>> > Yes it is, ever heard of PING NMAP?
>> >
>> > Google it and security and firewalls.
>> >
>>
>> or PING of Death?
>>
>that is indeed a logical reason to block ping. One wouldn't expect An
>error in the ICMP protocol. But, ping of death, is probably an error
>in the software handling ICMP, rather than the ICMP protocol itself.

Pretty often the protocols themselves are solid (protocols as in protocol
definitions), but implementations are faulty - just as in the case of
ping-of-death.

The same goes for various ftp implementations, some ssh implementations,
some web server implementations, ... . Now, it's rather easy to disable
an unneeded ftp server (as to why it was enabled anyway - f.ex. that
was the vendor default, and the person doing the system installation
didn't think enough to disable it). But how do you disable ICMP handling?
You turn off the machine, more or less.

This is why you only let in those ICMP packets that affect your own
communications. F.ex., inbound ICMP echo-requests are prohibited (unless
you're facing a site that does an echo-request every time you connect
to it); allowed are only such ICMP echo replies which correspond to
a recent outbound ICMP echo request, and so on.

So, ICMP is good and needed (just as inbound TCP ack's are needed), for
such sessions that are known to exist. Rest of ICMP is noise which is
best ignored at network boundary. Just to give yourself a little more
time to patch when someone finds a new critical fault somewhere in the
network infrastructure code.

Speaking of allow/disallow, allow the things you know you need, don't
deny things you know you don't need. If you go the "deny" path, you
may overlook things like IP subprotocols other than the common three
(TCP, UDP, ICMP) - just because you didn't pay attention to the multiple
other values there can be in the subprotocol field.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
 
Archived from groups: comp.security.firewalls,uk.telecom.broadband,comp.security.misc,alt.computer.security (More info?)

Leythos <void@nowhere.lan> said:
>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.

By the way, that may vary a lot geographically. F.ex. here it's more
common that customers buy their own hardware. ISPs may have recommendation
lists (or lists of supported hardware), but the lists are not exclusive.
Using something outside the list just means that the ISP support has
never seen such a box, and doesn't have a ready configuration/help
sheet for it.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
 
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.1d9fb675753739dd98a11b@news-server.columbus.rr.com...
> In article <ewlZe.2885$3q4.1333@newsfe5-gui.ntli.net>, abuse@[127.0.0.1]
> says...
> > Actually, it's not that simple (I'll stress again that this is *my*
> > particular need, but not one that is particularly uncommon)
> >
> > My monitoring service is me, with either my phone or a laptop.
> >
> > I need to be able to connect from a variety of countries, and a (for my
> > purposes) essentially random series of ISPs and routing networks.
>
> Are you unable to connect via VPN of some form?

Correct.

And, in any case, any way of swooping into the DMZ is a much more
significant hole than allowing an ICMP Ping...

The network is generally stable (a daemon abend a year, if that), but is
hosted via what is officially a dynamic IP address.

Some ISPs seem to block access on a variety of ports. Ping can be dead
useful in those sort of situations... I managed to run the demo I needed (me
in US, machine in UK) by running through a different port (technically
hosting a different site, but running a near-enough software level to the
"proper" demo).

I doubt that I would have remembered that redirected site was there, but for
getting a positive Ping with a negative "Internet" response on ports 80 and
443. ISP-specific blocking as it turned out (broken in Dallas, fine in
Chicago)

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

In article <MPG.1da072ebfc40a40b98a11d@news-server.columbus.rr.com>,
Leythos <void@nowhere.lan> wrote:
>What parts are you missing about ICMP being permitted for PARTNERS?

OK, perhaps I'm not explaining myself well. I'm assuming from your
statements that you allow ICMP _only_ between permitted endpoints, yes?

If so, under what error scenarios do you think the endpoints are going
to need to send ICMP packets to each other?

Now consider the routers along any one of the potential paths between
your endpoints. In certain circumstances these devices could want to
advise you of IP error events and will send ICMP packets to you. These
ICMP packets will have an originating address not of your endpoints,
and you will therefore block them. Correct?

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

In article <dh6ubo$v8q$1@lucy.duncodin.org>, mike@duncodin.org says...
> Now consider the routers along any one of the potential paths between
> your endpoints. In certain circumstances these devices could want to
> advise you of IP error events and will send ICMP packets to you. These
> ICMP packets will have an originating address not of your endpoints,
> and you will therefore block them. Correct?

Errors are not fixed by ICMP and are not going to cause a failure in
communications. You can still get the data.

--

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

On Sun, 25 Sep 2005 20:09:12 GMT, Leythos
<void@nowhere.lan> wrote:

> Errors are not fixed by ICMP and are not going to cause a failure in
> communications. You can still get the data.

Errors may not be "fixed" by ICMP but ICMP may just tell you what you need to
do in order to fix something - e.g. ICMP type 3 codes 4, 11 and 12. If you
trash the ICMP response then you may end up with a failed connection which
would have otherwise worked without any problem - so no - ignoring ICMP does
not mean that you still get the data in all circumstances.
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom