A solution for blocking ssh probers/scanners.

Erich, There's a much easier solution to blocking those ssh scanning bastards... some nice friendly iptables rules! (I forward ssh to an internal system, so this is in the FORWARD chain.. use the INPUT chain otherwise)

### Catch SSH probes
iptables -A FORWARD -p tcp --dport 22 -d <local net> -o eth0 -s 0/0 -i ppp0
         -m state --state NEW
         -m recent --rcheck --hitcount 3 --seconds 60 --name SSH_PROBERS
         -j LOG --log-prefix "Adaptive-FW SSH Prober: "

iptables -A FORWARD -p tcp --dport 22 -d <local net> -o eth0 -s 0/0 -i ppp0
         -m state --state NEW
         -m recent --update --hitcount 3 --seconds 60 --name SSH_PROBERS
         -j DROP

iptables -A FORWARD -p tcp --dport 22 -d <local net> -o eth0 -s 0/0 -i ppp0
         -m state --state NEW
         -m recent --set --name SSH_PROBERS
         -j ACCEPT

So, in the INPUT chain, you wouldn't use -o, and -d would be the IP on your external link.. in this example, ppp0.

What it does, is uses the ipt_recent module, tracking connections from a given IP. 3 incoming connections in 60 seconds will cause the remote host to be blocked. Of course, this affects normal logins too, so for known hosts, it pays to insert a rule beforehand that does a -j ACCEPT.

I'm enjoyng the very short log entries for a given ssh scanning host in my logcheck mail :).

UPDATE 2006/04/07: Whoops...
Sorry Erich, didn't notice that :)

[08:51] [/Hacking] [permanent link]

My New Tablet PC..

So, for various reasons, I've moved from my trusty old Toshiba TE2000 to a much smaller, and cooler, HP TC1100 Tablet PC. Basically the Toshy decided to croak it (whilst at LCA2005.. *mutter*) - turns out the connector between the internal power board and the motherboard was damaged. In the hope that it would be useful to one of my co-organisers for LCA2006, it is now repaired and in his possesion. Anyway, I digress...

So, it's pretty slick device, and I've spent an amount of time over the last 5 days getting all the neat bits of hardware working with a fresh Debian install (I just couldn't do the Ubuntu thing, it feels too much like two-timing). Everything, bar the little digitizer 'pad button' things, is working, including the lovely little SmartLink WinModem (haven't tested it yet, but I can talk to it with minicom).

For those that are clever, they'll recognise it as the Tablet that both Bdale and Edale^W, er.. Elizabeth were using at LCA2005. Bdale mentioned to me that he couldn't seem to get both the digitizer and accelerated graphics (via the official nvidia driver) to work together. I now wonder what problem he was having, as I didn't do anything special and it's working fine. I was worried though as I had it working well under the nv driver, but to get rotation working with xrandr I had to change to the nvidia driver. So, now Elizabeth will be jealous - I can now happily play tuxracer, and design new courses with the digitizer under gimp without restarting X :) .

I mentioned xrandr, because you can't use a tablet and not have the ability to flip around into "portrait" mode and use it as a tablet is meant to be used! After some fiddling, it was correctly rotating.. sadly, the X wacom driver didn't have the ability to rotate whilst X was running - you could happily add the "Rotate" option to the InputDevice entry in xorg.conf (yeah, XFree86 sucks, ok?), but that would require an X restart. The effect is somewhat disturbing when you attempt to use the stylus on the rotated screen.. :)

A little hunting uncovered this patch which appears to solve my problem. After downloading dilinger's Xorg source package, I was able to patch a recent linuxwacom driver, and slip it into the package build instead of the older version of the module there (If anyone would like a copy of my wacom_drv.o, email me). I also needed to build an updated xsetwacom that knew about the newly available 'rotate-while-running' feature.

After all that, I now have a 3D accelerated display with a working stylus, that can be easily rotated to a portrait mode with these two commands:

xrandr -o left
xsetwacom set "Wacom Stylus" Rotate CCW

So, some software to top things off. This chap wrote a nice little perl tool called tabatha that does a nice job of providing a little menu that you can access via the side buttons on the tablet (I use hotkeys for this, after mapping the keys to unused keycodes with setkeycodes somewhere in /etc/init.d). But, he really should have worked out that sudo would be a better tool to use within the config than making you run it as root. It appears I'm going to have to package this particular tool...

For Stylus input, I'm using both xvkbd and xstroke, the latter of which it appears I'll have to package too. And finally, a useful looking tool that works really well, and I'm so far enjoying immensely, is gournal (Which will be the third new package I have to churn out). Gournal is a note taking application that looks like it supports a networked collaborative mode, and also saves into a useful format - svg.

Well, that's enough boring detail for now - I guess at some stage I'll have to note down all the gory details on a webpage for future reference and for others to look at.. But I should be doing some work :)

[04:49] [/Hacking] [permanent link]

A Waste of Time?

Alexander Schmehl posted a small, somewhat complex and inefficient shell snippet..

He must have been very bored - it finds any occurence of a given two letter combination, that has only one result when running 'apt-cache search <xy>' on it.. Give me strength!

(The easiest way to work something like this out, is to take the given snippet, and reflow it into a multi-line indented format that you can read)

[22:08] [/Hacking] [permanent link]

Whew!

Well, I've spent a few hours over the last 2-3 days slowly converting all the entries in my blog to use Markdown syntax, mainly thanks to Andrew Cowie's entry regarding his escapades into the blogosphere. I'd wanted to get this sorted out for some time, since I was sick of writing HTML for relatively simple formatting.

Andrew's RSS2.0 and Atom feed code, munges with $ENV{TZ}, but sadly it appears the ctime() that Blosxom uses doesn't react well to it being set, so I took Andrew's code, and added a couple of splatterings of "delete $ENV{TZ};" to get around this. (Basically posts on your web version appear with GMT too, rather than just what's in your Syndicated feeds).

The result of this, is that I now have rss20 and atom 'flavours', in Blosxom speak, for my blog. I decided to use some of those funky little feed icons too. Now, at some stage, I may even get around to learning some CSS to change the look and feel of things... who knows!

[22:23] [/Hacking] [permanent link]

MMJ connectors..

Bdale, I've got a few MMJ connectors lying around... but sadly I'm not keen on giving any of them up - but I will give this bit of info - a correctly wired RJ11 connector, with its tab block sliced off, fits nicely into an MMJ socket and works a charm.

[21:52] [/Hacking] [permanent link]

MythTV

Ok, so I've had a MythTV box for quite some time, but recently I've done some cooler stuff with it - I've also got a local friend who's done some pretty neat stuff with it too. Well, indirectly - not really with Myth per-se, but with stuff Myth uses (You should see his Satellite Dish farm).

To start with, said local friend had a spare DVB-S card that he wasn't using, and I mentioned some time ago I was interesting in getting - so he sold it to me... (must pay him..) The house I'm renting at the moment already had a small dish on it, pointing at Optus B1. The previous tenants had Satellite TV, from the local provider, Sky, which has a presence on B1. The goverment owned broadcaster also has some FTA stations on it, which are the target.

Anyway, after futzing around, and upgrading the Myth box to a 2.6 kernel for support of the DVB-S card, I get things working, but not in MythTV. Takes me a good week to work out that the DVB testing utility in the setup program hardcodes the LNB values for a Universal LNB, As opposed to a Ku Band LNB that are all too common here. Grr. Grr. Grr. So I finally get things working in Myth. Damn, that DVB-S picture is crisp.

Right, about this time, I also noticed that the xmltv source I was using to get EPG data dried up - an old website that was discontinued by the entity that owned it - somehow tied up with the broadcaster, but I don't know for sure. This is where the local friend comes in. Drew has been mucking around with pulling the EPG data out of the DVB-S stream that the PayTV provider (Sky) has on B1 - and he was successful. The added bonus is that he provides the data in xmltv format..

So, the next problem was that the Audio I was feeding from the Myth box into the TV was really low, so I had the mixer wound all the way up so you could hear things - but playing videos was still really really quiet.. Turns out that the sound card is emitting line-level audio, but the TV is expecting something with a little more meat...

To solve this, I decided to purchase a simple Stereo Ampilifier kit from the local Radio-Shack-alike, Dick Smith Electronics. The K-5008 looked like it'd do the job nicely.

After building, then realising that I'd wired the 9V supply socket backwards, sadly, after I'd fried the chip... Then purchasing a replacement chip, I had a working Amp that meant I could finally wind down the volume in the software mixer, and actually have decent audio across the board within MythTV. Excellent.

I'm still pissed off that I managed to wire the socket wrong, when I swear I checked it at least three times before I soldered it...

The only downside, is that now it's actually possible to hear the 'muted' audio emerging from the line-in (for the TV tuner card)... It is very faint, and as long as you don't wind the TV volume up too far, you can't hear it...

[23:14] [/Hacking] [permanent link]

Serial Consoles (and other stuff)

Well, I'm sure we've all done this before, but I'll blog about it anyway, because I'm different, dammit. I did go one step further though.

Over the last couple of weeks, I've been productive at home, for the first time in a long while... I'm not sure what prompted it, but I think it has something to do with the fact I had to move my office and radio shack downstairs, to the cold room, next to the garage (where the rack of servers happens to be). This was prompted because the S.O. required the room I was using, since she wanted to create a spare bedroom/Her Space area. This is all fine, except that I had a lot of really heavy stuff in there, including two big desks, a filing cabinet, and an HF radio station.

Anyway, moved all this stuff, and started setting up the new room the way I wanted it, which meant running a new CAT5 cable, and getting antenna feed lines sorted out... (unfortunately, I'm going to be without a decent HF antenna until I can work out the best way to put one up in the new location...)

Through all this, I scavenged the 33.6k modem out of my old desktop, and lugged the machine half built as a firewall replacement down to the new office - these things prompted me to put them to use... Now the 33.6k is in my 'network' server (dns, dhcp, etc), being used as a modem with sendpage, so I can feed myself pager messages through the telco's TAP number. Pretty neat. I rummaged around and found the 40G drive that I couldn't decide what to do with, and stuck that in the mail/web server to use as a file store - it's now also a file server. Finished building the replacement firewall, and put it in production. (much better as a full woody, with a faster CPU, rather than that old 486dx40 with too little ram, and a really old insecure kernel).

The room was previously being used as storage of my collected hardware, so that stuff is now out in the garage... must get some shelving for them... Anyway, the cupboard in the room was also being used for storage, so I decided to pull out the two PowerMac 7200's, and putting the contents together as one system with a larger amount of RAM, and two HDD's. Installed this, and discovered that quik is pretty cool... no MacOS needed there. Inside these things is like a damned faraday cage, so the new machine got christened as faraday. (This now makes my home network have 5 out of the supported 11 architectures of woody.. i386, hppa, alpha, sparc, powerpc. - just need to get that mipsel box going now..)

Anyway, after doing all this, I decided I should get all these systems some upgraded, and packaged kernels... so after installing grub, and installing the respective kernels, they're all up to date. (and the root fs on the firewall is too small, so I had to purge the running kernel to get the new one on - I hate rebooting systems like this...)

Now, because I have a Stallion EasyServer II in the rack, with serial cables to everything in there, I decided to get all of these servers going with serial consoles.... a fiddle here, a tweak there, and a few reboots later, I can see each machine boot in a telnet window from my laptop upstairs...

Oh, and to top it all off, I decided to run a longer CAT5 serial cable up to the lounge, and have a DEC VT520 terminal there - great for nload on the firewall!

[22:42] [/Hacking] [permanent link]

On SMS Daemons...

Andrew, cheers for your suggestion. I'd actually looked at smstools prior to starting on this project, and decided that it was too GSM specific, and also lacking in functionality. I don't like the way it uses the filesystem for interaction either. The Plan is to make something generic enough to use as a general message delivery platform.

I do have a copy of the source sitting nearby, which I'm snarfing bits from occasionally.

Oh, and yes, it is fun to do anyway....

I've had a couple of suggestions to just use Python. I don't want to get into some sort of religious argument, so I'll just say that I prefer C when I want to do something substantial. I'm the sort of person that likes tools like Perl and Python for glue, quick hacks, or those little tools of convenience.

[21:34] [/Hacking] [permanent link]

C Sockets.

So, I've never spent a lot of time programming network applications. Sure, I've futzed around learning how you go about calling socket(), bind(), listen() and accept() or socket(), and connect(), then doing rudimentary data reads and writes, but I've never really spent the time learning how to make a really robust server daemon that uses non-blocking sockets.. Anyway, to cut a long story short, we've got this little CDMA modem here at work that's been purchased to use as an SMS sending tool, so that we're not relying on some internet service (which work really well when you're trying to send a message to the network admins that the internet connection is broken). This particular modem has no linux software, but it does have a nice AT command set that is available.

So I'm writing a daemon process that can collect messages in a queue, and make sure they're sent, and also collect any incoming messages to deliver them via email if it can work out who should get them.

It's a somewhat satisfying task, involving a large number of general programming tasks like socket, file and device IO, that are in themselves easy, but difficult to do right. All this adds up to a pleasurable learning experience.

I guess I should mention that I have spent a little time looking around trying to find something that can to the job for me, but everything seems to be somewhat bloated, or not general enough to apply to other types of devices. Oh, and there's that obligatory case of NIH syndrome that liw spoke of (OK, a very weak case).

I'm still debating though, whether or not to go down the threads with IPC track, or just create something monolithic with a good dose of careful non-blocking IO.

The latter feels more challenging...

[04:39] [/Hacking] [permanent link]

Making your Backup MX do recipient verification with Exim...

Well, in response to Kevin and Pascal's posts regarding backup MX's, I decided to actually do something about mine...

My backup MX does backup for my domain, as well as for a few friends and acquaintances. One such acquaintance happens to get one hell of a lot of spam traffic to his domain, which is directed at the backup MX... Me. He also happens to have recipient verification turned on. So, I end up with a gazillion messages in the queue on my backup MX.

So, I found a solution FOR EXIM *3* which gives the backup MX the ability to do recipient verification, without needing some static list of recipients available for a domain.

For those that want to do the same, here's the instructions.

To start with, you need an exim with the embedded perl interpreter, which isn't available with woody's exim. Source build time. Commands:

   apt-get build-dep exim
   apt-get install libperl-dev
   apt-get source exim
   cd exim-3.35

Edit src/EDITME, and uncomment the line: EXIM_PERL=perl.o

   dpkg-buildpackage -us -uc -rfakeroot
   cd ..
   sudo dpkg -i exim_3.35-1woody3_i386.deb

Right, now we have an exim package installed with the embedded perl interpreter enabled.

Second up, we need to make a few changes to exim.conf, so that we can do verification on domains we relay for. Here's a list:

1. Move all domains that we relay for, from the relaydomains directive to the localdomains directive [0].
2. Add "domains = !<relay domains>" to all existing directors

3. Add the following to the main configuration section:

   # Lets get perl going
   perl_at_start = true
   perl_startup = do '/etc/exim/relay_verify.pl'
   

4. Add the following to the directors section:

   # This is to verify local parts of relayed domains
   relay_verify:
     domains = <relay domains>
     driver = smartuser
     verify_only = true
     new_address = ${perl{relay_verify}}
   
   
   relay_deliver:
     domains = <relay domains>
     driver = smartuser
     transport = remote_smtp_relay
   

5. Add the following to the transports section:

   remote_smtp_relay:
     driver = smtp
     hosts = ${perl{relay_getmx}}
   

That's exim done. Now we just need to create the perl script that'll do the job for us. From above, create /etc/exim/relay_verify.pl with the following:

  #!/usr/bin/perl

  use strict;
  use Net::SMTP;

  sub relay_verify
  {
     # Get the local part and domain of the address we're relaying to.
     my $local_part = Exim::expand_string('$local_part');
     my $domain = Exim::expand_string('$domain');

     # Get our hostname for the HELO string below...
     my $hostname = Exim::expand_string('$primary_hostname');

     # Get the mx entries from exim, for the domain we're relaying for
     my $primarymx = relay_getmx();

     my $code = 451;
     my $msg = "Unknown error. Try again later.";

     if (defined $primarymx) {
        my $smtp = Net::SMTP->new($primarymx,
                                  Hello => $hostname,
                                  Timeout => 10,
                                  Debug => 0);

        if (defined $smtp) {
           $smtp->mail('');
           $smtp->to("$local_part\@$domain");

           $code = $smtp->code();
           $msg = $smtp->message();

           $smtp->quit;
        } else {
           # Cut our losses, if the primary MX isn't responding,
           # Accept anyway.
           $code = 250;
        }
     }

     if ($code >= 500) {
        return ":fail: $msg";
     } elsif ($code >= 400) {
        return ":defer: $msg";
     } else {
        return "$local_part\@$domain";
     }
  }

  sub relay_getmx
  {
     # Get the mx entries from exim, for the domain we're relaying for
     my $mxs = Exim::expand_string('${lookup dnsdb{mx=$domain}{$value}fail}');

     my $lowest = -1;
     my $primarymx;

     # Get the lowest valued MX entry.
     for my $entry (split("\n", $mxs)) {
        my ($pref, $host) = split(" ", $entry);

        if (($lowest == -1) or ($pref < $lowest)) {
           $lowest = $pref;
           $primarymx = $host;
        }
     }

     return $primarymx;
  }

The Code should be fairly self explanatory - in effect, if we can get a reply from the Primary MX for a domain we're relaying for to either fail or defer an arbitrary address, we pass that on to the system contacting the backup MX. If we get no reply in 10 seconds, we just accept the mail, since that's what a backup MX is supposed to do.

Setting the Debug option to 1 in the arguments to the Net::SMTP constructor, and using exim's -bh option, you can do some testing to see that this is working. (e.g.: exim -bh <some remote IP> )

[0]: I use files to list the domains my mailservers use, so I have things like:

  local_domains = /etc/exim/local_domains : /etc/exim/virtual_domains
  relay_domains = /etc/exim/relay_domains

[04:52] [/Hacking] [permanent link]