Netscan detected from host - Help!

SSH is not the only service that your server could have been broken in through.

Any service that you expose to the internet is a potential entry for an attacker. One commonly exploited service are web apps (like a BBS, blog or CMS). Are you running something like that? Is there anything unusual in the logs for any of the internet-facing services you're running?

I have apache2 and tomcat6 running a website I made. The logs for both have plenty of errors but none that would make me think of an attack.

Plus none of those services should be able to use port 22, right?

I'm not 100% sure I like that abuse report. I think what it is trying to say is that there were packets received with source (yourIP, 22) and destination (theirIP, 80). That seems rather weird: originating a packet from port 22 requires root, which is unnecessary to accomplish a TCP connection to someone's HTTP port.

It is possible (I just checked with scapy to make sure!) but why? (And how?)

Was it the same destination both times? If so, running 'tcpdump' (or perhaps adding a iptables rule with no action, just matching their dest IP, so that there's a packet counter) might help see wtf is going on.

Also, unless they include more information about the exact composition of the packets, it's possible they're connecting to YOUR port 22 from THEIR port 80, so check your ssh logs :-)

The destination ips are always different, but they all belonged to a company named Hetzner Online (which I believe is the one which made the abuse report).

Could it be that someone sent spoofed tcp packets to my server @ port 22, then my server tried to reply and that reply was interpreted as a netscan by the recipients?

My site is quite often the target of synfloods and other DoS attacks (It's a popular multiplayer game with audience being mostly teenagers I get lots of vandalism).

I've now blocked port 22 (moved ssh to another port).

Anything's possible. It might not be a bad idea to set up an IDS of some sort (e.g. snort) to monitor your outgoing traffic, just so you know what your "emissions" are.

Also, make sure you keep sshd somewhere below port 1024 – otherwise, in the event your sshd dies and someone has non-root access to your machine, they could bind a doppelganger sshd there. (Rare, but possible. Why chance it?)

@hoopycat:

Anything's possible. It might not be a bad idea to set up an IDS of some sort (e.g. snort) to monitor your outgoing traffic, just so you know what your "emissions" are.

I'll have a look at snort, however I'm worried, what do I do if I find nothing? Lack of evidence of my linode being guilty doesn't mean anything, so what do I do about the ticket? :\

@hoopycat:

Also, make sure you keep sshd somewhere below port 1024 – otherwise, in the event your sshd dies and someone has non-root access to your machine, they could bind a doppelganger sshd there. (Rare, but possible. Why chance it?)

Thanks for the advise, I had set the port to a number above 1024 without thinking of that.

If you have no evidence that you're the source of the packet in question, and you've checked your system against a last-known-good state (liberal use of etckeeper and a long archive of my own incremental file-based backups helps me with this), then I suppose the ticket is bollocks. It might be worthwhile to tweak your iptables rules to make sure they're set to "DROP" instead of "REJECT" for invalid inbound traffic, just to be sure.

Also, wouldn't hurt to consider dropping all traffic to/from the other provider's network ;-) (robtex.com can help find other IP ranges.)