IPv6 Privacy Extensions in Fedora 20

Posted 17/02/2014 19:41

Previously I blogged about Enabling IPv6 Privacy Extensions in Fedora 18. Unfortunately in Fedora 20, the Network Manager has a bug in it that means that the setting is not used.

Thankfully there has been an issue logged already and a fixed Network Manager can be installed from the testing repo, heres how:

sudo yum update --enablerepo=updates-testing NetworkManager

Now restart, and when you run ifconfig, you should see an additional randomly generated IPv6 address.

Fedora 19 Gnome 3 OpenVPN default route bug workaround

Posted 27/10/2013 14:10

In Fedora 19 and Gnome 3 there is a rather annoying bug when using OpenVPN, the 'Use this connection only for resources on its network' tick box does not remained ticked, and causes the default route to be updated to point through the OpenVPN tunnel.

In some situations (mine) I do not want the default route to go down the OpenVPN tunnel, and so this was a problem.

Luckily there is a simple workaround until it gets fixed, open the relevant file for your VPN connection, for example /etc/NetworkManager/system-connections/Work.

Then find the section:

[ipv4]
method=auto

And add the line:

never-default=true

Hey presto, the tick box is now ticked!

Using Fail2Ban to block bruteforce Wordpress login attacks

Posted 26/10/2013 23:45

A friend of mine hosts a lot of Wordpress sites and we regularly see a lot of brute force attempts from many different IP addresses repeatedly tring to login to the admin section of the site at wp-login.php

E.g.

mysite.com mysite.com 198.27.74.223 - - [26/Oct/2013:17:42:16 +0000] "POST /wp-login.php HTTP/1.0" 200 3747 "-" "-"
mysite.com mysite.com 208.84.146.60 - - [26/Oct/2013:17:42:16 +0000] "POST /wp-login.php HTTP/1.0" 200 3747 "-" "-"

This affects the load on the web server and we start to get load alerts from the ISP that provides the server.

To try and counter this I have setup the Fail2Ban tool on the server, which automatically blocks any IP that tries to login too many times repeatedly.

Configuring Fail2Ban

First install fail2ban, for CentOS it is available in the EPEL repository.

yum install fail2ban
Next, copy the jail.conf to jail.local for editing:
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Now edit /etc/fail2ban/jail.local and add the following lines:
[apache-wp-login]

enabled = true
action   = iptables[name=wplogin, port=http, protocol=tcp]
           sendmail-whois[name=wplogin, dest=root, sender=fail2ban@example.com]
filter  = apache-wp-login
logpath = /var/log/httpd/access_log
maxretry = 5

This file tells fail2ban what to do when the filter apache-wp-login matches, it sets up an action using iptables that blocks port http (80) and sends an alert E-mail.

The maxretry line tells fail2ban to only allow 5 repeat login attempts before blocking. The default time window is 5 minutes, which is specified at the top of that file.

Next define a filter to match wp-login.php requests by creating the file /etc/fail2ban/filter.d/apache-wp-login.conf

[Definition]

# Option:  failregex
# Notes.:  Regexp to catch Apache dictionary attacks on Wordpress wp-login
# Values:  TEXT
#
failregex = [\w\.\-]+ [\w\.\-]+ .*] "POST /wp-login.php

The regex above matches a custom log format I use that shows both the requested HTTP host header and the match vhost server name fields.

Now start the service and ensure it starts on boot:

service fail2ban start
chkconfig fail2ban on

Now your server will block repeat requests for wp-login.php and E-mail you when a block occurs.

October 2013 RPM Updates

Posted 20/10/2013 21:02

Hot on the heals of the CentOS 5.10, PHP 5.4.21 and PHP 5.5.5 releases, my RPMs have now been updated as follows:

  • CentOS 5 32 bit - PHP 5.4.21
  • CentOS 5 32 bit - Apache HTTPD 2.2.25
  • CentOs 5 32 bit - Freeswitch 1.2.14
  • CentOS 6 32 bit - PHP 5.4.21
  • CentOS 6 32 bit - PHP 5.5.5

All of these RPMs are available by following these instructions.

Installing Sublime Text on Fedora 19

Posted 06/10/2013 13:44

Sublime Text is a very good, but lightweight text editor for Windows, Mac and Linux.

Unfortunately the developers do not provide packages for Fedora (or any Linux distribution) and because it is non-free it is not in the Fedora official repositories.

This is how to install it and create a launcher for Fedora 19 using Gnome3.

Getting the tarball

First download the tarball from the Sublime Text site, then unpack it into /opt/sublime.

E.g.
cd /opt
wget http://c758482.r82.cf2.rackcdn.com/Sublime%20Text%202.0.2%20x64.tar.bz2
tar jxvf Sublime\ Text\ 2.0.2\ x64.tar.bz2
mv Sublime\ Text\ 2 sublime

Creating a Launcher for Gnome 3

In order to integrate Sublime Text with the Gnome 3 Desktop Environment, create the following file:

/usr/share/applications/sublime.desktop

[Desktop Entry]
Name=Sublime
Comment=Application for editing text files
Exec=/opt/sublime/sublime_text %U
Icon=/opt/sublime/Icon/128x128/sublime_text.png
Terminal=false
Type=Application
Categories=Programming;

I have found that you need to log out of Gnome and re-login before the new desktop entry is detected, but you will then be able to see the icon in the Applications list and be able to assign it as a default application for text files.

Enabling IPv6 Privacy Extensions on Fedora 18

Posted 06/04/2013 11:20

When using IPv6 on client computers (i.e not servers) it is common to use automatic address configuration (know as SLAAC). This means you do not have to statically assign every device with an IP address.

Unfortunately the default way that many IPv6 stacks operate is to use your network card's MAC address as the basis of your global IPv6 address. This has the (sometimes) undesirable effect of giving your machine an automatically configured static IPv6 address.

This can be a privacy issue, as all IPv6 compatible sites you visit will be able to use your IPv6 address as a type of unique identifier (a bit like a cookie) to identify you as a visitor across their site, and potentially any other sites they operate.

There is mode that can be enabled on Fedora 18 to use a random IPv6 address to avoid this issue, which is known as RFC3041.

To enable this on your network card in Fedora 18, modify the following file:

/etc/sysconfig/network-scripts/ifcfg-p1p1

Add the line:

IPV6_PRIVACY=rfc3041

Then disable your network interface and re-enable. You can test whether your IPv6 address is random by visiting ipv6.nl.

Problems with CentOS 5.9, Postfix and MySQL

Posted 26/02/2013 23:09

The latest version of CentOS, 5.9, has updated their Postfix (an SMTP mail server) package to require mysql because it now supports reading user and domain lists from a MySQL database.

Unfortunately this has caused issues with anyone using the Oracle or MariaDB MySQL distributions.

Update 2013-02-27

The folks over at RedHat have fixed the bug I logged within 1 day!

There is a new postfix RPM available that removes the dependency of "mysql", and instead only requires "libmysqlclient.so.15", which is satisfied by either MySQL-shared-compat or MariaDB-compat. Open Source for the win.

Its all about Requires

Software for any RedHat based operating system is packaged using an RPM (RedHat Package Manager) file. These files describe what features the software requires and provides to the system, along with what files it contains.

The postfix package in CentOS 5.9 requires the "mysql" package.

The "mysql" package in CentOS 5.9 provides the MySQL 5.0 client utility for accessing MySQL servers.

The problems arise when trying to use either Oracle's MySQL or MariaDB packages.

The latest version of Oracle's MySQL 5.5 series is 5.5.30. None of its packages now claim to provide "mysql", which means when installing Postfix these packages will not be installed. Instead the vanilla mysql client package will be installed.

Unfortunately when you try to install the MySQL-client package from Oracle, it will conflict, because both the "mysql" and "MySQL-client" packages try to manage the same files, e.g. /usr/bin/mysql.

For the MariaDB packages, the current stable version is 5.5.29. The MariaDB-server package claims to provide "mysql", so when installing postfix, yum will try and install MariaDB-server.

This works fine, but seeing as most servers should have some sort of MTA installed (for sending cron emails for example) and only database servers need MySQL-server install, it seems silly to go installing MariaDB-server on every server.

This means we are now in a rather awkward situation:

  • Oracle's MySQL client cannot be installed on a server running postfix
  • MariaDB's MySQL server must be installed on a server running postfix

A twist in the tale

It turns out that postfix doesn't actually require "mysql" at all. It requires the MySQL libraries so that it can communicate with a MySQL server, it doesn't need the command line client utility.

It seems the people who package postfix for CentOS 6 (and Fedora) realize this, and their packages do not require "mysql", but instead require only "mysql-libs".

The effect of this small change is to allow either MariaDB or Oracle's packages to be installed cleanly, as yum will pull in MariaDB-compat or MySQL-shared-compat respectively.

I do not know why the CentOS 5.9 package of postfix has this difference in requirements.

A solution, of sorts

A short term solution is to grab the postfix SRPM from a CentOS mirror, edit the RPM SPEC file to disable the requirement for mysql and increment its build version. Then rebuild it and put that in your own YUM repository. This will allow you to install the updated postfix without any MySQL dependencies.

A proper solution

As it stands currently Oracle's MySQL-client package is not installable on CentOS/RHEL 5.9 running postfix. These packages are specifically marketed as compatible with this OS, so for them to be incompatible is a big problem.

The upstream resolutions as I see them are:

  • Oracle and MariaDB to modify their client RHEL/CentOS packages to provide "mysql" - This will ensure compatibility with any other packages that require "mysql"
  • CentOS/RHEL update their postfix package to require "mysql-libs" rather than "mysql"

Installing Steam on Fedora 18

Posted 19/02/2013 20:34

The good folks over at Valve have recently launched their Steam client for Linux and ported some of their games to run on Linux.

Unfortunately the officially supported client only runs on Ubuntu, however Fedora People have kindly re-packaged it into an RPM suitable for running on Fedora 18.

Installing Steam

To install steam on Fedora run the following commands:

su
cd /etc/yum.repos.d/
wget http://spot.fedorapeople.org/steam/steam.repo
yum install steam

Installing 32bit textures

You can then start Steam using the normal application starter. However to run games there is also a need to install a texture package that is not installed automatically. Please note that even if you are running 64bit Fedora you should install the 32bit package as the games are compiled to use the 32bit textures.

yum install libtxc_dxtn.i686

That's all there is to it. Enjoy Linux gaming!

TCP PAWS extension breaks RIPE WHOIS lookups when behind NAT

Posted 12/03/2012 22:51

Background Info

For the last few weeks I have been encountering a strange problem with making IP WHOIS queries against the RIPE database, which covers all European IPs.

I first encountered the problem during a routine server upgrade and reboot. Suddenly some of our software that we run on these servers started producing errors saying that WHOIS lookups could not be performed.

After some investigation it transpired that it was only IP WHOIS lookups against the RIPE database that were failing. What is more, it was only happening on a couple of our servers, even though they all sat behind the same shared firewall and are Source NATed to the same public IP.

As time went by I upgraded more servers, and each time the newly upgraded server also started exhibiting the behaivour. Naturally my first thought was that something in the kernel upgrades that had warranted the reboot were to blame.

I began to downgrade some of the servers to their previous kernel versions, but this did not fix the issue. Stranger still some of the servers running the new kernels started working again, but intermittently!

Break out TCPDUMP

To try and understand what was going on I started running tcpdump on the firewall server to try and see the difference between a working server and a non-working server.

The results of a working server looked like this:
13:14:24.291132 IP x.x.x.x.40474 > 193.0.6.135.43: S 1723346221:1723346221(0) 
win 5840 mss 1460,sackOK,timestamp 3097608306 0,nop,wscale 4
The results of a non-working server looked like this:
12:58:26.886531 IP x.x.x.x.47159 > 193.0.6.135.43: S 9443771:9443771(0) 
win 5840 mss 1460,sackOK,timestamp 2068177 0,nop,wscale 4

Initially, the the packets looked the same with nothing obviously wrong.

The only thing that was different was that the timestamp of the newly rebooted non-working server packet was much lower than the server that had been running for months and was able to perform WHOIS lookups fine.

Surely this is perfectly acceptable, even behind NAT, because TCP connections use packet sequence numbers, not timestamps to order packets? If this wasn't the case, surely NAT would break things all the time?

As it turns out (after much searching) there is an extension to TCP called PAWS (Protect Against Wrapped Sequences) that is designed to prevent older packets from the same connection interfering with current TCP communication when using high bandwidth and high latency links.

Unfortunately it seems that the RIPE network has PAWS enabled, and it seems when making WHOIS requests from multiple servers behind the same public IP causes packets to be dropped because they have the conflicting combinations of timestamp and sequence numbers.

The Resolution

The resolution to this problem turned out to be very simple, disable TCP timestamps in our outgoing packets.

sysctl net.ipv4.tcp_timestamps=0

This means that PAWS cannot operate, and then immediately all the servers were able to perform WHOIS lookups with no problems.

Interestingly, enabling PAWS on your network can potentially introduce a DOS attack vector, by the attacker forging a packet to set a host's timestamp artificially high, and preventing future genuine communication.

Freeswitch Text-To-Speech Caching with Cepstral and LUA

Posted 13/11/2011 15:05

Recently I have been working on a project using software called Freeswitch, which is an excellent open source SIP server.

The project required the use of a text-to-speech (TTS) speech engine called Cepstral.

However Cepstral's product suffers with concurrency problems when used with many concurrent phone calls. Additionally there is about a 1 second delay before TTS audio actually starts to play, which can be off-putting for the callers.

To overcome these issues I have implemented a caching mechanism using Freeswitch's built in integration with the LUA scripting language.

Our system tends to 'say' the same things over and over again, so by caching the TTS output to a wav file this allowed Freeswitch to just play back the sound file, rather than generate the same audio over and over again.

The TTS Cache Script

The script below should be installed into the scripts directory in Freeswitch, commonly /opt/freeswitch/scripts/tts_cache.lua.

-- This script generates a wav file of the sentence passed in to it.
-- It uses the Cepstral swift command to perform text-to-speech conversion.
-- If the wav file already exists for this sentence, then it is not
generated.
api         = freeswitch.API();
msg         = argv[1];
msgMd5      = api:execute( "md5", msg );
filename    = '/var/lib/tts_cache/' .. msgMd5 .. '.wav';
cmd         = '/opt/swift/bin/swift';

-- Set a channel variable so that we know which file to play back.
session:setVariable( 'tts_file', filename );

-- Check whether the file already exists.
file, errMsg = io.open( filename, "r" )
if not file then
api:execute( 'system', cmd .. ' -o "' .. filename .. '" "' .. msg .. '"' );
end

Using The TTS Cache Script

To use the script, first create a directory to save the cache files in and ensure Freeswitch can write to it:

mkdir /var/lib/tts_cache
chown freeswitch /var/lib/tts_cache

Next, create a phrase macro to allow you use it within a dial plan or IVR setting, commonly this goes in /opt/freeswitch/conf/lang/en/ivr/tts_cache.xml:

<include>
  <!--Provides a phase to speak custom text-->
  <macro name="tts_cache">
    <input pattern="(.*)">
      <match>
        <action function="execute" data="lua(tts_cache.lua '$1')"/>
        <action function="play-file" data="${tts_file}" />
      </match>
    </input>
  </macro>
</include>

Finally, in your dial plan you can use this script as so:

<action name="phrase" data="tts_cache,Hello World" />

Now the first time the phrase "Hello World" is requested, it is passed into the Cepstral swift command, which generates a wav file, and then when ever the same phrase "Hello World" is requested in the future, Freeswitch will just playback the wav file, which is much quicker.