Re: (PM) Locking up telnet connections

michael@blueneptune.com
Sat, 6 Feb 1999 12:02:32 -0800 (PST)

> > The reality is that firewalls and filters do not exist in some cases, or
> > are improperly implemented. The reality is that trusted systems are
> > sometimes compromised. The more you work to make sure that -isn't- the
>
> The REALITY is that there exists a way to handle this problem in comos. We
> are talking about portmasters right? ;-)

Last I checked, yes, my boxes are PortMasters, even if the logos on them
change color and company names from time to time. :-) But I don't buy the
argument that the ability to install a filter to workaround or avoid a
problem removes all obligation to fix the problem in the first place. It
might reduce the need and urgency for such a fix, but it does not make it
unnecessary.

Another example along those lines is the problem with the way ComOS
routes packets that are destined for an address in the dialup address pool,
but no device is connected using that address. Currently, it routes the
packet back out to the default route, rather than returning a "no route
to host" ICMP message. This results in the packet bouncing around on the
network until the TTL expires. Yes, this can be fixed with a filter.
Does this mean ComOS is ok because a filter can fix it? I personally
don't think so. How many filters do you want to have on the box?

Yes, in the case of this telnet issue, you should have filters and/or
firewall rules in place to protect the box from unwanted eyes in the
first place. Still, it is an error in the handling of the network
connection to do as it does, and not everybody will have appropriate
filters in place for protection. In a properly maintained network, is
the risk of exposure high? No. If it should happen, is it possible to
recover from the problem in a number of different ways? Yes. Fine,
then it's not a high priority issue. But it's an error all the same,
one that in all likelihood is not difficult to fix. It could affect
some class of people who have not taken appropriate precautions, and
who might not immediately know ways to recover from it. So why argue
that it should -not- be fixed? List it as a known bug, and the next
time somebody is involved with the relevant code, or wants to look at
something that -might- be a simple fix, then fix it and eventually
release it.

-- 
Michael Bryan
michael@blueneptune.com
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>