# Sockstat output



## z662 (May 16, 2011)

Question about the output from sockstat

Below is some sample output: 


```
[brad@moon ~]$ sockstat -4l
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
brad     ssh        1426  4  tcp4   127.0.0.1:6667        *:*
root     Xorg       1171  3  tcp4   *:6000                *:*
root     sendmail   1012  4  tcp4   127.0.0.1:25          *:*
root     ntpd       781   20 udp4   *:123                 *:*
root     ntpd       781   22 udp4   192.168.0.104:123     *:*
root     ntpd       781   25 udp4   127.0.0.1:123         *:*
root     syslogd    562   7  udp4   *:514                 *:*
```

I would like to know if someone could explain the '*' as well as the '*:*'

I am guessing that the local address with a single * means listen on any address for that specific port, and since its local only, then the foreign address with '*:*' means that it cannot be connected remotely.  At least I hope that is the case.  

Also similarly I find it interesting that ntpd runs as root, in addition my webserver seems to run httpd as both root and an unprivileged user.  Is that to be expected?


----------



## bbzz (May 16, 2011)

z662 said:
			
		

> I am guessing that the local address with a single * means listen on any address for that specific port, and since its local only, then the foreign address with '*:*' means that it cannot be connected remotely.  At least I hope that is the case.



*:* stands for IPort tuple (socket).
For example syslogd listens on UDP port 514. *:514 means that IP address can be any local IP address, that is, any IP associated with any of your directly connected interfaces (including loopback).
*:* under foreign address stands for any IP and any port. It doesn't necessarily mean that everyone outside is allowed to connect, that depends on your firewall. The reason output is this way is because you specified to list ports you are listening on (tcp/udp).

Again, whether or not someone can connect to your service depends on your firewall; this only shows ports that are open and listening.


----------



## z662 (May 16, 2011)

Thanks for the reply.  Even though my firewall would theoretically prevent any intruders from accessing those services, it still be of peace and mind to keep them local in case a hacker was able to circumvent my firewall.  Do those services always need to listen remotely?  My firewall certainly blocks those ports, so I can't imagine why they would need to listen for remote connections, not only in my implementation but any.


----------



## bbzz (May 16, 2011)

TCP and UDP service listen to locally.
TCP is server-client protocol at transport layer. Server is a host that accepts connections from clients on open port.
For example when you enable TCP service ssh it listens on port 22. A remote client then initiates connection to your IP adress, port 22.
UDP is a bit different since its stateless (allows sending UDP datagrams to open port without establishing connection. See UDP attacks over Internet).
It is important to know what ports are available to outside world (outside can be LAN as well as Internet) trough firewall. 
Suggest to read about both in order to better understand if this is important to you.

Bytheway, the fact that program is TCP server-client, doesn't mean it _has_ to be connected to remotely. It can be connected to from local IP, from same machine that runs as server. Example, cupsd listens on port 631. When you want to print you connect to this port from same host that runs as server.


----------



## z662 (May 16, 2011)

I understand the differences, however



			
				bbzz said:
			
		

> Bytheway, the fact that program is TCP server-client, doesn't mean it _has_ to be connected to remotely.



It would be a better security practice to remove the capability that it can connect remotely, even though it only HAS to connect locally.

I am just saying it would be wise to remove that possibility from the equation assuming there is no reason (and that I can disable via the config file) for it to listen remotely.  At the very least, then I would not need to rely on my firewall.


----------



## bbzz (May 16, 2011)

Except the fact that this allows you to connect from remote machine and do your printing on remote printer.


----------



## SirDice (May 16, 2011)

For syslogd add this to /etc/rc.conf:

```
syslogd_flags="-ss"
```
That will prevent it from opening a socket at all.

For ntpd you'll need to install net/openntpd, it has more options.

Xorg, depends on how you've started it. There are setting for KDM, GDM and XDM that will prevent it from opening a port.


----------



## z662 (May 16, 2011)

Thanks again dice!

In regards to X, would that be in KDM config or xorg?  I installed KDE4 and xorg, then run *startx* which calls the startkde command from .xinitrc.  The standard handbook approach.  I'd like to be able to fix it so that it is only listening locally.


----------



## SirDice (May 16, 2011)

For startx you'll have to do something like:

```
startx -- -nolisten tcp -nolisten udp
```

If I remember correctly. Do note that this will break X-forwarding as there won't be an X server listening anymore.


----------



## z662 (May 16, 2011)

That should be fine considering this is just my laptop.  I will make those changes tonight after work.  

In regards to my webserver and the httpd daemons, would it be best to paste some sample output?  I am mainly just interested in the fact that both www and root are serving it.  Is that expected, or is something not properly configured?


----------



## SirDice (May 16, 2011)

Nope, that's expected. Only root is capable of opening ports below 1024. It therefor requires root access to open port 80. But as soon as that's done privileges will be dropped and switched to the www user.


----------



## z662 (May 16, 2011)

Isn't that the intention of sticky bits and setuid though?


----------



## SirDice (May 16, 2011)

z662 said:
			
		

> Isn't that the intention of sticky bits and setuid though?



Those are only related to the filesystem, not sockets.


----------



## z662 (May 16, 2011)

Good to know.  Thanks for all your help over the past week.  Very appreciated!  Id buy you a beer but I dont think Ill be in the Netherlands anytime soon :e

Update:  To disable X listening remotely use 


```
startx -- -nolisten tcp
```


----------

