DaemonForums  

Go Back   DaemonForums > Miscellaneous > Guides

Guides All Guides and HOWTO's.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 2nd May 2008
anomie's Avatar
anomie anomie is offline
Local
 
Join Date: Apr 2008
Location: Texas
Posts: 445
Default 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:
Code:
> 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         *:*
First, the command options: -4 means I am only interested in IPv4. -l means I only want to see listening sockets. (See the manpages for sockstat(1) for more info.)

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.

Code:
> sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
ryuf     firefox-bi 93662 36 tcp4   10.0.0.62:56582       208.69.32.230:80
...
www      httpd      1315  3  tcp4   10.0.0.102:80         66.14.160.210:61018
...
Again, -4 means I am only interested in IPv4. I omitted the -l option this time so that I can see all active connections (not just listening connections).

In this example, we can see the user 'ryuf' is connected to tcp port 80 on the remote host 208.69.32.230 (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:
Code:
> 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
For the command options, I used -P0 to skip ping, since many hosts unfortunately drop icmp echo requests. And I specified a comma-separated list of tcp (which is the default) ports: 80 and 443.

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.
Reply With Quote
  #2   (View Single Post)  
Old 9th May 2008
Bruco Bruco is offline
Fdisk Soldier
 
Join Date: May 2008
Location: Kalamazoo, MI, USA
Posts: 61
Default

Thanks for this!

On my 6.3 machine I had to do a sockstat -4c to see only connected (IP4) sockets.
Reply With Quote
  #3   (View Single Post)  
Old 13th May 2008
windependence's Avatar
windependence windependence is offline
Real Name: Tim
Shell Scout
 
Join Date: May 2008
Location: Phoenix, Arizona
Posts: 116
Default

This is fantastic. Thanks!

-Tim
__________________
www.windependence.org
Get your Windependence today!
Reply With Quote
  #4   (View Single Post)  
Old 13th May 2008
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

A more portable way to check this is to use netstat -an.
Code:
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   81.171.44.131.123     
udp        0      0  192.168.222.20.31964   131.211.187.240.123   
udp        0      0  192.168.222.20.25209   81.171.46.247.123     
udp        0      0  192.168.222.20.22752   62.93.230.13.123      
udp        0      0  192.168.222.20.35148   194.109.153.91.123    
udp        0      0  *.514                  *.*
Leaving out the -n option will make it even more readable
Code:
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               *.*
BTW this is on OpenBSD, which doesn't have a sockstat.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #5   (View Single Post)  
Old 14th May 2008
ephemera's Avatar
ephemera ephemera is offline
Knuth's homeboy
 
Join Date: Apr 2008
Posts: 537
Default

on *nixes that don't have sockstat i use 'lsof'. its a very useful tool.
Reply With Quote
  #6   (View Single Post)  
Old 14th May 2008
windependence's Avatar
windependence windependence is offline
Real Name: Tim
Shell Scout
 
Join Date: May 2008
Location: Phoenix, Arizona
Posts: 116
Default

Thanks guys, I run a few OBSD machines also.

-Tim
__________________
www.windependence.org
Get your Windependence today!
Reply With Quote
Reply

Tags
daemon, listening, service

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
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


All times are GMT. The time now is 02:30 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick