Add new files

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@843 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-12-13 18:13:49 +00:00
parent 3783c77ff2
commit 8e54f47816
2 changed files with 235 additions and 0 deletions

118
Shorewall-docs/Accounting.html Executable file
View File

@ -0,0 +1,118 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Shorewall Accounting</title>
<meta name="author" content="Tom Eastep">
</head>
<body>
<h1 style="text-align: center;">Shorewall and Traffic Accounting<br>
</h1>
Shorewall Traffic Accounting support was added in Shorewall release
1.4.7.<br>
<br>
Shorewall accounting rules are described in the file
/etc/shorewall/accounting. By default, the accounting rules are placed
in a chain called "accounting" and can thus be displayed using
"shorewall show accounting". All traffic passing into, out of or
through the firewall traverses the accounting chain including traffic
that will later be rejected by <a href="Documentation.htm#Interfaces">interface
options</a> such as "tcpflags" and "maclist". If your kernel doesn't
support the connection tracking match extension (Kernel 2.4.21) then
some traffic rejected under 'norfc1918' will not traverse the
accounting chain.<br>
<br>
The columns in the accounting file are as follows:<br>
<ul>
<li><span style="font-weight: bold;">ACTION</span> - What to do when
a
match is found. Possible values are:</li>
<ul>
<li>COUNT- Simply count the match and&nbsp; continue trying to
match the
packet with the following accounting rules</li>
<li>DONE- Count the match and don't attempt to match any following
accounting rules.</li>
<li>&lt;<span style="font-style: italic;">chain</span>&gt; - The
name of a chain to jump to. Shorewall will create the chain
automatically. If the name of the chain is followed by ":COUNT" then a
COUNT rule matching this rule will automatically be added to &lt;<span
style="font-style: italic;">chain</span>&gt;. Chain names must start
with a letter, must be composed of letters and digits, and may contain
underscores ("_") and periods ("."). Beginning with Shorewall version
1.4.8, chain names man also contain embedded dashes ("-") and are not
required to start with a letter.<br>
</li>
</ul>
<li><span style="font-weight: bold;">CHAIN </span>- The name of the
chain where the accounting rule is to be added. If empty or "-" then
the
"accounting" chain is assumed.<br>
</li>
<li><span style="font-weight: bold;">SOURCE</span> - Packet Source.
The name of an interface, an address (host or net) or an interface name
followed by ":" and a host or net address.</li>
<li><span style="font-weight: bold;">DESTINATION</span> - Packet
Destination Format the same as the SOURCE column.</li>
<li><span style="font-weight: bold;">PROTOCOL</span> - A protocol
name
(from /etc/protocols) or a protocol number.</li>
<li><span style="font-weight: bold;">DEST PORT</span> - Destination
Port number. Service name from /etc/services or port number. May only
be
specified if the protocol is TCP or UDP (6 or 17).</li>
<li><span style="font-weight: bold;">SOURCE PORT</span>- Source Port
number. Service name from /etc/services or port number. May only be
specified if the protocol is TCP or UDP (6 or 17).<br>
</li>
</ul>
In all columns except ACTION and CHAIN, the values "-","any" and "all"
are treated as wild-cards.<br>
&nbsp;<br>
The accounting rules are evaluated in the Netfilter 'filter' table.
This is the same environment where the 'rules' file rules are evaluated
and in this environment, DNAT has already occurred in inbound packets
and SNAT has not yet occurred on outbound ones.<br>
&nbsp;<br>
Accounting rules are not stateful -- each rule only handles traffic in
one direction. For example, if eth0 is your internet interface and you
have a web server in your DMZ connected to eth1 then to count HTTP
traffic in both directions requires two rules:&nbsp;<br>
<pre> #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE<br> # PORT PORT<br> DONE - eth0 eth1 tcp 80<br> DONE - eth1 eth0 tcp - 80</pre>
Associating a counter with a chain allows for nice reporting. For
example:<br>
<pre> #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE<br> # PORT PORT<br> web:COUNT - eth0 eth1 tcp 80<br> web:COUNT - eth1 eth0 tcp - 80<br> web:COUNT - eth0 eth1 tcp 443<br> web:COUNT - eth1 eth0 tcp - 443<br> DONE web<br></pre>
Now "shorewall show web" will give you a breakdown of your web traffic:<br>
<div style="margin-left: 40px;">
<pre>[root@gateway shorewall]# shorewall show web<br>Shorewall-1.4.6-20030821 Chain web at gateway.shorewall.net - Wed Aug 20 09:48:56 PDT 2003<br> <br>Counters reset Wed Aug 20 09:48:00 PDT 2003<br> <br>Chain web (4 references)<br> pkts bytes target prot opt in out source destination<br> 11 1335 tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:80<br> 18 1962 tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80<br> 0 0 tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:443<br> 0 0 tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443<br> 29 3297 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0<br>[root@gateway shorewall]#</pre>
</div>
Here's a slightly different example:<br>
<pre> #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE<br> # PORT PORT<br> web - eth0 eth1 tcp 80<br> web - eth1 eth0 tcp - 80<br> web - eth0 eth1 tcp 443<br> web - eth1 eth0 tcp - 443<br><br> COUNT web eth0 eth1<br> COUNT web eth1 eth0<br></pre>
Now "shorewall show web" simply gives you a breakdown by input and
output:<br>
<br>
<pre style="margin-left: 40px;">[root@gateway shorewall]# shorewall show accounting web <br>Shorewall-1.4.6-20030821 Chains accounting web at gateway.shorewall.net - Wed Aug 20 10:27:21 PDT 2003<br> <br>Counters reset Wed Aug 20 10:24:33 PDT 2003<br> <br>Chain accounting (3 references)<br> pkts bytes target prot opt in out source destination<br> 8767 727K web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:80<br> 0 0 web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:443<br>11506 13M web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80<br> 0 0 web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443<br>Chain web (4 references)<br> pkts bytes target prot opt in out source destination<br> 8767 727K all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0<br>11506 13M all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0<br>[root@gateway shorewall]#<br></pre>
Here's how the same example would be constructed on an HTTP server
(READ THAT FOLKS -- IT SAYS <span style="text-decoration: underline;"><span
style="font-weight: bold;">SERVER</span></span>. If you want to
account for web browsing, you have to reverse the rules below) with
only
one interface (eth0):<br>
<pre style="margin-left: 40px;">#ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE<br># PORT PORT<br>web - eth0 - tcp 80<br>web - - eth0 tcp - 80<br>web - eth0 - tcp 443<br>web - - eth0 tcp - 443<br><br>COUNT web eth0 -<br>COUNT web - eth0<br></pre>
Note that with only one interface, only the SOURCE (for input rules) or
the DESTINATION (for output rules) is specified in each rule.<br>
<br>
Here's the output:<br>
<pre style="margin-left: 40px;">[root@mail shorewall]# shorewall show accounting web <br>Shorewall-1.4.7 Chains accounting web at mail.shorewall.net - Sun Oct 12 10:27:21 PDT 2003<br> <br>Counters reset Sat Oct 11 08:12:57 PDT 2003<br> <br>Chain accounting (3 references)<br> pkts bytes target prot opt in out source destination<br> 8767 727K web tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80<br> 0 0 web tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443<br>11506 13M web tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80<br> 0 0 web tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443<br>Chain web (4 references)<br> pkts bytes target prot opt in out source destination<br> 8767 727K all -- eth0 * 0.0.0.0/0 0.0.0.0/0<br>11506 13M all -- * eth0 0.0.0.0/0 0.0.0.0/0<br>[root@mail shorewall]#<br></pre>
<p align="left"><font size="2">Last updated 12/06/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2003 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
</body>
</html>

View File

@ -0,0 +1,117 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<title>User-defined Actions</title>
<meta name="author" content="Tom EAstep">
</head>
<body>
<h1 style="text-align: center;">User-defined Actions</h1>
<br>
Prior to Shorewall version 1.4.9, rules in /etc/shorewall/rules were
limited to those defined by Netfilter (ACCEPT, DROP, REJECT, etc.).
Beginning with Shorewall version 1.4.9, users may use sequences of
these elementary operations to define more complex actions.<br>
<br>
To define a new action:<br>
<ol>
<li>Add a line to /etc/shorewall/actions that names your new action.
Action names must be valid shell variable names as well as valid
Netfilter chain names. It is recommended that the name you select for a
new action begins with with a capital letter; that way, the name won't
conflict with a Shorewall-defined chain name.<br>
</li>
<li>Once you have defined your new action name (ActionName), then
copy /etc/shorewall/action.template to /etc/shorewall/action.ActionName
(for example, if your new action name is "Foo" then copy
/etc/shorewall/action.template to /etc/shorewall/action.foo).</li>
<li>Now modify the new file to define the new action.</li>
</ol>
Columns in the action.template file are as follows.<br>
<br>
<ul>
<li>TARGET - Must be ACCEPT, DROP, REJECT, LOG, QUEUE or
&lt;action&gt; where &lt;action&gt; is a previously-defined action. The
TARGET may optionally be followed by a colon (":") and a syslog log
level (e.g, REJECT:info or ACCEPT:debugging). This causes the packet to
be logged at the specified level. You may also specify ULOG (must be in
upper case) as a log level.This will log to the ULOG target for routing
to a separate log through use of ulogd
(http://www.gnumonks.org/projects/ulogd).<br>
<br>
</li>
<li>SOURCE - Source hosts to which the rule applies. A
comma-separated list of subnets and/or hosts. Hosts may be specified by
IP or MAC address; mac addresses must begin with "~" and must use "-"
as a separator.<br>
<br>
Alternatively, clients may be specified by interface name. For example,
eth1 specifies a client that communicates with the firewall system
through eth1. This may be optionally followed by another colon (":")
and an IP/MAC/subnet address as described above (e.g.,
eth1:192.168.1.5).<br>
<br>
</li>
<li>DEST - Location of Server. Same as above with the exception that
MAC addresses are not allowed.<br>
<br>
Unlike in the SOURCE column, you may specify a range of up to 256 IP
addresses using the syntax &lt;<span style="font-style: italic;">first
ip</span>&gt;-&lt;<span style="font-style: italic;">last ip</span>&gt;.<br>
<br>
</li>
<li>PROTO - Protocol - Must be "tcp", "udp", "icmp", a number, or
"all".<br>
<br>
</li>
<li>DEST PORT(S) - Destination Ports. A comma-separated list of Port
names (from /etc/services), port numbers or port ranges; if the
protocol is "icmp", this column is interpreted as the destination
icmp-type(s).<br>
<br>
A port range is expressed as &lt;<span style="font-style: italic;">low
port</span>&gt;:&lt;<span style="font-style: italic;">high port</span>&gt;.<br>
<br>
This column is ignored if PROTOCOL = all but must be entered if any of
the following ields are supplied. In that case, it is suggested that
this field contain "-".<br>
<br>
If your kernel contains multi-port match support, then only a single
Netfilter rule will be generated if in this list and the CLIENT PORT(S)
list below:<br>
1. There are 15 or less ports listed.<br>
2. No port ranges are included.<br>
Otherwise, a separate rule will be generated for each port.<br>
<br>
</li>
<li>RATE LIMIT - You may rate-limit the rule by placing a value in
this columN:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
<br>
where &lt;rate&gt; is the number of connections per &lt;interval&gt;
("sec" or "min") and &lt;burst&gt; is the largest burst permitted. If
no &lt;burst&gt; is given, a value of 5 is assumed. There may be no
whitespace embedded in the specification.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Example: 10/sec:20</li>
</ul>
Example:<br>
<br>
/etc/shorewall/actions:<br>
<br>
LogAndAccept<br>
<br>
/etc/shorewall/action.LogAndAccept<br>
<br>
LOG:info<br>
ACCEPT<br>
<p align="left"><font size="2">Last Updated 12/09/2003 - <a
href="file:///Z:/Shorewall-docs/support.htm">Tom Eastep</a></font></p>
<a href="file:///Z:/Shorewall-docs/copyright.htm"><font size="2">Copyright</font>
&copy; <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</body>
</html>