Robin <[EMAIL PROTECTED]> writes:

> Any internet connected host can expected to be scanned in a fairly aggressive
> manner at any time. It happens regularly. I find plenty of scans, fragments and
> other network oddities accumulating in my firewall logs. If my systems were
> liable to fall over from a port scan I'd want to know in advance and fix the
> problem not the cause.

True and your systems should be firewalled anyway but some of the
problems are very hard to track down like the old solaris one where a
stealth port scan from nmap (common) didn't panic the kernel straight
away but when inetd was HUPed (rare).

The chances of you associating these two events is unlikely (although
obviously at least one person did).

> > nmap with the default flags crashes some legacy systems so be careful
> > if you are scanning more than one address.  I recently read a weblog
> > (I can't find the link alas) where a junior sysadmin was nmaping a
> > subnet at work through cron and regularly crashing another departments
> > mainframe with it.
> 
> sounds like the machine was not safe to be allowed onto the network. Always
> assume the worst.

I found the link

<http://mah.everybody.org/blog/2001_12_30_blog>

In many cases these things get put on networks almost by accident
("its OK its behind the firewall") or because there is supposed to be
a need and technical considerations often come last in reality as we
all know.

> > In fact if you supplied the "right" flags to nmap you could probably
> > crash virtually any system with it.
> 
> yer reckon? ... I think I've tried most of the obvious ones .. not had a Linux
> box fall over on me yet .. feel free to send me some option strings to try ..

google for "nmap crashes" -- even a search restricted to the last
three months finds loads of examples.

You would want to send bizarre combinations of option flags set in
unusual orders -- stuff along the lines of the traditional "Christmas
Tree Packet" (all options on) and forging IP and MAC addresses. On
linux you would probably want to start with varients of historic
denial of service attacks (like teardrop and land) and test against
every new kernel release.

Sending stuff really fast may help as well.  Programs like iptest
(from ipfilter) are designed to do this sort of thing (find networking
bugs) and the man page has suggestions.

<http://www.gsp.com/cgi-bin/man.cgi?section=1&topic=iptest>

If you can't panic the kernel you may be able to crash network
services.

A lot of things are networked now (printers, hubs etc) not just
computers and the chances of all their stacks and networking software
dealing sanely with really bizarre networking traffic is probably
quite low.

-- 
Steve Mynott <[EMAIL PROTECTED]>

Reply via email to