Hello,
I just started working with the accounting module and I''ve run into a
problem with it when I try to get counts on specific IP addresses. I am
hosting about 6 web sites on different IP addresses and wanted to track some
info on them.
Here''s a snippet from my accounting file:
jweb:COUNT - eth0:216.17.21.68 eth1 tcp
80
jweb:COUNT - eth1 eth0:216.17.21.68 tcp
- 80
DONE jweb
allweb:COUNT - eth0 eth1 tcp 80
allweb:COUNT - eth1 eth0 tcp - 80
DONE allweb
Here''s the output from ''shorewall show jweb'':
Shorewall-1.4.7c Chain jweb at jcs-lwall02.jibben.com - Mon Oct 27 21:24:12
CST 2003
Counters reset Mon Oct 27 20:25:36 CST 2003
Chain jweb (2 references)
pkts bytes target prot opt in out source
destination
0 0 tcp -- eth0 eth1 216.17.21.68
0.0.0.0/0 tcp dpt:80
0 0 tcp -- eth1 eth0 0.0.0.0/0
216.17.21.68 tcp spt:80
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0
Here''s the output from ''shorewall show allweb'':
Shorewall-1.4.7c Chain allweb at jcs-lwall02.jibben.com - Mon Oct 27
21:23:58 CST 2003
Counters reset Mon Oct 27 20:25:36 CST 2003
Chain allweb (2 references)
pkts bytes target prot opt in out source
destination
3245 383K tcp -- eth0 eth1 0.0.0.0/0
0.0.0.0/0 tcp dpt:80
3430 3167K tcp -- eth1 eth0 0.0.0.0/0
0.0.0.0/0 tcp spt:80
6675 3550K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
eth0 is my net zone (216.17.21.64/27)
eth1 is my loc zone (10.10.1.0/24)
The two accounting reports were run after I pulled up the web site at
216.17.21.68 and reloaded it several times from a computer that is outside
of the network. I noticed that the allweb stats would go up but the jweb
stats would stay at 0. Is my syntax in the accounting file incorrect? As
you can see I''m using version 1.4.7c.
Any suggestions would be appreciated. If more information is needed, let me
know.
sj
On Mon, 27 Oct 2003, Scott Jibben wrote:> > > Any suggestions would be appreciated. If more information is needed, let me > know. >Your ''jweb'' accounting rules are nonsense. Draw yourself a picture with the IP addresses and ports -- you''ll see your error. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> Your ''jweb'' accounting rules are nonsense. Draw yourself a picture with > the IP addresses and ports -- you''ll see your error.Well, I can make it work using: jweb:COUNT - eth0 eth1:10.10.1.249 tcp 80 jweb:COUNT - eth1:10.10.1.249 eth0 tcp - 80 DONE jweb I was following something I found in a mail archive where: COUNT eth0:206.124.146.177 # Count traffic from my # server arriving on # eth0 So, I assumed that counting could be accomplished from an external address/interface. This is from an email that you wrote, so I added a similar count in my accounting file like this: jweb:COUNT - eth0:216.17.21.68 jweb:COUNT - - eth0:216.17.21.68 DONE jweb I would think that the very first packet would be from an unknown source/port to 216.17.21.68 dport:80 on eth0. That''s why I thought that the above rules would count something. Does it not work because nat/dnat rules are applied to the packet before accounting? The statement ''All traffic passing into, out of or through the firewall traverses the accounting chain including traffic that will later be rejected by interface options such as "tcpflags" and "maclist".'' looks like accounting would be handled before nat/dnat. sj
On Tue, 2003-10-28 at 00:24, Scott Jibben wrote:> > Your ''jweb'' accounting rules are nonsense. Draw yourself a picture with > > the IP addresses and ports -- you''ll see your error. > > Well, I can make it work using: > jweb:COUNT - eth0 eth1:10.10.1.249 tcp 80 > jweb:COUNT - eth1:10.10.1.249 eth0 tcp - 80 > DONE jweb > > I was following something I found in a mail archive where: > > COUNT eth0:206.124.146.177 # Count traffic from my > # server arriving on > # eth0 >Note the word "from" in the above!!! Let''s look at what you have for rules: jweb:COUNT - eth0:216.17.21.68 eth1 tcp 80 jweb:COUNT - eth1 eth0:216.17.21.68 tcp - 80 DONE jweb The first rule counts tcp traffic coming in on eth0 FROM 216.17.21.89 and going out eth1 with destination port 80. The second rule counts tcp traffic coming in on eth1 with source port 80 and going out eth0 with destination address 216.17.21.68. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Hi there,
I noticed that route filtering (both the "ROUTE_FILTER" option in
shorewall.conf and the per-interface "routefilter" option in
interfaces)
wasn''t working with Shorewall 1.4.7c on kernel 2.4.22.
The kernel documentation (linux/Documentation/networking/ip-sysctl.txt)
says this about route filtering (see the underlined portion):
rp_filter - BOOLEAN
1 - do source validation by reversed path, as specified in RFC1812
Recommended option for single homed hosts and stub network
routers. Could cause troubles for complicated (not loop free)
networks running a slow unreliable protocol (sort of RIP),
or using static routes.
0 - No source validation.
conf/all/rp_filter must also be set to TRUE to do source validation
on the interface
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Default value is 0. Note that some distributions enable it
in startup scripts.
So in addition to setting each /proc/net/conf/$i/rp_filter to 1 for each
interface $i that I wanted to filter routes, I also needed to set
/proc/net/conf/all/rp_filter to 1.
What''s strange is that just setting
/proc/net/conf/{all,default}/rp_filter
to 1 doesn''t seem to enable filtering on all interfaces -- you have to
explicitly enable filtering on each interface.
Furthermore, I needed to issue an "ip route flush cache" command to
actually
cause the kernel to filter routes.
I''ve attached a patch that implements the above, and it works for me,
but YMMV.
The patch has rearranged the original logic a wee bit, so please check!
--eric
-------------- next part --------------
--- firewall 2003-09-19 04:45:25.000000000 +0900
+++ firewall.new 2003-10-30 15:24:35.000000000 +0900
@@ -4163,15 +4163,16 @@
echo 0 > $f
done
- interfaces="`find_interfaces_by_option routefilter`"
+ if [ -n "$ROUTE_FILTER" ]; then
+ interfaces="$all_interfaces default"
+ else
+ interfaces="`find_interfaces_by_option routefilter`"
+ fi
- if [ -n "$interfaces" -o -n "$ROUTE_FILTER" ]; then
+ if [ -n "$interfaces" ]; then
echo "Setting up Kernel Route Filtering..."
- if [ -n "$ROUTE_FILTER" ]; then
- echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
- else
- for interface in $interfaces; do
+ for interface in $interfaces; do
file=/proc/sys/net/ipv4/conf/$interface/rp_filter
if [ -f $file ]; then
echo 1 > $file
@@ -4179,8 +4180,10 @@
error_message \
"Warning: Cannot set route filtering on $interface"
fi
- done
- fi
+ done
+
+ echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
+ run_ip route flush cache
fi
#
# IP Forwarding
On Wed, 2003-10-29 at 23:01, Eric E. Bowles wrote:> ributions enable it > in startup scripts. > > So in addition to setting each /proc/net/conf/$i/rp_filter to 1 for each > interface $i that I wanted to filter routes, I also needed to set > /proc/net/conf/all/rp_filter to 1. > > What''s strange is that just setting /proc/net/conf/{all,default}/rp_filter > to 1 doesn''t seem to enable filtering on all interfaces -- you have to > explicitly enable filtering on each interface. > > Furthermore, I needed to issue an "ip route flush cache" command to actually > cause the kernel to filter routes. > > I''ve attached a patch that implements the above, and it works for me, but YMMV. > The patch has rearranged the original logic a wee bit, so please check!Thanks, Eric. I''ve done additional testing and determined that as you would expect, setting /proc/net/ipv4/conf/default/rp_filter to 1 will cause /proc/net/ipv4/conf/DEV/rp_filter to be set to one when DEV is started. So: a) ROUTE_FILTER=Yes needs to set both "all" and "default". b) ROUTE_FILTER=Yes only controls route filtering on devices started while Shorewall is started. A fix will be in 1.4.8 which I will release before I leave for California. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net