- Generate a key (interactive mode):
gpg --gen-key
- You can use the key generator in an unattended mode. Values in the example below are the same as the defaults proposed in the interactive mode above. Parameters in comments are there for reference:
gpg --gen-key --batch <<EOF Key-Type: RSA Key-Length: 2048 Subkey-Type: RSA Subkey-Length: 2048 Expire-Date: 0 Name-Real: Kevin # Name-Email: kevin@deldycke.com # Name-Comment: My auto-generated key # Passphrase: my_secret_passphrase EOF
- List available keys for the current user:
gpg --list-keys
- Decrypt a file:
gpg --decrypt archive.001.tar.gpg --output archive.001.tar
- Same as above but for a collection of files:
gpg --multifile --decrypt archive.*.tar.gpg
Tag Archives: security
Better Entropy on a Debian Squeeze server
While generating a GPG key on my server, I got the following error:
Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 283 more bytes)
That’s a well known issue on headless servers. Thanks to a comment on Hacker News, I knew there was a way to fix this thanks to software entropy generator, like the havege deamon.
My server is running Debian Squeeze. Luckily, a package is available in the backport repository. All we have to do is to add the latter in our source list before installing haveged:
$ echo 'deb http://backports.debian.org/debian-backports squeeze-backports main' > /etc/apt/sources.list.d/squeeze-backports.list $ apt-get update $ apt-get -t squeeze-backports install haveged
Now you can get a proof that haveged is running by monitoring your entropy. Here is for example the Munin graph of my server, on which you can clearly see the big jump in available entropy:

If I’m not sure about the quality of the randomness it generate on virtual machines, haveged is still a really practical solution for lack of entropy on a server.
Configuring Fail2Ban on Debian Squeeze
This always start with a package installation:
$ aptitude install fail2ban
Then I simply create a local configuration file where I’ll put all my custom config:
$ touch /etc/fail2ban/jail.local
Here is the content of that file:
[DEFAULT] # Do not filter connexion from my apartment and from the server itself ignoreip = 127.0.0.1 88.123.123.123 91.123.123.123 # Ban for a week bantime = 604800 maxretry = 3 destemail = kevin@deldycke.com banaction = iptables-allports action = %(action_mwl)s [ssh] enabled = true port = 22 maxretry = 2 [ssh-ddos] enabled = true port = 22 [apache] # Apache basic auth enabled = true maxretry = 3 # Ban for 1 hour bantime = 3600 [apache-noscript] enabled = true [apache-overflows] enabled = true [apache-badbots] enabled = true filter = apache-badbots port = http,https action = iptables-allports logpath = /var/log/apache*/*access.log maxretry = 1 [apache-nohome] enabled = true filter = apache-nohome port = http,https action = iptables-allports logpath = /var/log/apache*/*access.log maxretry = 1 [exim] enabled = true filter = exim port = smtp,ssmtp action = iptables-allports logpath = /var/log/exim*/rejectlog maxretry = 1 [exim-relay] enabled = true filter = exim-relay port = smtp,ssmtp action = iptables-allports logpath = /var/log/exim*/rejectlog maxretry = 1
While adjusting Fail2Ban, I was surprised by how sensitive this software is. It can just refuse to start without any notice in the log or on the command line. Even if its log_level variable is set to 4 (= DEBUG) in /etc/fail2ban/fail2ban.conf.
In such a case, a sure way to find the culprit is to use a brute force debugging method: first set all the enabled variable of your jail.local‘s sections to false. Then activate one section after another until Fail2Ban refuse to restart.
For me, the problem was that I forgot to add my custom exim-relay filter to Fail2Ban. So I fixed my issue by creating an empty file at /etc/fail2ban/filter.d/exim-relay.conf in which I pasted the following content:
# Based on default exim.conf filter by Cyril Jaquier # Real life exemaple: # 2009-07-02 08:16:42 H=118-167-129-21.dynamic.hinet.net (91.121.198.84) [118.167.129.21] F=<titieueue@hotmail.com> rejected RCPT <s2288@mail2000.com.tw>: relay not permitted [Definition] # Option: failregex # Notes.: regex to match use of my exim mail server as a relay it does not # allow. # Values: TEXT # failregex = \[<HOST>\] .*(?:relay not permitted) # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex =
Speaking of custom filters, here is one to filter DFind scans (file located at /etc/fail2ban/filter.d/apache-w00tw00t.conf):
# Based on http://howflow.com/tricks/block_w00tw00t_scan_hosts_with_fail2ban # Real life exemaple: # [Sat Jun 27 16:43:08 2009] [error] [client 94.23.57.77] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:) [Definition] # Option: failregex # Notes.: regex to match the w00tw00t scan messages in the logfile. # Values: TEXT failregex = ^.*\[client <HOST>\].*w00tw00t\.at\.ISC\.SANS\.DFind.* # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT ignoreregex =
And here is the corresponding section from my jail.local file:
[apache-w00tw00t] enabled = true filter = apache-w00tw00t action = iptables-allports logpath = /var/log/apache*/*error.log maxretry = 1
Blocking e107 dDOS attack with fail2ban
Last month, a new security vulnerability was discovered in e107. If a fix was released quickly, some instances on the web were left unpatched. These sites are easy target for hackers script-kiddies, and a generalized dDOS attack was carry out on every e107 websites out there.
I’m no exception and the old and decrepit part of Cool Cavemen’s website still running on e107 was attacked. This was enough to crash my tiny server. Unfortunately this happened while I was on holidays. Without any time to address this issue properly, I decided to shutdown my web server. This explain why this blog and all Cool Cavemen’s websites were dead during half of july.
Now everything is back to normal (I hope), thanks to fail2ban. I created a set of rules (based on this article) to dynamically catch dDOS attempts and ban all IP addresses involved. Here is how I configured fail2ban…
First, create a new empty file at /etc/fail2ban/filter.d/apache-e107ddos.conf and put the following directives there:
# Fail2Ban configuration file
# Notes.: Regexp to catch all attemps to exploit an e107 vulnerability.
# Author: Kevin Deldycke
[Definition]
failregex = <HOST>\s-\s-\s.*\s"(GET|POST).*\/(help_us|contact|config|avd_start|\*)\.php
<HOST>\s-\s-\s.*(Casper|b3b4s|dex|Dex|kmccrew|plaNETWORK|sasqia|sledink|indocom) Bot Search
<HOST>\s-\s-\s.*MaMa CaSpEr
<HOST>\s-\s-\s.*rk q kangen
<HOST>\s-\s-\s.*Mozilla\/4\.76 \[ru\] \(X11; U; SunOS 5\.7 sun4u\)
<HOST>\s-\s-\s.*perl post
ignoreregex =
Then update you fail2ban config file (/etc/fail2ban/jail.local in my case) with the appropriate section:
[apache-e107ddos] enabled = true filter = apache-e107ddos port = http,https action = iptables-allports logpath = /var/log/apache*/*access.log maxretry = 1
Then restart your fail2ban service:
$ /etc/init.d/fail2ban restart
And you’ll start to get those nice logs:
$ tail -F /var/log/fail2ban.log 2010-06-23 16:05:37,417 fail2ban.actions: WARNING [apache-e107ddos] Ban 193.33.21.199 2010-06-23 16:05:58,113 fail2ban.actions: WARNING [apache-e107ddos] Ban 89.108.116.226 2010-06-23 16:05:58,521 fail2ban.actions: WARNING [apache-e107ddos] Ban 69.41.162.10 2010-06-23 16:05:58,541 fail2ban.actions: WARNING [apache-e107ddos] Ban 209.62.28.178 2010-06-23 16:06:03,573 fail2ban.actions: WARNING [apache-e107ddos] Ban 69.73.147.90 2010-06-23 16:06:42,975 fail2ban.actions: WARNING [apache-e107ddos] 69.41.162.10 already banned 2010-06-23 16:06:44,227 fail2ban.actions: WARNING [apache-e107ddos] 69.41.162.10 already banned 2010-06-23 16:06:54,238 fail2ban.actions: WARNING [apache-e107ddos] 69.73.147.90 already banned 2010-06-23 16:07:50,305 fail2ban.actions: WARNING [apache-e107ddos] Ban 80.55.107.74
Google Apps’ video chat comes with secure Gmail sessions
The story was spread by all top tech blogs last week: Google’s Gmail now features a video chat. And it requires the installation of a dedicated plugin.
Alas, there is no such plugin for any other platform except “Windows XP and later” (according the official website) and Macs (as read on the official blog). So it’s a quite sad news for us Linux users. Indeed, I’m confident about a future seamless integration into the free software ecosystem, as the Gmail’s video chat is based on a stack of open (or soon-to-be, according the recent controversy) standards and protocols: XMPP/Jingle, h264/SVC & RTP.
Anyways, that’s not the main purpose of this post.
I just wanted to point out an update that was not reported by the news: as soon as it was officially made available for the public, the brand new video feature was released for Google Apps’ Gmail too.
Not only that, Google also backported to Apps’ Gmail the much awaited HTTPs option that allow you to force secure encryption of your sessions:

These two updates are quite interesting to note. I long as I remember (and I might be wrong), Google Apps components were always out-of-sync with their legacy equivalent. So this maybe a sign of change in a really good direction for Google Apps users ! ![]()
WordPress 2.2 Security Hole: Identity Theft
I’m running 4 WordPress blogs, for me and my friends. All of them are updated to latest version of WordPress as soon as a new one is available.
One of them, Maomium, was hacked last night. Someone created a user account on it then stole my admin identity to post content. As soon as I discovered the hack, I’ve put the blog down and changed all passwords which may have been exposed to the hacker (database, etc…).
Before the hack happened, my apache log show me that a person was looking for blogs powered by WordPress 2.2 and open to registration:
123.76-136-217.adsl-dyn.isp.belgacom.be www.maomium.com - [07/Jun/2007:00:51:55 +0200] "GET /category/wordpress/ HTTP/1.1" 200 2960 "http://www.google.be/search?hl=fr&q=%22powered+by+wordpress+2.2%22+Register&btnG=Rechercher&meta=" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4"
This person was my hacker. As you can see he’s a belgian guy and his broadband provider is Belgacom, to which I sent an abuse request. He register himself as Waryas with his myv4you@hotmail.com email. I know that, thanks to the email WordPress send me each time someone register. Then google told me that this hack was not his first.
If you want to disect his behaviour, you can download my apache log.
This event show us that the WordPress vulnerablility regarding guest account registration is still there. So the advice given by CountZero must be applied !