IT Forensics · Linux
Write protection and write blockers in Linux backups
The use of appropriate write-protection measures is one of the most fundamental requirements for a proper forensic backup, in order to reliably prevent any alteration of the original evidence during the backup process.
This point is particularly important for Linux systems, as distributions, kernel versions, memory architectures and security mechanisms can vary significantly. A standard Debian system, a containerised Kubernetes node and an embedded system must not be treated according to the same technical approach. The file system, encryption, runtime environment and the respective system state determine which data is accessible and which backup method causes the least disruption.
Under Linux, both dedicated hardware write-blockers and software-based read-only mounting mechanisms are available for this purpose; their correct use is crucial to ensuring that the backup can be utilised later.
Why LanCologne?
LanCologne does not examine Linux systems according to a blanket, standardised approach, but rather on the basis of the specific hardware, distribution and security architecture. Our staff have decades of experience in information technology and many years of practical experience in IT forensics. We assist companies, solicitors and private individuals, as well as regularly supporting courts and public authorities, in the technical investigation of digital matters.
The investigation is generally carried out on a forensic copy, a forensic image or a data source captured in a technically equivalent manner that preserves the integrity of the evidence. The original evidence is either left unchanged or, where technically unavoidable alterations have been made, these are transparently documented and the evidence is stored in a manner that preserves its integrity.
Our working methods and the tools we use
Our investigation does not begin by launching an analysis programme, but by gathering evidence. The system, hardware, network connection, visible operational status and existing peripherals are documented. A decision is then made as to whether the system must remain switched off, whether live data capture is advisable, or whether offline access via a forensic recovery system is technically justifiable.
The next step is to define the backup strategy. In doing so, we distinguish between block-oriented mapping, logical backups and targeted triage. The choice depends not on convenience, but on storage architecture, encryption, system availability and the specific issue to be proven. Where technically feasible, we work in read-only mode. Unavoidable changes in state during live data capture are explicitly logged.
The backup created is documented using hash values. The actual analysis is not carried out on the original, but on a working copy or a verified proof image. This allows parsers, searches or custom utilities to be used without continuously altering the original evidence.
For every backup, we consistently implement appropriate write-protection measures, choosing between dedicated hardware and write-protected software mechanisms depending on the situation, and document their use as an integral part of our backup protocols.
For a reader unfamiliar with the subject, one point is particularly important: a forensic programme does not automatically „find" the truth. It reads data structures and interprets them according to known rules. If a new kernel or distribution version changes a log format or a data structure, a parser may respond incompletely or incorrectly. That is why, in the case of crucial findings, we check which file, database or file system structure the result originates from and whether a second technical approach confirms the same findings.
That is also why we use several tools. The Sleuth Kit and Autopsy can analyse Linux file systems natively and are open-source; Belkasoft X offers a different perspective on artefacts and correlations; X-Ways enables highly detailed file system and raw data examinations. If independent analyses agree, this increases the robustness of the findings. If they do not agree, the cause is investigated rather than simply selecting the most convenient match.
Typical areas of application
This is how the forensic investigation is carried out
The Linux system is first clearly identified and documented either photographically or in writing. We note whether it is switched on or off, logged in, locked, or connected to external storage devices or networks. This information may prove crucial later on.
The distribution, kernel version, file system, encryption and relevant security mechanisms are identified. Only then can the appropriate collection method be determined.
The backup method is chosen so that as little as possible is altered on the original. Depending on the circumstances, options include a block-level image created using a forensic recovery system, a live capture of the running system, or a targeted selection of individual directories. Every step is logged.
Images or logical backups that are created are given unique names, assigned hash values and verified. Analysis and search operations are then carried out on working copies.
The Sleuth Kit, Autopsy, Belkasoft X and X-Ways are combined depending on the specific task. Where possible, key results are not derived from a single parser view alone.
If a piece of evidence is particularly relevant, unusual or only partially supported by standard software, we manually examine raw data, database structures, log files or file system information. Where necessary, we use our own tools.
In the end, we do more than simply list the results displayed by a tool. We explain the technical basis for the findings, what conclusions can be drawn, and where the limitations lie.
Why is this area of investigation relevant to forensics?
The use of appropriate write-protection measures is one of the most fundamental requirements for a proper forensic backup, in order to reliably prevent any alteration of the original evidence during the backup process.
The forensic value lies not solely in the volume of data found, but in its origin and reliability. A file name, a timestamp or a log entry can be misleading without context. That is why we document how an artefact may have come into being, what alternative explanations exist and what further evidence supports the findings.
Under Linux, both dedicated hardware write-blockers and software-based read-only mounting mechanisms are available for this purpose; their correct use is crucial to ensuring that the backup can be utilised later.
On modern Linux systems in particular, attempts at „traditional" disk forensics may also fail due to technical limitations. Encryption, containerisation, volatile memory and dynamic configurations highlight why it is so important to carry out a proper backup before the actual analysis begins. Errors made at this stage cannot always be reversed later on.
Frequently Asked Questions
LanCologne – Linux Forensics Cologne
Do you require a professional investigation into „write protection and write blockers in Linux backups"? LanCologne supports you in carrying out evidence-secure backups, multi-stage analysis and traceable documentation. The key here is not to generate as many automatic hits as possible, but to secure technically sound and verifiable evidence.