Stephen Brown <ICSSMB@ASUACAD.bitnet> (02/22/90)
We've recently experienced problems with VM becoming confused about it's default gateway and it's own Ethernet address. We suspect that an uninformed users cranked-up an incorrectly configured Mac TCP/IP, some how the Mac convinced VM that it's Ethernet address was that of the Mac. Thus while Sniffing, VM would respond to ARPs for it's IP address with the Ethernet address of the Mac; the bad information travelled quickly and soon all the users started sending SYNs to the Mac. IMLing VM TCP/IP solved the problem, I assume by clearing the ARP entry for VM. Does VM consult it's ARP table before the hard-coded configuration? I would not expect this behavior with the IP address AND Ethernet address both being in the config. Secondly, in a separate incident, VM began sending ALL packets to it's default gateway. The cisco router, which is the default gateway, ignored the packets since they were arriving on the network which they were destined. My understanding of the cisco is that global ICMP redirects are not possible, I'm not sure VM would correct the problem even if it received a redirect. There's nothing complicated about the GATEWAY statement: if it's 129.219.0.0 send it direct, otherwise send to 129.219.16.1. Is this known behavior? What can we do to avoid this in the future. Help!? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Stephen Brown (602) 965-5922 Arizona State University, Tempe, AZ 85287-0201 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Paul Goodwin <PGOODWIN@GTRI01.bitnet> (02/22/90)
We have also had an instance where a user started up a MACII and duplicated our mainframe's IP address. Apparrently, the MAC sent out a message saying 'this is my IP address, and this is my ethernet address', which was picked up by the big system. It saw it's own IP address, and updated the online version of it's ethernet address. Our 'fix' was to shutdown and re-ipl the TCP/IP account and reset our 8232. I am not sure if a fix is available for this; our solution was to tell the MAC user not to do it again.... :-) Paul Goodwin Georgia Institute of Technology 'As a general rule, Georgia Tech doubts everything that I say'
Ken Howard <KHOWARD@UVVM.UVIC.CA> (02/23/90)
On Thu, 22 Feb 90 19:40:56 PST Paul Molyski said: >Something all "chief of security" people should be aware of. > I RESIGN!!! >----------------------------Original message---------------------------- >We have also had an instance where a user started up a MACII and duplicated >our mainframe's IP address. Apparrently, the MAC sent out a message saying >'this is my IP address, and this is my ethernet address', which was picked up >by the big system. It saw it's own IP address, and updated the online version >of it's ethernet address. > >Our 'fix' was to shutdown and re-ipl the TCP/IP account and reset our 8232. > >I am not sure if a fix is available for this; our solution was to tell the >MAC user not to do it again.... :-) > >Paul Goodwin >Georgia Institute of Technology >'As a general rule, Georgia Tech doubts everything that I say' --------------------------------------------------------------------- Ken Howard KHOWARD @ UVVM.UVIC.CA Communications Systems, Computing Services University of Victoria 604/721-7659 ---------------------------------------------------------------------
Mike Hojnowski <MQH@CORNELLC.bitnet> (02/26/90)
On Thu, 22 Feb 90 10:19:14 EST Paul Goodwin said: >We have also had an instance where a user started up a MACII and duplicated >our mainframe's IP address. Apparrently, the MAC sent out a message saying >'this is my IP address, and this is my ethernet address', which was picked up >by the big system. It saw it's own IP address, and updated the online version >of it's ethernet address. This is one of the biggest security mistakes you can make. If your IBM mainframe is used for anything you would consider "production", you should have it on a separate wire, isolated by a router. Putting a mainframe on the same wire as a personal workstation is begging for security exposures and availability problems from mistakes like you experienced. >Our 'fix' was to shutdown and re-ipl the TCP/IP account and reset our 8232. > >I am not sure if a fix is available for this; our solution was to tell the >MAC user not to do it again.... :-) The "fix" is to remove the mainframe from the same wire as users. The "workaround" when this problem occurs again (and I'm sure it will), is to shoot the MAC user, remove his machine from the wire, then issue the OBEYFILE command with a profile which contains a single "translate" statement with no parameters. This will cause the ARP cache in TCP/IP to be flushed, and you should be back online without shutting down TCPIP. Mike
Dave Buechner <DBUECHNE@GTRI01.bitnet> (02/28/90)
On Mon, 26 Feb 90 11:20:14 EST Mike Hojnowski said: >On Thu, 22 Feb 90 10:19:14 EST Paul Goodwin said: >>We have also had an instance where a user started up a MACII and duplicated >>our mainframe's IP address. Apparrently, the MAC sent out a message saying >>'this is my IP address, and this is my ethernet address', which was picked up >>by the big system. It saw it's own IP address, and updated the online version >>of it's ethernet address. > >This is one of the biggest security mistakes you can make. If your IBM >mainframe is used for anything you would consider "production", you should >have it on a separate wire, isolated by a router. Putting a mainframe on >the same wire as a personal workstation is begging for security exposures and >availability problems from mistakes like you experienced. > If only I had that much control over network policy around here it'd been done a long time ago! :-| For this to work we'd have to start sub-netting around here as well, which has not been very popular with network policy makers in the past. >>Our 'fix' was to shutdown and re-ipl the TCP/IP account and reset our 8232. >> >>I am not sure if a fix is available for this; our solution was to tell the >>MAC user not to do it again.... :-) > >The "fix" is to remove the mainframe from the same wire as users. The >"workaround" when this problem occurs again (and I'm sure it will), is to >shoot the MAC user, remove his machine from the wire, then issue the >OBEYFILE command with a profile which contains a single "translate" >statement with no parameters. This will cause the ARP cache in TCP/IP to >be flushed, and you should be back online without shutting down TCPIP. > We discovered this later. This does lead me to a further question though. Is there any way to dump the ARP cache so that you can see what it has in it? This could be very helpful in instances such as these. >Mike Dave Buechner Lead IBM Systems Programmer Georgia Institute of Technology, Atlanta, GA, USA