MS SQL Server Worm Wreaking Havoc 964
defile writes "Since about midnight EST almost every host on the internet has been receiving a 376 byte UDP payload on port ms-sql-m (1434) from a random infected server. Reports of some hosts receiving 10 per minute or more. internetpulse.net is reporting UUNet and Internap are being hit very hard. This is the cause of major connectivity problems being experienced worldwide. It is believed this worm leverages a vulnerability published
in June 2002. Several core routers have taken to blocking port 1434 outright.
If you run Microsoft SQL Server, make sure the public internet can't access it. If you manage a gateway, consider dropping UDP packets sent to port 1434." bani adds "This has effectively disabled 5 of the 13 root nameservers."
Whoever puts their database server (Score:5, Insightful)
NGSSoftware alerted Microsoft to this problem on the 17th of May 2002 and
they have produced a patch that resolves these issues.
This is January 25 2003 if I'm not mistaken. Are these the same people that leave their cars unlocked with the keys in the ignition?
Whoever... (Score:5, Insightful)
Sysadmins like that should be dragged into the street and shot.
Re:As I said in a previous post... (Score:3, Insightful)
The point isn't finding the hole, it's people not patching their servers. I mean FFS this was discovered and patched over six months ago. SQL Server is not consumer software - you can't blame Joe Public for not being up-to-speed on net security issues - this is professionals not doing their jobs properly.
Re:As I said in a previous post... (Score:5, Insightful)
As far as I'm concerned, boxes SHOULD be able to stand on their own without firewalls. A firewall just adds another layer.
Sounds like you're advocating armadillo security to me - hard on the outside, soft on the inside.
Re:As I said in a previous post... (Score:5, Insightful)
Re:As I said in a previous post... (Score:5, Insightful)
the problem is monoculture again (Score:3, Insightful)
Open the gates... (Score:4, Insightful)
Seriously though, you should have upgraded!
Re:Every Server, eh? (Score:1, Insightful)
No mention in media? (Score:1, Insightful)
Re:the problem is monoculture again (Score:2, Insightful)
The argument could be made that with more different types of software, there is a greater risk of DDoS that could cripple the net (although cleanup will be easier in that case, too).
Do ya REALLY think all servers have active SA's? (Score:2, Insightful)
All servers that were placed up there years ago to host one silly site get checked regularly?
All companies (or individuals) who host sites pay to have them maintained?
All sysadmins are competent and on top of their patches
There are alot of servers and alot of sites. There aren't alot of "great" admins IMHO. And, often, patches are bundled together when you upgrade a server which may be once EVERY TWO TO FOUR YEARS.
Reality folks.
Re:As I said in a previous post... (Score:5, Insightful)
"Oh, it's OK because it's behind the firewall..."
I think firewalls make people lazy. Imagine if we didn't have firewalls. We'd have to keep our passwords good, our services minimal, and make sure we were running the latest, most secure daemons.
Re:Such floods can be easily stopped. (Score:3, Insightful)
Wagner LLC Consulting Co. - Getting it right the first time
If I took you for someone else, please accept my apology.
Re:As I said in a previous post... (Score:5, Insightful)
Re:Turn your SQL server off? (Score:5, Insightful)
No, it's a very reasonable one. Yes, you still need to patch, use non-blank SA passwords and the other things you suggest, but if you have an SQL server (any SQL server) directly visible to the Internet then you are either a fscking moron or have a very abnormal circumstance. A database server is a backend server, and should be completely hidden from the Internet by not one but two layers of firewalls.
Basically, in this day and age, your setup from the Internet in to your internal LAN, should be (as a minimum):
Internet router(s) => Firewall(s) => Web servers (HTTP, mail relays, proxies, VPN termination, etc.) => Firewall(s) => backend servers (SQL, internal mail etc..) => Internal network.
Some of these networks can quite easily be different ports on the same physical firewall, but I'm limited by ASCII. Alternatively, if you have no backend servers, that segment can obviously be omitted altogether.
Firewall rulesets can, and should, apply to outbound as well as inbound traffic and allowing traffic to flow cleanly accross multiple firewalls should be limited as much as possible. At a pinch, you could put your backend servers (if any) directly on the internal LAN, and get by with a single, three port firewall, but this should be the absolute minimum setup if you are hosting connections from the Internet. Sticking a two port firewall between your network and the Internet is simply not good enough anymore.
With resonable DMZ capable firewalls available for less than $500, either as a dedicated box, or old PC running the open source apps of your choice, there is no fiscal reason for even the smallest of companies not to be secure. As ever, the real reason is lack of a clue when it comes to matters of security.
Re:As I said in a previous post... (Score:5, Insightful)
That's what VPNs are for, my friend.
Re:wow yeah! (Score:5, Insightful)
AND verisign will be down for certain hours while
Re:wow yeah! (Score:3, Insightful)
Comment removed (Score:3, Insightful)
Re:Turn your SQL server off? (Score:4, Insightful)
Maybe because bind was built with the Internet in mind. Besides, who in their right mind (I know its redundant), would expose a database server to the Internet, whether that be Oracle, MySQL, PostgreSQL, MSSQL or anything of this nature. It should be hidden completely behind an application layer, preferrably behind a firewall.
Remember to all: This isn't about bashing Micro$oft per se, but rather bashing sysadmins who expose a database out on the net.
Re:Such floods can be easily stopped. (Score:3, Insightful)
I agree. However I also suggest that packets streaming into any port under a gaussian bell curve probability and/or a poisson distribution also be filtered out. I heard that the newest version of the linux kernel has mechanisms for thermodynamically analyzing all packets for signs of randomness. As all computer scientists and mathematicians know, humans are not random and it is therefore unlikely that packets sent from a client will arrive at any given server randomly. Richard Stallman in his PhD thesis ``The Statistical Thermodynamics of Software Evolution'' says as much. Please read the paper for details.
Sorry, I don't have the URL. I'm not a karma whore.
Re:Turn your SQL server off? (Score:2, Insightful)
Re:The Fix? (Score:3, Insightful)
For free.
Asshead.
Re:wow yeah! (Score:1, Insightful)
No, by not installing SP2 which has been out for yonks, you assisted in bringing down the net. You should have installed it when the advisories came out. An IT policy of reaction rather than pre-action where I work would get me the sack.
By the way, SP3 is out, I suggest you install it before you have to hike into work on a Saturday morning this June
Re:Whoever... (Score:5, Insightful)
V P N
There is NO excuse for leaving BACKEND services like DBs, appservers, or whatever else visible on the public net. NONE WHATSOEVER. I work on a major website with multiple different data servers and backend applications, all distributed (and load balanced) over 4 physical sites on 2 continents. We use private circuits to handle the inter-site traffic, you could use VPN just as well. But everything vulnerable is buried from the internet behind several layers of firewall. Anything else is sheer lunacy.
Crappy admins bring this kind of attack on themselves, and alas, on the rest of us too.
PostgreSQL keeps .org up /MS-SQL brings down net (Score:3, Insightful)
This will continue (Score:5, Insightful)
Re:First hand report (Score:3, Insightful)
Comment removed (Score:3, Insightful)
Re:Terrorism, must be (Score:1, Insightful)
While there are some dumb admins (Score:3, Insightful)
Comment removed (Score:3, Insightful)
Re:wow yeah! (Score:3, Insightful)
Re:PostgreSQL keeps .org up /MS-SQL brings down ne (Score:3, Insightful)
Re:As I said in a previous post... (Score:5, Insightful)
This adds a third layer of security, in addition to the 'secure firewall' and the 'secure desktop'. If, god forbid, someone gets through your firewall, you'll at least know it.
And I'm talking about logging outgoing traffic, also. After all, if your firewall is set up correctly you can't have any random incoming traffic...but you'll have lots of outgoing. They have NIDS to detect suspicious traffic, or you can just get a huge dump and start filtering out things you know are okay.
And it's about the only way you'll ever catch that some idiot is running an ICQ from three years ago with a known buffer overflow or something stupid. Neither firewalls nor updated desktop machines can protect you from your own users, only log files of network traffic can do that.
Re:As I said in a previous post... (Score:2, Insightful)
The problem with ACLs on most Cisco gear is where it gets processed. On all but the most recent (and very expensive) hardware requires all the packets to pass through the RSP or NPE if an access list is applied. I forget what the conditions are for ACLs on a 75xx VIP -- everytime I've been forced to filter traffic it's been process switched through the RSP (it isn't designed to move packets -- it's designed to manage routing) If you happen to have a 7400/7600/NSE, then it's a different story; most of the things needed to filter IP traffic are PXF accelerated.
The next time someone steps up to say "let's just filter..." cut them off at the word filter. Routers are routers; firewalls are firewalls. Routers are designed to move packets (quickly), not block them. Firewalls are designed to block packets, not move them. Switches move millions of packets per second. Routers move hundreds of thousands of packets per second. Firewalls move around 1000 packets per second.
Re:Who's fault? (Score:2, Insightful)
Will PostgreSQL make you smart (Score:3, Insightful)
Re:wow yeah! (Score:3, Insightful)
With a good inital security setup and vigilant upkeep system compramises can be basically eliminated. There is always a possability the a bug will slip through and not get patched quick enough, but generally you can stop 99% of problems by securing the system properly and the other 1% through daily patch monitoring.
Frankly, I consider this the job of a sysadmin and think you are remiss in your duties if you don't do it.
Re:As I said in a previous post... (Score:5, Insightful)
You put your webserver on a DMZ, and let it (and only it) talk to the database server through the firewall. Any 2-tier client-server app should be going through a VPN or other secure tunnel.
The only way to do security is to have multiple layers, and to ruthlessly apply the priciple of least privilidge (you get only those permissions you ABSOLOUTELY need and nothing more).
Re:As I said in a previous post... (Score:1, Insightful)
Re:Who did this I wonder????? (Score:5, Insightful)
My "oh crap,no internet" communications plans are a heap-o shortwaves and scanners. Better than nuthin. I know all the commercial am and fm and tv stations will all get taken over by the fema boxes, and start spewing dotgov propaganda (moreso than normal), so I'd be more monitoring some more "unregulated" sources.
Don't think MS is to blame? Read this: (Score:5, Insightful)
The bad assumption people are making here is that there's "no reason to break this rule." Well, unfortunately, this is just not so.
In my case, a project involved upsizing a client's access database, and then transferring it from my dev machine to an ISP's SQL Server instance. The client has a dynamic IP address, and they would never even consider the cost of using a VPN. My SQL Server ports were open for only 3 weeks, during the transition period, and would have been shut down next week.
I kept up on service packs (I was up to SP2), and had installed every SQL Server security patch I could find. I had a non-guessable sa password. I got it anyway.
So why is that? I'm not sure. But I have some observations about the manner in which you're supposed to keep SQL Server (and other MS applications for that matter) current which bear seriously on the issue:
Anywhere? I can't find it today. Maybe it exists and I just didn't notice it. That would be atrocious site design. Or maybe a simple, centralized "MS SQL Server 2000 Security Page" with ordered patch list and instructions doesn't even exist. That's just atrocious.
All I can find is top-level references to service packs and an unqualified link to an all-microsoft download search page. When you select SQL Server 2000 in it, you get everything, not in order, patches thrown together with samples, evaluation downloads, etc.
And I'm supposed to check here... every week? Sounds sensible on the surface, but if they really wanted to prevent trouble:
IT'S SO BLOODY SIMPLE. Yet they didn't bother.
Compare this to redhat, where there's one tool, up2date, and it works for everything. And you are trivially notified by email when there's an update.
At any rate, we can at least tell people a convenient fix - go install SQL Server 2000 SP3.
What's the bottom line? I had a reason to have the port open. And I had a not-for-nothing false sense of security that I was protected against this vulnerability. And most of all, if this was RedHat (for instance) I would never have had this problem - because I would have been notified the moment the patch was available, and would have installed it in a heartbeat, through their single, consistent, easy-to-use interface; and so would tens of thousands of others.
Re:First hand report (Score:5, Insightful)
The patch does not affect routers stupid. Just because his routers are all lit up with massive amounts of traffic, does not mean that his servers are unpatched!
My link was down for 4 hours from the flooding with everything all lit up, and I'm not even running an SQL server.
Re:Terrorism, must be (Score:5, Insightful)
N.
We shouldn't blame MS... no wait, yes we should. (Score:5, Insightful)
But on second thought, when I look at the serious impact of the worms that have been created for MS products and their vulnerabilities the last few years, the obvious becomes apparent: admins of MS OS's and processes on them are a LOT slower to patch than any of their counterparts (read: stupider). And the thing is, MS knows this, they specifically market to the stupid/lazy admins. They're the "easy" OS, they sell their products by telling people that you just install them and never worry about them again. I've taken too many MS courses (I am an MSCE and MSCDBA if they haven't expired on me, but I couldn't care less) and not once was patching the operating systems or server processes ever mentioned during all those courses, which is amazing to me.
And hey, to each their own I guess... apparently there aren't enough intelligent or well read admins around so there is a demand for these products and this approach. But if that's the case, then I think it has to be said that MS has a greater responsibility to create products free from exploits than anyone else, if they're marketing and teaching the idea that you don't need to patch.
It's by creating that laissez faire attitude towards administration that MS is directly responsible for the proliferation of these worms.
my naked-to-the-net sqlserver2000 box is aok (Score:2, Insightful)
i run a solitary box at a colo with win2000 advanced server and sql server 2000 on it (not all of us are technical or engrossed enough to deal with linux/ mysql and not all of us have enough $ to have two boxen).
when i installed sql server, sql server has a server network utility that allows you to control which protocols sql server uses. again, i am not that technical, but without visiting any SANS or other security site, or reviewing any server hardening techniques, or patching anything, it was pretty damn obvious to me to disable the tcp/ip protocol for sql server 2000. it really doesn't take much technical expertise to understand the need for this.
anyone screaming "apply your damn patches" also doesn't consider another simple statement they should be screaming: "familiarize yourself with the BASICS of your box/ the internet before you run a web server and/ or database."
Re:As I said in a previous post... (Score:3, Insightful)
This is a bad analogy. A better analogy is this:
Firewalls promote an all-or-nothing way of thinking that I routinely encounter at work. Firewalls only mitigate the risk of running insecure services, but the false assurances of perimeter security they offer frequently lead to a careless internal security posture, vulnerable both to insider attack and firewall failure/misconfiguration.
Re:Who's fault? (Score:3, Insightful)
The problem is that with MS, there are two levels of fixes, hotfixes and service packs. hotfixes could be anything from a slight cosmetic bug that isn't worth the time to worry about in a professional environment, to a critical vulnerability. There really isn't a huge sense of urgency at the word 'hotfix'. They really need a separate category of 'critically needed patch' for stuff that can cause problems of this scale if left unpatched.
Re:my naked-to-the-net sqlserver2000 box is aok (Score:4, Insightful)
You, and the rest of you non-engrossed, non-technical people who don't have $15.00 to put a NIC in a 486 firewall that you can pick up at the dump, but plenty of money to shell out system upgrades every few years... You're causing this problem. You, personally.
First, by buying and deployng a server OS by an untrustworthy organization, followed by not even complying with thier reccomendations of protecting, securing, and updating that server.
Then, by saying "Whew! Dodged that bullet" after you CLICKED ON A CHECK BOX is not quite the same as.. oh.. patching it, securing it behind a firewall and testing it for packet traffic... THESE are the "basics" of your box and the internet. Not what your manual, the context sensitive help, or what MS' Marketing department tell you.
Was that non-technical enough for you? Stop being smug, and stop being part of the problem.
Re:waiting for patches is hardly good security pol (Score:5, Insightful)
Sounds like a damn good advice to me. Why the hell should either of those be exclusive?
It's very BAD advice! What happens when you blindly apply the patch and find out your mission critical app won't run anymore? A little QA testing would show you that on a test system instead of your live servers. If a firewall rule can protect you, use that, then QA the patch and apply if it is safe.
Consider that sometimes, the 'security patch' just disables a feature that 'nobody uses anyway' (except for your mission critical app, that is). Other times, it doesn't fix the hole, it just changes it's shape a little. In that case, you go from a hole you know about and can guard against at the firewall to one you don't know exists that has less information about it available.
It's not purely a dig at MS (though their track record for quality patches is spotty), any sudden change to widely deployed software runs the risk of causing a problem for sombody's configuration.Re:As I said in a previous post... (Score:2, Insightful)
Seriously. I would guess that some of the most succesful marketing strategies are based on this fact.
(otoh, IOS isn't always the most stable piece of software, but I tend to run LD/ED releases because I need the features, roughly equivalent to beta versions. A software failure is also much less of a catastrophe than a hardware failure--it's much faster to restart a router than to wait for hardware.)
While a Linux/BSD box running iptables/ipf is dirt cheap, it's not hard to imagine why it might not sit well with the suits in larger companies. I would wager that PC hardware isn't quite as reliable, either--especially since nearly all hardware firewalls/routers use flash as the primary means of storage rather than a hard drive.
Re:ATM's out... (Score:2, Insightful)
Go easy on the sysadmins (Score:2, Insightful)
Re:As I said in a previous post... (Score:3, Insightful)
In general, middleware, firewalls, proxies, and VPNs add to overall security. They do this by pushing the most important piece of the overall system, the database and data as far away from the public as possible.
In many cases though, a 3-tier or similar configuration adds more needless complexity which creates more problems then it solves. I recently did some work at a datacenter that provides directory services for a large (500,000 user, 350,000 host) enterprise. This datacenter literally has two racks of PIX firewalls providing access to one rack of LDAP servers!
Whether a "hacker" or an admin makeing a mistake takes down access to a web or middleware server which denies access to data, the application is still down.
There is no general rule to "secure" services -- you need to make an intelligent decision based on your budget, staffing and application. Multi-layered, locked down configuration cause plenty of grief to regular users and often pose no challenge to intruders, who exploit bugs to get full access to everything anyway.
In plenty of cases a single, secureed server providing all services is a simpler and affordable solution.
Re:!!!ATTENTION MS ADMINS!!! (Score:2, Insightful)
Actually, we already did this bit on Slashdot. It was back when MS released SP3 for Win2k which basically did just that (installed an automated patch collection/installation system, placed it in the start menu and system tray). And, IIRC, back then the consensus was that it's A Bad Thing(tm).
Anyways, it's there if you want it. Ignorance is no excuse.
Re:Who did this I wonder????? (Score:2, Insightful)
Well if you took the time and installed the patches (which have been out for some time, also included in SP3, BTW), you wouldn't have been a part of the problem, you would have been a part of the solution.
Leave it to Mircosoft to crash the internet.
Leave it to the lazy and incompetent, I say...