Home / server / Questions / 857445
Accepted
Nick_K
Asked: 2017-06-23 22:52:33 +0800 CST

Man in The Middle Attack, or something else?

  • 772

I was wondering if someone could help me out with this problem.

We have a webservice that is available only through https:// port 443.

Using netstat I see that there is particular ip that tries to connect to the server.

For example, all the other connections connect to the server from their port to the server's 443 port (normal https behaviour).

This particular ip: 192.0.73.2, tries to open connection from remote port 443 to a local port. (Its state is always TIME_WAIT, it goes away and then it comes back as TIME_WAIT after minute or so.

I am reporting this ip in the open because it has been reported here before: https://www.abuseipdb.com/check/192.0.73.2

There is a CISCO firewall that protects the company network and my system admin told me that he could not find any hits from that ip to the server. But the netstat tool reports otherwise.

Can you offer me any suggestions? Or tell me what is going on? Thank you!

That is what the netstat command shows:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 server_ip:32884         192.0.73.2:443      TIME_WAIT
tcp6       0  69000 server_ip:443           remote_ip:65045     ESTABLISHED
tcp6       0      0 server_ip:443           remote_ip:20467     TIME_WAIT
tcp6       0      0 server_ip:443           remote_ip:55430     TIME_WAIT
tcp6       0      0 server_ip:443           remote_ip:65248     ESTABLISHED

Thank you all for helping me out solve this problem. It was a call to gravatar after all

ssl

4 Answers

  1. Probably there's no-one trying to connect from 443 to a local upper port. Connections usually originates from dynamic port range (49152 through 65535). Is the 32884 always 32884 or is it actually always something within that range?

    The IP address 192.0.73.2 hosts wordpress.com and gravatar.com etc. It's way more likely that your server is connecting to that server to gather some information. We couldn't know the details, because we don't know your site and what's its purpose.

    • 3
  2. Best Answer

    A normal hit to 192.0.73.2 redirects to https://en.gravatar.com/. This is definitely not MITM attack.

    Your website is using a module of gravatar and it is trying to connect to its server to gather data i.e the User avatar to be used for comments. You need not worry about it and since it dies after TIMED_WAIT it is not able to connect to the server.

    You should not be worried since the IP is not detected from the firewall. It would be best to fix the module trying to access gravatar and allow access to it.

    • 3

  3. This is an outbound connection, your server is connecting to a remote address, not the other way around. That usually translates to: you have some background service that sends data somewhere. To work out what the process is, use netstat (with root permissions):

    netstat -tulpn

    If you don't see it in the output, try (also as root):

    lsof -i tcp

    That will show you all the connections with the relevant process name. Find your outgoing connection, look at the process.

    As an example, my server regularly maintains an outbound connection to a foreign https port, because I have Nginx Amplify running, and it needs to report server statistics to it.

    You can see an example of this here, in my server's current output (redacted):

    joe@testbed~$ sudo lsof -i tcp
COMMAND     PID      USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
amplify-a  6355  user-nam   14u  IPv4  7657189     0t0  TCP testbed.avx.local:36970->ec2.us-west-1.compute.amazonaws.com:https (ESTABLISHED)

    My server there is making an outbound connection from a random port to a https port, just like yours. Run the commands, find the process, then you can decide if it's malicious or not.

    • 2

  4. The IP 192.0.73.2 ended up in my firewall also today. It is indeed from gravatar.

    The reason for the IP getting caught is because the TCP connection had both syn and fin flags and my firewall adds those connections to a list. From https://www.juniper.net/documentation/en_US/junos/topics/concept/tcp-syn-fin-flags.html

    Both the SYN and FIN control flags are not normally set in the same TCP segment header. The SYN flag synchronizes sequence numbers to initiate a TCP connection. The FIN flag indicates the end of data transmission to finish a TCP connection. Their purposes are mutually exclusive. A TCP header with the SYN and FIN flags set is anomalous TCP behavior, causing various responses from the recipient, depending on the OS

    • 1