North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: "portscans" (was Re: Arbor Networks DoS defense product)

  • From: Scott Francis
  • Date: Sat May 18 16:54:56 2002

On Sat, May 18, 2002 at 04:10:53AM +0000, [email protected] said:
[snipage throughout]
> > up your network, or risk being blackholed." If no response is received, and
> > scans continue, blackhole. Simple as that, and puts responsibility back on
> > the shoulders of the offending network.
> 
> Oh but there _WILL_ be disputes. Even with spam there is considerable enough
> gray area that I find solutions like the RBL distasteful, and the questions
> surrounding what is and isn't a portscan will be much, much, worse.  The
> simple fact is that there are no good definitions of a portscan.  I say this
> because I work on developing IDSes and portscan detectors amongst other
> things.

there doesn't have to be a good definition. If network B receives what they
consider to be a scan from network A, and network A does not reply to emails
requesting explanation, network B can blackhole. Heck, network B can
blackhole whoever they want for any or no reason. It's _their_ network. An
agreed-upon definition of what constitutes a portscan is not required, by any
means.

> Port agile trojan scans won't be caught by any of your "portscan" detectors.
> Your "portscan" detection will likely only catch admins who have misfired with
> nmap, or kids playing, or legitimate network applications that have high

In which case, a simple email to the network operator in question should
clear up the confusion early in the game, with no harm done. If people can't
be bothered to properly manage their contact information for netblocks,
that's nobody's fault but their own.

> Bitching about portscans is misdirected and stupid, while lacking a good
> definition

again, definition is not necessary. I think many network operators are simply
tired of dealing with crap from other networks and operators that can't be
bothered to clean things up. Consider it fair warning. As long as network
operators are responsible for their networks, they can do as they please,
including denying contact from arbitrary other networks for any or no reason.

> of what a "portscan" is (with all deference to the popularity of nmap :-).
> If you think you have some information there you do not want to leak, put in
> measures to stop this, but route blocking based on contravention of some
> dubious "portscan" regulation is like trying to swat flies with atomic bombs,
> you may get the fly, but arguably the cure is worse than the disease.

Maybe so, but that decision still belongs to the individual network
operators.

> > There's no point to what you have just said. When you find a machine has
> > been rooted, unplug it from the network and commence forensic analysis.
> > Knowingly allowing it to attack other networks is foolhardy at best.
> 
> There we agree to disagree.  Blindly shutting down attackers without any ID or
> attempt to discern motive seems unwise.  But your policies may differ. :-)

This is what forensic analysis is for. You cut off the machine and then
analyze it. Motive is generally pretty obvious - Yet Another Zombie for use
in DDoS, an IRC shell, or a jumping point for further network penetrations.
*yawn* The motives are mind-numbingly common at this point. If proper logging
is in place, you won't lose any information by unplugging the machine as
opposed to allowing the intruders to continue to do whatever they're doing.

> I work with several groups that attempt to study intrusions and intruder
> techniques.  If the villains have broached your defenses and you simply
> patch up the defenses with the same construct that was broached initially,
> blindly hoping they'll go away... well... further more, if you don't
> even look at the villains to identify their motive, strength and number, 
> simply pretending they aren't there... then you aren't being a good
> defender.

Forensic analysis after an intrusion does not require continuing to allow the
intruders to do as they please. For honeypots, of course, this is a different
matter.

> Their loss if true. I pity the fool that cannot laugh.

Just because I have a sense of humor, does not mean I find it amusing when
people penetrate, or attempt to penetrate, my network.

> > Neither are network operators whose networks are constantly under attack.
> > This kind of thing loses its novelty the first time one of your machines is
> > rooted and has to be wiped and rebuilt.
> > 
> > Whether or not it's amusing to you is immaterial. If the person being
> > scanned does not find it so, scans should cease, period.
> 
> By all means if you are under attack, filter and protect yourself.
> 
> However a "portscan" is not an attack.

Precursor to an attack, certainly. As you mentioned earlier, forewarned is
forearmed. If I find myself being scanned, as a responsible network operator
I will contact the operator of the block in question, and if things are not
cleared up to my satisfaction, I will take proactive measures to protect
myself from the attacks that are sure to come by whatever means seem
appropriate and necessary to me.

regards,
--
Scott Francis                   [email protected] [home:] d a r k u n c l e . n e t
Systems/Network Manager          [email protected] [work:]         t o n o s . c o m
GPG public key 0xCB33CCA7              illum oportet crescere me autem minui

Attachment: pgp00032.pgp
Description: PGP signature