New enhanced Version of IP Account collector now available

[candinet]

I thought what the HEC, now he talks about license fees, his "accounting" is hardly an improvement from Eje Gustafsson's IP Accounting v.1, besides from the graphs, which are nice, but not really a big deal to implement and other than that HECs frontend is not really comfortable.

So I took Eje Gustafsson's IP Accounting v.1 and worked a bit on it.
http://BaliMesh.com/downloads/StarOS_Account_Collector.tgz

The script now allows to select a date range to evaluate,
can produce subtotals per day, week or month, select all traffic, an IP range, a specific IP or part of any IP,
select to show details per IP, can resolve names and offers a choice to show PPoE user names.

If you do not upgrade from the previous version:
You need to create or define a database and a username according to your settings in configure.php on your mySQL server and then use dailyacctsum.sql file as input file to create the required database tables.

The README was a bit enhanced and also shows a sample for the 2 recommended cron jobs.

Let's colloborate and publish usefull applications and code snipplets here.
Examples for usefull stuff:
- Billing system based on contract details and radius or IP accounting data.
- Add-ons and plugins for radmin, the freeRadius web interface
- Ticket system for HotSpot, Prepaid accounts
...

[mrmike]

And how do you input the ip range? I have it collecting now. The output gives me the info by individual ip for each day, but if I leave the IP blank, I get every ip for every day. There must be a short cut.

Great work, by the way.

[candinet]

And how do you input the ip range? I have it collecting now. The output gives me the info by individual ip for each day, but if I leave the IP blank, I get every ip for every day.

You may either enter a complete IP number like 172.16.0.1 or enter a partial IP number like 172.16.0, which will result in evaluating IPs ranging from 172.16.0.1 - 172.16.0.255.

I will amend the front end to take true IP ranges with the next release, which is planned to be published within 2 weeks from now.

[georgew]

This all looks great... except for one thing...

Bandwidth accounting has two purposes. One is to generate usage based bills. You cover this use just fine.

But that is not what I use bandwidth accounting for 99.44% of the time...

I want to know "What the hell just happened?"

For example, a user is on a conference call (vonage) and he keeps getting cut off.. At the same time 8 megabits of UDP traffic are slaming him (and everyone else) off the net. I use bandwidth accounting to track this down and figure out who attacked who.

I can't do this if my accounting collector is throwing the data away.

Rather than only storing a summary, you should also maintain a circular buffer with the ip to ip stats collected for the last week. 9 times out of 10 the offending traffic source is long gone by the time I am looking into the complaint. Complaints are often delayed by a couple of days. So I need enough data to be able to do the research.

I need this sort of capability much more than I need the capability of billing for bandwidth.

[Kasper]

i don't much like perl, so i rewrote the collector in commandline php so i could know what it's doing all the time, and have it saving all the pulls to text files in my /var/log/cbqstats folder. once a week, i have another cron job take all the files in that folder and create an ISO and then delete those txt files. i have all of them going back to october, and it doesn't really take up that much space... my df shows 12% of an 80g drive...
and here lately, i've noticed an increase in portscans and sequential ip activities in the log files, so i'm thinkin it's time to modify that script that rips the cbq info, so that it also checks for sequential ip activity coming from 1 ip, and having it log that and auto-email me, letting me know it's happenning.

if anyone has a better method of doing that, i'm all ears...

[Kasper]

ok, i guess i openned up a can of worms on that one...
works good, emails me fine... just tons of email warnings now
looks like it's happenning alot more frequently than i thought.
time to sit down, track where they're all coming from and do a cisco block

[mmc1800]

I have found Cacti/Ntop/Nagios running on a linux machine near my firewall to be invaluable collecting traffic/security data. Not sure if those packages would do what you are looking for, but I would be happy to help you get them running if they have the features you would need (not really too much of a challenge but there were a couple issues).

Ntop is especially useful for finding out what is happening the last minute, or for the last 10 minutes (or even the last week) along with mac address and arp info, protocols, IPs and general security warnings for suspicious activity broken down by IP mac address protocol type and such.

Not sure I am even on topic with you guys, but seems like that might be useful if you haven't checked them out already.

[Kasper]

Thanks for the offer mmc, but since our network spans multiple cities, there is no one spot that i can setup that type of stuff on that would cover everything. The best I could come up with was to modify my cbq stats harvester script to check for sequential ip destinations within each 5 minute harvest and save the results to a new table, saving the source of the attack, the targets hit, and a timestamp. Accumulations over the past 9 hours show 201 attacks from 57 different sources, totalling 21,211 targets.
From this, I can see we'll be needing to block about 9 external IPs in our cisco's.

The good part, is that my harvester is now saving traffic history. So now, I can run my report script and it will give me the latest probe/scan stats, sorted by number of scans, with source ip and number of targets hit.

[tim]

I am seeing quite a lot of these sequential scan probes. How about an iptables module that :

1) Detects an ip destination which is known to be UNused,
2) Blocks all packets from the source address that tried to access the unused address. Possibly with a timeout on the block.

Providing the site under attack had sufficient unused ipspace, this would trigger a block at a very early stage in the scan probe.

The iptables module would need to be suppliied with the IP addresses of UNused destinations, but it should not be difficult to write.

Tim