| ActiveMac | Anonymous | Create a User | Reviews | News | Forums | Advertise |
|
|
|
User Controls |
|
New User |
|
Login |
|
Edit/View My Profile |
|
|
|
|
|
|
|
ActiveMac |
|
Articles |
|
Forums |
|
Links |
|
News |
|
News Search |
|
Reviews |
|
|
|
|
|
|
|
News Centers |
|
Windows/Microsoft |
|
DVD |
|
ActiveHardware |
|
Xbox |
|
MaINTosh |
|
News Search |
|
|
|
|
|
|
|
ANet Chats |
|
The Lobby |
|
Special Events Room |
|
Developer's Lounge |
|
XBox Chat |
|
|
|
|
|
|
|
FAQ's |
|
Windows 98/98 SE |
|
Windows 2000 |
|
Windows Me |
|
Windows "Whistler" XP |
|
Windows CE |
|
Internet Explorer 6 |
|
Internet Explorer 5 |
|
Xbox |
|
DirectX |
|
DVD's |
|
|
|
|
|
|
|
TopTechTips |
|
Registry Tips |
|
Windows 95/98 |
|
Windows 2000 |
|
Internet Explorer 4 |
|
Internet Explorer 5 |
|
Windows NT Tips |
|
Program Tips |
|
Easter Eggs |
|
Hardware |
|
DVD |
|
|
|
|
|
|
|
Latest Reviews |
|
Applications |
|
Microsoft Windows XP Professional |
|
Norton SystemWorks 2002 |
|
|
|
Hardware |
|
Intel Personal Audio Player 3000 |
|
Microsoft Wireless IntelliMouse Explorer |
|
|
|
|
|
|
|
Site News/Info |
|
About This Site |
|
Affiliates |
|
ANet Forums |
|
Contact Us |
|
Default Home Page |
|
Link To Us |
|
Links |
|
Member Pages |
|
Site Search |
|
Awards |
|
|
|
|
|
|
|
Credits |
 |
Laborious Updates Leave SQL Databases Unpatched | |
|
||
| Time: 12:12 EST/17:12 GMT | News Source: eWeek | Posted By: Bill Roach | ||
|
The patches that could have stopped last week's attack on Microsoft Corp. database software were so difficult to install or so poorly publicized that some of Microsoft's own database administrators failed to install them. The Redmond, Wash., developer released last July patch MS02-039 to fix a known vulnerability in its SQL Server database and wrapped it into Service Pack 3, which shipped only days before the SQL Slammer worm struck. However, many IT departments did not install the initial patch because installation could not be scripted. | ||
|
Write Comment
Return to News |
Displaying 1 through 25 of 325 Last | Next |
The time now is
3:31:11 PM
ET.
Any comment problems? E-mail us |
| #1 By 3465 (65.222.202.173) at 2/3/2003 12:39:15 PM |
|
point, click, download, extract, copy to directory, done baby!....that was six months ago for admins who research or keep up with updates. yea, baby. This post was edited by kirk26 on Monday, February 03, 2003 at 12:41. |
| #2 By 5444 (67.1.37.38) at 2/3/2003 1:06:09 PM |
|
Point click, Load up VS, VS.net, Office Developer, Office Access with MSDE support, Visual Foxpro with msde support, Visio, Project, and at least 30 other programs that load MSDE some silently others you have to load seperate and know that you are loading MSDE.
Now have you patched or verified that all of those instances are patched on every system in your network. Which btw, VS.net instance of the MSDE couldn't be upgraded with the standard service pack, you had to get a special one fo it. A properly configured Firewall does more to pretect against this attach that makeing sure that every single instance of a sql server was patched. But I know of many where they were hit when a laptop connected outside of the firewall was brought into the firewall enviroment. So while I agree, that the point click download, extract, copy to directory is true, for known instances of SQL Server, which is usually one platform, it is the number of MSDE that can be on individual machines that take care of the done part and probably are biteing most DB admins. Unless the DBA's are also the ones responsible for Loading programs like develepors Tools, or deal with the server software that isn't nec part of the DB server (several antivirus and even firewall using msde as the database for its functionality at the server level. if I were you I would go through every system on the network just to make sure that MSDE isn't running. or use that nice tool they just recently released that will let you do it from the server. el |
| #3 By 5444 (67.1.37.38) at 2/3/2003 5:47:45 PM |
|
ComputerExpert,
I won't argue the point that it should be done. But I will argue, from past exprience that it is stupid to apply patches Blindly, Especially in systems that generate Revenue. NT sp3 or was it 4 would be a prime example. Changes in SP may fix issues that different programs take advantage of and cause them to stop working properly, (this can be true of interally coded items or 3rd party VAR items) that my require a small update after a sp is installed. While 6 months may seem to be a long time, to evaulate and then distribute an Update, I would say it is small on any Network with more than 50 or above systems. especially in system critical upates (which SQL server would be one of those system) Best case scenario is to roll out the patch to a test bed to make sure it doesn't break any of the other assets, then roll it out live. At the enterprise level there is more coded for the situation than the off the shelf issues that occur in Home PC's. There are also more critical in that down time costs money. So there is a trade off to be had. This patch was very critical and the downtime involved could have been prevented. and the patch is now forced to be put on because of a Villian. But it is also a review process of when and how to put patches on. I do agree that a Push service for critical patches should be started. so that System admins can't forget that a patch is needed on the different systems. But if that is going to be true. MS needs to do it internally first as they had as many systmes hit. Also Different groups shouldn't change the underlying platforms so that normal patching doesn't work. (MSDE for vs.net for example couldn't use the normal SP as a matter of fact you couldn't apply sp2 yet alone sp3 or even this critical patch. MSDE should be part of windows update patches and or office patches. as it is a part of office. So what can be done. from this, One, the Patching process for multiple instances of SQLServer (includeing MSDE) should just be a run once deal. I run the upgrade for SP it should check all of the instances report them, and offer to upgrade them, without haveing to write a scrpt for each and every named instance of sql server. I say offer, because of compatability issues a sp may not be an option at that time. until all programs on that instance can be updated. 2. A lock down of the Firewall to prevent access to the sql server database. if the enterprise tools are needed for access, scripting should be at the highest security from outside sources, (the CLR in Yukon will handle that issue) also MS should probably make a remote adminstartion tool for ISP's to use that is safe to expose to the outside world. 3. Companies need to have a Team that works within the IT department and the other managers to better address how Security Upgrades should be installed. Perhaps an Industry wide best practices should be implemented between not only MS and its var partners but those that buy the products, (this is true even in a Unix enviroment and a linux enviroment) so this is something that could be used industry wide. 4. all systems that can leave the corporate firewall should be installed with a software firewall. This would have prevented the Laptops from bringing in the virus when they are connected to the internet externally of the system. While I think the one included in XP is horrible at least if it was enabled on the laptops with MSDE installed it would have prevented this simple worm from getting anywhere. Remember some Admins have their hands tied when Management sees things that are working doing upgrades can be locked down. el This post was edited by eldoen on Monday, February 03, 2003 at 18:00. |
| #4 By 5444 (67.1.37.98) at 2/3/2003 11:55:17 PM |
|
mat,
While I agree that the third party vendors should ensure that their products work with the new patch and or new version, There is time involved. I was on the beta for sp3 on sql server 2000 and on the latest sp for sql server 7, While it is stabel they are still releaseing newer versions so which one do you verify if your software will work. The RC1 or RC2 versions or wait until final. If you make the necessary changes for rc1 or rc2 and somthing in final breaks it. How about the smaller VAR's and other vendors which are not on the beta, or the internally coded programs in some of the larger IT departments. These take time to fix. I can almost assure that the 3rd parties that sell off the shelf stuff will have a patch and update much faster than the interal IT departments. VAR and other vendors that support many customers may have even a slower update schedule for the small business platforms, (for them it just works, why mess around with it until the fix is known) if you have a bomb sp that causes more probablems than it fixes. (sp2 for share point server comes to mind as a recent one, or sp3 or 4 for nt as another one) Even with beta testing and other testing, there is just no way to test for every configuration that exists. If you as a 3rd party vendor recoded for that issue and was caught by the bad side effects of it, it would be time spent in the wrong area. I am not argueing that it shouldn't occur, I do want to point out that 6 months isn't alot of time to test and verify in a mid size company with 100 to 200 employees with 50 to 100 computers and a stripped down IT budget as there are in these days and times. El |
|
Write Comment
Return to News |
Displaying 1 through 25 of 325 Last | Next |
The time now is
3:31:11 PM
ET.
Any comment problems? E-mail us |
