LinuxLEO Website an...
 
Notifications
Clear all

LinuxLEO Website and Training Materials - Updated

8 Posts
5 Users
0 Likes
1,259 Views
(@bgrundy)
Posts: 70
Trusted Member
Topic starter
 

For those that might be interested, the guidebook and materials at www.linuxleo.com have been updated. The guide is still a beginners guide…this is not "sequel". I've started teaching again and so it was time for a refresh. Much of the material remains the same (still works), but a lot has been added, and commands and output updated as needed. The guide went from ~190 pages to just over 300 pages.

There's also a YouTube channel (empty for now…subscribe for notifications) that will mostly be used for demo videos and related stuff. Comments are welcome at bgrundy@linuxleo.com.

Thanks,
Barry

 
Posted : 12/09/2017 1:57 pm
(@thefuf)
Posts: 262
Reputable Member
 

Thank you! Nice update!

On page 93 you write Keep in mind our previous discussion regarding write blocking. But the discussion starts later on the same page, so there is a next discussion, not a previous one.

Also, teaching examiners to trust hardware write blockers more than software ones is a bad practice (in my opinion). Some hardware write blockers run Linux too. And there are issues too (and a simple act of attaching a suspect drive to a hardware write blocker may result in write requests being sent to that drive).

 
Posted : 12/09/2017 8:42 pm
(@ganron)
Posts: 16
Active Member
 

wow thanks…back in 2008, it helped me prepare for SANS GCFA. )

 
Posted : 14/09/2017 4:19 pm
binarybod
(@binarybod)
Posts: 272
Reputable Member
 

Also, teaching examiners to trust hardware write blockers more than software ones is a bad practice (in my opinion). Some hardware write blockers run Linux too. And there are issues too (and a simple act of attaching a suspect drive to a hardware write blocker may result in write requests being sent to that drive).

In truth, neither are 100% safe but I would opt for hardware blockers.

With software blocking you are at the mercy of kernel code and library writers who's first priority is to ensure the disk & file system drivers actually work. Ensuring nothing is written back to the disk comes some way down their priority list.

At least with a hardware blocker the company making them has a reputational stake in the process. I once went to a demonstration by a hardware blocker manufacturer and was heartened by them admitting that they sometimes get it (accidentally) wrong, for example, when the chip manufacturers change the API allowing undocumented write-backs. In this example the write-blocker manufacturer was made aware (quite quickly) by their users and issued a patch forthwith.

I am not aware of any hardware write blocker that uses Linux or any other OS as a background system (incidentally, wouldn't that make it a 'software' blocker?), there is no need to mount the filesystem at all, I would soon ditch it if it did. All that is needed is a chip (or number of chips) that allow all read operations and disallow ANY writebacks.

Bottom line - both have to be taken on faith unless you have lots of expensive equipment to PROVE that under all circumstances there are no writebacks. I used hardware writeblockers for many years without any problem. I used software write blocking too when I had to, though I had less success with this (mainly due to having occasional fat fingers and/or being slow of thought wink ).

 
Posted : 24/09/2017 6:11 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I am not aware of any hardware write blocker that uses Linux or any other OS as a background system (incidentally, wouldn't that make it a 'software' blocker?), there is no need to mount the filesystem at all, I would soon ditch it if it did. All that is needed is a chip (or number of chips) that allow all read operations and disallow ANY writebacks.

Strictly speaking, if the "hardware" write blocker has a "firmware" (i.e. it can - one way or the other - be "patched" or "updated"), it is a "software" write blocker anyway.

jaclaz

 
Posted : 24/09/2017 6:43 pm
(@thefuf)
Posts: 262
Reputable Member
 

Strictly speaking, if the "hardware" write blocker has a "firmware" (i.e. it can - one way or the other - be "patched" or "updated"), it is a "software" write blocker anyway.

It is possible to create a simple IDE-to-IDE write blocker without firmware (using an FPGA).

 
Posted : 24/09/2017 7:35 pm
(@thefuf)
Posts: 262
Reputable Member
 

In truth, neither are 100% safe but I would opt for hardware blockers.

With software blocking you are at the mercy of kernel code and library writers who's first priority is to ensure the disk & file system drivers actually work. Ensuring nothing is written back to the disk comes some way down their priority list.

This is why the write blocking functionality should be implemented in a single spot somewhere in a kernel.

At least with a hardware blocker the company making them has a reputational stake in the process.

Reputation should never replace validation.

I once went to a demonstration by a hardware blocker manufacturer and was heartened by them admitting that they sometimes get it (accidentally) wrong, for example, when the chip manufacturers change the API allowing undocumented write-backs. In this example the write-blocker manufacturer was made aware (quite quickly) by their users and issued a patch forthwith.

The explanation mentioning API changes is really odd. If a hardware write blocker is implemented on top of a microcontroller, then there should be modified (custom) firmware created using the original one provided by the vendor of the microcontroller. For example, a Tableau T35u write blocker is using an ARM Cortex M3 microcontroller from Texas Instruments, its firmware is based on what Texas Instruments provides to customers. If things change in the original firmware, developers from Guidance Software should notice that in the vendor's source code before they start distributing an update of customized write blocking firmware. If they don't, well, there is no valid reason to blame the API change. Also, what API?

I am not aware of any hardware write blocker that uses Linux or any other OS as a background system (incidentally, wouldn't that make it a 'software' blocker?), there is no need to mount the filesystem at all, I would soon ditch it if it did. All that is needed is a chip (or number of chips) that allow all read operations and disallow ANY writebacks.

Tableau TD3 & TX1 devices are running Linux (these are forensic duplicators, but both are capable of acting as a network-based write blocker, and both have "write blocked" ports).

Tableau T356789iu devices are running Linux (this model is a pure write blocker).

Bottom line - both have to be taken on faith unless you have lots of expensive equipment to PROVE that under all circumstances there are no writebacks. I used hardware writeblockers for many years without any problem. I used software write blocking too when I had to, though I had less success with this (mainly due to having occasional fat fingers and/or being slow of thought wink ).

And I saw a Tableau TD3 device writing to a drive attached to a "write blocked" port. Also, I saw a Tableau T356789iu device blocking perfectly legal and usual read requests. A "reputational stake" is pretty bad here (but things may change since I found my software write blocking patch implemented in Tableau TX1 D ).

 
Posted : 24/09/2017 8:40 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

It is possible to create a simple IDE-to-IDE write blocker without firmware (using an FPGA).

Sure, and that is probably the "last" actually hardware writeblocker.

More or less "parallel" allowed that, "serial" not so much.

Though, just as an example, the Read Only version of this adapter is declared to be "hardware only"
http//www.addonics.com/products/adsau31r.php

WRITE PROTECT version, model ADSAU31R-WP

All features are identical as the standard version except the WRITE function is disabled. This unique feature ensures absolute protection on any hard drive or SSD against virus contamination or data tampering. It is a great tool for sharing drives containing important data among different users or for forensic application. Drives connecting to this bridge appears as a READ only media, similar to CD or DVD disc.

  • Same features as the standard version except READ only
  • Protect drive against virus contamination or data tempering
  • WRITE disabled at hardware level. No software hacking to circumvent the WRITE PROTECT function
  • No volatile memory
  • Drive appears to OS as READ only device. Options to format, delete and others that alter the content or structure of the drive are all disabled by the OS

I suspect that it instead contains some unmodifiable firmware. ?

And - but this has nothing to do with the writeblocker and its software or hardware nature - modern (last 10-15 years) storage devices are way too "smart" for a writeblocker to be really-really 100% effective anyway.

It will never happen, of course, but in theory nothing prevents from reprogramming the disk (or SSD or flash) controller to behave differently from what is expected, and possibly even to detect the presence of a write blocker.

jaclaz

 
Posted : 25/09/2017 8:59 am
Share: