sshd : .example.com : severity emergIt is also possible to specify a facility using the severity option. The following example logs anySSH connection attempts by hosts from the example.com domain to the local0 facility with apriority of alert:sshd : .example.com : severity local0.alertNoteIn practice, this example does not work until the syslog daemon (syslogd) isconfigured to log to the local0 facility. Refer to the syslog.conf man page forinformation about configuring custom log facilities.2.2.2. Access ControlOption fields also allow administrators to explicitly allow or deny hosts in a single rule by addingthe allow or deny directive as the final option.For instance, the following two rules allow SSH connections from client-1.example.com, butdeny connections from client-2.example.com:sshd : client-1.example.com : allow sshd : client-2.example.com : denyBy allowing access control on a per-rule basis, the option field allows administrators toconsolidate all access rules into a single file: either hosts.allow or hosts.deny. Someconsider this an easier way of organizing access rules.2.2.3. Shell CommandsOption fields allow access rules to launch shell commands through the following two directives:• spawn — Launches a shell command as a child process. This option directive can performtasks like using /usr/sbin/safe_finger to get more information about the requesting clientor create special log files using the echo command.In the following example, clients attempting to access Telnet services from the example.comdomain are quietly logged to a special file:in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from%h>>/var/log/telnet.log \ : allowChapter 17. TCP Wrappers and ...316
