Welcome to the Geeks & God Static Archive. Read more »



You are missing some Flash content that should appear here! Perhaps your browser cannot display it, or maybe it did not initialize correctly.

This week on the podcast we hack your iPod and force you to listen to an episode about Security. After seeing way too many websites and web servers become compromised this year, Rob and Matt decide to tackle the basics of what you can do to keep your site and server secure. We talk about generating, storing, and remembering passwords, locking down your server environment, keeping your website up on it's security releases and finally what to do if you get hacked.

But before all this we get a little too excited when one of our listeners asks us how we feel about non-Christians participating in our community and how, in general, Christians should act towards those outside the faith.


I've been using KeePass for a while now for creating and storing my passwords, keeping a copy both on my home computer and my USB drive. I find it really good and highly recommend it for people wanting to store passwords without having to remembers them.

However, I recently came across LastPass, an online password manager, and would like to know what you think of it. I'm thinking of using it, but would like a second opinion before giving them all my passwords (especially since it's not open source like Keepass).

You Guys Rock!, I cannot

You Guys Rock!,

I cannot believe that there is a Christian podcast out there that is so sensitive to the needs of Christians and Non-Christians.. You guys are a great example to what believers should strive to be like. I love how you mentioned all that you did about loving others and treating them like we want to be treated.

Keep up the good work and keep up your studies.. I love to study the word and I feel the same way about some Christians and I sit back and Go DUH! what are you doing.

Thanks a Million for everything you do.
Be Blessed1

Visit These Great Websites
www.embassyonline.ca (Young Adults)
www.embassystudents.ca (JR & SR High)
www.theembassyofgod.com (Main Site)
www.embassyworship.com (Worship Teams)
www.durhamhop.com (Durham House of Prayer)

Password software

A good friend of mine runs Edgerift Software. They produce software to remember your passwords (Mac only). He was just tweeting a couple days ago that someone cracked his software and is distributing the cracked version.

Think about this. Yeah, you can use the software for free if you use the cracked version. But what other modifications did the cracker add? It's the ultimate ID theft spyware. Do you trust the cracker? I'll give you a hint--he's breaking the law by cracking the software. Loose morals determined.

I just thought it was funny.

Rob, when you restored that hacked website, what were you using for db backup?

Atheist video on his encounter with a christian

I thought this video would be a great addition to the discussion on the show. If you know anything about this guy you'll know he's a very devout atheist. He has a television show (on HBO?) and a show in Las Vegas, you might have heard of Penn & Teller



Liked this episode. I do not think you mentioned Captchas. I use them on my login form which adds a layer to the password guessing problem.

I also use a module which emails the sql database to me once a day. I like the feature and it helped me diagnose and recover from the one time my site got hacked. I do wonder if transmitting the sql file poses a security threat.

I also use a module which

I also use a module which emails the sql database to me once a day.

Which module is this? I'd be interested to find out more about it...

sql backup

Its the drupal dba module. It is not available in version 6

ssh protection

I was just looking at my logs last week and noticed some ssh login attempts. I found and installed DenyHosts. It will block an IP after a set number of unsuccessful logins. Now I have a nice little collection of IPs in my hosts.deny file.

ssh protection

If you connect from a to your server from a static IP, you can only allow connections from known IPs and IP ranges using a firewall. I have used this approach in the past. The biggest problem is if your IP changes unexpectedly you are locked out of the server. I would only recommend this on a server that you can have physical access to, which I had, or a secondary way of connecting.

Another security tip for SSH is to use SSH Keys. I have never used this, but I am looking into seeing if it is something I want / need to use.

Another strong suggestion for for SSH

Included with the SSH keys I would strongly suggest also changing your default ssh port to something other than 22. As most of the port scanning software will always look for that default port first before taking the time to do a "thorough port scan" through the whole range.

RightPath Networks
Building Relationships.. One Connection at a time

Diffrent SSH Port

Changing the default port of SSH doesn't always work, unless you also remove the SSH banner. If you were to telnet to an SSH port it will report that SSH is listening. For example telnet to login.swcp.com:22. Also as a note you can telnet to mail server on port 25, and if you are familiar with SMTP commends you can actually send an email to a user on that system. But my point is, regardless of the port number you use for SSH, it really don't make you any more secure. The one thing that it does do, is protect you from the possibility of being hit by a ssh worm. A smart hacker is going to see right past this, and it will hardly slow him down.

It is best to have good security practices is your best defense. The two biggest things you can do is keep your software up-to-date with all of the security patches. Security patches should normally be applied as soon as possible. Having correct permissions and user groups, and strong passwords. Random passwords containing at least one upper or lower case letter and a number that is at least 8 characters long, and is random. Locking accounts, after wrong passwords can prevent brute force attacks. You may even need to require users to change passwords every few months depending on requirements for security about 60 days at the short end to every 90days. I would even be willing consider 120days.

There are other things that can be done, but it is likely beyond scope of what most people here need.

The drupal.org post controversy

Thank you for this episode. I noticed the controversy on drupal.org about Christian Assemblies International. This particular group is kind of on the extreme end of the theological spectrum, because they believe that british and northern european peoples are the literal descendants of the lost tribes of israel, and the inheritor of the biblical promises to israel. The web sites says, "The literal descendants of the lost ten-tribed House of Israel are found today throughout the British Commonwealth of Nations, the United States of America, and certain countries of north-western Europe, particularly Denmark, Sweden, Norway and Holland." This is not a view held by the vast majority of christians, and it is not surprising to me that some would find it essentially racist. The problem is that non-believing people tend to lump us all together, and assume that any Christian believer is the same type of person they see on the news carrying signs that say "God hates fags." We are not all the same, and need to remember that as we deal with other people.

A few comments and recommendations


Thanks for doing this show, guys. As you mentioned, I think most people are way too lax about security. I agree that it's quite possible to go too far with security in some situations, but overall you hit the nail on the head. Drawing from my experience as a linux server admin, I'd like to make a few comments and recommendations.

Media Temple was totally, completely wrong that using a longer password was the only thing that could have been done to prevent that brute force attack. There are several other things that can be done - below is a short list of a few of them.

(Note: all of these recommendations require root access to the server - if you're running a dedicated server or VPS, you should be all set. If you're on shared hosting, though, there's not much that can be done other than using a very strong password)

First, if you have root access to the server or VPS, you can change what port the SSH daemon listens on. The scripts that run these attacks assume that they'll be able to connect to ssh on TCP port 22 (the default ssh port). If you've changed that to a high port number, it'll try to connect, won't get a response, and then will move on to its next victim. Before making this change on my servers, I'd get notifications several times daily about brute force attacks. Since changing (about a year ago), I haven't received a *single* brute force attack. So that's recommendation number one.

My second recommendation would be to install a program that watches logs for these brute force attacks and then takes action to mitigate them. The two that I've used are DenyHosts and Fail2Ban. Both work well, but I've migrated most of my servers over to Fail2Ban for the reason that it seems to take less CPU cycles than DenyHosts. Fail2Ban watches the syslog for failed attempts, and if a user-configurable threshold is exceeded, it will actually use the linux iptables firewall to block the source IP of the attack. Problem solved.

Lastly, change the authentication method for ssh so that it will only use keypair auth instead of password auth. This process may look a bit daunting at first, but it's actually quite simple. The gist of is is that you generate a keypair for yourself (the "pair" comprising a public key and a private key). The private key is kept on your workstation, and the public key is placed on the target server. Then, instead of using a password to authenticate, the ssh server will actually match up the public and private keys. If they match correctly, it will let you into the server. The advantage this has over password auth is that the keys you generate are a *lot* longer than any password you could possibly remember. Once you have key auth set up successfully you can actually completely disable password authentication over ssh. Just google for "ssh public key authentication", and you'll be provided with a bunch of tutorials to help get you set up.

I guess those are my recommendations for now. If anyone is interested in more info on any of these, feel free to contact me via my contact form.


Diceware for creating Good Passwords

Diceware (www.diceware.com) is a system for creating strong passwords. It works well because system doesn't leave any difficult decisions to the user: the passphrase is built using a word list and ordinary dice. The only options are how long to make the passphrase and whether to add a special character. Mathematicly, the resulting passphrase is like a random string of characters, but arguably easier to remember. Even if an attacker knows you used the Diceware system to build the password, the passphrase is secure and resistant to brute-force attack (it's designed for encryption keys, where you can't prevent brute-force attack).

Great Episode


Great episode guys. A few comments:

1.) To generate random passwords I use www.grc.com/passwords
It will generate a 64-character ASCII, Hex or alpha-numeric password. When I need a short one, say 8-12 characters, I just highlight the appropriate number of characters and use those.

2.) Wordpress uses an auto-update feature. Any comments on how that is implemented? Not being a heavy db or php guy I'm not sure if their implementation is secure. I believe it is but any input from anyone out there would be appreciated.

Jesus Geek: Technology, news and how-to's for the connected Christian
Follow me on Twitter: http://www.twitter.com/theOJG

Security Now

The passwords created by grc are supposed to be pretty solid. I've heard how they are generated on the Security Now podcast. It's pretty crazy stuff and they are as random as there are out there.

Matt Farina
Geeks and God Former Co-Host

GRC Passwords

The passwords from GRC are very very good. They are so long and so random that I normally use the password only for use for WPA pass phrases.

If you use Firefox download the password hasher add-on. It will generate unique passwords for each site you visit based on the domain name and a master password. You can specify the length, and the type of characters that are used.

SSH Keys and HP SQL injection White Paper


Great episode! Here are a couple of additional resources for everyone.

SSH Key-Based Authentication

I'll echo the comments above about creating SSH key pairs for authentication. One my most secure servers, you can't login remotely with a password at all, and then you have to su to become root.

Here are a couple of links that explain this process in pretty good detail:

When connecting from a Windows workstation, you can use puttygen to create key pairs for PuTTY and then follow these articles for the rest of the implementation steps.

Download and run puttygen from the PuTTY download page, and generate a public/private keypair of type "SSH2 DSA." Install the public key on the desired Linux/UNIX host as described in the articles. In PuTTY, specify the private key on the Connection/SSH/Auth tab, then go back and save this change into your default settings.

For an even easier-to-use approach, this follow-up SecurityFocus article explains how to use ssh-agent to manage keys so that you only need to provide your password once per session. PuTTY has a corresponding pageant.exe utility that works very well. Create your private key (with passphrase) in puttygen, and then put a shortcut for path\to\pageant.exe path\to\private\key in your Windows Startup folder. Pageant will prompt you for your passphrase at Windows login time, and then provide authentication for all of your PuTTY sessions to hosts with login accounts that have the matching public key. If "Allow agent forwarding" is checked in PuTTY's Connection / SSH / Auth tab, you can usually get to a second hop with forwarded keys, too.

Blind SQL Injection Attacks

Last spring, we suffered an attack against some older web pages written in VBScript. The result was that our web server was sending out content with <script> tags that were trying to load infected software on visitors' computers. Not good.

In the process of figuring out what happened and correcting it, I found an excellent white paper from HP explaining blind SQL injection attacks and how to defend against them. It's pretty clear and easy to understand stuff. You do have to register to download this white paper, and a sales rep from HP called me afterward trying to sell me some security tools. (We considered it, but I was too busy at the time to really look into it.)

To get this document, check out the White Papers section at the HP Application Security Resource Library. It's the first one on the list. I'm sure the rest of the white papers there (covering a variety of other hot-topic security issues) are equally good.

So happy web serving, and hey, let's be careful out there!


Backups or Restores?

Nobody cares about backups. What they really care about are restores.