LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 03-28-2011, 01:25 PM   #1
asleeis
LQ Newbie
 
Registered: Mar 2011
Posts: 5

Rep: Reputation: 0
Logging connection bytes for iptables?


Hey all... first post here. I did do some searches to see if this question has been answered (or asked before, and didn't see anything).

I am wondering if it's possible to log the number of bytes a connection transfered when the connection is complete with iptables. I know I've seen this sort of information in Cisco FWSM logs, where the "Teardown" entry of the logs has the bytes transferred for that connection.

Is it possible to have something similar to that with iptables? Where the initial connection attempt is logged (i.e. NEW, which I have logging fine) AND an entry for that connection that includes the bytes transferred?

Thanks,
-Alex
 
Old 03-29-2011, 02:17 PM   #2
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 782
Blog Entries: 8

Rep: Reputation: 158Reputation: 158
In my opinion, iptables is not a good tool to do this type of thing. And, it is a bit unfair to compare it with Cisco's firewalls. Iptables will track connection states (it is a stateful firewall), but it wasn't necessarily meant to track bytes of each connection/session. I believe this is more networking-related, and there are plenty of dedicated network-based tools that are up to the task (although there may be some modules that might be able to be leveraged to give you what you need...those I'm not aware of, though).

Have you tried looking up conntrack, or iptraf, or ntop? There might be other tools, also...those are just from the top of my head.
 
Old 03-29-2011, 02:57 PM   #3
asleeis
LQ Newbie
 
Registered: Mar 2011
Posts: 5

Original Poster
Rep: Reputation: 0
I wasn't necessarily comparing it TO Cisco firewalls... just an example of the type of info I was looking for in logs.

I wasn't sure if it was built into iptables or not, but I think I remember reading something about connbytes being an attribute that could be used for rules (to have special rules for larger transfers), and was hoping the info would be available for logging. It's possible that was just a patch.

iptables certain does track bytes transferred, as it's reported as part of the output of 'iptables -nvL', but that seems to be tracked at the "rule" level (from the point of last "zeroing").

Oh well. I'll take a look at some of your other suggestions.

Thanks,
-Alex
 
Old 03-29-2011, 02:59 PM   #4
asleeis
LQ Newbie
 
Registered: Mar 2011
Posts: 5

Original Poster
Rep: Reputation: 0
Ahh. I just double checked. Looks like connbytes WAS a patch, but seems to be part of standard build. So, that means that iptables is indeed tracking bytes by connection. I just need to find a way to get it to LOG that info. hehe.
 
Old 03-29-2011, 03:13 PM   #5
asleeis
LQ Newbie
 
Registered: Mar 2011
Posts: 5

Original Poster
Rep: Reputation: 0
Btw, if I'm not mistaken, iptraf and ntop are just commandline tools, right? They don't log over time? I'm looking at doing trending correlation... poor-man's SIEM, if you will... I feed the data for my one server into Splunk, and am generating various quick reports and correlation views to identify anomalies (the easy part), and then identify the details of the anomalies (such as when, where, what else happened at the time; the harder part).

So, I'm looking for logging of data that I can ingest, that will have connection details with bytes. iptables seemed ideal (in terms of resources, since it's already running and doing the calc and regular logging, and in minimizing redundancy). For example, I saw a spike in overall bandwidth outbound, that I accounted for via various other methods, except a sizable chunk of it. This is what led me to wanting to know bytes at connection level.

I will continue to dig. conntrack might be more along what I'm wanting, but unsure yet.

Thanks again.
 
Old 03-30-2011, 08:19 AM   #6
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 782
Blog Entries: 8

Rep: Reputation: 158Reputation: 158
I've never seen a SIEM that tracks connection byte consumption, but my experience with SIEMs and SEMs are security-focused (as in alert logs showing broken parameters/thresholds, trending of hours of data to highlight low-level attacks [10 or more brute-force attempts in 5 min, for example], and pattern-matching [pre-defined rule triggering against network packet info]). Byte rates are usually tracked (in my experience) when there are no other anomaly-tracking options. An example of this would be, if a 0-day exploit was announced and IDS signatures are not yet available. Then again, high byte rate or byte rate spikes and trending won't necessarily always indicate malware attacks. IDS/IPS would detect this type of anomaly far better, especially an IPS (most IPSs actually route...if you break an IPS, you're definitely affecting a network segment...dead IPS, dead network segments). I'd also not want to put undue load on a firewall, especially if it is a gateway that's already monitoring a very busy network.

I mentioned iptraf and ntop because they may still offer options that conntrack might not. Both iptraf and ntop have the capability to log long term. iptraf is CLI. ntop is GUI-based. iptables will track connection states and basic byte consumption (even without conntrack, I believe), but it's probably not going to give you enough data to determine if IP aaa.aaa.aaa.aaa is acting anomalously. A basic firewall is normally just a security guard. He'll route and block. He's not going to track every single human that crosses the threshold, though. A security guard isn't going to remember how many times a person has gone through his gate in the last 30 days or how much material that person was carrying when he came through. Someone else might be doing that or know how to do it on-demand (this would be the third-party tool in this analogy). The security guard might be able to attempt to do this if he/she were shown how and told to do it, but can you imagine how that would affect the traffic crossing the threshold, especially if it were busy? The security guard would eventually go postal (FW crash...seen this before).

Cisco does it natively. Checkpoint FWs don't do such tracking natively, although if there's a Nokia backend, the backend may do tracking, but not per individual IP (usually, its per interface per day/week, for example). Juniper Netscreens don't do this type of tracking. TippingPoint FWs don't either.

Maybe I'm wrong, though...I've been wrong before but that's why I'm here (to learn).
 
Old 03-30-2011, 10:34 AM   #7
asleeis
LQ Newbie
 
Registered: Mar 2011
Posts: 5

Original Poster
Rep: Reputation: 0
My experience with SIEM is also security (my role ranging from operations oversight to incident response to forensic investigation to application security.

Bytes per connection aren't generally ideal for identifying anomalies. However, when anomalies are detected for other reasons, it helps greatly to be able to drill down to identify specifics of behavior. Malware isn't the only concern, and IDS and IPS don't always catch what we (my day job) would like. This is not for my day job, though, this is on my personal server... thus the poor man's approach.

But in the case of a real world situation, if it's discovered that malware is on a system, or within the network, identifying how much data might have been exfiltrated by the attacker is a quick way to assess potential risk, when needing to give quick feedback to a CISO. Also, it paints a picture to see when data was loaded where. With connection bytes, when drilling into detail, you can readily get a general idea as to when an initial payload has been dropped onto a system, what connections are only C&C checkins, and which ones might have exfiltrated more information. And most current DLP solutions rarely help for such cases, as exfiltrated data is often encrypted now before sending.

Bytes per connection just offer a quick high level view of just how much when in/out, where the spikes are, etc. But yes, this is more after you know something is wrong, and are using the SIEM to drill down into more detail to gain a more specific picture of the security incident. When I handle a security incident, I like to be able to spell out step by step, how an infection got in, how and where it spread, and how much, if any, data may have been lost. It may be excessive for some, but this kind of quick view into detail has allowed me to shut down malware infections within hours, when (according to FBI contacts for an incident) other companies our size were taking days, or even weeks... both due to lack of process and lack of gaining specifics. Of course, in that situation I'm dealing with Cisco, and other higher end systems. I would love to have such toys for my personal use. hehe.

So, to bring it back to my situation on my personal server. I saw a spike in bandwith that I'm not getting a clear picture about where/why. This is more SIEM-approach for operational monitoring/management, though... I acknowledge that. Various other logs give me approximate chunks that stuff like "traffic from site X", but still don't seem to be accounting for the whole. If I were tracking connection bytes, this would be identified within minutes. So, that's why I'm looking to track it. I've just migrated my software/sites/etc into a new dedicated hosting provider, and I like to keep a close eye on things for a little while. Call it the paranoid security professional in me.

Anyway... thanks for your assistance. conntrack looks like it may provide what I need. I just need to identify how to log it without too much wasted space. I mean, brute force, I could snapshot the proc file every 15 seconds, and then parse it to build a view of individual connections, but that would be wasteful of splunk DB ingestion. This is where having it hooked into the firewall (where events of open and close connections are known) to log at appropriate times made sense to me.


ntop is GUI based now? Was it always? I seem to recall playing with ntop some 10-11 years ago as command line. heh. I do like iptraf. I'd never actually played with that before. Not quite what I need for historical tracking, but still pretty slick, none-the-less.

Thanks again.

Last edited by asleeis; 03-30-2011 at 10:38 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
logging iptables sang_froid Linux - Security 1 05-19-2009 10:46 AM
iptables logging saavik Linux - Networking 5 09-13-2007 01:49 AM
Iptables Logging doublejoon Linux - Security 8 01-09-2006 04:20 AM
connection reset after 4096 bytes when using FTP to access remote server socrates71 Linux - Networking 2 10-20-2005 08:37 AM
iptables and logging Yohhan Linux - Networking 2 05-04-2004 11:55 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 11:04 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration