I've caused something similar in the past, and it was because NMAP quickly used up all available and allowable sockets, and the TCP tuning on the box (a) didn't allow all that many sockets and (b) didn't allow for rapid "clean-up" of finished sockets. As a result, the TCP-based heartbeat signal from one system to the other couldn't go through (silly admins didn't employ a serial backup heartbeat), and as a result it triggered an "I've fallen and can't get up" signal. Caused quite a mess. :) At 11:40 AM 30/01/2002, Dennis Jenkins wrote: >:) I took down our production Tandem S series mainframe and a VAP (Visa >Access Point?) box (it ran QNX) using nmap. After dealing with the very >irate Tandem Ops guy (I don't blame him), we determined that the nmap >probe triggered some kind of fail-over detection. I induced a hot fail >over from one mainframe some kind of non-existant hot spare. Or >something. Anyway, it was kind of funny. The mainframe might have been >"Mission critical", but it certainly was not fault tolerant... :) > >"Jason Johns - SAS(IT)" wrote: > > > > Today we were using nmap to scan our network and when we scanned our > > Tru64 machines, telnet and ftp froze and timed out. We could not make > > any connections to those ports and existing connections froze. New > > connections were denied for about a minute after the scan was finished. > > I've checked with Compaq and on Securityfocus and neither place has any > > knowledge of this. > > > > We are running Tru64 Unix 4.0D patch kit 3 on Alpha 4100's and 8400's. > > The nmap command line that was used is: > > nmap -T Polite -O -p 23,139 -oM /tmp/lst 'xxx.xxx.16-44.*' > > > > /Jason Johns > >-- >djenkinsat_private Universal Savings Bank. >Security Administrator, Unix Administrator, Alpha Geek > >The three most dangerous things are a programmer with a soldering >iron, a manager who codes, and a user who gets ideas.
This archive was generated by hypermail 2b30 : Mon Feb 04 2002 - 16:48:23 PST