Small syslog server

My home network has several devices that do not have large persistent storage to keep log files. For example, my wireless routers based on OpenWRT doesn’t log to the limited local storage it has, and a Flukso energy metering device log power readings to a ramdisk. These devices log a fair amount of information that I ideally would like to keep for later analysis. I have never before seen a need to setup a syslogd server, thinking that storing logs locally and keeping regular backups of the machine is good enough. However, it appears like this situation calls for a syslogd server. I found an old NSLU2 in my drawer and installed Debian Squeeze on it following Martin Michlmayr’s instructions. I’m using a 4GB USB memory stick for storage, which should hold plenty of log data. I keep backups of the machine in case the USB memory stick wears out.

After customizing the installation to my preferences (disable ssh passwords, disable portmap/rpc.statd/exim4, installing etckeeper, emacs23-nox, etc) I am ready to configure Rsyslog. I found what looked like the perfect configuration example, “Storing messages from a remote system into a specific file”, but it requires me to hard code a bit too much information in the configuration file for my taste. Instead, I found the DynFile concept. With a file /etc/rsyslogd.d/logger.conf as below I can point any new device to my log server and it will automatically create a new file for it. And since the dates are embedded into the filename, I get log rotation suitable for rsync-style backups for free.

$ModLoad imudp
$UDPServerRun 514

$ModLoad imtcp
$InputTCPServerRun 514

$template DynFile,”/var/log/network-%HOSTNAME%-%$year%-%$month%-%$day%.log”
:fromhost-ip, !isequal, “127.0.0.1″ ?DynFile
:fromhost-ip, !isequal, “127.0.0.1″ ~

Syndicated 2011-12-12 11:19:45 from Simon Josefsson's blog

Unattended SSH with Smartcard

I have several backup servers that run the excellent rsnapshot software, which uses Secure Shell (SSH) for remote access. The SSH private key of the backup server can be a weak link in the overall security. To see how it can be a problem, consider if someone breaks into your backup server and manages to copy your SSH private key, they will now have the ability to login to all machines that you take backups off (and that should be all of your machines, right?).

The traditional way to mitigate SSH private key theft is by password protecting the private key. This works poorly in an unattended server environment because either the decryption password needs to be stored in disk (where the attacker can read it) or the decrypted private key has to be available in decrypted form in memory (where attacker can read it).

A better way to deal with the problem is to move the SSH private key to a smartcard. The idea is that the private key cannot be copied by an attacker who roots your backup server. (Careful readers may have spotted a flaw here, and I need to explain one weakness with my solution: an attacker will still be able to login to all your systems by going through your backup server, however it will require an open inbound network connection to your backup server and the attacker will never know what your private key is. What this does is to allow you to more easily do damage control by removing the smartcard from the backup server.)

In this writeup, I’ll explain how to accomplish all this on a Debian/Ubuntu-system using a OpenPGP smartcard, a Gemalto USB Shell Token v2 with gpg-agent/scdaemon from GnuPG together with OpenSSH.


First we need to install some packages. The goal is to configure OpenSSH to talk to the gpg-agent which will start and talk to scdaemon which in turn talks to pcscd which talks to the smart card reader. For some strange reason, the scdaemon binary is shipped with GnuPG’s S/MIME interface in the gpgsm package.

# apt-get install pcscd gnupg-agent gpgsm

The above command should install and start pcscd and if all works well, you should be able to check the status of the smartcard using GnuPG.

# gpg --card-status

You need to initialize the smartcard and generate a private key on it, again using GnuPG. If you trust GnuPG more than the smartcard to generate a good private key, you may generate the private key using GnuPG and then move it onto the smartcard (hint: use the keytocard command). Make sure you don’t leave a copy of the private key on the same machine!

# gpg --card-edit
gpg: detected reader `Gemalto GemPC Key 00 00'
...
gpg/card> admin
Admin commands are allowed

gpg/card> name
Cardholder's surname:
Cardholder's given name: host.example.org
gpg: 3 Admin PIN attempts remaining before card is permanently locked

Please enter the Admin PIN
gpg: gpg-agent is not available in this session

gpg/card> lang
Language preferences: en

gpg/card> generate
Make off-card backup of encryption key? (Y/n) n

Please enter the PIN
What keysize do you want for the Signature key? (2048)
What keysize do you want for the Encryption key? (2048)
What keysize do you want for the Authentication key? (2048)
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: host.example.org
Email address:
Comment:
You selected this USER-ID:
    "host.example.org"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
gpg: existing key will be replaced
gpg: please wait while key is being generated ...
gpg: key generation completed (33 seconds)
gpg: signatures created so far: 0
gpg: existing key will be replaced
gpg: please wait while key is being generated ...
gpg: key generation completed (18 seconds)
gpg: signatures created so far: 1
gpg: signatures created so far: 2
gpg: existing key will be replaced
gpg: please wait while key is being generated ...
gpg: key generation completed (23 seconds)
gpg: signatures created so far: 3
gpg: signatures created so far: 4
gpg: key 12345678 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/12345678 2011-09-19
      Key fingerprint = 1234 5678 1234 5678 1234  5678 1234 5678 1234 5678
uid                  host.example.org
sub   2048R/23456789 2011-09-19
sub   2048R/34567890 2011-09-19

gpg/card> quit
#

Now for the interesting part. OpenSSH talks to an agent for private key handling, and GnuPG’s gpg-agent supports this protocol when the --enable-ssh-support parameter is given. During startup, gpg-agent will print some environment variables that needs to be set when ssh is run. Normally gpg-agent is invoked by the Xsession.d login scripts, so that the environment variables are inherited by all your processes. However, for an unattended machine without any normal login process, we need to write a script to start gpg-agent. First do these manual steps, to confirm that everything works.

# gpg-agent --daemon --enable-ssh-support > /var/run/gpg-agent-info.env
# . /var/run/gpg-agent-info.env
# ssh-add -L
ssh-rsa AAAAB3N... cardno:000500000BD8
#

If the final step printed a SSH public id, the (sometimes) tricky part in getting the hardware to work is (hopefully) complete. What remains is to script things so that gpg-agent is started on boot and to make sure that your backup scripts has the proper environment variables before launching whatever processes will launch ssh. Further, since we will be running unattended, we need a mechanism to unlock the smartcard using a PIN interactively once on each boot of the machine. I prefer manually entering the PIN on every boot over having the PIN stored in a file on the disk.

I will use the /etc/rc.local mechanism to start gpg-agent, like this:

# cat> /etc/rc.local
#!/bin/sh -e
exec gpg-agent --daemon --enable-ssh-support \
    --pinentry-program /usr/local/sbin/pinentry-unattended \
    --write-env-file /var/run/gpg-agent-info.env
^D

The astute reader will now ask what /usr/local/sbin/pinentry-unattended is and why it is needed. Now here is the situation. scdaemon will normally query the user for a PIN using a tool called pinentry which reads and write to the user’s TTY directly. This won’t work in unattended mode, so we want the scdaemon to signal failure here — unless we are actually unlocking the smartcard manually. Here is the entire script:

#!/bin/sh
# /usr/local/sbin/pinentry-unattended -- by Simon Josefsson
if test x"$PINENTRY_USER_DATA" = xinteractive; then
    exec pinentry "$@"
fi
exit 1

What remains is a script to unlock the smartcard by providing the PIN. This is typically invoked manually if the server has restarted for some reason. Don’t worry, any ssh sessions invoked by cron until you have managed to unlock the smartcard will fail with an authentication error — it won’t hang waiting for a PIN to be entered.

#!/bin/sh
# /usr/local/sbin/unlock-smartcard -- by Simon Josefsson.
. /var/run/gpg-agent-info.env; export GPG_AGENT_INFO SSH_AUTH_SOCK SSH_AGENT_PID
gpg-connect-agent 'scd killscd' /bye > /dev/null
while ! gpg-connect-agent 'scd serialno' /bye | grep -q SERIALNO; do
    sleep 1
done
PINENTRY_USER_DATA=interactive
export PINENTRY_USER_DATA
checkpin

And the script checkpin is as follows:

#!/bin/sh
# /usr/local/sbin/checkpin -- by Simon Josefsson.
id=`gpg-connect-agent 'scd serialno' /bye | head -1 | cut -d\  -f3`
gpg-connect-agent "scd checkpin $id" /bye | grep -q OK

At this point, you should have everything configured and installed. Don’t forget to chmod +x the scripts. The typical use-pattern is as follows. After the machine has been started, gpg-agent is running but the smartcard is not unlocked with the PIN. You need to manually login to the machine and run ‘unlock-smartcard’ and enter the PIN. In the script that runs the backup jobs, invoked via cron, make sure that the first line of the scripts reads (assuming Bourne shell script syntax):

. /var/run/gpg-agent-info.env; export GPG_AGENT_INFO SSH_AUTH_SOCK SSH_AGENT_PID

To avoid needlessly attempting ssh connections if the smartcard is not unlocked, your backup script can also call the checkpin code and abort if it doesn’t return true.

checkpin || exit 1

Some final words about debugging. A basic command to run to check that the GnuPG side is working is gpg --card-status, it should print some information about the smartcard if successful. To check that the SSH agent part is working, use ssh-add -L. If you get error messages, try killing the scdaemon process by running killall -9 scdaemon and let gpg-agent respawn a new scdaemon process.

That’s it! If you like my writeup, please flattr it.

Syndicated 2011-10-11 09:34:41 from Simon Josefsson's blog

OpenWRT with Huawei E367 and TP-Link TL-WR1043ND

The ability to connect a 3G modem to a wireless router to form a Internet connected ad-hoc network of machines is very powerful. I’ve done this many times and have written about it before (e.g., see my OpenWRT writeup page) but I recently did it with modern hardware again. Here I will use the TP-Link TL-WR1043ND wireless router (available here for around $50) together with the Huawei E367 3G UMTS/HSDPA modem. Other wireless routers and modem should work fine. The software is OpenWRT 10.03 although I hope to redo this with LibreWRT eventually. My writeup is mostly focused around what is happening around the prompt, so it is mostly a cut’n'paste terminal session with a comment interlined.

Router and modem

root@choco:~# cd /tmp
root@choco:/tmp# wget http://downloads.openwrt.org/backfire/10.03/ar71xx/openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin
Connecting to downloads.openwrt.org (78.24.191.177:80)
openwrt-ar71xx-tl-wr 100% |*******************************|  2688k 00:00:00 ETA
root@choco:/tmp# md5sum openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin
9927973ba5da65d0d52e255397452b87  openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin
root@choco:/tmp# mtd -r write /tmp/openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin firmware
Unlocking firmware ...
Writing from /tmp/openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin to firmware ...
Rebooting ...

jas@latte:~$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
 === IMPORTANT ============================
  Use 'passwd' to set your login password
  this will disable telnet and enable SSH
 ------------------------------------------

BusyBox v1.15.3 (2010-04-06 03:14:11 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 Backfire (10.03, r20728) --------------------------
  * 1/3 shot Kahlua    In a shot glass, layer Kahlua
  * 1/3 shot Bailey's  on the bottom, then Bailey's,
  * 1/3 shot Vodka     then Vodka.
 ---------------------------------------------------
root@OpenWrt:/# passwd
Changing password for root
New password:
Retype password:
Password for root changed by root
root@OpenWrt:/# sed -i -e 's/OpenWrt/choco/' /etc/config/system
root@OpenWrt:/# sed -i -e 's/192.168.1.1/192.168.1.46/' /etc/config/network
root@OpenWrt:/# cat>/etc/dropbear/authorized_keys
ssh-rsa AAAAB3NzaC1yc2...
^D
root@OpenWrt:/# dropbearkey -y -f /etc/dropbear/dropbear_rsa_host_key
Public key portion is:
ssh-rsa AAAA... root@OpenWrt
Fingerprint: md5 45:fd:62...
root@OpenWrt:/#

root@OpenWrt:/# opkg update
Downloading http://downloads.openwrt.org/backfire/10.03/ar71xx/packages/Packages.gz.
Inflating http://downloads.openwrt.org/backfire/10.03/ar71xx/packages/Packages.gz.
Updated list of available packages in /var/opkg-lists/packages.
root@OpenWrt:/# opkg install kmod-ath9k wpad-mini
...
Configuring iw.
Configuring kmod-crypto-core.
Configuring kmod-crypto-arc4.
Configuring kmod-crypto-aes.
Configuring wireless-tools.
Configuring kmod-cfg80211.
Configuring kmod-mac80211.
Configuring kmod-ath.
Configuring kmod-ath9k.
Configuring crda.
Configuring wpad-mini.
root@OpenWrt:/#

root@OpenWrt:/# opkg install comgt kmod-usb-serial kmod-usb2 kmod-usb-uhci kmod-usb-ohci usb-modeswitch
...
Configuring kmod-nls-base.
Configuring kmod-usb-core.
Configuring chat.
Configuring kmod-usb-ohci.
Configuring kmod-usb2.
Configuring comgt.
Configuring usb-modeswitch.
Configuring kmod-usb-serial.
Configuring kmod-usb-uhci.
root@OpenWrt:/#

root@OpenWrt:/# sync
root@OpenWrt:/# reboot

root@choco:~# cat /proc/bus/usb/devices
...
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=1446 Rev= 0.00
S:  Manufacturer=Huawei Technologies
S:  Product=HUAWEI Mobile
C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
root@choco:~#

root@choco:~# cat>/etc/usb-modeswitch.conf
EnableLogging=1

DefaultVendor= 0x12d1
DefaultProduct=0x1446

TargetVendor=  0x12d1
TargetProductList="1001,1406,140b,140c,1412,141b,14ac,1506"

CheckSuccess=20

MessageContent="55534243123456780000000000000011062000000100000000000000000000"
root@choco:~#

root@choco:~# usb_modeswitch 

Looking for target devices ...
 No devices in target mode or class found
Looking for default devices ...
 Found default devices (1)
Accessing device 002 on bus 001 ...
Using endpoints 0x01 (out) and 0x81 (in)
Inquiring device details; driver will be detached ...
Looking for active driver ...
 No driver found. Either detached before or never attached

SCSI inquiry data (for identification)
-------------------------
  Vendor String: HUAWEI
   Model String: Mass Storage
Revision String: 2.31
-------------------------

USB description data (for identification)
-------------------------
Manufacturer: Huawei Technologies
     Product: HUAWEI Mobile
  Serial No.: not provided
-------------------------
Setting up communication with interface 0 ...
Trying to send the message to endpoint 0x01 ...
 OK, message successfully sent

Checking for mode switch (max. 20 times, once per second) ...
 Waiting for original device to vanish ...
 Original device can't be accessed anymore. Good.
 Searching for target devices ...
 Searching for target devices ...
 Searching for target devices ...
 Searching for target devices ...
 Searching for target devices ...
 Found correct target device

Mode switch succeeded. Bye.

root@choco:~#

root@choco:~# cat /proc/bus/usb/devices
...
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=1506 Rev= 0.00
S:  Manufacturer=Huawei Technologies
S:  Product=HUAWEI Mobile
C:* #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
A:  FirstIf#= 1 IfCount= 2 Cls=02(comm.) Sub=00 Prot=00
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=(none)
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=(none)
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=(none)
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
root@choco:~#

root@choco:~# cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

/usr/bin/usb_modeswitch
exit 0
root@choco:~#

root@choco:~# cat>/etc/modules.d/60-usb-serial
usbserial vendor=0x12d1 product=0x1506 maxSize=4096
root@choco:~# rmmod usbserial
root@choco:~# insmod usbserial vendor=0x12d1 product=0x1506 maxSize=4096
root@choco:~# gcom -d /dev/ttyUSB3 info
##### Wireless WAN Modem Configuration #####
Product text:
====

Manufacturer: huawei
Model: E367
Revision: 11.807.05.00.00
IMEI: 353613040739180
+GCAP: +CGSM,+DS,+ES
OK
====
Manufacturer:           huawei
IMEI and Serial Number: 353613040739180
Manufacturer's Revision:
11.807.05.00.
Hardware Revision:      NOT
Network Locked:         ERROR:
Customisation:          NOT SUPPORT
Band settings:          (NOT)
APN:                    ERROR:
##### END #####
root@choco:~#

root@choco:~# cat /etc/config/network
config 'interface' 'loopback'
       option 'ifname'   'lo'
       option 'proto'    'static'
       option 'ipaddr'   '127.0.0.1'
       option 'netmask'  '255.0.0.0'

config 'interface' 'lan'
        option 'ifname'   'eth0.1'
        option 'type'     'bridge'
        option 'proto'    'static'
        option 'ipaddr'   '192.168.1.46'
        option 'netmask'  '255.255.255.0'

#config 'interface' 'wan'
#        option 'ifname' 'eth0.2'
#        option 'proto' 'dhcp'

config 'switch'
	option 'name' 'rtl8366rb'
        option 'reset' '1'
        option 'enable_vlan' '1'

config 'switch_vlan'
        option 'device' 'rtl8366rb'
        option 'vlan' '1'
        option 'ports' '1 2 3 4 5t'

config 'switch_vlan'
        option 'device' 'rtl8366rb'
        option 'vlan' '2'
        option 'ports' '0 5t'

config interface wan
        option ifname   ppp0
        option proto    3g
        option device   /dev/ttyUSB0
        option apn      bredband.tre.se
        option pincode  8328
root@choco:~# cat /etc/config/wireless
config wifi-device  radio0
	option type     mac80211
	option channel  5
	option macaddr	00:27:19:fc:87:b2
	option hwmode	11ng
	option htmode	HT20
	list ht_capab	SHORT-GI-40
	list ht_capab	DSSS_CCK-40

config wifi-iface
	option device   radio0
	option network  lan
	option mode     ap
	option ssid     Grisslan
	option encryption psk2
	option key	  notforyoutosee

config wifi-iface
        option device     radio0
        option network    lan
        option mode       wds
        option bssid      00:1F:C6:60:D3:11
        option ssid       GrisslanWDS
        option encryption psk2
        option key        thisisalsosecret
root@choco:~# reboot
root@choco:~#

root@choco:~# ifup wan
Trying to set PIN
PIN set successfully
root@choco:~# logread |tail -20
May 21 13:41:20 choco local2.info chat[2419]: send (ATD*99***1#^M)
May 21 13:41:20 choco local2.info chat[2419]: expect (CONNECT)
May 21 13:41:20 choco local2.info chat[2419]: ^M
May 21 13:41:20 choco local2.info chat[2419]: ATD*99***1#^M^M
May 21 13:41:20 choco local2.info chat[2419]: CONNECT
May 21 13:41:20 choco local2.info chat[2419]:  -- got it
May 21 13:41:20 choco local2.info chat[2419]: send ( ^M)
May 21 13:41:20 choco daemon.info pppd[2412]: Serial connection established.
May 21 13:41:20 choco daemon.info pppd[2412]: Using interface ppp0
May 21 13:41:20 choco daemon.notice pppd[2412]: Connect: ppp0  /dev/ttyUSB0
May 21 13:41:24 choco daemon.warn pppd[2412]: Could not determine remote IP address: defaulting to 10.64.64.64
May 21 13:41:24 choco daemon.notice pppd[2412]: local  IP address 95.209.96.115
May 21 13:41:24 choco daemon.notice pppd[2412]: remote IP address 10.64.64.64
May 21 13:41:24 choco daemon.notice pppd[2412]: primary   DNS address 80.251.201.177
May 21 13:41:24 choco daemon.notice pppd[2412]: secondary DNS address 80.251.201.178
May 21 13:41:24 choco daemon.info dnsmasq[1028]: reading /tmp/resolv.conf.auto
May 21 13:41:24 choco daemon.info dnsmasq[1028]: using nameserver 80.251.201.178#53
May 21 13:41:24 choco daemon.info dnsmasq[1028]: using nameserver 80.251.201.177#53
May 21 13:41:24 choco daemon.info dnsmasq[1028]: using local addresses only for domain lan
May 21 13:41:25 choco user.notice rdate: Synced with ptbtime1.ptb.de
root@choco:~#

May 21 12:25:04 choco daemon.notice pppd[1157]: primary   DNS address 10.11.12.13
May 21 12:25:04 choco daemon.notice pppd[1157]: secondary DNS address 10.11.12.14

# Written by Simon Josefsson May 2011.
root@choco:~# cat> /etc/hotplug.d/iface/01-reconnect-if-dns-is-broken
case "${ACTION:-ifup}" in
    ifup)
	    if grep -q 10.11.12.13 /tmp/resolv.conf.auto; then
		(sleep 30 && ifdown wan && ifup wan) &
	    fi
	    ;;
esac
root@choco:~# chmod +x /etc/hotplug.d/iface/01-reconnect-if-dns-is-broken
root@choco:~#

Introducing the OATH Toolkit

I am happy to announce a project that I have been working quietly on for about a year: the OATH Toolkit. OATH stands for Open AuTHentication and is an organization that specify standards around authentication. That is a pretty broad focus, but practically it has translated into work on specifying standards around deploying and using electronic token based user authentication such as the YubiKey.

OATH’s most visible specification has been the HOTP algorithm which is a way to generate event-based one-time passwords from a shared secret using HMAC-SHA1. HOTP has been published through the IETF as RFC 4226. Built on top of HOTP is the time-based variant called TOTP, which requires a clock in the token. OATH do some other work too, like specifying a data format for transferring the token configuration data (e.g., serial number and shared secret) called PSKC.

The aim of my project OATH Toolkit is to provide an implementation of various OATH related technologies. I’m intentionally leaving it open ended because you never know what they may specify that I find interesting. However, the primary goal has been to focus on HOTP and TOTP. Throughout 2010, the project was called HOTP Toolkit but that name made it difficult to support TOTP in a non-confusing way. During the last month, after discussion with Daniel Pocock on Dynalogin which is a potential consumer of my package, I took the time to create a fork of the HOTP Toolkit and the OATH Toolkit was born.

Now what does the OATH Toolkit actually do? Primarily it provides a library called liboath that implements HOTP and TOTP. Liboath is a relatively small library, and my goal is to keep it well documented and of high quality. There is GTK-DOC generated API documentation. Of course there is a command line tool to go with it, called oathtool which makes working with HOTP/TOTP from the command line easier. It can generate and validate one-time passwords. Let’s say you want to generate the first four OTP based on the dummy key 1234.

jas@latte:~$ oathtool -w4 1234
376439
299783
041392
819202
158134
jas@latte:~$

By default the tool is using HOTP, but you can switch it into TOTP mode with the –totp parameter. The output OTP will now depend on the current time on your machine, unless you specify the time manually using the –now parameter.

jas@latte:~$ oathtool –now=”2011-01-20 15:46 UTC” –totp 1234
527971
jas@latte:~$

The tool can do more, check the oathtool man page for all the details.

The final component of the OATH Toolkit is a PAM module pam_oath. With it, you can login to your machine using an OTP and optionally a password. Right now the user and password management is simplistic, but that should improve over time. To setup single-factor authentication for su you would create a file containing the user information and HOTP key as /etc/users.oath like this:

HOTP root – 1234

Then configure PAM to use the pam_oath module like this in /etc/pam.d/su:

auth requisite pam_oath.so debug usersfile=/etc/users.oath window=20

The user file will be rewritten every time you su to hold the current state. There is a README for the PAM-module with more documentation.

That’s it for an intro! From the OATH Toolkit webpage we link to binary packages for Debian and Ubuntu so please try the OATH Toolkit yourself and provide feedback to the oath-toolkit-help mailing list.

Syndicated 2011-01-20 16:09:37 from Simon Josefsson's blog

On Password Hashing and RFC 6070

The RFC Editor has announced a new document, RFC 6070, with test vectors for PKCS5 PBKDF2. The document grow out of my implementation of SCRAM for GNU SASL. During interop testing, more than one other implementation turned out to have mistakes in the PBKDF2 implementation. It didn’t help that there weren’t any stable test vectors for PBKDF2, so that we could do black-box testing of our PBKDF2 implementations against well-known and stable test vectors. Debugging this was time consuming. The document addresses this problem.

So what is PBKDF2?

Briefly, the PBKDF2 is the state of the art way to convert a password string into a cryptographic binary key. There are many ways to design such an algorithm. To understand why PBKDF2 is designed the way it is we need some basic understanding. The typical attack you would be concerned with is if someone compromises your authentication servers and steals the credential database. This is what happened with the recent Gawker attack, where passwords were apparently stored in clear text.

The first security improvement compared to storing passwords in clear text is to only store a hashed or encrypted form of the password. Hashing is preferable over encryption in this context, because with encryption it is possible to go back to the unencrypted form (if you know the key) whereas with a hash it is computationally infeasible to do so.

The downside of hashing is that it is impossible to be compatible with all kind of authentication systems: the hash of the password in the database needs to be computed using the same algorithm as the system will be using. Unfortunately there are many different schemes out there to do password hashing, including the old Unix crypt(3) algorithm and the Windows LM-hash. You normally never know in advance what kind of systems your hashed credential database needs to work for, so you have to pick some set of algorithms and hope for the best.

The next security improvements are iterations and salting.

Iterations means to run the hash function not once, but hundreds or even thousands of times, on the input data (e.g., password). The extra time is hardly noticeable for the user, but for an attacker who is testing an entire dictionary of common passwords against your hash, making the work cost thousand times higher quickly makes the attack vector computationally infeasible.

Salting means to include something other than the password in the input to the hash function, typically a random string. Without salting, a pre-computed rainbow table would provide a dictionary attack against all hashed password databases (one rainbow table per hashing algorithm). By using a sufficiently long and random salt, a rainbow table for one system is not applicable to another system. Since generating a rainbow table is time consuming, this adds another barrier to the attacker.

PBKDF2 combines these three concepts — hashing, iteration and salting — into one construct, and it is designed flexible enough so that it can work on any pseudo-random function. In practice, I’ve only ever seen HMAC-SHA1 be used.

Some final words on the publication behind RFC 6070: Out of my earlier publications, this was the document that (by a large margin) spent the least time in the IETF process. You see various milestones of the document in the RFC 6070 datatracker history page. The time in the publication process was from 2010-08-09 to 2011-01-06. One month was in the AUTH48 state, of which the initial 20 days were waiting for me to respond. Thank you to my sponsoring AD, Sean Turner, for making this possible!

Syndicated 2011-01-07 12:55:05 from Simon Josefsson's blog