This can also happen with Memcached, Redis, and for that matter SQL databases. If you find it on your servers, you should be very, very alarmed. (Assume that any attacker with arbitrary access to any of these owns the box. [+]) One easy-ish way to make sure you don't inadvertently leave a port open is to use iptables and deny inbound connections to everything but 22, 80, and 443 by default.<p>This is part of the Slicehost VPS setup guide that PickledOnion wrote back in the day, and it's still one of the first things I do when I get a new box. (Typically right after locking down SSH with a key requirement.)<p>Edit to add:<p><a href="http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-page-1" rel="nofollow">http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-p...</a>
<a href="http://articles.slicehost.com/assets/2007/9/4/iptables.txt" rel="nofollow">http://articles.slicehost.com/assets/2007/9/4/iptables.txt</a> <-- make sure you change the port 30000 on the SSH to whatever you use on your boxes<p>[+] You might think "Well, that requires the existence of both a vulnerability in the server and a local privilege escalation exploit", but in practice, you can assume that the attacker has access to both of these. They also probably aren't trying to get into <i>your</i> box, specifically -- your box is merely one of the several thousand Redis instances on the Internet that they're firing e.g. a specially corrupted Unicode string to get a buffer overrun on, at which point they will -- in a mostly automated fashion -- run metasploit (or similar ratware) and turn that into a root shell.