Category: Networking

Setup a Postfix Alias Email Account

Recently, my business had the need to create an email account for general inquiries. Since I’m currently the only employee, the email will be sent to me, but I’d like to publish a contact email address in some instances rather than my personal email address.

The email address I decided to publish rather than my own was In order to avoid setting up an user account on the mail server for a user named contact (and creating a mail store for the user), I decided to create an alias for contact and set myself as the contact user. This way, when email is received by Postfix for contact, the email will be sent to my mail store in my user directory.

The Configuration

First check the file (located at /etc/postfix on my Ubuntu server) to find the alias file configured for Postfix. Look for the following lines.

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

This tell us where the aliases file is located, so we open the file and you will see something like this:

# /etc/aliases
mailer-daemon: postmaster
postmaster: jason
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: jason
www: root
ftp: root
abuse: root
noc: root
security: root

I simply added contact: jason to the file and then run the newaliases command to inform postfix of the update of aliases file. Voila, now when messages are sent to, the message will be sent to my user.

Basic iptables Firewall

The iptables software is a user space application for configuring packet filtering in the Linux kernel. iptables is used to set rules for packets that travel through a host’s network stack and at certain points, called hooks, the iptables rules are evaluated and actions, such as dropping a packet, can be executed. In this post I will draft a script to setup the iptables’ rules for a firewall and then set that script to be executed at boot time.Read More

Adding a Samba Share

This post will use Samba Version 4.1.6-Ubuntu (the version in use on Ubuntu 14.04 LTS Server at the time of this writing) to setup Samba (smb) shares from a drive attached to a server on a local network. Three shares will be created: dropbox, hub, and restricted which will correspond to directories on the attached drive with the same names (although the names of shares and directories can differ).

The dropbox share will allow any user to connect and read, add, and remove objects from it. The hub, will allow any user to connect and read files, but only listed users will have the ability to add and remove them. Finally the restricted share will only allow access and privileges to certain users.

Mount the Drive in the File System

First, find and mount the drive that will host the shares in the file system. Use lsblk to print the device list, then mount the device — in our example the device that represents our drive is /dev/sdb1.

> lsblk
sda      8:0    0   149G  0 disk 
├─sda1   8:1    0 145.1G  0 part /
├─sda2   8:2    0     1K  0 part 
└─sda5   8:5    0   3.9G  0 part [SWAP]
sdb      8:16   0   1.8T  0 disk 
└─sdb1   8:17   0   1.8T  0 part 

> sudo mount /dev/sdb1 /media/share

To automatically mount this device, grab the UUID of the disk with blkid and add it to the /etc/fstab file (I’m using vim, but use whatever text editor you like). Once the fstab file has been edited correctly, the drive will be mounted automatically during system start up.

> sudo blkid
/dev/sda1: UUID="ed9feafe-6654-4173-9967-7b6fe43581b5" UUID_SUB="532b088c-66f9-4ca2-8664-d80ff7612891" TYPE="btrfs" 
/dev/sda5: UUID="678e7a38-6367-4305-929f-b96ae36d7329" TYPE="swap" 
/dev/sdb1: LABEL="Black" UUID="46E6328FE6327EED" TYPE="ntfs" 

> sudo vim /etc/fstab

Add the following line to fstab, save and close the file.

UUID=46E6328FE6327EED /media/share ntfs defaults 0 2

Creating the Share and Controlling Access

Before we begin editing the Samba configuration file, it’s a good idea to make a backup of the original. Also, access to the share is controlled by Samba, so we also need to create users within the Samba program.

> sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.orig

> sudo smbpasswd -a [user]
New SMB password:
Retype new SMB password:
Added user [user].

The following are the definitions of the shares we’ve set out to create:


Before defining our dropbox, we change the ownership of the /media/share/dropbox directory to facilitate the requirement that anyone can access/read/write/delete files and directories. In this case, I’ve chosen to set the nobody user and nogroup group as having ownership of the dropbox.

> sudo chown nobody:nogroup /media/share/dropbox

Now, we can create the definition of the share.

 path = /media/share/dropbox
 browseable = yes
 read only = no
 guest ok = yes
 force user = nobody
 force group = nogroup
 force create mode = 664
 force directory mode = 775

The path directive tells where in the file system the share is located, and browseable determines whether or not the share will be advertised on the network (in the network neighborhood on Windows systems). By setting read only to ‘no’, we’ve declared that users who can access the share can write to it, and by setting guest ok to ‘yes’ we’re not restricting access.

Forcing the user and group to nobody and nogroup respectively we’re ensuring files and directories created in the dropbox will be owned by the unprivileged Posix user and group of the same corresponding names. Forcing create mode makes sure files are created with read and write privileges to users accessing the share, and force directory mode makes sure directories are created with read, write, and execute permissions.


 path = /media/share/hub
 browseable = yes
 read only = yes
 guest ok = yes
 write list = [user]
 force user = nobody
 force group = nogroup
 force create mode = 664
 force directory mode = 775

This share is a lot like the last one, but notice this share has been declared read only. This means that, although anybody can find and connect to the share, only those users listed in the write list can write new files and delete files within the share.


The restricted share will not be advertised on the network and only certain users will be allowed to access it. When these users do gain access they will have read and write permissions permissions on all files and full permissions on directories. Unix users that will have access to this share must be the user or in the group that the share forces users to use.

  path = /media/share/restricted
  browseable = no
  read only = no
  guest ok = no
  valid users = [user]
  force user = [user]
  force group = restricted
  force create mode = 664
  force directory mode = 775


Preventing SSH Known Hosts Enabled Island Hopping

Upon connecting to an OpenSSH server, the server sends its public key to the
client so that the user on the client side can verify that the server they
are trying to connect to is indeed the server they expect it to be (and not an
attacker spoofing the desired SSH server). Once initially verified, the server’s
key is then stored in the $HOME/.ssh/known_hosts file. Proper use
of this system mitigates SSH Spoofing attacks, but by default it also
presents a data leak that could be utilized by someone who has cracked your system.

When securing a system, we would like to believe our efforts will thwart any
any such attempts at penetration; but any good security plan should consider how
to minimize damage in the event that an intruder does gain access. By default
the keys in known_hosts are referenced in plain text:

$ cat $HOME/known_hosts
$, ssh-rsa AAAAB3NzaC1yz2EAAAADAQABAAABAQC/TLO38IPrLW18kgKx4BQmPGmOXaIKRyTGTFtOT4tCph9ORyb7Mh0SlIe1bowqOFcNI6LUNcrloiTFd9wvAljTHriZJASEOy6uCBf1cKcwX/TpjtiA2uJ7mzosmeoB0PFAxCmKvb2xGXGIsjFOHYWSOitKqxj9r9JUAAURgzb5teml9/bcsMz05qZtkS4EmvYAFXXSaqLNiT+Q3UCjj2GD3mSGqyuy4ad+pEENXNf10D/hMxQBiedH4jNhUJSqTCtJtfVf7532OP7qvQ4PISbh3itEmrFBelkDxlC+3mxFFOzk/SyYWf16Roc9xsnR5HK7mGYG4N4YcxYaioCV1Nd9

The problem here is that if an attacker found a vulnerability in your security
and gained access to a single machine, all they would need to do is run the above
command and they would have a list of hosts on the network that possibly have
the same vulerability. This is a type of an Island Hopping attack, in
which an attacker gains access to a ‘weak link’ in the network and then ‘hops’
around from system to system. We can prevent this type of attack by hashing the
hostnames in our known_hosts file.

Hashing will take our human readable hostname (and ip address) and transform
it into something like


Which is virtually useless to an attacker, but OpenSSH will have no problem
utilizing. To configure our server to hash hostnames automatically, set the
following directive in /etc/ssh/ssh_config:

HashKnownHosts yes

To hash existing entries in your known_hosts use:

ssh-keygen -H

This command will copy your $HOME/.ssh/known_hosts file to
$HOME/known_hosts.old with all the plain text hostnames and replace
the known_host file with hashed hostnames. It would be wise to verify
this replacement file will allow you to connect to remote hosts before removing
the known_hosts.old file.