Learn which services are listening on your box
As a responsible member of the *nix community, it's a good idea to know exactly which services on your box are listening for connections from the outside world. To that end, what follows is a beginner-oriented guide to answer the questions: Which daemons are listening? Who is connecting to them? What networks have access to them?
Note that this is written specifically for FreeBSD versions 6.x and 7.0. Different OSes and different versions may require different approaches.
Which daemons are listening?
This question can be answered simply enough using the sockstat program. Example:
> sockstat -4l USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS www httpd 1319 3 tcp4 10.0.0.102:80 *:* www httpd 1318 3 tcp4 10.0.0.102:80 *:* www httpd 1317 3 tcp4 10.0.0.102:80 *:* www httpd 1316 3 tcp4 10.0.0.102:80 *:* www httpd 1315 3 tcp4 10.0.0.102:80 *:* root httpd 1203 3 tcp4 10.0.0.102:80 *:* root sendmail 699 4 tcp4 127.0.0.1:25 *:* root syslogd 563 6 udp4 10.0.0.62:514 *:*
In this example, we see plenty of information about listening daemons, including the user the daemon is running as, the daemon name itself, the PID, protocol type (tcp or udp; well beyond the scope of this explanation), and the interface it is actively listening on.
[ For users who are familiar with GNU/Linux, this output contains a lot of the same information that you might get from the command: netstat -ltunp ]
Who is connecting to the listening daemons (real-time)?
To see who currently has active connections (inbound or outbound, actually) to any of the daemons, we'll use a slightly different invocation of sockstat.
> sockstat -4 USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS ryuf firefox-bi 93662 36 tcp4 10.0.0.62:56582 126.96.36.199:80 ... www httpd 1315 3 tcp4 10.0.0.102:80 188.8.131.52:61018 ...
In this example, we can see the user 'ryuf' is connected to tcp port 80 on the remote host 184.108.40.206 (which just happens to be google). This is a connection from a local user to a remote web server.
We can also see a connection that is associated with the user 'www'. It appears to be coming from a high-numbered tcp port on a remote IP address to tcp port 80 on our local machine. This is a connection from a remote user to our web server.
Who is connecting to the listening daemons (non real-time)?
Keeping track of this information is important, and it's generally the job of your daemon's connection logging. Additionally, if you are running a packet filtering firewall, you may choose to implement logging at that level as well.
Configuring this is beyond the scope of this explanation. A good place to start would be the documentation for your daemon and/or firewall.
What networks have access to the daemons?
This question is a little trickier to answer, as there are a lot of variables that may be involved, depending on your situation. For example: if your box is behind a packet filtering appliance (firewall or switch) or behind some sort of NAT device (e.g. a SOHO router), that will complicate testing who really has access to your daemons considerably. (This becomes especially complicated if any of those appliances or devices are managed by someone other than you.)
Nonetheless, we have a very effective tool (among several) to test that your daemons are listening to the networks you think they are, and that your host-level firewall rules are working as you'd expect: the popular nmap. It can be installed from the security/nmap port.
Note that for useful results, bear in mind all the gotchas above, and test from another box on a network that is appropriate given your situation. It is virtually useless to run a nmap scan against localhost on your own machine. Doing so tells you nothing that you couldn't glean from sockstat output.
In one of its simplest invocations, we will scan two different tcp ports on a remote host. Example:
> nmap -P0 web.bunnyland.local -p 80,443 Starting Nmap 4.20 ( http://insecure.org ) at 2008-05-02 12:05 CDT Interesting ports on web.bunnyland.local (10.0.0.191): PORT STATE SERVICE 80/tcp filtered http 443/tcp open https Nmap finished: 1 IP address (1 host up) scanned in 11.213 seconds
From the output we see that tcp port 80 is "filtered". This likely means that there is a packet filtering rule that drops tcp packets to port 80 from at least my own box. We also see that tcp port 443 is "open". This means that at the TCP/IP level, I should be able to initiate a connection to port 443 on web.bunnyland.local.
[ nmap has many, many more options. See its manpages at nmap(1) and its project page to learn more. ]
That's it for now; hopefully these tips have given you a slightly clearer view of what is happening with listening daemons on your box. Stay aware and stay safe.
Kill your t.v.
Last edited by anomie; 2nd May 2008 at 05:24 PM.
A more portable way to check this is to use netstat -an.
netstat -an -f inet Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 *.80 *.* LISTEN tcp 0 0 *.6000 *.* LISTEN tcp 0 0 127.0.0.1.587 *.* LISTEN tcp 0 0 127.0.0.1.25 *.* LISTEN tcp 0 0 *.22 *.* LISTEN tcp 0 0 *.515 *.* LISTEN Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 192.168.222.20.20996 220.127.116.11.123 udp 0 0 192.168.222.20.31964 18.104.22.168.123 udp 0 0 192.168.222.20.25209 22.214.171.124.123 udp 0 0 192.168.222.20.22752 126.96.36.199.123 udp 0 0 192.168.222.20.35148 188.8.131.52.123 udp 0 0 *.514 *.*
netstat -a -f inet Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 hercules.8448 mu-in-f91.google.www ESTABLISHED tcp 0 0 *.www *.* LISTEN tcp 0 0 *.6000 *.* LISTEN tcp 0 0 localhost.submissi *.* LISTEN tcp 0 0 localhost.smtp *.* LISTEN tcp 0 0 *.ssh *.* LISTEN tcp 0 0 *.printer *.* LISTEN Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 hercules.20996 ams1.x31.com.ntp udp 0 0 hercules.31964 ruumzp.med.uu.nl.ntp udp 0 0 hercules.25209 vm196.contextshi.ntp udp 0 0 hercules.22752 sectionzero.org.ntp udp 0 0 hercules.35148 ntp.t.niet.net.ntp udp 0 0 *.syslog *.*
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
|daemon, listening, service|
|Thread||Thread Starter||Forum||Replies||Last Post|
|learn assembly||ephemera||Book reviews||5||26th December 2012 06:29 PM|
|Would BSD be right to learn networking?||php111||Off-Topic||17||25th September 2008 07:02 PM|
|How did you learn to program?||TerryP||Off-Topic||25||6th September 2008 04:00 PM|
|start stop services ?||smooth187||OpenBSD General||4||31st August 2008 01:00 AM|
|Questions about my home configuration services||aleunix||OpenBSD Security||9||12th June 2008 01:54 PM|