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, this 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 would 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 != 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 ... -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui