I've been poking around the internet trying to get an answer to this one but so far I've only seen it as "normal" behavior.
I have a fedora 29 host configured to send rsyslog messages over the default 514 port. That works as intented and has been for some time now. I had a client notice that the host would "listen" on an ephemeral port that appears to change with each reboot:
ss -tulnp | grep 46852
udp UNCONN 1536 0 0.0.0.0:468520.0.0.0:* users:(("rsyslogd",pid=676,fd=15))
also:
lsof -i :46852 -P
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd 676 root 15u IPv4 24836 0t0 UDP *:46852
Anyone know why rsyslog is doing this? It appears to be default behavior, and I'm not worried about it as the port can't be hit externally (firewall prohibits it) but just wanted to understand it. I also couldn't find anything in the rsyslog docs that talked about it.
Thanks!
This is just observed behavior I am curious about.
This isn't something that rsyslog is doing, but rather your OS.
Clients are assigned port numbers (random and sequential) by your operating system, as part of the sequence of system calls, that create a network connection. For example TCP and UDP typically use an "ephemeral" port for the client-end of a client–server communication.
These port numbers are - as you said - called "ephemeral" because they are valid only for the life of the connection and have no special significance.
As to why ephemeral ports are used.. I don't know. Maybe someone on ServerFault or Network Engineering can answer this question.
From my understanding ephemeral ports can be used either temporary or private. So if a service (temporarily) needs a port it can use an ephemeral port. After the service has done it's requests and has timed-out for some time, the port is released and can be used by some other service. This way a service doesn't block a port even though it doesn't even use it, or just frequently uses it.
Related
I've created an Oracle Cloud infrastructure compute instance running Ubuntu 20.04. I am trying to open port 19132.
As per another question I found
Opening port 80 on Oracle Cloud Infrastructure Compute node
I've created a public subnet which has an internet gateway and added ingress rules for port 19132 (in the security lists)
netstat looks good
netstat -tulpn
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:19132 0.0.0.0:* 1007/./bedrock_serv
I installed ufw and added rules to allow 19132 but I still can't connect to it from the outside world. Can anyone point out where I am going wrong?
I got the same issue on the Oracle cloud.
Here is what works for me;
First, install firewalld
sudo apt install firewalld
Then open the port in public zone;
sudo firewall-cmd --zone=public --permanent --add-port=19132/tcp
Finally, reload firewalld
sudo firewall-cmd --reload
Looks like you need to have a Public IP configured on that VM for it to be reachable from the internet.
Please look at
https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/managingpublicIPs.htm
For an instance to communicate directly with the internet, all of the following are required:
The instance must be in a public subnet.
The instance must have a public IP address.
The instance's VCN must have an internet gateway.
The public subnet must have route tables and security lists configured accordingly.
You haven't mentioned anything about the route table. If missing add to it a route with destination=0.0.0.0/0 and target=the Internet Gateway.
Two questions come to mind:
You have specified two rules, one for TCP and one for UDP.
Your netstat shows that something is listening for UDP traffic. Is
there also something listening on TCP or are you using UDP only for
the test?
Can you tell us anything about the traffic characteristics
on this port? I'm asking because if it is UDP traffic the only way
for connection tracking to work is to track the source/dest IP and
port. Since the port will not be present in fragments, the traffic
will be dropped. This could be happening on the ingress or egress
side. To verify, you could create test ingress/egress rules for all
UDP traffic to/from your test IP.
Since your ingress rules are stateful, the egress rules shouldn't matter but it wouldn't hurt to double check them. If none of these things work, you might try a tool like echoping to get more insight into whether or not the traffic is having trouble on the ingress or egress side.
Please check the order of your IPtables rules. Could you post the following command's output for Input chain.
sudo iptables -S INPUT
I have seen Iptables rules as the single prominent reason for these issues.
Regards
Muthu
I think you have to allow user or add user who can connect like this:
create user 'user'#'publicIP' identified by 'password';
grant all privileges on *.* to 'user'#'publicIP' with grant option;
flush privileges;
Here publicIP can be '0.0.0.0' or your system IP address.
Don't use '0.0.0.0' as it is open to all, I have faced various breaches on my GCP machine which leads to account block.
I am trying to follow this tutorial. You do not have to read whole tutorial, my small goal is to create firewall rule on Google Compute engine and connect to using telnet.
I did create firewall rule:
But when type telnet X.X.X.X 5901, I get back
Connecting To X.X.X.X...Could not open connection to the host, on port 5901: Connect failed
I replaced actual ip with X.X.X.X in the above.
Any suggestions how I can troubleshoot it?
That should work!
I suspect vncserver isn't running (correctly) on the instance.
Or you're using the internal IP rather than the external IP address.
Did you confirm the server is running before you tried access it remotely? The tutorial suggests:
nc localhost 5901
But, you could also try:
ss --tcp --listening | grep 5901
and should see something similar to
LISTEN 0 5 *:5901
you need to tag the one GCE instance with vnc-server, in order to apply the rule. setting IP ranges to the home network might be tighter than permitting range 0.0.0.0. think one can use Stackdriver to log whenever a firewall rule applies. the host firewall might also prevent the access (eg. when Stackdriver logs, but it still not works).
I've looked through posts with no real answer to this question: is the address 127.0.0.1 a hardware set address much like promiscuous mode is a hardware setting on devices? I've tried to set my address to 127.0.0.1 on eth0, disable the lo, and even change the lo address, to make packets go out the eth0 port with address 127.0.0.1. The packets always end up on the lo port when I use sniffing tools like wireshark. Is there a way to do this, is this hardware or hardcoded into the drivers?
The loopback address is controlled by software (e.g. in the kernel). It is never associated with any hardware.
You don't specify your operating system, but unless it's very unusual, there really isn't a way to do what you ask (have packets addressed to 127.0.0.1 appear on an external interface).
Update:
Here's the spec:
127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].
In case of not turning the Firewall off:
after pinging the IP the Request time out will appears,
but after turning off the firewall it will reply.
Why?
I am using Mysql with Java, the question not related with java but maybe java programmers get something like this issues with sharing the database.
Your firewall will block access to port 3306 (default port for MySQL). To get it to work without turning the firewall off, you will have to configure the firewall to let connections to port 3306 (other whatever port is configured in your my.cnf) through.
A process is connecting to a certain ip or domain, but I do not know what it is. The process can't connect to the server. How do I find and change it?
TCPView and netstat work best for connections already established, which isn't the original poster's position.
A better tool for this task is a packet sniffer, which can observe the connection attempt. I recommend Wireshark, which is available for all major platforms.
Details:
Install, then start Wireshark
Press Ctrl-K to start capturing
Select the network interface that you expect the program to use
Type "tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn" in the Capture Filter box (no quotes)
Start the capture, go make your program try to connect, and then stop the capture.
If you do the last step fast enough on a machine without a lot of other network activity, you will have only one captured packet. Otherwise, you'll have to dig through a list to find the one you want. This packet will show the TCP port the program is trying to use.
Type netstat at the cmd prompt to see what ports are being used by active processes. Aside from that, you can't change the port being used by the proc to connect (unless you built the app obviously)
TCPView is a nice little utility that will show you all the open connections and endpoints on the local machine.
If the program is connecting using a DNS name (e.g., example.com), you can use the hosts file (c:\windows\system32\drivers\etc\hosts) to make that name map to a different IP address.
If you mean redirect the connection programmatically, that is a lot more complicated. You're not writing malware, are you?