Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Softpanorama Search

Syslog-ng for Suse and Solaris

News See also Recommended Links Manual Reference Recommended Papers Installation on Solaris 9
Options Configuring syslog-ng to send logs Filters Configuration Examples Tips History Humor

On Suse 10 syslog-ng is preinstalled (used instead of standard syslog daemon).  Both Solaris 10 and Solaris 9 syslog-ng packages are available from Sun Freeware:

Solaris 9:

syslogng-1.6.4-sol9-sparc-local.gz Syslog-ng is a syslogd replacement, but with new functionality - installs in /usr/local. You will need to have the libol package installed. Configuration documentation can be found in /usr/local/doc/syslog-ng.

The main problem with syslog-ng is that after starting it does not always wants to log messages whatsoever :-).  Pid file is created and syslog-ng daemon is running but it does not accept messages.  If you try pkill the daemon answers:

root@nti253:/var/adm # kill syslog-ng
ksh: syslog-ng: Arguments must be %job or process ids

To troubleshoot you need first to check the correctness of the configuration, for example:

    /usr/local/sbin/syslog-ng -v -s -f /etc/syslog-ng/syslog-ng.conf

That helps to detect errors in configuration files.

 If there is no errors you can try to run syslog with debug option (-d). Use

 options { long_hostnames(off); sync(0); };

in your syslog-ng.conf.

Notes:
  • This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
  • The site contain some broken links as it develops like a living tree... Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.
Google Search
Open directory
Research Index

Old news ;-)

[Jun 20, 2005] Remote Logging with SSH and Syslog-NG by Hal Pomeranz

One of the points I make repeatedly in my training classes is the value of centralized logging. Keeping an off-line copy of your site's logs on some central, secure log server not only gives you greater visibility from a systems management perspective but also can prove invaluable after a security incident when the local copies of the log files on the target system(s) have been compromised by the attacker.

[Dec 15, 2006]  Interview syslog-ng 2.0 developer Balázs Scheidler by: Robert Fekete

December 13, 2006 (Linux.com ) syslog-ng is an alternative system logging tool, a replacement for the standard Unix syslogd system-event logging application. Featuring reliable logging to remote servers via the TCP network protocol, availability on many platforms and architectures, and high-level message filtering capabilities, syslog-ng is part of several Linux distributions. We discussed the highlights of last month's version 2.0 release with the developer, Balázs Scheidler.

NewsForge: How and why did you start the project?

Balázs Scheidler: Back in 1998 the main Hungarian telecommunication company was looking for someone on a local Linux mailing list to port nsyslog to Linux. nsyslog -- developed by Darren Reed -- was at that time incomplete, somewhat buggy, and available only for BSD. While at university, I had been working for an ISP and got often annoyed with syslogd: it creates too many files, it is difficult to find and move the important information, and so on. Developing a better syslog application was a fitting task for me.

NF: Why is it called syslog-ng?

BS: syslog-ng 1.0 was largely based on nsyslog, but nsyslog did not have a real license. I wanted to release the port under GPL, but Darren permitted this only if I renamed the application.

NF: What kind of support is available for the users?

BS: There is a community FAQ and an active mailing list. If you are stuck with the compiling or the configuration, the mailing list is the best place to find help. My company, BalaBit IT Security, offers commercial support for those who need quick support.

NF: Documentation?

BS: The reference guide is mostly up-to-date, but I hope to improve it someday. I am sure there are several howtos floating around on the Internet.

NF: Who uses syslog-ng?

BS: Everyone who takes logging a bit more seriously. I know about people who use it on single workstations, and about companies that manage the centralized logging of several thousand devices with syslog-ng. We have support contracts even with Fortune 500 companies.

NF: What's new in version 2.0?

BS: 1.6 did not have any big problems, only smaller nuances. 2.0 was rewritten from scratch to create a better base for future development and to address small issues. For example, the data structures were optimized, greatly reducing the CPU usage. I have received feedback from a large log center that the new version uses 50% less CPU under the same load.

Every log message may include a timezone. syslog-ng can convert between different timestamps if needed.

It can read and forward logfiles. If an application logs into a file, syslog-ng can read this file and transfer the messages to a remote logcenter.

2.0 supports the IPv6 network protocol, and can also send and receive messages to multicast IP addresses.

It is also possible to include hostnames in the logs without having to use a domain name server. Using a DNS would seriously limit the processing speed in high-traffic environments and requires a network connection. Now you can create a file similar to /etc/hosts that syslog-ng uses to resolve the frequently used IP addresses to hostnames. That makes the logs much easier to read.

syslog-ng 2.0 uses active flow control to prevent message losses. This means that if the output side of syslog-ng is accepting messages slowly, then syslog-ng will wait a bit more between reading messages from the input side. That way the receiver is not flooded with messages it could not process on time, and no messages are lost.

NF: Is syslog-ng available only for Linux, or are other platforms also supported?

BS: It can be compiled for any type of Unix -- it runs on BSD, Solaris, HP-UX, AIX, and probably some others as well. Most bigger Linux distributions have syslog-ng packages: Debian, SUSE, Gentoo.... I think Gentoo installs it by default, replacing syslogd entirely.

NF: What other projects do you work on?

BS: syslog-ng is a hobby for me; that is why it took almost five years to finish version 2.0. My main project is Zorp, an application-level proxy firewall developed by my company. Recently I have been working on an appliance that can transparently proxy and audit the Secure Shell (SSH) protocol.

During development I stumble into many bugs and difficulties, so I have submitted patches to many places, such as glib and the tproxy kernel module.

NF: Are these projects also open source?

BS: No, these are commercial products, but the Zorp firewall does have a GPL version.

NF: Any plans for future syslog-ng features?

BS: I plan to support the syslog protocol that is being developed by IETF.

I would like to add disk-based buffering, so you could configure syslog-ng to log into a file if the network connection goes down, and transmit the messages from the file when the network becomes available again.

It would be also good to transfer the messages securely via TLS, and to have application-layer acknowledgments on the protocol level.

[Apr 11, 2006]  Build a Secure Logging Server with syslog-ng Part 1 of 2 by Carla Schroder

Configuration File Structure
With all of this flexibility comes a bit of a learning curve. Syslog-ng's configuration file is /etc/syslog-ng/syslog-ng.conf, or on some systems /etc/syslog-ng.conf. You'll need man 5 syslog-ng.conf to understand all the different options and parameters. syslog-ng.conf has five possible sections:

options{}
Global options. These can be overridden in any of the next four sections

source{}
Message sources, such as files, local sockets, or remote hosts

destination{}
Message destinations, such as files, local sockets, or remote hosts

filter{}
Filters are powerful and flexible; you can filter on any aspect of a log message, such as standard syslogd facility names (man 5 syslog.conf), log level, hostname, and arbitrary contents like words or number strings

log{}
Log statements connect the source, destination, and filter statements, and tell syslog-ng what to do with them

Here are some typical global options:

options {

    sync (0);
    log_fifo_size (2048);
    create_dirs (yes);
    group (logs);
    dir_group (logs);
    perm (0640);
    dir_perm (0750);
    };

Options statements must use options as defined in /etc/syslog-ng.conf. This what the examples mean:

sync
How many lines of messages to keep in the output queue before writing to disk. (Logging output is called "messages.") Zero is the preferred option, since you want to be sure to capture everything, and not risk losing data in the event of a power failure

log_fifo_size
The maximum number of lines of messages in the output queue. The default is 100 lines of messages. You can do some calculations to figure out a suitable value, as this syslog-ng mail list post shows. To quote the relevant bit:

Each message source receives maximum 1024 bytes of data. A single log message is about 20 to 30 bytes. So on a single run each log source may emit 1024/20 = 50 messages. Your log fifo must be able to hold this number of messages for each source. So for two sources, you'll need at least 100 slots in your fifo.
It is easy to get confused by these two options. Incoming messages from remote hosts arrive in bursts, so what you need to do is make sure your log_fifo_size is large enough to handle these bursts. Otherwise you risk losing messages. Ultimately you will be limited by i/o and network speeds

create_dirs
Enable or disable automatic directory creation for destination files. In this article this value is "yes", so that remote host directories can be created on demand

group
dir_group
Set the group owner of logfiles and directories, so you don't have to read and analyze logs as the superuser

perm
dir_perm
Default permissions on new files and directories

Source, Destination, and Filter Statements
Source, destination, and filter names are arbitrary, like these examples show:

source s_local { internal(); unix-stream("/dev/log"); file("/proc/kmsg" log_prefix("kernel: ")); };
destination d_auth { file("/var/log/auth.log"); };
filter f_auth { facility(auth, authpriv); };

So "source s_local" could be "source frederick_remington_depew" if you so desired, and "destination d_auth" could be "destination moon." The convention is to prefix source names with "s", destination names with "d", and filter names with "f", but this is not required. All other elements of source, destination, and filter statements must use parameters as defined in man 5 syslog-ng.conf.

The "source s_local" example collects all locally-generated log messages into a single source statement. The "destination d_auth" statement directs authorization messages to /var/log/auth.log, which are defined by the "filter f_auth" statement. auth and authpriv are standard syslog facility names.

Log statements pull it all together:

log {source(s_local); filter(f_auth); destination(d_auth); };

So these four lines filter out all the auth and authpriv messages from all local messages, and write them to /var/log/auth.log.

Enabling Remote Logging
While it's possible to send log messages from remote clients with good old syslogd, it's really not adequate because it only transmits UDP packets. So you need syslog-ng installed on all client hosts as well. Adding these lines to syslog-ng.conf on the server accepts remote messages from clients and dumps them into a single file per host:

source s_remote { tcp(); };
destination d_clients { file("/var/log/HOSTS/$HOST/"); };
log { source(s_remote); destination(d_clients); };

This is a very simple, but functional example for your client hosts that collects all local messages and sends them to the remote server:

#sample syslog-ng.conf for a remote client
source s_local { internal(); unix-stream("/dev/log"); file("/proc/kmsg" log_prefix("kernel: ")); };
destination d_loghost {tcp("192.168.1.10" port(514));};
log { source(s_local); destination(loghost); };
 

Sample syslog-ng.conf
A complete sample configuration file is a bit long to include here, so you should take a look at the one that came with your syslog-ng installation. Debian users get a customized file that replicates a syslogd setup. Let's put together our examples here in a single file for the server, set up a remote client, and run some tests to see how it works:

#sample syslog-ng.conf for a central logging server
options {

    sync (0);
    log_fifo_size (2048);
    create_dirs (yes);
    group (logs);
    dir_group (logs);
    perm (0640);
    dir_perm (0750);
    };

source s_local { internal(); unix-stream("/dev/log"); file("/proc/kmsg" log_prefix("kernel: ")); };
destination d_auth { file("/var/log/auth.log"); };
filter f_auth { facility(auth, authpriv); };

source s_remote { tcp(); };
destination d_clients { file("/var/log/HOSTS/$HOST"); };

log { source(s_remote); destination(d_clients); };
log { source(s_local); filter(f_auth); destination(d_auth); };

Whenever you make changes to syslog-ng.conf you must restart it:

# /etc/init.d/syslog-ng restart

Testing Everything
Now you can runs some simple tests on both the server and the client. Since the only local server messages that are going to be logged are authorization messages, you can test these by opening a new login session on the server, or running su or sudo. Then check /var/log/auth.log. Test the client by doing anything, then see if a new directory was created for the remote client in /var/log/HOSTS.

Another way is to use the useful and excellent logger command:

# logger "this is a test"
# logger -p auth.debug "this is a test"

This will create a line like this in your logfiles:

Apr 1 16:08:42 localhost.localdomain logger: this is a test

Now that we have a grasp of syslog-ng basics, come back next week to learn how to fine-tune and organize syslog-ng just the way you like, for both local and remote logging, and how to securely encrypt all syslog-ng network transmissions.

[Apr 11, 2006] Build a Secure Logging Server with syslog-ng (Part 2) by Carla Schroder

Securing Your Log Server
For your log server to be trustworthy, it should have some good access controls in place. These example iptables rules, run on the logging server itself, illustrate how to allow in only log messages and SSH traffic from the LAN:

iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 514 --sport 1024:65535 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 22 --sport 1024:65535 -m state --state NEW -j ACCEPT

Presumably your default policies are DENY, so you need rules only to allow authorized bits.

You definitely want /var on its own partition, or even a separate drive. If something goes haywire and your log files are flooded with data, you don't want the entire system to go down.

And of course you know to pay attention to hardening the entire system and application-level security.

Organizing Client Messages
Your starting point is the default syslog-ng.conf created by the installer. Typically, though it depends on the distribution, this replicates a standard syslogd configuration. This saves you a bit of labor setting up all the standard facility logs, and gives you a nice model to study.

Syslog.ng lets you slice and dice your log files finely. Don't make yourself crazy and create all manner of separate files for every last little individual criterion. I suggest starting with broader configurations, then directing certain types of messages to their own individual files as you need them. Start with directing unfiltered client messages to the server and let the server sort them out. Then fine-tune the client configurations as you need to. Just keep in mind it's easier to test and debug a single server configuration file than bales of of client files.

The example server configuration from Part 1 can be refined in a number of useful ways. This line creates a new client logfile every day. The client's directory is named for the remote host, then each logfile uses the date for its name:

destination d_clients { file("/var/log/HOSTS/$HOST/$DATE"); };

Other options are MONTH, WEEKDAY, HOUR, FACILITY, PRIORITY, and several others that you can find in the Syslog-ng Reference Manual. Dumping everything into a single file is rather messy, so you may wish to duplicate a stock configuration by creating files by facility, like this:

destination d_clients { file("/var/log/HOSTS/$HOST/$DATE_$FACILITY"); };

This example gives you another way to sort by date, which is helpful if you need to archive log files for a long time:

destination d_clients { file("/var/log/HOSTS/$HOST/$YEAR/$MONTH/$DATE_$FACILITY"); };

Be sure to have the create_dirs (yes); option set as shown in Part 1.

This introduces a new issue: the default logrotate configuration probably doesn't have a clue about your new log configurations. If you want your logs to be rotated instead of archived, you'll have to tweak logrotate.

Logging Both Remotely and Locally
There's no downside to logging remote clients both locally and remotely. Adding these lines to a stock syslog-ng.conf adds remote logging to the existing standard local logging configuration:

source s_local { internal(); unix-stream("/dev/log"); file("/proc/kmsg" log_prefix("kernel: ")); };
destination d_loghost {tcp("192.168.1.10" port(514));};
log { source(s_local); destination(d_loghost); };

Of course you must use your own loghost IP and port number. 514 is the standard syslog-ng port, but you may use any unused port that you desire. Check /etc/services to find unused ports, then be sure to edit /etc/services to include the port you are using.

Encryption With Stunnel
For additional protection you can use stunnel with syslog-ng. Syslog-ng has no native encryption, so stunnel fills this role quite ably. Stunnel must be installed on the server and on all clients. You'll also need OpenSSL, since Stunnel requires it. You'll need to create and distribute SSL certificates, which is the usual many-step dance: create your certificate authority, create .pem files for server and clients, sign the certificates, edit the derned things to remove the private keys, then distribute them.

If you do not already have your own SSL certificate authority, you must now create one. (The following instructions work on most Linux distributions, except Fedora/Red Hat etc., which as usual do things their own weird way. I'm not sure what to do with these, so I'm afraid you're on your own.) Find openssl.conf, and find and edit these lines: 

[ CA_default ]
dir   =   ./masterCA    # Where everything is kept
countryName_default             = US
stateOrProvinceName_default     = Oregon
0.organizationName_default      = Alrac Logging Co.
stateOrProvinceName		= Oregon
stateOrProvinceName_default	= OR
localityName			= Portland
organizationalUnitName_default	= CutEmAllDown
commonName			= Alrac AceAdmin
emailAddress			= carla@boardfeet.com

Now find the CA.sh script, and edit this line to tell CA.sh where to put your new certificates, giving it any name you like:

CATOP=./masterCA

Now change to the directory you want to store your CA in, typically /etc/ssl/, and run the CA.sh script:

# CA.sh -newca

This creates the /etc/ssl/masterCA/ directory, and populates it with all manner of files and directories, including your new server CA, private/cakey.pem. You'll be asked to create a passphrase, which you must write down and keep in a safe place.

Now create the certificate requests for the server, and individual ones for each client:

# openssl req -new -nodes -out logserver_req.pem -keyout logserver.pem
# openssl req -new -nodes -out client1_req.pem -keyout client1.pem
# openssl req -new -nodes -out client2_req.pem -keyout client2.pem

Now each one must be signed by your certificate authority:

# openssl ca -out logserver_cert.pem -infiles logserver_req.pem
# openssl ca -out client1_cert.pem -infiles client1_req.pem
# openssl ca -out client2_cert.pem -infiles client2_req.pem

There are a couple more steps before your shiny new certificates are usable. First, place logserver_cert.pem in /etc/stunnel on the server, and put every client key into each client's /etc/stunnel directory.

Each certificate contains a private key and the certificate itself. The server and client certificate portions need to be exchanged, so that the server has a copy of every client certificate, and every client has a copy of the server certificate. So first copy the certificate portion from every client certificate, and place them all into a single file for the server and store it in /etc/stunnel. The certificate is the bit between

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

You can call this file anything you want; I use client_cert.pem. Then you need to delete the private key from a copy of logserver_cert.pem, and place copies on every client in /etc/stunnel.

Configure Stunnel
Finally we get to configure Stunnel. You'll need to edit /etc/stunnel/stunnel.conf. If your installer didn't create one, look for an example file to use. Add these options, using your own server IP, port numbers, and certificate names:

#stunnel.cnf for the logserver
cert = /etc/stunnel/logserver_cert.pem
CAfile = /etc/stunnel/client_cert.pem
verify = 3
[5140]
    accept = 192.168.1.10:5140
    connect = 127.0.0.1:514

#stunnel.cnf for all clients
client = yes
cert = /etc/stunnel/client_cert.pem
CAfile = /etc/stunnel/logserver_cert.pem
verify = 3
[5140]
    accept = 127.0.0.1:514
    connect = 192.168.1.10:5140

 

Syslog-ng.conf
Finally, your syslog-ng.conf file will need a few additions on both clients and server. (These lines reference the examples in both part 1 and part 2.) On the clients, add these lines:

destination d_stunnel {tcp("127.0.0.1" port(514));};
log {source(s_local);destination(d_stunnel);};

The server needs these lines:

source s_stunnel {tcp(ip("127.0.0.1");port(514));};
log {source(s_stunnel); destination(d_clients);};

Start up stunnel by running the stunnel command, and fire up syslog-ng if it isn't running already. Run some tests with the logger command (see Part 1), and there you are, running your own nicely secured remote logging server.

Resources
 

[syslog-ng]Configure syslog-ng to act as a central logging server

This is the base config file I'm working with..Note: i'm using unix_stream. Should I be using unix_dgram since im on a 2.6x kernel?  I'm reading through the section on syslog-ng in the book
"Building Secure Server with Linux", and it mentions something about using "unix-dgram" .. note the "-" instead of "_".  I'm assuming its a typo and should be "_".------

source s_sys { file ("/proc/kmsg" log_prefix("kernel: "));
unix_stream("/dev/log"); internal(); };

destination d_cons { file("/dev/console"); };
destination d_mesg { file("/var/log/messages"); };
destination d_auth { file("/var/log/secure"); };
destination d_mail { file("/var/log/maillog"); };
destination d_spol { file("/var/log/spooler"); };
destination d_boot { file("/var/log/boot.log"); };
destination d_cron { file("/var/log/cron"); };
destination d_mlal { usertty("*"); };

filter f_filter1     { facility(kern); };
filter f_filter2     { level(info) and
                     not (facility(mail)
                        or facility(authpriv) or facility(cron)); };
filter f_filter3     { facility(authpriv); };
filter f_filter4     { facility(mail); };
filter f_filter5     { level(emerg); };
filter f_filter6     { facility(uucp) or
                     (facility(news) and level(crit)); };
filter f_filter7     { facility(local7); };
filter f_filter8     { facility(cron); };

#log { source(s_sys); filter(f_filter1); destination(d_cons); };
log { source(s_sys); filter(f_filter2); destination(d_mesg); };
log { source(s_sys); filter(f_filter3); destination(d_auth); };
log { source(s_sys); filter(f_filter4); destination(d_mail); };
log { source(s_sys); filter(f_filter5); destination(d_mlal); };
log { source(s_sys); filter(f_filter6); destination(d_spol); };
log { source(s_sys); filter(f_filter7); destination(d_boot); };
log { source(s_sys); filter(f_filter8); destination(d_cron); };
 

[syslog-ng]Configure syslog-ng to act as a central logging server

Where can I find documentation that will give me information on how to accept logs from remote hosts and have each of the hosts log to their own file?

destination hosts {
file("/var/syslog/HOSTS/$HOST/$YEAR/$MONTH/$HOST-$FACILITY-$YEAR$MONTH$DAY"

owner(bob) group(llamafood) perm(0755) dir_perm(0755) create_dirs(yes));

};

[Jun 21, 2005]  Windows event logs to syslog

Syslog-ng 1.6.7 package for Solaris 10, Sparc platform

Recommended Links

Configuration examples

Etc

 

Recommended Papers

Mick's syslog-ng chroot howto

Using syslog-ng and Stunnel for a Centralized, Secure Log Server

Article Explains Technique in a Step-by-step Approach A featured article on Sun's BigAdmin Web site by Amy Rich describes how to create a centralized secure log server by using syslog-ng and Stunnel. She covers everything from installing Stunnel and syslog-ng to creating certificate files for syslog-ng over Stunnel, as well as configuring both these tools.

Rich begins by addressing the issue of uncollected information that is compiled with syslog daemon due to time and staff constraints. Centralized logging assists in this matter, however, she acknowledges that syslogd hasn't seen much development since its original implementation and does not address all issues.

"...most centralized log servers using the stock syslog daemon wind up with monolithic log files that are only processed after the syslogd processes close them," Rich writes. "As a result, most sites that centralize logging also wind up replacing the stock syslog daemon with something more secure and more flexible such as Metalog, msyslog, or something similar."

Rich then explains the benefits of syslog-ng, and how when run on each UNIXR host, it encrypts the logging channel with IPSec or the utility Stunnel ensuring its security. She describes the interworkings of Stunnel and its process with SSL sessions and the syslog server. She writes, "In the case of syslog-ng, Stunnel works by accepting log connections on a local port, wrapping them in SSL sessions, and then redirecting them to a secure port on the remote log host. The stunnel process on the remote log host then decrypts the SSL session and hands the information back to the syslog server on the standard port. Once on the log server, organization and parsing of the log files then takes place using the flexibility of syslog-ng."

The article continues by taking the reader through a step-by-step process of installing and configuring syslog-ng and Stunnel on systems running the SolarisTM 8 Operating System (Solaris OS) (SPARCR Platform Edition), with code examples.

To read Rich's complete article, visit:

http://www.sun.com/bigadmin/features/articles/syslog_ng.html

Linux Journal On-Line

Stealthful Logging

Now it's time to combine the previous two techniques in a third one: stealth logging. Normally, a central log server runs syslog or syslog-ng. And indeed, it's possible to capture log packets via a non-IP-addressed interface with Snort and pass them to syslog or syslog-ng. However, it's a lot simpler to let Snort write the packets to a log file itself. The method I'm about to describe uses Snort, tail and awk instead of a traditional logger (on the central logserver, that is; on hosts that send logs you'll still need to configure syslog or syslog-ng as described below).

Suppose you have a LAN segment with several servers whose log messages you'd like sent to a single log server. Suppose further that you're far less concerned with the confidentiality of these log messages than with their integrity. You don't care if anybody eavesdrops the messages, but you don't want the messages tampered with once they've been received by the central log server. Your log server, therefore, is connected to the LAN via a non-IP-addressed interface and will sniff log packets sent to a bogus IP address on the LAN.

Configuring Your Hosts to Send Logs to the Stealth Logger

On each server from which you wish to send logs, you'll need to do two things. The first step is to configure each sender's system logger to send its messages to the bogus IP. By ``bogus'', I only mean that no host actually has that IP address; it must be valid for the LAN in question. Suppose our example LAN's network address is 192.168.1.0/24 and our bogus logger-host address is 192.168.1.111. Servers on the LAN that use standard syslog will each need a line like this in /etc/syslog.conf:

*.info @192.168.1.111
 

On servers that use syslog-ng, you'll need several lines in /etc/syslog-ng/syslog-ng.conf, like these:

destination d_loghost { udp(ip(192.168.1.111)
port(514)); };
filter f_info { level(info); };
log { filter(f_info); destination(d_loghost); };

In either case you may wish to specify different criteria from simply saying ``all messages whose severity is ‘info' or higher'', as shown in the above two examples.

Besides the appropriate lines in its logger's configuration file, each log sender will also need a static ARP entry for the bogus IP address. If your LAN consists of a hub or a series of ``cascaded'' hubs, this ARP address also can be bogus. If your LAN is switched, you'll instead need to specify the real MAC address (hardware address) of the log server. The command to add a static ARP entry on our example log-sending servers is:

arp -s 192.168.1.111 00:04:C2:56:54:58

where 192.168.1.111 is our bogus log-host IP, and 00:04:C2:56:54:58 is either a bogus MAC address or the real MAC address of our stealth logger's non-IP-addressed interface.

Now each server on our protected LAN is configured to send its logs to 192.168.1.111, and in the case of a switched LAN, they'll be sent to the stealth logger's switch port. Now all we need to do is configure the stealth logger itself

[Jun 22nd, 1999] Syslog-ng  Syslog-ng By Balazs Scheidler --Historically important paper from LG #43

Reference

Man page

syslog-ng [ -dFsvVy ] [ -f <config-filename> ] [ -p <pid-filename> ] [ -C <chroot-dir> ] [ -u <user> ] [ -g <group> ]  

DESCRIPTION

syslog-ng reads and logs messages to the system console, log files, other machines and/or users as specified by its configuration file.

The configuration file is read at startup and is reread after receipt of a hangup (HUP) signal. When reloading the configuration file, all destination files are closed and reopened as appropriate. For more information about the configuration file, see syslog-ng.conf(5).

Typically messages are sent to syslog-ng via a Unix domain socket (/dev/log) or via UDP, to port 514 or to whatever syslog/udp is defined to be in /etc/services. To receive messages from the kernel, /dev/klog is opened for reading.

Messages sent to syslog-ng should be an entire line, prefixed by a priority code in between '<' and '>'. Definititions of the recognised values can be found in the include file <sys/syslog.h>.

syslog-ng can be configured to pass messages on to other syslog-ng's and when doing so, it sends the message on with the priority as a prefix.

It is not necessary to terminate a message with a line feed or carriage return.

 

OPTIONS

-C  <directory>, --chroot=<directory>
Chroot to directory.
-d, --debug
Set "debug mode". Prints out various messages to aid in debugging and stops it from becoming a daemon.
-y, --yydebug
Enable debugging messages in the yacc parser, this option is only present if syslog-ng was compiled in debugging mode (--enable-debug configure option).
-F, --foreground
Don't fork into background.
-f  <filename>, --cfgfile=<filename>
Instead of reading the normal /etc/syslog-ng/syslog-ng.conf file for configuration information, use the filename given instead.
-g  <group>, --group=<group>
Switch to group.
-p  <filename>, --pidfile=<filename>
Write the current PID information to the specified file. Defaults to /var/run/syslog-ng.pid.
-s, --syntax-only
Only read and parse the configuration file. See also the option -f.
-u  <user>, --group=<user>
Switch to user.
-v, --verbose
Enable verbose mode. Prints out fewer messages, compared to -d.
-V, --version
Print the version number.
 

DIAGNOSTICS

It is expected that syslog-ng will run as root, however, if not running on a priviledged port of it it owned its own log directories, etc, it might run as a non-root user.  

SEE ALSO

syslog-ng.conf(5), logger(1), syslog(2), syslog(3), services(5), syslog.conf(5), klogd(8), syslogd(8), sysklogd(8)  

FILES

/etc/syslog-ng/syslog-ng.conf
Configuration file for syslog-ng. See syslog-ng.conf(5) for more information.
/var/run/syslog-ng.pid
The file containing the process id of syslog-ng.
 

BUGS

If you find any, please send email to the syslog-ng mailing list at syslog-ng@lists.balabit.hu

Etc

Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Disclaimer:

Last modified: August 09, 2009