After Ross Ulbricht was arrested, people thought about how exactly the evidence on him was gathered. One part in particular received a lot of attention, which involved the feds grabbing his unlocked laptop while he was sitting in a public place conducting his darknet business. Two projects were developed: USBKill (not to be confused with the USBKill anti–forensics device) and Buskill. The former was a simple python script that could be executed and would watch for any USB drives being plugged in or out. The latter is a hardware solution consisting of a USB drive, a USB extension cable, a magnetic breakaway, and a carabiner. While the official store has the hardware for sale for over 100€, it is easy to find the same components on the internet and just build it yourself for less. It doesn't need any fancy software nor does the USB drive need to have anything on it. All you have to do is plug the USB extension cable into the computer, followed by the magnetic breakaway, then the USB drive, and finally attaching the carabiner to the USB drive and to your pants / belt. Once plugged in, it's possible to either write your own script to watch for any changes to the available drives or use the buskill software. It doesn't take long and it's pretty painless if you are familiar with shell script and linux.
The simplest action is to lock the screen. However, this is only useful for casual use when your threat model doesn't involve well–funded feds and when you are not in a jurisdiction with key disclosure laws. Shutting down is another simple action that will prevent forensics from extracting the keys from memory as long as the memory gets properly wiped at shutdown. However, it doesn't help you in countries with key disclosure laws (i.e. jurisdictions that require you to hand over passwords or face additional prison time), such as the UK, Australia, and Hong Kong (since 2020). If this is part of your threat model, then you can add a snippet above the shutdown command to wipe the LUKS header (usually first 16M). You can do this with dd if=/dev/urandom of=/dev/ bs=1M count=16. Make a backup of the header first and keep that backup safe and out of reach!
Why random data and not just luksErase? The luksErase command erases keyslots, however it leaves data indicating that this is a LUKS volume in the first bits. You can test this with hexdump -C -n 256 . It should show "LUKS" which indicates that this is a LUKS encrypted volume. Overwriting with zeros is suspicious when the first 16M are zeroed while the rest appears to have random data. It's a clear giveaway that this is a LUKS encrypted volume.