From d1bcb442eb4a7a0248a4d53abdfb3873c84dfb69 Mon Sep 17 00:00:00 2001 From: teastep Date: Thu, 18 Dec 2003 21:16:57 +0000 Subject: [PATCH] Convert shorewall_logging.html to XML git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@888 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/shorewall_logging.html | 180 ---------------- Shorewall-docs/shorewall_logging.xml | 284 ++++++++++++++++++++++++++ 2 files changed, 284 insertions(+), 180 deletions(-) delete mode 100644 Shorewall-docs/shorewall_logging.html create mode 100644 Shorewall-docs/shorewall_logging.xml diff --git a/Shorewall-docs/shorewall_logging.html b/Shorewall-docs/shorewall_logging.html deleted file mode 100644 index 493933164..000000000 --- a/Shorewall-docs/shorewall_logging.html +++ /dev/null @@ -1,180 +0,0 @@ - - - - Shorewall Logging - - - - -

Logging

-

How to Log Traffic through a Shorewall Firewall

-The disposition of packets entering a Shorewall firewall  is -determined by one of a number of Shorewall facilities. Only some of -these facilities permit logging.
-
    -
  1. The packet is part of an established connection. The packet is -accepted and cannot be logged.
    2. -
  2. The packet represents a connection request that is related to an -established connection (such as a data connection -associated with an FTP control connection).  These packets -also cannot be logged.
    3. -
  3. The packet is rejected because of an option in /etc/shorewall/shorewall.conf or /etc/shorewall/interfaces. -These packets can be logged by setting the appropriate logging-related -option in /etc/shorewall/shorewall.conf.
    4. -
  4. The packet matches a rule in /etc/shorewall/rules. -By including a syslog level (see below) in the ACTION column of a rule -(e.g., "ACCEPT:info -net fw tcp 22"), the connection attempt will be logged at that level.
    5. -
  5. The packet doesn't match a rule so is handled by a policy defined -in /etc/shorewall/policy. These -may be logged by specifying a syslog level in the LOG LEVEL column of -the policy entry (e.g., "loc net ACCEPT info"
    -
    6. -
-

Where the Traffic is logged and how to Change the Destination
-

-By default, Shorewall directs NetFilter to log using syslog (8). Syslog -classifies log messages by a facility and a priority -(using the notation facility.priority).
-
-The facilities defined by syslog are auth, authpriv, cron, daemon, -kern, lpr, mail, mark, news, syslog, user, uucp and local0 -through local7.
-
-Throughout the Shorewall documentation, I will use the term level -rather than priority since level is the term used by -NetFilter. The syslog documentation uses the term priority.
-

Syslog Levels
-

-Syslog levels are a method of describing to syslog (8) the importance -of a message and a number of Shorewall parameters have a syslog level -as their value.
-
-Valid levels are:
-
-       -7       debug -(Debug-level messages)
-       -6       info -(Informational)
-       -5       notice -(Normal but significant Condition)
-       -4       -warning (Warning Conditions)
-       -3       err -(Error Conditions)
-       -2       crit -(Critical Conditions)
-       -1       alert -(Must be handled immediately)
-       -0       emerg -(System is unusable)
-
-For most Shorewall logging, a level of 6 (info) is appropriate. -Shorewall log messages are generated by NetFilter and are logged using -the kern facility and the level that you specify. If you are -unsure of the level to choose, 6 (info) is a safe bet. You may specify -levels by name or by number.
-
-Syslogd writes log messages to files (typically in /var/log/*) -based on their facility and level. The mapping of these facility/level -pairs to log files is done in /etc/syslog.conf (5). If you make changes -to this file, you must restart syslogd before the changes can take -effect.
-

Configuring a Separate Log for Shorewall Messages

-There are a couple of limitations to syslogd-based logging:
-
    -
  1. If you give, for example, kern.info it's own log destination then -that destination will also receive all kernel messages of levels 5 -(notice) through 0 (emerg).
    2. -
  2. All kernel.info messages will go to that destination and not just -those from NetFilter.
    -
    3. -
-Beginning with Shorewall version 1.3.12, if your kernel has ULOG target -support (and most vendor-supplied kernels do), you may also specify a -log level of ULOG (must be all caps). When ULOG is used, Shorewall will -direct netfilter to log the related messages via the ULOG target which -will send them to a process called 'ulogd'. The ulogd program is -available from http://www.gnumonks.org/projects/ulogd and can be -configured to log all Shorewall message to their own log file.
-
-Note: The ULOG logging mechanism is completely separate -from syslog. Once you switch to ULOG, the settings in /etc/syslog.conf -have -absolutely no effect on your Shorewall logging (except for Shorewall -status -messages which still go to syslog).
-
-You will need to have the kernel source available to compile ulogd.
-
-Download the ulod tar file and:
-
    -
  1. Be sure that /usr/src/linux is linked to your kernel source tree
    -
    2. -
  2. cd /usr/local/src (or wherever you do your builds)
    3. -
  3. tar -zxf source-tarball-that-you-downloaded
    4. -
  4. cd ulogd-version
    -
    5. -
  5. ./configure
    6. -
  6. make
    7. -
  7. make install
    -
    8. -
-If you are like me and don't have a development environment on your -firewall, you can do the first six steps on another system then either -NFS -mount your /usr/local/src directory or tar up the /usr/local/src/ulogd-version -directory and move it to your firewall system.
-
-Now on the firewall system, edit /usr/local/etc/ulogd.conf and set:
-
    -
  1. syslogfile <file that you wish to log to>
    2. -
  2. syslogsync 1
    3. -
-Also on the firewall system:
-
touch <file that you wish to log to>
-
-I also copied the file /usr/local/src/ulogd-version/ulogd.init -to /etc/init.d/ulogd. I had to edit the line that read "daemon -/usr/local/sbin/ulogd" to read daemon /usr/local/sbin/ulogd -d". On a -RedHat system, a simple -"chkconfig --level 3 ulogd on" starts ulogd during boot up. Your init -system -may need something else done to activate the script.
-
-You will need to change all instances of log levels (usually 'info') in -your configuration files to 'ULOG' - this includes entries in the -policy, rules and shorewall.conf files. Here's what I have:
-
	[root@gateway shorewall]# grep ULOG *
	policy:loc  fw   REJECT  ULOG
	policy:net  all  DROP    ULOG   10/sec:40
	policy:all  all  REJECT  ULOG
	rules:REJECT:ULOG loc net tcp 6667
	shorewall.conf:TCP_FLAGS_LOG_LEVEL=ULOG
	shorewall.conf:RFC1918_LOG_LEVEL=ULOG
	[root@gateway shorewall]#
-Finally edit /etc/shorewall/shorewall.conf and set LOGFILE=<file -that you wish to log to>. This tells the /sbin/shorewall program -where to look for the log when processing its "show log", "logwatch" -and -"monitor" commands.
-

Syslog-ng

-Here -is a post describing configuring syslog-ng to work with Shorewall.
-

Updated 10/30/2003 - Tom -Eastep -

-

Copyright © 2001, 2002, 2003 Thomas M. Eastep
-

-
-
- - diff --git a/Shorewall-docs/shorewall_logging.xml b/Shorewall-docs/shorewall_logging.xml new file mode 100644 index 000000000..3928615cb --- /dev/null +++ b/Shorewall-docs/shorewall_logging.xml @@ -0,0 +1,284 @@ + + +
+ + Shorewall Logging + + + + Tom + + Eastep + + + + 2003-12-18 + + + 2001 - 2003 + + Thomas M. Eastep + + + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, Version + 1.2 or any later version published by the Free Software Foundation; with + no Invariant Sections, with no Front-Cover, and with no Back-Cover + Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". + + + +
+ How to Log Traffic Through a Shorewall Firewall + + The disposition of packets entering a Shorewall firewall is + determined by one of a number of Shorewall facilities. Only some of these + facilities permit logging. + + + + The packet is part of an established commection. The packet is + accepted and connot be logged. + + + + The packet represents a connection request that is related to an + established connection (such as a data + connection associated with an FTP control connection). These + packets also cannot be logged. + + + + The packet is rejected because of an option in /etc/shorewall/shorewall.conf or + /etc/shorewall/interfaces. + These packets can be logged by setting the appropriate logging-related + option in /etc/shorewall/shorewall.conf. + + + + The packet matches a rule in /etc/shorewall/rules. By + including a syslog level (see below) in the ACTION column of a rule + (e.g., "ACCEPT:info net fw tcp + 22"), the connection attempt will be logged at that level. + + + + The packet doesn't match a rule so it is handled by a policy + defined in /etc/shorewall/policy. + These may be logged by specifying a syslog level in the LOG LEVEL + column of the policy's entry (e.g., "loc net ACCEPT info"). + + +
+ +
+ Where the Traffic is Logged and How to Change the Destination + + By default, Shorewall directs NetFilter to log using syslog (8). + Syslog classifies log messages by a facility and a + priority (using the notation facility.priority). + + The facilities defined by syslog are auth, authpriv, cron, + daemon, kern, lpr, mail, mark, news, syslog, user, uucp and + local0 through local7. + + Throughout the Shorewall documentation, I will use the term + level rather than priority since + level is the term used by NetFilter. The syslog + documentation uses the term priority. + +
+ Syslog Levels + + Syslog levels are a method of describing to syslog (8) the + importance of a message. A number of Shorewall parameters have a syslog + level as their value. + + Valid levels are: + + + 7 - debug (Debug-level + messages) + + 6 - info (Informational) + + 5 - notice (Normal but + significant Condition) + + 4 - warning (Warning + Condition) + + 3 - err (Error Condition) + + 2 - crit (Critical + Conditions) + + 1 - alert (must be handled + immediately) + + 0 - emerg (System is + unusable) + + + For most Shorewall logging, a level of 6 (info) is appropriate. + Shorewall log messages are generated by NetFilter and are logged using + the kern facility and the level that you specify. + If you are unsure of the level to choose, 6 (info) is a safe bet. You + may specify levels by name or by number. + + Syslogd writes log messages to files (typically in /var/log/*) + based on their facility and level. The mapping of these facility/level + pairs to log files is done in /etc/syslog.conf (5). If you make changes + to this file, you must restart syslogd before the changes can take + effect. +
+ +
+ Configuring a Separate Log for Shorewall Messages + + There are a couple of limitations to syslogd-based logging: + + + + If you give, for example, kern.info it's own log + destination then that destination will also receive all kernel + messages of levels 5 (notice) through 0 (emerg). + + + + + + + + All kernel.info messages will go to that destination and not + just those from NetFilter. + + + + Beginning with Shorewall version 1.3.12, if your kernel has ULOG + target support (and most vendor-supplied kernels do), you may also + specify a log level of ULOG (must be all caps). When ULOG is used, + Shorewall will direct netfilter to log the related messages via the ULOG + target which will send them to a process called 'ulogd'. The + ulogd program is available from http://www.gnumonks.org/projects/ulogd + and can be configured to log all Shorewall message to their own log + file. + + + The ULOG logging mechanism is completely + separate from syslog. Once you switch to ULOG, the settings + in /etc/syslog.conf have absolutely no effect on your Shorewall + logging (except for Shorewall status messages which still go to + syslog). + + + You will need to have the kernel source available to compile + ulogd. + + Download the ulog tar file and: + + + + Be sure that /usr/src/linux is linked to your kernel source + tree + + + + cd /usr/local/src (or whereever you do your builds) + + + + tar -zxf source-tarball-that-you-downloaded + + + + cd ulod-version + + + + ./configure + + + + make + + + + make install + + + + If you are like me and don't have a development environment on + your firewall, you can do the first six steps on another system then + either NFS mount your /usr/local/src directory or tar up the + /usr/local/src/ulogd-version directory and move it + to your firewall system. + + Now on the firewall system, edit /usr/local/etc/ulogd.conf and + set: + + + + syslogfile <the file that you wish to log to> + + + + syslogsync 1 + + + + Also on the firewall system: + + + touch <the file that you wish to log to> + + + I also copied the file /usr/local/src/ulogd-version/ulogd.init + to /etc/init.d/ulogd. I had to edit the line that read "daemon + /usr/local/sbin/ulogd" to read daemon /usr/local/sbin/ulogd -d". + On a RedHat system, a simple "chkconfig --level 3 ulogd on" + starts ulogd during boot up. Your init system may need something else + done to activate the script. + + You will need to change all instances of log levels (usually + 'info') in your configuration files to 'ULOG' - this + includes entries in the policy, rules and shorewall.conf files. + Here's what I have: + + [root@gateway shorewall]# grep ULOG * + policy:loc fw REJECT ULOG + policy:net all DROP ULOG 10/sec:40 + policy:all all REJECT ULOG + rules:REJECT:ULOG loc net tcp 6667 + shorewall.conf:TCP_FLAGS_LOG_LEVEL=ULOG + shorewall.conf:RFC1918_LOG_LEVEL=ULOG + [root@gateway shorewall]# + + Finally edit /etc/shorewall/shorewall.conf and set LOGFILE=<file + that you wish to log to>. This tells the /sbin/shorewall + program where to look for the log when processing its "show + log", "logwatch" and "monitor" commands. +
+
+ +
+ Syslog-ng + + Here + is a post describing configuring syslog-ng to work with Shorewall. +
+ +
+ Understanding the Contents of Shorewall Log Messages + + Please see FAQ #17. +
+
\ No newline at end of file