Heartbleed OpenSSL vulnerability

Tuesday, 04. 8. 2014  –  Category: stash, sw

Here’s a oneliner to check if a remote server might be vulnerable by checking if it advertises the Heartbeat TLS extention during connection negotiation.


$ openssl version
OpenSSL 1.0.1e-freebsd 11 Feb 2013
$ < /dev/null openssl s_client -connect example.com:443 -tlsextdebug 2>&1 | grep -i heartbeat
TLS server extension "heartbeat" (id=15), len=1

It’s important that the local OpenSSL version supports the extension, otherwise it will not be listed during the negotiation.

Better yet, grab Heartbleed test tool


$ go get github.com/FiloSottile/Heartbleed
$ ${GOPATH}/bin/Heartbleed example.com:443
2014/04/08 14:12:31 ([]uint8) {
 00000000  02 00 79 68 65 61 72 74  62 6c 65 65 64 2e 66 69  |..yheartbleed.fi|
 00000010  6c 69 70 70 6f 2e 69 6f  59 45 4c 4c 4f 57 20 53  |lippo.ioYELLOW S|
 00000020  55 42 4d 41 52 49 4e 45  02 6d 00 00 b3 de ab 6c  |UBMARINE.m.....l|
 00000030  71 ac cd 71 a9 63 74 36  8f ac 49 7d 32 36 48 00  |q..q.ct6..I}26H.|
 00000040  00 00 16 00 14 00 00 00  00 00 00 00 00 00 00 00  |........example.|
 00000050  00 00 00 00 00 00 00 00  00 00 05 00 05 01 00 00  |com.............|
 00000060  00 00 00 0a 00 08 00 06  00 17 00 18 00 19 00 0b  |................|
 00000070  00 02 01 00 00 0d 00 0a  00 08 04 01 8d 71 65 6d  |.............qem|
 00000080  27 9d 51 a8 01 37 02 50  63 67 ca db              |'.Q..7.Pcg..|
}

2014/04/08 14:12:31 example.com:443 - VULNERABLE

/dev/tty inside LXC under libvirt on CentOS 6

Thursday, 09. 26. 2013  –  Category: sw

Search engine fodder:

The stock CentOS RPMs:

Sep 11 06:42:15 Installed: libvirt-0.10.2-18.el6_4.9.x86_64

don’t create a /dev/tty inside the LXC container. This breaks SSH (host key prompts), sudo (password prompt) and doubtless more things too.

To fix roll something more current from Fedora:

Sep 25 11:29:23 Updated: libvirt-1.1.2-3.local.x86_64

Seems the project first thought /dev/tty was a risky proposition (!), but changed their mind.

IPv6 for SmartOS guest VMs on Hetzner hosts

Sunday, 08. 25. 2013  –  Category: sw

This Hetzner wiki page covers how to configure a SmartOS installation at Hetzner including how to route an IPv4 subnet to guests via the global zone.

Matters are a little bit more involved for IPv6, because

  • vmadm and friends don’t support IPv6, so you have to configure guests manually
  • Hetzner network won’t talk to the virtual MAC addresses generated by SmartOS

I ended up doing something similar to the IPv4 setup, but all inside the one /64 IPv6 subnet that came with the server. The global zone creates a bridge for the IPv6 traffic, and guests route via that instead of the upstream gateway at Hetzner. Hetzner provide guidance for a similar approach for Linux VM servers.


# setup IPv6 on the physical nic
ifconfig rge0 inet6 plumb 
ifconfig rge0 inet6 addif ${IP6SUBNET}::1/${IP6PREFIX} up
route add -inet6 ${IP6GATEWAY} ${IP6SUBNET}::1 -interface
route add -inet6 default ${IP6GATEWAY}

# create a bridge and an etherstub
dladm create-bridge six
dladm create-etherstub stub2
dladm set-linkprop -p mtu=1500 stub2

# bridge the physical nic and the stub
dladm add-bridge -l stub2 -l rge0 six

# add a vnic to the stub in the global zone with an adjacent address
dladm create-vnic -l stub2 vnic2
ifconfig vnic2 inet6 plumb
ifconfig vnic2 inet6 addif ${IP6SUBNET}::2/${IP6PREFIX} up

# forward IPv6 packets to/from outside world
svcadm enable ipv6-forwarding

  • Guests set their gateway to the vnic2 address.
  • FreeBSD guests (seemingly others too) need to disable Duplicate Address Detection with a judicious net.inet6.ip6.dad_count=0 sysctl tweak.
  • I wrapped the script up as a SMF service based on this Gist.
  • I am unsure why the vnic is necessary, but the IPv6 alias on the physical NIC wasn’t visible on the bridge to guests.
  • This page was a useful start for dladm bridging.
  • My first time out with dladm – disclaimers apply.

Update (20140814)

To use IPv6 in the guest OS it’s important that SmartOS knows to put the guest’s NIC in the bridge. This is done through the nic_tag attribute, which needs to match the etherstub configured in the global zone. Further, allow_ip_spoofing must also be set so that SmartOS will deliver traffic outside of any IPv4 configuration.


# vmadm get xxxx-yyyy-zzzz | json nics
[
      {
    "interface": "net0",
    ...
    "nic_tag": "stub2",
    "allow_ip_spoofing": true,
    ...
  }
]

The SmartOS wiki has some good information about setting up IPv6 in a SmartOS guest OS.

« Older Entries
Newer Entries »