Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Subject: RE: can/should
From: Jonathan Day (jd9812my-Deja.com)
Date: Thu May 25 2000 - 13:00:18 CDT
- Next message: John Mee: "Re: can/should"
- Previous message: Ola Nyström: "Re: can/should"
- Maybe in reply to: Barry Hudson: "can/should"
- Next in thread: John Mee: "Re: can/should"
- Maybe reply: Jonathan Day: "RE: can/should"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
First off, how to identify a portscan. That's
not as easy as it sounds. Lots of packets is a
sign of lots of traffic, but not much else.
(Unless, of course, your boss is even worse at
Quake than StefUserfriendly.:)
Anyone who is serious about damaging a system is
unlikely to be rampaging like a bull in a china
shop. And if they are, they're unlikely to be
much of a problem. The real threats are the ones
you DON'T see. If your firewall is sound, the
password policy sane, and the network traffic
secure, skript-kiddies are about as threatening
as a paper dart.
On the other hand, if someone adapts their
portscanner to sweep your machines over a period
of weeks, sending the individual scans in a
stoccastic manner to keep under IDS thresholds,
THEN you have a problem. Whilst any coder could
modify any Open Source portscanner to work this
way (and probably more than a few have), it does
mean that you won't see them and your IDS
software won't see them. And if you can't see
them, you can't see what they're doing or how
much they know.
There is, of course, an answer. Instead of
worrying about scans (seen or unseen), spend
your time on securing your systems. Then scans,
however invisible, won't reveal anything useful.
How? Easy. Ban telnet and RSH. Install SSH or
OpenSSH instead. Ban .rhosts files. Enforce
strong passwords. Use shadow passwords and/or
PAM. Use IPSec for ALL internal traffic. Use DNS
and router authentication. Use TCP Wrappers, and
deny all access to all services except where
explicitly permitted. Use IPv6 for as much
internal traffic as possible. Install tripwire
or other monitor on the firewall and servers.
That's not the only way to secure a site. It's
merely one way. I doubt it's even the best way.
But it should be little more than an afternoon's
work, and would make your site as bullet-proof
as you're likely to need. With a mix of user and
host authentication for all communications, it
would not be easy for someone to do any harm.
What about DDOS? Also easy. Install CBQ and RED
on your firewall, and set hard limits on the
queues to within the range the network and
servers can support. Then, someone can DDOS all
they like. It won't bring anything down, because
the excess will all fall out of the queue. It
also won't block legitamate use, although it'll
slow it down, as RED will do random drops. This
means that as any DDOS will make the bulk of the
queue, it'll also make the bulk of discarded
packets, allowing -some- (although not as much
as usual) legitamate traffic through.
Last, but not least, how do you ensure that your
fortress is strong and has no hidden back doors?
You've guessed it - it's easy! Just install your
very own portscanner and sweep your site, both
from the inside and the outside, on a regular
Please note: All standard disclaimers apply. Any
resemblance to Real World security, living or
dead, is entirely coincidental.
--== Sent via Deja.com http://www.deja.com/ ==--
Before you buy.
For help using this (nmap-hackers) mailing list, send a blank email to
nmap-hackers-helpinsecure.org . List run by ezmlm-idx (www.ezmlm.org).