How to tame the B.E.A.S.T. in your SSL

Since I was looking the details how to tame the B.E.A.S.T. (Browser Exploit Against SSL/TLS) once again, I thought I write a few lines down about it. The exploit actually was discovered last year by Juliano Rizzo and Thai Duong. More details about the exploit can be found at h-online.com. To hinder the BEAST from attacking you, one way is to enable TLS 1.1 in your browser, but I plan to go another way.

I actually disable the vulnerable CBC modes. To archive this with apache and mod_ssl/mod_gnutls, do the following:

- mod_ssl:

SSLHonorCipherOrder on
SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL

- mod_gnutls:

GnuTLSPriorities NONE:+VERS-TLS1.0:+ARCFOUR-128:+RSA:+SHA1:+COMP-NULL

I found this information in the German IT-security forum over at XING.

flattr this!

Transfer mail encrypted between the servers with postfix

When I was looking at mailheaders again (it became kind of a hobby, and this proves you learn from it^^) I was noticing one of my incoming mails was transfered via ESMTPS. So far I knew SMTP and ESMTP but ESMTPS was appearently a new. Turned out it was ESMTP via secure transportlayer, or like RFC 3848 defines it: “The new keyword ‘ESMTPS’ indicates the use of ESMTP when STARTTLS is also successfully negotiated to provide a strong transport”. So I became curious, how can I do that too? After a bit searching I came across the setting smtp_tls_security_level in postfix and yes, after setting it to ‘may’ it did the trick. So now if the server supports STARTTLS he opens a encrypted connection with the remote server for the transfer. You need to set a bit more to make it working without any errors, here is what you need to do on a Ubuntu 10.04 (Debian and others should work similar):

sudo postconf -e 'smtp_tls_security_level = may'
sudo postconf -e 'smtp_tls_loglevel = 1'
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo service postfix restart

We set only smtp_tls_security_level to ‘may’ cause otherwise with ‘encrypt’ the remote server is forced to support STARTTLS, if he does not the transfer fails. So with may encryption gets used when supported. Loglevel 1 gives you a short notice when a safe connection was established and what cipher got used. Like this:

Mar 14 00:22:08 utgard postfix/smtp[11397]: setting up TLS connection to gmail-smtp-in.l.google.com[173.194.70.26]:25
Mar 14 00:22:08 utgard postfix/smtp[11397]: Trusted TLS connection established to gmail-smtp-in.l.google.com[173.194.70.26]:25: TLSv1 with cipher RC4-SHA (128/128 bits)
Mar 14 00:22:09 utgard postfix/smtp[11397]: 6A591E6C2C3: to=, relay=gmail-smtp-in.l.google.com[173.194.70.26]:25, delay=0.9, delays=0.01/0.03/0.13/0.73, dsn=2.0.0, status=sent (250 2.0.0 OK 1331680929 s26si2913819weq.13)

And last but not least, we need to set the path to where he can find the ca-certificates to validate the remote servers certificate. Otherwise we get a entry saying a untrusted connection gets used, means he encrypts but can’t verify the remote identity. In Ubuntu (Debian) inside the chroot path of postfix lies a file containing all ca-certificates, we just need to point postfix to it. The normal path is not accessable from inside the chroot. Thanks to Alain Kelder to point this out. With all that done, our server is good and enabled to send out his outgoing mail to other smtp servers using a secure transport layer. You can go even further and for example force encryption for specific servers on a per-site basis. But since thats not the scope of this article, please refer to the postfix TLS documentation for that. There you find also information how to optimise the encryption by disabling/enabling ciphers and similar.

flattr this!

pam_geoip – Restrict accounts to certain Cities/Countrys only

A friend did ask me, if its possible to block access to his SSH server by blocking via GeoIP which he is already successful using on his webserver to lower the amount of spam he gets (at the cost of potential visitors, but thats his choice after all, right ?). So I dugg a bit in the net, and came across the module pam_geoip.so which allows me based on Maxmind’s GeoIP City Database to block access to services using PAM for authentification. What I show here is a example how to install it and block certain countries using GeoIP City DB lite (aka Maxmind’s free database) from accessing our SSH accounts. This works on a Ubuntu/Debian Linux, for other Distributions/OSes please check if the libary packages named similar. I expect you to have the basic development tools installed already. So let’s start:

sudo apt-get install libgeoip-dev libpam0g-dev
wget http://ankh-morp.org/code/pam_geoip/pam_geoip-0.9.tar.gz
tar xzvf pam_geoip-0.9.tar.gz
cd pam_geoip-0.9
make
sudo -i
cp pam_geoip.so /lib/security/
chown root:root /lib/security/pam_geoip.so && chmod 644 /lib/security/pam_geoip.so
cp geoip.conf /etc/security
chown root:root /etc/security/geoip.conf && chmod 644 /etc/security/geoip.conf
cd /etc/security
wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
gunzip GeoLiteCity.dat.gz
chmod 644 /etc/security/GeoLiteCity.dat

When that is done, fire up nano and set the geoip.conf to something similar as this:

#
# /etc/security/geoip.conf - config for pam_geoip.so
#

#<domain>   <service>  <action>  <location>  
*           sshd       deny      CN
*           *          ignore    UNKNOWN

When you’ve done this, fire up nano again to edit this time /etc/pam.d/sshd and add this:

account required pam_geoip.so geoip_db=/etc/security/GeoLiteCity.dat system_file=/etc/security/geoip.conf action=allow

With all this we set the pam_geoip module to default allow, and block all access attempts from Chinese IP’s. Don’t forget to restart the sshd and logout, as we don’t wanna be root longer then needed. You can use way more complex configurations like allowing access to a certain account only in a specific place or within a radius around this place. But for that I would really suggest to buy the premium version of the GeoIP City Database for the higher accuracy. For country-blocking the free should be fine for most of us through. For more complex usage check out the modules website at http://ankh-morp.org/code/pam_geoip/geoip.conf.html. And also checkout the included manpages/config samples. Thanks for help with the installation and the sample to block Chinese IP’s goes to guruway’s blog.

flattr this!

A bunch of tips for improving your postfix setup

Laptop with a opened envelope on the screen that has written eMail on it.Today I learned a few things on postfix and how to set it up cleaner. So I want to share this insights with you, especially the part how to clean up the mail header since it helps a lot and improves your privacy quite a bit. So let’s get started, shouldn’t we ? Lets start by adding a limitation on the SASL authenticated clients which address they can to send out mail. This gets archived by setting up “smtpd_sender_login_maps =” and adding “reject_authenticated_sender_login_missmatch” to smtpd_recipient_restrictions, so he check the map we setup in smtpd_sender_login_maps and if the SASL authenticated client fails rejects the mail. The map is looking like this:

# envelope sender           owners (SASL login names)
john@example.com            john@example.com
helpdesk@example.com        john@example.com, mary@example.com
postmaster                  admin@example.com
@example.net                fred, barney, john@example.com

So, setup the list with the addressed and allowed owners. Then convert it to a hashmap with postmap, and setup postfix.

$: postmap hash:/etc/postfix/addressowner_map
$: postconf -e \ 
'smtpd_sender_login_maps = hash:/etc/postfix/addressowner_map'
$: postconf -e \
'smtpd_recipient_restrictions = permit_mynetworks, reject_sender_login_mismatch, permit_sasl_authenticated, reject_unauth_destination'

Don’t forget to make smtpd_recipient_restrictions fitting your setup! After that restart postfix, try first to send out using the usual sender address. It should work fine, but when you set up a sender address you don’t own he should reject it. More information on this mechanism you can find in the Postfix SASL How to.

I was looking a while now for a way to remove my IP from outgoing mails, so my server is the start point of the delivery path. This is to hide my IP, also internal IPs and it solves problems with anti-spam mechanism like SPF. postfix (or any other SMTP server) receives mail from other mail servers (“incoming”), and mails by users (“outgoing”). As we don’t want to strip any headers from incoming mail, we first have to force all users to authenticate (which is a good thing anyway), and make Postfix add another header to authenticated (“outgoing”) mails. Then, we can match this header and strip both the Received line containing internal host names and IPs, and the authenticated header. So edit the config like this:

$: postconf -e 'smtpd_sasl_authenticated_header = yes'
$: postconf -e 'header_checks = regexp:/etc/postfix/header_checks'

Then create the file “header_checks” and add the following line, while editing “yourdomain\.com” to match your mail servers domain.

/^Received: .*\(Authenticated sender:.*/ IGNORE
/^Received: by yourdomain\.com .*from userid [0-9]+\)/ IGNORE

Restart postfix. This takes care of our problem. Send out a mail and compare the resulting header with an older, its much cleaner. Thanks goes to Moblog, who explained it nice and from where I took some parts. So this enables us, cause we have a clean header, to add a SPF record to our domain. To archive this, just create a TXT record with the content “v=spf1 a mx -all”. Simple but working good. For more information on SPF, check Wikipedia, since OpenSPF.org is at least for me always down.

That’s it for today, hope it was inspiring for you.

flattr this!

One-Time-Passwords with Google-Authenticator


Today I want to show you how to set up Google-Authenticator so make your remote login more secure then before. It offers us to secure our login with a HOTP (counter-based, HMAC-based OTP) or TOTP (time-based) tokens as an additional challenge before you can login. Basically even IF someone spots your password, without a fresh token he can’t login. But no worries, in case you loose your cell (which is used as our token-generator, supported is iOS, Android and BlackBerry) he also give us 5 extra tokens for emergency’s.

 

A word for those maybe thinking “Urk, its from Google”. Yes it is, BUT its not dependent or require you to have anything from the Google services. It’s a opensource implantation of the known algorithms, and like the WordPress plugin shows, nicely can be integrated into various apps. Also its quite cost-effective as most have anyway a smartphone today.

So let’s start with the installation, I did it on a Ubuntu Lucid 10.04. We need to build it the packages “gcc mercurial libpam0g-dev subversion git-core”. Additional we should install “libqrencode”, but as it’s not available from the repository’s we just build it from the source, so we need also “git” to checkout the source from GitHub. libqrencode is to display a QR code on the terminal, saving us the typing of the initial code for the token generator.

$: sudo apt-get update ; sudo apt-get install -yy gcc mercurial libpam0g-dev git-core subversion

Once we’re done that, lets check the mercurial version as its crucial to checkout the Google-Authenticator source-code. You do that with “hg –version”. If the version is bigger then 1.5 then all is OK but if the version is smaller then that, we need to upgrade it to one bigger then 1.5. To do so, just go to the Ubuntu FTP Server and grab the package “mercurial-common_*.deb” and the “mercurial_*_amd64.deb” or “mercurial_*_i386.deb” depending on your system. Install them with:

$: sudo dpkg -i mercurial*.deb

That takes care of mercurial, lets move on with the preparations. Next we install libqrencode:

$: git clone https://github.com/fukuchi/libqrencode.git
$: cd libqrencode
$: ./autogen.sh
$: ./configure --prefix=/usr
$: make
$: sudo make install

With that libqrencode is in place. We need to install it in /usr instead of /usr/local, cause otherwise google-authenticator won’t find it. On we go with building the pam-module:

$: hg clone https://code.google.com/p/google-authenticator/
$: cd google-authenticator/libpam
$: make
$: sudo make install

Now that the parts are in place we begin assembling them. Each user now must run “google-authenticator” once so he gets a key generated before we can activate it. The program generates a base32-encoded key you are to enter in you smartphone, and also here comes libqrencode into play. It generate us a nice handy QR code to shoot with the phone saving us the typing (yes, it works fine on a console, using ansi). Also you get the 5 emergency codes I mentioned earlier. Put them in a save place! Before we make the final changes and activate the new config, open a additional terminal just in case. It’s for the case that something get wrong, so you can look up whats wrong with your config, and so you still have access to the server. Now it gets time to edit the pam-configuration.

$: sudo nano /etc/pam.d/sshd

Now we have to decide if we want get asked for the token before or after the regular password. That determines if you insert the line “auth required pam_google_authenticator.so” before the or after the default line. In Ubuntu the line for the default auth is for example “@include common-account”. So insert it before or after that line, depending on how you like it better. I get asked for my token before the usual password, so I can anger the brute-force kids a bit. After that we edit the sshd_config to enable Challange-Response-Auth.

$: nano /etc/ssh/sshd_config

Here look for the line “ChallengeResponse no” and change the “no” to a “yes”. Now we’re ready to to restart the sshd, and it (should) work.

$: sudo service ssh restart (or sudo /etc/init.d/ssh restart)

Now try to login, and see if everything works. If not, check “/var/log/auth.log” for error-messages. If you only want to use 2-factor-auth only for a few users, then you find a patch here to disable the 2-factor-auth when there is no .google-authenticator file in the home-folder of the user.

If you should use public-key-auth, its a bit complicated. That comes from the fact that the OpenSSH daemon overrides the pam-config on public-key-auth, and so the token-auth won’t take place. For some of you this might be what you want, but for others wanting to combine both, it might be not what they want. I have a solution in one of my magazines here but I want to play first with it a bit, before I write here in detail about that.

Hope you could find something useful in this article. The applications for the cellphones can be found in the following places:

While looking for more information on the Blackberry client I just found something nice. There is a WordPress plugin that allows you to use this login-method with your blog to raise safety for you admin account. The plugin you can download here.

And for more information/references:

 

flattr this!