1

Out of curiosity, I ran Netstat on my Windows PC, and I found some strange entries like:

xx-fbcdn-shv-01-amt2:https
edge-star-mini-shv-01-frt3:https
mil04s03-in-f10:https
xx-fbcdn-shv-01-amt2:https
fra16s25-in-f14:https
lu7:http
40:https
mil04s04-in-f12:https
wb-in-f188:https
ec2-52-86-85-106:https
db5sch101101419:https
bam-6:https

What are these/how can I tell what these are?

1
  • 1
    If you want to see what executables on your machine are responsible for each of these connections, along with the fully qualified name of the remote host, run netstat -f -b Mar 21, 2017 at 20:06

4 Answers 4

3

You can get more useful information from the Netstat command by adding the -f and -b parameters, like this:

netstat -f -b

According to the help (netstat -?) the -f switch:

Displays Fully Qualified Domain Names (FQDN) for foreign addresses.

And the -b switch:

Displays the executable involved in creating each connection or listening port. In some cases well-known executables host multiple independent components, and in these cases the sequence of components involved in creating the connection or listening port is displayed. In this case the executable name is in [] at the bottom, on top is the component it called, and so forth until TCP/IP was reached. Note that this option can be time-consuming and will fail unless you have sufficient permissions.

Put the two together and you'll see what processes are creating each connection and the full remote host name.

To aid in investigating the executables (and the connection's they're making) use Microsoft's Process Explorer. When you run the program you'll be presented with a list of everything running on your system, like this:

enter image description here

Then, to see the connections made by an executable, double-click it and have a look at the TCP/IP tab: enter image description here

1
  • You're welcome. I updated my answer to give you an additional resource for investigating the connections made by processes on your machine. Hope it helps. Mar 21, 2017 at 21:16
2

The other answers clarify this pretty well in most cases, but I'd like to elaborate on the 40 case - eg. showing an entry that's just a few digits and nothing else, nothing alphabetical.

For me, the weird one was entries that only showed up as a single decimal number. It's not entirely obvious what these are and not something that's easy to Google either. I have a lifetime of networking experience and this still got me even.

For example I had an entry like:

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    10.10.10.10:7890       38:https               ESTABLISHED

Running netstat -n to show the IP, I realized it was one of my own GCP servers - which made me wonder even more what was going on, thinking perhaps reverse DNS or even one of my DNS servers or something was configured incorrectly or something. Reverse DNS looked fine, although it should've clicked once I saw the reverse DNS.

I had looked into this before and I don't remember if I came to a satisfactory answer, so when I saw it today I stumbled on this thread and also tried with -f - that's when it clicked!

With -f it showed (actual IP changed):

TCP    10.10.10.10:7890         38.255.255.255.bc.googleusercontent.com

Aha! 38 is the first part of the subdomain and quite often the hostname of a system is considered to be the first part, eg. for myfileserver.westoffice.mycompany.com the hostname would be myfileserver.

GCP in this case, returns 38.255.255.255.bc.googleusercontent.com for the reverse DNS lookup, this Windows' netstat follows this normal convention thinking 38 is the hostname of the machine and thus only shows 38 in the list.

I am now curious / suspect as to whether this is a/the reason AWS uses - (eg. an AWS hostname like this would be ec2-54-255-255-255.compute-1.amazonaws.com) in their auto-generated hostnames instead of the . that GCP uses.

For those knowledgeable-yet-paranoid in networking, seeing a listing like this almost immediately makes you do a double-take.

Even though you didn't specify -n to show IPs, any connection that netstat lists that fails a reverse DNS lookup will get shown as a numeric IP address - so you're not 100% sure that you're looking at just part of a DNS name and not part of an IP (although the DNS name in this case contains the IP it points to, it's still technically printed as a DNS name here).

Also, IP addresses do not have to be represented in x.x.x.x format; for example CloudFlare's 1.1.1.1 DNS server can also be represented as 16843009, any IP address with a 0 part in it can have it dropped, eg 10.0.0.1 and 10.1 are equivalent, etc. So 38 here could technically be 0.0.0.38, which is obviously a non-usable IP address.

If you had 38 as an entry in your hosts file pointing to a certain IP, that could also show in netstat like this.

One of the OP's entries was indeed 40 and would've been a victim of this. All the other addresses the OP listed wouldn't have made me wonder, but a number alone is a bit of a unique case.

I blame Google/GCP for having their automatic hostnames/reverse DNS setup to use . instead of - or otherwise. It ignores at least as old as if not older than the web regarding DNS and hostnames of specific machines/services.

I also blame Microsoft's netstat implementation for generally assuming this convention is always adhered to, especially on the public internet. I would've perhaps truncated the domain to the length of the field with -f still allowing the full domain to be shown instead of assuming the first subdomain is always a hostname and truncating at the first . - this is what the version of netstat on Ubuntu seems to do on Linux and avoids this confusion, either way the reverse DNS lookup is still happening. If you really needed/wanted to just see the first part as a hostname, then maybe add a -h option for that or something.

I also perhaps blame the DNS standard for not disallowing digits as the first character of a subdomain; though it's understandable as the way DNS works, domains and subdomains aren't really treated any differently thus if this had been a rule when DNS was initially designed, you couldn't have 123plumbing.com as a domain name.

2
  • It was kind of a rule when DNS was initially deployed, but then 3Com wanted a domain name and 3com.com happened and it wasn't a rule anymore. Jul 13, 2023 at 7:40
  • Of course it was 3com.. gives shady eye towards a nearby 3com switch! Though tbh, I've been around long enough that if 'tis be the lore, I should've known.. also long enough that this shouldn't have made me raise an eyebrow, but it definitely did the first time I saw it, especially since it's far less often I'm looking at the output of a Windows netstat.exe versus the same on anything nixlike whose output isn't willynilly truncated to the 'hostname' AKA first dot Jul 19, 2023 at 10:29
0

You noted that "ec2-52-86-85-106 turned out to be 52.86.85.106 which is Amazon, even though I wasn't connected to it." A reverse DNS lookup on the IP address returns ec2-52-86-85-106.compute-1.amazonaws.com, i.e., that is the fully qualified domain name (FQDN) that will be returned, because there is a PTR DNS record that associates that FQDN with that IP address. But you could have accessed www.example.com in your web browser and the example.com domain name could have an A DNS resource record that associates that FQDN with the IP address 52.86.85.106. The 52.84.0.0 to 52.95.255.255 address block is assigned to Amazon by the American Registry for Internet Numbers. Amazon uses it for its Amazon Web Services (AWS).

Let's say I purchase the domain name example.com from a domain name registrar. I now want to host my website at www.example.com and decide to use AWS to host my site. I configure DNS servers for my domain name to point to the IP address AWS has provided to me for the server hosting my site. Let's say that address is 52.86.85.106. So if you put www.example.com in your web browser, your system connects to 52.86.85.106. But now you issue a netstat command on your system. You see a connection to 52.86.85.106, if you use netstat -an or you see ec2-52-86-85-106 if you omit the n argument to the command. So it may not be obvious to you, unless you issue an nslookup command on www.example.com, that your browser connection to my website is why you see ec2-52-86-85-106 in the results from the netstat command you issued.

In regards to the 1e100.net domain name you mentioned in another comment, as you discovered, the 1e100.net domain belongs to Google. 1e100 is scientific notation for 1 googol, i.e., 1 raised to the power of 100, which is 1 followed by one hundred zeros. Google uses the domain name for its servers. If you had recently accessed a Gmail account or or performed a search using google.com with a browser on your system, you might see that domain name returned in your results.

Another netstat command option is -o which will show you the process ID (PID) of the process that established the connection. You can then use the Windows Task Manager to link the PID to an application that you are running, e.g., Chrome, Firefox, Microsoft Edge, etc., by clicking on the details tab in the Task Manager to see the PID.

0

Look at mine, been under targeted attack from hackers the last 2-3 years. No I found one of the is connted to a chinese created trojan and stuff. I just block them, delete it. Or setup a honeypot/sandbox like kali linux and reverse the attack. enter image description here

1
  • 1
    As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Apr 12 at 13:40

You must log in to answer this question.