Security Treats

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Would like to survey what are the most security threats in the 2000
environments? What would be the things that are usually neglected by
regular admins.

Thanks.

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

That is a huge topic. But here are some for my two cents and are not related to
Windows 2000 necessarily.

-- No or improperly configured firewalls.

-- No or inadequate backup and disaster recovery strategy.

-- No or poor password and account lockout policy.

-- Not keeping current with critical updates.

-- No or poor implementation of a strategy to manage risks for viruses, worms,
trojans.

-- Misconfigured operating systems - particularly domain controllers and dns.

-- No or not enforced computer user policy.

-- Unauthorized computers allowed on the network.

-- Letting users be local administrators when they do not need to be.

-- Not using Group Policy to manage/enforce Internet Explorer security settings.

-- Not enabling effective auditing and actually monitoring the logs.

-- Too many domain admins and not taking advantage of delegation for AD domain.

-- Operating system not hardened with too many services enabled such as IIS that is
installed and enabled by default.

-- Excessive default permissions to shares and root folder of a default install.
Everyone has full control.

-- Not physically securing sensitive computers, particularly domain controller.

-- Lazy, inept, malicious employees/students/admins.


"Sherman H." <shung@charter.net> wrote in message
news:10lb67g21jv2g11@corp.supernews.com...
> Would like to survey what are the most security threats in the 2000
> environments? What would be the things that are usually neglected by
> regular admins.
>
> Thanks.
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Great list there.

I'll add just one thing:

-- Network admins logging on to users' workstations using domain admin
credentials.

Oli


"Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
news:dzi5d.110450$MQ5.11812@attbi_s52...
> That is a huge topic. But here are some for my two cents and are not
> related to Windows 2000 necessarily.
>
> -- No or improperly configured firewalls.
>
> -- No or inadequate backup and disaster recovery strategy.
>
> -- No or poor password and account lockout policy.
>
> -- Not keeping current with critical updates.
>
> -- No or poor implementation of a strategy to manage risks for viruses,
> worms, trojans.
>
> -- Misconfigured operating systems - particularly domain controllers and
> dns.
>
> -- No or not enforced computer user policy.
>
> -- Unauthorized computers allowed on the network.
>
> -- Letting users be local administrators when they do not need to be.
>
> -- Not using Group Policy to manage/enforce Internet Explorer security
> settings.
>
> -- Not enabling effective auditing and actually monitoring the logs.
>
> -- Too many domain admins and not taking advantage of delegation for AD
> domain.
>
> -- Operating system not hardened with too many services enabled such as
> IIS that is installed and enabled by default.
>
> -- Excessive default permissions to shares and root folder of a default
> install. Everyone has full control.
>
> -- Not physically securing sensitive computers, particularly domain
> controller.
>
> -- Lazy, inept, malicious employees/students/admins.
>
>
> "Sherman H." <shung@charter.net> wrote in message
> news:10lb67g21jv2g11@corp.supernews.com...
>> Would like to survey what are the most security threats in the 2000
>> environments? What would be the things that are usually neglected by
>> regular admins.
>>
>> Thanks.
>>
>>
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Oli - why?
I realize it creates a local domain admin profile. Is
this so that someone doesn't use L0ft or the like to
extract the password? Thanks.

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

That may be a possibility (although I understood that it wasn't all that
easy), but it wasn't what I was thinking.

Think about your machine and what happens when you log in. When you log in,
several programs can start in the background, because they're in the
computer's "startup" group, or other launching points.

Now, imagine that a malicious user wants to gain domain admin access. All
he has to do is to make a script that will add a new user to the domain and
give that user domain admin rights, make that script launch when somebody
logs in and then persuade an administrator to come over and fix some
"problem". When they log in, the administrator unwittingly gives away
domain admin.

This isn't a bug or a problem in Windows and Microsoft aren't going to "fix"
this.

Now, it may be the case that you don't give your users the power user or
administrator level access to the local machine that's required to cause
things to run when somebody logs into a machine.

That's good, but there are two reasons why this is not enough. The first is
that there's nearly always a gap between what you think is true and what is
actually true. You may think that nobody has power user or administrator to
any machines, but this is an common way to make some poorly-written software
run.

The other reason is that if sombody has physical access to your computer,
they can change the way that computer behaves. Sure, it may take some
effort, but given the right software, it's actually not difficult to gain
local admin access given physical access to a machine.

So, how should you change your ways and still allow you or your helpdeesk
people to do their job? If you have group policy, it's fairly easy.

Create a new security group and call it, say, "Helpdesk". Create some
workstation admin accounts and place them in the group.

Make sure your workstation accounts reside in an OU (rather than the default
"computers" container) and create a new group policy object on that OU.

Then, create a new Group Policy object and set up a computer startup script
(Computer Configuration | Windows Settings | Scripts (Startup/Shutdown) |
Startup

For name, use "net"
For parameters, use "localgroup administrators domain\helpdesk /add"

This will execute the command "net localgroup administrators domain\helpdesk
/add" each time a machine affected by the policy boots.

Additionally, you should aim to not even log in at your own workstation with
domain admin credentials. You can do this and still allow your regular
accouunt to do day-to-day activities such as creating users and resetting
passwords by using the delegation of control wizard. If you do this, make
sure you always delegate permissions to a group, rather than individual
users.

Hope this helps

Oli






<anonymous@discussions.microsoft.com> wrote in message
news:2d7b01c4a4a6$3bb831b0$a301280a@phx.gbl...
> Oli - why?
> I realize it creates a local domain admin profile. Is
> this so that someone doesn't use L0ft or the like to
> extract the password? Thanks.

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Gee I though you were just concerned that they could install a keyboard
logger. --- Steve

"Oli Restorick [MVP]" <oli@mvps.org> wrote in message
news:OEWxewmpEHA.3572@TK2MSFTNGP10.phx.gbl...
> That may be a possibility (although I understood that it wasn't all that
> easy), but it wasn't what I was thinking.
>
> Think about your machine and what happens when you log in. When you log
> in, several programs can start in the background, because they're in the
> computer's "startup" group, or other launching points.
>
> Now, imagine that a malicious user wants to gain domain admin access. All
> he has to do is to make a script that will add a new user to the domain
> and give that user domain admin rights, make that script launch when
> somebody logs in and then persuade an administrator to come over and fix
> some "problem". When they log in, the administrator unwittingly gives
> away domain admin.
>
> This isn't a bug or a problem in Windows and Microsoft aren't going to
> "fix" this.
>
> Now, it may be the case that you don't give your users the power user or
> administrator level access to the local machine that's required to cause
> things to run when somebody logs into a machine.
>
> That's good, but there are two reasons why this is not enough. The first
> is that there's nearly always a gap between what you think is true and
> what is actually true. You may think that nobody has power user or
> administrator to any machines, but this is an common way to make some
> poorly-written software run.
>
> The other reason is that if sombody has physical access to your computer,
> they can change the way that computer behaves. Sure, it may take some
> effort, but given the right software, it's actually not difficult to gain
> local admin access given physical access to a machine.
>
> So, how should you change your ways and still allow you or your helpdeesk
> people to do their job? If you have group policy, it's fairly easy.
>
> Create a new security group and call it, say, "Helpdesk". Create some
> workstation admin accounts and place them in the group.
>
> Make sure your workstation accounts reside in an OU (rather than the
> default "computers" container) and create a new group policy object on
> that OU.
>
> Then, create a new Group Policy object and set up a computer startup
> script
> (Computer Configuration | Windows Settings | Scripts (Startup/Shutdown) |
> Startup
>
> For name, use "net"
> For parameters, use "localgroup administrators domain\helpdesk /add"
>
> This will execute the command "net localgroup administrators
> domain\helpdesk /add" each time a machine affected by the policy boots.
>
> Additionally, you should aim to not even log in at your own workstation
> with domain admin credentials. You can do this and still allow your
> regular accouunt to do day-to-day activities such as creating users and
> resetting passwords by using the delegation of control wizard. If you do
> this, make sure you always delegate permissions to a group, rather than
> individual users.
>
> Hope this helps
>
> Oli
>
>
>
>
>
>
> <anonymous@discussions.microsoft.com> wrote in message
> news:2d7b01c4a4a6$3bb831b0$a301280a@phx.gbl...
>> Oli - why?
>> I realize it creates a local domain admin profile. Is
>> this so that someone doesn't use L0ft or the like to
>> extract the password? Thanks.
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

When I said "Make sure your workstation accounts reside in an OU", that may
have been confusing. What I meant was the computer accounts for your
workstations, or more simply, the computer objects.

Cheers

Oli


"Oli Restorick [MVP]" <oli@mvps.org> wrote in message
news:OEWxewmpEHA.3572@TK2MSFTNGP10.phx.gbl...
> That may be a possibility (although I understood that it wasn't all that
> easy), but it wasn't what I was thinking.
>
> Think about your machine and what happens when you log in. When you log
> in, several programs can start in the background, because they're in the
> computer's "startup" group, or other launching points.
>
> Now, imagine that a malicious user wants to gain domain admin access. All
> he has to do is to make a script that will add a new user to the domain
> and give that user domain admin rights, make that script launch when
> somebody logs in and then persuade an administrator to come over and fix
> some "problem". When they log in, the administrator unwittingly gives
> away domain admin.
>
> This isn't a bug or a problem in Windows and Microsoft aren't going to
> "fix" this.
>
> Now, it may be the case that you don't give your users the power user or
> administrator level access to the local machine that's required to cause
> things to run when somebody logs into a machine.
>
> That's good, but there are two reasons why this is not enough. The first
> is that there's nearly always a gap between what you think is true and
> what is actually true. You may think that nobody has power user or
> administrator to any machines, but this is an common way to make some
> poorly-written software run.
>
> The other reason is that if sombody has physical access to your computer,
> they can change the way that computer behaves. Sure, it may take some
> effort, but given the right software, it's actually not difficult to gain
> local admin access given physical access to a machine.
>
> So, how should you change your ways and still allow you or your helpdeesk
> people to do their job? If you have group policy, it's fairly easy.
>
> Create a new security group and call it, say, "Helpdesk". Create some
> workstation admin accounts and place them in the group.
>
> Make sure your workstation accounts reside in an OU (rather than the
> default "computers" container) and create a new group policy object on
> that OU.
>
> Then, create a new Group Policy object and set up a computer startup
> script
> (Computer Configuration | Windows Settings | Scripts (Startup/Shutdown) |
> Startup
>
> For name, use "net"
> For parameters, use "localgroup administrators domain\helpdesk /add"
>
> This will execute the command "net localgroup administrators
> domain\helpdesk /add" each time a machine affected by the policy boots.
>
> Additionally, you should aim to not even log in at your own workstation
> with domain admin credentials. You can do this and still allow your
> regular accouunt to do day-to-day activities such as creating users and
> resetting passwords by using the delegation of control wizard. If you do
> this, make sure you always delegate permissions to a group, rather than
> individual users.
>
> Hope this helps
>
> Oli
>
>
>
>
>
>
> <anonymous@discussions.microsoft.com> wrote in message
> news:2d7b01c4a4a6$3bb831b0$a301280a@phx.gbl...
>> Oli - why?
>> I realize it creates a local domain admin profile. Is
>> this so that someone doesn't use L0ft or the like to
>> extract the password? Thanks.
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

Well, doesn't Ctrl-Alt-Delete stop the keylogger working? <g>

Oli




"Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
newsDG6d.180014$3l3.172957@attbi_s03...
> Gee I though you were just concerned that they could install a keyboard
> logger. --- Steve
>
> "Oli Restorick [MVP]" <oli@mvps.org> wrote in message
> news:OEWxewmpEHA.3572@TK2MSFTNGP10.phx.gbl...
>> That may be a possibility (although I understood that it wasn't all that
>> easy), but it wasn't what I was thinking.
>>
>> Think about your machine and what happens when you log in. When you log
>> in, several programs can start in the background, because they're in the
>> computer's "startup" group, or other launching points.
>>
>> Now, imagine that a malicious user wants to gain domain admin access.
>> All he has to do is to make a script that will add a new user to the
>> domain and give that user domain admin rights, make that script launch
>> when somebody logs in and then persuade an administrator to come over and
>> fix some "problem". When they log in, the administrator unwittingly
>> gives away domain admin.
>>
>> This isn't a bug or a problem in Windows and Microsoft aren't going to
>> "fix" this.
>>
>> Now, it may be the case that you don't give your users the power user or
>> administrator level access to the local machine that's required to cause
>> things to run when somebody logs into a machine.
>>
>> That's good, but there are two reasons why this is not enough. The first
>> is that there's nearly always a gap between what you think is true and
>> what is actually true. You may think that nobody has power user or
>> administrator to any machines, but this is an common way to make some
>> poorly-written software run.
>>
>> The other reason is that if sombody has physical access to your computer,
>> they can change the way that computer behaves. Sure, it may take some
>> effort, but given the right software, it's actually not difficult to gain
>> local admin access given physical access to a machine.
>>
>> So, how should you change your ways and still allow you or your helpdeesk
>> people to do their job? If you have group policy, it's fairly easy.
>>
>> Create a new security group and call it, say, "Helpdesk". Create some
>> workstation admin accounts and place them in the group.
>>
>> Make sure your workstation accounts reside in an OU (rather than the
>> default "computers" container) and create a new group policy object on
>> that OU.
>>
>> Then, create a new Group Policy object and set up a computer startup
>> script
>> (Computer Configuration | Windows Settings | Scripts (Startup/Shutdown) |
>> Startup
>>
>> For name, use "net"
>> For parameters, use "localgroup administrators domain\helpdesk /add"
>>
>> This will execute the command "net localgroup administrators
>> domain\helpdesk /add" each time a machine affected by the policy boots.
>>
>> Additionally, you should aim to not even log in at your own workstation
>> with domain admin credentials. You can do this and still allow your
>> regular accouunt to do day-to-day activities such as creating users and
>> resetting passwords by using the delegation of control wizard. If you do
>> this, make sure you always delegate permissions to a group, rather than
>> individual users.
>>
>> Hope this helps
>>
>> Oli
>>
>>
>>
>>
>>
>>
>> <anonymous@discussions.microsoft.com> wrote in message
>> news:2d7b01c4a4a6$3bb831b0$a301280a@phx.gbl...
>>> Oli - why?
>>> I realize it creates a local domain admin profile. Is
>>> this so that someone doesn't use L0ft or the like to
>>> extract the password? Thanks.
>>
>>
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.security (More info?)

This isn't hard to exploit, btw. A two line batch file will do just fine.

Oli


"Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
newsDG6d.180014$3l3.172957@attbi_s03...
> Gee I though you were just concerned that they could install a keyboard
> logger. --- Steve
>
> "Oli Restorick [MVP]" <oli@mvps.org> wrote in message
> news:OEWxewmpEHA.3572@TK2MSFTNGP10.phx.gbl...
>> That may be a possibility (although I understood that it wasn't all that
>> easy), but it wasn't what I was thinking.
>>
>> Think about your machine and what happens when you log in. When you log
>> in, several programs can start in the background, because they're in the
>> computer's "startup" group, or other launching points.
>>
>> Now, imagine that a malicious user wants to gain domain admin access.
>> All he has to do is to make a script that will add a new user to the
>> domain and give that user domain admin rights, make that script launch
>> when somebody logs in and then persuade an administrator to come over and
>> fix some "problem". When they log in, the administrator unwittingly
>> gives away domain admin.
>>
>> This isn't a bug or a problem in Windows and Microsoft aren't going to
>> "fix" this.
>>
>> Now, it may be the case that you don't give your users the power user or
>> administrator level access to the local machine that's required to cause
>> things to run when somebody logs into a machine.
>>
>> That's good, but there are two reasons why this is not enough. The first
>> is that there's nearly always a gap between what you think is true and
>> what is actually true. You may think that nobody has power user or
>> administrator to any machines, but this is an common way to make some
>> poorly-written software run.
>>
>> The other reason is that if sombody has physical access to your computer,
>> they can change the way that computer behaves. Sure, it may take some
>> effort, but given the right software, it's actually not difficult to gain
>> local admin access given physical access to a machine.
>>
>> So, how should you change your ways and still allow you or your helpdeesk
>> people to do their job? If you have group policy, it's fairly easy.
>>
>> Create a new security group and call it, say, "Helpdesk". Create some
>> workstation admin accounts and place them in the group.
>>
>> Make sure your workstation accounts reside in an OU (rather than the
>> default "computers" container) and create a new group policy object on
>> that OU.
>>
>> Then, create a new Group Policy object and set up a computer startup
>> script
>> (Computer Configuration | Windows Settings | Scripts (Startup/Shutdown) |
>> Startup
>>
>> For name, use "net"
>> For parameters, use "localgroup administrators domain\helpdesk /add"
>>
>> This will execute the command "net localgroup administrators
>> domain\helpdesk /add" each time a machine affected by the policy boots.
>>
>> Additionally, you should aim to not even log in at your own workstation
>> with domain admin credentials. You can do this and still allow your
>> regular accouunt to do day-to-day activities such as creating users and
>> resetting passwords by using the delegation of control wizard. If you do
>> this, make sure you always delegate permissions to a group, rather than
>> individual users.
>>
>> Hope this helps
>>
>> Oli
>>
>>
>>
>>
>>
>>
>> <anonymous@discussions.microsoft.com> wrote in message
>> news:2d7b01c4a4a6$3bb831b0$a301280a@phx.gbl...
>>> Oli - why?
>>> I realize it creates a local domain admin profile. Is
>>> this so that someone doesn't use L0ft or the like to
>>> extract the password? Thanks.
>>
>>
>
>