svc: bad direction 268435456, dropping request

When I first looked on google for more clues, I saw a (recursive) suggestion to google on "kernel: svc: bad direction" and you'll get a ton of hits.

And yes, indeed you do get a lot of hits, but nothing really clear to say why this is occurring. First off, this appears to only affect Linux and possibly any other systems that shares code (or if this code was borrowed), as this line of code appears in the Linux kernel:

doujima:/usr/src/linux-2.6.17$ grep 'bad direction' net/sunrpc/*.c
net/sunrpc/svc.c: printk("svc: bad direction %d, dropping request\n", dir);

Well, here's a short summary of what I found and a fix.

Basically I was able to stop these kernel warnings from showing up by disabling or firewalling UDP/RPC services using supervisory calls that use portmap, such as nfsd, statd, and mountd. This kernel message is generated when a malformed service call packet is received. The malformed packets are typically from the Internet and the most typical one was not even intended to be a service call, it was intended for a WINDOWS PROGRAM! Most likely a Windows Messenger Service packet landed on your Linux box from a random computer probe. The message is a warning/informational, there is no reason for alarm. See pop-up spam for details of one of these possible culprits.

To stop these warnings from showing up, disable all services you don't need, or make sure your machine is not listening to these SVC calls. Firewalling these ports off from external attackers will do the trick. Or making sure the RPC/SVC call handlers are not listening to the public internet, if that machine also is your router.

If you can't do that, you may also change the port these services run on. The easiest thing to try is to restart all your NFS services (NOT by rebooting! Kill them individually and restart them in order.) The ports are pseudo-random, and chances are, it will pick another port to register to the port mapper. When it does, you'll be fine until next reboot.

If you need more deterministic results, you could force ports for these programs programs. For user-space RPC services, most of them you can change on the command line - supply "-p 31523" options to mountd, "-p 31263 -o 31264" to statd and "-p 31524" to quotad. For kernel based lockd, you'll need to pass different parameters to the kernel upon boot or module options. For the kernel option, you need to edit your boot loader config to append lines like these to change the port:

# Kernel 2.6.x - kernel command line option
lockd.nlm_udpport=31222 lockd.nlm_tcpport=31222

# Kernel 2.4.x - kernel command line option
lockd.udpport=31222 lockd.tcpport=31222

# For kernel modules - modules.conf
options lockd nlm_udpport=4001 nlm_tcpport=4001

This will use different ports and reduce chances for a clash. Make sure you choose different ports for each service. Also, firewall off port 111 (portmap) and 2049 (nfsd) while you're at it. If the attack truly was after the Linux box, it'd either be more random, port wise (which would make the search space too large to handle - so unlikely they'd do this.) More likely the attacker should be trying to attack the portmapper and nfsd since they're more "well-known" ports.

Otherwise, so far, these messages are purely informational and benign - no known attacks as of yet cause these warnings. The Linux kernel is basically notifying you that someone send a misformed packet with questionable source to your machine. The Windows exploit one obviously does no harm except spoil log files. It's merely trying to talk to RPC services in the wrong language, so-to-speak.

Other interesting information:
268435456 (decimal) is 0x10000000 (hex) which is the location for 256MB.
Other possible payloads for these junk packets - these connects could also caused by a 'p2p' virus program trying to find and communicate to other infected machines. But most likely it's spam and can be ignored.