Re: network request not supported - source virus??

Hi "sameproblem"!

You have a good point there.
Here's my strategy and thoughts on the matter:

In principle, I agree with the rule: "if it isn't broken, don't fix
it". But I believe that you have to differentiate between critical
security updates from Microsoft, and all other updates.

The special case with security vulnerabilities is that your server
can have been "broken" , i.e. vulnerable for a long time, without
giving you any problems. But as soon as a particular vulnerability
is published, you can count on it that there will be a lot of
attempts to exploit it. So *not* applying a security update will
leave you more vulnerable than you were before.

Here's what I do in practice:

* non-critical, non-security updates: I read the documentation, and
only download them for testing if they seem to fix a problem which
we actually experience, or if they offer important new
functionality that we need (this happens *very* seldom; off the top
of my head: I think that I installed 2 non-critical updates during
the last year, 1 fixed a problem in our backup software, one fixed
a problem in Citrix).
* critical security updates: I download them (they usually come
twice a month as you say), read all available documentation to see
if I can spot any potential problems, and then I install them on a
test server, which is an exact copy of one of our production
servers. Then I spend between 1 - 4 hours testing, first as
Administrator, then as a normal user. If all seems to be as it
should, then we test with a limited amount of real users, a couple
of days to one week. Then I check the newsgroups to see if there
are any reports about problems with this update. If there aren't
any, we apply the update to all production servers.
This approach has worked so far (touch wood :-)

Crucial here is a test server, which is an exact copy of your
production server(s). The time involved for testing security
updates is really not so much. And the alternative is running the
risk of a security exploit causing a compromized system, possible
down-time, loss of data, etc. In my job, that's *not* an option.
_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
http://hem.fyristorg.com/vera/IT
___ please respond in newsgroup, NOT by private email ___

=?Utf-8?B?c2FtZSBwcm9ibGVt?=
<sameproblem@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote on 09 jun 2005 in
microsoft.public.win2000.termserv.apps:

> Vera Noest,
>
> I wanted to thank you for your reply.
>
> I am a little concerned with one part of your suggestion and
> feel itâ??s a dammed if you do and dammed if you don't solution.
> Not a good feeling for a production environment at all.
>
> If a server is working perfect in a production environment would
> you update the software if there were no problemsâ?¦of course
> NOTâ?¦and especially NOT in a production environment without
> testing first. Why create possible problems on a system that is
> working. Therefore, why should I apply Windows Updates blindly
> or even have to on a server that is working perfectlyâ?¦.If I
> donâ??t I may get a virus and if I do my software may stop
> working because of some little conflict that the update
> causedâ?¦something that may not show up right away even if I was
> able to test. Iâ??m sure thatâ??s why most people donâ??t
> update their windowsâ?¦.Iâ??ve seen it happen where a windows
> update stop a production server because some part of the
> software didnâ??t like the update and decided to start
> generating problemsâ?¦of course the vendor had no long term
> solution and suggest for the short term to rollback the windows
> update. With some apps sometimes itâ??s best to leave a server
> as is.
>
> Also, if one had many window servers running and tested every
> windows update before applying to live server that would give
> that person a full time job for live since Microsoft seems to
> release patches on average of two per month....
>
> Anyway, just wanted to post my two cents worth.
>
> Thanks again.
>
>
> "Vera Noest [MVP]" wrote:
>
>> OK, good that you investigated how the infection started.
>>
>> Trend Micro has this information about the virus:
>> http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?
>> VName=WORM_RBOT.BJF
>>
>> Aliases: Malware.b, W32.Spybot.Worm, Win32.Rbot.gen*2
>> This worm arrives through network shares. Upon execution, it
>> drops a copy of itself in the Windows system folder. It
>> modifies the registry to ensure its automatic execution at
>> every Windows start...
>>
>> It turns out that the virus is new, but it exploits old, known
>> vulnerabilities. Each of them has been covered in a Microsoft
>> critical security update.
>>
>> There's really not one single measure which prevents problems
>> like this, it's more a continuous effort in several fields.
>>
>> I've noticed that the four or five similar reports all
>> mentioned that they hadn't applied Windows critical security
>> updates. That's definitively something to see to, and it would
>> have prevented the problem.
>>
>> Another line of defence is to work with minimal user rights.
>> I do all of my normal work under a normal user account, and
>> have made sure that normal users cannot modify crucial registry
>> keys like the
>> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ru
>> n] and related registry keys.
>>
>> If I need to do something that requires Administrator
>> permissions, I am very careful to *only* do what I need to do,
>> and never start Internet Explorer, read email, or run similar
>> programs. Once you start surfing from a server with
>> Administrative rights, you can unknowingly infect your server
>> with this kind of malicious programs.
>>
>> _________________________________________________________
>> Vera Noest
>> MCSE, CCEA, Microsoft MVP - Terminal Server
>> http://hem.fyristorg.com/vera/IT
>> ___ please respond in newsgroup, NOT by private email ___
>>
>> =?Utf-8?B?c2FtZSBwcm9ibGVt?=
>> <sameproblem@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote on 06 jun 2005 in
>> microsoft.public.win2000.termserv.apps:
>>
>> > Vera Noest,
>> >
>> > You're right...crossing my fingers is not an adequate
>> > response for a production environment. The crossing my
>> > fingers part was that I removed the current virus
>> > successfully since Norton and MacAfee could not detect it.
>> >
>> > After looking at the file on each server I noticed it
>> > attached my one web server on 6/1/05 at 8:16pm EST and then
>> > spread from there. I'm the only one with access so I'm
>> > trying to figure out how the virus was able to attach since I
>> > wasn't accessing the server that day. I only have 4 ports
>> > open so I thought I was okay...guess not.
>> >
>> > Do you have any suggestion on how to protect myself from
>> > future attachs?
>> >
>> > Thanks
>> >
>> > "Vera Noest [MVP]" wrote:
>> >
>> >> FWIW:
>> >> "Crossing your fingers" doesn't seem an adequate response in
>> >> a situation where it's perfectly possible that you still
>> >> have an open backdoor in a production environment.
>> >>
>> >> The McAfee forum shows that the virus is detected by 9 of
>> >> the listed antivirus engines and was missed by 10 of them.
>> >> Unfortunately for you, McAfee missed it.
>> >>
>> >> Have you at all investigated where the infection started?
>> >> How about your workstations? Why do you believe that you are
>> >> *not* going to be re-infected?
>> >>
>> >> And since this infection usually spreads using KaZaA file
>> >> sharing and mIRC: either your Administrator is playing
>> >> around with an Administrative account on your production
>> >> servers, or your users are file sharing and chatting during
>> >> work hours AND they have way too high permissions, since the
>> >> original infection was able to modify the registry in places
>> >> where no normal user should go!
>> >>
>> >> _________________________________________________________
>> >> Vera Noest
>> >> MCSE, CCEA, Microsoft MVP - Terminal Server
>> >> http://hem.fyristorg.com/vera/IT
>> >> ___ please respond in newsgroup, NOT by private email ___
>> >>
>> >> =?Utf-8?B?c2FtZSBwcm9ibGVt?=
>> >> <sameproblem@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote on 05 jun 2005
>> >> in microsoft.public.win2000.termserv.apps:
>> >>
>> >> > I posted this problem also on Mcafee and it does seem like
>> >> > a new virus
>> >> > http://forums.mcafeehelp.com/viewtopic.php?p=240094#240094
>> >> > I've also updated all critical win 2000 server updates and
>> >> > at least for the past 12 hours the server has been running
>> >> > like normal. I'm crossing my fingers.
>> >> >
>> >> > Thanks for your help.
>> >> >
>> >> > "Patrick Rouse" wrote:
>> >> >
>> >> >> These are some that I like:
>> >> >>
>> >> >> http://housecall.trendmicro.com
>> >> >> http://www.spywareinfo.com/xscan.php
>> >> >> Spybot Search & Destroy
>> >> >>
>> >> >> --
>> >> >> Patrick Rouse
>> >> >> Microsoft MVP - Terminal Server
>> >> >> http://www.workthin.com
>> >> >>
>> >> >>
>> >> >> "Vera Noest [MVP]" wrote:
>> >> >>
>> >> >> > Sounds like one of those SpyBot backdoors to me.
>> >> >> > It probably loads in
>> >> >> > [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVe
>> >> >> > rsi on\ Run] and related registry keys, which explains
>> >> >> > why you can log in for a minute or 2 after rebooting.
>> >> >> > Once the service is started, you're locked out again.
>> >> >> >
>> >> >> > Why don't you run another anti-virus program or an
>> >> >> > online virus check?
>> >> >> >
>> >> >> > ________________________________________________________
>> >> >> > _ Vera Noest
>> >> >> > MCSE, CCEA, Microsoft MVP - Terminal Server
>> >> >> > http://hem.fyristorg.com/vera/IT
>> >> >> > ___ please respond in newsgroup, NOT by private email
>> >> >> > ___
>> >> >> >
>> >> >> > =?Utf-8?B?c2FtZSBwcm9ibGVt?=
>> >> >> > <sameproblem@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote on 04 jun
>> >> >> > 2005 in microsoft.public.win2000.termserv.apps:
>> >> >> >
>> >> >> > > On 6/2/05 all of my licensed Windows 2000 Servers
>> >> >> > > w/SP4 would not allow anyone to login via remote or
>> >> >> > > at the console. Then have been running for 5+ months
>> >> >> > > without change. If I were to reset the server I could
>> >> >> > > login within approx 2 minutes but after that I would
>> >> >> > > be locked out. This and a few other forums have
>> >> >> > > others with the same problem starting on 6/2/05.
>> >> >> > > Therefore, I felt/feel this is either a Microsoft bug
>> >> >> > > or a virus.
>> >> >> > >
>> >> >> > > In review of my system32 folder I found a file that
>> >> >> > > looked like it did not belong 'msupdtm.exe' since a
>> >> >> > > clean install I have of windows 2000 server w/sp4 did
>> >> >> > > not have the file. However, I ran Managed McAfee and
>> >> >> > > no viruses were found. Has anyone found a solution to
>> >> >> > > the BIG PROBLEM yet??
>> >> >> > >
>> >> >> > > HELP!!!
.

Relevant Pages

  • Re: The Active Directory is rebuilding indices, please wait
    ... Go in eventvwr - start>run>eventvwr and check the Directory Services event ... Windows Server MVP - Directory Services ... I installed a couple of windows security updates last week but only ...
    (microsoft.public.windows.server.active_directory)
  • Re: Trust Issues
    ... about to put my production environment at risk if I can recreate so ... I could load it on VirtualPC or Virtual Server too. ... >>able to sccuessfullly add win2k3 domain account to the win2k domain? ... >>validate this trust; or the trust has not been succussfully established at ...
    (microsoft.public.windows.server.general)
  • Unable to visit sites I normaly visit.
    ... I use windows xp. ... internet explorer browser. ... The two sites share the same server. ... One of the recent security updates I read said something to the effect that ...
    (microsoft.public.windowsupdate)
  • Re: Server Configuration Help
    ... Upgrading to normal windows domain is not that simple and you can not use ADMT for it. ... Server 1: Windows Server 2003 Enterprise with Domain Controller, ... configuration, and ultimately a production environment. ...
    (microsoft.public.windows.server.setup)
  • Re: network request not supported - source virus??
    ... If a server is working perfect in a production environment would you update ... may get a virus and if I do my software may stop working because of some ... term solution and suggest for the short term to rollback the windows update. ...
    (microsoft.public.win2000.termserv.apps)