Massive DDoS Attack to THE WORLD!!

[WyWyWyWy]

http://forums.military.com/1/OpenTopic?a=tpc&s=78919038&f=409192893&m=4551982416

I can't access about 20% of all websites on the internet today.

[Wombat]

Yes, and it's a bug in MS SQLs servers that had a patch released in <B>July</B>. Damn lazy admins.

[MultimediaMan]

Well, it may be that a patch that was offered way back in July, but sysadmins are generally quite leery of patches without validating them first...6 months sounds like a long time, but in the IT world you tend to take the long view.

If you've ever seen what happens when a bad patch hits 8,000-10,000 Servers, you'll know what I mean.

Most places test in the lab for about a week to a month, then issue the patch to a few machines in the real world for another month or two, then do a wider scale release (~100-500 units) for another few weeks before releasing it to production. That kind of validation takes time. And the paperwork involved is also noteworthy for change control and other whatnot.

[SteveC]

http://average.matrix.net/Daily/markP.html and http://average.matrix.net/Daily/markR.html !!!!

[thop]

Does the patch need Windows (or MSSQL) to restart?

[MultimediaMan]

Yes.

[thop]

So that explains quite a bit while so many systems are still not updated. I guess uptime still comes first.
And as you already said if the patch happens to be broken (the WinNT SP6 which broke quite a few systems, until 6a came out, comes to my mind) and will render machines useless it will become a FIASCO.

[Wombat]

Yes, but this is a security vulnerability patch. It should have been on every system after a month. Look at all the damage done. Look at all the damage done by Code Red and Nimda. Patches were available for a long time. Irresponsible admins cost the rest of the world a LOT of money.

[MultimediaMan]

Lazy is probably too strong a word to use: they were more than likely not able to validate in time. When Code Red was big a while back we knew we were vulnerable, and we got bit by it, bbecuase the testing for the fix wasn't yet finished. Any change that goes out to production must be validated, no matter how small. (I have seen a "non-impacting change" break hundreds of servers simply because of a botched install script.)

You must first validate, especially with mission-critical equipment.

Knowing of your vulnerability and know how to fix it if something bad happens is a much better alternative than blindly sending out a "fix" that behaves unexpectedly. We knew what to do to get our systems back online with minimum disruption. It was a pity we couldn't be more proactive, but we didn't lose any data nor did we have do it twice.

SecAdmin did get a bigger budget, tho...

[WyWyWyWy]

To be honest, it is entirely sysadmins' fault.
RDBMS shouldn't be connected to the internet in the first place.
Because of this, I think most of the affected servers are not from big companies with well-defined change management. They are all small companies who don't have a dedicated db admin (I think).

[the maddman]

Originally posted by WyWyWyWy
To be honest, it is entirely sysadmins' fault.
RDBMS shouldn't be connected to the internet in the first place.
Because of this, I think most of the affected servers are not from big companies with well-defined change management. They are all small companies who don't have a dedicated db admin (I think).

Exactly. This is something that's easily fixed with a firewall. At work, we except incomming connections for web, DNS and email and that's it. And all of it is checked by the firewall and dropped if you don't use the right protocol. I still patch the servers whenever they need it.

I can't believe the number of companies that put servers on the net without a firewall or anything. My policy is nothing Windows is Internet accessable either, but that's just me.

[WyWyWyWy]

Hmm... wait.
Someone just told me that it is possible to use SOAP/XML or similar technology to attach a worm
Obviously they will pass through firewall... hmm... unblockable power?