backups to an encrypted volume using clonezilla

i had a few problems getting clonezilla to work

firstly, my live usb of clonezilla didn’t boot. turns out unetbootin, tuxboot, lili etc (i tried a few) don’t always edit the partition to be bootable and of type fat32. so while i’d formatted the usb to be fat32 and written the iso to it, it was still marked ‘linux, non-bootable’! using gnome-disks to edit the partition to fat32/bootable fixed it

so then i had clonezilla live booting. let it be said that clonezilla itself isn’t going to win any awards for clear instructions. i was paranoid i was going to write over my source drive by mistake, there was quite a bit of ambiguity in the first few screens

anyway, my second problem was one of encryption. clonezilla allows you to make encrypted backups, but i didn’t want that, i wanted to make unencrypted backups to an encrypted disk… i was going to use the same backup disk for rsync backups of bits of my filesystem too, you see. a disk password was out because my bios doesn’t support those for usb devices, even though the disk itself does. so i luks-encrypted my backup disk. but then clonezilla doesn’t support luks!

turns out the solution was easy. when clonezilla boots, it offers to drop you into a shell. do that, run the following commands, and then clonezilla will use your luks-encrypted disk as backup

sudo cryptsetup luksOpen /dev/sdN foo
sudo mount /dev/mapper/foo /home/partimag

…when prompted to mount the destination filesystem, just skip it (as it will offer by default), since you just did it…

after clonezilla has finished, it’ll drop you back into a shell. then you can do the following:

sudo sync
sudo umount /home/partimag
sudo crypysetup luksClose foo

# references

running a local moloch server

i came across moloch at my new workplace and thought i’d run it locally and play around with it. it’s a scalable packet capture and analysis tool. it has a nice GUI, and an API to build tools with (e.g. alerting)

# install
git clone
cd moloch

# build
./ Moloch INTERNAL encryption phrase: [0mgMolochRules1] MOLOCH: Adding user admin/admin

# add/change interfaces (if needed)
gedit /data/moloch/etc/config.ini

# fix up a script that was spewing errors
gedit /data/moloch/bin/
(add) ulimit -l unlimited

# create some sketchy start/stop scripts (can’t believe some aren’t provided!!)
==== /data/moloch/bin/start
sleep 30
nohup /data/moloch/bin/ &
nohup /data/moloch/bin/ &
===== /data/moloch/bin/stop
ps -elf | grep moloch | awk -F ” ” ‘{print $4}’ | xargs kill -9

# restart moloch

# connect

# change admin password

if you hit problems, look at the files in /data/moloch/logs. everything worked ok for me after the aforementioned steps

# links

linux process sandboxing with linux ‘user namespaces’ and firejail

i’m quite a fan of security-by-isolation, i.e. VMs and/or sandboxing. of course there are still vulnerabilities in the form of security-by-correctness failures (sandbox escapes), but i think they are far less likely to be found and widely exploited

i was initially considering running my internet-facing/vulnerable clients (browser, various messaging clients, etc) in a VM, but this seemed quite heavyweight and inconvenient

qubes would allow comparatively lightweight vms (they share the same resources such as filesystem), but that OS was out of the question because it can’t run some stuff i need it to (e.g. virtualbox VMs on top)

i figured i might not need to isolate an application in its own OS or filesystem, but rather use a sandbox. i came across sandboxie and then went on a hunt for a linux equivalent. i found firejail

it’s been described as ‘chroot on speed’, but it allegedly more secure than chroot. using linux kernel ‘user namespaces’, a container can be set up for a process so that it has its own private view of the filesystem, the network, processes, and so on

so for a potentially dangerous program (like suspected malware), one could run it in firejail where it has no internet access and no changes are persisted to the filesystem. alternatively, changes can be isolated to a private working space on the filesystem for the process (or process group)

it’s fine-grained control, so you can selectively disable ipv4, ipv6 or named pipes, whitelist or blacklist network interfaces (including localhost) or IP addresses, create a copy of the tcp/ip stack, whitelist or blacklist dirs/files, narrow permissions on the filesystem, hide other accounts entirely (such as root), reconfigure dns, and so on. amazingly you can even whitelist (or blacklist) the system calls that a process can make! amazing! but there are yet more features, such as replacing the process’s X11 server with one that allegedly cannot be screenshotted or keylogged, and whitelisting/blacklisting of ‘capabilities’ (of which there are about 35 in today’s linux kernel), which can be used to constrain superuser activities

firejail is easy to use, you just run ‘firejail <command>’. if it finds or is explicitly pointed-at a pre-baked profile for the <command> then that is leveraged, otherwise it defaults to a boilerplate profile. the default profile is generic.profile file if firejail is run by a regular user, and server.profile if run by root. profiles matching the application’s basename are searched-for first in ~/.config/firejail, then in /etc/firejail.  if you supply any other options to firejail apart from the jailed process name, then they override the respective part(s) of any loaded profile

firejail also logs attempts by the process to access blacklisted resources! and it has this nifty feature that you can symlink any binary to firejail, and firejail will look at the name it was given and then hunt for the real thing on the remainder of the path (so you could make a symlink called ‘firefox’ which pointed at the ‘firejail’ binary, and firejail would see it was actually called with name ‘firefox’, and load the real firefox in a firejail). it’s packed with good features!

firejail is incredibly easy to use. that is great, but i think is also slightly dangerous. for instance typing ‘firejail skype’ will launch the bundled profile at /etc/firejail/skype.profile and it will work fine, but i find the ignorance of what is going on under the covers a bit scary 🙂 also, i can see that profiles often use blacklisting, which i’m wary of because blacklisting is fragile.  of course whitelisting is also fragile, but in a different way 😀

so while initially i will use those pre-build profiles (of which there are many!), my goal, *eventually*, is to learn all about firejail and build my own profiles based purely on whitelisting. in fact the recommended approach for whitelisting is ‘run and profile the process with no permissions, see what breaks, fix the profile and try again’. using this approach i should build up a library of custom profiles and confidence in what firejail is allowing/disallowing, plus a much better idea of what the processes i’m jailing are actually trying to do! when i get a bit more expert then another blog post will materialize

# install firejail
apt-get install firejail

# example invocations (these all have pre-built profiles)
firejail google-chrome-stable
firejail firefox
firejail skype
firejail /opt/Wire/wire <– requires downloading the wire profile and an .inc file from

# look at the firejailed process tree
firejail –tree

lastly, firejail is itself a setuid program, which is a security risk! so there is definitely a degree of ‘security by correctness’, but hopefully it is small and the program drops its privileges after running a relatively small surface-area of code. all in all, and without being an expert in this area, i’m well impressed with firejail!

INTERESTING NOTE! an exploit for firejail has arrived! it seems to have been possible because the setuid attack surface was too large… – hopefully this will be addressed soon

# links (linux kernel ‘user namespaces’ feature overview)
Firejail Seccomp Guide
Firejail Linux Capabilities Guide
man firejail-profile