The default Solaris syslogd daemon is a primitive (old style) daemon that is controlled by /etc/syslog.conf. It can send/receive messages from the remote hosts but the level of control is very primitive (they will be mixed with the logs from the LOGHOST server). syslog-ng is probably a step forward and can be used with Solaris.
The default Solaris syslog daemon uses port 514 (UDP) for forwarding messages to a centralized log host. There is no acknowledgement and messages are lost if the LOGHOST server is down or if its syslogd daemon is down of if the is a firewall that filter out this port on the route tot he LOGHOST. In Solaris this is done using STEAMS log driver.
The simplest remote syslog configuration is an unencrypted one. To activate such remote sysloging on Solaris you need:
* To edit /etc/hosts (./inet/hosts) and add one or several lines that defines IP address for loghost (Name is arbitrary, and if several remote hosts are defined you can use any name you wish)
* Edit syslog configuration file (/etc/syslog.conf) for each server you need to collect logs from. To send everything to remote syslog server, add this line to your syslogd.conf file:
After editing file you need to restart syslogd:
#pname -HUP syslogd
#/etc/rc2.d/S74syslog stop ; /etc/rc2.d/S74syslog start
You can use a full DNS name like @logbase.mycompany.com In this case you do not need to touch hosts file, but remote logging became dependent on the DNS availability.
Solaris uses macro processor M4 to preprocess syslog.conf and you can use all the power of M$ to make the configuration more flexible. Example in the standard syslogd configuration is a pretty weak one: it is based on checking if LOGHOST env. variable is defined (it is only if IP address of the server is defined as loghost in /etc/hosts) The ifdef (â€˜LOGHOSTâ€™, truefield, falsefield) command permits to select two variants of log forwarding depending on this. This permits any server to be used by loghost. Nice, but pretty useless in practice trick as LOGHOST server generally needs to be a specialized and more secure server.
Also you can replace syslogd with syslog-ng. The latter lets filter and route logs. The ability of syslog-ng to filter messages of various types provides the capability to distribute specific message types to people responsible for a given application/function. That makes the environment closer to VM/CMS system ;-). It is possible to invoke a script on the receipt of specific mail messages. If you use Perl the logic can be pretty sophisticated.
Creating a loghost for your servers can be invaluable both for troubleshooting and in the event of a security breach. If you are part of a cluster, make sure your machine logs to another loghost as well as itself. If someone breaks in and erases your log files, and you have only been logging locally, you will have no chance of figuring out where they came from or what they did. Intruders commonly use scripts to erase their presence from the log files. By sending your logs to another more secure machine, you have a better chance of at least tracking the intruder’s activities.
Security precautions to take:
* Make sure the time is correct on your system. Otherwise you will have trouble tracing problems and breakins.
* System logs are generally kept in the /var partition, mainly /var/adm. Make sure that /var is large enough to hold much more than the basic log file. This is to prevent accidental overflows, which could potentially erase important logging info.
* The default syslog.conf does not do a very good job of logging. Try changing the entry for /var/adm/messages to:
If you start getting too much of a certain message (say from sendmail), you can always bump that particular facility down by doing
* To enable more logging of logins, create the "loginlog":
chmod 600 /var/adm/loginlog
chgrp sys /var/adm/loginlog
* Enable ssh and tcpwrappers that log important events to syslogd.
Additional security precautions for LOGHOST:
* In order to create a loghost, pick one machine and secure it as much as possible. Basically, donâ€™t run anything on this machine besides syslogd. Turn off inetd, sendmail, everything, but make sure you have basic networking up. Possibly donâ€™t even run ssh on this machine. That way, the only way to view the log files on the loghost would be to physically log into the console.
* Make sure the time is always correct on the loghost.
* In order to allow the loghost to receive syslog messages from other machines, you may need to enable it to receive remote logging. (Find out first by reading the syslogd man pages). Do this by adding the â€“r command line upon syslogd startup. Edit /etc/rc2.d/S74syslog, and find the line:
and change it to:
* Again, make sure the loghost is as secure as possible: the only thing it should be running is syslogd.
* No congestion control with UDP, allowing denial of service attack (Contra argyment: "Simple protocol")
* UDP packets are easily spoofed. (Contra: "No more easily than TCP, aside from sequence number.")
* No authentication – no way for a loghost to reject messages received.
* No confidentiality of message data. (Contra: "Use IPSEC." if you are really concered about security)
* Vulnerable to man-in-middle attack — packets may be altered undetectably in transit. (Contra: "Use IPSEC.")
* Vulnerable to spoofing/chaffing — bogus messages can be sent to the logging host. (Contra: "Use IPSEC.")
* Gaps in the message sequence due to lost packets can’t be detected by receiver
* Vulnerable to successful intruders: need to have inviolability of the log itself. Contraargument: you first need to make logs availbale to your personnel that most often does not read them at all. also Loghost server can be easily secured more tightly to aviod common breakins.
* Timestamp is provided at receiver, not originator; forwarding often adds observable delay potencially causing misinterpretation.
* Limited information on originating facility and severity level (priority) of message
* Lack of flexibility in use of facility codes among systems and applications — making it difficult to write filter scripts to detect security event.
1. Firewalls & proxies: need UDP port 514 proxy
2. Unreliable: No guarantee that a syslog packet will be received, and no facilities for retransmission (Contra: "Simple protocol, usually not needed on a typical LAN")
3. Better Timestamping: It should be a requirement that the timestamp specified in the protocol (both by the client, in the packet; and in the server, when the message is logged) are recorded in the logfile.
4. Problems with log message formatting & structure: "The structure of messages is really a mess."
* No standard way of formatting of message text and separating various arguments of the log message
* Priority/facility are encoded in a not particularly human-readable way, but then sent in text form. "This has the worst features of binary protocols (not human-readable) and text protocols (inefficient use of bandwidth – and just to make this one worse, the first byte of every packet is constant!)"
5. Standardisation: syslog is not standardised, which makes it more difficult than it should be to produce interoperable implementations. (Contra: "Syslog is currently interoperable and actually more or less standardized between all flavours of Unix though there are some individual variations.")
* Repeat notification: ‘"…repeated N times" doesn’t show up until a different line comes along which is a pain if you’re watching the log.
* Problems with multiple syslog.conf lines that name the same file.
* Problem with spraing LAN when logserver became unabalable or IP address changed.
* No ability to define daemon’s fsync() behavior.
* No standardized logging directory (/var/log, /var/adm, …).
* No forwarding for sulog.
Syslog is still the most widespread and usable tool for event logging, esp. because it is a buil-in, low-cost protocol that can be easily added to network and embedded devices. Strategies for cautious use include:
* Use physically separate out-of-band networks for all management data including syslog.
* Syslog configuration can use non-IP interfaces between log hosts, e.g. serial links, to keep the destination loghost out of the ARP tables of a compromised access host.
* Firewall filtering, route authentication, VLAN assignments, etc. to limit udp/514 syslog, can isolate syslog regions within a network as well as inside from outside.
* Syslog servers can be provided with CPU and disk capacity far exceeding normal needs.
* Syslog daemon code can be altered for improved filtering and handling of application-specific messages. (This has been widespread in the UNIX and Open Source community, with versions of syslog() and syslogd sometimes distributed with other applications — e.g. INN.)
Basic security enhancements
* Out-of-band management network can be used for logging.
* Non-IP links can limit visibility of syslog forwarding path.
* IP access list for syslogd can permit receiver to drop all packets not claiming to be from a valid source address.
* Check file permissions for all logfiles and syslog.conf.