Spiral four: Add a Trap and Analize
Goal of this spiral is to evaluate the security of the completed Piception system.
-
Analize the system
- lynis
- rkhunter
-
Physical accses
- Add a trap
- Ls trap
Analize
After completing the security hardening, I wanted to evaluate the system using security auditing tools. I had previously used rkhunter, but I also wanted to try Lynis on Piawake to get a broader assessment of the system's security
| Feature | rkhunter | Lynis |
|---|---|---|
| Detect known rootkits | Excellent | No |
| Check system binaries | Yes | Basic |
| Detect hidden files/processes | Yes | Limited |
| Audit security configuration | Limited | Excellent |
| Check firewall configuration | No | Yes |
| Check SSH configuration | Basic | Detailed |
| Check kernel hardening | No | Yes |
| Give hardening recommendations | No | Yes |
| Security score | No | Yes |
Lynis
Install:
Run a system audit:
After installing it I ran the audit Lynis prints out nice verbose that is easy to read trough and in the end you get a good result summary.

The scan completed and produced this summary:
The audit showed that the system already had several important security measures in place, including:
- Firewall enabled
- SSH hardening
- Automatic updates
- Fail2ban
- Reduced attack surface
- Persistent system logging
Lynis also suggested additional hardening options that could be implemented in the future. Lynis also generated two reports that can be reviewed:
Rkhunter
Install:
Update database:
Run a system audit:
--skip-keypress runs it continusly

The scan took a little longer than Lynis but provides a detailed and easy-to-read summary:
Files checked : 141
Rootkits checked : 497
Possible rootkits : 0
Files checked: 141
Suspect files: 1
I got two warnings in the end and it's interesting because I had the decrypted drive in the pi and had also made the VM image disk.
Checking /dev for suspicious file types [ Warning ]
Checking for hidden files and directories [ Warning ]
Physical Accses
Next, I considered what would happen if an attacker gained physical access to the devices.
SD cards
Both Raspberry Pi SD cards could be removed and read from another computer. However, the sensitive data was still protected because the virtual machine and the totem were encrypted. Although the SD cards were accessible, the encrypted contents could not be read without the correct passphrase.
USB stick
The USB stick was encrypted using LUKS. When I connected it to my laptop, no files were accessible until the correct passphrase was provided. This confirmed that the encrypted USB protected its contents even if it was removed from the Raspberry Pi.
Ethernet cable
I did not test connecting directly to the isolated Ethernet network because my laptop does not have an Ethernet port. However, the design assumes that physical access to the cable alone does not provide access to the protected data. An attacker would still need to compromise Piawake before reaching Piception.
Adding a Trap
After evaluating the system, I realized that it is difficult to remain completely secure once a system is connected to the Internet. One option to further isolate Piception would be to physically desolder the onboard WiFi chip, ensuring that it could never communicate wirelessly. I chose not to do it this time, but it would be an effective way to permanently remove the wireless attack surface.
I decided to add a defensive feature that could physically disconnect Piception from the Piawake network by cutting its Ethernet connection. Although Piception was not directly connected to the Internet, it was still connected to a machine that was. Physically disconnecting the Ethernet cable would therefore isolate it completely.

I built a simple mechanical trap using a small hatchet mounted on a hinge. A servo motor connected to the Raspberry Pi GPIO pins releases the hatchet, cutting the Ethernet cable and isolating Piception from the rest of the network.
I first implemented the control software in Python to test the servo to try it out.
from gpiozero import AngularServo
from time import sleep
servo = AngularServo(18)
servo.angle = -90
sleep(1)
servo.angle = 90
sleep(1)
servo.detach()
Once the prototype was working, I rewrote it in C and compiled it into a standalone executable:
#include <lgpio.h>
#include <stdio.h>
#include <unistd.h>
#define CHIP 0
#define GPIO 18
int main(void)
{
int h = lgGpiochipOpen(CHIP);
if (h < 0) {fprintf(stderr, "Failed to open GPIO chip\n");return 1;}
if (lgGpioClaimOutput(h, 0, GPIO, 0) < 0) {fprintf(stderr, "Failed to claim GPIO18\n");lgGpiochipClose(h);return 1;}
printf("Decrypting wallet... NOT!! Now get out!\n");
/* servo start */
lgTxServo(h, GPIO, 1000, 50, 0, 0);
sleep(1);
lgTxServo(h, GPIO, 2000, 50, 0, 0);
sleep(1);
lgTxServo(h, GPIO, 0, 50, 0, 0);
lgGpiochipClose(h);
return 0;
}
The executable was compiled and placed on Piception with the name decrypt_wallet. During testing, activating the program successfully released the mechanism and disconnected the Ethernet cable.
LS trap
As an experiment, I also considered replacing commonly used commands with wrapper programs that would activate the isolation mechanism. For example, the standard ls command could be replaced by a wrapper while the original binary is renamed (for example, to lss). This demonstrates how deception can be incorporated into a security design by triggering a defensive response when an attacker performs common reconnaissance actions.
Although this approach was only explored conceptually, it illustrates how layered security can combine traditional defenses with deception techniques.
