[55509] in North American Network Operators' Group
Re: What could have been done differently?
daemon@ATHENA.MIT.EDU (Scott Francis)
Wed Jan 29 23:23:20 2003
Date: Wed, 29 Jan 2003 20:19:28 -0800
From: Scott Francis <darkuncle@darkuncle.net>
To: "Rubens Kuhl Jr." <rkjnanog@ieg.com.br>
Cc: nanog@merit.edu, bdragon@gweep.net
Mail-Followup-To: Scott Francis <darkuncle@darkuncle.net>,
"Rubens Kuhl Jr." <rkjnanog@ieg.com.br>, nanog@merit.edu,
bdragon@gweep.net
In-Reply-To: <018f01c2c6cf$31d81590$1302a8c0@default>
Errors-To: owner-nanog-outgoing@merit.edu
--bajzpZikUji1w+G9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 28, 2003 at 11:13:19AM -0200, rkjnanog@ieg.com.br said:
[snip]
> But this worm required external access to an internal server (SQL Servers
> are not front-end ones); even with a bad or no patch management system, t=
his
> simply wouldn't happen on a properly configured network. Whoever got
> slammered, has more problems than just this worm. Even with no firewall or
> screening router, use of RFC1918 private IP address on the SQL Server wo=
uld
> have prevented this worm attack
Only if the worm's randomly-chosen IP addresses were picked from the valid =
IP
space (i.e. not RFC1918 addresses), and although I am not sure, I doubt the
worm's author(s) was that conscientious.
Later, on Wed, Jan 29, 2003 at 19:01:25 -0500 (EST), <bdragon@gweep.net>
replied:
> RFC1918 addresses would not have prevented this worm attack.
> RFC1918 !=3D security
All too true. However, using NAT/packet filtering can at least prevent
casual/automated network scans. Of course, if one was implementing proper
filtering, 1434/udp wouldn't be accepting connections from outside sources,
whether directly or through NAT/port forwarding. But then, this observation
has been made many times already ...
--=20
-=3D Scott Francis || darkuncle (at) darkuncle (dot) net =3D-
GPG key CB33CCA7 has been revoked; I am now 5537F527
illum oportet crescere me autem minui
--bajzpZikUji1w+G9
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)
iD8DBQE+OKfQWaB7jFU39ScRAjFnAKCXQk2rDX7ZkzvAW53A4e+5RCze8ACg1HsK
Z9OHmuu13lhrpL8ViETrNOQ=
=9Hx8
-----END PGP SIGNATURE-----
--bajzpZikUji1w+G9--
