SPIT: Where do we stand?

SPAM over Internet Telephony (SPIT) is a strange beast: Everybody knows it is a threat, but in real life SIP installations, it has hardly been observed. In other networks it is not uncommon, Skype needs to police its users to get a grip on abuse, and all Instant Messaging networks have to deal with IM spam, and once they offer voice capability, SPIT as well.

So, SPIT over SIP hasn’t been a problem so far. After all, there are millions of SIP devices out there replacing PSTN phone service. Why?

  • In many end-user installations, SIP is just a replacement for the old analog last-mile technology. There may be SIP accounts provisioned into these devices (ATAs, hardphones), but the user does not see them. Nor do they know their own SIP AoR. None of the people calling them knows their SIP AoR. It wouldn’t help them anyway, as these networks are usually not reachable via SIP from the Internet
  • The same is true for IP enabled PBXs: They talk SIP on the inside, and maybe to other
    PBXs in other offices of the same company (usually via some QoS-enabled VPN). In rare cases, people build SIP trunks to upstream carriers or even establish manual cross-links to the PBXs of other companies.
  • Fully-featured SIP installations which implement inter-domain SIP routing as standardized by the IETF in RFC 3263 are the exceptions. They are the enthusiast’s Asterisk installations, some enterprising VoIP operators (perhaps even using User-ENUM) and that’s it.

Summary: the vast majority of SIP devices out there is not reachable over the public Internet.

Corrolary: There is no SPIT problem, as the target audience is too small to make SPIT profitable.

This is some sort of vicious circle: Operators don’t want to open up their SIP ingress elements, because they fear SPIT. On the other hand, it is hard to build defenses against SPIT, whose characteristics and weak points you don’t really know. And it is completely impossible to prove that certain clever anti-SPIT measures work if you can’t test them in practice.

There has been no shortage on clever ideas concerning SPIT defenses. Academic papers galore, internet drafts, and even products claiming to solve the problem.

We are still in the same vicious circle.

Will RUCUS help?

System Administration

HP DLxxx, iLo2, XEN and remote consoles

As a general principle, servers with PC-style BIOS suck. If you ever worked with a real server with native support for a serial console, then anything else feels like a crude crutch.

HP servers with iLo2 are no exceptions.

At least unless you’re unwilling to shell out additional money for the feature packs.

You get a crude vt100 emulation during the boot sequence, but once the operating system starts, this falls back to a real serial device. The trick is thus to configure grub, the kernel, and the gettys in a way to get consistent console access all through the boot process.

Now add XEN and and root in an encrypted LVM volume to the mix and things start to become nasty. So here is my solution, for all those weary souls googling for a recipe for Debian (etch):

title Xen 3.0.3-1-i386-pae / Debian GNU/Linux, kernel 2.6.18-6-xen-686
root (hd0,0)
kernel /xen-3.0.3-1-i386-pae.gz dom0_mem=128M com1=115200,8n1,0x2f8,3
module /vmlinuz-2.6.18-6-xen-686 root=/dev/mapper/vg_main-lv_root ro console=ttyS0 xencons=ttyS0
module /initrd.img-2.6.18-6-xen-686

And don’t forget to note these parameters in the comments in /bot/grub/menu.lst unless you want to manually add them after each kernel upgrade. i.e.:

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=dom0_mem=128M com1=115200,8n1,0x2f8,3

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=ttyS0 xencons=ttyS0

If you’ve forgotten that, you can save yourself the trip to the server room by manually editing the boot config using grub’s edit functionality.

Enabling login via ttyS0 is then just a matter of
T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
in /etc/inittab, and ttyS0 in /etc/securetty.

Once you enable ssh access in iLo2, you can reach the console of your server from any *ix shell via a simple ssh command.