🚀 go-pugleaf

Ben Lovejoy <ben@lovejoy.demon.co.uk> wrote:

Snip loads of stuff which is very useful to me, as I'll shortely be
implementing something similar

> For fixed machines, you no longer need PPP. For PowerBooks which will
> continue to use dial-up access outside the office, you have to create a
> second 'environment' and then switch between the two. This is a slight pain
> that I'll create a Keyquencer macro to sort.

Have a look at Apple's free Location Manager


-- 
'ric

btgsch@rmplc.co.uk (ric) wrote:

>Snip loads of stuff which is very useful to me, as I'll shortely be
>implementing something similar

Anything else I can tell you about it, just ask.

>> For fixed machines, you no longer need PPP. For PowerBooks which will
>> continue to use dial-up access outside the office, you have to create a
>> second 'environment' and then switch between the two. This is a slight pain
>> that I'll create a Keyquencer macro to sort.

>Have a look at Apple's free Location Manager

I've got it on my machine, but no documentation. Anyone got a quick guide?

Ben
-- 
Ben Lovejoy             | For special addresses
ben@lovejoy.demon.co.uk | (auto-responder, etc):
www.lovejoy.demon.co.uk | autoresponder@lovejoy.demon.co.uk

Ben Lovejoy wrote:
> 
> Demon's Corporate Services people redeemed themselves today, successfully
> installing our ISDN router and configuring the Mac network for use with a
> Network Dial-Up (NDU) account.
> 
> For anyone considering an NDU account, the basic facts and first
> impressions ...
[snip]

Thanks for sharing this with us. The only extra recommendation that I would
make to anyone else considering such a thing is to include a firewall as well.
The extra security comes from both the presence of the firewall machine and
the fact that you can then run the internal network using "illegal" ip addresses.

Anyone trying to hack-in then only has one ip address to target (that of the
firewall machine) rather than the 100 or so that Demon allocate. It means that
your administrator has only one machine to try and keep secure instead of
every machine on your network - a somewhat unrealistic proposition.

Regards,

-- 
Bruce Horrocks
Hampshire
England
bh@granby.demon.co.uk

Bruce Horrocks <bh@granby.demon.co.uk> wrote:

>> For anyone considering an NDU account, the basic facts and first
>> impressions ...
>[snip]

>Thanks for sharing this with us. The only extra recommendation that I would
>make to anyone else considering such a thing is to include a firewall as well.

How real are the risks? Given that a hacker would have no knowledge of our
internal IP addresses, nor any of the filenames, folder structures, etc,
where would they start? Does anyone know of any documented cases of hacking
into an NDU account?

We do have sensitive data on our machines, so security is a concern if the
risks are significant. OTOH, if the risks are extremely low, then I'd
rather avoid the hassle of restructuring the network - especially as there
is no central server.

Ben
-- 
Ben Lovejoy             | For special addresses
ben@lovejoy.demon.co.uk | (auto-responder, etc):
www.lovejoy.demon.co.uk | autoresponder@lovejoy.demon.co.uk

Ben Lovejoy <ben@lovejoy.demon.co.uk> wrote:

> We do have sensitive data on our machines, so security is a concern if the
> risks are significant. OTOH, if the risks are extremely low, then I'd
> rather avoid the hassle of restructuring the network - especially as there
> is no central server.

In that case a firewall makes sense. Have a look at Vicom's Internet
Gateway which is cheap and can (at a pinch) be run on a non-dedicated
machine. You will also need MacDNS if you want to do this sensibly and
an SMTP/POP3 mail server such as SIMS from Stalker Software also makes
sense.... as does having a separate gateway machine. All of this stuff
will run happily on a low-end Power Macintosh and it makes good sense to
have a separate server.

If you want to do this on the real cheap, and provide a good service to
your users it is possible to set up a Linux box as a router. I can
arrange for this to be done for you as a commercial service, but if you
want to DIY, then it's definitely a case of being on your own. I haven't
as much time free as it takes to talk someone into doing the right
things by remote control.


-- 
Steve Firth                . Amand's Law of Management: Everyone is
steve@firthcom.demon.co.uk . always someplace else.
Random sigs for Internet   . 
Config from sigFried 0.1a  . 

filter@firthcom.demon.co.uk (Steve Firth) wrote:

>> We do have sensitive data on our machines, so security is a concern if the
>> risks are significant. OTOH, if the risks are extremely low, then I'd
>> rather avoid the hassle of restructuring the network - especially as there
>> is no central server.

>In that case a firewall makes sense.

Can you give me an idea of how a hacker might attack an NDU network? In
particular, why the risk is higher than with dialup accounts?

Ben
-- 
Ben Lovejoy             | For special addresses
ben@lovejoy.demon.co.uk | (auto-responder, etc):
www.lovejoy.demon.co.uk | autoresponder@lovejoy.demon.co.uk

Ben Lovejoy <ben@lovejoy.demon.co.uk> wrote:

> Can you give me an idea of how a hacker might attack an NDU network?

Because they can. Most hacking seems to be a matter of curiosity, people
just trudge around the net looking for insecure sites, then getting in
and seeing what's lying around. Some do it for fun, some to steal
software and there are nasty little tricksters as well. Hacking is less
of a problem with a Mac based network because the lack of a CLI and a
suite of internet tools which can be driven via a CLI confuses the heck
out of a hacker.

However, security on Mac networks is usually dreadful, with users
choosing to share volumes at random and often without passwords. Hence a
clued up hacker can often get more out of a Mac network once they
realise what kind of system they are connecting to.

> In particular, why the risk is higher than with dialup accounts?

With a dialup account, a hacker has to get in when your system is up,
which tends to happen in 15 - 30 minute slots randomly dispersed through
the day. Also with a dialup account, the hacker can't connect when they
want, only when you decide to connect to the host router. 

-- 
Steve Firth                . I really hate this damned machine I wish
steve@firthcom.demon.co.uk . that they would sell it. It never does
Random sigs for Internet   . quite what I want But only what I tell it.
Config from sigFried 0.1a  . 

In article <34A7A9E8.56B2D140@granby.demon.co.uk>,
Bruce Horrocks <bh@granby.demon.co.uk> wrote:

>  The only extra recommendation that I would
> make to anyone else considering such a thing is to include a firewall

I recently found out (at a job interview !) that some routers can
do a similar thing ... refrain from passing along certain types of
packet to certain machines.  You could, for example, block all
http connections except to the one machine you set up as a web
server and block all smtp connections to machines that shouldn't
deal with external email.

If you consider setting-up a router to be better than setting-up
yet another UNIX machine, you might try this.

Simon.
-- 
Simon Slavin -- Computer Contractor. | Excessive quoting from Shakespeare:
   http://www.hearsay.demon.co.uk    |                  gag me with a folio.
Check email address for spam-guard.  | -- sclerc@ernie.bgsu.edu (Susan Clerc)
Junk email not welcome at this site. | I receive about 2.5 junk emails a day.

Steve Firth <filter@firthcom.demon.co.uk> wrote:

> Ben Lovejoy <ben@lovejoy.demon.co.uk> wrote:
> 
> > Can you give me an idea of how a hacker might attack an NDU network?
> 
> Because they can. Most hacking seems to be a matter of curiosity, people
> just trudge around the net looking for insecure sites, then getting in
> and seeing what's lying around. Some do it for fun, some to steal
> software and there are nasty little tricksters as well. 

"I used to be a hacker, now I'm a Corporate Computer Security
Consultant"....

ISTR there used to be some good stuff linked from the Apple site
about a Swedish Mac-based security challenge - can't remember
the URL now, I'm afraid.

Basically what Steve said is correct - it's much harder to
get into a Mac 'cos they tend not (unless you want them) to
run SMTP gateways, telnet/ftd deamons, gettys etc.

_Providing Internet Services Via the MacOS_ [1] has some 
good info, mainly on running Peter Lewis's stuff.

rgds, Alan
[1] ISBN 0-201-48998-8, Addison-Wesley <http://www.aw.com/devpress/>

filter@firthcom.demon.co.uk (Steve Firth) wrote:

>> Can you give me an idea of how a hacker might attack an NDU network?

>Because they can. Most hacking seems to be a matter of curiosity

Sure, but I mean how they would go about it? I'm unclear as to where the
risk lies. What do they do - try to telnet to an IP address or what?

>However, security on Mac networks is usually dreadful, with users
>choosing to share volumes at random and often without passwords. 

All our volumes are password-protected.

Ben

-- 
Ben Lovejoy             | For special addresses
ben@lovejoy.demon.co.uk | (auto-responder, etc):
www.lovejoy.demon.co.uk | autoresponder@lovejoy.demon.co.uk

In article <B0CF2F8A9668103526@lovejoy.demon.co.uk>,
ben@lovejoy.demon.co.uk (Ben Lovejoy) wrote:

> Bruce Horrocks <bh@granby.demon.co.uk> wrote:
> 
> >[snip] include a firewall as well.
> 
> How real are the risks? Given that a hacker would have no knowledge of our
> internal IP addresses, nor any of the filenames, folder structures, etc,
> where would they start?

Try connecting to all the common ports (http, nntp, pop3, smtp, telnet,
ftp, etc.) for every machine on your subnet.  If one of those works,
take a look at the transcript and take it from there.  Should take two
or three seconds per machine to explore all the useful ports.

> Does anyone know of any documented cases of hacking
> into an NDU account?

I know of such cases.  I am not permitted to produce documentation
of them.  The machines attacked were at a company which had recently
installed a system like yours.  While the company involved did work
which would be 'spoiled' if leaked to the public, the work wasn't
anything to do with the military or anything SOOPER SEKRIT, just a
normal company with around 50 micros connected to the net.  I think
they were attacked not because of what they did, but because they
were there.

The installation was secure -- the cracking attempt showed only
because I noticed that the router was unusually busy and checked
some of the logs.

Simon.
-- 
Simon Slavin -- Computer Contractor. | Excessive quoting from Shakespeare:
   http://www.hearsay.demon.co.uk    |                  gag me with a folio.
Check email address for spam-guard.  | -- sclerc@ernie.bgsu.edu (Susan Clerc)
Junk email not welcome at this site. | I receive about 2.5 junk emails a day.

Ben Lovejoy <ben@lovejoy.demon.co.uk> wrote:

> Sure, but I mean how they would go about it? I'm unclear as to where the
> risk lies. What do they do - try to telnet to an IP address or what?

That's one route. Others include exploiting known weaknesses such as
program linking, printer sharing, oddball Java weaknesses. Basically if
they can launch or control an application on your machine (somehow) then
they have a route in.

I'm trying hard not to be specific about this because what little I do
know is covered by non-disclosure agreements. How about taking it as
read that connectign a system to the net without a firewall is a
security risk. How big a risk depends upon the sensitivity of the
information that you store and the financial risk if someone should
happen to get in and (say) trash all the info on your system.

-- 
Steve Firth                . First Law of Bicycling: No matter which way
steve@firthcom.demon.co.uk . you ride, it's uphill and against the wind.
Random sigs for Internet   . 
Config from sigFried 0.1a  . 

Simon Slavin <slavins@hearsay.demon.co.uk.NOJUNK> wrote:

> I think
> they were attacked not because of what they did, but because they
> were there.

I've worked at places that were supposedly secure installations that had
been hacked into. Same as above, it wasn't targetted, in fact what gave
the game away was the hackers panic when they realised what they had
done.

-- 
Steve Firth                . First Law of Bicycling: No matter which way
steve@firthcom.demon.co.uk . you ride, it's uphill and against the wind.
Random sigs for Internet   . 
Config from sigFried 0.1a  . 

slavins@hearsay.demon.co.uk.NOJUNK (Simon Slavin) wrote:

>> How real are the risks? Given that a hacker would have no knowledge of our
>> internal IP addresses, nor any of the filenames, folder structures, etc,
>> where would they start?

>Try connecting to all the common ports (http, nntp, pop3, smtp, telnet,
>ftp, etc.) for every machine on your subnet.

Wouldn't they need the subnet addresses? How would they get these?

Sorry to keep pushing on this one, but I really do need to get some kind of
meaningful sense of the risks involved before deciding what precautions
need to be taken.

Ben

-- 
Ben Lovejoy             | For special addresses
ben@lovejoy.demon.co.uk | (auto-responder, etc):
www.lovejoy.demon.co.uk | autoresponder@lovejoy.demon.co.uk

filter@firthcom.demon.co.uk (Steve Firth) wrote:

>That's one route. Others include exploiting known weaknesses such as
>program linking, printer sharing, oddball Java weaknesses. Basically if
>they can launch or control an application on your machine (somehow) then
>they have a route in.

It's the 'somehow' bit I'm trying to understand. I appreciate that it
wouldn't be wise to get too specific in a public forum, but how could
someone even begin an attack without knowledge of the IP addresses?

Feel free to use email if you feel that to be safer.

>How about taking it as
>read that connectign a system to the net without a firewall is a
>security risk. How big a risk depends upon the sensitivity of the
>information that you store and the financial risk if someone should
>happen to get in and (say) trash all the info on your system.

Trashing info isn't really a concern since we have automated backup s/w
which does a complete backup of each machine each evening just prior to
shutdown (except for the PowerBooks which aren't permanently connected
anyway and which have SyQuest drives for manual backups). But most of our
work is commercially sensitive in that it would have value to a competitor
of one of our clients. I'm thus trying to make some kind of realistic
assessment of the risk.

Ben

-- 
Ben Lovejoy             | For special addresses
ben@lovejoy.demon.co.uk | (auto-responder, etc):
www.lovejoy.demon.co.uk | autoresponder@lovejoy.demon.co.uk

Ben Lovejoy wrote:
[snip]
> Sorry to keep pushing on this one, but I really do need to get some kind of
> meaningful sense of the risks involved before deciding what precautions
> need to be taken.

Ben,

You can't eliminate the risk of someone hacking into your system. What you can
do though is to minimise the chance of someone getting in, and secondly,
minimise the damage than can be inflicted if someone does get in. A firewall
achieves both of these in a number of ways.

Suppose that I knew of a way to hack into a standard Mac running OT and I
publicise that information in a hacking forum. All the wannabee hackers
immediately go off attacking every known Mac in sight and word gets back to
Apple who release a patch. Mac users install that patch and sleep easily
again. However in your case you have two options: without a firewall you have
to install that patch on every one of your Macs. With a firewall you only have
to install it on one machine. Well big deal you think, "I've only got a few
tens of machines at the most and it's not that big a problem." But suppose
that while you are away on holiday a user has a disk crash and re-installs the
MacOS. Except they don't know about the patch so their machine is now
vulnerable. Suppose someone hacks in while you are still on holiday and
haven't even had a chance to check up? Well your back's covered but it didn't
help your company much.

If you had taken the firewall approach users wouldn't be allowed to access the
machine so there is no danger of the patch inadvertantly being removed. And
because the machine is solely for use as a firewall you can produce a
backup/recovery tape with all the right software on to be used in the event of
a disk crash. While you're on holiday a deputy can be instructed to only
restore from that tape only should it become necessary to do so.

So the risks here are not what chance is there of being hacked into but what
chance is there of you or a user making an inadvertant change to a machine
that could leave your network vulnerable? Let's face it - if users didn't
screw up their machines on a fairly regular basis we wouldn't need help desks
and system administrators. I think that this risk is nearly unquantifiable in
terms of how many times will it happen in a year on average but

    (small risk) * (one machine) < (small risk) * (tens of machines)

is indisputable.

Not convinced by this scenario? The recent crack-a-mac contest was won, not
because of a weakness in the MacOS or the web server software being used, but
because of a weakness in a third-party add-in to the web-server. Such a
weakness could just as easily be present in an add-in to Netscape, or
Photoshop or whatever. Are you going to prevent all of your users from
installing add-ins? Sooner or later one of them will complain to the boss that
they can't get their work done without such-and-such an add-in. Your response
of "Well it might have a security vulnerability" won't wash because you can't
prove it. Besides your boss probably won't even understand and will (a) tell
you to install the add-in for the user and, (b) still blame you for any
security breach that happens anyway.

In this situation, using a firewall doesn't prevent the add-in from having a
vulnerability but it will help to prevent and contain the activities of any
hacker who does exploit the vulnerability. It will also alert you to
suspicious activity so you'll know about the breach earlier than you would
otherwise, and hopefully before too much serious damage is done. In this
situation the firewall has helped to reduce the consequences of the security breach.

In 99.999% of all hacking incidents that cause damage, the hacking was carried
out either by, or with the assistance of someone inside the targetted
organisation. Usually it's an aggrieved employee getting even, occasionaly it
is bribery, blackmail or some other form of coercion. Companies that
manufacture widgets have procedures to deter employees who try to steal them
from the warehouse so it is perfectly reasonable to try and stop the same
thing from happening with your valuable data. Okay, admittedly, stopping an
employee from stealing data is much harder, but at least a firewall could be
configured to log data transfers - dates, times, volumes, ip addresses etc.
Without a firewall you would have no evidence at all.

What about pornography and related evils of the internet? The security advisor
for my own company was telling me (and this happened only recently, just
before Christmas) that an employee was escorted to the door to be arrested by
waiting police officers for downloading child pornography using the company's
internet link. What gave him away was the fact that the corporate firewall
logs all accesses by source and destination ip address, time of transfer etc.
and in his case these details were a bit supicious. Without the firewall we
may never have known.

Now comes the nightmare scenario to have sleepless nights over. Suppose that
we didn't have the firewall, didn't keep the logs and hadn't found out
ourselves but instead the police had caught him by other means. Suppose that
he claims in his defence that the company had led him astray by providing
unfettered access to such material? Where does that leave us? The internet and
criminal law is a whole new ball game with little in the way of precedent. Do
you want to be the company that has to fight the test case in such a
situation? Besides, even if you win, mud sticks and the company may never live
it down.

The risk of this is slight (although remember that it may yet happen to us)
but the repercussions are horrendous. I suggest that you put a proposal for a
firewall on your MD's desk: if he rejects it because there's only a _slight
risk_ of the system being hacked into then tell him that there's only a
_slight risk_ of him going to prison and see what colour his face turns...

Regards,

-- 
Bruce Horrocks
Hampshire
England
bh@granby.demon.co.uk

Steve Firth <filter@firthcom.demon.co.uk> wrote:

> Ben Lovejoy <ben@lovejoy.demon.co.uk> wrote:
> 
> > Sure, but I mean how they would go about it? I'm unclear as to where the
> > risk lies. What do they do - try to telnet to an IP address or what?
> 
> That's one route. Others include exploiting known weaknesses such as
> program linking, 

Ah - that phrase!  Could you tell me what program linking is?  I've been
trying to find out, and I'm currently clueless.

[snip]

Rowland.

-- 
Remove the animal for my email address:   rebecca@astrid.dog.u-net.com
Sorry - the spam got to me.          
PGP pub key A680B89D; fingerprint: F5605EAE F56F2C0B 818F3319 5227767F
                                   What?  Don't ask me - I don't know.

In article <B0D431199668C5233@lovejoy.demon.co.uk>,
ben@lovejoy.demon.co.uk (Ben Lovejoy) wrote:

> slavins@hearsay.demon.co.uk.NOJUNK (Simon Slavin) wrote:
> 
> >Try connecting to all the common ports (http, nntp, pop3, smtp, telnet,
> >ftp, etc.) for every machine on your subnet.
> 
> Wouldn't they need the subnet addresses? How would they get these?

They probably wouldn't intentionally be concentrating on one
company -- just trying every IP address they could find.  Your
subnet is probably a collection of addresses which are all in
a block: aa.bb.cc.1 to aa.bb.cc.254.

If you have an IP address that isn't behind either a firewall
or a router programmed to drop intrusive packets, their packets
will reach your machines.  If you don't have Internet-type
software on your machines (more than just a web-browser), it
probably doesn't matter.  Some software (like FileMaker Pro)
which isn't obviously Internet-based software will still pick
up some Internet packets and do things with them if correctly
configured -- that's the stuff you have to watch.

Simon.
-- 
Simon Slavin -- Computer Contractor. | If I ran usenet, the timestamp for
   http://www.hearsay.demon.co.uk    | anything posted between 2am and 5am
 Check email address for UBE-guard.  | would *blink*. -- Nancy Lebovitz
My s/ware deletes unread >3 UBEs/day.| Junk email not welcome at this site.

Simon Slavin <slavins@hearsay.demon.co.uk.NOJUNK> wrote:

> Some software (like FileMaker Pro)
> which isn't obviously Internet-based software will still pick
> up some Internet packets and do things with them if correctly
> configured -- that's the stuff you have to watch.

Timbuktu Pro is another not-very-obvious one.
(assuming you normally just use it over AppleTalk)

A more obvious one (but potentially more useful/dangerous) is Peter
Lewis's _Script Daemon_ that allows you to telnet onto a mac
and issue AppleScript commands.

rgds, Alan

Rebecca and Rowland <real-address-in-sig@flurbletigibbet.rhubarb.foobar>
wrote:

> Steve Firth <filter@firthcom.demon.co.uk> wrote:
> 
> > Ben Lovejoy <ben@lovejoy.demon.co.uk> wrote:
> > 
> > > Sure, but I mean how they would go about it? I'm unclear as to where the
> > > risk lies. What do they do - try to telnet to an IP address or what?
> > 
> > That's one route. Others include exploiting known weaknesses such as
> > program linking, 
> 
> Ah - that phrase!  Could you tell me what program linking is?  I've been
> trying to find out, and I'm currently clueless.
> 
I think it is when you allow a program on your machine to be controlled
by reomte apple events.

-- 
'ric

ric <btgsch@rmplc.co.uk> wrote:
> Rebecca and Rowland <real-address-in-sig@flurbletigibbet.rhubarb.foobar>
> wrote:
> > Steve Firth <filter@firthcom.demon.co.uk> wrote:
> > > Ben Lovejoy <ben@lovejoy.demon.co.uk> wrote:
[]
> > > That's one route. Others include exploiting known weaknesses such as
> > > program linking, 
> > 
> > Ah - that phrase!  Could you tell me what program linking is?  I've been
> > trying to find out, and I'm currently clueless.
> > 
> I think it is when you allow a program on your machine to be controlled
> by reomte apple events.

AIUI, kind of, but it's a bit more than that.
['tho it does let you write AppleScripts like:
----
Tell application "MacSOUP" on machine "My Mac" in zone "Ground Floor"
  connect with fetching news and sending
end tell
---]

It's used to allow programs on different machines to communicate
(using the standard file shareing privs). Things like AppleSearch use it
to provide non-file-server server services. (IYSWIM)

Another app I've used that uses it is "teleport"[1] that creates
a window on each Mac running it and allows anything to be dragged
and dropped onto it - the item (text & other media) then automagically
appears on the other Mac - rather usefull if you're lucky enough
to have two macs on your desk.

There is another much more common example, but I can't remember it right
now...

rgds, Alan
[1] from MacHack, ISTR

In article <1d2fdvy.1hvrc5wsadth8N@rm-dynf1-159.rmplc.co.uk>,
btgsch@rmplc.co.uk (ric) wrote:

> Rebecca and Rowland <real-address-in-sig@flurbletigibbet.rhubarb.foobar>
> wrote:
> 
> > Could you tell me what program linking is?  I've been
> > trying to find out, and I'm currently clueless.
> > 
> I think it is when you allow a program on your machine to be controlled
> by reomte apple events.

Correct answer, as far as it goes.

Program linking lets one program tell another program what to do.
The use of it you're probably most familiar with is when you make
AppleScript tell a program to do something.  It's possible for
programs to tell each-other what to do without using something
as clunky as AppleScript: they communicate using Apple Events.

Now, if two Macs are connected to each-other over a network
a program on one Mac can tell a program on the /other/ Mac what
to do -- if and only if you have a password and remote program
linking enabled.  This is useful for database engines and using
one Mac to run a slide-show on another, etc..  It's easy and fun
to set up an AppleScript demo of this working and it scares the
heck out of people who don't know what's going on.  Which is nice.

Now, if only Disk First Aid was scriptable, I could get all my
user's Macs to check their hard disks at once.

Simon.
-- 
Simon Slavin -- Computer Contractor. | If I ran usenet, the timestamp for
   http://www.hearsay.demon.co.uk    | anything posted between 2am and 5am
 Check email address for UBE-guard.  | would *blink*. -- Nancy Lebovitz
My s/ware deletes unread >3 UBEs/day.| Junk email not welcome at this site.

Ben Lovejoy <ben@lovejoy.demon.co.uk> wrote:

> filter@firthcom.demon.co.uk (Steve Firth) wrote:
> 
> >I've seen several sites where I've been assured that all
> >the Macs had file sharing disabled and that guest access was blocked
> >only to find that I could log in within minutes as a guest onto a users
> >machine.
> 
> I'm sure.
> 
> Incidentally, there seems to be a bug in File Sharing.

Well, there was the old "mis-feature" in 7.0 (or maybe 7.0.1) where
sharing was *on* by default, until you switched it off....

>I configured one Mac on a (different company's) network so that one
>>volume had nothing checked (no see, read or write) even for the owner
>when accessing remotely. This wasn't for any security reasons, just to
>avoid confusing people with an irrelevant volume. Yet the volume still
>showed up on the network.

Did the machine have other volumes shared, and did it show up
greyed out?
"They all do that sir"

If you want to avoid confusing people, give them aliases - in the 
past I've managed to upgrade servers (from a Q700 to a Workgroup
Server) *without* any users' aliases breaking. :-)

rgds, Alan

slavins@hearsay.demon.co.uk.NOJUNK (Simon Slavin) wrote:

>If you have an IP address that isn't behind either a firewall
>or a router programmed to drop intrusive packets, their packets
>will reach your machines.  If you don't have Internet-type
>software on your machines (more than just a web-browser), it
>probably doesn't matter.  Some software (like FileMaker Pro)
>which isn't obviously Internet-based software will still pick
>up some Internet packets and do things with them if correctly
>configured -- that's the stuff you have to watch.

Ah, don't think there's a problem there - we don't have anything like that.

Ben

-- 
Ben Lovejoy             | For special addresses
ben@lovejoy.demon.co.uk | (auto-responder, etc):
www.lovejoy.demon.co.uk | autoresponder@lovejoy.demon.co.uk

filter@firthcom.demon.co.uk (Steve Firth) wrote:

>I've seen several sites where I've been assured that all
>the Macs had file sharing disabled and that guest access was blocked
>only to find that I could log in within minutes as a guest onto a users
>machine.

I'm sure.

Incidentally, there seems to be a bug in File Sharing.

I configured one Mac on a (different company's) network so that one volume
had nothing checked (no see, read or write) even for the owner when
accessing remotely. This wasn't for any security reasons, just to avoid
confusing people with an irrelevant volume. Yet the volume still showed up
on the network.

Ben

-- 
Ben Lovejoy             | For special addresses
ben@lovejoy.demon.co.uk | (auto-responder, etc):
www.lovejoy.demon.co.uk | autoresponder@lovejoy.demon.co.uk

In article <B0E157699668ED2A8@195.173.76.4>,
ben@lovejoy.demon.co.uk (Ben Lovejoy) wrote:

> Incidentally, there seems to be a bug in File Sharing.
> 
> I configured one Mac on a (different company's) network so that one volume
> had nothing checked (no see, read or write) even for the owner when
> accessing remotely. This wasn't for any security reasons, just to avoid
> confusing people with an irrelevant volume. Yet the volume still showed up
> on the network.

It showed up for the owner, or for other people? The owner of a Mac can
always access all volumes if filesharing's enabled. Whether this is a bug
of a feature is another matter. :-)

Paul Durrant

alan.frame@acm.org (Alan W. Frame) wrote:

>> Incidentally, there seems to be a bug in File Sharing.

>Well, there was the old "mis-feature" in 7.0 (or maybe 7.0.1) where
>sharing was *on* by default, until you switched it off....

No, it (generally) stays off - the exception being that I always get an
AppleShare error on bootup with Location Manager set to my 'no network
present' and 'AppleShare off' settings, but it's fine if I boot with
network present and then switch LM once it's up.

>>I configured one Mac on a (different company's) network so that one
>>>volume had nothing checked (no see, read or write) even for the owner
>>when accessing remotely. This wasn't for any security reasons, just to
>>avoid confusing people with an irrelevant volume. Yet the volume still
>>showed up on the network.

>Did the machine have other volumes shared, and did it show up
>greyed out?

No, but I understand now from Paul that the owner /always/ has access, no
matter what the settings say.

>If you want to avoid confusing people, give them aliases

Good idea.

I seem to be ending up default IT manager here by virtue of knowing more
than anyone else, and you lot are largely to blame for this. :-)

Ben

-- 
Ben Lovejoy             | For special addresses
ben@lovejoy.demon.co.uk | (auto-responder, etc):
www.lovejoy.demon.co.uk | autoresponder@lovejoy.demon.co.uk

pdurrant@durrant.demon.co.uk (Paul Durrant) wrote:

>The owner of a Mac can
>always access all volumes if filesharing's enabled.

That explains it, ta.

>Whether this is a bug of a feature is another matter. :-)

Bug! :-)

Ben

-- 
Ben Lovejoy             | For special addresses
ben@lovejoy.demon.co.uk | (auto-responder, etc):
www.lovejoy.demon.co.uk | autoresponder@lovejoy.demon.co.uk