Integrating Shorewall and sshguard on Ubuntu

I’ve been getting familiar with Shorewall since last fall, and quite like it. I also use sshguard to prevent incessent knocking on SSH and FTP ports. Or I thought I was using sshguard, after all, it was running. Then I realized that I had set up and tested sshguard way before I started using Shorewall, and as my understanding of how Shorewall functions gradually incrased, it eventually occurred to me that Shorewall likely overwrites the ‘placeholder’ chain sshguard needs to function.

I was looking for an easy way to view and occasionally delete sshguard rules, and came across Mika’s post that outlined two handy command line aliases that accomplish just that. While starting to test these, I noticed the ‘sshguard’ chain was nowhere to be found.

My first attempt was to load the sshguard chain with iptables-restore in pre-up, but that disabled the entire network! ๐Ÿ˜€ I suppose sshguard chain needs to come after Shorewall chains/rules have been initialized. While I’m not sure if this is the best way to get it working, this does work: I added two lines from sshguard sample ruleset in /etc/rc.local:

iptables -N sshguard
iptables -A INPUT -j sshguard

Importing Installer ISOs to ESXi 5.x Datastore

VMware ESXi 5.x service console no longer offers ftpget command. But all is not lost.. ๐Ÿ™‚ Follow the steps below to transfer your favorite OS installer ISO to the datastore from where you can conveniently mount it as if it were DVD/CD-ROM:

  1. Download 64-bit ncftp binary distribution to your local (Windows) workstation.
  2. Open vSphere, highlight the hostname, select the the desired storage unit from the Storage list under Resources (I usually use the datastore on the “system” disk for this purpose), and right click on it to open the context menu, then choose “Browse Datastore”.
  3. With the root highlighted, click on the “Upload files to this datastore” (the fourth icon from the left, with green “up” arrow). Select the ncftp binary package (that you download in step 1) from your local Windows hard drive.
  4. After making sure SSH login is enabled on the Yellow and Grey screen (Troubleshooting Options > Enable SSH), log in to the service console via SSH.
  5. Move the ncftp binary archive to /opt from the Datastore root, decompress it, and cd to the ncftp folder:
    cd /opt
    mv /vmfs/volumes/yourdatastore/ncftp* .
    tar zxvf ncftp*
    cd ncftp*
  6. Open ESXi firewall egress (outbound) rules so that the FTP client can access the outside FTP server:
    esxcli network firewall ruleset set -r ftpClient -e true
  7. With your favorite installer ISO available on an FTP server (perhaps on the distribution server, or on your local FTP server), you can now access it, like so:
    ./ncftpget -v -E -u ftpuser -p password some.remotehost.com /vmfs/volumes/mydatastore ‘/remotefilename.iso’

    Command from left to right:
    ncftp command (requires path, here “./” since you’re in the ncftp directory)
    -v for progress indicator
    -E for NOT passive mode (omitting it makes connection passive)
    -u ftpuser for remote ftp server
    -p password for remote ftp server (note: this is NOT sent encrypted!)
    some.remotehost.com is the ftp host name or IP address
    /vmfs/volumes/mydatastore is the path where you want to store the data on the local system
    /remotefilename.iso is the remote file (with full remote path if needed) to be transferred; the local file name will be the same

  8. Optinally, if you want to close the firewall egress rule for the FTP client, you can do so by issuing the following command:
    esxcli network firewall ruleset set -r ftpClient -e false

Now, when starting OS installation in ESXi you can highlight a created blank server instance, click on the CD-ROM icon on the toolbar (“CD/DVD drive 1” > “Connect to ISO image on a datastore…”), and then navigate to and select the ISO image you just transferred to your favorite datastore!

Finding public IP on Linux command line

Here’s a handy command to display the Internet facing IP on a Unix/Linux command line. This is particularly useful on systems where lynx is not available, and where the system might be behind a firewall so that the public IP cannot be discerned from ifconfig output.

curl -s myip.dk | grep 'IP Address' | egrep -o '[0-9.]{3,}+'

Chrome v18, self signed certs, “signed using a weak signature algorithm”, and an internal CA

Today when I was accessing some internal resources that are protected with an SSL cert that has been signed by the internal CA, I got an SSL error I hadn’t seen before: “This site’s security certificate is signed using a weak signature algorithm!” (see image below). With a quick test it was clear this was only an issue with Chrome. And a few Googlings later I found it was thanks to a recent auto-upgrade to Chrome 18. Most of the Google hits were discussing this error in the context of Facebook รขโ‚ฌโ€œ apparently some facebook servers are configured with an old, expired intermediate certificate. But this was not the case with my server cert, signed with the internal CA cert.

Digging some more, I came across a post by Dave Christiansen where he points out an obscurely documented switch for openssl req command. That works great for single self signed certs, but what if you’re using an internal CA? The CA cert can be created with “-sha512” command using “openssl req” (as outlined in Dave’s post), but then when you sign server certs with “openssl ca” รขโ‚ฌโ€œ even when you’ve created the CA cert with the “-sha512” switch รขโ‚ฌโ€œ Chrome still throws the same error.

The trick is to specify an equally obscurely documented argument “sha512” for the “-md” switch with “openssl ca”, like so:

openssl ca -md sha512 -config /etc/ssl/openssl.cnf.internalCA -policy policy_anything -in my.server.name.csr -out my.server.name.pem -keyfile ../private/internalCA.key -days 3650

Now the signed server certificate reflects “sha512RSA” as the Signature algorithm, and the Chrome error is gone.