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?

Anders
  • 64,406
  • 24
  • 178
  • 215
spacetrack
  • 99
  • 1
  • 8
  • 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 04:45
  • 1
    So now, you do know why your db is compromised. https://security.stackexchange.com/questions/167880/hundreds-of-users-creating-mail-ru-and-projectgold-ru-accounts-on-my-application/167888#167888 – Baptiste Aug 22 '17 at 06:14
  • 1
    hi @Baptiste it was on different server :D – spacetrack Aug 22 '17 at 06:21
  • Yeah I am not good at explaining things, and I thinks the best answer is by @deviantfan – spacetrack Aug 22 '17 at 06:22
  • 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 07:19
  • telnet? srsly? Use ssh. – Martin Schröder Aug 22 '17 at 09:39
  • 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](https://stribika.github.io/2015/01/04/secure-secure-shell.html)...) – user Aug 22 '17 at 09: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 09:54
  • @MartinSchröder well what info could I get from ssh? I don't have any trouble login using ssh, I am sorry I am new on this, and we don't have IT security, just a small company – spacetrack Aug 22 '17 at 10:20
  • @user155462, the other one was not an attack, just the application package we used for a forum got many spams and to solve the problem just ban the users and delete related posts – spacetrack Aug 22 '17 at 10:24

2 Answers2

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.
Toby Speight
  • 1,214
  • 9
  • 17
deviantfan
  • 3,854
  • 21
  • 22
  • yeah I am just want to know where the IP is pointing to, that's why I am using telnet, I have 0 knowledge on security :D. – spacetrack Aug 22 '17 at 03:28
  • 2
    @RampertoPPasaribu Telnet won't help you with finding the attacker. – deviantfan Aug 22 '17 at 03:30
  • and Thank you @deviantfan ,rebuilding my server has been thought before but I want to avoid this method since this server is being used for a project, if there are any other options would be great for me – spacetrack Aug 22 '17 at 03: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 03: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 08: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
  • @RampertoPPasaribu I know the pain - but if it is your server, and you can decide, get rid of that stupid bunch. ... (btw. a firewall does not prevent DDOS attacks. It might make them less of a problem, sometimes) – user155462 Aug 22 '17 at 10:58
  • 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
  • What you should do now, #3: Disable telnet and *only* ever log in using SSH. – Doktor J Aug 22 '17 at 15:31
  • @A.Hersean thanks I have already implement those you mentions on my server – spacetrack Aug 23 '17 at 06:21
  • @DoktorJ haha yeah I will disable telnet, thanks for the comment – spacetrack Aug 23 '17 at 06:22
  • @user155462 just meet this dev guy, asked him to generate another key and failed, I walk to his desk and check his PC, well the reason it always failed was because after generating the key, he moved the key to other directories, don't know why he did that but now it solved :D – spacetrack Aug 23 '17 at 07:30
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.

user133831
  • 161
  • 1
  • 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