Openstack - List of ports which must be opened in the firewall

I must confess that when testing new Openstack releases on a variety of different Linux distros (RHEL, Fedora, Ubuntu) I often disable the firewall in the interests of expediency. While this might be OK for internal testing in a lab environment or while preparing a Proof of Concept (PoC) for a client, this is definitely a bad habit that is unacceptable for a production environment.

I recently did a Devstack install on Ubuntu 15.10 to test upstream Openstack compatibility with the Sheepdog distributed storage backend. This time I left the firewall running (ufw, aka uncomplicated firewall for Ubuntu) and opened the ports necessary for Openstack to run.

Before I present the list of ports which must be opened, note that you can find all these port numbers in the conf files for Glance, Cinder, Nova, Keystone, etc. in /etc/glance/glance-api.conf, /etc/nova/nova.conf, /etc/cinder/cinder.conf, and so on.

In the conf files, many ports will be commented out. For example, it is possible to connect Nova Compute with Amazon EC2 so it can launch instances from AWS. To do so, you would have to open TCP port 8773 in your firewall on your compute node, but this is commented out by default in nova.conf.

Here is the list of ports I have compiled. All ports are TCP unless specified otherwise:

AMQP/RabbitMQ: 5672 (5671 if rabbitmq uses SSL auth)
Ceilometer: 8777
Ceilometer: udp_port=4952
Cinder: sheepdog_store_port=7000
Cinder: 8776
Glance: 9292
Glance glance-api.conf: registry_port=9191
Neutron: 9696
Nova novncproxy: 6080
Nova ec2_port: 8773 (commented out by default)
Nova metadata: 8775 (commented out by default)
Nova iSCSI target: 3260 (commented out by default)
Nova nova.virt.xenapi.image.bittorrent: 6881~6891 (commented out by default)
Nova redis host: 6379 (commented out by default)
Neutron ovs_neutron_plugin.ini: vxlan_udp_port=4789
Nova s3_port=3333 (commented out by default)
...
(there are more, but those ports are optional)

I have written a simple bash script that can be used to open the necessary ports in ufw. You can find the script at the following URL:

https://gitlab.com/gojun077/openstack-conf/blob/master/ufw_openstack.sh

#!/bin/bash
# ufw_openstack.sh
# Created by Jun Go gojun077@gmail.com
# Last Updated 2016-05-25

# Script that will open ports needed by Openstack in
# UFW Firewall

# This script should be run as root

#################
#   TCP PORTS
#################
AMQP=5672
CEILOM=8777
CINDER=8776
GLANCE=9292
GLANCEREG=9191
NEUTRON=9696
NOVNCPROX=6080
#NOVAEC2=8773
#NOVAMETA=8775
#NOVAISCSI=3260
#NOVAREDIS=6379
#NOVAS3=3333
SHEEPDOG=7000

#################
#   UDP PORTS
#################
CEILUDP=4952
OVSNEUTRONVXLAN=4789

TCPPORTS=($AMQP
   $CEILOM
   $CINDER
   $GLANCE
   $GLANCEREG
   $NEUTRON
   $NOVNCPROX
   $SHEEPDOG
  )

UDPPORTS=($CEILUDP
   $OVSNEUTRONVXLAN
   )

for i in ${TCPPORTS[*]}; do
  ufw allow "$i"/tcp
done

for j in ${UDPPORTS[*]}; do
  ufw allow "$j"/udp
done

# List Open Ports
ufw status

Enabling Port Forwarding with UFW on Ubuntu

Several months ago, I described how to enable port forwarding with the dynamic firewall firewalld in a post titled Internet connection sharing through a computer with two NIC's. Today I will describe how to achieve the same thing in Ubuntu 15.10 using uncomplicated firewall, ufw, a front-end to iptables.

Keep in mind that the method I am describing requires two NIC's on the machine that will be forwarding packets from the internal to the external network.

1. Make sure ip forwarding is enabled in the Kernel

On most linux distros this has historically been set in /etc/sysctl.conf but in recent years with the rise of systemd, the actual setting net.ipv4.ip_forward=1 might be found in a rules file under /usr/lib/sysctl.d/ or /etc/sysctl.d/ ; in the case of Ubuntu running ufw, however, the ip forwarding setting shown above should be made in /etc/ufw/sysctl.conf

2. Edit /etc/ufw/before.rules

Make sure that NAT is enabled with the following setting:

# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]

And then enable the forwarding of packets from your internal network subnet (mine is 192.168.95.0/24) to the external network interface (enp3s5f0 in my case):

-A POSTROUTING -s 192.168.95.0/24 -o enp3s5f0 -j MASQUERADE

-A is for append rule
-s specifies the source address
-o indicates the output (egress) interface

The internal network at work is on the 192.168.95.X subnet (iface enp5s0), while the external subnet is on 192.168.30.X (iface enp3s5f0).

To apply the changes, sudo ufw disable && sudo ufw enable


Notes

For some reason after applying the changes, pinging the Ubuntu 15.10 server worked, but ssh was blocked by ufw. I thus had to manually add ssh to the ufw firewall with the following command:

sudo ufw enable ssh

It is also possible to enable port forwarding using native iptables commands:

iptables -A FORWARD -i enp5s0 -j ACCEPT
iptables -A FORWARD -o enp3s5f0 -j ACCEPT
iptables -t nat -A POSTROUTING -o enp3s5f0 -j MASQUERADE

But I didn't actually try this method, so it may or may not work on your machine.

References:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Security_Guide/s1-firewall-ipt-fwd.html

https://gist.github.com/kimus/9315140

Unable to reload rules in firewalld 0.3.14.2-1 Archlinux (workaround: restart firewalld.service)

firewalld is an upstream dynamic firewall project from Fedora. Personally, I find working with firewalld to be much more pleasant than trying to decipher and write arcane iptables static firewall rules.

Although Archlinux is generally a cutting-edge Linux distro that gives users access to the newest packages from upstream and the newest kernels, in my humble opinion it lags behind Fedora/RHEL/CentOS in the security department. SELinux and firewalld are setup by default in Fedora et al, but in Archlinux only firewalld is available from the default repositories. As of June 2015, SELinux can be installed on Arch, but SELinux policies have not been customized for Archlinux (i.e. the default policies assume Fedora/RHEL paths and filenames).

A test machine running Arch and firewalld also happened to be an NFS server, but NFS clients could no longer connect to the server because of the firewall. Since I only use NFS within my LAN, I assigned the Ethernet port enp1s0 to the firewalld internal zone and then added NFS-related services to internal as follows:

$ sudo firewall-cmd --zone=internal --change-interface=enp1s0
[sudo] password for archjun: 
success
$ sudo firewall-cmd --permanent --zone=internal --add-service=nfs
success
$ sudo firewall-cmd --permanent --zone=internal --add-service=rpc-bind
success
$ sudo firewall-cmd --permanent --zone=internal --add-service=mountd

Now to apply this to firewalld, we need to reload the firewall rules:

$ sudo firewall-cmd --reload
Error: 'NoneType' object has no attribute 'query_rule'

I verified that the services I added above (nfs, rpc-bind, and mountd) were not yet reflected in firewalld:

$ firewall-cmd --zone=internal --list-all
internal (active)
  interfaces: enp1s0
  sources: 
  services: dhcpv6-client mdns samba-client ssh
  ports: 
  masquerade: no
  forward-ports: 
  icmp-blocks: 
  rich rules:

I looked for any firewalld-related errors in the systemd journal journalctl, but found nothing of interest.

Googling for the error above did not turn up any relevant results. I also tried to use the firewalld GUI, firewall-config, and clicked the checkbox for each service to whitelist in Zone internal :

Changing Runtime rules only works for the current session, but you can also define Permanent rules, too. I assumed that changing Runtime rules in the GUI would be immediately applied, but this was not the case; I am not sure if this is a problem with firewall-config in Archlinux or a lack of understanding on my part. When I clicked Options -> Reload Firewalld, I got the exact same error that firewalld-cmd gave me:

'NoneType' object has no attribute 'query_rule'

As a last resort, I invoked

$ sudo systemctl restart firewalld

After restarting systemd's firewalld.service, you can see that the permanent rule changes I made to the internal zone with firewall-cmd finally appear:

$ firewall-cmd --zone=internal --list-all
internal (active)
  interfaces: enp1s0
  sources: 
  services: dhcpv6-client mdns mountd nfs rpc-bind rsyncd samba-client ssh
  ports: 
  masquerade: no
  forward-ports: 
  icmp-blocks: 
  rich rules:

*Note: although firewalld calls "rpcbind" rpc-bind, the name of the systemd service is rpcbind.service, not rpc-bind.service.


Update 2015-07-10

On another Archlinux machine using the Openbox Desktop Environment, reloading firewalld rules with firewall-cmd --reload works just fine. The problem I have described in this post occurred on an Archlinux machine using the LXDE desktop environment. Perhaps the problems I experienced are somehow related to LXDE?

References:

https://fedoraproject.org/wiki/User:Renich/HowTo/NFSv4 (with firewalld)

https://fedoraproject.org/wiki/FirewallD#Using_firewall-cmd

Setting up fail2ban on CentOS 7 with firewalld on a Digital Ocean droplet

When running a server in the cloud, it is a good idea to at least secure SSH so that brute forcing attempts will automatically be blocked after a set number of incorrect tries. Having set up fail2ban with firewalld in Archlinux on a laptop, I figured the process would be pretty much the same for CentOS 7 in a Digital Ocean droplet.

As soon as you login into your new Droplet, I recommend that you follow the steps in this DO article about creating a regular user account, enabling sudo, disabling root logins over SSH, etc. You should also read the follow-up article about how to set up firewalld in CentOS 7 (TL;DR sudo systemctl enable firewalld, sudo systemctl start firewalld)

Now you need to install fail2ban. Although it is not in the default CentOS yum repositories, it is available through EPEL which is included in the CentOS Extras repository (which is enabled by default).

sudo yum install epel-release

Starting from RHEL/CentOS 7, iptables and rsyslog have been replaced with firewalld and journalctl (part of systemd), so you must be sure to yum install the following packages:

fail2ban-systemd (to ensure journalctl compatibility)
fail2ban-firewalld
ipset (to ban IP's with firewalld)
fail2ban-server

Now cd into /etc/fail2ban where you will see the systemwide fail2ban config file jail.conf which you can use as a reference but should not edit directly. Instead, in the subdir /etc/fail2ban/jail.d/ you should make your own config file ending with the .conf extension (I named mine local.conf). You will also notice that in this sub-directory there will be two other .conf files named 00-firewalld.conf and 00-systemd.conf which contain the following:

[centjun@juncent7 jail.d]$ cat 00-firewalld.conf 
# This file is part of the fail2ban-firewalld package to configure the use of
# the firewalld actions as the default actions.  You can remove this package
# (along with the empty fail2ban meta-package) if you do not use firewalld
[DEFAULT]
banaction = firewallcmd-ipset

[centjun@juncent7 jail.d]$ cat 00-systemd.conf 
# This file is part of the fail2ban-systemd package to configure the use of
# the systemd journal as the default backend.  You can remove this package
# (along with the empty fail2ban meta-package) if you do not want to use the
# journal backend
[DEFAULT]
backend=systemd

In Archlinux, these config files are not included in the jail.d subdir, so I had to add banaction=... and backend=... in local.conf (in the case of Archlinux, not CentOS7).

The /etc/fail2ban/jail.d/local.conf which I used in Archlinux is as follows:

[DEFAULT]
bantime = 18000
banaction = firewallcmd-ipset
backend = systemd
sender = fail2ban@example.com
destemail = root
ignoreip = 127.0.0.1 192.168.0.0/16
use_dns = no
maxretry = 21

action = %(action_mwl)s

[sshd]
enabled = true

However when I used the settings above in CentOS 7 and then tried to start the fail2ban systemd service with sudo systemctl start fail2ban I got the following errors in journalctl:

Jul 04 14:36:19 juncent7 fail2ban-client[1674]: ERROR  Found no accessible config files for 'action.d/sendmail-whois-lines' under /e...ail2ban
Jul 04 14:36:19 juncent7 fail2ban-client[1674]: ERROR  Error in action definition sendmail-whois-lines[name=sshd, dest="centjun", lo...INPUT"]
Jul 04 14:36:19 juncent7 fail2ban-client[1674]: ERROR  Errors in jail 'sshd'. Skipping...

Since fail2ban uses sendmail as its default mta, I checked to see if sendmail was installed:

[centjun@juncent7 jail.d]$ rpm -q sendmail
package sendmail is not installed

Instead, I found that postfix was installed, so I then added mta = postfix to local.conf, but still got similar errors:

Jul 04 14:45:13 juncent7 fail2ban-client[1715]: ERROR  Found no accessible config files for 'action.d/postfix-whois-lines' under /etc/fail2ban
Jul 04 14:45:13 juncent7 fail2ban-client[1715]: ERROR  Error in action definition postfix-whois-lines[name=sshd, dest="centjun", log...INPUT"]
Jul 04 14:45:13 juncent7 fail2ban-client[1715]: ERROR  Errors in jail 'sshd'. Skipping...

I checked /etc/fail2ban/action.d/ for the files postfix-whois-lines and sendmail-whois-lines but both of the them were nowhere to be found.

Finally I edited the default action in local.conf to just ban the offending IP instead of sending a mail to root:

action = $(action_)s

Now when starting fail2ban.service with systemctl start fail2ban, everything works fine:

[centjun@juncent7 jail.d]$ systemctl status fail2ban
fail2ban.service - Fail2Ban Service
   Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled)
   Active: active (running) since Sat 2015-07-04 15:08:04 SGT; 44min ago
     Docs: man:fail2ban(1)
  Process: 1803 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=0/SUCCESS)
 Main PID: 1806 (fail2ban-server)
   CGroup: /system.slice/fail2ban.service
           └─1806 /usr/bin/python -Es /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b

[centjun@juncent7 jail.d]$ sudo fail2ban-client status
[sudo] password for centjun:
Status
|- Number of jail:      1
`- Jail list:   sshd

Just in case you think it is too much hassle to do minimal server hardening, take a look at just a few of the dozens of unauthorized login attempts recorded by PAM in journalctl:

Jul 04 15:21:42 juncent7 sshd[1828]: reverse mapping checking getaddrinfo for 107.30.65.218.broad.xy.jx.dynamic.163data.com.cn [218...ATTEMPT!
Jul 04 15:21:43 juncent7 sshd[1828]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.65...ser=root
Jul 04 15:21:43 juncent7 sshd[1828]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Jul 04 15:21:45 juncent7 sshd[1828]: Failed password for root from 218.65.30.107 port 57804 ssh2
Jul 04 15:21:45 juncent7 sshd[1828]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Jul 04 15:21:47 juncent7 sshd[1828]: Failed password for root from 218.65.30.107 port 57804 ssh2
Jul 04 15:21:49 juncent7 sshd[1828]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Jul 04 15:21:51 juncent7 sshd[1828]: Failed password for root from 218.65.30.107 port 57804 ssh2
Jul 04 15:21:54 juncent7 sshd[1828]: Received disconnect from 218.65.30.107: 11:  [preauth]
Jul 04 15:21:54 juncent7 sshd[1828]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.65.30.107  user=root
Jul 04 15:21:55 juncent7 sshd[1830]: reverse mapping checking getaddrinfo for 107.30.65.218.broad.xy.jx.dynamic.163data.com.cn [218...ATTEMPT!
Jul 04 15:21:55 juncent7 sshd[1830]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.65...ser=root
Jul 04 15:21:55 juncent7 sshd[1830]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Jul 04 15:21:58 juncent7 sshd[1830]: Failed password for root from 218.65.30.107 port 53038 ssh2
Jul 04 15:22:03 juncent7 sshd[1830]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Jul 04 15:22:04 juncent7 sshd[1830]: Failed password for root from 218.65.30.107 port 53038 ssh2
Jul 04 15:22:05 juncent7 sshd[1830]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Jul 04 15:22:06 juncent7 sshd[1830]: Failed password for root from 218.65.30.107 port 53038 ssh2
Jul 04 15:22:07 juncent7 sshd[1830]: Received disconnect from 218.65.30.107: 11:  [preauth]
...

When I switched to root user PAM informed me of a large number of failed login attempts on the root account:

[centjun@juncent7 jail.d]$ su -
Password:
Last login: Fri Jul  3 23:08:03 SGT 2015 from xxx.xxx.xxx.xxx (redacted) on pts/0
Last failed login: Sat Jul  4 15:22:42 SGT 2015 from 218.65.30.107 on ssh:notty
There were 65 failed login attempts since the last successful login.

This large number of unsuccessful logins occurred within just 1 hour of launching my new droplet!

When I ran a reverse DNS on one of the IP's associated with a failed login, it appeared to be an address from China.


Comments on certain settings in /etc/fail2ban/jail.d/local.conf

ignoreip = 

It is a good idea to put your remote IP (the IP of the computer you are connecting from) into ignoreip above (multiple IP's can be entered in the whitelist, separated with spaces) to avoid getting locked out of your cloud server by an attacker sending packets with a spoofed source header (of course the attacker would have to know your remote IP address).

use_dns = no

It is safer not to use dns to ban hostnames because an attacker can change the PTR of an IP that they control to point to another hostname that could make fail2ban to mistakenly ban valid domains (http://www.fail2ban.org/wiki/index.php/Hostnames_or_IP_Addresses).


Thoughts about Digital Ocean Droplets

I was pleasantly surprised with my first experience using Digital Ocean (DO) cloud instances. The only other cloud server I have used is AWS EC2 (free usage tier) and I think DO compares favorably. Although DO is missing the "enterprisey" features of AWS, I think DO is much easier to use and better-suited for quickly spinning up a server instance in the cloud. Whereas AWS micro instances only give you 8GB of storage and 1 CPU, DO's smallest instance gives you 1 CPU with 30 GB of SSD!

For me, DO's killer feature is the ability to take a snapshot of an instance (once you have shut it down), delete the Droplet, and then later create a new Droplet from the snapshot you created earlier. The reason this is so awesome is that DO snapshots are free (unlike those on AWS EC2, which take up gigabytes of Elastic Storage) and allow you to use cloud instances on an hourly basis if you are so inclined. Here are some good forum posts about using DO on an hourly basis:

https://www.digitalocean.com/community/questions/pricing-monthly-or-hourly

https://www.digitalocean.com/community/questions/restore-snapshot-after-destroying-a-droplet

On AWS EC2, however, snapshots are destroyed along with an image, so you couldn't easily replicate this DO feature over there.

References:

https://fedoraproject.org/wiki/Fail2ban_with_FirewallD
Fedora wiki about setting up fail2ban with firewalld; also explains the meaning of variables in fail2ban config files

https://wiki.gentoo.org/wiki/Fail2ban#Actions
Gentoo wiki about fail2ban

Some observations about glibc GHOST vulnerability patching in the field

I currently work as a Linux System Engineer for an open source software service company that provides manpower for various Managed Service Providers (MSP) serving the Korean telecom industry. I spend most of my days out of the office on service calls ranging from basic server installation, system monitoring, to troubleshooting. In the normal course of my work I come into contact with sysadmins with varying levels of Linux familiarity. About 50% of the time the sysadmins I meet are more familiar with Windows or various flavors of Unix like HPUX, AIX, Solaris, etc. Of course, there are some sysadmins who are quite adept at Linux, too.

Thanks to an itinerant work arrangement in which I visit different sites every day, I have some perspective on the diverse ways that IT staff maintain their Linux servers. 2014 and early 2015 have been a busy time for patching servers with bugs found in Bash, OpenSSL and glibc. Although the glibc GHOST vulnerability was announced in Jan 2015, some of our clients still haven't completed patching all of their servers. Several sysadmins have asked me about the proper rpm commands for upgrading glibc-related packages on RHEL or CentOS. I was a bit worried when they said they used commands like

rpm -Uvh --nodeps pkgName

rpm -i --force --nodeps pkgName

as hacky workarounds for dependency errors that popped up when they tried to update glibc.

For the record, at my employer Growin, we recommend the following steps for upgrading glibc.

1) First identify relevant glibc packages installed on your RHEL/CentOS system

rpm -qa | grep -E "glibc|nscd" | grep -v "compat"

This will return a list of glibc-related packages on your system with the exclusion of compat- packages which don't need to be upgraded. For why compat-glibc doesn't need to be patched, see the Redhat Solutions post Is compat-glibc affected by GHOST, glibc vulnerability CVE-2015-0235? (login required). I quote,

The dynamic libraries provided by the compat-glibc package are not vulnerable because they do not provide runtime code...

2) Although there are more than 16 packages related to glibc that you could install, most probably you don't have glibc-debug* or the glibc-utils packages installed on your system. If these packages did not appear in the results from step 1, do not try to install them (doing so can lead to dependency errors)! Prepare only the updated rpm's that you need for an upgrade in a separate directory and then

rpm -Uvh glibc*

should do the trick. If your system has nscd installed, the above command would become:

rpm -Uvh glibc* nscd*


It is also possible to skip step 1 if you use the rpm -F flag (--freshen), which, according to man rpm:

will upgrade packages, but only ones for which an earlier version is installed

Desktop Linux users of Fedora, CentOS, or other rpm-based distros might wonder why sysadmins go to all the trouble of manually upgrading packages using rpm -Uvh pkgName when they could just do a yum update and upgrade all packages at one go.

There are several good reasons for not using yum update in an enterprise environment. First, some servers are only connected to an internal network. Second, custom applications created by developers may be compiled against a certain version of the C libraries in glibc, so doing a yum update runs the risk of breaking applications. Mainly for the second reason, it is not uncommon to see production servers running really old kernels like 2.6.18 (RHEL 5.X), and I have heard horror stories from coworkers about companies that use even older kernels!

glibc patch for non-LTS Ubuntu 12.10

A few weeks ago when the glibc 'ghost' vulnerability was announced, sysadmins and system engineers the world over frantically began patching systems. Although most of the servers my company manages have been patched by now, I got a weird request from a client - they have an old development machine still running Ubuntu 12.10 Quantal Quetzal, a non-LTS release that went out of support in 2014. The Ubuntu security advisory for glibc (known as eglibc in Ubuntu provided by package libc6) indicates that patches are available for 12.04 and 10.04, but 12.10 is left out in the cold.

Taking a look at the packages depending on libc6 in Ubuntu 12.04 reveals 19 packages including libc6 itself:

libc6 (mandatory)
libc-bin (mandatory)
libc6-i386
libc6-dbg
libc6-dev
libc6-dev-i386
linux-libc-dev (req'd by libc6-dev, libc6-dev-i386)
libc-dev-bin
libc6-pic
libc6-prof
glibc-doc
nscd

libc6-amd64 (i386)
libc6-dev-amd64 (i386)
libc6-xen (i386)
libnss-files-udeb (debian installer build only!)
libnss-dns-udeb (debian installer build only!)
libc6-udeb (debian installer build only!)
multiarch-support (dummy pkg)

All of the above packages must be upgraded to version 2.15-0ubuntu10.10 or above for Ubuntu 12.04!

Since my client is running 12.10 64-bit on x86 hardware, however, packages for the i386 architecture (indicated in red) can be ignored. The libc6-i386 and libc6-dev-i386 packages cannot be ignored, however, as they are multiarch 32-bit glibc packages for 64-bit Ubuntu. Also the debian installer build packages with the '-udeb' suffix and the dummy package can be ignored as well.

To check the current eglibc version in use by 12.10 Quantal Quetzal, run the following from the commandline:

$ ldd -version
Ubuntu eglibc 2.15-0ubuntu-20

Hmm... the unpatched version of eglibc in Ubuntu 12.10 is nominally higher than that of the patched version (2.15-0ubuntu10.10) in Ubuntu 12.04. But the higher version doesn't mean we are safe because the Quantal Quetzal packages don't receive updates!

One solution is to manually downgrade all the 12.10 eglibc packages to patched 12.04 versions.

First we need to find which glibc/eglibc packages are currently installed on the Ubuntu 12.10 machine, because during the patch we don't want to install any unnecessary packages.

Enter the following bash for-loop on the command-line:

for i in {libc6,libc-bin,libc-dev,libc-i386,glibc-doc,nscd}; do
  dpkg -l | grep $i
done

Installed packages matching from the list will be displayed one to a line. Here's what I get when I run the above command on a minimal 12.10 install:

ii  libc6:amd64                        2.15-0ubuntu20             amd64        Embedded GNU C Library: Shared libraries
ii  libc-bin                           2.15-0ubuntu20             amd64        Embedded GNU C Library: Binaries


Only two glibc-related packages are installed but on a development machine it would not be surprising for more packages to be returned.

Updated 12.04 LTS packages can still be downloaded from the web (which is unfortunately no longer the case for 12.10, as it is no longer supported). At the following link you can download the latest libc6 for 12.04:

http://packages.ubuntu.com/precise/amd64/libc6

And from packages.ubuntu.com you can also search for the other packages you need (listed in the security advisory link presented earlier).

OK- so now you have downloaded all the packages you need to some directory on your 12.10 box. Now it's time to "downgrade" your 12.10 libc6-related packages to those from 12.04:

Assuming all the downloaded .deb files for downgrade exist in the same folder, you can run the following:

$ sudo dpkg –i *.deb
dpkg: warning: downgrading libc6:amd64 from 2.15-0ubuntu20 to 2.15-ubuntu10.11
...
Although you are downgrading the packages, you are downgrading to patched versions from 12.04 LTS.

Now if you reboot and run ldd -version, you will see that your system is now running the patched version of eglibc:

$ ldd –version
ldd (Ubuntu EGLIBC 2.15-0ubuntu10.11) 2.15


A Note about enabling apt-get for unsupported Ubuntu versions

If you try to run sudo apt-get install foo in Ubuntu 12.10 you will get a message that this version is no longer supported. But what if you want to upgrade to 13.04 and from there to 14.04 LTS? Or what if you plan to stay at 12.10 but just want to download additional packages from that version?

First of all, you need to edit your /etc/apt/sources.list file and change the URL for the package repository from us.archive.ubuntu.com to old-releases.ubuntu.com

Sure, you could do this manually, copy-pasting multiple times, but I suggest you use vi's global find-replace for this task: Enter the following in the vi buffer while editing sources.list:

:%s:us-archive.ubuntu.com:old-releases.ubuntu.com:g

where s means substitution
g means global replace
instead of / as a field delimiter, I have chosen to use :

Now apply changes to sources.list:

sudo apt-get update

You will find that you can now use apt-get to install packages from 12.10 or even upgrade the distro to supported (and patched) versions of Ubuntu.

As of Jun 19, 2014 Project Euler site is down :(

When I visited Project Euler on Thursday, I got the following page:

Apparently the site operators suspect their database was hacked. I hope they come back soon!

Update 2014-06-22: The site is back up, but logins are disabled and Project Euler banners listing how many problems a user has solved are no longer provided.