Hacking

A tripwire installation and configuration on debian jessie MATE

trip

Tripwire is an intrusion detection system that keeps your critical system files and reports under control if they have been destroyed or modified by a cracker (or by mistake). It allows the system administrator to know immediately what was compromised and fix it.

Using tripwire makes sense only if it is installed, fully configured and initialized at the very first boot after an installation from scratch, before ever connecting to the Internet or doing anything else. It takes only one attack to install a back door. Using tripwire after such an event would guarantee that the back door remains just as open as the day a cracker installed it!

One way to do this is to take the machine to single-user mode, reinstall all system binaries, and run tripwire in initialization mode before returning to multi-user operation.

Of course, even if you don’t want to or can’t re-install everything now, nothing prevents you from downloading the package anyway and becoming familiar with it. Testing, a good thing!!!!!

Installing tripwire

… on an off-line Linux box

  • Launch Synaptic on the offline computer. If not yet installed, install synaptic.
  • Mark the packages you wish to install.
  • Choose File-> Generate package download script.
  • Save the script to your USB stick.
  • Take the USB stick to an online Linux computer and run the script there from the USB stick. It will download only the packages required by the offline computer to the USB stick.tripwire1
  • Insert the USB stick into the offline computer.
  • Launch Synaptic and click on File-> Add downloaded packages
    Select the directory on your USB stick containing the downloaded *.deb files and click Open. The packages will be installed.

During install, you will be asked if you wish to set the site and local passphrase. Make ’em good, long, include upper-case and lower-case, numbers and special characters. Preferably store both in a keepassx database (or other password management tool) on an encrypted USB stick.

tripwire3

After install you are notified:

The Tripwire binaries are located in /usr/sbin and the database is located in /var/lib/tripwire. It is strongly advised that these locations be stored on write-protected media (e.g. mounted RO floppy). See /usr/share/doc/tripwire/README.Debian for details.

And I would not be me, if I had not had that thought, “What if I *do* that, what if I put the binaries, database AND reports on an encrypted usb stick or external drive? What could possibly go wrong?” A stick can easily overflow if many reports are generated, so an external drive it is. You can check state, and turn write protect of a drive (or USB stick) on and off (during initialization and updates) with hdparm. This would require copying the directories to a drive, making changes to tripwire cleartext configuration files, generating a new tripwire encrypted configuration file, and when everything works flawlessly (ahem) removing the directories and the configuration cleartext files from the local machine.

Configuration binaries and database

tripwire4

Just after install the tripwire directory cd /etc/tripwire contains a number of files, two of which are useful for its configuration:

  • twcfg.txt is for general configuration and can easily be the same for all the computers on the same local network. It contains “things” like the location of the tripwire database, instructions for minimising the amount of time the passphrases are kept in memory, and the number of redundant reports.tripwire5
  • twpol.txt contains the policy that declares all the objects that must be monitored and what to do when one of them is lost or altered. Unlike the configuration file, the policy could (and almost certainly will) vary across the several computers on the same network.tripwire6

For security reasons (preventing a malicious intruder from spoofing tripwire into giving a false “okay” message) tripwire uses these cleartext files to create binary files for database checking rather than the cleartext files (that are best immediately removed after the deed).

Backup files

If you make incorrect edits to either of the cleartext files, you will have to restore from backup or tripwire will not be able to create its database. Before making modifications to the configuration files, make a backup first:

root@debian:/etc/tripwire#: cp twcfg.txt twcfg.txt.old
and/or
root@debian:/etc/tripwire#: cp twpol.txt twpol.txt.old

Copy binaries and database

On an external drive, create a directory tripwire to hold both the tripwire binary in /usr/bin/ and databases in /var/lib/tripwire so that if and when your system is compromised and the drive is mounted, the intruder would need root to change the files (-rwxr-xr-x). Also create a /etc/tripwire directory for file manipulation on the drive.

The binaries to copy from /usr/sbin are:

  • tripwire: The main file; used for initialising the database, checking the integrity of the file system, updating the database and updating the policy.
  • twadmin: tripwire’s administrative and utility tool; used for creating and printing configuration files, replacing and printing a policy file, generating site and local keys and other encryption related functions.
  • twprint: Used to print the reports and database in human-readable format.
  • siggen: Generates the various hashes that tripwire supports for checking the integrity of files.

With drive being the name of your drive:

root@debian:/# cp -R /var/lib/tripwire /media/user/drive/tripwire/var/lib/
and copy the binaries tripwire, twadmin, siggen and twprint:
root@debian:/# cp /usr/sbin/tripwire /media/user/drive/tripwire/usr/sbin/
root@debian:/# cp /usr/sbin/twadmin /media/user/drive/tripwire/usr/sbin/
root@debian:/# cp /usr/sbin/siggen /media/user/drive/tripwire/usr/sbin/
root@debian:/# cp /usr/sbin/twprint /media/user/drive/tripwire/usr/sbin/

Configuration file changes

root@debian:/# geany /etc/tripwire/twcfg.txt
Change DBFILE and REPORTFILE to reflect the location on your drive:

tripwire7

Likewise for twpol.txt change TWBIN and TWVAR:

root@debian:/# geany /etc/tripwire/twpol.txt
tripwire8

Initial run

Install default policy as root (capital P):

root@debian:/# /usr/sbin/twadmin -m P /etc/tripwire/twpol.txt
You will be asked for your site passphrase. Still as root, generate the initial database:
root@debian:/# /usr/sbin/tripwire -m i
You will be asked for your local passphrase. Then a bunch of these appear:
### Warning: File system error.
### Filename: /proc/5199/fd/4
### No such file or directory
The example twpol.txt files distributed with tripwire contains anything that could be on a UNIX system, so it is guaranteed to complain about programs that you never installed or placed in a different location. These false positives are created when there is a discrepancy between the default policy and the current local configuration.

Until you get:
tripwire10
Put the generated debian.twd database on your stick or drive in the designated space for the database:

root@debian:/# cp /var/lib/tripwire/debian.twd /media/user/drive/tripwire/var/lib/tripwire/

More customisation

After the initial database is created, some further customization is necessary to prevent these large numbers of false positives.
The “thing” to do to create a good policy is to remove as many unneeded programs as possible before starting. Next, to make your usage as quick and effective as possible, your policy must cover everything you really need to monitor and nothing else. This includes, at least, all the system binary and library directories (minimally the contents of /bin, /sbin, /usr/bin, /lib) and the corresponding configuration files in /etc/.

As of version 2.3.1.2-5, the tripwire package manages policy at a directory level: if a directory appears in the policy, tripwire will add the files in that directory. Not all directory policy entries are recursive and tripwire may not check the contents of those subdirectories.

To generate a listing of the discrepancies between the local system and the default policy:

root@debian:/# /usr/sbin/tripwire -m c | grep Filename >> twtest.txt
Waaaait for it! When this listing has been generated, edit /etc/tripwire/twpol.txt again, and comment out or delete each of the filenames listed in twtest.txt.
root@debian:/# geany /etc/tripwire/twpol.txt
And there are other files in the default policy that may not make sense to monitor on the local system. These include lock files (which identify that some process is in use) and pid files (which identify the process ID of some daemons). Such files are likely to change often, if not at every system boot, and they can cause tripwire to generate false positives. You can comment out all of the /var/lock/subsys entries as well as the entry for /var/run.

After that you need to re-install default policy and generate the database again. This is a good time to test running it from the drive (as root):

root@debian:/# /media/user/drive/tripwire/usr/sbin/twadmin -m P /etc/tripwire/twpol.txt
and:
root@debian:/# /media/user/drive/tripwire/usr/sbin/tripwire -m i
You will be asked for your site and local passphrase. You get a message: Wrote database file: /var/lib/tripwire/debian.twd

Problems

Mounting /dev and /proc subs

*** Processing Unix File System ***
Performing integrity check...
The object: "/dev/hugepages" is on a different file system...ignoring.
The object: "/dev/mqueue" is on a different file system...ignoring.
The object: "/dev/pts" is on a different file system...ignoring.
The object: "/dev/shm" is on a different file system...ignoring.
The object: "/proc/sys/fs/binfmt_misc" is on a different file system...ignoring.
The /dev entries spell that the /dev file system also has other file systems mounted as /dev/hugepages, /dev/mqueue, /dev/pts, and /dev/shm. Similar objects in proc are also ignored. Directories in /proc change all the time and it is a pseudo-filesystem. You can’t create files in /proc. My solution:

tripwire11

After which these appeared:

The object: "/proc/sys/fs/binfmt_misc/register" is on a different file system...ignoring.
The object: "/proc/sys/fs/binfmt_misc/status" is on a different file system...ignoring.
binfmt_misc is a capability of the Linux kernel which allows arbitrary executable file formats to be recognised and passed to certain user space applications, such as emulators and virtual machines. The executable formats are registered through a special purpose file system interface (similar to /proc). Debian-based distributions provide the functionality through an extra binfmt-support package. Needs monitoring. So, added those two as well.

Paths

Another problem is that even with the paths set to the drive directories and files, when running tripwire from the drive the resulting report is put in the /var/lib/tripwire directory on the local machine (not on the drive), and when re-initialising the database the database is also put in the directory on the local machine. Plus that running tripwire from the drive expects the database in /var/lib/tripwire on the local machine.

Rather than hacking the code, I’ll use a workaround and add two little zero version scripts to my script wardrobe, one for running tripwire from the drive:

#!/bin/bash
# 
DRIVE=/media/user/drive/tripwire/
DBLOCAL=/var/lib/tripwire/debian.twd
DBDRIVE=${DRIVE}var/lib/tripwire/debian.twd
REPORTS=/var/lib/tripwire/report/

if test ! -f "$DBDRIVE"
then 
  echo "Error - $DBDRIVE not found"
  exit 1
fi
echo "debian.twd exists on drive, fetching it ..."      
cp ${DBDRIVE} /var/lib/tripwire/
echo "running tripwire ..."
${DRIVE}usr/sbin/tripwire -m c
echo "moving report to drive..."
mv ${REPORT}*.* ${DRIVE}var/lib/tripwire/report/
echo "removing database from local machine..."
rm ${DBLOCAL}
echo "done."
Or something like that. Give it a name like “runtripwire.sh” and run it with
sudo sh runtripwire.sh
And another one for updating the tripwire policy database:
#!/bin/bash
# Install policy, initialise database, copy the new database to the
# external drive and remove it from the local machine.

DRIVE=/media/user/drive/tripwire/
DBLOCAL=/var/lib/tripwire/debian.twd
DBLOCALBAK=${DBLOCAL}.bak
BINARY=${DRIVE}/usr/sbin/
ADMINBINARY=${BINARY}twadmin

# Check if cleartext policy file exists or not
if test ! -f "${DRIVE}etc/tripwire/twpol.txt"
then 
  echo "Error - ${DRIVE}etc/tripwire/twpol.txt not found"
  exit 1
fi
echo "cleartext policy config file exists on drive, getting it"
cp ${DRIVE}etc/tripwire/twpol.txt /etc/tripwire/ 

# Check if twadmin exists on drive or not
if test ! -f "$ADMINBINARY"
then 
  echo "Error - $ADMINBINARY not found"
  exit 1
fi
echo "Binary twadmin found, installing policy ..."
${DRIVE}usr/sbin/twadmin -m P /etc/tripwire/twpol.txt
echo "initialise database ..."
${DRIVE}usr/sbin/tripwire -m i

# Check if debian.twd exists on local machine or not
if test ! -f "$DBLOCAL"
then 
  echo "Error - $DBLOCAL not found"
  exit 1
fi
echo "Resulting database found on local machine, copying resulting database to drive ..."
cp ${DBLOCAL} ${DRIVE}var/lib/tripwire/
echo "removing database from local machine ..."
rm ${DBLOCAL}

# Check if debian.twd.bak exists on local machine or not
if test ! -f "$DBLOCALBAK"
then 
  echo "$DBLOCALBAK not found, no need to remove"
  exit 1
fi
rm /var/lib/tripwire/debian.twd.bak
echo "done."
Or something like that. Give it a name like “updatetripwirepolicy.sh” and run it with
sudo sh updatetripwirepolicy.sh

Cleaning up

It is now safe to delete the clear text versions of the tripwire policy and configuration files:

root@debian:/# rm /etc/tripwire/twcfg.txt /etc/tripwire/twpol.txt
If they need to be restored, cleartext versions of these files can be created from the by tripwire encrypted versions (lowercase p):
root@debian:/# /media/user/drive/tripwire/usr/sbin/twadmin -m p > /etc/tripwire/twpol.txt
You can keep the /var/lib/tripwire directory on your local system as if you do not have a functional tripwire but remove the database file. Save a copy of it, at least initially (and periodically if possible) to read-only media. Having read-only copies of the database file is the only way to guarantee 100% that tripwire’s database is authentic.

Note: Addition of packages

The management at a directory level also means that addition of packages to a system will almost certainly require the updating or regeneration of the tripwire database.


Anonymising blogging with A/I

Guest post by @reginazabo

If you are planning to open a website or a blog, one of the first things you should consider is that, if you want your own domain, you need to register it, which may give out your true identity — all assignees of a domain are recorded in a database that can be easily queried through a simple command (whois) or on several websites such as Gandi: Whois

You can register your domain giving the data of an association and using a prepaid credit card that is not connected to your data (if available in your country), or else you can use a registrar like Gandi.net that allows you to hide personal data.

When you’ve registered your domain, you can open a website with your own domain with A/I’s secure webhosting service.

Besides its web spaces, A/I also offers a blogging platform.


Hello World Tahoe-LAFS through i2p on Debian

kill-your-tv

Tahoe-LAFS is a free and open cloud storage system. It distributes your data across multiple servers. Even if some of the servers fail or are taken over by an attacker, the entire file system continues to function correctly, preserving your privacy and security. With Tahoe-Lafs for i2p (only exists for linux) we can use the “underground” cloud for example, for a library of documents, videos.

Requirements: An installed, configured and running i2p router.

Installation tahoe-lafs

There are two competing implementations of Tahoe-LAFS available for i2p: Ducks’ method which goes through the eeProxy and Socrates’ method which communicates via BOB. This is Duck’s, via killyourtv.

repository-add

To use the repository with apt in Debian over i2p:

  • Add a line like deb http://localhost:8999/debian wheezy main or deb http://localhost:8999/debian testing main (for jessie) to the /etc/apt/sources.list.d/i2p.list you created when installing i2p. Pick a free port, it doesn’t have to be 8999 as per this example.
  • Create a standard client tunnel pointing to killyourtv.i2p, accessible via port 8999 (or whatever free port you chose above). Enter:tunnel-killyourtv
    • Name:(N): killyourtv.i2p
    • Description:(E): Killyourtv repository
    • Access Point: Port: 8999 (or the port you chose)
    • Reachable by(R): 127.0.0.1
    • Tunnel Destination(T): killyourtv.i2p
    • Tick box Auto Start(A): check

    If your protections refuse the above standard client tunnel link, at the bottom of the tunnelmanager page in your i2p router click create:
    at-bottom-create

Update:

sudo apt-get update

Install:

sudo apt-get install i2p-tahoe-lafs

Installation plugin

plugin-page

Go to the plugins page for the Tahoe-LAFS Controller. The address marked by the red arrow needs to be entered in the bottom of another page, the i2p clients configuration page. Wait for it!

Create a client node

Create a client node on the command line (no sudo):

tahoe create-client

Configuration

Edit the configuration file ~/.tahoe/tahoe.cfg. Modify the following options, the other values should be left at default for now:

  • Specify a nickname for your node. This is shown to all nodes in the grid so choose the nickname carefully.
  • The web.port number and bind address for the web interface can be changed if desired. This should not be opened up to the public; see above privacy warning.
  • Uncomment http_proxy (remove the # in front) and enter the i2p HTTP Proxy. Most users will enter 127.0.0.1:4444 here.
  • Uncomment tub.location (remove the # in front) but leave it empty. This will prevent your other interfaces besides 127.0.0.1 from being broadcast to the introducer. WARNING: Failure to do this will cause you to leak your IP address!
  • Specify the introducer.furl. This defines the grid and should be published to everyone who wishes to connect to this grid. This example below points to a test introducer operated by KillYourTV:
    introducer.furl = pb://c6w5ernw7y7rp3uwmdyu5clujyt2y4m4@w2zrwz5gplkkufix7cb4gmxfbrkwg2abnsgk62bm5iifzlahe7kq.b32.i2p/introducer

Install grid-updates

Grid-updates is a script that retrieves important NEWS alerts and keeps your introducer lists up-to-date:

sudo apt-get install grid-updates

Restart Tahoe

Time to start Tahoe. At any point you can use tahoe stop, tahoe start, tahoe restart (no sudo):

tahoe start

Test

If all went well, you have a web interface on http://127.0.0.1:xxxx/ (where xxxx is your web.port) and of course, the command line interface. And of course, the command line.

If, like me, you are still above ground now and then (albeit with heavy use of VPN and tor services) in the same browser, and using foxyproxy for that, don’t forget to whitelist those http://127.0.0.1:3456/* addresses in the i2p router proxy.
welcome

Start Up

Add tahoe start to your startup items:
tahoe-start


A (more) secure host: running tiger

look-at-all-the-fucks-i-give-tiger-meme1Tiger supports multiple UNIX platforms it is free and provided under a GPL license. Tiger is used as a security audit and is useful both for system analysis (security auditing) and for real-time, host-based intrusion detection. More on its history and resurrection here.

It consists of Bourne Shell scripts, C code and data files used for checking for security problems on a UNIX system. It scans system configuration files, file systems, and user configuration files for possible security problems and creates a report on issues found.

Installing

root@host:# apt-get install tiger

Configuration

You can mess with the tiger variables in the /etc/tiger/tigerrc configuration file. For each available module there is a corresponding variable in the file that determines whether the module is run. A variable can be set equal to Y to run, or N to skip. Other configuration variables will modify the behaviour of some modules, and can be adjusted based on the operating system.

The /etc/tiger/tiger.ignore configuration file defines the set of messages that will not be presented in the report even if any of the modules generate them. All entries (per line) are used as extended regular expressions that are compared against each message (mind the overhead which grows with the size of the file).

Usage

The command tig‐exp(8) can be used to obtain explanations of the problems reported by tiger. Doing a first run can be shocking (not boring). For all listed fixes below the explanations are included.

This run was done on a fresh debian wheezy with MATE desktop VM, after installing harden-servers and harden packages (in that order), and making some changes to the sysctl.conf file.

Checking passwd files

--WARN-- [pass014w] Login (name) is disabled, but has a valid shell.
The listed login ID is disabled in some manner (‘*’ in passwd field, etc), but the login shell for the login ID is a valid shell (from /etc/shells or the system equivalent). A valid shell can potentially enable the login ID to continue to be used. An attacker can hide programs within these shells by simply ‘su’ing into these accounts.

Debian comes with some predefined users listed in /etc/passwd:

  • The default behavior is that UID’s from 0 to 99 are reserved in Debian to ease the installation of some services that require that they run under an appropriate user/UID. If you do not intend to install these services, you can safely remove those users who do not own any files in your system and do not run any services.
  • UID’s from 100 to 999 are created by packages on install (and deleted when the package is purged). Some of the accounts in this range are users linked to programs you’re running. In general, it is better to prune your system via the associated packages than try to manage them manually.
  • Manually created users end up with a UID just above 1000 (unless you manually specified the uid).

For example www-data in most cases, does not need a shell, but some cgi could need it. Historically all users under UID 99 had a /bin/sh as login shell, and the ones found and listed here by tiger are historic or legacy users, for all “modern” linux services already come preconfigured to “/bin/false”. For those not preconfigured, you can dig into your system to know what each user does there:

  • Do a top or a ps -aux and check the users; if there’s a process started by “nobody” user you can’t delete it.
  • Also check crontab and cron.d; if you delete a user required for starting a cron job, that job never will work again.
  • Another useful check is to check the /etc/shadow file and see which second fields are X (crossed out) for which accounts.

If you conclude a process shouldn’t be there, then stop the daemons, uninstall its packages, and then delete the users. If you are unsure about deleting a user used as administrative user you can set its shell to /bin/false or /sbin/nologin (or something else that doesn’t exist). The user will remain there but nobody will get a shell from it.

Always leave the shell for your user and root user. Whatever you do, do NOT remove or change the shell for root.

--WARN--­­ [pass015w] Login ID sync does not have a valid shell (/bin/sync)
The listed login ID does not have a valid login program or shell. Usually these Shells are defined in /etc/shells.

This is a special case in which there is not a valid shell for sync. /bin/sync is a valid file with a valid purpose. You can ignore.

--WARN­­-- [pass006w] Integrity of password files questionable (/usr/sbin/pwck ­r).
The password files have integrity issues as found by pwck -r. This can lead to looping of password manipulation programs and to authentication or login issues if not corrected. Install the relevant packages or create the directory and set permissions for only limited access.
root@host:# /usr/sbin/pwck -r

Checking user accounts

--WARN­­-- [acc022w] Login ID nobody home directory (/nonexistent) is not accessible.
But without a valid home directory, the user could end up with / as the home directory. You can disable his shell in /etc/passwd by setting it to /bin/false or /sbin/nologin and ignore the resulting error, or you can create the directory, change its ownership and persmissions.
mkdir /nonexistent
chown nobody:nobody /nonexistent
chmod 400 /nonexistent

Checking cron entries

Cron allows users to submit jobs for the system to do at a particular, possibly recurring time. It can be very useful, but also has a very real potential for abuse by either users or system crackers. Users can be restricted to use cron by creating a /etc/cron.allow (holding only system administrators) or a /etc/cron.deny file (listing which users are not allowed access).

--WARN-- [cron004w] Root crontab does not exist
Not a problem. Ignore.
--WARN-- [cron005w] Use of cron is not restricted
For standard Debian systems, all users may use this command. Use the fix on Linux/UNIX Restricting at/cron Usage To Authorized Users here or ignore.

Checking services

--WARN--­­ [inet003w] The port for service (x) is also assigned to service (y)
A program with a port assigned to TCP and a second entry for the same port with UDP. These service ports are defined in /etc/services and “double entries” is quite normal (it is about synonyms). You can just ignore or review these and make sure they are all synonyms and you don’t have two very different programs accessing the same port. Check /etc/services against the file the official assigning authority provides. Review open ports and if any, either uninstall or disable services you don’t use or want. Be careful.

Checking system file permissions

--ALERT-- [perm023a] /bin/su is setuid to `root'
The explanation of tiger reads: The indicated file has the setuid bit set, but it should not have it. This should be changed by using ‘chmod u-s file’ where ‘file’ is the indicated file. The system should be checked for signs of intrusion.

Restricting the su command to superuser only in Linux can affect some apps and packages that link to suid rooted su binary. For example, on debian it leads to an authentication failure when ‘su’ing in console or terminal of a user. My recommendation is to ignore this and those like it. You also don’t, for example, want to remove the suid bit from /usr/bin/passwd, for if you do no user will be able to change password.

Everything from /bin/, /sbin/, /usr/bin and /usr/sbin should be safe, they are part of the base OS. The most common reason for any program to be setuid is to enable it to act as root (setuid root) for access to hardware, secure storage, devices …

AND any vulnerability in a program that is set up as setuid root can get an attacker root-level access to your box, by running the command as a regular user (privilege escalation). If you can avoid it (or doing so is inconvenient or opens up other holes or cans of worms and authentication failures), you don’t want things to run setuid root.

If you are mounting shares that have setuid root files on them that were created by a user on another box, they can be used to own your box. There are options to mount such shares no-setuid – so the setuid bit on files will be ignored on that filesystem.

In particular, you don’t want files that are setuid to be writable by non-root users, otherwise someone could replace them with malicious code that will then be executed as root.

If you find setuid binaries in non-binary filesystem locations (especially in for example /tmp or anywhere under /var) whose origins are unknown you may have been hacked. A setuid enabled binary for root under /home/username/crack smells definitely fishy.

You can find all files (in /usr/local/bin) with S_ISUID bit set with:

root@host:# find /usr/local/bin -perm +4000
And all files with S_ISUID and that are writable by owner with:
root@host:# find /usr/local/bin -perm -4200

Checking network configuration

--WARN-- [lin017w] The system is not configured to log suspicious (martian) 
         packets
Fix with:
root@host:# sysctl ­w net.ipv4.conf.all.log_martians=1
root@host:# sysctl ­w net.ipv4.conf.default.log_martians=1
Yes, yes, I had forgotten those default versions. See here corrected.

More later …


A (more) secure host: everything under control

sysctl is a tool for examining and changing kernel parameters at runtime, a near-necessary tool in the defense from malware.

geany /etc/sysctl.conf
For now it was naught more than removing a few comment-out chars and adding a few lines. More later.
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additonal system variables
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1

###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# 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.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
Resources:


Setting DNS nameservers in debian

leaky-boat_1442059i

Fail

In case the network you hook into uses DHCP and you set your DNS nameservers (in debian) manually in /etc/resolv.conf, any change will be lost as it gets overwritten next time something triggers resolvconf.

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
And adding nameservers after a loopback in interfaces doesn’t work either.

Why?

resolvconf is a set of script and hooks managing DNS resolution using DHCP client hooks, a network manager plugin and /etc/network/interfaces to generate a list of nameservers and domain to put in /etc/resolv.conf

Then how?

The /etc/resolvconf/resolv.conf.d directory (probably) contains base, head, original and tail files in resolv.conf format:

  • base: used when no other data can be found
  • head: for the header of resolv.conf, can be used to ensure a DNS server is always the first one in the list
  • original: backup of your resolv.conf at the time of resolvconf installation
  • tail: appended at the end of the resulting resolv.conf

Open the head file with your favorite editor for it (geany, vi, vim, nano) as root (sudo, su or root terminal). The head file contains the same warning as above … but in this case it is there so that when the resolv files are constructed, the warning will ultimately work its way into the resulting resolv.conf file.

Just add (or replace) the nameservers you picked from for example, the opennic project or the wikileaks alternative DNS list:

nameserver nnn.nnn.nn.nnn
nameserver nn.nn.nnn.nnn
Then update:
user@host:~$ sudo resolvconf -u
And test by viewing the results in /etc/resolv.conf

Set up a diskless debian LiveCD VM for managing gateway VMs

eaze5For isolating management functions of gateway VMs we best use a LiveCD VM. I chose a debian LiveCD. There is no 4GB memory limit with a 64-bit OS, so use that if your hardware supports it.

This post is based on the recipes in Installing VirtualBox and creating Linux VM’s and has images of some of the steps and some comments added to them.

Installing a debian Live/CD in a VM

  1. Torrent or download the latest Live install .iso file of your choice (check its accompanying md5 or sha256 key if downloading with the command md5sum or sha256sum)
    user@host:~$ md5sum some-live-install.iso
    or
    user@host:~$ sha256sum some-live-install.iso
    and compare the output with key listed in the associated md5 or sha256 file.
    For managing pfsense gateway VM’s, a debian xfce minimal install wurks and does not take up too much space.
  2. In VirtualBox create a New VM. Select OS type and Version, in my case that is Linux resp. Debian (64 bit)1 GB memory; Do not add a virtual hard drive and create.2728
  3. More settings. In VirtualBox, select the LiveCD install VM you just created and up top click Settings. In General leave Shared Clipboard and Drag’n’Drop set to Disabled; In System, remove floppy from boot order. Change boot order to Hard Disk, CD/DVD, and enable PAE/NX; ; In Audio and USB disable support (uncheck checkboxes); In Display increase video memory to 128 MB (unless host RAM is limited).29
  4. In Storage, delete IDE controller and attached CD/DVD drive (right click Controller: IDE and in menu choose remove). Under the SATA controller, create two CD/DVD drives. For the SATA port 0 drive, add the Live installer iso image, and enable Live CD/DVD. Add another CD/DVD driver for the Guest Additions that you can pick from virtualbox.org. Click OK.303135
  5. Start the VM. Choose Live. 33

Configuring a shared folder between host and Live/CD VM

Note: By default, there is not any root password. You can switch to root with sudo -i or set a password for root with sudo passwd. The user password for the live user is ‘live’.

Installing the VirtualBox guest additions is necessary for using (temporarily) shared host folders. The VM has no persistent storage, so every time management functions require fetching specific files from the host, these steps need to be done to install the guest additions and shared folders:

  1. run VBoxLinuxAdditions.run36
  2. Create a to be shared folder on the host:
    user@host:~$ mkdir /home/user/Shared
  3. On the guest LiveCD VM go to Devices up top in the menu bar, and select Shared Folders. Click the + icon and choose the host folder just created. OK.37
  4. On the guest open a terminal:
    user@debian:~$ sudo mkdir host
    user@debian:~$ sudo mount -t vboxsf Shared host
    38
  5. Make your moves. Do your thing(s).
  6. Leave no trace. Nothing needs to be removed on the guest before a power down. By design (using a LiveCD) no data on it is persistent. After powering down the pfSense management VM, remove the Shared folder on the host. Nothing remains except perhaps maybe for some traces lingering in host memory cache (cache policy is Least Recently Used), soon to evaporate. Or, for immediate clearing, try your hand at drop_caches.
    user@host:~$ sudo sh -c "sync; echo 3 > /proc/sys/vm/drop_caches"

Set up pfSense gateway VMs as VPN routers

routerThe pfSense® project is a free, open source customized distribution of FreeBSD specifically tailored for use as a firewall and router that is entirely managed via web interface. In addition to being a powerful, flexible firewalling and routing platform, it includes a long list of related features and a package system allowing further expandability without adding bloat and potential security vulnerabilities to the base distribution. More on pfSense here.

I’m using instances of this pfSense gateway in VM’s for experimenting with nested chains of VPNs and Tor.

This post is based on the recipes in Creating pfSense® 2.1.5 VMs as VPN Clients and has images of some of the steps and some comments added to them.

Installing pfSense in a VM

  1. Download the latest .iso pfSense file and its accompanying md5 or sha256 file from pfsense.org. Verify the md5 or sha256 checksum of the .iso file with (replacing x.x.x with version numbers of your download):
    user@machine:~$ md5sum pfSense-LiveCD-x.x.x-RELEASE-amd64.iso.gz
    or
    user@machine:~$ sha256sum pfSense-LiveCD-x.x.x-RELEASE-amd64.iso.gz
    and compare the output with key listed in downloaded md5 or sha256 file.

    4

  2. In VirtualBox create a new VM; Select BSD and FreeBSD (64 bit); 512MB memory; Create a new hard disk using the defaults (VDI, dynamically allocated, 2GB) and create.6811
  3. More settings. Select the pfSense gateway VM in VirtualBox and up top click Settings. In System, remove floppy from boot order. Change boot order to Hard Disk, CD/DVD, and enable PAE/NX; In Audio and USB disable support (uncheck checkboxes);1213
  4. In Storage, add the installer image to the virtual CD/DVD drive. When clicking on Empty the drive appears on the right hand side. Click on the little CD/DVD icon, and attach the pfsense iso file. 14
  5. In Network, if this is a first pfSense VM in a chain, keep the default network adapter connected to NAT (make no changes in advanced settings). If this is the second pfSense VM in a VPN chain and it will connect through another pfSense VPN-gateway VM, connect this adapter to that internal network. Connect the second network adapter to an internal network by naming it (make no changes in advanced settings). Done with the additional settings.1817
  6. Start the pfSense VM. Choose 1 to boot (or not for it is default and you have only seconds). 26
  7. Wait for it while the pretty letter soup continues to flow by on screen. The installer will start up. 20
  8. On the Configure Console screen, select Accept these Settings; On the Select Task screen, select Quick/Easy Install; When asked whether you are sure, select OK; On the Install Kernel(s) screen, select Standard kernel; On the Reboot screen, select Reboot.
  9. While it is rebooting, use the Devices | CD/DVD Devices menu up top and Remove disk from virtual drive. You may have to force an unmount. 24
  10. Enter n to decline setting up vLANs; Enter em0 as the WAN interface; Enter em1 as the LAN interface; Hit enter to pass on OPT interface setup. Enter y. Some more booting. Done.25

Configuring a pfSense gateway as VPN client

Prerequisite: The pfSense gateway must be installed. And ye have the debian Live/CD VM installed. Arrr!

  1. Go into the settings of the debian LiveCD VM. Change the first network adapter to the same internal network as created in the second adapter of the pfSense VM during installation. In my case that is pfS-SK.39
  2. Start the LiveCD VM and download your VPN files from your provider, or set up a Shared folder on your LiveCD VM and copy the files from the host.
  3. In the LiveCD VM start up a browser and go to 192.168.1.1 and create a server certificate exception.40
  4. Login as admin with password pfsense, and complete the setup wizard.43
    Uncheck Allow DNS servers to be overridden by DHCP/PPP on WAN (avoiding DNS servers pushed by your ISP and avoiding using the same DNS servers at multiple levels of your VPN chain) and pick two DNS servers. I used two servers from the WikiLeaks Alternative DNS list. Next. Accept Time Server Information settings. Next. On the screen for configuring WAN, uncheck both Block RFC1918 private networks and Block bogon networks. Next. Set Password. Make it strong. Write it down. Finish.
  5. In the pfSense VM enter 5, then yes. Wait for it.44
  6. In the LiveCD VM browse to 192.168.1.1 again and login using the new password. 45
  7. More settings: To prevent propagation of DNS server specifications through pfSense, in System -> General Setup, check Do not use the DNS Forwarder as a DNS server for the firewall, and save. In Services -> DNS forwarder, uncheck Enable DNS forwarder, and save; In System -> Advanced -> Networking, uncheck Allow IPv6 and save46For backup protection against leaks to WAN if the iVPN connection goes down, check Skip rules when gateway is down in System -> Advanced -> Miscellaneous -> Gateway Monitoring (3/4 of page)
  8. Reboot pfSense again from the console in the pfSense VM, by entering 5 and then y to confirm.
  9. Go back to the LiveCD VM, and login again on the pfsense webgui at 192.168.1.1 for configuring its VPN
  10. How to set this up depends on what the OpenVPN server supports and expects but basically follows these steps:
    • Create CA Certificate
    • Create password file to store your PIA username and password
    • Create/configure an OpenVPN Client
    • Create/configure an OpenVPN interface
    • Configure Outbound NAT rules
    • Verify OpenVPN Service

    Use the OpenVPN configuration file (with extension .conf or .ovpn) or other information available from your VPN service as a guide. Examples:

  11. Verify OpenVPN Service: check whether is up in Status -> OpenVPN and the logs under Status ->System Logs -> OpenVPN must have an entry openvpn[xxxxx]: Initialization Sequence Completed. If not up, first check host connections and VM settings. 😀