From: "Taylor, Grant" <gtaylor@riverviewtech.net>
To: netfilter@lists.netfilter.org
Subject: Re: Iptables logs on High bandwidth traffic network
Date: Thu, 05 May 2005 02:24:46 -0500 [thread overview]
Message-ID: <4279CA3E.3000104@riverviewtech.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0505050848090.21265@blackhole.kfki.hu>
> Why where a FIFO and a program which parses and transmit the data to
> another system any faster than syslog/syslog-ng/ulogd/etc? (Why reinvent
> the wheel?)
It is my belief that Syslog and the mechanism that it uses to log is not meant for extreme volume of login. As I understand it Syslog will log each and every individual packet that passes through the IPTables LOG target individually, thus causing a write through the kernel in to SysLog space and possibly to disk for a VERY small amount of data. Where as TCPDump or Snort will dump to memory for a specific amount of time or amount of traffic captured and then write a large group of packets as one write. The former will have an I/O action for each and every packet that comes through the kernel, where as the later will have an I/O action once every x number of thousands or millions of packets (user definable). It is much easier / efficient for a system to write a larger chunk of data at one time than it is for it to write the same amount of data in a lot of little bitty increments. Imag
en moving a book shelf from the basement in a house to the upstairs bedroom. Would it be
easier to move one book at a time up the stairs for each and every book on the shelf or would it be easier to grab as many books as you can carry and take a bunch of books at one time? Which would you view as more work in the long run? There is this same type of load on systems when logging via SysLog.
(Again, this is my perception of the way that SysLog writes log entries. If someone knows this to be incorrect please tell me other wise.)
> If you sniff the network for logging, where do you actually want to sniff?
> Before the firewall? You'll have to cope with the same traffic as the
> firewall itself and won't see the dropped traffic on the other side.
> Behind the firewall? You won't see again the dropped traffic coming from
> outside. (Please note, I do not advise against an IDS inside which sniffs
> the traffic.)
If you are wanting to log for accounting reasons to know how much traffic any person behind the system moved I would sniff on the internal side of the system. If you are wanting to log attacks and / or traffic that is dropped by the firewall I would log on the internal and external find find the difference and thus deduce what has been dropped. Where you want to sniff will really depend on what you are wanting to log. If you can be more specific I'd be glad to give a more specific response. :)
Grant. . . .
next prev parent reply other threads:[~2005-05-05 7:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-04 12:45 Iptables logs on High bandwidth traffic network bharathi
2005-05-04 15:59 ` Taylor, Grant
2005-05-04 22:40 ` Mogens Valentin
2005-05-04 23:13 ` Taylor, Grant
2005-05-05 6:59 ` Jozsef Kadlecsik
2005-05-05 7:24 ` Taylor, Grant [this message]
2005-05-05 8:15 ` Jozsef Kadlecsik
2005-05-05 11:24 ` Mogens Valentin
2005-05-05 11:59 ` Jozsef Kadlecsik
2005-05-05 9:37 ` Mogens Valentin
2005-05-05 10:07 ` Jozsef Kadlecsik
2005-05-04 16:39 ` Jason Opperisano
2005-05-04 17:18 ` Steven M Campbell
2005-05-04 20:37 ` Jozsef Kadlecsik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4279CA3E.3000104@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.