When connecting to a VPN you may have a DNS server which serves split horizon for a particular domain. For example when connected to your companies VPN, your local DNS config in /etc/resolv.conf is updated with:

nameserver 192.168.1.1

The DNS server 192.168.1.1 is your companies internal DNS server which resolves admin.example.org to 192.168.1.100. You need to access admin.example.org on 192.168.1.100 but don’t necessarily want to have all DNS queries go to 192.168.1.1. You also don’t want manage /etc/hosts entries which can become stale over time.

dnsmasq, a lightweight DNS and DHCP service can help.

Simply install dnsmasq, starting off with a simple config.

listen-address=127.0.0.1
bind-interfaces
conf-dir=/etc/dnsmasq.d/

Create /etc/dnsmasq.d/example.org.conf.

address=/vpn.example.org/198.51.100.100
server=/example.org/192.168.1.1
  • line 1 returns 198.51.100.100 for the host vpn.example.org.
  • line 2 specifies 192.168.1.1 as the upstream DNS server for all other example.org queries such as admin.example.org.

and finally update /etc/resolv.conf.

nameserver 127.0.0.1

Now your local resolver clients will use dnsmasq as a DNS server with dnsmasq only forwarding queries for example.org to the upstream DNS server 192.168.1.1.

When using dhcp within a ifcfg network configuration file you may want to specify a different nameserver instead of using the nameserver assigned by the DHCP server.

Use the PEERDNS, DNS1 and DNS2 options.

DEVICE="em1"
BOOTPROTO="dhcp"
ONBOOT="yes"
TYPE="Ethernet"
PEERDNS="yes
DNS1="8.8.8.8"
DNS2="8.8.4.4"

To check that it all works.

$ ifdown eth0;ifup eth0
$ grep ^nameserver /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

If you want to use the nameservers that are provided by DHCP server but also specify an extra nameserver within your /etc/resolv.conf, you can make use of dhclient.conf options.

prepend domain-name-servers 8.8.4.4;

The OpenVPN auth-pam module provides an OpenVPN server the ability to hook into Linux PAM modules adding a powerful authentication layer to OpenVPN. Adding support to your existing OpenVPN server config is simple.

On the server, add the following to the OpenVPN config.

plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

For Ubuntu and Debian distributions, the path to the plugin is /usr/lib/openvpn/openvpn-plugin-auth-pam.so.

Create a PAM service file.

auth    required        pam_unix.so    shadow    nodelay
account required        pam_unix.so

On the client, add the following to the OpenVPN config.

auth-user-pass

Restart the OpenVPN server and that should be it. Any new OpenVPN connections will first be authenticated with pam_unix.so so the user will need a system account.

If the OpenVPN server exits with the log below, after an authentication attempt you most likely are running OpenVPN within a chroot and have not created a tmp directory.

Wed Sep 17 19:58:15 2014 us=704365 10.40.10.3:33518 Could not create temporary file '/tmp/openvpn_acf_5a98375273019ab2d5d300dabcf91c91.tmp': No such file or directory

Simply create a tmp directory within the chroot with the appropriate permissions that match your OpenVPN server config.

$ grep -E "(^chroot|^user|^group)" /etc/openvpn/server.conf
chroot /var/lib/openvpn
user openvpn
group openvpn
$ mkdir --mode=0700 -p /var/lib/openvpn/tmp
$ chown openvpn:openvpn /var/lib/openvpn/tmp

Extending the OpenVPN PAM service

You can extend the use of PAM by adding to the /etc/pam.d/openvpn file.

auth    required        pam_unix.so    shadow    nodelay
auth    requisite       pam_succeed_if.so uid >= 500 quiet
auth    requisite       pam_succeed_if.so user ingroup wheel quiet
auth    required        pam_tally2.so deny=4 even_deny_root unlock_time=1200
account required        pam_unix.so
  • line 2 requires that the user’s uid is greater than or equal to 500.
  • line 3 requires that the user belongs to the wheel group.
  • line 4 uses pam_tally2 to lock out the account after 4 consecutive unsuccessful authentication attempts. After 1200 seconds, the counter will reset back to 0.

Update the timezone in CentOS 6

September 22, 2014

The timezone a server is configured with can be shown with the date command.

$ date +%Z
EDT

To change the timezone in CentOS 6, first ensure you have the latest tzdata package installed.

$ yum install tzdata

Then update the /etc/localtime with the new timezone by copying the timezone file the tzdata package.

$ cp /usr/share/zoneinfo/UTC /etc/localtime
$ date +%Z
UTC

Fed up with vim 7.2 on CentOS 6?

The vim RPM that ships with CentOS7, currently at version 7.4.160, can be rebuilt and installed on a CentOS 6 box.

First, install the source RPM.

$ rpm -Uvh http://vault.centos.org/7.0.1406/os/Source/SPackages/vim-7.4.160-1.el7.src.rpm

Make a minor change to the vim.spec file with this patch.

$ cd ~/rpmbuild/SPECS
$ wget -O - \
   https://gist.githubusercontent.com/renecunningham/897bc360210c2901d6d5/raw | \
   patch -p0 vim.spec

Install the required build dependencies.

$ yum install ncurses-devel 'perl(ExtUtils::Embed)' libacl-devel autoconf \
    gpm-devel ruby-devel ruby gtk2-devel gtk2-devel libSM-devel libXt-devel \
    libXpm-devel

Build the vim-7.4.160 RPM.

$ rpmbuild -ba vim.spec

The vim-7.4.160 the RPMs ready to be installed will be stored ~/rpmbuilds/RPMS/$(uname -p).

$ ls ~/rpmbuild/RPMS/$(uname -p)
vim-common-7.4.160-1.el6.x86_64.rpm      vim-minimal-7.4.160-1.el6.x86_64.rpm
vim-enhanced-7.4.160-1.el6.x86_64.rpm    vim-X11-7.4.160-1.el6.x86_64.rpm

SIP commonly runs over UDP but there are times when you may need to run it over TCP.

To allow SIP TCP clients to connect with asterisk update sip.conf with the following

[general]
tcpenable=yes
tcpbindaddr=0.0.0.0

Within your SIP clients definition you have to add transport=tcp for each individual connection.

[client001]
callerid="Client 001" <001>
username=client001
secret=password
type=friend
host=dynamic
context=internal
canreinvite=yes
mailbox=001@default
transport=tcp
disallow=all
allow=alaw
nat=route
dtmfmode=inband

Reload sip within the asterisk console and confirm that asterisk is now listening on 5060/tcp with netstat.

server*CLI> sip reload
server*CLI> quit
Executing last minute cleanups
$ sudo netstat  -tlpn | grep 5060
tcp        0      0 0.0.0.0:5060            0.0.0.0:*               LISTEN      17414/asterisk  

Discover Googles Netblocks

September 19, 2014

Do you need to discover what IP netblocks are owned and operated by google to perhaps add to your firewall ACLs?

Use dig.

$ dig -t txt _netblocks.google.com

Have you ever used SSH within a script or perhaps with rsnapshot and had to accept the servers host key?

$ ssh server.example.org
The authenticity of host 'server.example.org (192.0.2.100)' can't be established.
ECDSA key fingerprint is 63:f1:fe:d1:a5:4e:2e:94:33:13:46:58:9f:51:32:f1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server.example.org,192.0.2.0' (ECDSA) to the list of known hosts.

By using StrictHostKeyChecking and UserKnownHostsFile SSH client options you can bypass this check.

$ ssh server.example.org -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null
Warning: Permanently added 'server.example.org (192.0.2.100)' (ECDSA) to the list of known hosts.
root@server:~#

Alternatively you could update ${HOME}/.ssh/config

Host                    server.example.org
    HostName                server.example.org
    User                    root
    Compression             yes
    ForwardAgent            no
    ForwardX11              no
    StrictHostKeyChecking   no
    UserKnownHostsFile      /dev/null

Security Warning

It’s important that you trust the server that you are connecting to before changing the default StrictHostKeyChecking & UserKnownHostsFile options. All an attacker would need to do is poison your DNS and import your SSH public key to fake what you would expect to be the server you are connecting to.

Good Sysadmins always produce great documentation and descriptive network diagrams.

It’s good form to use appropriate network addresses within documentation, example code and diagrams.

Ever seen a Fictitious IP address in a movie?

Well someone should of read RFC5735.

192.0.2.0/24 – This block is assigned as “TEST-NET-1″ for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation.

198.51.100.0/24 – This block is assigned as “TEST-NET-2″ for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation.

203.0.113.0/24 – This block is assigned as “TEST-NET-3″ for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation.

So next time you write some documentation, create a diagram or reference a network in example code consider using one of the networks in RFC5735.

Ever logged into an Ubuntu box and seen this?

Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-29-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Sat Sep 13 23:12:33 UTC 2014

  System load:  0.08              Processes:           118
  Usage of /:   12.7% of 7.74GB   Users logged in:     1
  Memory usage: 16%               IP address for eth0: 10.1.1.1
  Swap usage:   0%

  Graph this data and manage this system at:

https://landscape.canonical.com/

  Get cloud support with Ubuntu Advantage Cloud Guest:

http://www.ubuntu.com/business/services/cloud

You can configure /etc/pam.d/sshd to not include the pam_motd.so module when logging in. Just hash out the following lines in /etc/pam.d/sshd.

session    optional     pam_motd.so  motd=/run/motd.dynamic noupdate
session    optional     pam_motd.so # [1]