2

I don't know how to ask this because this is something new for me, I try telnet to my server and the output was like this:

Trying <IP>...
Connected to www.tjto6u0e.site.
Escape character is '^]'.

Then I tried netstat -a | grep www.tjto6u0e.site, found this:

Netstat screenshot.

I am using ubuntu and it was compromised before, but I have scanned my server and delete all infected files, including changing my default ssh port (22) to another one, but this one, I don't understand what is this about, is this normal or something that I should worry about?

I checked this IP 43.252.11.213 from netstat -an and redirected to a URL bulan.loket.co.id, I don't have any idea what is happening, is it meant that my site is copied to other domain?

  • 3
    For me it is unclear what you are asking, i.e. which of the information you show you worry exactly about and why and which not. Also, to see if these are really a problem one need to know what the task of the server is and what activity is normal and it can also help to know what is the IP you connect from, what is the IP you connect to, what port you connect to ... . Also, why did you tag it as man-in-the-middle when you never said anything like this in your question? – Steffen Ullrich Aug 22 '17 at 4:45
  • 1
    So now, you do know why your db is compromised. security.stackexchange.com/questions/167880/… – Baptiste Aug 22 '17 at 6:14
  • 8
    That's not a URL, it's a domain name (which might be used elsewhere as part of a URL, but not here). – Toby Speight Aug 22 '17 at 7:19
  • 3
    @MartinSchröder We don't know what OP was trying to accomplish. Using telnet to connect to an arbitrary port to see if it accepts connections is reasonable (and mostly harmless); using telnet to actually log in to a system is, indeed, horribly bad practice. For the former use case, ssh is basically useless; for the latter, ssh is absolutely the way to go. (After reading Secure Secure Shell...) – a CVn Aug 22 '17 at 9:51
  • 7
    So, you have multiple compromised computers ... please get skilled help. Apparently you're not able to stop it alone. – user155462 Aug 22 '17 at 9:54
26

is this normal [that the my server login reports a different domain]

Of course not.

I am using ubuntu and it was compromised before

Well ... you shouldn't have continued using it.

but I have scanned my server and delete all infected files

Virus scanners on an already compromised machine are pretty useless. (Even more useless than at other times).

including changing my default SSH port (22) to another one

  1. Does this matter?
  2. Does this matter if you're using telnet?

And why you are using telnet!?

I checked this IP 43.252.11.213 ... and redirected ...

You also should never have called this in a browser.

is it meant that my site is copied to other domain?

No. Well, maybe, but that's not the problem. Until proven otherwise, assume that someone else has full control over your server (including all content, but also all other things the computer can do).


What you should do now:

  1. Try to find out how your server got compromised and fix that (the probability is low that you find the reason). Also change all passwords, get used to regular software updates, SSH keys, fail2ban and so on.
  2. Wipe your server clean and start again by installing an OS, all necessary software, and all configs you need/want.
  • 2
    @RampertoPPasaribu Telnet won't help you with finding the attacker. – deviantfan Aug 22 '17 at 3:30
  • 10
    @RampertoPPasaribu If there were a feasible simpler option have a (hopefuly) clean server, I would have told you already. ... – deviantfan Aug 22 '17 at 3:33
  • 13
    A clean install is the only solution. But before that, you should not administrate a server without knowledge about security, because you are bound to get abused again. So first, learn about basic security for a server, do not install needless services/daemons, do not blindly use methods you found on the web (stop using telnet!), RTFM of the tools you use (SSH) and configure them correctly. The first step towards security is RTFM: you must know the implications of what you do with your server. – A. Hersean Aug 22 '17 at 8:44
  • 1
    @A.Hersean, thank you very much as I said earlier I am new on this, I know I never should allow login using password, but the dev guy, this one guy asked to enable the login by password since he always tried generating ssh keys but unable to login to the server, and another guy asked to disable the firewall because he is testing something, I forgot to enable the firewall, two days later got DDos attack :D – spacetrack Aug 22 '17 at 10:29
  • 4
    Minor comments: (a) You were not DDOS (look up the definition). (b) SSH with a password is possible but not recommended: you have to be very careful with the passphrases the users choose. (c) I would never give access to one of my servers to someone not skilled enough to use SSH with a public key (he just has to generate a key pair and to give you the public key). (d) You could just have added a rule to the firewall to accommodate the needs of you teammate, after having checked what were those tests about. – A. Hersean Aug 22 '17 at 12:01
6
Trying <IP>...
Connected to www.tjto6u0e.site.
Escape character is '^]'.

The hostname given after Connected to is just the DNS resolution of the IP you gave telnet. The only thing it can really show is a mis-configured DNS - though I suppose if it used to be configured correctly that may be a sign of unauthorised access.

The netstat output (without the use of -n) also does a DNS resolution so it makes sense you see the same name there.

The summary being that what you show isn't sufficient evidence of unauthorised access without more context - but its not evidence there wasn't either.

  • Sure, that might be the right domain - but then this question wouldn't exist. And sure, this doesn't mean root access to the server itself - except OP said already that he knows he's compromised (except he believed it's solved already). – user155462 Aug 22 '17 at 10:57
  • 2
    My point wasn't regarding if it was the name the OP wanted the IP to resolve to - just that the resolution wasn't evidence in of itself of a compromise of the machine using that IP address. – user133831 Aug 22 '17 at 11:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.