Shorewall devel - Aug 2004 - [PATCH] Support for accounting based on uid/gid

Hi,

I noticed shorewall''s accounting feature didn''t support the
owner
module of iptables. Well, I needed the feature so here''s a patch that 
makes it possible. However, there''s one thing you might review 
carefully as I wasn''t sure what''s the best way to work around
it. You
must use chain OUTPUT in order to make -m owner work (iptables 
limitation). As you know, shorewall tries to create the defined chain 
if it doesn''t exist (this decision is based on existance of 
exists_${chain_name} variable). For built-in chains there''s no such 
variable so shorewall would try to create chain OUTPUT. That would 
fail, of course. I solved this by specifying 
exists_{INPUT,OUTPUT,FORWARD}=Yes just before setting default policy 
for the chains. You could also patch the routines that create chains on 
demand not to try to create built-in chains. I''m not sure
what''s the
best solution. Anyways, you''d use the feature like this:

add to accounting file:
# count all tj''s traffic from eth0 to anywhere but 130.233.0.0/16 
network
a_tj-out:COUNT OUTPUT - eth0:!130.233.0.0/16 - - - tj

view it:
shorewall show a_tj-out

The patch is against version 2.0.7 but it works for both 2.0.8 and 
2.1.6 (the patch that is, only tested with 2.0.7). Feel free to use it 
in the upcoming versions.

Best Regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shorewall-accounting-user.diff
Type: application/octet-stream
Size: 3600 bytes
Desc: not available
Url :
http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20040824/ee55e802/shorewall-accounting-user.obj
-------------- next part --------------

-- 
Tuomas Jormola <tjormola@cc.hut.fi>

On 24.8.2004, at 23:27, Tuomas Jormola wrote:

I didn''t get it quite right for the 1st time. That patch included an 
unneeded debug command. I also added checking that the chain really is 
OUTPUT when parsing the user section.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shorewall-accounting-user-2.diff
Type: application/octet-stream
Size: 3615 bytes
Desc: not available
Url :
http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20040824/400c6538/shorewall-accounting-user-2.obj
-------------- next part --------------

-- 
Tuomas Jormola <tjormola@cc.hut.fi>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tuomas Jormola wrote:
|
| On 24.8.2004, at 23:27, Tuomas Jormola wrote:
|
| I didn''t get it quite right for the 1st time. That patch included an
| unneeded debug command. I also added checking that the chain really is
| OUTPUT when parsing the user section.

I don''t think is is quite what you want yet -- if the USER column
contains "-", "All" or "Any" and the chain
isn''t OUTPUT your code
generates an error.

- -Tom
- --
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBK7RWO/MAbZfjDLIRArbVAKCGrWS3+6RbBjb2BxtTqZIVdmhvhQCfUic2
b5P4lsdsIf3bo33C51xhvEw=8ewK
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Eastep wrote:
| Tuomas Jormola wrote:
| |
| | On 24.8.2004, at 23:27, Tuomas Jormola wrote:
| |
| | I didn''t get it quite right for the 1st time. That patch included
an
| | unneeded debug command. I also added checking that the chain really is
| | OUTPUT when parsing the user section.
|
| I don''t think is is quite what you want yet -- if the USER column
| contains "-", "All" or "Any" and the chain
isn''t OUTPUT your code
| generates an error.
|

I guess my next question would be "Is this really useful"? It is only
capable of accounting for output traffic from the firewall itself; I
would think that input traffic might be slightly more interesting but as
you say, Netfilter can only match output traffic by UID/GID.

Any opinions?

- -Tom
- --
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBK7UzO/MAbZfjDLIRAiUtAKC5GwGmfo+Lxb5EykaMw4RIW8cbCACbBh8b
ZdNFcRJDNGFUP7fI5O0nFhU=bwYp
-----END PGP SIGNATURE-----

On 25.8.2004, at 00:34, Tom Eastep wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tuomas Jormola wrote:
> |
> | On 24.8.2004, at 23:27, Tuomas Jormola wrote:
> |
> | I didn''t get it quite right for the 1st time. That patch
included an
> | unneeded debug command. I also added checking that the chain really 
> is
> | OUTPUT when parsing the user section.
>
> I don''t think is is quite what you want yet -- if the USER column
> contains "-", "All" or "Any" and the chain
isn''t OUTPUT your code
> generates an error.
Yes, you''re right. Stupid me. Another try.

-- 
Tuomas Jormola <tjormola@cc.hut.fi>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shorewall-accounting-user-3.diff
Type: application/octet-stream
Size: 3746 bytes
Desc: not available
Url :
http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20040825/474508c3/shorewall-accounting-user-3.obj

On 25.8.2004, at 00:37, Tom Eastep wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tom Eastep wrote:
> | Tuomas Jormola wrote:
> | |
> | | On 24.8.2004, at 23:27, Tuomas Jormola wrote:
> | |
> | | I didn''t get it quite right for the 1st time. That patch
included
> an
> | | unneeded debug command. I also added checking that the chain 
> really is
> | | OUTPUT when parsing the user section.
> |
> | I don''t think is is quite what you want yet -- if the USER
column
> | contains "-", "All" or "Any" and the chain
isn''t OUTPUT your code
> | generates an error.
> |
>
> I guess my next question would be "Is this really useful"? It is
only
> capable of accounting for output traffic from the firewall itself; I
> would think that input traffic might be slightly more interesting but 
> as
> you say, Netfilter can only match output traffic by UID/GID.
>
> Any opinions?
Well, I do think it''s useful (I would not have put the hack together if
I didn''t). Imagine a situation where you have quota for your 
daily/weekly/monthly/whatever upstream bandwidth and many users sharing 
it. If I was a sysadmin of such system (and guess what, I am ;), I''d be
quite interested in monitoring the individual bandwidth usage of the 
users. If you have bandwidth-hogging users and this kind of monitoring 
setup, it''s trivial to spot the problem and take action before the 
quota is exceeded. Maybe you could enforce bandwidth quotas for your 
users but setting up that would be unnecessarily complicated and not 
really justified if the number of expected incidents involving 
unusually high bandwidth usage is relatively low. Better just be 
alerted by a script after certain threshold has been exceeded so that 
you can contact the individual and just tell he or she better watch it 
in the future or else... You can implement this kind of accounting 
setup with iptables so why not integrate it with your nice existing 
shorewall configuration?

-- 
Tuomas Jormola <tjormola@cc.hut.fi>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tuomas Jormola wrote:

|
| Well, I do think it''s useful (I would not have put the hack together
if
| I didn''t). Imagine a situation where you have quota for your
| daily/weekly/monthly/whatever upstream bandwidth and many users sharing
| it. If I was a sysadmin of such system (and guess what, I am ;), I''d
be
| quite interested in monitoring the individual bandwidth usage of the
| users. If you have bandwidth-hogging users and this kind of monitoring
| setup, it''s trivial to spot the problem and take action before the
quota
| is exceeded. Maybe you could enforce bandwidth quotas for your users but
| setting up that would be unnecessarily complicated and not really
| justified if the number of expected incidents involving unusually high
| bandwidth usage is relatively low. Better just be alerted by a script
| after certain threshold has been exceeded so that you can contact the
| individual and just tell he or she better watch it in the future or
| else... You can implement this kind of accounting setup with iptables so
| why not integrate it with your nice existing shorewall configuration?
|

But it only counts packets *from applications running on the firewall*
- -- Are you saying that this system is regularly used by a large number
of different people?

- -Tom
- --
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBK83dO/MAbZfjDLIRAvJIAJ9u4EnymoiPflmUfG/5gBrUydktYwCfcz4J
eFsGbBiXqDqSpdA8LGA92YY=jk0T
-----END PGP SIGNATURE-----

On 25.8.2004, at 02:23, Tom Eastep wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tuomas Jormola wrote:
>
> |
> | Well, I do think it''s useful (I would not have put the hack
together
> if
> | I didn''t). Imagine a situation where you have quota for your
> | daily/weekly/monthly/whatever upstream bandwidth and many users 
> sharing
> | it. If I was a sysadmin of such system (and guess what, I am ;),
I''d
> be
> | quite interested in monitoring the individual bandwidth usage of the
> | users. If you have bandwidth-hogging users and this kind of 
> monitoring
> | setup, it''s trivial to spot the problem and take action before
the
> quota
> | is exceeded. Maybe you could enforce bandwidth quotas for your users 
> but
> | setting up that would be unnecessarily complicated and not really
> | justified if the number of expected incidents involving unusually 
> high
> | bandwidth usage is relatively low. Better just be alerted by a script
> | after certain threshold has been exceeded so that you can contact the
> | individual and just tell he or she better watch it in the future or
> | else... You can implement this kind of accounting setup with 
> iptables so
> | why not integrate it with your nice existing shorewall configuration?
> |
>
> But it only counts packets *from applications running on the firewall*
> - -- Are you saying that this system is regularly used by a large 
> number
> of different people?
Yes, that''s right (not a large number of users though). We
aren''t
talking about network of a Fortune 500 company with huge array of 
systems but a small, lonely hobby box ditched into a corner of the 
internet.

-- 
Tuomas Jormola <tjormola@cc.hut.fi>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tuomas Jormola wrote:

|>
|> But it only counts packets *from applications running on the firewall*
|> - -- Are you saying that this system is regularly used by a large number
|> of different people?
|
| Yes, that''s right (not a large number of users though). We
aren''t
| talking about network of a Fortune 500 company with huge array of
| systems but a small, lonely hobby box ditched into a corner of the
| internet.
|

Ok -- got it.

- -Tom
- --
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBK9MgO/MAbZfjDLIRAoMdAJ9DuWH/TN/5iOq8M1WjQHUmLfjC9gCfZXTc
KZ5AFq9QF7NMHkXY4q7GY0U=1dck
-----END PGP SIGNATURE-----