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.
Related
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.
I am running a simple UDP server using Nodejs's dgram module.
Relevant code is simply:
server = dgram.createSocket('udp4');
server.bind(10022,'127.0.0.1');
When I netstat on the local machine, using this:
sudo netstat -l
I see this entry:
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 localhost:10022 *:*
When I do a nmap from a remote machine using the IP address of the interface:
sudo nmap -sU -p 10022 192.168.7.171
I see this:
Nmap scan report for 192.168.7.171
Host is up (0.00032s latency).
PORT STATE SERVICE
10022/udp closed unknown
I have UDP client code running on the same machine which works fine when I use server.bind(10022,'127.0.0.1'), as done above. It does not when I use the real IP address assigned to the interface.
I also want to use the client code from a remote machine. So, when I use server.bind(10022, '192.168.7.171') in place of server.bind(10022,'127.0.0.1'), I would have expected to be able to send messages to the UDP process from a remote machine. I cannot. Interestingly the send function's callback, in the remote machine, does not return an error either.
How do I get the client code on the remote machine send message to the UDP server. All firewalls were shutdown for testing because I initially suspected it to be a firewall issue. In any event, both the machines are on a local intranet during testing.
The address parameter of bind() is optional, you can try to listen to all local addresses (0.0.0.0) by omitting it but still specify the port. Eg:
server.bind(10022);
Regarding the missing error UDP is by default a not reliable protocol, the transmission will be treated as successful when it's sent on the wire. UDP does not send back and acknowledgement packet, if you need a reliable channel you can use TCP.
I am trying to set up a test Cassandra 3.3 cluster on Ubuntu 15.10 with OpenJDK 1.8. The nodes can't talk to each other because Cassandra only listens on the loopback interface, as netstat shows.
tcp 0 0 127.0.0.1:7199 0.0.0.0:* LISTEN
tcp6 0 0 127.0.0.1:9042 :::* LISTEN
I have tried to insert my external IP address in /etc/cassandra/cassandra.yml.
listen_address: I tried the actual external IP address and leaving the field empty.
rpc_address: I tried the actual external IP address and 0.0.0.0.
I also tried modifying the following in /etc/cassandra/cassandra-env.sh.
JVM_OPTS="$JVM_OPTS -Djava.rmi.server.hostname=<actual external IP address>"
Between each change I stop the service, delete /var/lib/cassandra/data/system, and restart the service.
How does one configure the interface Cassandra listens to?
rpc_address is the address that external app clients will use to connect with Cassandra.
listen_address is the address that Cassandra will use to connect to other Cassandra nodes.
I would make sure that your nodes can communicate on that IP. Specifically, Cassandra will use port 7000 for inter-node communication (7001 if using node-to-node SSL). The best way to test this is with telnet. If it works, this is what you will see:
$ telnet 192.168.0.101 7000
Trying 192.168.0.101...
Connected to 192.168.0.101.
Escape character is '^]'.
So I would:
Figure out whether or not the nodes can communicate with each other on port 7000.
If they can, set the IPs that they see each other as in each cassandra.yaml's listen_address.
You'll probably also want to pick one of those as a seed node.
I am trying to understand a setup and have highly confused my self.
Say my box IP is xx.xx.xx.xx and the 127.0.0.1 is Local Loopback of my Linux box. Now when I do a netstat for a port I see below output:
tcp 0 0 127.0.0.1:11191 0.0.0.0:* LISTEN 9999/myexe off (0.00/0/0)
tcp 0 0 xx.xx.xx.xx:11191 0.0.0.0:* LISTEN 26998/anotherexe off (0.00/0/0)
What does the output basically means - since 127.0.0.1 and xx.xx.xx.xx refers to same box then does it means that two executable have binded and running at same port is same box - if so which binary would service the request if coming at port 11191 in my case?
Each of those is almost certainly a different interface and hence a different internet address. That is, 127.0.0.1 is typically the loopback interface. While presumably xx.xx.xx.xx is a real (ethernet) network interface. It is entirely possible to have two separate programs bound to the same port number on separate addresses. It is more common that a single program simply binds to the port number and the kernel in effect translates that into multiple binds, one for each interface's address.
See bind(2) and ip(7) manual pages for details. Specifically, INADDR_ANY is the pseudo-address that can be used by a server that wishes to bind the port on all interfaces.
See also the answer here under the first paragraph of the Linux subheading:
Socket options SO_REUSEADDR and SO_REUSEPORT, how do they differ? Do they mean the same across all major operating systems?
On some platforms, netstat can show you the processes that own the sockets. For example, on Windows, the -b switch displays executable names, and the -o switch displays process IDs. On Linux, the -p switch displays process information.
does it means that two executable have binded and running at same port is same box
Yes. Your netstat output includes process names, so we can clearly see that myexe is listening on 127.0.0.1:11191 and anotherexe is listening on xx.xx.xx.xx:11191.
if so which binary would service the request if coming at port 11191 in my case?
It depends on which local IP the connection arrives on. 127.0.0.1 is a loopback adapter, so only clients running on the same machine can connect to it. If a client connects to port 11191 on 127.0.0.1 specifically, myexe will handle the connection. If a client connects to port 11191 on xx.xx.xx.xx, anotherexe will handle the connection.
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