[47921] in North American Network Operators' Group
Re: "portscans" (was Re: Arbor Networks DoS defense product)
daemon@ATHENA.MIT.EDU (Scott Francis)
Sat May 18 16:53:38 2002
Date: Sat, 18 May 2002 13:48:27 -0700
From: Scott Francis <darkuncle@darkuncle.net>
To: Dragos Ruiu <dr@kyx.net>
Cc: nanog@merit.edu
Message-ID: <20020518204827.GB67349@darkuncle.net>
Mail-Followup-To: Scott Francis <darkuncle@darkuncle.net>,
Dragos Ruiu <dr@kyx.net>, nanog@merit.edu
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-ripemd160;
protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA"
Content-Disposition: inline
In-Reply-To: <20020518041053.0ca11310.dr@kyx.net>
Errors-To: owner-nanog-outgoing@merit.edu
--neYutvxvOLaeuPCA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, May 18, 2002 at 04:10:53AM +0000, dr@kyx.net 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.
>=20
> Oh but there _WILL_ be disputes. Even with spam there is considerable eno=
ugh
> gray area that I find solutions like the RBL distasteful, and the questio=
ns
> 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 t=
his
> 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 a=
ny
means.
> Port agile trojan scans won't be caught by any of your "portscan" detecto=
rs.
> 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 simp=
ly
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 reaso=
n.
> 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 bo=
mbs,
> 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.
>=20
> 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 loggi=
ng
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,=
=20
> 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 t=
he
intruders to do as they please. For honeypots, of course, this is a differe=
nt
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 attac=
k.
> > This kind of thing loses its novelty the first time one of your machine=
s is
> > rooted and has to be wiped and rebuilt.
> >=20
> > Whether or not it's amusing to you is immaterial. If the person being
> > scanned does not find it so, scans should cease, period.
>=20
> By all means if you are under attack, filter and protect yourself.
>=20
> 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 darkuncle@ [home:] d a r k u n c l e . n e t
Systems/Network Manager sfrancis@ [work:] t o n o s . c o m
GPG public key 0xCB33CCA7 illum oportet crescere me autem minui
--neYutvxvOLaeuPCA
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQIXAwUBPOa+GogCD7rLM8ynFAO3Jgf6ApvzhhsgDQDyTHBOshDhd4iHpKaYlUuh
/IgQ5t5AapPuSFUUPOqmD06EnbleG5v7Y6gzpJhMbG8UORHIxcOEa5oW1e4LvFrj
4nZGy4+FJFzVfnKZL/+BqlUapDqL2xfRybhQ/Hu3qku8x3JjXS8w9372HEzXfF8n
xiYW27rF7haqQi4d2LcaLJ9sgB7lWZ8NrfhcFJn+4Kqn9E84AqcoYB6mJ6XKsnO+
49/3H6/D1n0owi4mpc4dDjsL3AbgEiXBFKO+BVdnUDap6orK2kl+5e8d8S73wXws
V/7ZkeCfrFgZE9NOQ+DIsI3uSfqGu1XPrE/dQtdSQCzwk0RjbDcZIAf+PAVPrRY9
xt/9Yx6zJCzTj5x7ZzceOJW/5N2viQyotKbA6fAostiz0z9Zwm2AmSmf+OOkwL0n
T7MIw54em7ZwtghtuMs+E2iCSA1awZFArXFgU94xB0CyMst3Jv5Ks3sApes1DYTB
y4qcnbTsYAobrjBS3uuf8UhqhYDXPNmOrbNNyzwTHY4JCeEgELrJ+wjuae2OSIaf
gVe3OalRGmPd1B8HKX/l8s9i5kIuzyeb04iF6URq6VS23tNlVR6qq2ElCpBnJrzI
6EzC0NwBYPy0Kr1+iVUVzyAI3S6ibrwrbAy7Vg4k4pTJktvdv2q90vviD8wkuVqI
L3MSiFz9lJKPZg==
=qFb/
-----END PGP SIGNATURE-----
--neYutvxvOLaeuPCA--
