. HIDS and NIDS ( intrusion detection systems,a.k.a. Aside from blank lines and comment lines, syslog.confhas rule lines, with two parts:.
Contribute to balabit/syslog-ng-3.5 development by creating an account on GitHub. Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un.x-like operating systems. Join them; it only takes a minute.
The first part says what to log (that is, it is a filter calledthe selector).
SummaryThis article describes how to help syslog-ng developers to diagnose and fix syslog-ng crash problems. Compile with debug symbolsIf you are compiling syslog-ng from source, include debug symbols using the '-enable-debug' configuration option or by passing the '-g' flag in the 'CFLAGS' and 'LDFLAGS' environment variables. This will produce a slightly larger syslog-ng binary which contains debug symbols. Dependencies should also be compiled with debug symbols. For most distributions debug information is contained in an additional package with a -dbg (Debian),-dbgsym (ubuntu) -debuginfo (Fedora/openSUSE) suffix. Generating a core fileWhen syslog-ng crashes and the ulimit -c resource limit is set to unlimited or a large enough value, the operating system produces a core file upon crash.
The location of the core file depends on how syslog-ng was started:. if started in the background, then the location of the PID file (usually /var/run/syslog-ng for OSE or /opt/syslog-ng/var for PE). if started in the foreground, then the current directoryMake sure that the syslog-ng process has appropriate write permissions in this directory.The name of the core file is somewhat OS dependent, it is usually simply named 'core', but variations that include the pid number also exist. Generating a backtraceOnce you have a binary that has debug symbols and a core file containing the memory map of the crash, you can generate a backtrace using gdb (the GNU Debugger) like this$ gdb /sbin/syslog-ng -c core(gdb) bt full. Backtrace output.Post the backtrace to syslog-ng GitHub issues at as an attachment, or send it to the syslog-ng mailing list. The developers of syslog-ng might request additional information; sometimes the complete core file is required to diagnose the problem.
Additional information. GDB documentation:.
Wikipedia page on core dumps. This depends on the configuration of syslog-ng, the hardware running syslog-ng, and the exact situation and environment. The limits of the throughput of syslog-ng are similar to the limits of other network applications. When sizing the hardware required for syslog-ng, try to estimate the log traffic to be processed and the parsing and filtering complexity to be applied.The main limiting factors are the following:. Network bandwith.
Disk I/O. CPU (only in you have complex parsing and filtering setup)Other limiting factors are:. SSL, as it is very CPU intensive.
database destinations, as due to their complexity they can handle a lot less traffic than plain text filesAdditional informationFor more details, check!(Obsolete, / and /usr is merged in distributions). Yes, this is possible, if you can get the packaging system of your Linux/UNIX operating system to install both syslog-ng and syslogd at the same time. The syslog-ng application can be configured not to process locally generated messages, and local syslogd can be configured to send all log messages to syslog-ng using the UDP protocol using the following configuration line:. @127.0.0.1Please note that syslogd might open the syslog UDP port automatically, in which case the above configuration will cause all syslog messages to be resent to itself, causing an endless loop.The syslog-ng application can accept messages from syslogd using the 'udp' source.One can also use a named pipe to send logs to syslog-ng. From man syslogd: This version of syslogd(8) has support for logging output to named pipes (fifos). A fifo or named pipe can be used as adestination for log messages by prepending a pipe symbol (' ') to the name of the file. This is handy for debugging.Note that the fifo must be created with the mkfifo(1) command before syslogd(8) is started.
Yes, by default syslog-ng has a supervisor process, which monitors the child. If the child crashes, the supervisor process automatically restarts it. Its behavior is controlled by the command line: '-process-mode=' The default is 'safe-background' which enables the supervisor. The other two disables it. In practice the child is the main process, the supervisor is only there to restart it in the following cases:. it was killed by a signal. it exited with a non-zero return valueWhen shutting down syslog-ng, the child process needs to receive a TERM signal, which will exit with a zero return value and also brings away the supervisor process.
QuestionCan I use AppArmor with syslog-ng? AnswerYes, with some limitations. Those Linux distributions, which have AppArmor enabled, have also a profile for syslog-ng, which covers the syslog-ng version and configuration included in the distribution. What it means in practice, that syslog-ng installed from distribution sources and using default configuration works fine, and enjoys AppArmor protection. As soon as one starts to change syslog-ng.conf it is easy to run into problems.
AppArmor protection is based on directory and file names. If syslog-ng is not installed to the distribution default location, usually '/sbin/syslog-ng', then syslog-ng is not protected / limited by AppArmor. Modifying AppArmor settingsAppArmor settings for different applications are stored in so called 'profiles'. These can usually be found in the directory called '/etc/apparmor.d/'. Profile names are derived from from path and application names, just slashes are replaced by dots. So for syslog-ng it is usually 'sbin.syslog-ng'. It has usually some comments and copyright info at top, then some includes, capabilities and then access control to files and directories.
This is where additional entries should be added, if log files outside of /var/log should be read or written by syslog-ng. For example to write logs to '/opt/myapp/logs/iwantlogshere.log' add the following line: /opt/myapp/logs/iwantlogshere.log rw, Or if only read-only access is necessary, as the file is read by syslog-ng, processed and forwarded somewhere, then replace 'rw' with 'r'. Once a profile is modified, AppArmor should be restarted. There are some advanced syslog-ng features, for which it is quite difficult to add AppArmor protection. A prime example is the program destination, where the called application either runs unprotected or a separate profile needs to be created. Calling external applications is tested to work with AppArmor v2.5 but did not work at all with version 2.3. See 'man apparmor.d' for details on different execution permissions.