Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Mogens Valentin <monz@danbbs.dk>
To: netfilter@lists.netfilter.org
Cc: "Taylor, Grant" <gtaylor@riverviewtech.net>,
	Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Subject: Re: Iptables logs on High bandwidth traffic network
Date: Thu, 05 May 2005 11:37:48 +0200	[thread overview]
Message-ID: <4279E96C.7010304@danbbs.dk> (raw)
In-Reply-To: <Pine.LNX.4.58.0505050848090.21265@blackhole.kfki.hu>

Jozsef Kadlecsik wrote:
> On Wed, 4 May 2005, Taylor, Grant wrote:
> 
> 
>>>How about using a fifo (man mkfifo and man syslog) and let syslog pipe
>>>to that fifo. Some program can then read from the fifo, parse data, and
>>>maybe use a database for storing the parsed, now more limited, data.
>>>Might be a good ide to have the database on another system :-
>>
>>Using a FIFO to a program that parses and transmits the data to another
>>system to network might be a possibility.  Keep in mind that any
>>processing that you do on the packets has to be able to be done at least
>>as fast if not faster than the rate the packets come in.  If you ever
>>end up getting behind on the processing things will snowball on you VERY
>>quickly and more than likely end up in a very nasty mess.  This is why I
>>think it would be better to use something like TCPDump or Snort to sniff
>>the network and then post process the dumps.
> 
> 
> 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 might not.. AFAIK, the FIFO is implemented not as disk I/O, but is a 
memory thingy.
It *appears* as file I/O, but the filesystem is used only to create that 
named pipe.
Hence, my thought was that since logging with iptables has to go throu 
syslog, this might offload faster through a FIFO.
The app reading the FIFO would preprocess the datastream and turn it 
into chunks, exactly as Taylor put it.
Depending on what one really wants to look at / dig out of logging, the 
FIFO-reading app could also reduce data.

-- 
Kind regards,
Mogens Valentin



  parent reply	other threads:[~2005-05-05  9:37 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
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 [this message]
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=4279E96C.7010304@danbbs.dk \
    --to=monz@danbbs.dk \
    --cc=gtaylor@riverviewtech.net \
    --cc=kadlec@blackhole.kfki.hu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox