Update lab instructions

modules/generators/structured_content/hackerbot_config/dead_analysis/templates/dead_investigation.md

@@ -295,7 +295,7 @@ whois *IP-address*
 
 Within Autopsy, ==view the /var/log/boot.log file==. At the top of this file Syslog reports starting at August 10 at 13:33:57. 
 
-==LogBook Question: Given what we have learned about this system during timeline analysis, what is suspicious about Syslog restarting on August 10th? Was the system actually restarted at that time?==
+==Log Book Question: Given what we have learned about this system during timeline analysis, what is suspicious about Syslog restarting on August 10th? Was the system actually restarted at that time?==
 
 Note that according to the log, Apache fails to restart. Why can't Apache restart? Do you think the attacker intended to do this?
 
@@ -313,7 +313,7 @@ ps aux | grep apache
 kill -9 21510 21511 23289 23292 23302
 ```
 
-==LogBook Question: What is the attacker attempting to do with these commands?==
+==Log Book Question: What is the attacker attempting to do with these commands?==
 
 Apache has clearly played an important role in the activity of the attacker, so it is natural to investigate Apache's configuration and logs.
 
@@ -351,7 +351,7 @@ Scroll down, and ==find any deleted email message logs.==
 
 > Hint: try pressing ":" then type "/To:".
 
-==LogBook Question: What sorts of information was emailed?==
+==Log Book Question: What sorts of information was emailed?==
 
 To get the list of all email recipients quit less (press 'q'), and ==run:==
 

modules/generators/structured_content/hackerbot_config/dead_analysis/templates/deleted.md.erb

@@ -24,7 +24,7 @@ Scroll down, and ==find any deleted email message logs.==
 
 > Hint: try pressing ":" then type "/To:".
 
-==LogBook Question: What sorts of information was emailed?==
+==Log Book Question: What sorts of information was emailed?==
 
 To get the list of all email recipients quit less (press 'q'), and ==run:==
 

modules/generators/structured_content/hackerbot_config/dead_analysis/templates/logs.md.erb

@@ -37,7 +37,7 @@ whois *IP-address*
 
 Within Autopsy, ==view the /var/log/boot.log file==. At the top of this file Syslog reports starting at August 10 at 13:33:57. 
 
-==LogBook Question: Given what we have learned about this system during timeline analysis, what is suspicious about Syslog restarting on August 10th? Was the system actually restarted at that time?==
+==Log Book Question: Given what we have learned about this system during timeline analysis, what is suspicious about Syslog restarting on August 10th? Was the system actually restarted at that time?==
 
 Note that according to the log, Apache fails to restart. Why can't Apache restart? Do you think the attacker intended to do this?
 
@@ -55,7 +55,7 @@ ps aux | grep apache
 kill -9 21510 21511 23289 23292 23302
 ```
 
-==LogBook Question: What is the attacker attempting to do with these commands?==
+==Log Book Question: What is the attacker attempting to do with these commands?==
 
 Apache has clearly played an important role in the activity of the attacker, so it is natural to investigate Apache's configuration and logs.
 

modules/generators/structured_content/hackerbot_config/dead_analysis_v2/templates/dead_investigation.md

@@ -295,7 +295,7 @@ whois *IP-address*
 
 Within Autopsy, ==view the /var/log/boot.log file==. At the top of this file Syslog reports starting at August 10 at 13:33:57. 
 
-==LogBook Question: Given what we have learned about this system during timeline analysis, what is suspicious about Syslog restarting on August 10th? Was the system actually restarted at that time?==
+==Log Book Question: Given what we have learned about this system during timeline analysis, what is suspicious about Syslog restarting on August 10th? Was the system actually restarted at that time?==
 
 Note that according to the log, Apache fails to restart. Why can't Apache restart? Do you think the attacker intended to do this?
 
@@ -313,7 +313,7 @@ ps aux | grep apache
 kill -9 21510 21511 23289 23292 23302
 ```
 
-==LogBook Question: What is the attacker attempting to do with these commands?==
+==Log Book Question: What is the attacker attempting to do with these commands?==
 
 Apache has clearly played an important role in the activity of the attacker, so it is natural to investigate Apache's configuration and logs.
 
@@ -351,7 +351,7 @@ Scroll down, and ==find any deleted email message logs.==
 
 > Hint: try pressing ":" then type "/To:".
 
-==LogBook Question: What sorts of information was emailed?==
+==Log Book Question: What sorts of information was emailed?==
 
 To get the list of all email recipients quit less (press 'q'), and ==run:==
 

modules/generators/structured_content/hackerbot_config/dead_analysis_v2/templates/deleted.md.erb

@@ -24,7 +24,7 @@ Scroll down, and ==find any deleted email message logs.==
 
 > Hint: try pressing ":" then type "/To:".
 
-==LogBook Question: What sorts of information was emailed?==
+==Log Book Question: What sorts of information was emailed?==
 
 To get the list of all email recipients quit less (press 'q'), and ==run:==
 

modules/generators/structured_content/hackerbot_config/dead_analysis_v2/templates/logs.md.erb

@@ -35,7 +35,7 @@ whois *IP-address*
 
 Within Autopsy, ==view the /var/log/boot.log file==. At the top of this file Syslog reports starting at August 10 at 13:33:57.
 
-==LogBook Question: Given what we have learned about this system during timeline analysis, what is suspicious about Syslog restarting on August 10th? Was the system actually restarted at that time?==
+==Log Book Question: Given what we have learned about this system during timeline analysis, what is suspicious about Syslog restarting on August 10th? Was the system actually restarted at that time?==
 
 Note that according to the log, Apache fails to restart. Why can't Apache restart? Do you think the attacker intended to do this?
 
@@ -53,7 +53,7 @@ ps aux | grep apache
 kill -9 21510 21511 23289 23292 23302
 ```
 
-==LogBook Question: What is the attacker attempting to do with these commands?==
+==Log Book Question: What is the attacker attempting to do with these commands?==
 
 Apache has clearly played an important role in the activity of the attacker, so it is natural to investigate Apache's configuration and logs.
 

modules/generators/structured_content/hackerbot_config/ids/templates/IDS.md

@@ -199,7 +199,7 @@ tail -f /var/log/snort/alert
 ```
 >The tail program will wait for new alerts to be written to the file, and will display them as they are logged.
 
-==LogBook question: Does the log match what happened? Are there any false positives (alerts that describe things that did not actually happen)?==
+==Log Book question: Does the log match what happened? Are there any false positives (alerts that describe things that did not actually happen)?==
 
 ==Do an nmap port scan of the web_server== VM (from the desktop VM):
 

modules/generators/structured_content/hackerbot_config/ids/templates/snort.md.erb

@@ -2,13 +2,7 @@
 
 Continuing **on the ids_monitor VM:**
 
-==Make a backup== of the snort's configuration file in case anything goes wrong:
-
-```bash
-sudo cp /etc/snort/snort.conf /etc/snort/snort.conf.bak
-```
-
-==Change Snort's output== to something more readable:
+==Confirm Snort's output== is set to something readable:
 
 ```bash
 sudo vi /etc/snort/snort.conf
@@ -17,16 +11,16 @@ sudo vi /etc/snort/snort.conf
 
 > ":wq" to write changes and quit)
 
-==Add (or uncomment) the following lines:==
+==Check for the following lines:==
 `output alert_fast`
 `output log_tcpdump: tcpdump.log`
 
-==Change Snort's interface== to ens18 (or as you identified earlier), and set the local network to your IP address range (or "any"):
-
 ```bash
 sudo vi /etc/snort/snort.debian.conf
 ```
-> Set the interface and HOME network range, and exit vi (Esc, ":wq").
+==Check Snort's interface== which will be ens18 (or as you identified earlier), and the local network is set to your IP address range (or "any"):
+
+> Confirm the above, and exit vi (Esc, ":wq").
 
 ==Start Snort:==
 
@@ -53,7 +47,7 @@ sudo tail -f /var/log/snort/alert
 ```
 >The tail program will wait for new alerts to be written to the file, and will display them as they are logged. (Ctrl-C to exit)
 
-==LogBook question: What does the `-sX` in the nmap command mean? Does the log match what happened? Are there any false positives (alerts that describe things that did not actually happen)?==
+==Log Book question: What does the `-sX` in the nmap command mean? Does the log match what happened? Are there any false positives (alerts that describe things that did not actually happen)?==
 
 ==Try another type of port scan from the desktop== VM (Hint: `man nmap`).
 

modules/generators/structured_content/hackerbot_config/ids_exfiltration/templates/intro.md.erb

@@ -34,7 +34,7 @@ Work through the below exercises, completing the Hackerbot challenges as noted.
 
 **On the ids_monitor VM:**
 
-==Ensure Snort's output== includes something more readable:
+==Confirm Snort's output== is set to something readable:
 
 ```bash
 sudo vi /etc/snort/snort.conf
@@ -43,16 +43,16 @@ sudo vi /etc/snort/snort.conf
 
 > ":wq" to write changes and quit)
 
-==Check for the following line:==
+==Check for the following lines:==
 `output alert_fast`
-
-==Ensure Snort's interface is correctly configured== to the interface with IP address <%= $ids_server_ip %> (likely ens3), and set the local network to your IP address range (or "any"):
+`output log_tcpdump: tcpdump.log`
 
 ```bash
 sudo vi /etc/snort/snort.debian.conf
 ```
-> If you are not sure which interface to use, list the interfaces with `ifconfig` or `ip a s`
-> Set the interface and HOME network range, and exit vi (Esc, ":wq").
+==Check Snort's interface== which will be ens18 (or as you identified earlier), and the local network is set to your IP address range (or "any"):
+
+> Confirm the above, and exit vi (Esc, ":wq").
 
 ==Restart Snort:==
 

modules/generators/structured_content/hackerbot_config/ids_rules/templates/IDS.md

@@ -199,7 +199,7 @@ tail -f /var/log/snort/alert
 ```
 >The tail program will wait for new alerts to be written to the file, and will display them as they are logged.
 
-==LogBook question: Does the log match what happened? Are there any false positives (alerts that describe things that did not actually happen)?==
+==Log Book question: Does the log match what happened? Are there any false positives (alerts that describe things that did not actually happen)?==
 
 ==Do an nmap port scan of the web_server== VM (from the desktop VM):
 

modules/generators/structured_content/hackerbot_config/ids_rules/templates/snort.md.erb

@@ -2,12 +2,6 @@
 
 Continuing **on the ids_monitor VM:**
 
-==Make a backup== of the snort's configuration file in case anything goes wrong:
-
-```bash
-sudo cp /etc/snort/snort.conf /etc/snort/snort.conf.bak
-```
-
 ==Change Snort's output== to something more readable:
 
 ```bash
@@ -17,15 +11,25 @@ sudo vi /etc/snort/snort.conf
 
 > ":wq" to write changes and quit)
 
-==Add the following line:==
-`output alert_fast`
+==Confirm Snort's output== is set to something readable:
 
-==Change Snort's interface== to eth1 (or as you identified earlier), and set the local network to your IP address range (or "any"):
+```bash
+sudo vi /etc/snort/snort.conf
+```
+> (Remember: editing using vi involves pressing "i" to insert/edit text, then *Esc*,
+
+> ":wq" to write changes and quit)
+
+==Check for the following lines:==
+`output alert_fast`
+`output log_tcpdump: tcpdump.log`
 
 ```bash
 sudo vi /etc/snort/snort.debian.conf
 ```
-> Set the interface and HOME network range, and exit vi (Esc, ":wq").
+==Check Snort's interface== which will be ens18 (or as you identified earlier), and the local network is set to your IP address range (or "any"):
+
+> Confirm the above, and exit vi (Esc, ":wq").
 
 ==Start Snort:==
 
@@ -56,7 +60,7 @@ nmap <%= $web_server_ip %>
 
 This should trigger another alert.
 
-==LogBook question: Does the log match what happened? Are there any false positives (alerts that describe things that did not actually happen)?==
+==Log Book question: Does the log match what happened? Are there any false positives (alerts that describe things that did not actually happen)?==
 
 Try another type of port scan, such as an ==Xmas Tree scan from the desktop== VM (Hint: `man nmap`).
 

modules/generators/structured_content/hackerbot_config/ids_rules/templates/write_snort_rules.md.erb

@@ -69,7 +69,7 @@ Right click the Web traffic, and select *Follow TCP Stream*.
 
 Note that you can also view the unzipped version of the content in Wireshark. In the view below the list of packets, ==expand the "Line-based text data: text/html" heading==
 
-==LogBook Question: What is the difference between these views?==
+==Log Book Question: What is the difference between these views?==
 
 Also experiment with using Wireshark display filters of `http` and `irc`.
 
@@ -155,7 +155,7 @@ sudo tail -f /var/log/snort/alert
 ```
 > -f outputs appended data as the file grows
 
-==LabBook Question: Browse the existing rules in `/etc/snort/rules` and describe how one of the existing rules works.==
+==Log Book Question: Browse the existing rules in `/etc/snort/rules` and describe how one of the existing rules works.==
 
 Tips:
 * **Don't forget to reload Snort each time you change your rules.**

modules/generators/structured_content/hackerbot_config/live_analysis/templates/live_evidence_collection.md.erb

@@ -10,7 +10,7 @@ script -f /tmp/evid/invst.log
 ```
 > Note: *if you do this lab over multiple sessions*, be sure to save the log of your progress (/tmp/evid/invst.log), and restart `script`.
 
-==LogBook question: Make a note of the risks and benefits associated with storing a record of what we are doing locally on the computer that we are investigating.==
+==Log Book question: Make a note of the risks and benefits associated with storing a record of what we are doing locally on the computer that we are investigating.==
 
 Consider the advantages of *handwritten* documentation of what investigators are doing.
 
@@ -64,7 +64,7 @@ ps aux | ssh <%= $main_user %>@*desktop-IP-address* "cat > evidence/ps_out"
 
 > (Where *desktop-IP-address* is the IP address of your *desktop VM*, which should be on the same subnet as your compromised VM)
 
-==LogBook question: Why might it not be a good idea to ssh to your own account (if you had one on a Desktop in real life) and type your own password from the compromised system? What are some more secure alternatives?==
+==Log Book question: Why might it not be a good idea to ssh to your own account (if you had one on a Desktop in real life) and type your own password from the compromised system? What are some more secure alternatives?==
 
 **On your Desktop VM**, find the newly created files and view the contents.
 
@@ -113,7 +113,7 @@ $static/lsof | ssh <%= $main_user %>@*Desktop-IP-address* "cat > evidence/lsof_o
 
 **On your Desktop VM**, open evidence/lsof\_out.
 
-==LogBook question: Are any of these marked as "(deleted)"? How does this compare to the ils output? What does this indicate?==
+==Log Book question: Are any of these marked as "(deleted)"? How does this compare to the ils output? What does this indicate?==
 
 **On the compromised VM (Redhat7.2)**,
 

modules/generators/structured_content/hackerbot_config/live_analysis/templates/live_investigation.md

@@ -93,7 +93,7 @@ script -f /tmp/evid/invst.log
 ```
 > Note: *if you do this lab over multiple sessions*, be sure to save the log of your progress (/tmp/evid/invst.log), and restart `script`.
 
-==LogBook question: Make a note of the risks and benefits associated with storing a record of what we are doing locally on the computer that we are investigating.==
+==Log Book question: Make a note of the risks and benefits associated with storing a record of what we are doing locally on the computer that we are investigating.==
 
 Consider the advantages of *handwritten* documentation of what investigators are doing.
 
@@ -147,7 +147,7 @@ ps aux | ssh <%= $main_user %>@*desktop-IP-address* "cat > evidence/ps_out"
 
 > (Where *desktop-IP-address* is the IP address of your *desktop VM*, which should be on the same subnet as your compromised VM)
 
-==LogBook question: Why might it not be a good idea to ssh to your own account (if you had one on a Desktop in real life) and type your own password from the compromised system? What are some more secure alternatives?==
+==Log Book question: Why might it not be a good idea to ssh to your own account (if you had one on a Desktop in real life) and type your own password from the compromised system? What are some more secure alternatives?==
 
 **On your Desktop VM**, find the newly created files and view the contents.
 
@@ -196,7 +196,7 @@ $static/lsof | ssh <%= $main_user %>@*Desktop-IP-address* "cat > evidence/lsof_o
 
 **On your Desktop VM**, open evidence/lsof\_out.
 
-==LogBook question: Are any of these marked as "(deleted)"? How does this compare to the ils output? What does this indicate?==
+==Log Book question: Are any of these marked as "(deleted)"? How does this compare to the ils output? What does this indicate?==
 
 **On the compromised VM (Redhat7.2)**,
 

modules/generators/structured_content/hackerbot_config/live_analysis_v2/templates/live_evidence_collection.md.erb

@@ -18,7 +18,7 @@ script -f evid/invst.log
 ```
 > Note: *if you do this lab over multiple sessions*, be sure to save a copy of the log of your progress (evid/invst.log), and restart `script`.
 
-==LogBook question: Make a note of the risks and benefits associated with storing a record of what we are doing locally on the computer that we are investigating.==
+==Log Book question: Make a note of the risks and benefits associated with storing a record of what we are doing locally on the computer that we are investigating.==
 
 Consider the advantages of *handwritten* documentation of what investigators are doing.
 
@@ -66,7 +66,7 @@ ldd /media/cdrom0/statbins/linux2.2_x86/ls
 
 ==Compare the output to the previous command== run on your own Desktop system. The output will be distinctly different, stating that the program is not dynamically compiled.
 
-Note that, although an improvement, using statically linked programs such as these still do not guarantee that you can trust the output of the programs you run. ==Consider why, and make a note of this in your LogBook.==
+Note that, although an improvement, using statically linked programs such as these still do not guarantee that you can trust the output of the programs you run. ==Consider why, and make a note of this in your Log Book.==
 
 ## First look around
 
@@ -239,7 +239,7 @@ ls -la /home/<%= $main_user %>/evidence
 
 At this stage ==take a closer look through== some of the information you have collected.
 
-==LogBook Task:== Examine the contents of the various output files and identify anything that may indicate that the computer has been compromised by an attacker. Hint: does the network usage seem suspicious?
+==Log Book Task:== Examine the contents of the various output files and identify anything that may indicate that the computer has been compromised by an attacker. Hint: does the network usage seem suspicious?
 
 ### Collecting live state using scripts
 

modules/generators/structured_content/hackerbot_config/live_analysis_v2/templates/live_investigation.md

@@ -58,7 +58,7 @@ script -f /tmp/evid/invst.log
 ```
 > Note: *if you do this lab over multiple sessions*, be sure to save the log of your progress (/tmp/evid/invst.log), and restart `script`.
 
-==LogBook question: Make a note of the risks and benefits associated with storing a record of what we are doing locally on the computer that we are investigating.==
+==Log Book question: Make a note of the risks and benefits associated with storing a record of what we are doing locally on the computer that we are investigating.==
 
 Consider the advantages of *handwritten* documentation of what investigators are doing.
 
@@ -112,7 +112,7 @@ ps aux | ssh <%= $main_user %>@*desktop-IP-address* "cat > evidence/ps_out"
 
 > (Where *desktop-IP-address* is the IP address of your *desktop VM*, which should be on the same subnet as your compromised VM)
 
-==LogBook question: Why might it not be a good idea to ssh to your own account (if you had one on a Desktop in real life) and type your own password from the compromised system? What are some more secure alternatives?==
+==Log Book question: Why might it not be a good idea to ssh to your own account (if you had one on a Desktop in real life) and type your own password from the compromised system? What are some more secure alternatives?==
 
 **On your Desktop VM**, find the newly created files and view the contents.
 
@@ -161,7 +161,7 @@ $static/lsof | ssh <%= $main_user %>@*Desktop-IP-address* "cat > evidence/lsof_o
 
 **On your Desktop VM**, open evidence/lsof\_out.
 
-==LogBook question: Are any of these marked as "(deleted)"? How does this compare to the ils output? What does this indicate?==
+==Log Book question: Are any of these marked as "(deleted)"? How does this compare to the ils output? What does this indicate?==
 
 **On the compromised VM (Redhat7.2)**,