On Friday night, I spent my time until 4 am in the morning to perform a forensically sound experiments under Ubuntu machine. These experiments are actually revision form of previous experiments carried out a few weeks ago concerning 'Write Protect'. In the previous experiments, I could make the USB port to be fully protected by reconfiguring files of /etc/mtab and /etc/fstab, but I still feel unsatisfied with those experiments because I did it manually for write protection, not automatically. It does not meet the forensics needs, therefore last night I undertook these revised experiments. Experiments Preparation I used my 4GB flashdisk as the object of these experiments. I set up it by using GParted, so that it has 4 partitions with different file system. Below is the specifications of each partition with the operating system installed within it by using Unetbootin.
Partition 1 996.19 MB ntfs Partition 2 996.22 MB fat16 BartPE Partition 3 996.19 MB ext2 Helix 3.0 Partition 4 847.15 MB ext3 Ubuntu 8.10
Particularly for partition 1, there is no OS installed in it because it is designed for storing files. This configuration is intended to make a condition of flashdisk becomes closely similar with a real harddisk having some partitions with different file systems.
fstab Configuration
Before configuring /etc/fstab, firstly I made some subdirectories in directory /media as mounting points of flashdisk when it is attached to the experimental machine. In /media, there are 7 new subdirectories, namely :
/media/sdb1ro /media/sdb2ro /media/sdb3ro /media/sdb4ro /media/sdb5ro /media/sdb6ro /media/sdb7ro
The reason why the number of new subdirectories are 7 is in order to cover the number of partitions in one harddisk. it usually has 2 to 4 partitions. fstab containing descriptive static information about the file systems is only read by programs, and not written. Each line describing file system on separated partition comprises 6 fields, namely file system, mount point, type, options, dump and pass. Below is revised configuration in /etc/fstab which is edited using Text Editor./dev/sdb1 /media/sdb1ro auto noauto,user,ro,nosuid,nodev,uhelper=hal 0 0
/dev/sdb2 to /dev/sdb7 have same configuration as /dev/sdb1, except mount point, for instance /dev/sdb2 has /media/sdb2ro as location of mounting. Below is the explanation of selected configuration quoted from manual pages of mount and umount.
auto : mount will try to guess the desired type of file system. noauto : it can only be mounted explicitly. user : only the user that mounted a file system can umount it again. ro : mount the file system read only nosuid : do not allow set-user-identifier or set-group-identifier bits to take effect. nodev : do not interpret character or block special devices on the file system. uhelper=hal : The uhelper (unprivileged umount helper) is possible to used when non-root user wants to umount a mountpoint which is not defined in the /etc/fstab file (e.g devices mounted by HAL). After this configuration finished, it was saved in /etc/fstab. Comparative Analysis I plugged in the 4 GB flashdisk above into my experimental machine having reconfigured fstab, the I mounted it over command console, then run md5sum to check hash value of each partition. Below is the first result : /dev/sdb1 94bb79d86726636c015df89e274df644 /dev/sdb2 9077f2c533bb50992bd0828b7f56d7c0 /dev/sdb5 b665c813c2db0aaca3c20cfa38a30023 /dev/sdb6 0578121443c16b0721857a19441d2da0 /dev/sdb5 and /dev/sdb6 refer to partition 3 and 4 because both partitions are logical. On each partition, I run file browser to access it and also opened some files, after that I calculated again the md5 value of each partition. Below is the second result : /dev/sdb1 94bb79d86726636c015df89e274df644 /dev/sdb2 9077f2c533bb50992bd0828b7f56d7c0 /dev/sdb5 b665c813c2db0aaca3c20cfa38a30023 /dev/sdb6 0578121443c16b0721857a19441d2da0 md5 value from the first result is same as the second, it means that the reconfigured fstab works well for forensically sound write protect which is automatically set when a removable media attached to the machine at the first time. After that I unmounted the flashdisk and plugged it out. Checking the Changes I disabled all configurations of write protect in fstab. I recover fstab back to the original state with automount and read-write This was carried out in order to gain the understandings on how far the changes occur in a removable media when it is plugged in to a machine. I attached the flashdisk again to the machine, then directly I calculated md5 value for each. Below is the third result : /dev/sdb1 94bb79d86726636c015df89e274df644 /dev/sdb2 9077f2c533bb50992bd0828b7f56d7c0 /dev/sdb5 9fffeaa755ebf36ef6285fb3272ed420 /dev/sdb6 db2b32be1a9d5de156787241f2413c5d I found that md5 value of sdb1 and sdb2 remain the same, but sdb5 and sdb6 have changed without accessing it at all. On each partition, I accessed it by using file browser twice without opening or accessing files, then I run md5sum to check the hash value. Below is the forth result : /dev/sdb1 94bb79d86726636c015df89e274df644 /dev/sdb2 9077f2c533bb50992bd0828b7f56d7c0 /dev/sdb5 eb891ff58ad46540758cada117cb4983 /dev/sdb6 2043eaa09cc47b1f0743584151b87316 I noticed that sdb1 with ntfs and sdb2 with fat16 are still unchanged on md5 value, but sdb5 with ext2 and sdb6 with ext3 experienced changed because of being accessed via file browser. Conclusion It is too risky running acquisition of a removable media via usb port of an analysis machine without reconfiguring fstab because the original state of fstab allows changes on removable media when it is attached at the first time. If this is still performed, so the acquisition for forensics imaging is questionable and doubt. This can affect the next steps of forensics analysis. To avoid this, I suggest to reconfigure /etc/fstab as explained above because so far, it is fully protection from the first time a removable media attached via usb port, therefore it fits with forensically sound write protect. Acknowledgement I dedicate these experiments to my group of investigation phase (i.e. Piotrek and David) of 'CS937-Crime Scene and Court Exercise' and Phil Murray who show me a good effort and valuable discussion to develop computer forensic investigation. I hope these experiments could be accepted. I am also opened to receive any comments. Anyway I apologise with this long email consisting over 1000 words. However it is not counted as an essay..hehehe. I hope you could not feel bored reading this email.
From the description above, the experiment of 'forensically sound write protect' on Ubuntu is essential for forensic investigators to apply in order to avoid changes which might happen accidentally. Reconfiguring fstab file for this purpose is reliable to keep the contents of a storage medium. With this technique, they become more flexible to analyse any computers without worrying to make accidental changes.
No comments:
Post a Comment