marcus-s' notes on ArchLinux

Version: 1.0.2

Changelog:

V1.0.2
- Added section regarding iptables

V1.0.1
- Added howto on encrypting communication

V1.0
- Initial release
Author: marcus-s -- mail [at] marcus-s [dot] de
Last modified: Feb 25, 2016


Why this document?
In my time I have often switched OS' - either from one distro to another, or from one distro to Windows, then to one of the BSDs, and back to another distro. Eventually I settled for ArchLinux. In case you don't know it: it's a simple and lightweight Linux distributions primarily target at experienced and power users, who want to have fine-grained and hand-picked control over the environment they use. In other words, if you really want to be in the driver's seat and be able to fully tune the engine inside your car, Arch's for you. If you'd rather just drive a car but can live with how ugly the dashboard looks and can't be bothered to do some fine-tuning or replacement of that dashboard yourself, I suggest you stop reading here, get one of the pre-made distros such as Ubuntu, and live with the cosmetic damage of what Unity has to offer. If, however, you're the man in the garage that likes to tinker with his car, Arch is for you. Here are some notes to help you get started, or maybe acquire some useful information.

A note on the notes
I won't provide step by step instructions for a normal Arch install. These exist in great abundance. If it's that you're looking for, then this guide is a good place to start.


Table of contents
- Install Arch with full-drive encryption
- PulseAudio start on boot
- Encrypt your communication or data
- A simple but effective firewall for your Linux desktop




Install Arch with full-drive encryption

Privacy is a good thing. Complete privacy is hard to come by these days, but there are steps you can take to reduce the risk of your information taking an unwanted ride somewhere else. While full-disk encryption does not protect you from other attacks, it provides a pretty good layer of security and privacy for the files on your machine. It also provides a strong shields against anyone who might want to get to your data, and I mean physically. Like folks who take out the hard drive, or steal it, and then want to look at what you're hiding. Using the steps outlined below, these folks will have a pretty hard time as 1) the entire drive is encrypted, and 2) the OS requires a password for it to boot up. In other words if someone manages to look at the drive's content, it will be nothing but random binary data which makes no sense.

The steps outlined below use an AES cipher which the FBI and CIA use to encrpyt documents classified as Top Secret. That should be just about safe enough for us. So... here goes.


One more thing before we actually begin:

+++ BACK UP ALL YOUR DATA +++

We gonna wipe everything on your drive, so... if you love your data, you do this NOW. Do not proceed before you have backed up every single bit of data you want to keep.


1) Acquire the current live Arch ISO file

This should be obvious, but I'm stating that here.


2) "Burn" the ISO to a USB or CD

While I won't explain the burning of a CD, I will provide you with a hint on getting the ISO on a bootable USB. There are some tools available to do this job. If you're on a Linux distro already, you can use this command: $> dd if=/path/to/arch.iso of=/dev/[USB device] bs=1M. If you're on Windows, there's this handy tool called Win32 Disk Imager, which you can get your hands on over at our friends of SourceForge. Download that, burn Arch to your USB. Once you done this, move on to the next step.


3) Boot from USB or CD

Again, there is a huge abundance of explanations of how to perform the correct BIOS settings. Those depend on your computer and vary from case to case... so it's best to google how to enter the BIOS, and tune it so the machine boots from CD or USB.


3.5) OPTIONAL BUT RECOMMENDED: Secure-erase hard drive

You can skip this step... but what good is full-disk encryption if unused parts of the drive can be recovered, yes? I highly recommend tou do this step. Note: depending on the size of the drive you want to encrypt, this step might take a while. On my laptop it took about 90 minutes to fully wipe a 500 GB drive.

Once you see the command prompt of Arch, you can begin the secure-erase. We do this by filling the drive with 0's until there is no more space. If you have only one hard drive, the device is sda - otherwise find out which drive "letter" belongs to yours. Replace the "*" with that letter.

Then issue this command:
$> dd if=/dev/zero of=/dev/sd* bs=1M



4) Prepare the hard drive

I usually do this with fdisk, so here's what I have done:
- Create small boot partition for UEFI. Some systems need that, 2 MB - Needs to be flagged bootable in UEFI systems
- Create swap space. Formula: 1.5 the size of your RAM
- Create boot partition that holds the kernels and GRUB config, 150 MB
- Create partition that holds OS and data, the drive to be encrypted.


Here is an excellent guide that explains the usage of fdisk on a Linux distro. The command to run fdisk is $> fdisk /dev/sd*, where "*" is to be replaced with the actual drive letter.


5) Create file systems

If you followed the scheme above, then you need to perform the commands as in the sequence below. You want to store data, yes? So we need file systems. So here goes. The "*" is to be replaced with the actual letter.

For the first small partition do:
$> mkfs.ext4 /dev/sd*1

Then, for the swap space, use this:
$> mkswap /dev/sd*2

Enable the swap space right now:
$> swapon /dev/sd*2

Create an ext4 file system on the partition holding the kernels. We cannot encrypt this partition though.
$> mkfs.ext4 /dev/sd*3

Create the file system on the main partition. This is a personal preference... I personally use JFS here, but if you want to use Ext4, that's cool too.
For Ext4:
$> mkfs.ext4 /dev/sd*4

For JFS:
$> mkfs.jfs /dev/sd*4



6) Set up encryption for the drive

This is by far the most important step in this guide. There is long command that has to be typed exactly like this if you want scure encryption. The same filesystem you created on the big drive will have to be created again, that's fine. You will also have to settle on a "nickname" for your drive, a name or identifier you want to call that drive. So be creative, it can be anything (but no spaces). Let's go.

Set up encryption on the partition, like so:
$> cryptsetup -v -y --cipher aes-xts-plain64 --key-size 256 --hash sha256 --iter-time 2000 --use-urandom --verify-passphrase luksFormat /dev/sd*4

Obviously you will have to define a password. Choose a strong one. Preferably with upper and lowercase letters, numbers, and at least one special character.

Next up, we will prepare and open the drive for use just as normal. Got a nickname yet? We will use it now. It cannot be changed later. So choose wisely.
$> cryptsetup open /dev/sd*4 [DriveNickname]

Of course, provide the password you just created for that drive. That's what you need to remember.

Create the same file system for this drive as in step 5. If it is Ext4, create that. If it's JFS or anything else, use the same. But the command is now different:
$> mkfs.[filesystem] /dev/mapper/[DriveNickname]

The encrypted drive is now mapped into a "translator" in /dev, called mapper. This is where your main drive lives now.

Now proceed with mounting the drives, as per the normal installation guide for Arch Linux, like so:
$> mount /dev/mapper/[DriveNickname] /mnt


As we created a separate boot partition, we create that seemingly inside the encrypted drive:
$> mkdir /mnt/boot

And mount that too:
$> mount /dev/sd*3 /mnt/boot

This takes us neatly to the next step:


7) Install Arch Linux as normal

Up until a certain point this is the process as normal. So I will provide you with the fast-lane service. This is a courtesy so you don't have to read through the longer manual on the Arch page. Go through these steps in order... but make sure you have a working internet-connection.

Compared to Gentoo, Arch has built-in ready-to-use tools for Wifi-setup.

If you are on a wired connection, chances are this connection already works. Check with $> ping google.com and see if you get a reply. If this is the case you can skip the Wifi-setup.

If you are on Wifi, run
$> wifi-menu

Select Wifi, put in password, you don't need to store the profile since this is the live environment. But you should now have locked all chevrons on the Stargate for a connection to the universe out there. Test with a ping to somewhere.

Now for the fast lane service. Do these commands in sequence:

$> pacstrap -i /mnt base base-devel

$> genfstab -U /mnt > /mnt/etc/fstab

$> arch-chroot /mnt /bin/bash

$> nano /etc/locale.gen (Uncomment your desired locale in that file)

$> locale-gen

$> echo "LANG=[YOUR LOCALE] > /etc/locale.conf

$> tzselect

$> ln -s /usr/share/zoneinfo/MAINZONE/SUBZONE /etc/localtime

$> hwclock --systohc --utc



8) Prepare Kernel and GRUB for encrypted booting

We have to deviate from the normal guide again here a bit. Since you want your encrypted drive to boot properly, we need to make sure that that's what's happening. So let's bounce.

Issue this command:
$> mkinitcpio -p linux

This generates an initial RAM disk for the Kernel to use. This is important.

You need to edit the file /etc/mkinitcpio.conf now to implement the necessary hook for booting. Find the line that contains HOOKS=. There you need to insert the hook "encrypt" before the "filesystems" keyword, like so:

$> nano /etc/mkinitcpio.conf
---- HOOKS=[...] encrypt [...] filesystems [...]


Save the file, and run this command again:
$> mkinitcpio -p linux

This time it will implement the hook needed to decrypt a drive.

Perform installation of GRUB and bootloader as normal:

$> pacman -S grub os-prober

$> grub-install /dev/sd*

$> grub-mkconfig -o /boot/grub/grub.cfg


We need to edit the GRUB config file in two places, so that your encrypted drive can boot. The GRUB command line needs editing, which is in most cases on line 5, and is most often empty. So we need to insert something there:

$> nano /etc/default/grub
---
(Line 5):
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sd*:[DriveNickname] root=/dev/mapper/[DriveNickname]
---
(Add after end of file):
GRUB_ENABLE_CRYPTODISK=y


Save that file. In nano, you this with Ctrl+O, [Enter].

Generate the config again:
$> grub-mkconfig -o /boot/grub/grub.cfg



9) Finish installation


This is the moment you've been waiting for. We'll set a hostname, unmount everything, and boot the whole thing! Let's see.

First we need set a hostname. Think of something nice you wanna call your machine.
$> echo "YourMachineName" > /etc/hostname


We also need a password for root, as normal:
$> passwd


Now leave the chroot, exit and unmount everything, and boot!
$> exit
$> umount -R /mnt


Also close the conduit into your encrypted drive. Otherwise this can have funky consequences.

cryptsetup close DriveNickname


And finally the moment of truth:

reboot



10) Go where you wanna go from here!


You should have a working bootable encrypted volume. At each boot, you're asked for the password. Don't mind the initial error message of GRUB that it hasn't found a device name... I haven't found a solution for that yet, but the drive boots as normal - after you entered the correct password.

Once you're up and running, you can go and configure your system like you'd do with any Arch system at this point. Enjoy.



PulseAudio start on boot

There is this peculiar issue happening. Maybe it's happening to other Linux distros too, didn't have time to test. You gonna have a hard time getting your sound system to fire up when your Arch machine starts. That's because PulseAudio now uses a Socket based system,
according to the Arch wiki on the subject.

I'm gonna save you some searching on Google and the Arch forums: there is no solution yet. None that I can see.

The only resolution I have found for the moment, is to have PulseAudio fire up when you log in with your normal user to Arch.

You can do this by adding a line to your ~/.bashrc, like so:

pulseaudio --start

If you're logging in on another terminal, of course the .bashrc will be run. But since the daemon is running, the line has no effect.

Until I have found a better way, this'll have to do.

Note:
There is a possible solution over at rudd-o.com, I have to test it out.



Encrypt your communication or data

Privacy is some kind of a prestige good these days. You have to assume that pretty much everyone out there is out to get to your data, information, or whatever else there is that might reveal sensitive intel about you. So I have learned about this little nifty thing called PGP - Pretty Good Privacy - and I encourage you to use it. More specifically, the open source implementation GPG -
GNU Privacy Guard.

With this method you don't need any particular email program. Only a terminal tool capable of copy and paste. I personally recommend you LilyTerm.

Okay so first you obviously need the gpg tool. Install it like so:

$> pacman -S gnupg


Bam. You now have a pretty powerful tool at hand.

Before you proceed, it's important to familiarize yourself with Pretty Good Privacy / GNU Privacy Guard, how it works, and how it can protect you from prying eyes that should not see your communication.

You need to generate a key pair - a public key everyone can use to encrypt messages intended for your eyes only, and your personal private key which only you possess to decrypt the encrypted text and/or material. IF YOU LOSE THAT PRIVATE KEY, YOU WILL ALSO LOSE THE ABILITY TO DECRYPT INFORMATION -- FOREVER.

Make sure that key is in a very safe place. I mean it. Make sure no one can acquire that key.

So... generate a keypair. This page is a good place to create such a pair. You're strongly advised to save the keys in two separate files, ending in "-pub" for the public key (the key you can hand out to everyone), and "-sec" for the private key you better guard with your life.

Once you have done so, and stored the keys in a place the machine can access for the moment, you need to import your keys:

$> gpg --import [path to keyfile]


Obviously you need to do this for each key. From this moment on, you are able to encrypt and decrypt anything - as long as you're in posession of both keys. Remember: the public key encrypts, the private key decrypts.

So to test this, lets create a small text file with one line of content:

$> echo "This is some very important information that needs to be classified as Top Secret!" > ~/message.txt


Let's assume that this is the content or message you want to encrypt. Imagine this is some real text.

Now encrypt the information:

$> gpg -r [username of key] -a -o ~/enc.txt --encrypt ~/message.txt


The -r option specifies the username for the key. The -a option specifies ASCII encryption. The -o option specifies the destination file. And the --encrypt option obviously specifies which file to encrypt.

Go ahead. Open enc.txt or whatever file name you chose in a text editor. Not very readable eh?

Okay so you want to decrypt a message someone send you, in which your public key was used to encrypt the message. Let's assume for a moment that it is ~/enc.txt is the message for you.

You can decrypt that like so:

$> gpg -r [username of key] -a -o ~/dec.txt --decrypt ~/enc.txt


You are now asked for your passphrase to decrypt the message. It will be stored in the filename you specified in the -o switch.

Read the message with nano, vim, or whatever. Be sure to perform a Burn-After-Reading, like so:

$> shred ~/dec.txt
$> rm -rf ~/dec.txt


This will first obscure the file you have decrypted, then remove it from the drive. Think of it as a secure-wipe off your hard drive for the message to be delivered. You wouldn't want that anyone can recover the file, even if your drive itself is encrypted and someone somehow gained access to your machine right? Yop.

So there you have mail-client-independent GPG-encryption for all your messages. Works with files too btw... there you simply need to omit the -a switch in the command.



A simple but effective firewall for your Linux desktop

I think it goes without saying that safety and security are pretty vital these days when being online in general, particularly when browsing the web. The web isn't just your browser, you use other tools too. So this short tutorial shows you how to be pretty safe. These IPTables settings make sure that only connections you have established - outgoing connections - are the ones being allowed back in. So that you are in control.

ArchLinux's stock kernel ships with iptables support, a very powerful, effective and built-in firewall. If you want to secure your webserver, or enterprise intranet machine, you'd have to read up on a more comprehensive manual, because the config shown here won't cut it for you.

If you are doing your, let's say, investigative work from your prime machine, or your desktop, than this config will be good enough for starters. It will make sure that conduits you opened are the only ones accepting traffic in and out - and nothing else.

So in order to edit the file we need, you need to temporarily either login as root directly, or so a

$> sudo su


in your shelArchLinux's stock kernel ships with iptables support, a very powerful, effective and built-in firewall. If you want to secure your webserver, or enterprise intranet machine, you'd have to read up on a more comprehensive manual, because the config shown here won't cut it for you.

If you are doing your, let's say, investigative work from your prime machine, or your desktop, than this config will be good enough for starters. It will make sure that conduits you opened are the only ones accepting traffic in and out - and nothing else.

So in order to edit the file we need, you need to temporarily either login as root directly, or so a

$> sudo su


in your shell. On my standard Arch install, the iptables rule file didn't exist, so we need to make one by editing it directly. Let's say we use nano, so do a

$gt; nano /etc/iptables/iptables.rules


and you will probably see an empty file. Now paste the following lines into that editor:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -i lo -j ACCEPT
-A TCP -p tcp --dport 80 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT
COMMIT


The first six lines dictate iptables to drop anything there has been before. The next lines basically instruct iptables to accept packets and requests from connections YOU have initiated. The others will simply be dropped, and that includes ping requests.

If you don't have a webserver (XAMPP or the likes), you can remove this line:

-A TCP -p tcp --dport 80 -j ACCEPT

This line instructs iptables to open up port 80 for listening.

Save the file, and perform a

$> sudo systemctl restart iptables


for the rules to take immediate effect.

If this ruleset should come online at boot time, do a

$> sudo systemctl enable iptables


This activates iptables and this ruleset the moment your computer starts.