Wandering Thoughts archives

Why the (Sun) JVM is irrelevant to me

In this entry, Ian Bicking responds in part to Tim Bray's On Beyond Java -- the JVM and comments as an aside that he's indifferent to the JVM. I want to expand on Bicking's aside, because I am in much the same boat as him. Here's the pragmatic reasons why the (Sun) JVM is pretty much irrelevant to me:

• it's a 46 megabyte download (for the JDK; the JVM alone is smaller).
• ... with an install script that mangles my systems.
• ... that my Linux distribution can't include. (It is not alone in this; I don't think any Linux distribution includes the Sun JVM.)
• this means my distribution can't integrate it into things like Apache, or ship programs that depend on a JVM.
• since it's not part of my distribution packages, I don't automatically get security alerts and upgrades for it.

As Ian Bicking also mentions, what this boils down to is that Sun has made it a pain for me (and open source people in general) to have anything to do with the JVM. Open source people generally don't involve themselves with things that are pains, so in turn there are no 'must have' JVM-based open source programs that would make the JVM actually important to us (the closest is parts of Open Office 2, generally written by Sun programmers).

So the JVM stagnates in the open-source world, sitting quietly in its little corner. Nobody uses it, nobody needs it, and the big reason for a lot of people to even bother with a copy of the JVM is to make Java applets play in their browser. I suspect that more Linux machines have a copy of Macromedia Flash than a JVM.

And in the future, I suspect that more machines will have a copy of the Mono .NET environment than will have a JVM. Certainly there's strong signs that people are developing attractive open source applications with Mono, and (absent patent concerns) distributions can actually ship the runtime.

(Due to the heroic work people have done to create usable free JVMs and to get useful free programs working with them, the JVM situation is changing a bit; a modern Fedora Core distribution actually includes a number of useful Java-based things. I suspect that by now this is too little, too late.)

A thing I don't like about Linux

So much for my nice uptime. As I was browsing along in Firefox, the X server crashed. (The crash was for the usual reason: trying to display some characters in some fonts gives the X server a signal 11 heartburn. Ever once in a while, I'll stumble over a web page that nails just the right combination.)

A crashed X server doesn't take the system down on the spot, but on Linux it makes the console pretty much unusable because the X server is the only thing that can take the hardware out of graphics mode. This means I can't read anything on the console, even if I restart the X server, which makes the machine useless from a practical perspective.

Rebooting my machine is somewhat time-consuming process, lengthened this time around because all of my filesystems were well overdue to be fsck'd, and it was not exactly what I'd been planning to do late this afternoon. Plus, you know, the whole thing about losing my entire session in a ka-blam.

So I really wish Linux would recover more gracefully from X server crashes.

Now that it's happened, I'm not too angry; really, a reboot was overdue anyways. The machine's kernel is seriously out of date and missing various sorts of networking goodies that I'd been leaving out of my kernel configurations until I learned better semi-recently. Since I've had to reboot already, I might as well build a modern kernel with all the goodies and switch to it; I've already lost the nice 315 days and 4 minutes uptime.

I still wish it'd been up to me when exactly to schedule the reboot, as opposed to X server bugs.

Sidebar: cleaning up from an X server crash

It's possible to get console input back and thus to do blind typing, if you have the 'Magic SysRq' key enabled. This is Alt plus SysRq (aka 'Print Screen') plus various special keys; here, the must useful is 'r', to take the keyboard out of the raw mode that the X server's left it in. Once the keyboard's out of raw mode, you can flip screens with Alt-Fn (although you probably won't see anything useful) and use Ctrl-Alt-Del to do a reasonably orderly reboot and so on.

(Other useful keys: 's' to sync, 'u' to unmount filesystems or make them read-only, and 'b' to reboot the system. See Documentation/sysrq.txt in the kernel source code for a full list and more information. Note that 'b' reboots immediately, without sync'ing.)

A number of distributions default to disabling Magic SysRq. Make sure that if your /etc/sysctl.conf mentions kernel.sysrq that it sets it to a value of '1', not '0'. (This is also /proc/sys/kernel/sysrq.)

However, logging in over the network from another machine is usually the much easier way to deal with things.

Iptables modules that aren't in the iptables manpage

I recently discovered that not all of the iptables extension modules are documented in the iptables manual page, at least the versions installed on Debian Sarge or Fedora Core 4; they're only documented in the netfilter.org extensions HOWTO here, or sometimes not even there.

I care about this because this means there's interesting things I could do with iptables that I can't find out by reading the manpage. So for my future reference and anyone else's use, here's a quick summary of the 'missing' extension modules, based on what's in Debian Sarge and Fedora Core 4.

The non-manpage iptables modules documented in the extensions HOWTO are:

• connlimit, which appears to be what netfilter.org calls iplimit.
• ipv4options: match various IP v4 options, like source routing. (Debian only)
• psd: attempt to detect port scans. (Debian only)
• quota: supports byte transfer quotas. (Debian only)
• recent: keep track of and match various sorts of recent packets.
• string: match strings anywhere in a packet. (Debian only)
• u32: match arbitrary bytes in a packet. (Debian only)
• IPV4OPTSSTRIP: strip all IP obtions from an IPv4 packet. (Debian only)
• NETLINK: send rejected packets to userspace via a netlink socket. (Debian only)
• SAME: remap source addresses down to a narrow range.
• XOR: simple XOR-based packet encryption. (Debian only)

(Note that some extension modules, although mentioned in the manpage, are much better documented at netfilter.org. One example is the fuzzy match extension.)

Pretty undocumented (in neither the manual page nor netfilter.org's extensions HOWTO):

• comment: adds comments to any rule; see here. (Fedora Core 4 only)
• hashlimit: a more general limit matcher; see here. (Fedora Core 4 only)
• pool and POOL: obsolete; see here. (Debian only)
• osf: match based on passive OS fingerprinting. See here. (Debian only)
• rpc: some sort of matcher for RPC packets. Apparently obsolete; see here.
• sctp: matches sctp packets. See here.
• set and SET: match and modify sets of IP addresses; see here, apparently. You'll need an additional utility or two. (Debian only)
• IPMARK: mark a received packet based on IP address; see here. (Debian only)
• TARPIT: capture and hold incoming TCP connections using no per-connection resources. See here.
• TCPFLAG: passively monitor connections for how lagged they are. See here. (Debian only)

At the user level, extension modules are implemented as shared libraries in /lib/iptables, so your system's iptables may or may not support all of these netfilter extensions. Even if your iptables knows about an extension, your kernel may not support it.

You can get basic argument information for any extension from iptables by using either '-m <WHAT> --help' for match extensions or '-j <WHAT> --help' for target extensions.

(Disclaimer: all of these URLs worked when I wrote this entry, but netfilter.org may have shuffled some of them by the time you read this. If you can't find something, look through all of the repositories in their patch-o-matic.)

Stopping brute-force ssh scans the easy way

I recently stumbled over this blog entry on a nice, easy way to stop brute force ssh scans, so it's time to spread this knowledge around.

If you've got an ssh daemon exposed to the Internet, you know about the brute force ssh scans and password guessing attacks. The real problem with them is the sheer volume, which creates log clutter (and system load) as they spew login failures and unknown users all over your logs.

(If brute force ssh attacks give you security ulcers, get passwords that follow even basic password security rules, because the scanners pretty much only try obvious simple passwords. Anyone who gets compromised by one should be hideously embarrassed.)

In theory the easy way to stop them is to block ssh access from all the networks that don't need it (even tcpwrappers will do; a few 'connection refused' and the scanners go away). Unfortunately, figuring what such places are (or aren't) can be a slog, and it can change over time, and your users can lynch you when you get it wrong.

Thus the easy way to stop brute force ssh scans is to rate-limit incoming ssh connections; this keeps the log spam down to a couple of entries. Linux iptables can do this using the recent and state match modules, like so:

# iptables -A INPUT -p tcp --dport 22 -s <good-IP> -j ACCEPT

[repeat for all of the netblocks and IPs you want know you want to accept ssh from all the time.]

# iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
# iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP

(This blocks people after 3 new ssh connections within 60 seconds. If you prefer different numbers, adjust --seconds and --hitcount to taste.)

Both lines are necessary because you can only give one of --set or --update, and --update does nothing if the source IP address is not already being tracked by the recent module.

You can see the state of this ruleset in /proc/net/ipt_recent/SSH (or whatever name you gave it). Entries can be removed by writing '-IP.AD.DR.ES' into the file, and the entire thing can be purged by writing 'clear'. The ruleset only keeps stuff on the most recent 100 IP addresses, which shouldn't normally be a problem (this is controlled by the kernel module ipt_recent's ip_list_tot module parameter).

Documentation on the recent matcher is here. It is not yet in the iptables manpage, at least in the versions in Fedora Core 4 and Debian Sarge.

Naturally, the kernel side of this has to be built for your kernel, which is yet another reason to always enable NAT et al in your kernel configuration. (I failed to do this on the system where the brute force scanners most annoy me, thereby insuring they will be annoying me for a while more yet.)

(It turns out that I am late to this particular party; people have been talking about this since at least February of 2005.)

Updated December 16th: corrected the iptables usage; my original version had iptables -I instead of iptables -A, with entertaining havoc ensuing.