[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Are we connected ? - round II
From:       Holger Thon <devel_ht () unidui ! uni-duisburg ! de>
Date:       1999-05-18 18:17:46
[Download RAW message or body]

Andreas Pour wrote:
> 
> Hello,
> 
> Holger Thon wrote:
> 
> > Andreas Pour wrote:
> >
> >        Matt Koss wrote:
> >        this.  But if the gateway does not understand the query, the only
> > thing to do is to
> >        try
> >        to ping the outside world, I think . . .
> >
> > Well, i don't think pinging is a good idea, for it produces dns-lookups
> > which - in my opinion - have to be avoided on DOD systems.
> 
> Well, if you use something like "ping 209.23.55.112" it does not cause a
> DNS lookup.  I presume, incidentally, that the computer you would want to

You mean ping -n IP, ok I'll agree. :-)
But some systems need a dummy device to be up if not connected and check
if network traffic is passed to this device. 

> > 2.) client over gateway
> >    - assume permanent connection (-> see 08/15)
> >    - dod/assume no connection at all
> 
> What would be the granuality of this assumption?  Each http request?  Every
> 20 minutes?  I don't know how this is workable . . .

I mean something like connections will be avoided, but the user can
enable connections to the outside by telling to do so (maybe over
dialog).

> 
> >       -> ask what to do when remote actions requested
> 
> Depending on the granularity, this could kill the user with questions
> (e.g., if you ask the user for each http request what to do, well, you know
> what that would mean . . .).

Well, when the user really wants to do something "outside" he will
answer yes. And if he accidently follows a link to other servers, he
won't mind this question, i suppose.

For DOD systems this would mean: If Client says yes, request is
permitted. Request causes dialin and we can assume we are connected.
After a specified timeout (where no remote actions are taken) we can
switch back to the mode no connection.

> >       -> these questions may be turned off
> 
> That just means turning the service off, no?

Yes. Then the user has to allow connections himself.

> > When there's a
> > firewall inbetween the clients and the gateway using e.g. socks, it
> > won't work. If the gateway itself is a firewall, the process will become
> > an additional security threat to e.g. exploits.
> 
> I do not understand how so?  It responds only to queries from the local LAN
> device.  And the only thing it says is "I'm connected".  Now, I do not see

I thought of a process accepting queries on each device. Your idea is
much prettier, then. ;-)

The exploits i meant are something like cause buffer overruns on the
listening process, crashing it and forcing some code to execute. There
have been a lot of these exploits on services, e.g. on the qpopper,
sendmail and others. But if you only listen to a specific device this
will only be a problem to those having access to the subnet of this
device connected to. 

So we can forget this security paranoia here. :-)

> > I really think checking if we are connected is a good idea, but for some
> > systems it might be good to have a force-connected (clients over
> > gateway) or force-not-connected option (dod).
> 
> Right, but by dod you still are looking whether the local device is
> connected.  You just assume that the gateway is not connected.  What does
> this mean, though -- if the remote device is connected, and I have an
> e-mail to send, it won't be sent b/c I'm afraid to check?  OK, this is
I think most networks having gateways to Internet have a mailserver
installed nereby, for offline mailing becomes easyier for the users
then. And a gateway is installed to connect two different NETs together,
i.e. you have multiple clients which may want to access the internet
through the gateway. But i may be wrong ... :-)

Well, i wanted to show that there are some kind of networks that are to
be handled separately. The one which causes most problems of these is a
masquerading system with a firewall inbetween, making connections on
demand to the isp. A DOD system should at least fullfill two things:
Transparent use by the user and avoiding unwanted connections, for they
mean unwanted produced costs.

I think, a desktop with a URL-based filemanager makes the chance bigger
of "unwanted connections", when a user follows a link which is not local
and doesn't even know it.
I don't think this will keep a user off working, for when he wants the
questions turned off he won't get any connections. The user is aware off
this, for he switched them off ("Do you want to proceed?  -> No to All). 

So when there should be a check if we are connected, why shouldn't we
take care of this anyway.

To perfect confusion: For we have two nets (the outside - Internet, and
the local) we could
also want to check if local connections are possible additional to those
for the outside. So we can check if a routes assumed to "local network"
are up and if those to the e.g. internet are up. Or more simple: We
assume local net is always up, check if the connection to be made is
local or remote and perform (local) or check if connected (remote) and
connect in that case.

> possible, but a bad solution, best solution is have a small daemon on the
> gateway that tells device 2 (local) whether or not device 1 (Internet) is
> connected, this is such a small thing.\

I still think this is the easiest and a good idea, but i think we should
have solutions for situations where this isn't possible (Maybe
gateway/router is something special, i.e. hardware router, cisco or
something like that), as well.


Well, this got too long again...

Regards,
  Holger

[prev in list] [next in list] [prev in thread] [next in thread]