Can anybody tell me where can I find full explanation of "pfctl -s state" output?
all tcp 192.168.0.123:22 <- 192.168.0.234:38095 ESTABLISHED:ESTABLISHED
What direction means, which TCP infos are available like "ESTABLISHED:ESTABLISED" and so on.
Good day to you..
This rule means; there is a TCP (as opposed to UDP) connection from remote IP addres 192.168.0.234 port 38095 to local IP address 192.168.0.123 port 22. ESTABLISHED refers to the state of the connection.
Related
I just want to know what is the network protocol or port used by nc command,anyone answer is much appreciate ^^
From https://www.computerhope.com/unix/nc.htm it looks like TCP or UDP protocol. It works with whichever ports you tell it to look at.
I have an hadoop defaultFs application run in port 8020, as show with sudo netstat -tulpn | grep :8020, where 10.44.142.19 is the internal address,
tcp 0 0 10.44.142.19:8020 0.0.0.0:* LISTEN 31680/java
I also opened this port in iptables
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8020
But this port is still blocked.
I guess is the problem of ip address, where 10.44.142.19 should be 127.0.0.1, because I am visiting it from external, right?
How could I solve this? Thanks in advanced.
ok if you are coming in from the WAN you need to use your ip from your modem. google "whats my ip" If you are behind a router, your router will give you an ip of something like, 192.168.10.101 type that in goto your sever over a LAN.
:8020 at the end if that is your port you are directing to.
firewall must be down for that port to come from the outside, and your web server must be setup to make the files and folders you want to disturb or make available with permission of at least read for your web servers user or group, in permissions.
each system is a little different so you have to tweek things as you go.
on one of my linux hosts, one tcp socket seems to be visible on one side and invisble on the other side. I mean netstat displays this socket when I am on one of the hosts and not when I am on the other (linux too):
# netstat -anp|grep 37674
udp 0 0 169.254.192.2:37674 169.254.192.1:8649 ESTABLISHED 22644/xxxxx
# ssh 169.254.192.1
Last login: Mon Jan 13 15:22:54 CET 2014 from xxxxxx on ssh
# netstat -anp|grep 8649
#
If I undestand correctly, netstat reads connections from /proc/net/tcp. Apparently, local ip address and ports are given as 0123ABCD:1234 in /proc/net/tcp in second column.
37674(10) = 932A(16)
Thus, I tried to find 932A in /proc/net/tcp, ignoring case but found nothing.
IP address is not truncated as I have no other 169.254.192.1xx host on my network.
This connection is still visible after three hours, thus I don't think it's timeout related.
The output of netstat says UDP. (Look in /proc/net/udp)
This means means 169.254.192.2 has called connect() to 169.254.192.1:8649. UDP is however connectionless, so this info is just recorded locally on a socket on the 169.254.192.2 machine.
Calling connect() on an UDP socket just enables you to call send() on that socket without specifying the destination address for each packet with sendto()/sendmsg() - no actual connection created between the two machines.
If the 169.254.192.1 machine isn't listening/receiving packets on port 8649, it isn't meaningful for the 169.254.192.1 machine to set up a socket that can send packets there though.
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
Machine is RHEL 5.3 (kernel 2.6.18).
Some times I notice in netstat that my application has connection, established TCP connection when Local Address and Foreign Address are same.
Here same problem reported by someone else too.
The symptoms are same as described in link - client connects to port X port of server running locally. After some time netstat shows that client has connection from 127.0.0.1:X to 127.0.0.1:X
How it's possible?
Edit 01
Simultaneous open is causing the problem (thanks a lot to Hasturkun). You can see it on classical TCP state diagram in transition from SYN_SENT state to SYNC_RECEIVED
This may be caused by TCP simultaneous connect (mentioned on this post to LKML, see also here).
It's possible for a program looping on trying to connect to a port within the dynamic local port range (which can be seen in /proc/sys/net/ipv4/ip_local_port_range),to succeed while the server is not listening on that port.
On a large enough number of attempts, the socket being used to connect may be bound to the same port being connected to, which succeeds due to previously mentioned simultaneous connect. You now magically have a client connected to itself
A TCP connection is uniquely identified by this tuple (local address, local port #, foreign address, foreign port #). There is no requirement that local address and foreign address, or even that the port numbers be different (though that would be exceedingly strange). But there is at most 1 TCP connection that has the same values for a given tuple.
When a computer connects to itself, it's local address and foreign address are almost always the same. After all, the 'local' side and 'foreign' side are actually the same computer. In fact, when this happens your computer should be showing two connections that have the same 'local' and 'foreign' addresses, but reversed port numbers. For example:
$ ssh localhost
will result in two connections that look something like this:
$ netstat -nA inet | fgrep :22
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:56039 127.0.0.1:22 ESTABLISHED
tcp 0 0 127.0.0.1:22 127.0.0.1:56039 ESTABLISHED
As you can see, the local address and foreign addresses are the same, but the port numbers are reversed. The unique tuple for this TCP connection is (127.0.0.1, 56039, 127.0.0.1, 22). There will be no other TCP connection that has these same four fields.
The fact you see two is because your computer is both ends of the connection. Each end has its own view of which one is 'foreign' and which is 'local'.
You can even connect to yourself on the same port, and while this is not a common occurrence, it is not forbidden by the spec. Here is a sample program in Python which will do this:
import socket
import time
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('127.0.0.1', 56443))
s.connect(('127.0.0.1', 56443))
time.sleep(30)
This code works because one way in which it's possible to open a TCP connection is to have the other side of the connection try to open one with you simultaneously. This is known as simultaneous SYN exchange, and the linked to StackOverflow answer describes what that's about.
I also have a paper on using simultaneous SYN exchange to get through NAT, though in that case the source and foreign would be completely different.