312-50 Question 155
Single answer▪ Clearing LogsDuring an authorized internal penetration test of a Linux web server, you obtain root access through a vulnerable application. The engagement rules allow you to demonstrate anti-forensic techniques, but the client wants minimal disruption to system operations. You need to remove evidence of your interactive shell activity from the current session without wiping historical logs for the entire system. Which action is the MOST appropriate?
- A
Run history -c and unset HISTFILE in the current shell session
- B
Delete /var/log/auth.log and /var/log/syslog to remove all traces of access
- C
Use shred on every file in /var/log to ensure no log recovery is possible
- D
Restart rsyslog and journald so recent shell commands are not written to disk
Show answer and explanation
Correct answer: A
Explanation
This question tests the distinction between shell history and system logging. In real environments, "clearing logs" is often misunderstood as deleting files under /var/log, but a user's command activity is frequently preserved in shell history files such as ~/.bash_history, which are managed by the shell. For Bash, history -c clears the current in-memory list, and unsetting or redirecting HISTFILE can prevent the session from writing history at logout. By contrast, deleting or shredding system logs is noisy, disruptive, and often ineffective because logs may be protected by permissions, monitored by audit controls, or forwarded to centralized logging systems. This aligns with standard Linux shell behavior documented in the Bash manual and common syslog/journald operational practices.
- A. Correct.
Correct. On Linux, shell command history for interactive shells is commonly controlled through the shell history mechanism rather than system log files. Running history -c clears the in-memory history for the current shell, and unsetting HISTFILE prevents that shell from writing its history to the configured history file (such as ~/.bash_history) when the session ends. This is targeted to the current session and is far less disruptive than deleting centralized logs.
- B. Incorrect.
Incorrect. Deleting /var/log/auth.log and /var/log/syslog is highly disruptive and affects system-wide logging, not just the current session. It also creates obvious evidence of tampering because missing log files are themselves suspicious. In many environments, logs may already be forwarded to remote collectors, making local deletion ineffective.
- C. Incorrect.
Incorrect. Using shred on all files under /var/log is destructive and operationally unsafe. It can break logging services, interfere with incident response, and exceed the stated requirement for minimal disruption. It also does not address other evidence sources such as shell history files, audit frameworks, or remote log aggregation.
- D. Incorrect.
Incorrect. Restarting rsyslog and journald does not prevent shell history from being stored by the shell itself. It may briefly interrupt logging, but it is not a reliable way to remove evidence of commands typed in the current shell. Additionally, service restarts can be noticeable to administrators and may generate their own log entries.