On Mon, September 21, 2015 15:37, m.roth@5-cent.us wrote:

Gordon Messmer wrote:

...

...

...

In other words, the hostkeys would be identical.

I think what the error indicates is that a client tried to connect to SSH, and the host key there did not match the fingerprint in the client's "known_hosts" database.

...

It seems to me that someone attempted an ssh connection while spoofing our internal address. Is such a thing even possible? If so then how does it work?

In the situation as you've described it, probably not.

It would be best to go to your logs themselves for the full

...

log entry and context, rather than relying on a report that summarizes log entries.

Looks like someone trying to break in. You *are* running fail2ban, are you not? If not, you need to install and fire it up, now.

Yes, we run fail2ban. No, fail2ban did not catch this because the number of attempts was below the threshold for a single IP.

The logwatch message reported is incomplete. Our address was the destination address. The source address was not reported by logwatch but it was logged in the syslog and it was not an internal address. It did belong to an organisation that bills itself as "a leader in enterprise security. . .".

We have contacted them requesting an explanation of the probe. It could have been an error on someone's part. I suppose.

We see a lot of cracker traffic from Chile, Romania, Russia and the Ukraine. China was such a PITA that eventually we simply cut off that range of addresses from reaching us by any ports other than 25/80/443 so we do not even see it any more, except via proxy. Taiwan is nearly in the same boat and Vietnam is next in the queue.