Firewall Wizards mailing list archives
RE: terminal services
From: "Paul D. Robertson" <proberts () patriot net>
Date: Tue, 28 Jan 2003 17:59:35 -0500 (EST)
On Tue, 28 Jan 2003, Noonan, Wesley wrote:
I am not trying to pick on anyone here, but I have some comments/observations inline.
Me too! Add me to the comment list!!!1111 ;)
Through things like VPN connections in many cases. In others, you are
Agreed, and hibernating laptops too- I think it should be a rule that some sort of extra laptop/VPN behaviour must happen on days like that.
The issue isn't just that people inside didn't patch their machines (though by my analysis, to a first approximation virtually every machine they own was likely to be vulnerable)I actually disagree here. The issue with slammer/sapphire is precisely that people didn't patch their machines. Let's review some of the recent history. 1) Code Red. IIRC the patch against code red had been released almost 2 months before Code Red hit, yet so many systems were still vulnerable.
Worse (in terms of damage) was RDS, which was patched years before there was an exploit, but exploited more than anything else until we got the .printer stuff.
2) Nimda. Same thing. The patch against Nimda had been out for quite some time as well. 3) Slammer/sapphire. The patch against slammer/sapphire was released in July of *last* year. We are talking about a patch that is well over 6 months old, IOW, a mature patch. That it was not applied in so many places is just embarrassing, especially after Code Red and Nimda.
Yes, but if you look at all the patches and DLL versions, it's a twisty maze of patches, all seemingly alike. For instance... http://ntbugtraq.ntadvice.com/default.asp?pid=36&sid=1&A2=ind0301&L=ntbugtraq&O=D&F=P&P=5163 Is a post to NTBugtraq that details the versioning thing[1]. Clear as mud, and I'm not at all surprised that MS-based admins had trouble with untangling the patch issues surrounding this thing. Trust me, the primary data Russ used to get to that e-mail wasn't nearly as easy to figure out as it looks. ;) Not only that, I think we can summize by the 9AM Monday in Australia upshoot that MSDE was a bigger factor than SQL Server itself- and patching that wasn't a trivial task _if the user even *knew* it was necessary_-- Now, I don't use MS Project, but if I did, I don't think I'd assume that SQL Server issues would affect my desktop. Worse-yet, there are still third-party products where the vendor will *not support the product* if you apply the patch. Everything from CRM applications to door badge readers- there are raftloads of vendors of turnkey (or not) applications who aren't supporting customers who know they need to patch, let alone encouraging their customers to patch.
; rather, it's that there was a hole. Mostly likely, there was more than one hole, but it only took one, given how virulent this worm was.No doubt, but the holes are secondary to what I believe the root problem is, which is laziness on the part of users, admins and vendors to apply patches in a timely fashion. I fully realize the costs of development, etc. but far too many people seem to think that once they install something, their responsibility is over. Patching systems is something that should be reviewed in the weekly security meetings and the patches should be applied on a regular and timely basis.
Didn't at least one of these patches have a memory leak associated with it?
Now I also realize that people sometimes can't apply a patch because "vendor A says that their software hasn't been tested against that patch", but this is where the vendor culpabilities lie. Vendors need to stop sticking their heads in the sand or waiting for months to years for platform testing support (including spot checking for patches) which only leaves their customers vulnerable. It is irresponsible computing on so many levels that I think it takes away from the problem to simplify it as "don't open holes in your firewall". Anyway, enough from me. Again, not trying to pick on anyone here, but this has been a frequent conversation for me of late and I figured I would toss it out to the list as food for thought. Thanks.
While I'm sure there needs to be some sort of patching discipline, it's not a simple or clear-cut thing. Paul [1] Disclaimer, TruSecure owns NTBugtraq too, and there's an advertisement for something or other (for our people certification thing even) tacked on to the post. Might be advertising on the site too. It's probably a plot to lure you all into our wiley list trap... ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts () patriot net which may have no basis whatsoever in fact." probertson () trusecure com Director of Risk Assessment TruSecure Corporation _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Re: terminal services, (continued)
- Re: terminal services David Lang (Jan 28)
- Re: terminal services Duncan Sharp (Jan 28)
- Re: terminal services Paul D. Robertson (Jan 28)
- RE: terminal services Noonan, Wesley (Jan 28)
- Re: terminal services Steven M. Bellovin (Jan 28)
- RE: terminal services Noonan, Wesley (Jan 28)
- RE: terminal services R. DuFresne (Jan 28)
- RE: terminal services Paul D. Robertson (Jan 28)
- Re: terminal services Barney Wolff (Jan 28)
- RE: firewall design (was: RE: terminal services ) m p (Jan 29)
- RE: terminal services R. DuFresne (Jan 28)
- RE: terminal services Paul D. Robertson (Jan 28)
- RE: terminal services R. DuFresne (Jan 28)
- Message not available
- RE: terminal services Marcus J. Ranum (Jan 28)
- Re: terminal services Barney Wolff (Jan 29)
- Re: terminal services Paul Robertson (Jan 29)
- Re: terminal services Barney Wolff (Jan 30)
- Re: DNS security (Was: re: terminal services) Mikael Olsson (Jan 31)