The kernel should not generate messages at the behest of the Internet

September 7, 2014

Here is a kernel message that one of my machines logged recently:

sit: Src spoofed 98.247.192.43/2002:4d4d:4d07::4d4d:4d07 -> 128.100.3.51/2002:8064:333::1

Did I say 'a message'? Actually, no, I meant 493 messages in a few days (and it would be more if I had not used iptables to block these packets). Perhaps you begin to see the problem here. This message shows two failures. The first is that it's not usefully ratelimited. This exact message was repeated periodically, often in relatively close succession and with no intervening messages, yet it was not effectively ratelimited and suppressed.

(The kernel code uses net_warn_ratelimited() but this is clearly not ratelimited enough.)

The second and more severe failure is the kernel should not default to logging messages at the behest of the Internet. If you have a sit tunnel up for 6to4, anyone on the Internet can flood your kernel logs with their own version of this message; all they have to do is hand-craft a 6to4 packet with the wrong IPv6 address. As we've seen here, such packets can probably even be generated by accident or misconfiguration or perhaps funny routing. Allow me to be blunt: the kernel should not be handing this power to people on the Internet. Doing so is a terrible idea for all of the usual reasons that giving Internet strangers any power over your machine is a bad idea.

These messages should not be generated by default (at any logging level, because there is no logging level that means 'only log messages that are terrible ideas'). If the kernel wants to generate them, it can and should be controlled by a sysctl or a sysfs option or the like that defaults to off. People who really really want to know can then turn it on; the rest of us will leave it off in our usual great indifference to yet another form of Internet badness.

(Since I haven't been this quite this harsh on kernel messages earlier, I'll admit it: my attitude on kernel messages has probably steadily gotten stricter and more irritated over time. I should probably write down my thoughts on good kernel messages sometime.)

Sidebar: what this message means

A 6to4 encapsulated packet has two addresses; the outside IPv4 address and the inner IPv6 address. The kernel insists that the inner IPv6 address is the IPv4 address's 6to4 address. Here the outside source is 98.247.192.43 but the inner 6to4 address in 2002::/16 is for the IPv4 address 77.77.77.7. You can get a similar message if the destination address has a mismatch between the IPv4 address and the 6to4 IPv6 address.

(To decode the 6to4 IPv6 address, take off the leading 2002: bit and then convert the next four hex octets to decimal bytes; each byte is one digit in the address. So the source is claimed to be 4d.4d.4d.07 aka 77.77.77.7. We can follow the same procedure for the destination address, getting (hex) 80.64.03.33 aka decimal 128.100.3.51, which matches the outer IPv4 address.)

Written on 07 September 2014.
« A DTrace script to help figure out what process IO is slow
Systemd's fate will be decided by whether or not it works »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 7 00:44:19 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.