When it comes to Linux, one of the things that sets it apart from other operating systems is the sheer variety of available filesystems. This flexibility can be great for users and administrators, but it can pose significant challenges for Digital Forensics and Incident Response (DFIR) teams.
Defaults and Common Filesystems
Although there are many different filesystems in Linux, defaults exist for most distributions, simplifying things for responders. Here are the most common filesystems you'll encounter:
EXT3: This is an older filesystem that's largely been replaced but can still be found in older appliances like firewalls, routers, and legacy systems.
EXT4: The current go-to for most Debian-based systems (e.g., Ubuntu). It's an updated version of EXT3 with improvements like better journaling and performance.
XFS: Preferred by CentOS, RHEL, and Amazon Linux. It’s known for its scalability and defragmentation capabilities. It's commonly used in enterprise environments and cloud platforms.
Notable mentions
Btrfs, used by Fedora and OpenSUSE
ZFS, which is specialized for massive storage arrays and servers.
Challenges in Linux Filesystem Forensics
Inconsistencies Across Filesystems
Each Linux filesystem has its quirks, which can make forensic analysis more difficult. EXT3 might present data in one way, while XFS handles things differently. Appliances running Linux (like firewalls and routers) often complicate things further by using outdated filesystems or custom configurations.
The Problem of LVM2
Logical Volume Manager (LVM2) is commonly used in Linux environments to create single logical volumes from multiple disks or partitions. While this is great for flexibility and storage management, it’s a pain for forensic investigators. Many tools (both commercial and open-source) struggle to interpret LVM2 structures, especially in virtual environments like VMware, where VMDK files are used. The best approach? Get a full disk image rather than relying on snapshots.
Timestamps Aren't Always Reliable
Timestamps in Linux, especially on older filesystems like EXT3, aren’t as granular as those in NTFS. EXT3 timestamps are accurate only to the second, while EXT4 and XFS provide nanosecond accuracy. Furthermore, modifying timestamps in Linux is trivial, thanks to the touch command.
Example:- malicious actor could use touch -a -m -t 202101010000 filename to make a file appear as though it was created on January 1, 2021.
Always double-check timestamps, and consider using inode sequence numbers to validate whether they’ve been tampered with.
Tooling Support Gaps
DFIR tools vary in their support for different Linux filesystems. Free tools like The Sleuth Kit and Autopsy often support EXT3 and EXT4 but struggle with XFS, Btrfs, and ZFS. Commercial tools may also fall short in analyzing these filesystems, though tools like FTK or X-Ways provide better support. When all else fails, mounting the filesystem in Linux (using SIFT, for example) and manually examining it can be a reliable workaround.
How to Identify the Filesystem Type
If you have access to the live system, determining the filesystem is relatively simple:
lsblk -f: This command shows an easy-to-read table of filesystems, partitions, and mount points. It’s particularly helpful for identifying root and boot partitions on CentOS systems (which will often use XFS).
df -Th: This provides disk usage information along with filesystem types. However, it can be noisy, especially if Docker is installed.
Because if this instead of above command use:
lsblk -f
For deadbox forensics, you have options like:
cat /etc/fstab: This command shows the filesystem table, useful for both live and mounted systems.
fsstat: Part of The Sleuth Kit, this command helps determine the filesystem of an unmounted image.
File System in Detail:
The EXT3 Filesystem
Released in 2001, EXT3 was a major step up from EXT2 due to its support for journaling, which improves error recovery. EXT3 offers three journaling modes:
Journal: This logs both metadata and file data to the journal, making it the most fault-tolerant mode.
Ordered: Only metadata is journaled, while file data is written to disk before metadata is updated.
Writeback: The least safe but most performance-oriented mode, as metadata can be updated before file data is written.
One downside to EXT3 is that recovering deleted files can be tricky. Unlike EXT2, where deleted files might be recoverable by locating inode pointers, EXT3 wipes these pointers upon deletion. Specialized tools like fib, foremost, or frib are often required for recovery.
The EXT4 Filesystem
EXT4, the evolution of EXT3, became the default filesystem for many Linux distributions starting around 2008. It introduced several improvements:
Journaling with checksums: Ensures the integrity of data in the journal.
Delayed allocation: Reduces fragmentation by waiting to allocate blocks until the file is ready to be written to disk. While this improves performance, it also creates the risk of data loss.
Improved timestamps: EXT4 provides nanosecond accuracy, supports creation timestamps (crtime), and can handle dates up to the year 2446. However, not all tools (especially older ones) are capable of reading these creation timestamps.
File recovery on EXT4 is difficult due to the use of extents (groups of contiguous blocks) rather than block pointers. Once a file is deleted, its extent is zeroed, making recovery nearly impossible without file carving tools like foremost or photorec.
The XFS Filesystem
Originally developed in 1993, XFS has made a comeback in recent years, becoming the default filesystem for many RHEL-based distributions. XFS is well-suited for cloud platforms and large-scale environments due to features like:
Defragmentation: XFS can defragment while the system is running.
Dynamic disk resizing: It allows resizing of partitions without unmounting.
Delayed allocation: Similar to EXT4, this helps reduce fragmentation but introduces some risk of data loss.
One challenge with XFS is the limited support among DFIR tools. Most free and even some commercial tools struggle with XFS, although Linux-based environments like SIFT can easily mount and examine it. File recovery on XFS is also challenging, requiring file carving or string searching.
Dealing with LVM2 in Forensics
LVM2 (Logical Volume Manager) is frequently used in Linux systems to create logical volumes from multiple physical disks or partitions. This can create significant challenges during forensic investigations, especially when dealing with disk images or virtual environments. Some forensic tools can’t interpret LVM2 structures, making it difficult to analyze disk geometry.
The best solution is to carve data directly from a live system or mount the image in a Linux environment (like SIFT). Commercial tools like FTK and X-Ways also offer better support for LVM2 analysis, but gaps in data collection may still occur.
Conclusion:
Linux filesystem forensics requires a broad understanding of multiple filesystems and their quirks. EXT4, XFS, and LVM2 are just a few of the complex technologies that forensic responders must grapple with, and each poses its unique challenges. By knowing the tools, techniques, and limitations of each filesystem, DFIR professionals can navigate this complexity with more confidence.
Akash Patel
Comments