Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
User Journal

Journal spun's Journal: Scan Monkeys Crash Interface 3

Oh brother. We've got our major in house application running on HP-UX. Apparently, the security team has port scanned this behemoth before, and crashed it. Port scans shouldn't crash a decent server, I know. It's behind multiple firewalls, so it never even gets seen by outsiders. Anyway, today the security team asked me for permission to port scan our IBM Bladecenter environment. I know there's nothing there they can crash with Nessus, so I said, "Fire away!"

The HP-UX server isn't even on that network segment, but we gave them a list of 'off limits' IP addresses anyway. Here's a tip: don't give scan monkeys a list in two columns, such as "primary interface" and "secondary interface." They may not look at the second column. They scanned the secondary interface, which all 2,500 fricken' clients in the state connect through, and crashed it, hosing the IP stack. And bringing a big Sybase server down and back up is not quick. We're talking an hour, multiplied by 2,500 people. And they lost everything they were working on at the moment.

Between 9 Ultrium-3 tapes going bad all at the same time (maybe heat stress from the cooling failure a month ago) and this, it's been a stressful week.

This discussion has been archived. No new comments can be posted.

Scan Monkeys Crash Interface

Comments Filter:
  • brought down every Oracle 7/8/9 server I ever tried.

    I told 'em to get tcpwrappers on those things, ASAP as a start. All it took was heavy SYN on 1521.
    • by spun ( 1352 )
      We had HP come out. This was supposed to be fixed. The exclusion list was supposed to be a failsafe. Dammit.
  • The worst I ever saw was my boss...

    They tried to switch out an attached tape drive on an old Solaris mainframe. Well, the old bitch held up through the hotswapping of it's SCSI tape drive (which was suprising because it didn't have that kind of scsi interface), but, when they realized the new SCSI drive had the wrong number, and fiddled it to the correct number while it was still plugged in to the running server...Well, that took it down. They probably conflicted every SCSI id on the damn machine at one poi

The key elements in human thinking are not numbers but labels of fuzzy sets. -- L. Zadeh

Working...