2

In 2017, I was running a local website on my own dedicated server in a professional data center. FreeBSD. Installed by me remotely. Maintained carefully by me. No other human users than myself. I was the only one with SSH access or indeed any kind of admin access to the machine.

One day, I got an e-mail from my watchdog script which was constantly inspecting the access log for the sshd. I had made it e-mail me immediately whenever a login attempt (successful or not) was not 100% certain to be me.

I got very upset when I read the hostname and noticed that it was not my ISP. However, it was still a local ISP, only not the one I had. I do not remember whether the IP address belonged to my actual ISP, but I think that may have been the case. (More details follow.)

By my reasoning, it would be far more likely for somebody to compromise my machine from across the world rather than just logging in from a consumer ISP nearby. I would have been certain that it was a compromise if the successful login attempt was made from shadyisp.ru or something. Of course, they could simply have used a compromised local (to me) PC to proxy themselves through, but still, the fact that it was local made me unconvinced that I had truly been compromised.

Also, there were no failed sshd login attempts prior to it (or at all, ever, basically), so it was clearly not a brute-force attack. The username was non-standard and the password extremely long and complicated. If they deleted the contents of the log, they did it unbelievably, impossibly quickly. And if so, they left the successful one... which would make no sense. Unless the entire point was to just mess with my mind...

At the time, I freaked out and spent hours looking through and comparing some sort of logs. I don't remember exactly what those were, or what I found, but something (other than pride and wishful thinking) eventually convinced me that, yes, this was indeed me, because the IP address and/or other data matched up. But still, the hostname was from a different local ISP... How is that even possible?

I stupidly did not save any notes to myself about this, nor the logs or the hostname/IP address of the potential compromiser. Only years later have I thought back about this and again become uncertain: maybe it was actually a compromise after all, and my reassuring conclusion back then was false? Maybe I was so ashamed of being server-compromised for (to the best of my knowledge) the first time in my life, that I convinced myself in spite of this "indisputable proof"?

I kept running the machine for quite some time after, and did not notice anything odd whatsoever. No deleted or corrupted data. No further logins. No 100% CPU usage. No blackmail or mocking e-mails linking me to a download archive of my entire server contents. Which of course says very little; maybe they had somehow figured out the username/password by some entirely different means and then just made one attempt to see if they could log in, they could, and then just left forever, content that they were able to do this?

What could possibly explain this "freak occurrence"? Sorry for not giving more info, but this is all I remember.

Improve this question
6
  • 3
    Too much unknown here so one can only speculate. For example your own ISP and the other local ISP could be resellers of a larger ISP. Or IP space has moved between the ISP for some other reasons - and there is always some delay that changes are propagated using DNS. So its not about actual "lying", instead caching of entries for some time and thus the possibility to be out of date with recent changes is part of how DNS works.
    – Steffen Ullrich
    Feb 26 at 21:08
  • 3
    You should change your thinking about the incident more technically: "how could hostname resolution show an unexpected host when the IP is valid?" Once your thinking goes there, then you have many different possibilities, and a lot of those possibilities are benign. Lookups don't "lie", they produce unexpected results.
    – schroeder ♦
    Feb 26 at 21:43
  • 1
    Out of curiosity, did your watchdog script monitor your logs in real-time or periodically? Also, how did it determine if it was 100% you or not?
    – user284677
    Feb 27 at 19:52
  • 1
    @Spyros Close-to real time. We're talking every few seconds. And it checked the hostname if it contained a specific string.
    – Cathan
    Feb 28 at 0:01
  • @Cathan Could someone have found out your hostname and used it as their hostname or a substring of it?
    – Solomon Ucko
    Feb 28 at 0:51

1 Answer 1

Reset to default
1

The discussion is fairly right. But it's more important to understand what you're seeing than why you're seeing it.

Your connection request comes in as a tcp/ip packet, in packet header is the IP address source. The server does a reverse DNS lookup of that IP address to attempt to determine the hostname of the source. Using the DNS servers it's configured to use. This is not a valid way of "authorizing a source", it's good as a reference but the IP address is the important bit.

As the discussion states, it's not lying;

  • Its potentially just old data in the DNS servers.
  • Or there may be other agreements for what network you're using at that time, for service shared with the local ISPs. This may be done with smaller "mom and pop" ISPs.
  • Your IP address (aparently must not be being static) may change regularly, and your local ISP maybe just acquired the IP range.

This is a lot of speculation as to why, but using reverse DNS to determine legitimate source host domain name is not perfect. You should not consider it authoratative unless you own the domain name itself, the DNS server data is under your control, and/or up to date.

If you're so security concious (which is good!), you should record the local IP address you've got using a site like whatismyip.org (or you can even ask google "what is my ip") when you make a connection attempt. You can then verify that against the audit record of the connection attempt of the IP address directly, not the reverse DNS result. Keeping an audit log of the connection attempt from your (client) side, and a audit log record of the connection attempt from the server side.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .