- Email: [email protected]
Deploying forensic tools via PXE
Digital Investigation (2004) 1, 173e176
www.elsevier.com/locate/diin
Deploying forensic tools via PXE Owen O’Connor
KEYWORDS Corporate investigations; Network forensics; Remote forensics; PXE; Network boot; Network deployment
Abstract Corporate investigations often require large numbers of initial examinations to identify relevant systems. Many investigators are turning to bootable Unix CDs such a Knoppix and Helix to assist with such ‘‘screening’’. A method is proposed for the mass deployment of such tools via the ‘‘PXE’’ network boot function, allowing more efficient parallel screening. ª 2004 Elsevier Ltd. All rights reserved.
Background Corporate investigations often involve large numbers of initial examinations in order to identify relevant systems. This ‘‘screening’’ process is often carried out using ‘‘live’’ examination tools such as ‘‘Knoppix’’, ‘‘PSK’’ or ‘‘Helix’’. These are bootable CDs containing stand-alone operating systems which help avoid data modification. Using these tools an investigator can boot subject systems ‘‘as found’’, without the need to open, or even move, each system. Basic checks can then be carried out, such as keyword searches, file hashing, file system analysis or manual data review. Systems shown to be relevant to the investigation can then be removed for further analysis or have their disks imaged to external media. Although these tools are extremely useful, they require each system to be booted and examined in turn. It would be preferable to boot from an external source to ‘‘screen’’ multiple systems in parallel, with the screening process initiated
E-mail address: [email protected].
automatically as each system boots. Since the same checks are performed on each system, this would greatly decrease the time and resources required. In addition, while the majority of systems can boot from such CDs some will not have a functioning CD drive, will fail to read the CD, or will fail to boot from the CD drive. Screening such systems may require examining the system disks from another system e again, the ability to boot from an external source would be preferable.
PXE The PXE network boot function offers a solution to both of these problems. The Pre-Boot Execution Environment is an Intel network boot specification which allows a system to boot from a network server rather than a local disk or removable media. PXE is widely used in system management tools, such as Microsoft’s Remote Installation Services and HP’s Rapid Deployment Pack. PXE has the potential to assist with both issues identified above e the time required for screening and difficulties encountered when booting systems
1742-2876/$ - see front matter ª 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.diin.2004.07.005
174 from CD. PXE allows an investigator to deploy a boot server containing a suitable screening system, such as Knoppix, and initiate a PXE boot from each system to be examined. With advance preparation it is possible to screen all target systems in parallel, without relying on a local CD drive.
PXE requirements For a system to support PXE, both the network card and system BIOS must comply with the specification. Volume shipments of PXE compliant PCs began in 1998 and compliance was mandatory in the ‘‘PC99’’ PC design standard. As a result virtually all PCs now support PXE, along with the majority of notebook PCs and Intel-based servers. Only two network services are required by the PXE specification: DHCP (Dynamic Host Configuration Protocol) and TFTP (Trivial File Transfer Protocol). In practice a network file system is also used to allow an initial boot program to access operating system components from a remote system. The DHCP and TFTP servers required are not specific to PXE e almost any TFTP server and any DHCP server supporting the PXE extensions can be used. The DHCP server must support options 066 and 067, or allow arbitrary DHCP options. When booting via PXE the client broadcasts a DHCP request, to which the DHCP server responds with standard configuration details and the PXE options. Option 066 (‘‘Boot Server Host Name’’) specifies the TFTP server IP address, while option 067 (‘‘Bootfile Name’’) identifies the file to be downloaded and executed.
Knoppix and PXE One PXE boot system is the ‘‘knoppix-terminalserver’’ package supplied with Knoppix, which includes a configuration script for the DHCP and TFTP and NFS servers supplied with Knoppix. It is useful to look at this package as an example PXE system, as the configuration defaults are sufficient to demonstrate a basic setup, and many investigators are familiar with Knoppix. To configure a Knoppix system as a PXE server, the configuration script should be executed as ‘‘/etc/init.d/knoppix-terminalserver’’. A series of menus will prompt for the PXE configuration: network interfaces to be used, IP range to be assigned, client network adapters to be supported, additional server options and client configuration options.
O. O’Connor The default options presented by the configuration script are sufficient for a basic demonstration, although the additional server options (‘‘secure’’, ‘‘masq’’, ‘‘dns’’, ‘‘squid’’) are not needed. For examination purposes additional client options will need to be set, such as ‘‘noswap’’ to disable the automatic use of any existing Linux swap partitions. A typical set of client options might be ‘‘noswap 2 lang Z uk’’, to boot Knoppix to runlevel 2 (command-line) with a UK keymap, preventing swap usage. After client options have been selected the configuration script will start the required services and the system will be ready to service PXE clients.
Knoppix configuration An additional client option that may be required is ‘‘myconf’’ which is used to specify the location of a Knoppix configuration file. Setting an option of ‘‘myconf Z scan’’ will cause clients to search for a configuration file named ‘‘knoppix.sh’’, which will be executed at startup. Although it is difficult to deploy such a file using an original Knoppix CD, the standard CD image (ISO) could be modified to include such a file. As an alternative to producing custom CDs, a hard disk installation of Knoppix could be performed on the investigator’s system, allowing modifications as required. It can be useful to perform this installation to a VMWare virtual disk, thus allowing the investigators to run their standard operating system alongside a full installation of Knoppix. In addition to reconfiguring Knoppix, the ‘‘knoppix.sh’’ file can be used to execute commands. These might include automated tasks such as keyword or file system searches, the generation of file hash lists, examination of file systems or extraction of selected data. When dealing with multiple systems it can be useful to enable the SSH server and redirect the output of these tasks to files. These files can then be monitored remotely via SSH, allowing parallel screening with real-time monitoring.
DHCP issues While the above configuration is sufficient for many purposes, it is not appropriate for the average corporate network. The use of a DHCP server on the PXE host will generally be unacceptable, as it is likely to conflict with an existing DHCP server. Introducing the investigator’s Knoppix PXE server may cause clients, other than those being screened, to receive network details from the Knoppix server, causing service disruption.
Deploying forensic tools via PXE One way to avoid this DHCP conflict is to perform the PXE boot on a separate network, cut off from the corporate network e e.g., to connect all systems to be screened to a separate network with access only to the PXE server. This will ensure that no conflict occurs but requires additional time to disconnect and reconnect each system. A less time-consuming approach is to isolate the systems under investigation from the rest of the network. On many corporate networks this may be relatively simple e e.g., where a single room or floor of a building is being screened it may be possible to disconnect the relevant network switches. The systems to be screened can then be booted from the Knoppix PXE server and, once all clients have booted, the Knoppix DHCP service can be stopped. The examination can then be performed with the network segment connected to the corporate network as before. A more useful approach, perhaps the most flexible, is to avoid using the Knoppix DHCP server entirely. Since virtually any DHCP server can be used, an existing server can be modified to refer PXE clients to a Knoppix server. The Windows 2000 DHCP server can be configured via the ‘‘DHCP’’ tool, accessible via CStart/ Programs/Administrative Tools/DHCPD, or as ‘‘dhcpmgmt.msc’’. Each DHCP scope on the server has an associated ‘‘Scope Options’’ configuration, where the 066 and 067 options can be set. These options are supported by default and need only to be enabled and configured. The ‘‘DHCP server’’ service does not need to be restarted, changes will be reflected in the next DHCP lease. To re-configure an ISC DHCP server it is necessary to edit the dhcpd configuration file, usually ‘‘/etc/dhcpd.conf’’. The 066 and 067 options are set by adding values of ‘‘next-server’’ for 066 and ‘‘filename’’ for 067. The exact means of adding these options is dependent on the structure of the existing configuration file. The configuration file must be reloaded or the service restarted after the options have been set. In both cases the 066 option must be set to the IP address of the PXE server, and the 067 option to ‘‘pxelinux.0’’, the filename used by the ‘‘knoppixterminalserver’’ package. These changes will not affect other clients and can be left in place until the screening process is complete.
A note on Knoppix Although Knoppix is presented here as an example, this should not be taken as an absolute endorsement, as the base Knoppix operating system (OS)
175 may not be suitable for all purposes. The ‘‘readonly’’ functionality of Knoppix relies on support in multiple OS layers, including disk and file system drivers, operating system commands, standard Unix utilities and other supplied tools. In many cases the ‘‘read-only’’ functionality is flawed and cannot be relied on in all cases. One such Knoppix issue has already been discovered, namely the fact that mounting certain journaling file systems will result in a file system write, even when the read-only option is passed to the ‘‘mount’’ command. This specific issue has been documented in detail by Ernie Baca in his paper ‘‘KNOPPIX Bootable CD Validation Study for Live Forensic Preview of Suspects Computer’’. Although workarounds for the above issue exist, it serves to demonstrate the potential issues. Since forensic examination is not a core function of Knoppix, similar workarounds may be discovered in future. In particular it is possible that future changes might impact the ‘‘read-only’’ functionality in an unpredictable, and potentially undocumented, fashion. For this and other reasons it would be preferable to adapt these PXE deployment techniques to a similar system intended for forensic examination, e.g., PSK or Helix.
Other scenarios In addition to the ‘‘screening’’ example presented, a PXE boot system such as Knoppix is useful in many other scenarios. One of the most promising scenarios is the use of PXE to provide an incident-based investigative capability. Since normal DHCP clients are unaffected by the additional PXE options, the DHCP options and Knoppix PXE server could be left in place, with clients simply booted via PXE when an examination is needed. Outside of investigations the Knoppix PXE system has many other potential uses in a corporate environment. Non-investigative searches could be carried out with ease, such as those required for electronic discovery, Data Protection subject access requests or to ensure compliance with data retention policies. Incident response efforts could benefit from the same techniques, for example in checking for compromised systems which might otherwise be undetectable. Basic data recovery may even be possible, such as restoring files deleted by malicious software. Most importantly, all these tasks can be carried out in parallel on multiple systems.
176
References Helix. !http://www.e-fense.com/helix/O. Knoppix. !http://www.knoppix.org/O. PC99 spec. !http://www.microsoft.com/whdc/system/platform/ pcdesign/desguide/pcguides.mspxO. PXE spec. !ftp://download.intel.com/labs/manage/wfm/download/ pxespec.pdfO.
O. O’Connor Owen O’Connor is a private sector security professional based in Ireland, where he specialises in computer forensics and incident response. He is an MSc student at the Royal Military College of Science and is the founder and Vice President of the Irish chapter of the Information Systems Security Association.
www.elsevier.com/locate/diin
Deploying forensic tools via PXE Owen O’Connor
KEYWORDS Corporate investigations; Network forensics; Remote forensics; PXE; Network boot; Network deployment
Abstract Corporate investigations often require large numbers of initial examinations to identify relevant systems. Many investigators are turning to bootable Unix CDs such a Knoppix and Helix to assist with such ‘‘screening’’. A method is proposed for the mass deployment of such tools via the ‘‘PXE’’ network boot function, allowing more efficient parallel screening. ª 2004 Elsevier Ltd. All rights reserved.
Background Corporate investigations often involve large numbers of initial examinations in order to identify relevant systems. This ‘‘screening’’ process is often carried out using ‘‘live’’ examination tools such as ‘‘Knoppix’’, ‘‘PSK’’ or ‘‘Helix’’. These are bootable CDs containing stand-alone operating systems which help avoid data modification. Using these tools an investigator can boot subject systems ‘‘as found’’, without the need to open, or even move, each system. Basic checks can then be carried out, such as keyword searches, file hashing, file system analysis or manual data review. Systems shown to be relevant to the investigation can then be removed for further analysis or have their disks imaged to external media. Although these tools are extremely useful, they require each system to be booted and examined in turn. It would be preferable to boot from an external source to ‘‘screen’’ multiple systems in parallel, with the screening process initiated
E-mail address: [email protected].
automatically as each system boots. Since the same checks are performed on each system, this would greatly decrease the time and resources required. In addition, while the majority of systems can boot from such CDs some will not have a functioning CD drive, will fail to read the CD, or will fail to boot from the CD drive. Screening such systems may require examining the system disks from another system e again, the ability to boot from an external source would be preferable.
PXE The PXE network boot function offers a solution to both of these problems. The Pre-Boot Execution Environment is an Intel network boot specification which allows a system to boot from a network server rather than a local disk or removable media. PXE is widely used in system management tools, such as Microsoft’s Remote Installation Services and HP’s Rapid Deployment Pack. PXE has the potential to assist with both issues identified above e the time required for screening and difficulties encountered when booting systems
1742-2876/$ - see front matter ª 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.diin.2004.07.005
174 from CD. PXE allows an investigator to deploy a boot server containing a suitable screening system, such as Knoppix, and initiate a PXE boot from each system to be examined. With advance preparation it is possible to screen all target systems in parallel, without relying on a local CD drive.
PXE requirements For a system to support PXE, both the network card and system BIOS must comply with the specification. Volume shipments of PXE compliant PCs began in 1998 and compliance was mandatory in the ‘‘PC99’’ PC design standard. As a result virtually all PCs now support PXE, along with the majority of notebook PCs and Intel-based servers. Only two network services are required by the PXE specification: DHCP (Dynamic Host Configuration Protocol) and TFTP (Trivial File Transfer Protocol). In practice a network file system is also used to allow an initial boot program to access operating system components from a remote system. The DHCP and TFTP servers required are not specific to PXE e almost any TFTP server and any DHCP server supporting the PXE extensions can be used. The DHCP server must support options 066 and 067, or allow arbitrary DHCP options. When booting via PXE the client broadcasts a DHCP request, to which the DHCP server responds with standard configuration details and the PXE options. Option 066 (‘‘Boot Server Host Name’’) specifies the TFTP server IP address, while option 067 (‘‘Bootfile Name’’) identifies the file to be downloaded and executed.
Knoppix and PXE One PXE boot system is the ‘‘knoppix-terminalserver’’ package supplied with Knoppix, which includes a configuration script for the DHCP and TFTP and NFS servers supplied with Knoppix. It is useful to look at this package as an example PXE system, as the configuration defaults are sufficient to demonstrate a basic setup, and many investigators are familiar with Knoppix. To configure a Knoppix system as a PXE server, the configuration script should be executed as ‘‘/etc/init.d/knoppix-terminalserver’’. A series of menus will prompt for the PXE configuration: network interfaces to be used, IP range to be assigned, client network adapters to be supported, additional server options and client configuration options.
O. O’Connor The default options presented by the configuration script are sufficient for a basic demonstration, although the additional server options (‘‘secure’’, ‘‘masq’’, ‘‘dns’’, ‘‘squid’’) are not needed. For examination purposes additional client options will need to be set, such as ‘‘noswap’’ to disable the automatic use of any existing Linux swap partitions. A typical set of client options might be ‘‘noswap 2 lang Z uk’’, to boot Knoppix to runlevel 2 (command-line) with a UK keymap, preventing swap usage. After client options have been selected the configuration script will start the required services and the system will be ready to service PXE clients.
Knoppix configuration An additional client option that may be required is ‘‘myconf’’ which is used to specify the location of a Knoppix configuration file. Setting an option of ‘‘myconf Z scan’’ will cause clients to search for a configuration file named ‘‘knoppix.sh’’, which will be executed at startup. Although it is difficult to deploy such a file using an original Knoppix CD, the standard CD image (ISO) could be modified to include such a file. As an alternative to producing custom CDs, a hard disk installation of Knoppix could be performed on the investigator’s system, allowing modifications as required. It can be useful to perform this installation to a VMWare virtual disk, thus allowing the investigators to run their standard operating system alongside a full installation of Knoppix. In addition to reconfiguring Knoppix, the ‘‘knoppix.sh’’ file can be used to execute commands. These might include automated tasks such as keyword or file system searches, the generation of file hash lists, examination of file systems or extraction of selected data. When dealing with multiple systems it can be useful to enable the SSH server and redirect the output of these tasks to files. These files can then be monitored remotely via SSH, allowing parallel screening with real-time monitoring.
DHCP issues While the above configuration is sufficient for many purposes, it is not appropriate for the average corporate network. The use of a DHCP server on the PXE host will generally be unacceptable, as it is likely to conflict with an existing DHCP server. Introducing the investigator’s Knoppix PXE server may cause clients, other than those being screened, to receive network details from the Knoppix server, causing service disruption.
Deploying forensic tools via PXE One way to avoid this DHCP conflict is to perform the PXE boot on a separate network, cut off from the corporate network e e.g., to connect all systems to be screened to a separate network with access only to the PXE server. This will ensure that no conflict occurs but requires additional time to disconnect and reconnect each system. A less time-consuming approach is to isolate the systems under investigation from the rest of the network. On many corporate networks this may be relatively simple e e.g., where a single room or floor of a building is being screened it may be possible to disconnect the relevant network switches. The systems to be screened can then be booted from the Knoppix PXE server and, once all clients have booted, the Knoppix DHCP service can be stopped. The examination can then be performed with the network segment connected to the corporate network as before. A more useful approach, perhaps the most flexible, is to avoid using the Knoppix DHCP server entirely. Since virtually any DHCP server can be used, an existing server can be modified to refer PXE clients to a Knoppix server. The Windows 2000 DHCP server can be configured via the ‘‘DHCP’’ tool, accessible via CStart/ Programs/Administrative Tools/DHCPD, or as ‘‘dhcpmgmt.msc’’. Each DHCP scope on the server has an associated ‘‘Scope Options’’ configuration, where the 066 and 067 options can be set. These options are supported by default and need only to be enabled and configured. The ‘‘DHCP server’’ service does not need to be restarted, changes will be reflected in the next DHCP lease. To re-configure an ISC DHCP server it is necessary to edit the dhcpd configuration file, usually ‘‘/etc/dhcpd.conf’’. The 066 and 067 options are set by adding values of ‘‘next-server’’ for 066 and ‘‘filename’’ for 067. The exact means of adding these options is dependent on the structure of the existing configuration file. The configuration file must be reloaded or the service restarted after the options have been set. In both cases the 066 option must be set to the IP address of the PXE server, and the 067 option to ‘‘pxelinux.0’’, the filename used by the ‘‘knoppixterminalserver’’ package. These changes will not affect other clients and can be left in place until the screening process is complete.
A note on Knoppix Although Knoppix is presented here as an example, this should not be taken as an absolute endorsement, as the base Knoppix operating system (OS)
175 may not be suitable for all purposes. The ‘‘readonly’’ functionality of Knoppix relies on support in multiple OS layers, including disk and file system drivers, operating system commands, standard Unix utilities and other supplied tools. In many cases the ‘‘read-only’’ functionality is flawed and cannot be relied on in all cases. One such Knoppix issue has already been discovered, namely the fact that mounting certain journaling file systems will result in a file system write, even when the read-only option is passed to the ‘‘mount’’ command. This specific issue has been documented in detail by Ernie Baca in his paper ‘‘KNOPPIX Bootable CD Validation Study for Live Forensic Preview of Suspects Computer’’. Although workarounds for the above issue exist, it serves to demonstrate the potential issues. Since forensic examination is not a core function of Knoppix, similar workarounds may be discovered in future. In particular it is possible that future changes might impact the ‘‘read-only’’ functionality in an unpredictable, and potentially undocumented, fashion. For this and other reasons it would be preferable to adapt these PXE deployment techniques to a similar system intended for forensic examination, e.g., PSK or Helix.
Other scenarios In addition to the ‘‘screening’’ example presented, a PXE boot system such as Knoppix is useful in many other scenarios. One of the most promising scenarios is the use of PXE to provide an incident-based investigative capability. Since normal DHCP clients are unaffected by the additional PXE options, the DHCP options and Knoppix PXE server could be left in place, with clients simply booted via PXE when an examination is needed. Outside of investigations the Knoppix PXE system has many other potential uses in a corporate environment. Non-investigative searches could be carried out with ease, such as those required for electronic discovery, Data Protection subject access requests or to ensure compliance with data retention policies. Incident response efforts could benefit from the same techniques, for example in checking for compromised systems which might otherwise be undetectable. Basic data recovery may even be possible, such as restoring files deleted by malicious software. Most importantly, all these tasks can be carried out in parallel on multiple systems.
176
References Helix. !http://www.e-fense.com/helix/O. Knoppix. !http://www.knoppix.org/O. PC99 spec. !http://www.microsoft.com/whdc/system/platform/ pcdesign/desguide/pcguides.mspxO. PXE spec. !ftp://download.intel.com/labs/manage/wfm/download/ pxespec.pdfO.
O. O’Connor Owen O’Connor is a private sector security professional based in Ireland, where he specialises in computer forensics and incident response. He is an MSc student at the Royal Military College of Science and is the founder and Vice President of the Irish chapter of the Information Systems Security Association.