Author: Michael Lucas

I’m a big fan of RANCID.  While RANCID is best known as a management tool for automatically backing up Cisco configs, it also supports much other handware, and is fairly easily extensible.  I’m responsible for several Mikrotik routers, and need to back up their configurations.  People have written scripts for Mikrotik support in RANCID… but they don’t work with SSH, only telnet.  And they don’t work if you run SSH on an unusual port.

After trials, errors, advice from Chris Falz, and more errors and trials, I found that the following RANCID configuration works.

add password YourRouter YourPasswordHere
add user YourRouter YourUsername+ct
add method YourRouter ssh
add sshcmd YourRouter {/usr/local/scripts/microtiklogin.sh}
add noenable YourRouter {1}

Adding +ct to your username turns off color.  Setting an SSH port in RANCID’s usual way didn’t work with the third-party mtlogin script, and the sshcmd variable doesn’t cope with spaces well, so I used an external SSH command script.  This script is just:

#!/bin/sh
exec ssh -p PortNumber $@

My Mikrotik configs are now automatically backed up over SSH.

If you’re looking for a good Perl project, fixing the actual underlying mtlogin and mtrancid SSH functions would be appreciated.

I detest this IE error message, especially when a user calls to complain that a Web site is down. Internet Explorer deliberately hides actual HTTP error messages on the grounds that the Web offers unfriendly but useful error messages.  Apparently this generic message is much less likely to cause the user to flee in terror from insanity-inducing text such as “404 – Page Not Found.”  They effectively shift the induced sanity from the end user to the sysadmin.

There’s a way to turn off this generic friendly message and replace it with the actual error.  It’s under Tools-> Internet Options -> Advanced -> Browsing -> Show friendly HTTP error messages.  Uncheck this and restart the browser to get user-hostile but troubleshooting-friendly error messages.

Every time I need this, I have to scramble to find it.  Perhaps now that I’ve documented this, I’ll remember where it is.  But I doubt it.

On an unrelated note:  tomorrow is the Thanksgiving holiday in the US.  I’d like to remind my readers that the holiday buffet is not a challenge, and that leaving food uneaten is not a threat to your masculinity (or femininity, or whatever).

I have diskless Ubuntu 10.04 servers sitting naked on the Internet.  They’re for internal use only, but I don’t have a firewall in that facility, so any firewalling must be done on the host itself.  Ubuntu includes UFW, the “uncomplicated firewall,” a front end to iptables.  I don’t know how anything can claim to make iptables uncomplicated, but I suppose nobody would use the tool if they called it “less appalling firewall.”

These servers need to be able to contact the Internet, to get updates and such, but nobody except myself and my coworkers need to access these servers. The coworkers and I only come from a limited range of IP addresses.

On a disk-based server, I would define rules in UFW and then run ufw default deny incoming, much like this:

# ufw enable
# ufw allow from 10.0.1.0/24
# ufw allow from 172.16.5.0/24
# ufw default deny

If you do this on a diskless Ubuntu server, the system loses disk — even if you have a rule that specifically permits access to the diskless server. The obvious thing to try is to rip out the “default deny” and replace it with a rule to block unwanted traffic at the end.

# ufw deny from 0.0.0.0/0

Your resulting rules look like this:

# ufw status
Status: active

To                         Action      From
--                         ------      ----
Anywhere                   ALLOW       10.0.1.0/24
Anywhere                   ALLOW       172.16.5.0/24
Anywhere                   DENY        Anywhere

This looks like it should work.  I attempt to connect to the SSH server from an IP not in the permitted list, however, and can connect.  It’s not blocking traffic from denied hosts.  Huh?

Go to the file that contains the user rules, /lib/ufw/user.rules.  This is actually a script to feed to iptables. There are several lines like this, one for each block of management addresses:

### tuple ### allow any any 0.0.0.0/0 any 10.0.1.0 in
-A ufw-user-input -s 10.0.1.0 -j ACCEPT

My last rule, however, looks different.

### tuple ### deny any any 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -j DROP

The “all other IP addresses” is probably implied in that last rule, but… it really couldn’t be that simple, could it?  I edit the script to explicitly specify the source IP addresses:

-A ufw-user-input-s 0.0.0.0/0 -j DROP

and reboot.

And yes, it is that simple.  The firewall comes up at boot.  ufw status displays exactly the same rules as before.  But now, I can only connect from my management IP addresses.

The problem with tools that make things “uncomplicated” is that rather than removing the underlying complexity, they hide it. I probably need to break down and learn iptables, but I think I’d rather figure out how to get these hosts behind a PF box.

The constant stream of referrer spam isn’t sufficiently annoying; no, now worms constantly nibble at my WordPress install.  I could avoid worrying about this by, say, having a third party host my content and control my work, but if I did that I’d get a punch on both my geek card and my writer card.  And I still wouldn’t know who is linking to me.  Some of the referral spam I get hits 10-15 times a day, flooding actual links.

Fortunately, Apache’s mod_security can help lock down my server.  While you’ll find tutorials on using mod_security to stop referrer spam, mod_security can do much more.  Here I’m installing mod_security on my FreeBSD server running Apache 2.2.

# cd /usr/ports/www/mod_security
# make all install clean

Look in /usr/local/etc/apache22/Includes afterwards.  You’ll find the file mod_security2.conf and the directory mod_security2.  Initially, mod_security is loaded into Apache but doesn’t block anything.  Go into the mod_security2 directory and edit the main config file, modsecurity_crs_10_config.conf.  Change the SecRuleEngine to On, and create a SecDataDir, like so:

SecRuleEngine On
SecDataDir /var/run/modsecurity

You’ll need to create the security data directory and make it writable by Apache.  Then restart Apache.

# mkdir /var/run/modsecurity
# chown www:www /var/run/modsecurity
# apachectl restart

Now test your Web server, and verify that it still functions.  Bad Web applications can trip over mod_security2.  If your Web app fails, I’d suggest talking to the vendor about why your application doesn’t work securely.

If your site still works with mod_security2, you can start to block referrers that bug you.  In the mod_security2 directory, create the file referer.conf for rules to block bogus referrers.  The rule has this general syntax:

SecRule REQUEST_HEADERS:REFERER “REGEX” deny,log,status:500

mod_security will evaluate each incoming request by its header.  If the referrer matches the regular expression in quotes, the browser will return a 500 error.  The sample rules below show a small slice of the things I’m blocking.

…
SecRule REQUEST_HEADERS:REFERER “write\-a\-resume” deny,log,status:500
SecRule REQUEST_HEADERS:REFERER “wigmall” deny,log,status:500
SecRule REQUEST_HEADERS:REFERER “windowsphone” deny,log,status:500
SecRule REQUEST_HEADERS:REFERER “windows\-phone” deny,log,status:500
SecRule REQUEST_HEADERS:REFERER “zune” deny,log,status:500

It’s possible that this would block legitimate traffic, but I have a hard time imagining being linked from a weight loss or Windows Phone site.  It’ll take a while to accumulate a list of suitable regexes for my site.  And it’s a limited technique — I’m enumerating badness. But mod_security also protects me against the various WordPress worms, and it can also block traffic from addresses on an RBL. I’ll do that at a later date.

UPDATE: Your SecRule should not include the “log” keyword. See the later posting here.

UPDATE2: more here.