I love being in IT. :-)

Installing phpsh

SSH into your server, and download, build & install the binaries. This assumes you’ve downloaded the .tar.gz version.

# wget http://github.com/facebook/phpsh/tarball/master
# tar xzf facebook-phpsh-1bc1c01.tar.gz
# cd facebook-phpsh-1bc1c01/
# python setup.py build
# python setup.py install
# phpsh

As simple as that.

How do I use it?

Even more simple. Once the install is done, execute phpsh on the CLI, and get started writing PHP code.

srv ~ # phpsh
Starting php
type ‘h’ or ‘help’ to see instructions & features
php>
php>
php> echo “Testing this new PHPSH”;
Testing this new PHPSH
php>
php>
php> $dbconn = mysql_connect(‘localhost’, ‘user’, ‘pass’);
PHP Warning:  mysql_connect(): Access denied for user ‘user’@'localhost’ (using password: YES) in /usr/lib/python2.4/site-packages/phpsh/phpsh.php(534) : eval()’d code on line 1
php>
php>
php> exit;

This can help to easily test or debug some PHP code. It has syntax highlighting, tab completion (!!), manual pages, … Still not convinced? Have a look at some real-life examples for a PHP interface shell.  Seriously, awesome tool.

1. What is DNSSEC?
2. Enabling DNSSEC in your environment
3. Generating your keys: Key Signing Key (KSK) and Zone Signing Key (ZSK)
4. Adding the public keys to your zone
5. Signing the zone
6. Key rotation, zone maintenance
7. Summary
8. Links, Articles & Video

There are a few assumptions throughout this article, mostly related to directory structures as I like to keep things organized. Another method would be to create a directory per zone, and store all data within that directory.

1. I’m doing the signing for the dummy host “dns.org“
2. I have my zonefiles stored in /var/named/zones/
3. I have my Key Signing Keys stored in /var/named/KSK
4. I have my Zone Signing Keys stored in /var/named/ZSK
5. I have my Delegation Signer and Keyset stored in /var/named/SET

1) What is DNSSEC?

Here are a few links that very accurately explain DNSSEC.

• http://blog.techscrawl.com/2009/01/06/dnssec-101/
• http://en.wikipedia.org/wiki/DNSSec
• http://www.dnssec.net/
• http://www.icann.org/en/announcements/dnssec-qaa-09oct08-en.htm

2) Enabling DNSSEC in your environment

For my examples, I’ll be signing the zone “dns.org“, for which my nameserver has been configured to be authoritive. To enable DNSSEC, you’ll need to add the following to your /etc/named.conf file. Note; this is only supported in Bind version 9.3 and upwards.

# named -v
BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2

So, edit the file /etc/named.conf and add the lines in bold to the options-section.

options {
…
// DNSSEC
dnssec-enable yes;
};

3) Generating your keys: Key Signing Key (KSK) and Zone Signing Key (ZSK)

Just a small clarification on what the KSK and ZSK actually are.
ZSK: Zone Signing Key – this key will sign your records in your zonefile.
KSK: Key Signing Key – this key will sign your Zone Signing Key. This is generally a key with greater key size.

In my set-up, I have all my zones in seperate files located in /var/named/zones/*. I’ll be storing my keys in seperate folders, to keep the overview.

• /var/named/ZSK: all zone signing keys
• /var/named/KSK: all key signing keys

Note; ideally, you would want to store your keys on a offline machine, sign your zones there, and transfer them to your online nameserver. However, in set-ups where zones are reconfigured daily, this would cause too much overhead.

First, we’ll generate the Zone Signing Key for dns.org:

# cd /var/named/ZSK
# dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE dns.org

This will generate 2 files, using the same naming format: K<zone>.<id>.key (ie:  Kdns.org.+005+03486.key) and K<zone>.<id>.private (ie: Kdns.org.+005+03486.private). The first file holds the public key, and the .private file holds our private key.

Now, to generate the Key Signing Key for dns.org:

# cd /var/named/KSK
# dnssec-keygen -r /dev/urandom -a RSASHA1 -b 4096 -n ZONE -f KSK dns.org

This will also generate 2 files, using the same naming format as the ZSK.

Note; every time you generate a KSK or a ZSK, it will assign a new random ID to the filename.

4) Adding the public keys to your zone

After having generated the KSK and ZSK, we need to add the public key of each file to the zone. In my environment (using the folders described above), this would mean:

# cat /var/named/ZSK/Kdns.org.*.key >> /var/named/zones/dns.org
# cat /var/named/KSK/Kdns.org.*.key >> /var/named/zones/dns.org

This will add the appropriate public key to my zone. I’ve used the wildcard “Kdns.org.*.key” because we can’t predict the ID. However, if you regenerate your keys, you’ll have multiple files that would be added with that wildcard (as there are multiple public keys), so be cautious to remove the “old” public and private keys first.

If you take a look at your zonefile now, you’ll see there are now 2 extra DNSKEY records which have been added.

dns.org. IN DNSKEY 256 3 5 “random chars”
dns.org. IN DNSKEY 257 3 5 “random chars”

The first DNSKEY, with the number “256″, is the smaller Zone Signing Key, with the actual key appended at the back. The second DNSKEY with number “257″ is the larger Key Signing Key with the actual key at the end.

After you’ve restarted your nameserver (to activate the newly updated zone) you can check if the records were added OK by trying to query for them:

# dig @localhost DNSKEY dns.org

The ANSWER SECTION should give you 2 DNSKEY’s.

5) Signing the zone

To sign the zone, we need the command to point at the zonefile, the ZSK and KSK.

# cd /var/named/SET
# dnssec-signzone -o dns.org -k /var/named/KSK/Kdns.org.+005+48967.key /var/named/zones/dns.org /var/named/ZSK/Kdns.org.+005+03486.key

Let’s break this down. The first parameter, “- 0“, tells us which zone to sign (in this case, dns.org). The second parameter, “- k“, allows us to point at the Key Signing Key. Next up is the location of our zonefile, followed by the location of the Zone Signing Key.

Note; the IDs in the filenames will vary for your set-up.

Afterwards, you’ll notice there are now 2 extra files generated in the /var/named/SET directory. First is “dsset-dns.org.”, followed by “keyset-dns.org.”. I’ve placed these in a seperate directory on purpose, to keep the overview in the /var/named/zones directory.

You’ll also notice that in /var/named/zones, beside the already existing “dns.org” file, there is now also a file called “dns.org.signed” which holds the signed version of the zonefile. It’s also much larger than the original zonefile, because all RRs (Resource Records) are now signed. For reference, here is the original zonefile, the zonefile with dnskey, and the fully signed zonefile.

Now we can change our named.conf to point at the “.signed” version to load this signed zone.

zone “dns.org” IN {
type master;
file “/var/named/zones/dns.org.signed”;
};

And reload your nameserver to test the newly signed zone.

# dig @localhost dns.org +dnssec

You’ll notice every record is now accompanied by a RRSIG Resource Record as well, which holds the signed version of that Resource Record you requested.

6) Key rotation, zone maintenance

A) Once a zone has been signed, the RRSIG‘s will have a lifespan of 30 days. After these 30 days, the signatures will expire and cause zones to no longer validate. The only method to “reset” that 30 day timer, is to resign your zones (see step 5 above).

B) Whenever you modify the zone, to add/modify/remove records, you will also have to resign the original zonefile, to re-generate the .signed version.

C) You should re-generate your KSK and ZSK on time. It’s advised to re-generate the KSK every year, and the ZSK every 3 months. The longer the key has been in existance, the greater the chance it’s been “compromised”. To do so, delete the old key (public & private), and re-generate using step 3 of this article.

7) Summary

All in all, enabling DNSSEC for one zone comes down to:

1. Generate a ZSK and KSK (per zone) using dnssec-keygen
2. Include those keys into your zonefile
3. Sign the zone using dnssec-signzone
4. Load your signed zonefile
5. Reload the zone or nameserver

8) Links, Articles & Video

I managed to implement DNSSEC fairly simply, because the following information was made available on the web which explained it very well.

• DNSSEC In 6 minutes (PDF)
• DNSSEC Mini Howto (html)
• Erik Berls – Deploying DNSSEC – LayerOne 2009 (Youtube video, 55min)
• Enabling DNSSEC On Bind (html)
• Practical DNS Setup: How To Implement DNSSEC (practical documents)
• Implementing DNSSEC (dyndns)

If you’d like to add something, please use the comments below. If I’ve missed some vital information, or published some awful mistake, please let me know.

options {
…
// DNSSEC
dnssec-enable yes;
};

Video: A Day In The Life Of A Facebook Engineer

Obviously, Facebook has seen amongst the most impressive scalability problems ever. And here are some of the interesting bits, which can be used to manage and tune high traffic & high availability websites.

• HipHop for PHP: transforms PHP code to optimized C++ code, for greater CPU efficiency. Started as a “hack” on one of Facebook’s Hackatons.
• Memcached: duh … only downside is it requires some PHP recoding to make use of it (but shouldn’t be much if you’re already using frameworks or database classes).
• Services: seperate key systems, make them independant of each other (news feed, photos, video, … – allows you to disable one service, and keep the rest going)
• CFEngine: automating sysadmin tasks (alternatives: Puppet, Chef). Ideal in “clone” environments, a cloud of servers running a similar configuration. I have my doubts on highly customized environments, where each server is configured individually to specifics needs.
• dsh: distributed shell, run commands on any set of hosts in your network

Monitoring will be needed to keep an eye on your infrastructure:

• Ganglia: outdated, but very fast
• Nagios

Take a look at other Open Source contributions made by Facebook’s Team!

For sale: Classic Mini, British Open (Special Edition). This version was created in limited stock. Only 1.000 in the UK, and 2.000 more in Europe.

It features an electric sunroof, 1.3l petrol engine, and the driving experience of a lifetime. It’s on sale since I lack the time to fully enjoy it. It’s among the best preserved British Open’s I’ve ever seen, fully restored by it’s previous owner.

It’s located on several dealer-sites:

• 2dehands.be
• hebbes.be
• kapaza.be
• vlanauto.be
• autoscout24.be
• autozone.be

And if you’re up for some mild reading, I would recommend: The History of Mini. Some more info on the car can be found here.

Redirects TCP connections from one IP address and port to another. rinetd is a single-process server which handles any number of connections to the address/port pairs specified in the configfile.

How to use it

First of, download it from the website. The Windows 2000 version also works on Server 2003.

Create a new config file, called “config.cfg” in the same folder as where you’ve extracted the file. Add the following line. The format is “<source> <port> <destination> <port>“.

0.0.0.0 80 192.168.100.1 80

And start the daemon by executing the following.

C:\Folder\Where\You\Extracted\rinetd>rinetd.exe -c config.cfg

This will start the daemon, using the config file mentioned. The example lets you redirect all traffic (0.0.0.0) on port 80 to a new server (192.168.100.1) on port 80. A perfect HTTP redirection!

You can add multiple rules, change ports, … A new rule should be started on a new line.

The IHL - or Internet Header Length – was removed from IPv6, as each IPv6 header will always be 40 bytes in length, despite the content. The Time to Live has been rephrased to “Hop Limit“, which more accurately describes its purpose. Each hop the fragment passes, the counter is reduced by value 1. As soon as the counter hits zero, the packet is destroyed. The Header Checksum was removed from IPv6.

The IPv6 looks less cluttered, and holds less fragmented data, but more to-the-point information. The Version holds value 6, to indicate IPv6. The Flow Label can be used to label certain packets belonging to the same stream or session, so they are more easily distinguishable. It could be used by routers to uphold certain Quality of Service settings, without having to analyze the packet entirely.

The Payload Length holds the length of the user data to be transmitted, as well as the length of any additional headers that might be sent along. Since the header has a fixed 40 byte size, the Total Length from IPv4 (which included both the header size + user data size) is no longer needed.

For a more detailed explanation, I’ll refer you to the post on Cisco’s website titled IPv6 internals.

Scanning ~3.7billion hosts (IPv4) vs a couple trillion hosts (IPv6)
This is probably the biggest advantage that IPv6 has over IPv4; it’s shere number of available IP addresses. A botnet nowadays can scan all of our IPv4 addresses in a relatively timely manner. It will never scan all assigned IPv6 ranges, because it’s just too big.

Of course, any targeted scan for a specific (smaller) range could yield results, but you’d still only see a fragment of all available addresses. I predict we’ll be seeing less computer infections in the first 20 minutes of being online.

IPSec built-in IPv6
For IPv4, IPSec was an extra protocol on top of the IP layer, which added encryption to individual IP packets (versus encrypting specific TCP streams with SSL). IPv6 has built-in support for IPSec, which means it can also be applied to UDP streams.

However, having the ability to use IPSec, does not necessarily mean it will be used. It requires a number of modifications in the applications themselves, to support and implement it. But having IPSec available for all hosts with IPv6, could mean a broader adaptation of the technology.

NAT won’t save you this time
Most home networks are relatively safe, as they only have one router in their network, and use NAT for all internal routing. Doing so gives you an advantage to the outside world, as your computer can’t be reached directly (unless through UPnP or port forwarding), but only your router can. Of course, this can be circumvented, but it’s a layer of “security”.

Since NAT was introduced as a means to stop the rapid assignment of IPv4 addresses, it was ment to be deprecated in IPv6. It has more advantages than disadvantages to give all hosts a publicly routable IP address, so IPv6 strives towards this. Your local LAN will probably contain hosts (computers, routers, NAS’s, printers, …) that all have public IPv6 addresses.

So your private LAN will no longer form a barrier, but direct access to your hosts will be possible. Which brings us to the next point.

Firewalling IPv4 traffic, doesn’t automatically mean firewalling IPv6 traffic
This is something very important to understand. A software firewall designed to filter IPv4 traffic based on IP policies, will probably not filter IPv6 addresses (some firewalls will, some won’t). This means that traffic targetted towards your IPv6 address, will most likely not be stopped by your IPv4 firewall.

Add to this that whenever you bring up a NIC (Network Interface Card), and attach a cable, an IPv6 address will automatically be assigned to that interface. So whenever you install a new host, and hook it up to your network, it will be reachable over IPv6 (but probably limited to the current network only).

Here’s how it works. The router sends out a “router advertisement” or RA, which contains the first 64bit of an IPv6 address. This value is defined on the router, by the network administrator. The host itself will use its own MAC Address, add some magic, and use it as the last 64 bit of the IPv6 address. Combine those, and you have a unique IPv6 network address.

Take the following example: the router will “advertise” the first 64 bits of the 128bit IPv6 address as 2001:0af2:0005:0001.

The MAC address of the node’s network card is 00:0A:95:A4:40:10, which in turn consists of 2 distinguishable parts. The first 24 bits (or the first 3 ‘blocks’ in the MAC address) are the OUI or Organizationally Unique Identifier. In this example, this would be 000A95. This is the OUI that is assigned by IEEE (Institute of Electrical and Electronic Engineers), and is guaranteed to be unique worldwide. The second part of the MAC address, or A44010 is a unique part that the owner of the OUI can assign.

MAC Address Layout

The first part of the MAC address is guaranteed to be unique by IEEE, the second part is guaranteed to be unique by the owner the of OUI (=the company which was assigned that specific OUI; ie: Apple, Xerox, HP, …).

The MAC address, however, has a so called “universal / local bit”. A specific bit (0/1) to indicate whether the MAC address is globally unique (provided by the hardware supplier), or not (it might be altered afterwards) and whether the MAC address is a multicast address, or a unicast address.

If a MAC address is not available, the “universal / local bit” is set to one, to indicate that the MAC address isn’t globally unique, and can’t be used universally. The end result – a combination of the 64 bit router-supplied prefix, and the MAC address – will form a Modified EUI-64 instead of a regular EUI-64 (because the “u/l bit” was flipped).

For those keeping count, you will have noticed that a MAC address does not contain 64 bits, and in itself would not be sufficient to be used as the last 64 bits of the IPv6 address. The 48bit MAC address should first be turned into a 64bit EUI-64, by adding the hexademical value FFEE in between the OUI (first 6 bits) and the owner-assigned bits (last 6 bits).

00:0A:95:A4:40:10 is the full MAC address
000A95 is the OUI
A44010 is the organization-assigned value
000A95FFEEA44010 is the 64-bit EUI-64

The end result, 000A95FFEEA44010, is EUI-64 which can be used as the last 64 bits of an IPv6 address.

In total, our IPv6 address could be as follows.

2001:0af2:0005:0001 are the first 64 bits advertised by our router
000a:95ff:eea4:4010 are the last 64 bits, made from the MAC address to a EUI-64
2001:0af2:0005:0001:000a:95ff:eea4:4010 is the logical combination of both
2001:af2:5:1:a:95ff:eea4:4010 is the shortened version, with leading zeros removed

If there are multiple routers, each handing out different address prefixes, the host will create a IPv6 address for each of those prefixes. A router can even announce a new prefix, and the connected clients will generate a new IP based on this new prefix. To keep existing connections alive, the previous IP address isn’t deleted right away, but marked as “deprecated” first.

Using Stateless Autoconfiguration can be a good way to assign the same IP to the same host, providing the MAC address of that host doesn’t change. Should a NIC (Network Interface Card) be replaced, removed or added, the MAC address will change, and inevitabely also its IPv6 address. For this reason, Stateless Autoconfiguration will be used primarily in small to medium sized organizations, and never in datacenter/hosting businesses which rely heavily on fixed IP addresses.

For Windows systems, a random MAC address will be generated to create a random IPv6 address which will be used for outgoing sessions. This will aid privacy, as your IP will never be the same (whereas the default Stateless Autoconfiguration will re-generate the same IP over and over again).

[root@srv~]# /etc/init.d/psa start

Starting xinetd service…               done

Starting named service…             done

Starting mysqld service…           done

Plesk: Starting Mail Server… already started

Starting mail handlers tmpfs storage

Starting Plesk…                       failed

There won’t be an obvious error message in any log file location (/var/log/*, /usr/local/psa/var/log/*, /usr/local/psa/admin/logs/*), but it will most likely be caused by your recent openssl upgrade. Solution is this.

Edit April 2nd: There’s now a Knowledge Base article available by Parallels on this issue: “Latest update of openssl breaks Parallels panel“. You might want to read that too, same solutions as stated below.

Edit April 2nd²: Parallels has release an official solution, using a Plesk update: http://kb.parallels.com/en/8338

1) Downgrade method

[root@srv~]# yum downgrade openssl openssl-devel

2) Using RPM packages

You have to download these first! After completing the next steps, you’ll be without openssl – and downloading through wget or curl won’t  work because of missing libraries. Please take note: the following is at your own risk (and if you lose your SSH connection in the meanwhile, you’re screwed).

Find your current OpenSSL version, it should read version “el5_4.6″.

[root@srv~]# rpm -qa | grep -i openssl
openssl-0.9.8e-12.el5_4.6

Remove the package (if you haven’t downloaded the openssl package yet, do so first !!). (due to the font of this blog, it’s confusing, but the parameter = ‘ – - nodeps’).

[root@srv ~]# rpm -e –nodeps openssl-0.9.8e-12.el5_4.6

And re-install the correct version (replace the RPM with the one for your achitecture).

[root@srv  ~]# rpm -ivh openssl-0.9.8e-12.el5_4.1.x86_64.rpm
warning: openssl-0.9.8e-12.el5_4.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID e8562897
Preparing…                ########################################### [100%]
1:openssl                ########################################### [100%]

Afterwards, you’ll be able to start Plesk again.

[root@srv~]# /etc/init.d/psa start

Starting xinetd service…               done

Starting named service…             done

Starting mysqld service…           done

Plesk: Starting Mail Server… already started

Starting mail handlers tmpfs storage

Starting Plesk…                       done

For now the only workaround is to downgrade openssl, either with yum or with rpm (if yum is not configured):

# wget -c http://mirrors.kernel.org/centos/5/updates/x86_64/RPMS/{openssl-0.9.8e-12.el5_4.1.x86_64.rpm,mod_ssl-2.2.3-31.el5.centos.2.x86_64.rpm,httpd-2.2.3-31.el5.centos.2.x86_64.rpm}

# rpm -Uvh –oldpackage {openssl-0.9.8e-12.el5_4.1.x86_64.rpm,mod_ssl-2.2.3-31.el5.centos.2.x86_64.rpm,httpd-2.2.3-31.el5.centos.2.x86_64.rpm}

# /etc/init.d/sw-cp-server start

Neighbor Discovery operates in the Link Layer (Layer #2 of the OSI model) and uses ICMPv6 (the obvious IPv6 version of ICMP) to discover neighboring nodes. It will provide the translation between the IPv6 address and the Link Layer address.

ND can be used to perform …

• Address Autoconfiguration: perform stateless configuration of addresses for an interface;
• Address Resolution: Mapping from IP address to link-layer address;
• Neighbor Unreachability Detection (NUD): determine that a neighbor is no longer reachable on the link;
• Duplicate Address Detection (DAD): nodes can check whether an address is already in use;

And many more.

::/3 – Special addresses types
2000::/3 – Allocated unicast addresses
4000::/2 – FE00::/9 – Reserved unicast addresses
FE80::/10 – Link-local unicast addresses
FEC0::/10 – Site-local unicast addresses
FF00::/8 – Multicast addresses

The site-local addresses can best be compared to the IPv4 local ranges 10.0.0.0/8, 172.16.0.0./12 and 192.168.0.0/16 ranges, although they are unique to some extent.

A unicast address is used to refer to a single host. It is ment to send data to a single destination.

A multicast address can be used to deliver a package to a group of destinations. Any packet sent to a multicast address, will be delivered to every host that has joined that particular group.

Since IPv6 has no support for the broadcast address, any function that used to rely on broadcasts will now be using multicast addresses. This has the great advantage of (ab)using less traffic, as only those hosts that are interested in it, will join that particular multicast group and receive the packets. If the host hasn’t join the group, the packets will be ignored at the hardware level – not asking any resources from the OS.

Multicast addresses are in the range of FF00::/8.

The anycast address is very similar to the multicast address, but packets will be delivered to only one random host, instead of the entire group.

• 127.0.0.1 (local loopback)
• 10.0.0.1 (typical local IP address)
• 193.239.210.183 (public IP address of this blog)

IPv6 uses eight 16-bit hexadecimal values, seperated by a colon “:”.

• ::1 (local loopback)
• fec0::3010:2ffe:fe21:2640 (typical local IP address)
• 2001:db2:31:1041:204a::1337 (random public IPv6 address)

The first thing you should know, is that IPv6 addresses can be abbreviated. The local loopback address, written in the example as “::1“, is actually the shortened version of 0000:0000:0000:0000:0000:0000:0000:0001.

Leading zeros in IPv6 can usually be left out. This would shorten our local loopback address to 0:0:0:0:0:0:0:1.

To further reduce the length of the address (and add to its confusion, at first), one sequence of zeros, seperated by colons, can be removed and replaced by a double colon “::”. Since our example holds seven zero’s, it’s shortened to ::1.

For instance, the IPv6 address 2001:af40:0401:0000:0000:a401:0000:f010 can be abbreviated like this.

2001:af40:0401:0000:0000:a401:0000:f010 (full form)
2001:af40:0401::a401:0000:f010 (series of zeros replaced by ::)
2001:af40:401::a401:0:f010 (leading zeros removed)

Replacing a series of zeros, can only occur once. The following isn’t a legal IPv6 address: 2001:af1::50:1002::5, because there is no way to determine if the address should be

2001:af1:0:0:50:1002:0:5
or
2001:af1:0:50:1002:0:0:5

Since IPv6 no longer uses points to seperate values, but colons, it poses a direct problem for specifying portnumbers, as its default notation is <ip>:<port>. This can be solved by placing the IP address in between brackets, such as [::3]:8080 (which addresses the local loopback address, on port 8080). For websites that use the IP for access, this should be http://[ip-address]:port.

Won’t be very interesting if you don’t give a **** about IPv6, but you may as well be warned. ;-)