May
4
Why ufw Does Not Need A GUI
Filed Under Security | 10 Comments
I’ve been hearing more and more recent requests (at OpenWeek -chat and in blog comments) regarding a request for a GUI on top of ufw. I wanted to take a second and outline more clearly what ufw is, which will likely stop these requests. I think its just a simple matter of not truly understand what ufw does which leads to these. Bottom line, there are already a number of GUI firewall applications, adding one for ufw would be basically pointless. (Before you argue that point, keep reading.)
What is ufw?
ufw, or “uncomplicated firewall”, is simply a management tool for creating kernel-level firewall rules which is done via the netfilter kernel module and iptables userspace tool. iptables has been around for quite a long time, is very, very robust and very widely used. It is installed by default on any Ubuntu system, but no “rules” have historically been applied to it. (Technically, every Linux system has a firewall utility built into the kernel, but if no rules are applied to that filter nothing is actually being specifically allowed or denied.)
The reason ufw was developed (I sat in on the sprint at UDS for this) is that we wanted to create a server-level firewalling utility that was a little bit more “for human beings”. While iptables is already installed and available for use, the syntax can be complicated. For example, lets say you wanted to block all connections from the IP address 10.100.0.5:
iptables : sudo iptables -A INPUT -s 10.100.0.5 -j REJECT
ufw: sudo ufw deny from 10.100.0.5
Another slightly more complicated example could be written for blocking specific ports and protocols:
iptables: sudo iptables -A INPUT --dport 22 -s 10.100.0.5 -j REJECT
ufw: sudo ufw deny from 10.100.0.5 to any port 22
ufw is creating the iptables / netfilter rule “under the hood”, but allowing us to create the rules in a simpler way. Both of the commands above basically do the same thing, ufw simply “uncomplicates” the process.
For those that are looking for a GUI on top of ufw, remember that you already have tools such as Firestarter or lokkit, etc. Those are graphical tools which create and manage iptables / netfilter rules “under the hood”. ufw is simply a command-line tool to manage iptables / netfilter rules “under the hood”.
The existing GUI tools (Firestarter) and ufw both use iptables underneath, so adding a GUI to ufw would basically be re-creating Firestarter, which is not really needed. ufw is simply a less complicated way to create firewall (iptables) “rules” on the command line.
I post tutorials very regularly on this site. You may want to consider subscribing to the RSS feed. Or if you'd prefer these tips sent to your inbox you can use Email Subscriptions.
Mar
21
Project Update Announcements
Filed Under Folding, GNOME, Security, c0de | Leave a Comment
I wanted to quickly toss something out there for all of you on the interweb. I spent some time last evening cleaning up a few of my code projects. If you have been using either of them you may want to update.
apturl for Gnome Do
I spent some time in the #gnome-do channel last nite seeing what needed to be done for the apturl plugin to become better supported. The end result is that its much cleaner, properly licensed and has been submitted to the do-plugins branch on launchpad for possible future inclusion in the “official” plugins package. If you have been using the apturl plugin for Gnome Do and saw some recent breakage, you can download the new known-to-be-working-on-0.4 version here.
GoogleSecure Greasemonkey Script
I’m a big fanboy of data encryption, including encrypting as much of my web traffic as I can. I hacked together a small Greasemonkey script long ago that will force encryption on any supported Google application (gmail, reader, docs, calendar, etc), and recently added Twitter as well. I guess that might be cause for a name change, but I didn’t get that far. I would like to extend the list of sites that it supports, so if you know of any sites that offer https on login but don’t require (but support) https session-wide, let me know. If you’re interested in this tool you can download Greasemonkey here and GoogleSecure here.
folding.sh
I also have time set aside today to try and squash two remaining bugs in folding.sh. For all of you great folks that have been using folding.sh, expect an update fairly soon.
Mar
18
I’m really happy to announce that SELinux is now available in Ubuntu 8.04 “Hardy Heron”. This is the result of the amazing work of the ubuntu-security and ubuntu-hardened teams, as well as the huge contributions from the folks at Tresys. (note: SELinux will not be the default, but is available as a security option.)
If you would prefer to use SELinux over AppArmour, or if you’re just a good soul that would like to help test Ubuntu’s SELinux implementation, please read on.
Install SELinux in Ubuntu 8.04
All that is needed is to install the SELinux package, which will remove AppArmour and apply the SELinux policy.
sudo aptitude install selinux
If you run across any issues or bugs please report them against SELinux on launchpad. Welcome to a more secure Ubuntu!
Jan
12
Disabling SSH connections on ipv6
Filed Under Security | 6 Comments
I was parsing through some of the logs on my new server tonite and I saw some unsuccessful ssh connection on ipv6. I thought I would mention quickly how you can disable listening on ipv6.
ListenAddress
The /etc/ssh/sshd_config file configures how your ssh daemon should run. By default it is likely listening on 0.0.0.0 (all ipv4 addresses) and :: (all ipv6), which is defined by two lines:
#ListenAddress 0.0.0.0
#ListenAddress ::
To configure your server to *not* listen on ipv6 you can remove that line. Now it might appear a bit confusing that the line we’re removing is commented out. That means its not reading that line, right? In this case it is displaying one of the default settings. I have altered my file to only listen on my public facing ipv4 address by removing the “::” listing, and specifically defining an ip instead of “0.0.0.0″.
Another solution which was brought to my attention by a comment is outlined here:
AddressFamily any # default
AddressFamily inet # IPv4 only
AddressFamily inet6 # IPv6 only
By defining the AddressFamily type that we want to use we can listen on both ipv4 and ipv6, just ipv4 or just ipv6. Find the line above in your config and define the AddressFamily you would prefer to listen on.
Once you update these lines you’ll need to restart your ssh service.
sudo /etc/init.d/ssh restart
Also, as a second measure you can firewall ipv6. I’ll be posting a firewall tutorial soon, but the below single command will block all incoming traffic on ipv6:
sudo ip6tables -P INPUT -j DROP
Sep
19
Looking for information on SELinux in Ubuntu
Filed Under Security | 8 Comments
This post is a request for information, tutorials, documentation, etc on using SELinux with Ubuntu or Debian. I am very interested in deploying it and documenting it (as I tend to do here, of course) but I’m not finding much information. If you have:
- Been able to deploy it on Ubuntu / Debian
- Can refer me to documentation on doing so
- Can give me information on the any status of the possibility
please let me know. I am perfectly aware that Apparmor has been chosen beginning with 7.10 but I would prefer not to use it. If I’m going to use one I’d prefer to use SELinux. If anyone can point me toward making this work I would very much appreciate it.
Sep
2
I thought today I would outline a few tips on network security with tcpwrappers or, as you’re probably more familiar, the hosts.allow and hosts.deny files. How you can use them? What applications are compatible? etc. I know network security is a really broad topic, but this will hopefully be enough to get you going and understand some more basics of securing your machine.
tcpwrappers compatibility
The first thing to remember is that not every network-based application on your machine is compatible with tcpwrappers. The restrictions on hosts.allow or hosts.deny are only valid if they refer to the tcpwrappers library. How can you find out if your application is compatible? Use this command:
ldd /path/to/binary | grep libwrap (general example)
ldd /usr/sbin/sshd | grep libwrap (shows that the sshd refers to libwrap)
ldd /usr/sbin/apache2 | grep libwrap (show that apache does not refer to libwrap)
In the basic example above we see that the sshd (ssh server) is referring to the libwrap.so, so we can tell that any restrictions in hosts.allow and hosts.deny are applicable to that service. We also see that apache2 does not refer to libwrap.so, so any restrictions outlined there do not apply to apache2 connections. (ie; you could lock down ssh but apache2 is still wide open)
hosts.allow and hosts.deny
These two files, located in your /etc/ folder, allow you to limit or permit connections from specific hosts or ips. Using these two files you could setup a whitelisting firewall or blacklist. Remember, as mentioned in the compatibility section, this only applies to the services referring to libwrap. If you are running services outside of the scope of libwrap.so this may not be the best solution for you in terms of firewalling.
/etc/hosts.allow
ALL: 127.0. [::1] (the 127.0. range is allowed, as well as the localhost ipv6 address)
sshd : 192.168.0.5 (specific IP) 192.168.0. (specific range) EXCEPT 192.168.0.10 (range exceptions)
/etc/hosts.deny
ALL : ALL (denying all services to all hosts)
This example would allow connections from localhost on ipv4 and ipv6 for all services and also explicitly allow ssh connections from the 192.168.0.5 address, the entire 192.168.0. range, but excluding the 192.168.0.10 host. The hosts.deny then outright denies all services for all hosts. This is a very basic example but hopefully it gets the idea across. You could also reverse the contents of the two files in the example above and do blacklisting. ALL : ALL are allowed with the exceptions of services and ips listed in the hosts.deny.
The syntax of the hosts.allow and hosts.deny files are:
service(s) : ips or hosts
You can comma separate the list of services you want to allow or deny and make a similar list of hosts/ips to allow or deny. Very simple syntax.
conclusion
The hosts.allow and hosts.deny files are very flexible and allow you to lock down your network in very granular ways. The limitation of some applications not honoring hosts.allow and hosts.deny is the biggest thing to remember. Make sure the service you are trying to block refers to libwrap.so before you start writing rules or you may sit and wonder why your rules don’t work, when its really the application itself not being compatible.
Aug
17
Update : Encypted root file system option now available at installation in Ubuntu 7.10. See Install Time Ubuntu Encryption for more information.
This last week I’ve been very interested in encryption. If you missed it you might be interested in my post on encrypting files or emails with GPG. In this tutorial I wanted to outline how to encrypt a local partition or a removable device (like a USB key). The steps used here will work for either type of device although you’ll need to replace your partition name and number for the examples provided here.
Attention: following this tutorial will wipe all data from the partition or device you write it to. You cannot encrypt your file system after-the-fact using this method. Be sure you have backups or don’t care about the data being lost if you follow these steps!!!
Step 1:
The first step in the tutorial is installing the cryptsetup utility, which is part of the cryptsetup package. You can search for this using your favorite package management utility or use this command:
sudo aptitude install cryptsetup
Step 2:
Now that we have the cryptsetup utility installed we’ll need to prepare the device for use. If you have a newly created device or partition you may be able to skip this step, but it also won’t hurt to redo this step anyway.
If you are unsure what the device is listed as, you can use either of these two commands:
sudo fdisk -l(this will list your current partition table, both on local and removable media.)
dmesg(this will show kernel messages pertaining to hardware. If you plug in a removable device and wait a few seconds, this will show what you what device the kernel assigned the hardware.)
Once you know what device you want to apply this to you can run the following command on [your device] to create the partition you want to encrypt. I suppose you can also use a graphical utility like gparted, etc. Those tools are outside the scope of this tutorial.
sudo fdisk /dev/[your device](ie; if your device showed up as /dev/sdb you would use: sudo fdisk /dev/sdb)
For removable media make a single primary partition using the entire space of the device (or alter for your needs if you know what you’re doing).
Once you have created the partition you’ll want to “w”rite the change in fdisk. Remember, if you don’t “w”rite the changes none will be applied.
Step 3:
To make sure that your kernel is up to date concerning the newly created / altered partition table you may need to run the command:
sudo partprobe
Step 4:
Now we’ll get to encrypting this new partition. There are different options you can use here, and I’ll outline a few of them, but there really isn’t one that is “the best”. It depends on your level of security needs and the time you want to spend on it. If you want it done quickly and want a basic level of fairly-hard-to-break encryption you can use the first option. If you are super paranoid and don’t mind letting this take some time (hours or days on large disks!) to build you can use option three. Somewhere in the middle, option two is probably fine. Anyone have suggestions on other methods?
We’ll write data over the newly created partition to help aid in the encryption process. By writing data to the partition prior to encryption it helps protect against data attacks, finding patterns on the block-level, etc. You can use one of the following three commands:
sudo dd if=/dev/zero of=/dev/[your device] bs=4K(this method is probably recommended unless you expect active attacks against your encryption layer)
sudo badblocks -vfw /dev/[your device] [block-size-of-your-device](this option will write 5 data patterns across your drive and overwrite and verify the data. This is used to check for badblocks, but can also be used to wipe out any existing data)
sudo dd if=/dev/urandom of=/dev/[your device] bs=4K
(this method is considered pretty secure. It is based on the truly random option below but is pseudo-random data–probably a very good option in most cases.)
sudo dd if=/dev/random of=/dev/[your device] bs=4K(this is considered the most secure but will take a long time. It is also important to generate a lot of random data on your machine. Launch some applications, do some high disc I/O, move the mouse erratically, etc. This may take DAYS!)
Step 5:
At this point the partition is ready to be encrypted. Now there are multiple encryption methods and options to be used within each. This tutorial outlines using the LUKS encryption with my prefered string length, hash and cipher. You may change these if you know what you’re doing. If not, omitting my options will use the defaults (ripemd160 hash). This command will remind you that all data will be lost (although we already lost everything in Step 4. This is also where you’ll be prompted for your passphrase to access the encryption.
sudo cryptsetup luksFormat /dev/[your device] -c aes -s 256 -h sha256(again, past [your device] are my preferred options)
If you see an error near this point similar to “Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-plain cipher spec and verify that /dev/[your device] contains at least 258 sectors.” you’ll need to run this command:
sudo modprobe dm-crypt
You may want to have this module auto-magically added at boot time by appending this line to your /etc/modules file:
dm-crypt
Step 6:
Now that we’ve created the encryption basic layout on the partition we need to open the encrypted partition for use.
sudo cryptsetup luksOpen /dev/[your device] name(name can be whatever you like. I use things like secure or vault or encrypt)
Step 7:
Now that we have the device open and added to the dm (dev mapper) system we can actually create a file system on it and use it. One last command and we’ve got ourselves an encrypted, usable filesystem.
sudo mke2fs -j /dev/mapper/name -L label(where name was applied above and label is the filesystem label. I generally match the two. This also assumes an ext3 file system. If you know you want a different filesystem type I’m assuming you know the right command.)
If you’ve come this far your device is ready to use. A few additional points that you may be interested in.
Additional
First, if this is a local partition and filesystem, such as a /data folder, you may want it to be mounted automagically at boot time. You can add the new partition to your /etc/fstab file to be mounted at boot. Be sure to specify the /dev/mapper/[name] location and not the original partition location. You should note that when your booting system arrives at this device it will prompt you for a passphrase key and halt the boot process until one is provided. An example of a line in the /etc/fstab is:
/dev/mapper/name /data ext3 defaults 0 0
Second, if you are using this on a removable drive such as a usb key the Gnome Desktop (someone verify in KDE?) will recognize the encrypted setup and prompt you for a key visually. A message such as “The storage device contains encrypted data. Enter a password to unlock” will appear. You will be required to know the passphrase (as supplied in Step 5) to access this device again. The desktop system also allows you to “forget immediately“, “remember password until you logout” or “remember forever” the key provided. Those options are up to you and your usage. “Remember forever” should store the key in your gnome keyring.
Third, if you are following this guide for use on a removable disk you may want to change ownership (chown) on the mounted path and set group id (sgid) on the directory so that your user has full permissions. Considering we ran everything with sudo the mounted path and ownership is probably set to the root user. You can use these two commands to set the permissions:
sudo chown -R user.user /media/[name](user.user should, of course, be replaced with your username on the system)
sudo chmod g+s /media/[name]([name] is the mount point that the system auto-mounted the device on. It *should* match whatever you set the label to in step 7.)
There is also an option to create multiple keys to unlock the device. This is helpful if it is a multi-user system and you don’t want to use a shared passphrase. You would add a key to the encrypted device using:
sudo cryptsetup luksAddKey /dev/[your device]
This will prompt you for your current key and then the new key. The new key will have to be entered twice. Also, if you want to remove a key you can use the similar:
sudo cryptsetup luksDelKey /dev/[your device] [slot #]
To find out more information about your encrypted partition / device, and to see things such as assigned key slots, you can also use:
sudo cryptsetup status name
sudo cryptsetup luksDump /dev/[your device]
I would like to expand this soon to include encrypting your entire root filesystem or other variations like bypassing the passphrase but storing the “key” an a usb drive or similar. This way it is similar to a hardware key needed to boot your machine. There are a lot of different ways this could go… until then, I think this has become long enough 
Jul
12
This post is in part an update to my previous post on resetting the gnome keyring, and partly due to my continued laziness, efficiency push. I want my machine to do everything for me anymore. The less tedious work I have to do the more actual work I can get done, right? This post will walk you through setting up your machine to auto-authenticate the gnome-keyring at login. One less password you have to enter when you login to your machine.
Installing the Package
We’ll need one tiny package for this to be supported. Using your favorite package manager install libpam-keyring, or use the following command:
sudo aptitude install libpam-keyring
Configuring PAM
Once this is installed we need to add a few lines to a configuration file. Follow this next step carefully. If you put the line in the wrong place it may cause problems with other parts of machine authentication.
Edit the /etc/pam.d/gdm file and append the following line to the end of the file:
@include common-pamkeyring
At this point the gnome-keyring will be handed your login password and, if they are the same, will be authenticated at login. If your login password and gnome-keyring password are different this will not work. Options? Set the passwords to match by first resetting the gnome-keyring password (this will wipe any saved keyring data) or come up with a solution that will authenticate one with the other, even if they are not the same. The latter solution I would be interested in, but am not aware of.
Thanks to Thad for the origins of this post, although slightly different between FC6 and Feisty.
Jun
22
A Discussion on Grub Security
Filed Under Security | 6 Comments
Today’s post isn’t so much a tutorial but more of a discussion or educational topic on grub. It was inspired by the original post here and continued discussion in the comments. I thought I would outline some suggestions on securing the grub boot loader and why Ubuntu adding a “rescue mode” entry in grub is not a security flaw and is really not any less secure than any other distribution.
(based on how long this entry has become I added the split post. If you’d like to read a long entry, click read more. If you’re not in the mood for a 10min read, relax and forget it.)
Jun
20
SSH, what a wonderful tool. One of the crowning achievements of the modern world, with a hundred and one different uses. One of my favorite being that of tunnelling and proxying connections over it’s secure, encrypted goodness.
I thought I’d outline how to setup a proxy system using SSH that can be used by any application that supports SOCKS proxy. This includes Firefox, Thunderbird, Gaim/Pidgin and anything that subscribes to the Gnome “Network Proxy Preferences” found in System > Preferences > Network Proxy. note: this sets the shell environment values for: http_proxy and no_proxy.
The only two requirements you’ll need for this tutorial are an internet connection (of course) and access via ssh to a remote machine. In my case I connect from my laptop while on the road to a server available at home. This could just as easily be used between an office and home or visa versa.
Use a command similar to that below to create this SOCKS supported tunnel:
ssh -D port hostname
ie; ssh -D 8080 example.com, ssh -D 8081 example.com, ssh -D 8888 example.com. In this example I am using the 8000 range ports but you should be able to use *any* available outbound port. No need to specify other ports on the remote end like you do with traditional -L tunneling.
Once this connection is established you can set your proxy settings within the application (look for any proxy prefernces) or globally in System > Preferences > Network Proxy.
Select Manual Proxy Configuration, and enter “localhost” “port” (where port is the number used following the -D) in the SOCKS (4 or 5) field provided.
At this point you’re outgoing connections will be privately routed over said port to your remote server via ssh and then out to the outside world. Enjoy your privacy and circumventing network filters.
I need to thank Aaron for initially showing me the -D option.
-
Blogroll
Subscribe to the RSS feed!
