the web comes to a grinding halt
Discussion
this might be of interest to you.
Dear Alan
Names.co Internet would like to reassure you that neither the servers nor the
network on which your website is hosted have been directly affected by the
denial of service attack experienced across much of the internet this weekend.
All systems have remained fully operational throughout this period, but our
firewalls are still detecting unusually high inbound traffic from affected
servers on other networks. For this reason, you may experience slower
connections than usual for the next couple of days until all affected ISPs have
completed the modifications neccessary to secure their systems.
The attack was caused by the "Slammer" worm, a virus that targets and infects
Microsoft SQL Server. Since all of our services are hosted on a Unix platform,
we are not reliant on any Microsoft software, and are therefore impervious to
this particular problem.
Our network monitoring systems first alerted us to the issue early on Saturday
morning, and an announcement was quickly placed on our technical support
hotline. You can call this number at any time for live system updates on 0870
162 4950.
Background information
The denial of service attacks stem from an old vulnerability in Microsoft SQL
Server and have vastly increased traffic on the Internet as a whole. For a
period, 5 of the 13 root nameservers were effectively disabled.
The problem is caused by infected hosts transmitting many UDP packets to port
1434 of other random hosts, which in turn generate new traffic. Many ISPs both
in Europe and worldwide have been affected.
We have been attempting to distinguish 'true' and 'spoof' outages since early on
Saturday morning. However, as the problem is widespread on the Internet, some
brief and/or spurious alerts have been generated to clients. These were due to
our monitoring nodes not being able to access some client sites, as would be the
experience of many Internet users at the time. Alerts may therefore have been
received at a time when Webservers and certain ISPs appeared to be fully
functional.
For detailed information about the SQL Server vulnerability, please consult the
security advisory at www.nextgenss.com/advisories/mssql-udp.txt
Kind regards
Technical Support
Names.co Internet plc
Dear Alan
Names.co Internet would like to reassure you that neither the servers nor the
network on which your website is hosted have been directly affected by the
denial of service attack experienced across much of the internet this weekend.
All systems have remained fully operational throughout this period, but our
firewalls are still detecting unusually high inbound traffic from affected
servers on other networks. For this reason, you may experience slower
connections than usual for the next couple of days until all affected ISPs have
completed the modifications neccessary to secure their systems.
The attack was caused by the "Slammer" worm, a virus that targets and infects
Microsoft SQL Server. Since all of our services are hosted on a Unix platform,
we are not reliant on any Microsoft software, and are therefore impervious to
this particular problem.
Our network monitoring systems first alerted us to the issue early on Saturday
morning, and an announcement was quickly placed on our technical support
hotline. You can call this number at any time for live system updates on 0870
162 4950.
Background information
The denial of service attacks stem from an old vulnerability in Microsoft SQL
Server and have vastly increased traffic on the Internet as a whole. For a
period, 5 of the 13 root nameservers were effectively disabled.
The problem is caused by infected hosts transmitting many UDP packets to port
1434 of other random hosts, which in turn generate new traffic. Many ISPs both
in Europe and worldwide have been affected.
We have been attempting to distinguish 'true' and 'spoof' outages since early on
Saturday morning. However, as the problem is widespread on the Internet, some
brief and/or spurious alerts have been generated to clients. These were due to
our monitoring nodes not being able to access some client sites, as would be the
experience of many Internet users at the time. Alerts may therefore have been
received at a time when Webservers and certain ISPs appeared to be fully
functional.
For detailed information about the SQL Server vulnerability, please consult the
security advisory at www.nextgenss.com/advisories/mssql-udp.txt
Kind regards
Technical Support
Names.co Internet plc
alan_driver said: For a
period, 5 of the 13 root nameservers were effectively disabled.
I may be wrong here - and put me right if I am - but I'm not sure why this virus would affect root nameservers - as I understand it they are all unix boxes running BIND, the virus propagates via random ip addresses - this is how I got infected (yup too slow on the updates) when I'm on dhcp - so would not even need to a domain lookup and therefore would have no need to reference a nameserver. Or does anyone know different?
Cheers
Paul
Edited to say - sorry Alan it looks like I'm quoting you when in fact I'm quoting you quoting someone else, not sure how to format it better.
>> Edited by gopher on Monday 27th January 20:11
gopher said:
alan_driver said: For a
period, 5 of the 13 root nameservers were effectively disabled.
I may be wrong here - and put me right if I am - but I'm not sure why this virus would affect root nameservers - as I understand it they are all unix boxes running BIND, the virus propagates via random ip addresses
The problem is if the root nameservers are hosted on the end of a link on which there's also an MS SQL server.
The worm will completely saturate networks attached to an infected SQL server... there have been reports of SQL servers kicking out a sustained 20Mbit/s of traffic. That's quite a bit, and I'm sure that a bigger fatter server, perhaps a server farm, hosted on Gigabit ethernet will manage considerably more. A friend of mine works somewhere with just that arrangement...
Anyway, the real questions are:-
a) When will M$ stop selling software that has this level of buggerdness built in? And where new buggerdly features get discovered at such an alarmingly regular bleedin' rate.
b) Why-o-why-o-why have people got unprotected M$ SQL servers accessible to the Internet? I mean, just *how* many years have us Internet Security types been banging on and on and on about bloody firewalls? Waste of breath, clearly.
Marshy said:
b) Why-o-why-o-why have people got unprotected M$ SQL servers accessible to the Internet? I mean, just *how* many years have us Internet Security types been banging on and on and on about bloody firewalls? Waste of breath, clearly.
Firewalls may not be the answer in this case, a customer of ours has become infected even though they are behind a Firewall, after all if you need it to be accesible from the Net then you have no choice. The answer lies in applying the relevant patch as soon as (a)it is available (b)you have tested it. A patch to avoid this vulnerability has been available for around 6 months, if you get infected then you only have yourselves (or your IT dept)to blame!!!
tuffer said:
Firewalls may not be the answer in this case, a customer of ours has become infected even though they are behind a Firewall, after all if you need it to be accesible from the Net then you have no choice. The answer lies in applying the relevant patch as soon as (a)it is available (b)you have tested it. A patch to avoid this vulnerability has been available for around 6 months, if you get infected then you only have yourselves (or your IT dept)to blame!!!
Indeed, although there's usually a way to ensure that even if something like an SQL server has to be *directly* accessible to customers on the 'net, then it's only open to them (say, via authentication at a firewall) rather than to all and sundry.
And if there's no other way to do it, then the customer is told in large letters, with a disclaimer attached, that if they don't patch on time, every time, then they're going to get spanked.
Oh, look...
My 2p worth...
All this fuss about MS products being insecure - I don't necessarily disagree but one point of view is that perhaps if hackers, etc tried to write worms, etc for MySQL, Oracle, etc then there would be problems in those products too. It's the fact that MS products are everywhere, freely available and there's generally an anti-MS campaign going on.
Also, because of the nature of MS products you get people who are not necessarily software experts so don't necessarily have the skills to apply fixes that perhaps an experienced Apache expert might.
Playing devils advocate...
Dan
All this fuss about MS products being insecure - I don't necessarily disagree but one point of view is that perhaps if hackers, etc tried to write worms, etc for MySQL, Oracle, etc then there would be problems in those products too. It's the fact that MS products are everywhere, freely available and there's generally an anti-MS campaign going on.
Also, because of the nature of MS products you get people who are not necessarily software experts so don't necessarily have the skills to apply fixes that perhaps an experienced Apache expert might.
Playing devils advocate...
Dan
There's a counter argument that says that open source alternatives are generally smaller, simpler, and subject to extensive peer-review, in theory meaning that the incidences of these sorts of bugs should be lower.
The "all things to all men, ever" school of software design leads to such enormous code-bloat and creeping-featurism that there are inevitably going to be more bugs, and therefore, more security flaws.
Regardless, I still think it's a daft plan to make an SQL server (whatever flavour) accessible to the *whole* internet. Hey ho.
The "all things to all men, ever" school of software design leads to such enormous code-bloat and creeping-featurism that there are inevitably going to be more bugs, and therefore, more security flaws.
Regardless, I still think it's a daft plan to make an SQL server (whatever flavour) accessible to the *whole* internet. Hey ho.
agree with you both .. msft code is heowge, bit buggy, but gets things into production very quickly .. and it get's attacked a lot ... pays your money and takes your choice. Doesn't make you a bad person.
I too cannot imagine why anyone would ever want/need to point a raw database at the outside world. Is that really what happened?
I too cannot imagine why anyone would ever want/need to point a raw database at the outside world. Is that really what happened?
this is the thing that amazes me.. you don't need SQL ports open when it's the top tier of a web-based application and like Marshy said, stick a firewall in and your cup runneth over with authentication methods, basic or complex depending on the sensitivity of data.
ATG said: I too cannot imagine why anyone would ever want/need to point a raw database at the outside world. Is that really what happened?
I think the problem is that firewalls are seldom understood, even by a lot of the people who are required to configure them (because fw specialists are expensive, eh Marshy?
). The result is that they're configured by trial and error, and things that are opened up practically at random when trying to get an application to work are rarely closed again even by process of elimination. Makes you wonder how many netbios & NFS ports are open. And of course there's the cretinous MS software
Actually I think Danhf made a very good point.
If I remember rightly, the core component of MS SQL server is also installed on workstations as the 'MS Data Engine' as a replacement for Jet. This means that plenty of people with workstation-type OS installs would have SQL server lurking somewhere as a service.
The 'Data Engine' version is similarly vulnerable to the UDP exploit. Obviously people running proper servers (a) shouldn't be exposing their SQL ports to the internet and (b) should be keeping up to date with MS patches.
However a lot of people using 2k Pro or XP Pro on broadband connections may have been unknowingly infected. And it only takes one workstation inside the firewall to get infected, and then the 'protected' servers inside will also.
Like the Code Red worm, I reckon the properly-maintained servers aren't to blame - it's the server-class software hidden in workstation-class OS installs.....
The 'Data Engine' version is similarly vulnerable to the UDP exploit. Obviously people running proper servers (a) shouldn't be exposing their SQL ports to the internet and (b) should be keeping up to date with MS patches.
However a lot of people using 2k Pro or XP Pro on broadband connections may have been unknowingly infected. And it only takes one workstation inside the firewall to get infected, and then the 'protected' servers inside will also.
Like the Code Red worm, I reckon the properly-maintained servers aren't to blame - it's the server-class software hidden in workstation-class OS installs.....
I'm no C/C++/VC++ nor assembler programmer so go on somebody - tell me why buffer overrun protection (i.e. some kind of parsing of an input string) isn't coded by default - and is Microsoft particularly guilty of this or is it a fault across th eindustry?
Also why does such an overrun lead to a complete brakdown of security within the server - or am I simply alluding to the very problem with using the Win32 platform - namely that security and process integrity has to be coded by application (i.e. SQL Server itself) programmers and is not integrated at the very heart of the o/s?
Also why does such an overrun lead to a complete brakdown of security within the server - or am I simply alluding to the very problem with using the Win32 platform - namely that security and process integrity has to be coded by application (i.e. SQL Server itself) programmers and is not integrated at the very heart of the o/s?
CarZee said:this is the thing that amazes me.. you don't need SQL ports open when it's the top tier of a web-based application and like Marshy said, stick a firewall in and your cup runneth over with authentication methods, basic or complex depending on the sensitivity of data.
ATG said: I too cannot imagine why anyone would ever want/need to point a raw database at the outside world. Is that really what happened?
I think the problem is that firewalls are seldom understood, even by a lot of the people who are required to configure them (because fw specialists are expensive, eh Marshy?
And of course there's the cretinous MS software
Actually I think Danhf made a very good point.
Mr Zee, the problem is that in my experience of Microshite based websites, the architects generally stick everything on the same subnet anyway. The use of VLANs and separate subnets for each tier greatly reduced these issues and security breaches.
Since I've moved to proper toys like J2EE and Unix, I've not encountered any of these issues.
Please feel free to shoot me down (especially the MS huggers)
Steve
Gassing Station | General Gassing [Archive] | Top of Page | What's New | My Stuff