Security Treats

  • Thread starter Thread starter Sherman H.
  • Start date Start date
S

Sherman H.

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.
 
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.
 
Great list there.

I'll add just one thing:

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

Oli
 
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.
 
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
 
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
 
Gee I though you were just concerned that they could install a keyboard
logger. --- Steve
 
This isn't hard to exploit, btw. A two line batch file will do just fine.

Oli
 
Back
Top