inetd: Disable inetd Connection Logging for individual Services

Noticed a large number of unwanted constant connection messages in my system messages file.




 

 Aug 31 18:36:39 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[19080] from ip-address 45632
 Aug 31 18:36:39 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[19081] from ip-address 45633
 Aug 31 18:40:35 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[19288] from ip-address 48640
 Aug 31 18:40:39 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[19290] from ip-address 48641
 Aug 31 18:41:05 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[19333] from ip-address 48653
 Aug 31 18:41:05 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[19333] from ip-address 48653
 Aug 31 18:41:05 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[19334] from ip-address 48654
 Aug 31 18:45:51 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[19543] from ip-address 48714
 Aug 31 18:45:52 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[19544] from ip-address 48715
 Aug 31 18:50:09 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[19781] from ip-address 48786
 Aug 31 18:50:09 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[19782] from ip-address 48787
 Aug 31 18:57:59 ausydwebt01 inetd[455]: [ID 317013 daemon.notice] vnetd[24199] from ip-address 48871

The above is coming from my Veritas Netbackup network connection daemon which is constantly filling up my messages file during its nightly backup procedure.

If inetd is running, the "tracing" feature can be used to log information about the source of any network connections seen by the daemon. Rather than disabling inetd tracing for all services, the administrator has the option of disabling tracing for individual services with inetadm -m svcname tcp_trace=FALSE , where is the name of the specific service that should use tracing.

1. The following command will display the properties for the vnetd service.

 # inetadm -l svc:/network/vnetd/tcp:default
 SCOPE    NAME=VALUE
          name="vnetd"
          endpoint_type="stream"
          proto="tcp"
          isrpc=FALSE
          wait=FALSE
          exec="/usr/openv/bin/vnetd"
          user="root"
 default  bind_addr=""
 default  bind_fail_max=-1
 default  bind_fail_interval=-1
 default  max_con_rate=-1
 default  max_copies=-1
 default  con_rate_offline=-1
 default  failrate_cnt=40
 default  failrate_interval=60
 default  inherit_env=TRUE
 default  tcp_trace=TRUE
 default  tcp_wrappers=TRUE
 default  connection_backlog=10

2. The following command will disable tracing for the vnetd service

 # inetadm -m svc:/network/vnetd/tcp:default tcp_trace=FALSE

3. Confirm the changes using the display option again.

 
 # inetadm -l svc:/network/vnetd/tcp:default
 SCOPE    NAME=VALUE
          name="vnetd"
          endpoint_type="stream"
          proto="tcp"
          isrpc=FALSE
          wait=FALSE
          exec="/usr/openv/bin/vnetd"
          user="root"
 default  bind_addr=""
 default  bind_fail_max=-1
 default  bind_fail_interval=-1
 default  max_con_rate=-1
 default  max_copies=-1
 default  con_rate_offline=-1
 default  failrate_cnt=40
 default  failrate_interval=60
 default  inherit_env=TRUE
          tcp_trace=FALSE
 default  tcp_wrappers=TRUE
 default  connection_backlog=10

syslog: Real-Time Email-Notification For Critical syslog Events

One of the big advantages of syslog is the separation between the log request and the logging action.

The following steps will show how to :

   1. Write all critical events to a local logfile
   2. Log this to the console
   3. Send an email notification of the event. 

In this example, we'll take all critical messages written from all facilities and (in addition to logging) send them to the mail recipient, named@example.com. 

First, create a log file for critical messages, for example:

 # touch /var/adm/critmessages
 # chmod 600 /var/adm/critmessages

Next, configure syslog to log all critical messages written from all facilitites to this log file. add the following statement to your syslog.conf file.

One thing to note when editing /etc/syslog.conf, you can't use spaces, you must use tabs.

 *.crit                             /var/adm/critmessages

The final step is to mail out any messages that are written to the pipe. you can do this with a simple shell script. i've included an example below, let's call it /usr/bin/syslogMailer:

 #!/bin/bash
 # syslogMailer: a script to read stdin and turn each line into an alert
 # email typically this is used to read a named-pipe written to by syslog
 #
 #   example usage: syslogMailer.sh < /var/adm/critmessages
 #

 hostname=`hostname`
 alertRecipient="named@example.com"      # the mail recipient for alerts
 TMOUT=1                                 # don't wait > 1 second for input

 # process each line of input and produce an alert email
 while read line
 do
    # remove any repeated messages
    echo ${line} | grep "message repeated" > /dev/null 2>&1
    if test $? -eq 1
    then
       # send the alert
       echo "${line}" | mailx -s "Critical Error on syslog | $hostname" ${alertRecipient}
       cat /dev/null > /var/adm/critmessages
    fi
 done

This allows you to schedule it in cron to run, say, every 1 min of every hour with a statement like:

 * * * * * /usr/bin/syslogMailer.sh < /var/adm/critmessages > /dev/null

After changing the configuration, make sure that you restart syslogd, on Solaris 10 Update 1 or newer you'd use svcadm restart svc:/system/system-log:default.

Test it by simply running the following logger command.

 logger -p auth.crit "test"

syslog: Syslog Defined

When a program sends a message to syslog, its given to the syslog daemon (syslogd) and then routed according to the /etc/syslog.conf

configuration file. By default most of the useful output from syslog is placed into /var/adm/messages.

When messages are sent to syslog they are given a "facility" (whats sending the message) and a "level" (how important is it). If you look in /etc/syslog.conf you'll see a variety of facility.level pairs and then for each of these a destination for that type of message. Facility can be named (daemon, kern, ...) or can be a wildcard (*). Level must be named (alert, crit, notice, ..), but a given level will also report all levels above it, so if you use the "notice" level you'll also get crit's as well, for instance.  

Of the facilities and levels, note that two are special, the wildcard (*) facility and the "none" level. Using the wildcard for the facility means all of them. The "none" severity level isn't useful on its own, but can be handy when creating compound statements for several facilities and levels.

 
So lets look at some sample lines from /etc/syslog.conf:

                 *.err;kern.debug;deamon.notice;mail.crit                /var/adm/messages

So this line passes along anything more sever than an error, any kernel notices or more sever, daemon notices or more sever, and critical or more sever mail messages, and routes these into the /var/adm/messages file. If we wanted to put all mail messages into a log file named "/var/adm/maillog" we could use something like "mail.debug /var/adm/maillog". 

Putting log messages into a file is handy, but we can also send those messages across the network to a centralized syslog server. Simply use "@mysyslogserver" instead of a filename. So, "auth.notice @logserver" will send all authorization notices (or more sever) to the syslog daemon running on a system called "logserver". 

                 auth.notice                @logserver

Syslog on Solaris is setup by default to accept messages both locally and over the network. Reguardless of how a message comes into the syslogd daemon, its routed according to the syslog.conf configuration. So you could put "*.notice @syslogcentral" into the syslog.conf of each of your clients and "*.notice /var/adm/centralized_messages" in the syslog.conf of syslogcentral and wamo bamo, you'd have a centralized syslog infrastructure! 

One thing to note when editing /etc/syslog.conf, you can't use spaces, you must use tabs. Also, after changing the configuration, make sure that you restart syslogd, on Solaris 10 Update 1 or newer you'd use svcadm restart svc:/system/system-log:default. 

syslog: Logging su Attempts & Failed Logins

From a security perspective when configuring system logging, I like to configure the syslogd daemon to monitor the following.

I like to log each time a user logs into my systems, as well as all attempts to su to another user. To log all su attempts, the file /var/adm/sulog can be created (in recent releases of Solaris, this file is created by default):

 # touch /var/adm/sulog

To log all successful and unsuccessful logins, you will first need to set the variable:

 SYSLOG_FAILED_LOGINS in /etc/default/login to the value 0

Once the variable is adjusted, you will need to create a log file to store the login attempts:

 # touch /var/adm/loginlog

After the log file is created, the auth priority needs to be added to /etc/syslog.conf:

 auth.debug /var/adm/loginlog

With the loginlog and sulog files in place, it is relatively easy to see who accessed a given system at time X, and who tried to become the super user.

One thing to note when editing /etc/syslog.conf, you can't use spaces, you must use tabs. Also, after changing the configuration, make sure that you restart syslogd, on Solaris 10 Update 1 or newer you'd use svcadm restart svc:/system/system-log:default.