Drupalcon 2011

Tom (my boss) and I arrived in Chicago last night for Drupalcon 2011.  I will be blogging my notes from training classes & sessions, but I will not be placing them in the "planet" category, so they will not be syndicated on Planet Ubuntu & Planet Georgia, unless there is content significantly relevant to the Ubuntu community.  (If you're interested in my Drupalcon 2011 coverage, please check my site or subscribe to its feed.)

Many of the notes will be intended for my later consumption, but I'm hoping they may also help others address the same issues.  Let me know if there are confusing parts you'd like me to expand upon.


Memo to Self when Moving Databases

As a memo to myself, and in case others aren't aware of this:

If you move the entirety of a mysql server (e.g., all databases, especially the "mysql" database) to a new Debian-based (Debian, Ubuntu, etc.) server, you need to make sure the debian-sys-maint user is created or updated.

If moving from a non-Debian-ish environment, try:

GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY '--password--' WITH GRANT OPTION;

where "--password--" comes from /etc/mysql/debian.cnf.

If moving from another Debian-ish environment, copy the password from /etc/mysql/debian.cnf on the old server to the same file on the new server.

HTH.


Password Generating Webpages

First off, let me say that I commend Steve Gibson's attempts to bring information security to the masses.  I think it's important to educate the user base, and most of the time, he does a great job of it.  Unfortunately, a lot of his advice also seems to be filled with either "marketing speak", or (worse) just plain incorrect information.

In February, the Atlanta Linux Enthusiasts mailing list had a long discussion about the merits of "CLOSED" vs "STEALTHED" ports as advocated by Steve Gibson of grc.com.  I, for one, love spirited discussion, and thought it was good to discuss a variety of viewpoints and issues.  I believe that >90% of the discussion was very professional and mature discussion, which is something I attribute largely to the membership of the ALE mailing list.  Many other mailing lists would have resulted in a very quick flame war.  During that discussion, I stated that I felt that much of his advice (though overall sound advice) was misleading to users, and I still believe that.  Even if the end result is users taking corrective action, misleading them is not helpful in the long run.

Today, I saw a link to Steve's page password generation page.  Looking at it, I had several concerns about the page.


GnuPG: The What and the Why (For Me, Anyway)

I'm a big advocate of GnuPG, the Free implementation of the OpenPGP standard.  I've even recently begun to use a smart card for storing my keys.  I've also answered some questions about why I do this, so I thought I'd write about it here.  Put simply: the Bill of Rights is important to me.  My privacy is important to me.  Security is important to me.  OpenPGP can help me protect the things that are important to me.


SSH across a Layer 7 Filter

Every once in a while, I find myself in a situation behind some sort of device that filters a lot of traffic.  Most often, it's on my laptop at some facility (e.g., coffee shop) that only allows HTTP/HTTPS out.  For a while, I just listened for SSH traffic on port 443 (HTTPS) to connect through port-based firewalls.  However, a few times now I've seen a connection reset immediately after the SSH handshake started (during the protocol&cipher negotation).  Looking at them through WireShark made it obvious it wasn't a server or client problem, but some intermediate device sending a RST.

At first, I just throught I would use Dag Wieers's method for tunneling SSH over HTTPS with Apache/mod_proxy.  Unfortunately, Apache bug 29744 causes CONNECT over HTTPS to fail.  I also didn't really want to add another application to my system just to do that via proxytunnel.

My method, I will note, does NOT allow you to run both an HTTPS server and allow these connections on the same port.  What it does do is prevent passive sniffers (including Layer 7 devices) from seeing the SSH session initialization.  It still uses SSH for authentication, and I don't believe it poses any special security risks.  You'll need a dedicated IP/port combination to run this on, and port 443 will have the easiest time getting out of the networks discussed at the beginning.

Yes, the double-encryption is unnecessary overhead, but it gives you the power of SSH while making the network see nothing more than a simple SSL connection.

So, let's get it done! First off, install stunnel4 on your server. My configuration looks something like this:

cert = /etc/ssl/somecert.pem
sslVersion = SSLv3
chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
pid = /stunnel4.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1

[ssh]
# This address and port cannot be used for anything except this connection
accept = 203.0.113.2:443
connect = 127.0.0.1:22

On your client, you'll just need the standard openssl application.  OpenSSL is installed on (nearly ?) every Linux distribution by default, so no extra client application needed here. You'll find it easiest to set up a ~/.ssh/config file. In my config, I have a stanza like:

Host server.https
	Hostname 203.0.113.2
	Port 443
	ProxyCommand openssl s_client -connect %h:%p -quiet 2>/dev/null
	User username

Doing an "ssh server.https" should connect to the server via the SSL tunnel.