Skip to contentSkip to conversation

IP Acounting Idea for 2.5

DISCUSSION David Findlay 12 participants 20 messages Apr 15, 2001 – Apr 20, 2001

lore
Share & tools
lore
#0 lore raw

I am using the kernel IP Accounting in Linux to record the amount of data transfered via my Linux internet gateway from individual IP addresses. This currently requires me to set up an accounting rule for each IP address that I want to record accounting info for. If I had 200 machines to individually log this would require me to set 200 rules.

In the 2.5 series of kernels, working towards 2.6, could you please make the IP Accounting so that I can set a single rule that will make it watch all IP traffic going from the local network, through the masquerading service to the internet, and log local IP Addresses using it? This would allow me to set 1 rule, but have the information I want on a per IP address system.

One other person I have talked to would like to see this too, and he basically says we need a software version of the Cisco IP Accounting server/router.

Could you please add this to the next kernel? Please CC me your responses as I am not a member of the kernel mailing list. Thanks,

David

#1 lore raw
Quoted 5 lines

In the 2.5 series of kernels, working towards 2.6, could you please make the IP Accounting so that I can set a single rule that will make it watch all IP traffic going from the local network, through the masquerading service to the internet, and log local IP Addresses using it? This would allow me to set 1 rule, but have the information I want on a per IP address system.

You could try using a mature userspace traffic meter like 'NeTraMet' (uses libpcap).

ftp://ftp.auckland.ac.nz/pub/iawg/NeTraMet/

Quoted 3 lines

One other person I have talked to would like to see this too, and he basically says we need a software version of the Cisco IP Accounting server/router.

NeTraMet can also account using Cisco Netflow accounting records.

Quoted 11 lines

Could you please add this to the next kernel? Please CC me your responses as I am not a member of the kernel mailing list. Thanks,

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#2 lore raw
In reply to David Findlay
Quoted 12 lines · David Findlay

I am using the kernel IP Accounting in Linux to record the amount of data transfered via my Linux internet gateway from individual IP addresses. This currently requires me to set up an accounting rule for each IP address that I want to record accounting info for. If I had 200 machines to individually log this would require me to set 200 rules.

In the 2.5 series of kernels, working towards 2.6, could you please make the IP Accounting so that I can set a single rule that will make it watch all IP traffic going from the local network, through the masquerading service to the internet, and log local IP Addresses using it? This would allow me to set 1 rule, but have the information I want on a per IP address system.

Quoted 6 lines

One other person I have talked to would like to see this too, and he basically says we need a software version of the Cisco IP Accounting server/router.

Could you please add this to the next kernel? Please CC me your responses as I am not a member of the kernel mailing list. Thanks,

Perhaps I misunderstand what it is exactly you are trying to do, but I would think that this could be done entirely in userland by software that just adds rules for you instead of you having to do it manually.

Just a thought.

----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
There are two major products that come out of Berkeley: LSD and BSD.
We don't believe this to be a coincidence. -- Jeremy S. Anderson

#3 lore raw
Quoted 4 lines · you

Perhaps I misunderstand what it is exactly you are trying to do, but I would think that this could be done entirely in userland by software that just adds rules for you instead of you having to do it manually.

I suppose, but it would be so much easier if the kernel did it automatically. Having a rule to go through for each IP address to be logged would be slower than implementing one rule that would log all of them. Doing this in the kernel would improve preformance.

David

#4 lore raw
Quoted 9 lines · David Findlay
Quoted 4 lines

Perhaps I misunderstand what it is exactly you are trying to do, but I would think that this could be done entirely in userland by software that just adds rules for you instead of you having to do it manually.

I suppose, but it would be so much easier if the kernel did it automatically. Having a rule to go through for each IP address to be logged would be slower than implementing one rule that would log all of them. Doing this in the kernel would improve preformance.

I don't think it would, but then only benchmarking it both ways would know for sure. Even with incredibly large rulesets, ipchains &&/|| netfilter works admirably well. Rusty?

----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------

#5 lore raw

No, one rule would be MUCH faster. What's do you think would be faster of the two:

if ((ipaddr>=3232235521)&&(ipaddr<=3232235774))

    return 1;
else
    return 0;

or

for (a=0;a<(3232235774-3232235521);a++)

    if (ipaddr==a)
        return 1;

return 0;

Obviously it compares the 192.168.0.1 - 192.168.0.255 range, but I think we both know which one will be faster. Not to mention countless other redundant checks will be added in on both, but on the second one the time of the checks is multiplied by the number of times you have too loop.

But, I'm just a newbie so I don't really know :P Just taking up bandwith :(

L8ers,
Matt

Quoted 27 lines · Mike A. Harris
Quoted 9 lines · David Findlay
Quoted 4 lines

Perhaps I misunderstand what it is exactly you are trying to do, but I would think that this could be done entirely in userland by software that just adds rules for you instead of you having to do it manually.

I suppose, but it would be so much easier if the kernel did it automatically. Having a rule to go through for each IP address to be logged would be slower than implementing one rule that would log all of them. Doing this in the kernel would improve preformance.

I don't think it would, but then only benchmarking it both ways would know for sure. Even with incredibly large rulesets, ipchains &&/|| netfilter works admirably well. Rusty?

----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#6 lore raw
In reply to Mike A. Harris
Quoted 10 lines · David Findlay
Quoted 4 lines · you

Perhaps I misunderstand what it is exactly you are trying to do, but I would think that this could be done entirely in userland by software that just adds rules for you instead of you having to do it manually.

I suppose, but it would be so much easier if the kernel did it automatically. Having a rule to go through for each IP address to be logged would be slower than implementing one rule that would log all of them. Doing this in the kernel would improve preformance.

Perhaps "netflow" would be an answer ?

It is cisco idea for collecting accounting data for
network flows. System has a cache of flows for
which it collects data, and once the cache overflows (or flow times out), data is sent to designated flow collection server(s).

http://www.cisco.com/warp/public/cc/pd/iosw/ioft/neflct/tech/napps_wp.htm

Quoted 1 line

David

/Matti Aarnio

#7 lore raw
In reply to Mike A. Harris
Quoted 9 lines · David Findlay
Quoted 4 lines · you

Perhaps I misunderstand what it is exactly you are trying to do, but I would think that this could be done entirely in userland by software that just adds rules for you instead of you having to do it manually.

I suppose, but it would be so much easier if the kernel did it automatically.

Yes, but by what criteria? You want to log on a per host basis. Someone else wants to log by service (www, ftp, mail, news), or any number of other criteria.

Quoted 3 lines

Having a rule to go through for each IP address to be logged would be slower than implementing one rule that would log all of them. Doing this in the kernel would improve preformance.

If there really is a performance issue with a few hundred rules, then it can be overcome by grouping rules in separate custom chains. F.e. if you have 1024 rules create 32 custom chains with 32 rules each. Then have 32 rules in your main table which jump to the appropriate custom chain --> maximum rules traversed by each packet = 64.

There is another issue with logging in general:

*COUNTERS MUST NOT BE RESETABLE!!!*

Resetable counters guarantee that no two programs can co-exists if they happen to reset the same counters.

All logging counters should be implemented with 32bit or 64bit unsigned integers. Any software using correct unsigned integer arithmetic can then simply subtract a previous value from the current value to get the difference. This works reliably across counter wrap-arounds. There is absolutely *no need for reset* !

Signature · 4 lines
Manfred Bartz
---------------------------------------------------------------
ipchainsLogAnalyzer, NetCalc, whois at: <http://logi.cc/linux/>
     NEW: <http://logi.cc/linux/NetfilterLogAnalyzer.php3>
#8 lore raw
In reply to Mike A. Harris
Quoted 3 lines · Manfred Bartz

There is another issue with logging in general:

*COUNTERS MUST NOT BE RESETABLE!!!*

Umm, no. Counters can be resetable - you just specify that accounting programs should not reset them, ever.

The ability to reset counters is extremely useful if you're a human looking at the output of iptables -L -v. (I thus far know of no one who can memorise the counter values for around 40 rules).

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

#9 lore raw
In reply to Mike A. Harris

Hi,

Quoted 5 lines · David Findlay

I suppose, but it would be so much easier if the kernel did it automatically. Having a rule to go through for each IP address to be logged would be slower than implementing one rule that would log all of them. Doing this in the kernel would improve preformance.

You can use the iptables ULOG facility (see netfilter CVS for the patches). With this you can copy packets to userspace programs which can do any further processing, like the accounting stuff. You can even choose to only copy part of a packet (say only the IP header) to userspace, to reduce the amount of data your application has to handle.

Simply copy the headers of all IP packets going through your router to userspace, and write a small application (possibly using libipulog which comes with the netfilter userspace code) which does the actual accounting. This has the additional benefit that further processing of the packet in kernel (i.e. outputting it on the destination interface) can continue while your application is processing the accounting data.

Andreas

Signature · 1 line
You are in a maze of little twisting passages, all alike.
#10 lore raw
In reply to Mike A. Harris
Quoted 11 lines · Russell King
Quoted 3 lines · Manfred Bartz

There is another issue with logging in general:

*COUNTERS MUST NOT BE RESETABLE!!!*

Umm, no. Counters can be resetable - you just specify that accounting programs should not reset them, ever.

The ability to reset counters is extremely useful if you're a human looking at the output of iptables -L -v. (I thus far know of no one who can memorise the counter values for around 40 rules).

You just illustrated my point. While there is a reset capability people will use it and accounting/logging programs will get wrong data. Resetable counters might be a minor convenience when debugging but the price is unreliable programs and the loss of the ability of several programs to use the same counters.

Also, do you always reset the date and time everytime you make time measurements?

Signature · 1 line
Manfred Bartz
#11 lore raw
In reply to Mike A. Harris
Quoted 6 lines · Manfred Bartz

If there really is a performance issue with a few hundred rules, then it can be overcome by grouping rules in separate custom chains. F.e. if you have 1024 rules create 32 custom chains with 32 rules each. Then have 32 rules in your main table which jump to the appropriate custom chain --> maximum rules traversed by each packet = 64.

still.. if you want to log multiple class B's it's a PITA, especially if your ruleset changes and you have to atomically replace all chains in one table to update the ruleset from userspace->kernel.

Quoted 6 lines

There is another issue with logging in general:

*COUNTERS MUST NOT BE RESETABLE!!!*

Resetable counters guarantee that no two programs can co-exists if they happen to reset the same counters.

That sounds like crap (sorry). Counters are resettable, and will be. If you run two applications resetting counters individually, you have a problem with your applications.

Quoted 2 lines

All logging counters should be implemented with 32bit or 64bit unsigned integers. Any software using correct unsigned integer

they are uint32 right now.

Quoted 3 lines

arithmetic can then simply subtract a previous value from the current value to get the difference. This works reliably across counter wrap-arounds. There is absolutely *no need for reset* !

so why are your applications resetting counters then? Nobody forces you to reset them right now.

Quoted 2 lines

Manfred Bartz
---------------------------------------------------------------

Signature · 5 lines
Live long and prosper
- Harald Welte / [email protected]                http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
#12 lore raw
In reply to Mike A. Harris
Quoted 5 lines · Harald Welte
Quoted 2 lines · Manfred Bartz

Resetable counters guarantee that no two programs can co-exists if they happen to reset the same counters.

That sounds like crap (sorry).

Care to explain how two independent apps can co-exists if they happen to reset the same counters?

Quoted 1 line

so why are your applications resetting counters then?

Ask the authors, not me. I wiped those apps from my system. Its just a pity about the time wasted.

Quoted 1 line

Nobody forces you to reset them right now.

Why do authors then write apps (f.e. ipac) which reset counters? Perhaps only because they can, not because it makes sense.

Signature · 1 line
Manfred Bartz
#13 lore raw
In reply to Mike A. Harris
Quoted 10 lines · Harald Welte
Quoted 4 lines · Manfred Bartz

*COUNTERS MUST NOT BE RESETABLE!!!*

Resetable counters guarantee that no two programs can co-exists if they happen to reset the same counters.

That sounds like crap (sorry). Counters are resettable, and will be. If you run two applications resetting counters individually, you have a problem with your applications.

Resettable counters in a security sensitive environment are just a call for trouble. That's why you can't reset the SNMP counters on any Cisco device I've encountered today. They learned their lesson. Maybe you will, too.

Regards
Henning

Signature · 5 lines
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   
#14 lore raw
In reply to Mike A. Harris
Quoted 6 lines

Umm, no. Counters can be resetable - you just specify that accounting programs should not reset them, ever.

The ability to reset counters is extremely useful if you're a human looking at the output of iptables -L -v. (I thus far know of no one who can memorise the counter values for around 40 rules).

You'll get bogus accounting results unless you stop/restart the accounting programs every time you manually deal with the counters. This sounds dangerously easy to make mistakes to me.

Olaf

#15 lore raw
In reply to Mike A. Harris
Quoted 5 lines · Henning P. Schmiedehausen

Resettable counters in a security sensitive environment are just a call for trouble. That's why you can't reset the SNMP counters on any Cisco device I've encountered today. They learned their lesson. Maybe you will, too.

Well, I'm not sure about which SNTP counters you are talking, but I suppose it is not about per-filtering-rule counters, but something like per-interface counters, etc.

There's always a way for somebody with root access to reset the counters of a rule:

just delete and re-insert the rule.

If somebody wants to reset the counter, he can. If we remove the functionality from iptables, people still can - but it's more difficult.

Quoted 2 lines

Regards
Henning

Signature · 5 lines
Live long and prosper
- Harald Welte / [email protected]                http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
#16 lore raw

Counters [Re: IP Acounting Idea for 2.5]

In reply to Mike A. Harris
Quoted 10 lines · Olaf Titz
Quoted 6 lines

Umm, no. Counters can be resetable - you just specify that accounting programs should not reset them, ever.

The ability to reset counters is extremely useful if you're a human looking at the output of iptables -L -v. (I thus far know of no one who can memorise the counter values for around 40 rules).

You'll get bogus accounting results unless you stop/restart the accounting programs every time you manually deal with the counters. This sounds dangerously easy to make mistakes to me.

mmh. But isn't that obvious? Every time you mess with anything (counters or rules) of the chains/tables, your accounting program will get into trouble, if it relies on those counters.

I don't think that it makes sense to do iptables-based accounting if you have changes to the ruleset (counters and/or rules) at runtime. You'd have to be very cautious what you are doing.

Quoted 1 line

Olaf

Signature · 5 lines
Live long and prosper
- Harald Welte / [email protected]                http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
#17 lore raw
In reply to Mike A. Harris
Quoted 10 lines · Harald Welte
Quoted 5 lines · Henning P. Schmiedehausen

Resettable counters in a security sensitive environment are just a call for trouble. That's why you can't reset the SNMP counters on any Cisco device I've encountered today. They learned their lesson. Maybe you will, too.

Well, I'm not sure about which SNTP counters you are talking, but I suppose it is not about per-filtering-rule counters, but something like per-interface counters, etc.

You don't want your counters going backward. Full stop. If a program can reset your counter, your application will never know, if it was a legal, correct, valid reason or just a hacker trying to hide his traces. At least provide some sort of lock-down.

Quoted 4 lines

There's always a way for somebody with root access to reset the counters of a rule:

just delete and re-insert the rule.

Bad thing. If you want to use the rules in a security sensitive environment, don't allow removal. If you need to, reset the whole module and notify the user. Better, shut down the filter and yell for help.

ipfilter is about security, isn't it?

Quoted 2 lines

If somebody wants to reset the counter, he can. If we remove the functionality from iptables, people still can - but it's more difficult.

There is no "more difficult", just "different ways". If you bother to use a filtering environment where the filter counters tell e.g. "we rejected xxx attacks", you don't want anyone to mess with these counters. If this is a counter for a filtering rule, don't allow the rule (and its counters) to be removed. Inactivate the rule but keep the evidence (counter settings) around till module removal or reboot.

Sorry, I may be anal about security but as more and more people start thinking "why should I bother with FW-1 or PIX when I can get a $99 Linux box and hack some filters", at least I want the $99 software trying not to be sloppy about security.

Regards
Henning

Signature · 5 lines
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   
#18 lore raw
In reply to David Findlay

David Findlay said once upon a time (Tue, 17 Apr 2001):

Quoted 5 lines

I am using the kernel IP Accounting in Linux to record the amount of data transfered via my Linux internet gateway from individual IP addresses. This currently requires me to set up an accounting rule for each IP address that I want to record accounting info for. If I had 200 machines to individually log this would require me to set 200 rules.

In 1999 I setup a Linux kernel 2.2 box to monitor traffic for about 2500 hosts. I created two rules for each host (to monitor inbound and outbound). I had over 5000 total rules on a Pentium II 300 Mhz box. I wrote some perl glue so I could accounts on a per customer basis (each customer had one or more IPs, not necessarily contiguous) and graph the results in MRTG.

There was ZERO performance problems on the box. The box is still runningly happily today. I don't there is a "problem" to fix.

Dax

#19 lore raw
In reply to David Findlay
Quoted 5 lines · David Findlay

In the 2.5 series of kernels, working towards 2.6, could you please make the IP Accounting so that I can set a single rule that will make it watch all IP traffic going from the local network, through the masquerading service to the internet, and log local IP Addresses using it? This would allow me to set 1 rule, but have the information I want on a per IP address system.

:) Well... there was a discussion about this on the netfilter-devel list some weeks ago.

This is definitely not a 2.5 / 2.6 issue, as it could be easily implemented by using the already existing flexibility of netfilter/iptables.

It's just a matter of somebody who needs it getting around actually implementing it. Could be either implemented as a 'raw' netfilter hook-attaching module or (more convenient) as a new iptables target, which allocates some internal tables for storing the accounting data.

Doesn't make sense to have a discussion about it on linux-kernel, and it certainly doesn't belong into a 2.5 featurelist.

Please refer to the netfilter-devel mailinglist (subscription information available at http://netfilter.samba.org/)

Quoted 1 line

David

Signature · 5 lines
Live long and prosper
- Harald Welte / [email protected]                http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)