Re: RWW Security was compromised.
From: Therion (therion_at_outlook.com)
Date: 02/01/05
- Next message: Therion: "Re: RWW Security was compromised."
- Previous message: Adam Butler: "sqlservr using lots of memory"
- In reply to: Tony Su: "Re: RWW Security was compromised."
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 31 Jan 2005 22:22:22 -0600
I was beginning to wonder; about being alone that is. :-) I am in the
process of getting this concern to the product team as an additional
hardening routine, but as you say this is for the future. Until then I have
taken the scripting advise for monitoring and have increased the password
strength/policies for all my clients. In addition I am playing with some
syslog stuff on our own network to facilitate better tracing and monitoring
of the various logs.
All in all, as Susan has pointed out the issue can be pushed beyond
probability by using strong enough passwords, which for today I am
comfortable with.
Thanks all for the responses and the chance to hear various opinions. I
will post any information I receive to this thread if I learn any
interesting words from MS.
"Tony Su" <TonySu@discussions.microsoft.com> wrote in message
news:08DA2550-4F69-4633-9B0A-90AD0FBD477B@microsoft.com...
> Therion,
> You are not alone in this concern, and I don't think you'll find too much
> disagreement that this special Admin Account policy will likely need to be
> modified.
>
> But, that's the future.
>
> What we can and should do today seems to be fairly obvious...
>
> - Configure a password to a far higher standard than your usual Domain
> Password Policy.
> - Know that Length of password is the most important single factor in
> determining the effective bit strength of the Password, although other
> factors can contribute.
> - Exceptions exist for all current Password Rules and primarily because
> the
> existing settings Microsoft offers to set Password Policy is too crude and
> simple.
> - The "effective bit strength" and other concepts which relate mainly to
> brute force cracking cannot be ignored but does not address the most
> important threat head on, Dictionary attacks (and variants).
> - Because of "The Administrator" account is subject to special issues, it
> becomes imperative to monitor the number of consecutive password attempt
> failures. Jeff's suggestion about scripting an alert is good. If the
> password
> is <very> strong/random, then you have a bigger window for discovering and
> recognizing serious attacks.
>
> I'd also like to introduce what I believe is the concept of
> "Predictability"
> and educating any person who is responsible for configuring a password.
>
> http://msmvps.com/bradley/archive/2005/01/24/33789.aspx
>
> Also, partly as a result of this incident and some other issues I will be
> doing presentations to a number of local User Groups on my ideas regarding
> the <Practical> use of Passwords and Constructing Passwords. It won't be
> heavy on mathematics and probabilities and will be fairly short, but the
> slides will be available for free download from my site sometime after
> 2/5/2005.
>
> Tony
> www.su-networking.com
>
>
>
>
>
>
> "Therion" wrote:
>
>> Susan et al,
>>
>> Before I begin, a bit of background: I am fairly new to the concept of
>> Windows server security as my previous experience is Unix. Don't get me
>> wrong, I have deployed many Windows servers over the years but the
>> environments I have deployed in were Corporate Unix shops where all
>> external
>> facing equipment was Unix. Even in the Exchange situations I always
>> deployed it internally (until recently) and used Sendmail based gateways.
>> So
>> it would be an accurate statement to say I have grown in this business
>> with
>> the idea that Windows is inherently insecure, but that is changing... I
>> am
>> now heavily focused on the SMB market with Server 2003 products being the
>> primary solutions.
>>
>> Now that the resume is out of the way, I would like to get a better
>> understanding of the security issue brought out here. The debate here
>> unfortunately turned into arguing the primary "cause" for Larry's
>> incident.
>> As Susan and others have pointed out, the password was the weakest link.
>> I
>> will not argue that opinion. However I find myself both embarrassed and
>> concerned in light of what this has made me realize. The fact the
>> administrator account cannot be prevented from logging in from these
>> external tools is to say the least disconcerting, but even worse is that
>> I
>> am trying to learn how to disable this and coming up empty handed.
>>
>> I understand the practice of renaming the default admin accounts and the
>> complexity it adds to potential compromise. A routine both Unix and
>> Windows
>> admins should practice when feasible. I further understand the
>> passphrase
>> versus password debates and the importance of strengthening them being
>> paramount. This may be a simple issue of what school of security you
>> come
>> from, but I still am finding it hard to understand why this account can
>> not
>> easily be removed from accessing external tools like RWW. If this were a
>> capability, I know I would sleep better at night.
>>
>> The probability of brute forcing a box with a 10+ strong password is
>> unlikely however it IS doable. The factors that I consider on this path
>> is
>> how long it would take. I have heard the arguments of how long it takes
>> to
>> brute force various length passwords with the computers of current. But
>> I
>> have to say that has little weight with me as I have "witnessed" the use
>> of
>> distributed processing for this purpose. So the question now takes a new
>> twist, what services can an attacker get the most cycles with? SMTP Auth
>> would be my gamble but form requests are right up there. With the average
>> SBS deployment, this could be done over a weekend and easily go
>> un-noticed.
>>
>> Now that I have rambled enough, let me be direct in my questions:
>>
>> 1) Am I crazy to be so concerned about the administrator account being
>> accessible externally?
>> 2) Should I just create monitoring scripts to assess this type thing in
>> the
>> logs? I would love to hear others that may be doing this.
>> 3) Or am I totally off track and need to re-program my brain... I
>> suspect I
>> will get a few of these. :-)
>>
>> P.S. I am very excited and impressed with MS's security efforts as of
>> late,
>> so I am not bashing MS, rather trying to comprehend what I am dealing
>> with.
>>
>> "Larry K" <tech@pcmavericks.com> wrote in message
>> news:%23XduJhmAFHA.2568@TK2MSFTNGP11.phx.gbl...
>> > One of our clients RWW was compromised over the weekend. Apparently
>> > they(the
>> > hack) setup a script to crack the password on the username:
>> > adminitrator
>> > and
>> > password. How do I know? I don't. What I do know is that there were
>> > around
>> > 580 attempts to login as administrator via RWW and one worked! So the
>> > password wasn't so good. It had 7 characters and numbers uppercase and
>> > lower. They accessed an application server and logged into 4 other
>> > accounts.
>> > I'm at a loss with this one. RWW doesn't lock anyone out after failed
>> > attempts. Is there a way to lock down RWW?
>> >
>> > Larry K
>> >
>> >
>>
>>
>>
- Next message: Therion: "Re: RWW Security was compromised."
- Previous message: Adam Butler: "sqlservr using lots of memory"
- In reply to: Tony Su: "Re: RWW Security was compromised."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
