I am working on a API Server hosted on a Windows Server 2019 instance of AWS EC2 (t2.micro version). I recently had to update the API after which I have been unable to connect from Chrome on my local machine although I am able to connect locally using http://localhost (it does return a DLG_FLAGS_SEC_CERT_CN_INVALID error but if you accept this you can navigate to the website and retrieve the JSON data).
In addition, I am now no longer able to use the VS2019 publish functionality as it returns a ERROR_DESTINATION_NOT_REACHABLE (same error is returned when I try to validate the connection). Finally, if I try to connect via my ReactJS app I get a timeout error.
What I have tried:
I have checked the EC2 public IP address
I have checked the username and password (I can use RDP to connect to the same machine)
I am able to ping the EC2 machine from my local machine
I have checked the EC2 security groups, it allows TCP 80, 443
I have attempted connections with the firewall off (and also added exception rules)
I've run netstat to get what ports are listening (possibly an issue, full file at end)
I have restarted the machine
I have stopped and started the machine (updating the public IP address afterwards)
Anyone with any thoughts, been working on this for a number of hours now and no closer.
Thanks.
NETSTAT output:
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:135 EC2AMAZ-CFSF2TM:0 LISTENING
RpcSs
[svchost.exe]
TCP 0.0.0.0:445 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP 0.0.0.0:1801 EC2AMAZ-CFSF2TM:0 LISTENING
[mqsvc.exe]
TCP 0.0.0.0:2103 EC2AMAZ-CFSF2TM:0 LISTENING
[mqsvc.exe]
TCP 0.0.0.0:2105 EC2AMAZ-CFSF2TM:0 LISTENING
[mqsvc.exe]
TCP 0.0.0.0:2107 EC2AMAZ-CFSF2TM:0 LISTENING
[mqsvc.exe]
TCP 0.0.0.0:3389 EC2AMAZ-CFSF2TM:0 LISTENING
TermService
[svchost.exe]
TCP 0.0.0.0:49664 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP 0.0.0.0:49665 EC2AMAZ-CFSF2TM:0 LISTENING
EventLog
[svchost.exe]
TCP 0.0.0.0:49666 EC2AMAZ-CFSF2TM:0 LISTENING
Schedule
[svchost.exe]
TCP 0.0.0.0:49667 EC2AMAZ-CFSF2TM:0 LISTENING
[spoolsv.exe]
TCP 0.0.0.0:49668 EC2AMAZ-CFSF2TM:0 LISTENING
[mqsvc.exe]
TCP 0.0.0.0:49669 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP 0.0.0.0:49673 EC2AMAZ-CFSF2TM:0 LISTENING
[lsass.exe]
TCP 127.0.0.1:80 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP 127.0.0.1:443 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP 127.0.0.1:5357 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP 127.0.0.1:5985 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP 127.0.0.1:8172 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP 127.0.0.1:44363 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP 127.0.0.1:47001 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
[svchost.exe]
TCP [::]:135 EC2AMAZ-CFSF2TM:0 LISTENING
RpcSs
[svchost.exe]
TCP [::]:445 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP [::]:1801 EC2AMAZ-CFSF2TM:0 LISTENING
[mqsvc.exe]
TCP [::]:2103 EC2AMAZ-CFSF2TM:0 LISTENING
[mqsvc.exe]
TCP [::]:2105 EC2AMAZ-CFSF2TM:0 LISTENING
[mqsvc.exe]
TCP [::]:2107 EC2AMAZ-CFSF2TM:0 LISTENING
[mqsvc.exe]
TCP [::]:3389 EC2AMAZ-CFSF2TM:0 LISTENING
TermService
[svchost.exe]
TCP [::]:49664 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP [::]:49665 EC2AMAZ-CFSF2TM:0 LISTENING
EventLog
[svchost.exe]
TCP [::]:49666 EC2AMAZ-CFSF2TM:0 LISTENING
Schedule
[svchost.exe]
TCP [::]:49667 EC2AMAZ-CFSF2TM:0 LISTENING
[spoolsv.exe]
TCP [::]:49668 EC2AMAZ-CFSF2TM:0 LISTENING
[mqsvc.exe]
TCP [::]:49669 EC2AMAZ-CFSF2TM:0 LISTENING
Can not obtain ownership information
TCP [::]:49673 EC2AMAZ-CFSF2TM:0 LISTENING
[lsass.exe]
UDP 0.0.0.0:123 *:*
W32Time
[svchost.exe]
UDP 0.0.0.0:500 *:*
IKEEXT
[svchost.exe]
UDP 0.0.0.0:3389 *:*
TermService
[svchost.exe]
UDP 0.0.0.0:3702 *:*
FDResPub
[svchost.exe]
UDP 0.0.0.0:3702 *:*
FDResPub
[svchost.exe]
UDP 0.0.0.0:4500 *:*
IKEEXT
[svchost.exe]
UDP 0.0.0.0:5353 *:*
Dnscache
[svchost.exe]
UDP 0.0.0.0:5355 *:*
Dnscache
[svchost.exe]
UDP 0.0.0.0:57259 *:*
FDResPub
[svchost.exe]
UDP 127.0.0.1:57258 *:*
iphlpsvc
[svchost.exe]
UDP [::]:123 *:*
W32Time
[svchost.exe]
UDP [::]:500 *:*
IKEEXT
[svchost.exe]
UDP [::]:3389 *:*
TermService
[svchost.exe]
UDP [::]:3702 *:*
FDResPub
[svchost.exe]
UDP [::]:3702 *:*
FDResPub
[svchost.exe]
UDP [::]:4500 *:*
IKEEXT
[svchost.exe]
UDP [::]:5353 *:*
Dnscache
[svchost.exe]
UDP [::]:5355 *:*
Dnscache
[svchost.exe]
UDP [::]:57260 *:*
FDResPub
[svchost.exe]
Your netstat shows the instance is listening on 127.0.0.1:80, 127.0.0.1:443 and 127.0.0.1:8172 (aka "localhost") for HTTP, HTTPS and Web deploy respectively. If you look at a working service like RDP its binding to 0.0.0.0:3389 (aka any/all IP's). Thats basically your issue - IIS is not listening on the servers network adapter / localhost is only available, well locally.
You can test this theory by rdp'ing to the server, and trying to connect via your instances public IP instead of localhost. My guess is this will fail, but localhost and 127.0.0.1 will still work. You would also be able to connect to web deploy locally - obviously thats a terrible/pointless idea - but same issue (can use putty or such to make a connection to prove its listening though).
You can just go into IIS and modify the site bindings in IIS Manager snapin- the IP address column should only contain * (When editing a binding, set the IP address to "All Unassigned"). I would guess they are currently localhost or 127.0.0.1?
Worth noting in theory IIS should backup its config at each change, so you should have a record of the old configuration in \windows\sytem32\inetsrv\history\cfgHistory_NNNNNNNNNN directory
The current IIS config is stored in inetsrv\config\applicationHosts.config. You can edit this file directly - but i would advise powershell or appcmd as they deals with the quirks of 32/64bit.
If you edit the config directly (stop the w3svc service first) remember to use a 64bit editor (like the builtin notepad.exe) to edit the 64bit config files (dont mess with the contents of SysWOW64\inetsvc - only use System32 even for 64bit files - its the "bitness" of the editor that determines which file Windows will modify)
NOTE Messing with applicationHosts.config can break IIS. Make sure you backup first, and i would strongly recommend using Powershell or AppCmd unless you fully understand the 32/64bit quirks (ie you make a change but it appears to be ignored).
See AppCmd (take a look at the backup/restore and the set binding examples) - https://learn.microsoft.com/en-us/iis/get-started/getting-started-with-iis/getting-started-with-appcmdexe
Also, if you edit the config, this is the reference: https://learn.microsoft.com/en-us/iis/configuration/
Related
When a client connects to a server using TCP, a new socket is created for the TCP stream. Does the connection remain on the same port the connection was made or does it get changed to some other port?
The new socket is an application-level concept introduced because each established connection needs a unique file descriptor (also distinct from the listening file descriptor), which maps to, but isn't the same as, a TCP session. The session itself is identified by the combination of source and destination address and port. The source (client) port is usually chosen at random, while the destination (server) port is the listen port. No additional port is allocated.
The server use the same port to listen and accept new connection, and communicate to the remote client.
Let's me give you an example, (in linux system):
First, start a http server by python：
xiongyu#ubuntu:~$ sudo python -m SimpleHTTPServer 500
Serving HTTP on 0.0.0.0 port 500 ...
Second use nc command to connect to the http server, here we start two client by:
xiongyu#ubuntu:~$ nc 0.0.0.0 500
Use netstat to see the netstate of port 500:
xiongyu#ubuntu:~$ netstat -natp |grep ':500'
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN 54661/python
tcp 0 0 127.0.0.1:51586 127.0.0.1:500 ESTABLISHED 57078/nc
tcp 0 0 127.0.0.1:51584 127.0.0.1:500 ESTABLISHED 54542/nc
tcp 0 0 127.0.0.1:500 127.0.0.1:51586 ESTABLISHED -
tcp 0 0 127.0.0.1:500 127.0.0.1:51584 ESTABLISHED 54661/python
You can see, the http server use port 500 to LISTEN for the client, after a new client connected to the server, it still use the port 500 to communite with the client, but with a new file descriptor .
The socket associated with the new descriptor returned by accept on the server will use the same port on the server side of the connection as the original socket (assuming "normal" definitions where the client initiates the connection). The new socket will have a different client port number (the remote port from the server's point of view).
I tried to scan ports with nmap to one of my servers in the same LAN and I got many ports opened:
Host is up (0.058s latency).
Not shown: 993 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
110/tcp open pop3
143/tcp open imap
993/tcp open imaps
995/tcp open pop3s
3306/tcp open mysql
so, I logged into the server to see what services are listening and there are only few of them:
netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1205/mysqld
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 32225/sshd
tcp6 0 0 :::22 :::* LISTEN 32225/sshd
tcp6 0 0 :::4118 :::* LISTEN 1264/ds_agent
Why then, those ports are listed in the nmap and how I can close them?
Add the --reason option to your Nmap scan to see information about each port. This may help reveal when responses are coming from a different source than the target. For instance, if you see 22/tcp open ssh syn-ack ttl 60 but 110/tcp open pop3 syn-ack ttl 63 then based on the ttl difference, the responses were likely coming from different targets. You say you are on a LAN, so this is less likely.
It's also possible that the ports were open when you scanned, but the process that was listening was turned off by the time you logged in to check. Can you confirm the same ports are still open? Can you check logs for a mail server service starting and stopping?
One more possibility would be a rootkit. This is malware that carefully hides its behavior from on-host diagnostic tools like netstat. This possibility is unlikely based on the ports you listed, which are consistent with a mail server instead. Malware would be unlikely to listen on so many commonly-used ports, but it is worth mentioning as a general case.
situation: I need to broadcast from client using UDP from some free port, then to accept tcp connection on client from server on the port with the same number, but TCP. That's why I need to listen (and bind) to this port BEFORE broadcasting. The port cannot be const, because I can have multiple clients running on one machine.
So here some questions, which can help me to make this situation clearer:
If I made sendto from unbinded UDP socket, is it binded to any free port and all next sendto messages will go from this port, or each time the port will be chosen for a new message?
Can I ask system to reserve some free port for me? (I need to reserve two ports with the same numbers for UDP and TCP connections)
I'm sure there is a known way to handle these situations, what is it?
1)If I made sendto from unbinded UDP socket, is it binded to any free port and all next sendto messages will go from this port
Yes.
or each time the port will be chosen for a new message?
No.
2) Can I ask system to reserve some free port for me? (I need to reserve two ports with the same numbers for UDP and TCP connections)
That's what happens when the auto-bind occurs. You can do explicitly by binding to port number zero, but it isn't necessary. It also does not guarantee that you can bind both UDP and TCP to the same port number.
3) I'm sure there is a known way to handle these situations, what is it?
You've found it. Let the auto-bind happen.
I've found some answers on stackoverflow
You can bind to 0 port, that is specified it struct semaddr_in. That will allow you get an unused port for your type of connection. It is not defined to be free for other types of connection.
Look at #remy's answer at Bind to any port available
Yes, they can because headers are specified for UDP or TCP protocols. So the machine can tell one from another.
See Can TCP and UDP sockets use the same port?
If you bind to 0 port you'll get ability to listen to it before calling sendto
I launch JBoss 7 on Centos6 using JDK7.
When I check what port is opened I see the following UDP port:
netstat -ntulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 :::43676 :::* 2460/java
The port is changing its value each time I restart JBoss.
Where and why the UDP connection is configured?
I use standalone\configuration\standalone.xml and I can not find any UDP configuration there.
Added
I have commended out management-native socket-binding and use only management-http socket-binding.
I still can see opened UDP port and I want to close it.
Please help.
JBoss used an ephemeral port for clustering. An old version of the documentation for "JGroups" is here.
Another possibility is that it is the JMX port used for the JBoss management interface.
I'm trying to connect to a service, and to debug it, I ran
netstat -nap | grep LISTEN
The results should rows of two types :
tcp 0 0 127.0.0.1:8020 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:57140 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:11000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN
unix 2 [ ACC ] STREAM LISTENING 4512 -
unix 2 [ ACC ] STREAM LISTENING 9760 -
I have 3 questions :
1) I want to connect to the process running on 127.0.0.1 --- how can I do this externally ? I have read elsewhere that 127.0.0.1 processes are only allowed to communicate with other localhost processes.
2) What is the difference between the "tcp 0" netstat records and the "unix 2" ones ? Im somewhat naive about networking, so feel free to overexplain this one :)
In short, your process is bound to a loopback interface which cannot receive packets from an external network. You'll need to reconfigure the process bound to port 8020 to bind to an external interface to be able to connect to it from another host.
The long answer is that the two addresses you site (127.0.0.1 and 0.0.0.0) are both special in certain ways, and it is useful to understand what you're seeing.
Addresses in the 127.0.0.0/8 Internet Protocol address block (of which 127.0.0.1 is one) are reserved for use internally on a host. See rfc5735 for details, but there's nothing special about these addresses except that all IP hosts use the same rules and aren't setup to route these addresses outside a host or router.
On your computer, you'll usually see a special "loopback" network interface that has 127.0.0.1 assigned.
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
This interface is special and never connected to an external network. It is used when a program wants to connect to a service on the local machine as 127.0.0.1 will almost always be configured as an active network interface. Packets will only arrive on this interface if they are sent from a local process.
The other address you site, 0.0.0.0 is special and usually represents all IP addresses mapped to any network interface on your computer. When a program wants to listen for connections arriving on any network interface or IP address, it will bind a TCP/UDP port to 0.0.0.0 to listen for connections.
In your case, however, you're reporting netstat output listing 0.0.0.0 on lines describing TCP sockets in a LISTEN state. In this case, netstat is listing sockets listening for connections and using 0.0.0.0:* as a place holder for the foreign address field of it's output. In this case, 0.0.0.0:* signifies that the socket is waiting for a connection from any host.
Regarding your question on "tcp 0" vs. "unix 2", these are the first two columns of your netstat output. A look at the column headers from your netstat command is useful:
# netstat -nap | head -2
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
What you're reporting as "tcp 0" simply means a socket using the TCP protocol has zero bytes in the received queue waiting for the program connected to this socket to consume. Similarly, "unix 2" is what's called a unix socket with two bytes waiting in its receive queue for the connected process to consume.
TCP sockets are part of the TCP/IP stack that can be used locally or across IP networks for processes to communicate. UNIX sockets, on the other hand, are simpler and only used for what's called IPC or inter-process communication which only happens between two processes both running on the local system, and there's no networking involved (no addresses and ports anyway). UNIX sockets are considered to be more efficient than TCP sockets, but they are obviously more limited in function. On UNIX-like systems UNIX sockets are implemented as a file on the file system of a special "socket" type that both processes using the socket read and write to as a communication channel.
1) Without binding it to 0.0.0.0, you can still access the service through a tunnel. This is similar to using a proxy as David Schwartz mentioned. There's a few assumptions I'm making for this example:
The server is running a service bound to 127.0.0.1:8020, we'll call it 'myservice'.
The server is running OpenSSH server 'sshd' on the default port of TCP 22, and the user can log in with the username 'myusername'.
The client is running a system with OpenSSH client installed.
The server is accessible via the IP address of 10.20.30.40.
On the client, SSH to the server with the following command:
ssh -L 12345:localhost:8020 myusername#10.20.30.40
Once you log in, minimize the SSH window. In another window on the client, run netstat to find listening ports. You should see 127.0.0.1:12345, just like on the server.
On the client, connect to the service on 127.0.0.1:12345. You should now be connected to the 'myservice' instance on the server, even though you made the connection to the client's local loopback interface.
The trick here is that SSH is tunneling a listening socket on the client to the listening socket on the server. I've made the port numbers different for clarity.
1) You would either need to modify the server to bind to a publicly accessible address (or 0.0.0.0) or run a local proxy to handle the connection.
2) TCP connections use the TCP protocol, the one used for connection-oriented traffic on the Internet. UNIX connections use a strictly local protocol that is much simpler than TCP (because it doesn't have to deal with dropped packets, lost routes, corrupted data, out of order packets, and so on).
1) You cannot (if you mean from another machine - 127.0.0.1 is localhost and by definition you can only connect to it from the local machine
2) The first column shows the domain of the sockets - tcp are tcp sockets and unix are unix domain sockets.
And as for the answer to you question 3 ;-)
3) 42