This is a copy pasta from another forum but the information was good enough for a repost. Credit was given to the original author.
The paranoid #! Security Guide
Table of Contents:
Making TrueCrypt Portable
Attacks on Full-Disk-Encryption
Attacks on encrypted Containers
Debian's encrypted LVM pwned
Encrypting SWAP using eCryptfs
Defense against Software Keyloggers
Defense against Hardware Keyloggers
srm [secure rm]
Other Ways to securely wipe Drives
Modem & Router
Intrusion-Detection, Rootkit-Protection & AntiVirus
Using secure and censor-free DNS
TOR [The Onion Router]
VPN (Virtual Private Network)
Secure and Encrypted VoIP
Alternatives to Facebook
Live-CDs and VM-Images that focus on security and anonymity
This is my first attempt to contribute something to the community. Basically you can find everything I write here somewhere else on the web or in some book - but exactly that is the problem. You can literally spend weeks digging up all this stuff. And to save you some trouble I thought: "Heck, let's just put this into a little manual."
You're dealing with a somewhat paranoid security setup for debian-based systems like #!.
[This is the end-user and not
the |-|4xx0|2-version. We are not getting into virtual-virtual-virtual-machine-double-vpn-ssh-proxy-chain-from-your-internet-cafe-type-stuff.]
In this small guide I simply provide several "recipes" for securing both your box and your internet-connection and web-applications. I won't go into the why of all of this in too much detail as I want to provide a simple how-to that people can follow to make their system more secure without having to read through hundreds of pages of explanations. This information can easily be found elsewhere. If you're interested in a certain topic then just fire up a web-search and give it a read.
This guide is not exhaustive of course. As they say, security is a process - and so this guide can only be a place to start which needs to be adjusted to your personal needs.
If you consider to use this information and you find something to be too overcautious for your particular need - just ignore it and move on. One last thing before we begin: I am not a "security-guru" (far from it) - but more appropriately (as my nick suggests) some dude wrapping his head around things...
For the physical security of your data you should always employ encrypted drives. But before we get to that make sure you set strong passwords in BIOS for both
starting up and modifying the BIOS-settings. Also make sure to disable boot for any media other than your harddrive.
With #! this is easy. In the installation you can simply choose to use an encrypted LVM. (For those of you who missed that part on installation and would still like to use an encrypted partition withouth having to reinstall: use to get the job done.) For other data, e.g. data you store on transportable media you can use - which is better than e.g. dmcrypt for portable media since it is portable, too. You can put a folder with TrueCrypt for every OS out there on to the un
encrypted part of your drive and thus make sure you can access the files everywhere you go.
This is how it is done:
Making TrueCrypt Portable
- Download yourself some TC copy.
- Extract the tar.gz
- Execute the setup-file
- When prompted choose "Extract .tar Package File"
- go to /tmp
- copy the tar.gz and move it where you want to extract/store it
- extract it
- once it's unpacked go to "usr"->"bin" grab "truecrypt"-binary
- copy it onto your stick
- give it a test-run
There is really not much more in that tarball than the binary. Just execute it and you're ready for some crypto.
I don't recommend using TrueCrypt's hidden container, though. Watch to find out why. If you don't yet know how to use TrueCrypt check out . [TrueCrypt's standard encryption is . This encryption is really good but there are and you don't know how advanced certain people already got at this. So when prompted during the creation of a TrueCrypt container use: AES-Twofish-Serpent
and as hash-algorithm use SHA-512
. If you're not using the drive for serious video-editing or such you won't notice a difference in performance. Only the encryption process when creating the drive takes a little longer. But we get an extra scoop of security for that...
There are three different types of hardware encrypted devices available, which are generally called: SED (Self Encrypting Devices)
- Flash-Drives (Kingston etc.)
- SSD-Drives (Samsung etc.)
- HD-Drives (WD, Hitachi, Toshiba etc.)
They all use AES encryption. The key is generated within the device's microprocessor and thus no crucial data - neither password nor key are written to the host system. AES is secure - and thus using these devices can give some extra protection.
But before you think that all you need to do is to get yourself one of these devices and you're safe - I have to warn you: You're not.
So let's get to the reasons behind that.
Attacks on Full-Disk-Encryption
Below we will have a look at a debian specific attack using a vulnerability common with encrypted LVMs.
But you need to be aware that all disk-encryption is generally vulnerable - be it software- or hardware-based. I won't go into details how each of them work exactly - but I will try to at least provide you with a short explanation.
disk-encryption there are these known attacks:
(DMA/HDMI-Ports are used to connect to a running, locked machine to unlock it)
(Keys are extracted from RAM after a )
- Freezing of RAM
(RAM is and inserted into the attacker's machine to extratct the key)
(Different methods to boot up a trojanized OS or some kind of software-keylogger)
disk-encryption there are similar attacks:
(same as with SW-based encryption)
(Drive's data cable is disconnected and connected to attacker's machine via SATA-hotplugging)
(Drive's data cable is disconnected and connected to attacker's machine after enforced reboot. Then the bios-password is circumvented through the repeated pressing of the F2- and enter-key. After the bios integrated SED-password has been disabled the data-cable is plugged into the attacker's machine. This only works on some machines.)
the actual SED and replaces it with another containing a tojanized OS. On bootup victim enters it's password which is subsequently send to the attacker via network/local attacker hot-spot. Different method: Replacing a laptop with a similar model [at e.g. airport/hotel etc.] and the attacker's phone# printed on the bottom of the machine. Victim boots up enters "wrong" password which is send to the attacker via network. Victim discovers that his laptop has been misplaced, calls attacker who now copies the content and gives the "misplaced" laptop back to the owner.)
A full explanation of all these attacks been be found in . (Unfortunately it has not yet been translated into English.) An English explanation of an evil-maid-attack against TrueCrypt encrypted drives can be found
Attacks on encrypted Containers
There are also . They pretty much work like cold-boot-attacks, without the booting part.
An attacker can dump the container's password if the computer is either running or is in hibernation mode - either having the container open and even when the container has been opened during that session - using temporary and hibernation files.
Debian's encrypted LVM pwned
This type of "full" disk encryption can also be fooled by an attack that could be classified as a custom and extended evil-maid-attack. Don't believe me? Read !
The problem basically is that although most of the filesystem and your personal data are indeed
encrypted - your boot partition and GRUB aren't. And this allows an attacker with physical access to your box to bring you into real trouble.
To avoid this do the following:
Micah Lee wrote:
If you don’t want to reinstall your operating system, you can format your USB stick, copy /boot/* to it, and install grub to it. In order to install grub to it, you’ll need to unmount /boot, remount it as your USB device, modify /etc/fstab, comment out the line that mounts /boot, and then run grub-install /dev/sdb (or wherever your USB stick is). You should then be able to boot from your USB stick.
An important thing to remember when doing this is that a lot of Ubuntu updates rewrite your initrd.img, most commonly kernel upgrades. Make sure your USB stick is plugged in and mounted as /boot when doing these updates. It’s also a good idea to make regular backups of the files on this USB stick, and burn them to CDs or keep them on the internet. If you ever lose or break your USB stick, you’ll need these backups to boot your computer.
One computer I tried setting this defense up on couldn’t boot from USB devices. I solved this pretty simply by making a grub boot CD that chainloaded to my USB device. If you google “Making a GRUB bootable CD-ROM,” you’ll find instructions on how to do that. Here’s what the menu.1st file on that CD looks like:
title Boot from USB (hd1)
I can now boot to this CD with my USB stick in, and the CD will then boot from the USB stick, which will then boot the closely watched initrd.img to load Ubuntu. A little annoying maybe, but it works.
(Big thanks to !)
: Apparently there is with installing GRUB onto USB with waldorf/wheezy. As soon as I know how to get that fixed I will update this section.
You might think that mixing soft- and hardware-based encryption will solve these issues. Well, no. They don't. An attacker can simply chain different methods and so we are back at square one. Of course this makes it harder for an attacker to reach his goals - but he/she will not be stopped by it. So the only method that basically remains is to regard full-disk-encryption as a first layer of protection only.
Please don't assume that the scenarios described above are somewhat unrealistic. In the US there are about 5000 laptops being lost or stolen each week on airports alone
. European statistics indicate that about 8% of all business-laptops are at least once either lost or stolen.
A similar risk is there if you leave the room/apartment with your machine locked - but running. So the first protection against these methods is to always power down the machine. Always.
The next thing to remind yourself off is: You cannot rely on full-disk-encryption. So you need to employ further layers of encryption. That means that you will have to encrypt folders containing sensitive files again using other methods such as tomb or TrueCrypt. That way - if an attacker manages to get hold of your password he/she will only have access to rather unimportant files. If you have sensitive or confidential data to protect full-disk encryption is not enough!
When using encrypted containers that contain sensitive data you should shutdown your computer after having used them to clear all temporary data stored on your machine that could be used by an attacker to extract passwords.
If you have to rely on data being encrypted and would be in danger if anyone would find the data you were encrypting you should consider only using a power-supply when using a laptop - as opposed to running on power and battery. That way if let's say, you live in a dictatorship or the mafia is out to get you - and they
are coming to your home or wherever you are - all you need to do when you sense that something weird is going on is to pull the cable and hope that they
still need at least 30 secs to get to your ram. This can help prevent the above mentioned attacks and thus keep your data safely hidden.
If for some reason (like performance or not wanting to type in thousands of passwords on boot) you don't want to use an encrypted LVM you can use ecryptfs to encrypt files and folders after installation of the OS.
To find out about all the different features of ecryptfs and how to use them I would like to point you to .
But there is one thing that is also important for later steps in this guide and is generally a good idea to do:
Encrypting swap using ecryptfs
Especially when using older machines with less ram than modern computers it can happen quite frequently that your machine will use swap for different tasks when there's not enough ram available to do the job. Apart from the lack of speed this is isn't very nice from a security standpoint: as the swap-partition is not located within your ram but on your harddrive - writing into this partion will leave traces of your activities on the harddrive itself. If your computer happens to use swap during your use of encryption tools it can happen that the passwords to the keys are written to swap and are thus extractable from there - which is something you really want to avoid.
You can do this very easily with the help of ecryptfs.
First you need to install it:
$ sudo apt-get install ecryptfs-utils cryptsetup
Then we need to actually encrypt our swap using the following command:
$ sudo ecryptfs-setup-swap
Your swap-partition will be unmounted, encrypted and mounted again.
To make sure that it worked run this command:
$ sudo blkid | grep swap
The output lists your swap partion and should contain "cryptswap".
To avoid error messages on boot you will need to edit your /etc/fstab to fit your new setup:
$ sudo geany /etc/fstab
Copy the content of that file into another file and save it. You will want to use it as back-up in case something gets screwed up.
Now make sure to find the entry of the above listed encrypted swap partition. If you found it go ahead and delete the other swap-entry relating to the unencrypted swap-partition. Save and reboot to check that everything is working as it should be.
Another great crypto-tool is provided by the .
Tomb uses LUKS AES/SHA-256 and can thus be consider secure. But Tomb isn't just a possible replacement
for tools like TrueCrypt.
It has some really
neat and easy to use features:
1) Separation of encrypted file and key
2) Mounting files and folders in predefined places using bind-hooks
3) Hiding keys in picture-files using
The documentation on Tomb I was able to find
, frankly, seems to be scattered all over the place.
After I played around with it a bit I also came up with some tricks that I did not see being mentioned in any documentation.
And because I like to have everything in one place I wrote a short manual myself:
First you will need to import dyne's keys and add them to your gpg-keylist:
$ sudo gpg --fetch-keys
Now verify the key-fingerprint.
$ sudo gpg --fingerprint [email protected]
| grep fingerprint
The output of the above command should be:
Key fingerprint = 8E1A A01C F209 587D 5706 3A36 E314 AFFA 8A7C 92F1
Now, after checking that you have the right key you can trust add it to apt:
$ sudo gpg --armor --export [email protected]
$ sudo apt-key add dyne.gpg
After you did this you want to add dyne's repos to your sources.list:
$ sudo geany /etc/apt/sources.list
deb dyne main
deb-src dyne main
To sync apt:
$ sudo apt-get update
To install Tomb:
$ sudo apt-get install tomb
If you have your swap activated Tomb will urge you to turn it off or encrypt it. If you encrypt it and leave it on you will need to include --ignore-swap into your tomb-commands. To turn off swap for this session you can run
$ swapoff -a
To disable it completely you can comment out the swap in /etc/fstab. So it won't be mounted on reboot. (Please be aware that disabling swap on older computers with not much ram isn't such a good idea. Once your ram is being used fully while having no swap-partition mounted processes and programs will crash.)
Tomb will create the crypto-file in the folder you are currently in - so if you want to create a tomb-file in your documents-folder make sure to
$ cd /home/user/documents
Once you are in the right folder you can create a tomb-file with this command:
$ tomb -s XX create FILE
XX is used to denote the size of the file in MB. So in order to create a file named "test" with the size of 10MB you would type this:
$ tomb -s 10 create test
Please note that if you haven't turned off your swap you will need to modify this command as follows:
$ tomb --ignore-swap -s 10 create test
To unlock and mount that file on /media/test type:
$ tomb open test.tomb
To unlock and mount to a different location:
$ tomb open test.tomb /different/location
To close that particular
file and lock it:
$ tomb close /media/test.tomb
To close all tomb-files:
$ tomb close all
$ tomb slam
After these basic operations we come to the fun part:
Obviously having a file lying around somewhere entitled: "secret.tomb" isn't such a good idea, really.
A better idea is to make it harder for an attacker to even find the encrypted files you are using. To do this we will simply move its content to another file.
$ touch true-story.txt true-story.txt.key
$ mv secret.tomb true-story.txt
$ mv secret.tomb.key true-story.txt.key
Now you have changed the filename of the encrypted file in such a way that it can't easily be detected.
When doing this you have to make sure that the filename syntax tomb uses is conserved:
Otherwise you will have trouble opening the file.
After having hidden your file you might also want to move the key to another medium.
$ mv true-story.txt.key /medium/of/your/choice
Now we have produced quite a bit of obfuscation. Now let's take this even further:
After we have renamed our tomb-file and separated key and file we now want to make sure our key can't be found either.
To do this we will hide it within a jpeg-file.
$ tomb bury true-story.txt.key invisible-bike.jpg
You will need to enter a steganography-password in the process.
Now rename the original keyfile to something like "true-story.txt.key-backup" and check if everything worked:
$ tomb exhume true-story.txt.key invisible-bike.jpg
Your key should have reappeared now. After making sure that everything works you can safely bury the key again and delete the residual key that usually stays in the key's original folder.
By default Tomb's encrypted file and key need to be in one folder. If you have separated the two you will have to modify your opening-command:
$ tomb -k /medium/of/your/choice/true-story.txt.key open true-story.txt
To change the key-files password:
$ tomb passwd true-story.txt.key
If, let's say, you want to use Tomb to encrypt your icedove mail-folders you can easily do that. Usually it would be a pain in the butt to do this kind of stuff with e.g. truecrypt because you would need to setup a container, move the folder to the container and when using the folder you would have to move back to its original place again.
Tomb does this with ease:
Simply move the folders you want to encrypt into the root of the tomb-file you created.
You want to encrypt your entire .icedove folder. Then you make a tomb-file for it and move the .icedove folder into that tomb. The next thing you do is create a file named "bind-hooks" and place it in the same dir. This file will contain a simple table like this:
The fist column denotes the path relative to the tomb's root. The second column represents the path relative to the user's home folder.
So if you simply wanted to encrypt your .icedove folder - which resides in /home/user/ the above notation is fine. If you want the folder to be mounted elsewhere in the your /home you need to adjust the lines accordingly.
One thing you need to do after you moved the original folder into the tomb is to create a dummy-folder into which the original's folders content can be mounted. So you simply go into /home/user and create a folder named ".icedove" and leave it empty.
The next time you open and mount that tomb-file your .icedove folder will be where it should be and will disappear as soon as you close the tomb. Pretty nice, hu?
I advise to test this out before you actually move all your mails and prefs into the tomb. Or simply make a backup. But use some kind of safety-net in order not to screw up your settings.
Keyloggers can pose a great thread to your general security - but especially the security of your encrypted drives and containers. If someone manages to get a keylogger onto your system he/she will be able to collect all the keystrokes you make on your machine. Some of them even make screenshots.
So what kind of keyloggers are there?
For linux there are several software-keyloggers available. Examples are lkl, uberkey, THC-vlogger, PyKeylogger, logkeys.
Defense against Software Keyloggers
1) Never use your system-passwords outside of your system
Generally everything that is to be installed under linux needs root access or some priveliges provided through /etc/sudoers. But an attacker could have obtained your password if he/she was using a browser-exploitation framework such as - which also can be used as a keylogger on the browser level. So if you have been using your sudo or root password anywhere on the internet it might have leaked and could thus be used to install all kinds of evil sh*t on your machine. Keyloggers are also often part of rootkits. So do regular system-checks and use intrusion-detection-systems.
2) Make sure your browser is safe
Often people think of keyloggers only as either a software tool or a piece of hardware equipment installed on their machine. But there is another threat that is actually much more dangerous for linux users: a compromised browser. You will find a lot of info on how to secure your browser further down. So make sure you use it.
Compromising browsers isn't rocket science. And since all the stuff that is actually dangerous in the browser is cross-plattform - you as a linux-user aren't safe from that. No matter what short-sighted linux-enthusiasts might tell you. A java-script exploit will
pwn you - if you don't secure your browser. No matter if you are on OSX, Win or debian.
3) Check running processes
If your attacker isn't really skilled or determined he/she might not think about of the running keylogger. You can take a look at the output of
$ ps -aux
and inspect the running processes. Of course the attacker could have renamed it. So have a look for suspicious processes you have never heard of before. If in doubt do a search on the process or ask in a security-related forum about it.
Since a lot of keyloggers come as the functionality of a rootkit it would be much more likely that you would have one of these.
4) Do daily scans for rootkits
I will describe tools for doing that further below. RKHunter and chkrootkit should definitely be used. The other IDS-tools described give better results and are much more detailed - but you actually need to know a little about linux-architecture and processes to get a lot out of them. So they're optional.
5) Don't rely on virtual keyboards
The idea to defeat a keylogger by using a virtual keyboard is nice. But is also dangerous. There are some keyloggers out there that will also capture your screen activity. So using a virtual keyboard is pretty useless and will only result in the false feeling of security.
There is also an ever growing number of hardware keyloggers. Some of which use wifi. And some of them can be planted inside your keyboard so you wouldn't even notice them if you inspected your hardware from the outside.
Defense against Hardware Keyloggers
1) Inspect your Hardware
This one's obvious.
2) Check which devices are connected to your machine
There is a neat little tool called USBView which you can use to check what kind of usb-devices are connected to your machine. Some - but not all
- keyloggers that employ usb will be listed there. It is available through the debian-repos.
$ sudo apt-get install usbview
Apart from that there's not much you can do about them. If a physical attack is part of your thread-model you might want to think about getting a laptop safe in which you put the machine when not in use or if you're not around. Also, don't leave your laptop unattended at work, in airports, hotels and on conferences.
Additional to encrypted drives you may also want to securely delete old data or certain files. For those who do not know it: regular "file deletion" does not erase the "deleted" data. It only unlinks the file's thus making it possible to recover that "deleted" data with .
There are several ways to securely delete files - depending on the filesystem you use. The easiest is:
With this little tool you can not only erase free disc space - but also clean your system from various temporary files you don't need any longer and that would give an intruder unnecessary information about your activities.
$ sudo apt-get install bleachbit
Just select what you need shredding. Remember that certain functions are experimental and may cause problems on your system. But no need to worry: BleachBit is so kind to inform you about that and give you the chance to cancel your selection.
Another great [and much more secure] tool for file deletion is:
srm [secure remove]
$ sudo apt-get install secure-delete
Syntax: srm [-dflrvz] file1 file2 etc.
-d ignore the two dot special files "." and "..".
-f fast (and insecure mode): no /dev/urandom, no synchronize mode.
-l lessens the security (use twice for total insecure mode).
-r recursive mode, deletes all subdirectories.
-v is verbose mode.
-z last wipe writes zeros instead of random data.
Other ways to securely wipe drives
To overrite data with zeros:
# dd if=/dev/zero of=/dev/sdX
$ sudo dd if=/dev/zero of=/dev/sdX
To overwrite data with random data (makes it less obvious that data has been erased):
# dd if=/dev/urandom of=/dev/sdX
$ sudo dd if=/dev/urandom of=/dev/sdX
Note: shred doesn't work reliably with ext3.
Generally it is advised to use a wired
LAN-connection - as opposed to wireless LAN (WLAN).
For further useful information in regards to wireless security read . If you must
use WLAN please use WPA2 encryption. Everything else can be h4xx0red by a 12-year-old using android-apps such as .
Another thing is: Try only to run services on your machine that you really use and have configured properly. If e.g. you don't use SSH - deinstall the respective client to make sure to save yourself some trouble. Please note that IRC also . Use it with caution or simply use a for stuff like that.
If you do use SSH please consider using or . (If you want to find out what might happen if you don't use such protection see .)
So, let's begin with your firewall. For debian-like systems there are several possible firewall-setups and different guis to do the job. However, I found ipkungfu [an iptables-script] to do the best job while being easy to set up. This is how you set it up:
ipkungfu [basic configuration]
download and install:
$ sudo apt-get install ipkungfu
$ sudo geany /etc/ipkungfu/ipkungfu.conf
uncomment (and adjust):
# IP Range of your internal network. Use "127.0.0.1"
# for a standalone machine. Default is a reasonable
# Set this to 0 for a standalone machine, or 1 for
# a gateway device to share an Internet connection.
# Default is 1.
# Temporarily block future connection attempts from an
# IP that hits these ports (If module is present)
FORBIDDEN_PORTS="135 137 139"
# Drop all ping packets?
# Set to 1 for yes, 0 for no. Default is no.
# What to do with 'probably malicious' packets
# What to do with obviously invalid traffic
# This is also the action for FORBIDDEN_PORTS
# What to do with port scans
enable ipkungfu to start with the system:
$ sudo geany /etc/default/ipkungfu
change: "IPKFSTART = 0" ---> "IPKFSTART=1"
$ sudo ipkungfu
fire up GRC's and check out the awesomeness.
(special thanks to the )
Here you set different ways how to deal with ICMP-packets and other stuff:
$ sudo geany /etc/sysctl.conf
# Do not accept ICMP redirects (prevent MITM attacks)
# TCP Hardening - [URL]http://www.cromwell-intl.com/security/security-stack-hardening.html[/URL]
#ignore all ping
# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0
# Do not accept IP source route packets (we are not a router)
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
# Log Martian Packets
net.ipv4.conf.all.log_martians = 1
After editing do the following to make the changes permanent:
sudo sysctl -p
(thanks to for these settings)
Modem & Router
Please don't forget to enable the firewall features of your modem (and router), disable UPnP and change the usernames and admin-passwords. Also try to keep up with the latest security info and updates on your firmware to prevent using equipment such as You might also want to consider setting up your own firewall using .
you can run a short test to see if your router is to UPnP-exploits.
The best thing to do is to use after-market-open-source-firmware for your router such as , or . Using these you can turn your router into an enterprise grade device capable of some real
Kungfu. Of course they come with heavy artillery - dd-wrt e.g. uses an IP-tables firewall which you can configure with custom scripts.
Intrusion-Detection, Rootkit-Protection & AntiVirus
snort [basic configuration]
The next thing you might want to do is to take a critical look at who's knocking at your doors.
For this we use snort. The setup is straight forward and simple:
$ sudo apt-get install snort
$ snort -D (to run as deamon)
to check out packages live type:
$ sudo snort
Snort should automatically start on reboot.
If you want to check out snort's rules take a look at: /etc/snort/rules
To take a look at snorts warnings:
$ sudo geany /var/log/snort/alert
Snort will historically list all the events it logged.
There you will find nice entries like this...
[**] [1:2329:6] MS-SQL probe response overflow attempt [**]
[Classification: Attempted User Privilege Gain] [Priority: 1]
...and will thank the flying teapot that you happen to use #!
The next thing to do is to set up RKHunter - which is short for [R]oot[K]itHunter.
What does it do? You guessed it: It hunts down .
Installation again is simple:
$ sudo apt-get install rkhunter
The best is to run rkhunter on a clean installation - just to make sure nothing has been tampered with already.
One very important thing about rkhunter is that you need to give it some feedback: everytime you e.g. make an upgrade to your sytem and some of your binaries change rkhunter will weep and tell you you've been compromised. Why? Because it can only detect suspicious files and file-changes
. So, if you go about and e.g. upgrade the coreutils package a lot of change will be happening in /usr/bin - and when you subsequently ask rkhunter to check your system's integrity your log file will be all red with warnings. It will tell you that the file-properties of your binaries changed and you start freaking out. To avoid this simply run the command rkhunter --propupd on a system which you trust to not have been compromised
In short: directly after commands like apt-get update && apt-get upgrade run:
$ sudo rkhunter --propupd
This tells rkhunter: 'sall good.
To run rkhunter:
$ sudo rkhunter -c --sk
You find rkhunter's logfile in /var/log/rkhunter.log. So when you get a warning you can in detail check out what caused it.
To set up a cronjob for RKHunter:
$ sudo geany /etc/cron.daily/rkhunter.sh
insert and change the mail-address:
/usr/local/bin/rkhunter -c --cronjob 2>&1 | mail -s "RKhunter Scan Details" [email protected]
make the script executable:
$ sudo chmod +x /etc/cron.daily/rkhunter.sh
$ sudo rkhunter --update
and check if it functions the way it's supposed to do:
$ sudo rkhunter -c --sk
Of course you can leave out the email-part of the cronjob if you don't want to make the impression on someone shoulder-surfing
your email-client that the only one who's sending you emails is your computer...
Generally, using snort and rkhunter is a good way to become paranoid - if you're not already. So please take the time to investigate the alerts and warnings you get. A lot of them are false positives and the listings of your system settings. Often enough nothing to worry about. But if you want to use them as security tools you will have to invest the time to learn to interpret their logs. Otherwise just skip them.
If you're in doubt whether you did a rkhunter --propupd after an upgrade and you are getting a warning you can run the following command:
$ sudo rkhunter --pkgmgr dpkg -c --sk
Now rkhunter will check back with your package-manager to verify that all the binary-changes were caused by legitimate updates/upgrades. If you previously had a warning now you should
get zero of them. If you still get a warning you can check which package the file that caused the warning belongs to.
To do this:
$ dpkg -S /folder/file/in/doubt
$ dpkg -S /bin/ls
This tells you that the file you were checking (in this case /bin/ls) belongs to the package "coreutils".
Now you can fire up packagesearch.
If you haven't installed it:
$ sudo apt-get install packagesearch
$ sudo packagesearch
In packagesearch you can now enter coreutils in the field "search for pattern". Then you select the package in the box below. Then you go over to the right and select "files". There you will get a list of files belonging to the selected package. What you want to do now is to look for something like:
The idea is to get a file belonging to the same package as the file you got the rkhunter-warning for - but that is not located in the binary-folder.
Then you look for that file within the respective folder and check the file-properties. When it was modified at the same time as the binary in doubt was modified you can be quite certain that the change was caused by a legitimate update. I think it is save to say that some script-kiddie trying to break into your system will not be that thorough. Also make sure to use debsums when in doubt. I will get to that a little further down.
Another neat tool with similar functionality is:
$ sudo apt-get install chkrootkit
$ sudo chkrootkit
Other nice intrusion detection tools are:
Tiger is more thorough than rkhunter and chkrootkit and can aid big time in securing your box:
$ sudo apt-get install tiger
to run it:
$ sudo tiger
you find tiger's logs in /var/log/tiger/
If you feel that all the above IDS-tools aren't enough - I got something for you:
Lynis is an auditing tool for Unix (specialists). It scans the system and available software, to detect security issues. Beside security related information it will also scan for general system information, installed packages and configuration mistakes.
This software aims in assisting automated auditing, software patch management, vulnerability and malware scanning of Unix based systems
I use it. It is great. If you think you might need it - give it a try. It's available through the debian repos.
$ sudo apt-get install lynis
$ sudo lynis -c
Lynis will explain its findings in the log-file.
debsums checks the md5-sums of your system-files against the hashes in the respective repos.
$ sudo apt-get install debsums
$ sudo debsums -ac
This will list all the files to which the hashes are either missing or have been changed. But please don't freak out if you find something like: /etc/ipkungfu/ipkungfu.conf after you have been following this guide...
There are some programs that come with sha256 hashes nowadays. For example: I2P
debsums won't help with that. To check these hashes manually:
$ cd /folder/you/downloaded/file/to/check/to -sha256sum -c file-you-want-to-chec
Then compare it to the given hash. Note: This tool is already integrated to debian-systems.
To make sure eveything that gets into your system is clean and safe use ClamA[nti]V[irus].
$ sudo apt-get install clamav
$ sudo freshclam
To inspect e.g. your download folder:
$ sudo clamscan -ri /home/your-username/downloads
This will ClamAV do a scan recursively
, i.e. also scan the content of folders and inform you about possibly infected files
To inspect your whole system:
$ sudo clamscan -irv --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/media --exclude=/mnt
This will make ClamAV scan your system recursively in verbose mode (i.e. show you what it is doing atm) whilst excluding folders that shouldn't be messed with or are not of interest and spit out the possibly infected files it finds. To also scan attached portable media you need to modify the command accordingly.
Make sure to test everything you download for possible infections. You never know if servers which are normally trustworthy haven't been compromised. Malicious code can be hidden in every usually employed filetype. (Yes, including .pdf!)
Remember: ClamAV is known for its tight nets. That means that you are likely to get some false positives from time to time. Do a web-search if you're in doubt in regards to its findings.
After you set up your host-based security measures we can now tweak our online security.
Using secure and censor-free DNS
To make changes to your DNS-settings:
$ sudo geany /etc/resolv.conf
change your nameservers to trustworthy DNS-Servers. Otherwise your modem will be used as "DNS-Server" which gets its info from your ISP's DNS.
And nah... We don't trust the ISP...
you can find secure and censor-free DNS-servers. The Germans look .
HTTPS-DNS is generally preferred for obvious reasons.
Your resolv.conf should look something like this:
Use at least two
DNS-Servers to prevent connectivity problems when one server happens to be down or experiences other trouble.
To prevent this file to be overwritten on system restart fire up a terminal as root and run:
$ sudo chattr +i /etc/resolv.conf
This will make the file unchangeble - even for root.
To revoke this for future changes to the .conf run:
$ sudo chattr -i /etc/resolv.conf
This forces your web-browser to use the DNS-servers you
provided instead of the crap your ISP uses.
To test the security of your DNS servers go .
What you can also do to secure your DNS-connections is to use .
The thing I don't like about DNScrypt is one of its core functions: to use OpenDNS as your resolver. OpenDNS has gotten quite a bad rep in the last years for various things like aggressive advertising and hijacking google-searches on different setups. I tested it out yesterday and couldn't replicate these issues. But I am certain that some of these "features" of OpenDNS have been actively blocked by my Firefox-setup (which you find below). In particular the addon seems to prevent to send you to OpenDNS' search function when you typed in an address it couldn't resolve. The particular issue about that search function is that it apparently is powered by yahoo! and thus yahoo! would log the addresses you are searching for.
Depending on your threat-model, i.e. if you don't do anything uber-secret you don't want anybody to know, you might consider using DNScrypt, as the tool seems to do a good job at encrypting your DNS-traffic. There also seems to be a way to use DNScrypt to tunnel your queries to a DNS-server other than OpenDNS - but I haven't yet checked the functionality of this.
So, if you don't mind that OpenDNS will know every
website you visit you might go ahead and configure DNScrypt:
Download the .
$ sudo bunzip2 -cd dnscrypt-proxy-*.tar.bz2 | tar xvf -
$ cd dnscrypt-proxy-*
Compile and install:
$ sudo ./configure && make -j2
$ sudo make install
Adjust -j2 with the number of cpu-cores you want to use for the compilation or have at your disposal.
Go and change your resolv.conf to use localhost:
$ geany /etc/resolv.conf
Run DNScrypt as daemon:
$ sudo dnscrypt-proxy --daemonize
According to the :
DNSCrypt will chroot() to this user's home directory and drop root privileges for this user's uid as soon as possible.
I have to admit that OpenDNS is really fast. What you could do is this: You could use OpenDNS for your "normal" browsing. When you start browsing for stuff that you consider to be private for whatever reasons change your resolv.conf back to the trustworthy DNS-servers mentioned above - which you conveniently could keep as a backup file in the same folder. Yeah, that isn't slick, I know. If you come up with a better way to do this let me know. (As soon as I checked DNScrypt's function to use the same encryption for different DNS-Servers I will make an update.)
The next thing on our list is:
Sandfox is a neat little script provided by which runs firefox (and other applications) in a environment which prevents firefox's access to crucial filesystem-areas in case it gets compromised.
$ sudo -s
$ gpg --keyserver keys.gnupg.net --recv-keys 7977070A723C6CCB696C0B0227A5AC5A01937621
$ gpg --check-sigs 0x01937621
$ bash -c 'gpg --export -a 01937621 | apt-key add -'
$ echo "deb [URL]http://ignorantguru.github.com/debian/[/URL] unstable main" >> /etc/apt/sources.list
$ apt-get update
$ apt-get install sandfox
(Thanks to )
$ sudo sandfox firefox
Type "/" into firefox address-bar to check out whether it works. Firefox should now only have access to files it really needs to function and not e.g. /root.
To be able to download stuff from the web you need to add a bind in sandfox's default profile:
$ sudo geany /etc/sandfox/default.profile
Check your systems filename-capitalization to make sure you really grant sandfox access to the right folder
In #! you can easily set this configuration as your default: simply go to "settings"->"openbox"->"GUI Menu Editor"->"Openbox"->"Web Browser". Then simply add the command "sandfox firefox". For this to work you need to once run
$ sudo sandfox firefox
after a system start to create a sandbox. If you happen to find this too much hassle simply go with tradetaxfree's .
After you successfully sandboxed your browser we now continue to make that particular application much
more secure than it is by default.
First go to:
and change these settings:
[Some of these are defaults already - but depending on who was/is using the machine you access the interwebs with and other varying factors you might want to control these settings.]
General"->"when Firefox starts"->"Show a blank page"
"General"->"save files to:"Downloads"
"Content"->check:"Block pop-up windows"
"Content"->"Fonts & Colors"->"Advanced"->"Serif":"Liberation Sans"
"Content"->"Fonts & Colors"->"Advanced"->"Sans-serif":"Liberation Sans"
"Content"->"Fonts & Colors"->"Advanced"->uncheck:"Allow pages to choose their own fonts"
"Content"->"Languages"->choose *only*:"en-us" [remove all others, if any]
"Applications"->choose:"Always ask" for every application - if not possible:choose:"Preview in Firefox/Nightly"
"Privacy"->"Tracking"->check:"Tell websites I do not want to be tracked"
"privacy"->"History"->"Firefox will:"Use custom settings for history"
"privacy"->"History"->uncheck:"Always use private browsing mode"
"privacy"->"History"->uncheck:"Remember my browsing and download history"
"privacy"->"History"->uncheck:"Remember search and form history"
"privacy"->"History"->uncheck:"Accept cookies from sites"
"privacy"->"History"->uncheck:"Accept third-party cookies"
"privacy"->"History"->check:"Clear history when Firefox/Nightly closes"
"privacy"->"History"->"settings":check all -> except:"Site Preferences"
[to enable cookies for certain trusted sites: use:"Exceptions" and paste URL of site and modify settings according to your preference. If you additionally use Cookie-Monster (Add-on) you need to uncheck "Block all cookies" in CM-Options]
"privacy"->"location bar"->"When using the location bar, suggest:"->choose:"Nothing"
"security"->check:"Warn me when sites try to install add-ons"
"security"->check:"Block reported attack sites"
"security"->check:"Block reported web forgeries"
"security"->"Passwords"->uncheck:"Remember passwords for sites"
"security"->"Passwords"->uncheck:"Use a master password"
"advanced"->"General"->"System Defaults"->uncheck:"Submit crash reports"
"advanced"->"General"->"System Defaults"->uncheck:"Submit performance data"
"advanced"->"Update"->check:"Automatically install updates"
"advanced"->"Update"->check:"Warn me if this will disable any of my add-ons"
"advanced"->"Update"->check:"Automatically update Search Engines"
"advanced"->"Encryption"->"Protocols"->check:"Use SSL 3.0"
"advanced"->"Encryption"->"Protocols"->check:"Use TLS 1.0"
"advanced"->"Encryption"->"Certificates"->"When a server requests my personal certificate"->check:"Ask me every time"
at the most use:
Flash [Be aware of the latest in flash!
Only allow them to run on trusted
[cool little addon which does exactly what its name says and also has some more tweaks in the settings]
[Allows you to Manage your Cookie-Policies. For less baggage use Firefox/Iceweasel "Preferences" -> "Privacy"]
[Download via EFF.org] [settings: enable SSL-Observatory but don't allow to transmit ISP-data]
[go to "settings" and check "also apply on whitelisted sites"]
[SSL-Cerfiticate-Control - go to settings: "notary servers" -> check "only contact when websites cause security error"]
[controls your HTTP-Referers - setting: "block" -> "3rd parties only"]
[rejects cross-site requests]
[Web of Trust - user based website ratings that show up in websearches. Caution: Not very accurate. Always double check when in doubt. This addon tends
to get abused by different groups of users who either give malicious sites good ratings - or flag perfectly good sites.]
[Nice addon to help your password management. Use "F2" when entering a password into a password field when setting up a new account somewhere to create a MD5-hash using your password and the domain. (When logging in you have to select the password-field and press F2 again to run the hashing.) This way you can use the same password on different sites without having to worry about security implications - because every site gets its own password generated through the hash. The tool is provided by Standford University and can be trusted. No data is actually transmitted to their servers. The hash is generated using your local java-script. If you need to login from a machine that doesn't have pwdhash installed: go to -> their SSL is very
[a convenient Proxy Switcher]
[Does exactly that. But be careful: If you set your user-agent as shown below - using this addon it will overwrite these settings and will not automatically restore them if you turn off the switcher. So you would have to manually reconfigure about:config again. Which kinda sucks. But you can get a whole load really cool user agents . Simply download the .xml and import it to the Useragent Switcher. There are really neat current agents in there: e.g. all kinds of different web browser for all OSs and of course various bots. Google bot comes in handy when you need access to some forum...
[Has some cool features. If you like inspecting websites just check it out.]
[Creates disposable mail-addresses]
You don't need . The above mentioned Adblock lists do a much better job protecting you from web-tracking without using the additional resourced Ghostery uses.
Of course there are more addons you could use. But I don't really see the point of them. Most of them either are snake-oil or even dangerous. But please inform me if you happen to come across something really
cool which could help improve security which none of the setting provided here can do.
To keep your ISP and possible MITM-attackers from reading what you do on the web always
use SSL - as far as it is available. To help with this use:
To get them go .
The user "" has provided easily installable SSL-searchbar-plugins
You get SSL-plugins for all the alternative search-engines like ixquick, duckduckgo etc. there. Install those you happen to use.
also looks promising. But I haven't tried it out extensively.
The next thing to do is to change macromedias flash-settings:
And fight yourself through their nasty settings-manager. Set everything to "0" or "never allow"/"never ask again" and
delete all stored website-content. Give special attention to the "webcam and mic"-options...
You might as well set the permissions of your .macromedia folder to read only
- but that's kind of unnecessary because you want to make sure to edit the options mentioned above - to make sure that you don't allow websites to use your mic or webcam... [I actually take this one step further by disabling them in BIOS and
sticking some neatly cut little piece of black cardboard on my webcam. Just because you're paranoid doesn't mean they aren't after you
] And if you set the parameters in the settings-manager accordingly nothing will be written to that folder anyway.
Now we come to the fun part. Finetuning Firefox using about:config. If you've never done this before: No reason to freak out. It's really easy.
[You can simply copy/paste these variables into the search-bar at the top: e.g. "browser.cache.disk.enable" and
then double-click on the entry that shows up to modify the settings.]
---disable browser cache:
---disable history & localization
---misc other tweaks:
network.dns.disablePrefetch:true -> very important when using TOR
network.dns.disablePrefetchFromHTTPS -> very important when using TOR
network.http.spdy.enabled:false ---> use http instead of google's spdy
plugins.click_to_play:true ---> also check each drop-down-menu under "preferences"->"content"
security.enable_tls_session_tickets:false ---> disable https-tracking
security.ssl.enable_false_start:true ---> disable https-tracking
extensions.blocklist.enabled:false ---> disble Mozilla's option to block/disable your addons remotely
webgl.disabled:true ---> disable WebGL ([URL]http://security.stackexchange.com/questions/13799/is-webgl-a-security-concern[/URL])
network.websocket.enabled:false ---> ***Tor Users: This is extremely important as it could blow your cover! See: [URL]http://pastebin.com/xajsbiyh***[/URL]
---make your browsing faster:
[thanks to machinebacon for these .
Prevent Browser Fingerprinting [still in about:config]
For all Firefox Versions after 17.0 [you should be using current versions and update them regularly anyway - to do this go to "preferences"->"advanced"->"update" select: "automatically install updates" & "warn me if this will disable any of my addons"] [not required for iceweasel]
For the following changes right-click in about:config and select "new"->"string" and enter in this order:
general.useragent.override Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0
general.appversion.override 5.0 (Windows)
general.oscpu.override Windows NT 6.1
general.useragent.vendor [enter variable - but leave value blank]
general.useragent.vendorSub [enter variable - but leave value blank]
network.http.accept-encoding gzip, deflate
This creates a fake-profile of your browser via the readable HTTP-headers it sends.
Check out .
With all the above settings I get 8.1 bits of identifying information at Panopticlick for my browser - which is really
"In particular, a fingerprint that carries no more than 15-20 bits of identifying information will in almost all cases be sufficient to uniquely identify a particular browser, given its IP address, its subnet, or even just its Autonomous System Number."
Source: EFF's [page 3]
Also check your settings on ip-check.info - but don't rely on it. Apparently they are quite busy promoting their JonDonym-Browser and services - which quite frankly I don't think anyone needs. I would rather warn you to use it since according to this JAP/JonDonym has implemented tracking-features wh