Hi everybody,

I get a log message from sshd every five minutes looking like this

<pre>
Apr 19 13:55:29 server1 sshd[5701]: Did not receive identification string from x.x.x.x
Apr 19 14:00:29 server1 sshd[5730]: Did not receive identification string from x.x.x.x
</pre>

What is really strange is that x.x.x.x is one of the machines own IP address. Moreover, the interface that handles x.x.x.x is configured to block all non-imcp traffic (with iptables). (Note: due to another external firewall, x.x.x.x is not accessible from the internet)

I've been trying to find any local process that could be responsible for making these connections, but I can't find anything suspicious.

Anyone got an idea what might be going on?

Thankful for any help,

Soren

assuming you have ethereal or wireshark(console versions of both)

y.y.y.y should be the IP of your good interface, x.x.x.x above relates to your bad interface.
Watch that for a few minutes to see if the machine is making requests to the server, if so you might be able to go more verbose and see what exactly it's passing. Maybe it's a rouge heartbeat app of some kind(do you run any network process monitor app).

Blocking all except icmp on x.x.x.x isn't going to work as this is outbound trafic, your log is telling you that x.x.x.x is trying to connect to your other IP, and the reply from your other IP is getting dropped on the way back thanks to your iptables script.

You could also try
If something breaks, you've just found your culprit(and have kernel logs to see a little more info).

Thanks for your elaborate response.

While reading your comment about network process monitors I suddenly realized that I compiled the newest version of my intrusion detection system with the "open ports" scan option enabled. After turning off the scan, the messages disappeared. God, am I stupid?

I'm still a little puzzled that the IDS managed to make connections from x.x.x.x to the ssh server. I forgot to mention it in my last post, but x.x.x.x and y.y.y.y are on two separate networks and there is no route from x.x.x.x to y.y.y.y (or the other way around). This was why I thought that the firewall on x.x.x.x should take care such problems. Being curious of nature I'll take a deeper look on this using wireshark (the software is new to me but looks very interesting) as soon as I get the time.

Thanks once more,

Soren

Just to answer my own question: I found that the traffic to x.x.x.x:22 was sent from x.x.x.x. The traffic was, however, sent over the loopback interface which was why it wasn't stopped by the firewall.