Advice Please; How to "Quarantine" Hard Drives

[David Maynard]

But since as I said, I'll be working with my "C" drive

And what does 'working with' the C drive mean?

(and will only
occasionally need to copy to the other three), it seems that I won't
have the freemdom I need with that drive until I login in as an
"Administrator", which of course opens up the other drives to
malicious code.

Your 'plan' opens them to malicious code by leaving your C: drive
completely unprotected, so that it can become infected, and then it infects
the other drives the instant you 'spin them up'.

It seems that you're talking about an all-or-nothing solution, and I
need complete freedom with *one* drive while protecting the others. Or
is there sommething I'm not being told?

You're asking for 'complete freedom', why I don't know, for the drive on
which an infection is most likely since every targeted vulnerability
resides on it, and the one where it matter most, yet want to be
'protected'. Just ain't going to happen.

Basically, I'd need for the "C" drive to "see" me as an
"Administrator", but not the other three drives. IS that possible?

Yes. Format them NTFS and then mount/dismount them when needed. Or buy
'removable' drives and 'unplug' them when not needed. Doesn't really matter
because whatever vulnerability you're protecting them from will simply
infect them the moment you activate them.

 

[kony]

It seems that you're talking about an all-or-nothing solution, and I
need complete freedom with *one* drive while protecting the others. Or
is there sommething I'm not being told?

That you're trying to reinvent the wheel to a certain extent,
that having protected data is the whole purpose behind removable
media and/or disconnected backup storage?

The moment you are in a position to access those other drive(s),
so is any virus/etc. If it were simply a matter of "denial" of
access to drives, would viri exist at all? Could we not simply
assign all file transfers to a ramdrive and deny all traditional
physical storage rights?

WinXP should be able to pick up a drive connected to a SCSI IDE
controller if it is powered on, from being off, while system
stays running, providing your SCSI controller also supports this.
In other words, you'd be closing power circuit to drive to use
it, then opening circuit again when done. If you can settle for
manually flipping a switch, it is relatively easy, or you could
go a more complicated route and have software commands to cause a
port to drive a relay to do it.

 

[J. Clarke]

But since as I said, I'll be working with my "C" drive(and will only
occasionally need to copy to the other three), it seems that I won't
have the freemdom I need with that drive until I login in as an
"Administrator", which of course opens up the other drives to
malicious code.

It seems that you're talking about an all-or-nothing solution, and I
need complete freedom with *one* drive while protecting the others. Or
is there sommething I'm not being told?


Basically, I'd need for the "C" drive to "see" me as an
"Administrator", but not the other three drives. IS that possible?

I'm going to give you a rather extreme suggestion that is quite workable and
about as secure as you're going to get with a single machine, but not
particularly simple or cheap. Run your Windows under VirtualPC for OS/2
with Netware 4.1 for OS/2, accessing your additional drives via Netware.
All runs on one box, quite reliable, performance is acceptable on modern
hardware, primary Internet exposure is OS/2 which if not bulletproof (and
OS/2 fans, I didn't say it wasn't bulletproof, just that even if it isn't)
is at least uncommon enough to be below the radar for crackers, you have
Novell's very robust and fine-grained security, you can do your
administration from a separate Windows session that is set up under IPX/SPX
and has no Internet access, so you can turn on and off privilege for your
working session as required, and your working Windows session is isolated
in the VirtualPC sandbox.

Less extreme, you could run your Windows session under VMWare on a Linux
box, with your additional drives accessed via SAMBA. Security is not as
fine-grained as Netware but should be plenty for what you want to do, you
can enable write access when desired from the Linux console without closing
Windows or unplugging anything, again Windows is isolated in a
virtual-machine sandbox, and primary internet exposure is Linux, which
while not below the radar doesn't have a whole heck of a lot of known
exploits extant.

Could also do this with VMware or VirtualPC under Windows, running
"dangerous" activities in the virtual session--this would be more secure
than running it in your console session but Windows would be exposed on the
Net, and there are known exploits that require only exposure. Again you'd
enable or disable write access from the console session.

 

[Don Taylor]

....
Basically, I'd need for the "C" drive to "see" me as an
"Administrator", but not the other three drives. IS that possible?

So, asking a question here, what would it take in terms of hardware
between the IDE cable and the drive to make a (non-boot) drive
read-only? Or maybe non-existant? Back in the old ST506/MFM days
I imagine that a switch to disconnect the write signal to the drive
would have done it. The same might be possible with (non-boot) IDE
drives.

And you might be able to accomplish the same with SCSI drives.

Then you don't need any suspicious software to pay for, you don't
need another operating system to use, any attempt to write to the
drive would likely just get an error reported by your OS, and on
the rare occasions you want to write to the drive you close the
switch.

 

[CJT]

So, asking a question here, what would it take in terms of hardware
between the IDE cable and the drive to make a (non-boot) drive
read-only? Or maybe non-existant? Back in the old ST506/MFM days
I imagine that a switch to disconnect the write signal to the drive
would have done it. The same might be possible with (non-boot) IDE
drives.

And you might be able to accomplish the same with SCSI drives.

Then you don't need any suspicious software to pay for, you don't
need another operating system to use, any attempt to write to the
drive would likely just get an error reported by your OS, and on
the rare occasions you want to write to the drive you close the
switch.

As I recall, to read an IDE drive you have to write to its registers.

 

[Don Taylor]

As I recall, to read an IDE drive you have to write to its registers.

I believe that is true, something like 8 registers make up IDE. You
fill some of those with the block number on the drive and then fill
a command register with a read command. But I've never found any
info on someone trying to protect drives with this, or do other
silly things like display the current block number on the front of
the case, the way some wierd off-brand pc did fifteen years ago.

thanks

 

[CJT]

I believe that is true, something like 8 registers make up IDE. You
fill some of those with the block number on the drive and then fill
a command register with a read command. But I've never found any
info on someone trying to protect drives with this, or do other
silly things like display the current block number on the front of
the case, the way some wierd off-brand pc did fifteen years ago.

thanks

The point is that the logic needed is more significant than simply
pulling down a write signal.

 

[Darren Harris]

That you're trying to reinvent the wheel to a certain extent,
that having protected data is the whole purpose behind removable
media and/or disconnected backup storage?

But I'm talking about the option of keeping all my data in one
place(case) and protecting it.

I'm not trying to reinvent the wheel. The wheel is inherently faulty.

The moment you are in a position to access those other drive(s),
so is any virus/etc. If it were simply a matter of "denial" of
access to drives, would viri exist at all? Could we not simply
assign all file transfers to a ramdrive and deny all traditional
physical storage rights?

There is no great technological hurdle in hardware manufacturers
making systems that give the user total control over the writing
between drives(without having to power them down), but they will not
do it.

WinXP should be able to pick up a drive connected to a SCSI IDE
controller if it is powered on, from being off, while system
stays running, providing your SCSI controller also supports this.
In other words, you'd be closing power circuit to drive to use
it, then opening circuit again when done. If you can settle for
manually flipping a switch, it is relatively easy, or you could
go a more complicated route and have software commands to cause a
port to drive a relay to do it.

Perhaps in the future one will have the option of "flipping a switch"
to quarantine specific drives, keeping them from being written to.

Darren Harris
Staten Island, New York.

 

[Darren Harris]

Yes. Format them NTFS and then mount/dismount them when needed. Or buy

'removable' drives and 'unplug' them when not needed. Doesn't really matter
because whatever vulnerability you're protecting them from will simply
infect them the moment you activate them.

Not if I can shut down the "C" drive first.

Nevertheless, if I have a system multiple drives inside it's case, I
shouldn't have to get "removable drives" in order to quarantine,
but...

The bottom line is that something that should be simple isn't because
there is too much money to be made using paid for solutions from that
hardware and software manufacturers.(Not to mention ITs).

Darren Harris
Staten Island, New York.

 

[David Maynard]

Not if I can shut down the "C" drive first.

And just how are you going to automagically, and instantly, transfer the
operating system to something else so it runs when you 'shutdown' the C:
drive? Not to mention, where are you going to find uninfected OS files if
the C: drive is corrupted: the reason you're shutting it down?

If you're going to operate it as if it were 'two' machines, one with the
'internet' infected files that never talk to the 'safe' drives, and the
'safe' drives that never talk to the nasty infected one, then simply dual
boot the thing with the opposing drives dismounted and removed from the other.

Nevertheless, if I have a system multiple drives inside it's case, I
shouldn't have to get "removable drives" in order to quarantine,
but...

And why not? Because you don't like the 'name'?

You presume there is some useful purpose to 'quarantining' hard drives but
there isn't; which answers your question of why they don't already do it.

The bottom line is that something that should be simple isn't because
there is too much money to be made using paid for solutions from that
hardware and software manufacturers.(Not to mention ITs).

No, the bottom line is that your proposed 'solution' does not solve the
problem you base it on any better than the solutions already available.

 

[Mike Redrobe]

Nevertheless, if I have a system multiple drives inside it's case, I
shouldn't have to get "removable drives" in order to quarantine,
but...

The bottom line is that something that should be simple isn't because
there is too much money to be made using paid for solutions from that
hardware and software manufacturers.(Not to mention ITs).

If you *really* want hardware level write-protection of hard drives
you have to look to the forensics industry - see links below...

This stuff isn't cheap though:

"This special Write-Protect version of the ARS7720UW disables the ability to
write to the
connected IDE drive. For auditability of forensic data this is an essential
product."
http://www.verbatim.com.au/products.cfm?productID=ARS7720WP

"SCSIBLOCK is a 68 Pin SCSI-3 to IDE conversion device that provides full
hardware
write protection to IDE devices while permitting direct connection to any
SCSI-3 bus."
http://www.digitalintel.com/scsiblock.htm

http://www.logicubeforensics.com/products/accessories/desktopwriteprotect.asp

http://www.forensicpc.com/products.asp?cat=19

http://www.memstore.se/LEVEL2/PRODUKTER/LEVEL3/FORENSIC/LEVEL2/DriveLock.htm

There are older IDE drives which had a write-protect jumper (I have an
ancient fujitsu
500Mb drive with one), it is/was much more common on SCSI drives though.

IIRC I'm sure I`ve seen this option in the BIOS of a SCSI adaptor as well.

It isn't as simple as cutting a wire on the ribbon....

 

[J. Clarke]

But I'm talking about the option of keeping all my data in one
place(case) and protecting it.

I'm not trying to reinvent the wheel. The wheel is inherently faulty.



There is no great technological hurdle in hardware manufacturers
making systems that give the user total control over the writing
between drives(without having to power them down), but they will not
do it.

Perhaps there is no demand for this feature?

Perhaps in the future one will have the option of "flipping a switch"
to quarantine specific drives, keeping them from being written to.

Perhaps. Personally I would rate the probability of it occurring on par
with the probability that Santa Claus and the Easter Bunny will have a
boxing match in Madison Square Garden. For the two people in the universe
who percieve this need there are ways to accomplish that objective with
software. If you aren't willing to do what you have to to get there then
you don't have a _need_, you have an idle whim.

 

[Darren Harris]

And just how are you going to automagically, and instantly, transfer the
operating system to something else so it runs when you 'shutdown' the C:
drive? Not to mention, where are you going to find uninfected OS files if
the C: drive is corrupted: the reason you're shutting it down?

No that wouldn't be the reason I'm shutting it down. You're missing
the whole point. I'm conveying inherent software(OS) limitations that
shouldn't exist. My first system had the OS on all three drives. But
thanks to the way software is written, if my "C" drive went down, I
still wouldn't be able to use my other drives without major changes to
my system first.

If you're going to operate it as if it were 'two' machines, one with the
'internet' infected files that never talk to the 'safe' drives, and the
'safe' drives that never talk to the nasty infected one, then simply dual
boot the thing with the opposing drives dismounted and removed from the other.

Again, you are missing the point. Re-read the above posts. You're
repeating what has already been said. And it's not in line with my
goal.(Achievable or not).

And why not? Because you don't like the 'name'?

That made no sense whatsoever. Again, re-read the above posts. I
already gave the reasons why that wasn't an option.

You presume there is some useful purpose to 'quarantining' hard drives but
there isn't; which answers your question of why they don't already do it.

You are incorrect. The reasons are amazingly obvious, and have already
been mentioned here.

No, the bottom line is that your proposed 'solution' does not solve the
problem you base it on any better than the solutions already available.

Sigh... Wrong. THis isn't about a "proposed solution". I indicated
what I wanted to do and why.(Re-read the post that started this
thread). The posters in this thread only had to say it is *not*
possible.

ie: "One cannot "quarantine" three drives from a fourth, or change
write options on the fly." I've come to this conclusion myself based
on what was said.

Darren Harris
Staten Island, New York.

 

[Darren Harris]

And what does 'working with' the C drive mean?

?!? I assume you don't understand that the "C" drive is the drive that
I want to isolate the other three from or that it is the one that will
be used when connected to the internet, correct?

Your 'plan' opens them to malicious code by leaving your C: drive
completely unprotected, so that it can become infected, and then it infects
the other drives the instant you 'spin them up'.

How is the "C" drive "completely unprotected", when there are
anti-virus and firewall utilities?

You're asking for 'complete freedom', why I don't know, for the drive on
which an infection is most likely since every targeted vulnerability
resides on it, and the one where it matter most, yet want to be
'protected'. Just ain't going to happen.

See my last paragraph.

Yes. Format them NTFS and then mount/dismount them when needed. Or buy
'removable' drives and 'unplug' them when not needed. Doesn't really matter
because whatever vulnerability you're protecting them from will simply
infect them the moment you activate them.

We've been through this already...

Darren Harris
Staten Island, New York.

 

[Darren Harris]

The moment you are in a position to access those other drive(s),

Perhaps there is no demand for this feature?

?!? There would be if it were an option.

Perhaps. Personally I would rate the probability of it occurring on par
with the probability that Santa Claus and the Easter Bunny will have a
boxing match in Madison Square Garden. For the two people in the universe
who percieve this need there are ways to accomplish that objective with
software. If you aren't willing to do what you have to to get there then
you don't have a _need_, you have an idle whim.

The inability to understand what I've written by *some* of the posters
in this thread is astounding.

I saw a problem. I asked if there a particular solution was possible.
And if so, how to do it. The common concensus *seems* to be that it is
*not* possible. Just because I find certain solutions given to be
impractical for me doesn't mean that I am "willing to do what (I) have
to to get there". It has become obvious that it isn't possible to have
the options I want, and I conveyed that it should be, and gave the
reasons. And I gave the reasons why the "proposed" solutions would not
work for me. That's all.

What's is so difficult to understand?

It's a good thing that inovative minds are not on "lock-down" like
that minds of many here.

Darren Harris
Staten ISland, New York.

 

[Darren Harris]

I'm going to give you a rather extreme suggestion that is quite workable and
about as secure as you're going to get with a single machine, but not
particularly simple or cheap. Run your Windows under VirtualPC for OS/2
with Netware 4.1 for OS/2, accessing your additional drives via Netware.
All runs on one box, quite reliable, performance is acceptable on modern
hardware, primary Internet exposure is OS/2 which if not bulletproof (and
OS/2 fans, I didn't say it wasn't bulletproof, just that even if it isn't)
is at least uncommon enough to be below the radar for crackers, you have
Novell's very robust and fine-grained security, you can do your
administration from a separate Windows session that is set up under IPX/SPX
and has no Internet access, so you can turn on and off privilege for your
working session as required, and your working Windows session is isolated
in the VirtualPC sandbox.

Less extreme, you could run your Windows session under VMWare on a Linux
box, with your additional drives accessed via SAMBA. Security is not as
fine-grained as Netware but should be plenty for what you want to do, you
can enable write access when desired from the Linux console without closing
Windows or unplugging anything, again Windows is isolated in a
virtual-machine sandbox, and primary internet exposure is Linux, which
while not below the radar doesn't have a whole heck of a lot of known
exploits extant.

Could also do this with VMware or VirtualPC under Windows, running
"dangerous" activities in the virtual session--this would be more secure
than running it in your console session but Windows would be exposed on the
Net, and there are known exploits that require only exposure. Again you'd
enable or disable write access from the console session.

The cost, learning curve, and relative support make all of this
impractical as far as what I'd like to do.

Thanks.

Darren Harris
Staten Island, New York.

 

[Alexander Grigoriev]

OK, here is a procedure for you:

1. Assume your drives you want to protect are formatted as NTFS. The example
goes for a drive E:
2. Create an user account, for example "PowerfulMe". It can be a limited
user, too. Set a password on it.
3. Run the following (while logged as an administrator):

cacls E: /g Everyone:r Administrators:f SYSTEM:f PowerfulMe:c
OWNER_CREATOR:f

4. When you want to copy files to E: (while logged as a regular user),
right-click on blue IE icon, select RunAs, enter PowerfulMe and its
password. Enter e:\ in the address line. Click on [Folders] button. Copy the
source files to the drive. It's assumed that you gave PowerfulMe
read-permissions to the source files. When you're done copying, close the
Explorer window, which runs as PowerfulMe. You can also run copy with a
command-line script, if you open a command console with Run As.

You can have a separate account with write privileges for each drive, if you
like.

 

[J. Clarke]

The cost, learning curve, and relative support make all of this
impractical as far as what I'd like to do.

The cost and learning curve might be an issue. The "relative support" is
minor--once you have OS/2 and Novell up and running they don't need much in
the way of support, they just kind of sit there and work.

Are you looking for a solution for a personal machine or for some other
purpose? If some other purpose if you gave some details someone might be
able to propose a workable solution.

 

[J. Clarke]

?!? There would be if it were an option.

It was on some drives. The market apparently gave a great big yawn and the
drive manufacturers decided that they had wasted the 2 cents or whatever it
is that the header for the jumper costs and quit providing such a feature.

The inability to understand what I've written by *some* of the posters
in this thread is astounding.

I saw a problem. I asked if there a particular solution was possible.
And if so, how to do it. The common concensus *seems* to be that it is
*not* possible. Just because I find certain solutions given to be
impractical for me doesn't mean that I am "willing to do what (I) have
to to get there".

Of course it doesn't. If you _were_ willing then you would go with one of
the solutions that does not require custom drive firmware.

It has become obvious that it isn't possible to have
the options I want, and I conveyed that it should be, and gave the
reasons. And I gave the reasons why the "proposed" solutions would not
work for me. That's all.

What's is so difficult to understand?

It's a good thing that inovative minds are not on "lock-down" like
that minds of many here.

The fact that someone disagrees with you does not mean that his "mind is on
lock-down". It may mean that he has seen the feature you want come and go
in the market without anybody to speak of wanting it.

 

[David Maynard]

No that wouldn't be the reason I'm shutting it down. You're missing
the whole point. I'm conveying inherent software(OS) limitations that
shouldn't exist. My first system had the OS on all three drives. But
thanks to the way software is written, if my "C" drive went down, I
still wouldn't be able to use my other drives without major changes to
my system first.

I have no idea what you mean by 'unable' to 'use' your 'other drives' but
if you mean the system not operating with a third of the OS missing from,
as you put it, the C: drive going down then that is a big "well, Duh." Not
to mention I can't figure out what the heck that has to do with
'quarantining' drives.

Again, you are missing the point. Re-read the above posts. You're
repeating what has already been said. And it's not in line with my
goal.(Achievable or not).




That made no sense whatsoever. Again, re-read the above posts. I
already gave the reasons why that wasn't an option.




You are incorrect. The reasons are amazingly obvious, and have already
been mentioned here.




Sigh... Wrong. THis isn't about a "proposed solution". I indicated
what I wanted to do and why.(Re-read the post that started this
thread). The posters in this thread only had to say it is *not*
possible.

ie: "One cannot "quarantine" three drives from a fourth, or change
write options on the fly." I've come to this conclusion myself based
on what was said.

I did read your originals and don't recall this new 'criteria' about the OS
spread over three drives, which would make 'quarantining' them rather
unworkable to begin with.

Frankly, I think you just want to 'complain' that operating systems aren't
made the way you think they should be and are artificially manufacturing
'requirements' to suit your preconceived 'solution' rather than seeking
workable ones. But since you've decided 'it' is, whatever 'it' is now,
impossible I'll leave it at that.