Hacked Workstations

[Guest]

I just want to say thank you all for your replies. I appreciate your help.
What we have ended up doing is just instituting a policy of containment. The
student network is completely seperate from the other networks in the school.
Our student servers are stored away from student access and locked down
tightly.

We just view the student network as a hostile network and assume that
anything going on could be being recorded via keystroke logger or packet
sniffer. For most software problems we just reimage the machine and don't
even log on, just wipe it and reimage. Oh well. I was hoping for a way to
actually beat these kids at their own game and take the network back. But
with out the support of the school administration that just isn't going to
happen.

 

[Steven L Umbach]

Well from reading all the posts it seems that other than you no one else
cares and the activity is tolerated which I find outrageous. If they disrupt
computers that no one uses then maybe that is not a huge problem but if they
are disrupting the work and privacy of other students that should be a major
concern to someone other than you and if a parent finds out that their child
had their hard work deleted or privacy violated I would not want to be in
your shoes or anyone else who is responsible for the computers and network
which ultimately could be the school's principle. I would make sure that you
CYA with documentation of this problem that includes that the right people
have been notified and you saving all reply responses. Personally I can't
believe that any parent would remove their child from the school because
they were not allowed to hack the schools computers. --- Steve

 

[Lanwench [MVP - Exchange]]

That is one of the problems. The administration does not view this as
a serious problem.

Keep exhaustively-detailed logs of every nanosecond spent fixing one of the
PCs/restoring/re-imaging it and note the student's name. Submit this weekly
to all management. If you are asked to work on other projects, show them how
much time was spent doing this, and explain that there are only so many
hours in a week, and ask your management which task they would rather you
did, as it's one or the other.

Also, you may be able to do what a lot of computer training centers do &
entirely re-image the machines nightly.

 

[Kevin D. Quitt]

What we have ended up doing is just instituting a policy of containment. The
student network is completely seperate from the other networks in the school.

Given the policy of allowing physical access to the machines and providing
a means to reboot the machines with the students' disks, I don't think
there is anything else meaningful you can do.

Our student servers are stored away from student access and locked down
tightly.

Clearly, an excellent idea under any circumstances.

We just view the student network as a hostile network and assume that
anything going on could be being recorded via keystroke logger or packet
sniffer.

Not a bad idea in general, unless the network is being actively monitored.
Also assume you're on Candid Camera.

For most software problems we just reimage the machine and don't
even log on, just wipe it and reimage. Oh well.

Even better than my suggestion; no extra hardware required. This, by the
way, is the policy at the school where my wife teaches (and helps manage
the network), even for teachers' machines. The rules are: keep your own
data backed up; if you want support, do not install any of your own
software; if your machine is causing problems on the network, it gets
reimaged. Draconian, but since there is no support department (just my
wife and a couple of savvy folk), it's the only way to keep everything
running.

I was hoping for a way to actually beat these kids at their own game and
take the network back.

Would be nice, eh? Too bad you can't lock them into virtual machines.

But with out the support of the school administration that just isn't
going to happen.

And there is the bottom line.

 

[Steve Clark [MSFT]]

This isn't an "NT" security trait: all *IT* security depends on layers of
security, starting with physical security.

The ability to use advanced security technologies is almost always
predicated on appropriate physical security.

It is a private school. The school makes tens of thousands of dollars for
every student that attends. So unless a student is causing the school to lose
money (causing tens of thousands of dollars in damage would make them
unprofitable for the school, but that kind of damage is unlikely) then there
is no way in hell that they will kick them out.

These students are not very smart. A few skript kiddiots showed everyone
else the few tricks mentioned to get the local admin password. So I was
thinking that maybe if I could somehow encrypt the System32 folder using EFS
or something then they at least wouldn't be able to boot off a Linux CD and
delete the SAM as the wouldn't be able to find the SAM on the encrypted drive.

Would that even work though? I don't know much about EFS.

All NT-type security (with very few exceptions)
require PHYSICAL security of the machines.

If you give them the ability to boot the machine
then all bets are off.

EFS can protect data files (and even some exe etc.)
but it cannot protect many/most system files since
they must be readable immediately.

THey would ALWAYS be able to "Find" the SAM
since EFS protects ONLY files (not the directory
structure.)

[Despite common misperception and even the way
the prompts in the tools are worded there are no
"encrypted directories" -- encrypting directories
means setting the defaults for files created there.]

 

[Herb Martin]

This isn't an "NT" security trait: all *IT* security depends on layers of
security, starting with physical security.

The ability to use advanced security technologies is almost always
predicated on appropriate physical security.

We agree -- what I meant by the statement is
that one cannot expect nor blame NT-security
features if you don't maintain physical security
of the machine and control of the hardware.

One of the few exceptions might be EFS if you
do it correctly.

--
Herb Martin

It is a private school. The school makes tens of thousands of dollars for
every student that attends. So unless a student is causing the school

to
lose

money (causing tens of thousands of dollars in damage would make them
unprofitable for the school, but that kind of damage is unlikely) then there
is no way in hell that they will kick them out.

These students are not very smart. A few skript kiddiots showed everyone
else the few tricks mentioned to get the local admin password. So I was
thinking that maybe if I could somehow encrypt the System32 folder

using
EFS

or something then they at least wouldn't be able to boot off a Linux CD and
delete the SAM as the wouldn't be able to find the SAM on the encrypted drive.

Would that even work though? I don't know much about EFS.

All NT-type security (with very few exceptions)
require PHYSICAL security of the machines.

If you give them the ability to boot the machine
then all bets are off.

EFS can protect data files (and even some exe etc.)
but it cannot protect many/most system files since
they must be readable immediately.

THey would ALWAYS be able to "Find" the SAM
since EFS protects ONLY files (not the directory
structure.)

[Despite common misperception and even the way
the prompts in the tools are worded there are no
"encrypted directories" -- encrypting directories
means setting the defaults for files created there.]



--
Herb Martin

:


I work at a school where students have been booting off Linux CDs and
deleting the SAM and booting off NT password reset floppies to

delete
the

admin password.

For reasons beyond my control we have to give the students the
ability to
boot off of floppies and CDs.

My question is how can we stop this from happening?

you have a couple options. the hardest one to get implimented is to
discipline anyone caught bypassing security... kick a few of them out
of
school and maybe the others will get the idea. or you could live

with
the

fact that its going to happen and make sure that you have a quick way
to
restore the proper image to a hacked machine. maybe even boot from a
network instead of the local hard drive. if you go this way you also
probably want to segregate the student machines so they don't have access to
anything important. basically if you are in a situation where you
can't
control physical access to the machines you can't stop anyone from
doing
basically anything they want.

 

[Guest]

You could try a peice of software called DeepFreeze, it might be a solution
to your problem... I basically reinstall a image of the drive at boot
time... Might work for you.