tom@wcc.oz.au (Tom Evans) (05/21/91)
In article <1991May17.195516.17707@terminator.cc.umich.edu>, cmclark@predator.rs.itd.umich.edu (Charles Clark) writes: "Terminator"? "Predator"? No wonder I'm being attacked :-). > tom@wcc.oz.au (Tom Evans) writes: > > > >Classify "unauthorised use" of Watch, Peek et.al. as being ... > > Like what? Not let you use your network? So then anybody who can > start up a "sniffer" can instantly blow away everyone else's ability to > use their network? Cool <-sarcasm It could stop you from using YOUR network connection. Why should this affect anybody else's network connection? Shouldn't. Doesn't. Won't. > >moyman@ECN.PURDUE.EDU (Mike Moya) writes: > >> ... that sniff the AppleTalk NBP *REGISTER* themselves on the NET. > > > >I agree, but I thought that all these programs "took over" the > >hardware, thus preventing any other activity (like responding to an > >NBP LookUp) on that Mac. I've just checked this. When you run Peek, or Peek5 or Watch on a Mac, they do not respond to NBP LookUps. They become "invisible". InterPoll can't see them (responder or anything else). As I suspected, they are too busy "peeking" to do anything else. > Say what? This would basically make all "sniffer" products worthless. > If I am trying to debug network problems by capturing packets, and my > presence on the net *changes* how the other machines are acting, then > it would be poor debugging tool, wouldn't it? Bzzzt! Again. It only affects the machine it is running on. "*changes* how the other machines are acting"? It doesn't. I mailed a long description of how to possibly distinguish "Mac Off" and "Mac on but promiscuous" to the original poster. It relied on querying the intervening gateway's error statistics for that channel to see if the Mac responded to "LAP RTS" packets, or if it didn't (the latter count as a "hard collision" in the router's error counters). Unfortunately, both Peek and Watch so totally take over the LocalTalk port that they don't respond to ANY packets. So you can't tell from the network if it is running one of these or if it is turned off. Shame. > >How about requiring ALL Macs to run Responder, and have a central > >monitoring program look for and log Macs that have gone "off air" > > Except that there are myriad reasons why macs go "off air"... Of course, but a Mac in a Student Lab going "off air" at lunchtime is probably worth inspecting. You can probably recognise a Watch or Peek screen from the back of the room, and then you can assault the perpetrator. This sort of "omniscience" can be very disturbing :-). Real solution. Break up your network with Routers. Put all the "sensitive" Macs and LaserWriters on networks that the students aren't on. If they can only peek on each other (and each other's student account passwords) then they can only hurt each other. If the network is confined to the one room, and the Students are made aware of the problem, then they'll probably solve the problem themselves (read "bash anyone they catch peeking on their passwords). ======================== Tom Evans tom@wcc.oz.au ** ADD ".au" MANUALLY (don't trust "reply") ** Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179 A.C.N. 004 818 455