LOGALLNEW=[log-level]
When set to a log level, this option causes Shorewall to
generate a logging rule as the first rule in each builtin chain.
o The table name is used as the chain name in the log prefix.
o The chain name is used as the target in the log prefix.
I''d like to make sure i''m understanding the functionality of
the
LOGALLNEW option.
I changed it to "info" and it''s definitely logging much more
data.
But, is it logging every packet?
Is there a way that I can log an initial handshake until a session is
established?
Ultimately, what I''m trying to do is make sure I have data to review
in my logs for any packets that come IN or OUT of our network. The man
page says that there is no rate limiting when enabling LOGALLNEW, so
is it true that LOGRATE and LOGBURST won''t help me with limiting when
enabling LOGALLNEW?
I don''t need every single packet IN/OUT, if I have to, then that will
be fine, but I just thought i''d ask.
Thanks
Brad B.
--
Have Mercy & Say Yeah
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Brad Bendily wrote:> LOGALLNEW=[log-level] > When set to a log level, this option causes Shorewall to > generate a logging rule as the first rule in each builtin chain. > o The table name is used as the chain name in the log prefix. > o The chain name is used as the target in the log prefix. > > > I''d like to make sure i''m understanding the functionality of the > LOGALLNEW option. > > I changed it to "info" and it''s definitely logging much more data. > But, is it logging every packet?It is logging every packet that is in the NEW connection state. And it is logging each of those multiple times.> > Is there a way that I can log an initial handshake until a session is > established?Use plain old LOG rules in the rules file. LOGALLNEW is intended as a debugging aid to be used infrequently and not something for continuous network auditing.> > Ultimately, what I''m trying to do is make sure I have data to review > in my logs for any packets that come IN or OUT of our network. The man > page says that there is no rate limiting when enabling LOGALLNEW, so > is it true that LOGRATE and LOGBURST won''t help me with limiting when > enabling LOGALLNEW?They ARE rate limited by LOGRATE and LOGBURST but if you use those parameters, LOGALLNEW is useless for debugging.> > I don''t need every single packet IN/OUT, if I have to, then that will > be fine, but I just thought i''d ask. >I really advise against using Netfilter for network auditing at all. But if you must, just use plain Shorewall logging rules with the ULOG pseudo log level and run ulogd to write the records to disk (possibly into a SQL database). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
> > Is there a way that I can log an initial handshake until a session is > > established? > > Use plain old LOG rules in the rules file. LOGALLNEW is intended as a > debugging aid to be used infrequently and not something for continuous > network auditing.These are my existing rules from the internal network to the external internet: ACCEPT sal ext tcp 80,443 Ok, so all of my rules look like the line above, to add LOG rules, is it best to do one rule like this: ACCEPT:info sal ext tcp 80,443 or have two rules like: LOG sal ext tcp 80,443 ACCEPT sal ext tcp 80,443 Also, my policy file looks like this: lab ext ACCEPT info scan ext ACCEPT info eng ext ACCEPT info eng lab ACCEPT info roade lab ACCEPT info ext all DROP info The "info" should be what tells the system what to log by default, if there is not a rule specified? And this should mean that any incoming packets are dropped and logged if they don''t match a specific rule allowing them, unless they''re ESTABLISHED or RELATED to an existing connection?> I really advise against using Netfilter for network auditing at all. But if > you must, just use plain Shorewall logging rules with the ULOG pseudo log > level and run ulogd to write the records to disk (possibly into a SQL database).If i''m using Shorewall to create the iptables config and load it, won''t I be using the default Shorewall logging capabilities? I''m not necessarily doing network auditing, I just want to be able to check for specific IP addresses that are either incoming or outgoing and be able to find out if something was sent in/out. It''s not something I do daily, just if someone ask if something was done, then I need to search the logs. Is using ulogd that much more beneficial than the default /var/log/messages? Thanks Brad B. -- Have Mercy & Say Yeah ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Brad Bendily wrote:>>> Is there a way that I can log an initial handshake until a session is >>> established? >> Use plain old LOG rules in the rules file. LOGALLNEW is intended as a >> debugging aid to be used infrequently and not something for continuous >> network auditing. > > These are my existing rules from the internal network to the external internet: > ACCEPT sal ext tcp 80,443 > > Ok, so all of my rules look like the line above, to add LOG rules, is > it best to do one rule like this: > ACCEPT:info sal ext tcp 80,443 > > or have two rules like: > LOG sal ext tcp 80,443 > ACCEPT sal ext tcp 80,443 >They are completely equivalent. The first takes less typing.> Also, my policy file looks like this: > lab ext ACCEPT info > scan ext ACCEPT info > eng ext ACCEPT info > eng lab ACCEPT info > roade lab ACCEPT info > ext all DROP info > > The "info" should be what tells the system what to log by default, if > there is not a rule specified?Yes.> And this should mean that any incoming > packets are dropped and logged if they don''t match a specific rule > allowing them, unless they''re ESTABLISHED or RELATED to an existing > connection?Yes.> >> I really advise against using Netfilter for network auditing at all. But if >> you must, just use plain Shorewall logging rules with the ULOG pseudo log >> level and run ulogd to write the records to disk (possibly into a SQL database). > > If i''m using Shorewall to create the iptables config and load it, > won''t I be using the default Shorewall logging capabilities? I''m not > necessarily doing network auditing, I just want to be able to check > for specific IP addresses that are either incoming or outgoing and be > able to find out if something was sent in/out. It''s not something I do > daily, just if someone ask if something was done, then I need to > search the logs.That''s still auditing. You want a record of each connection attempt.> > Is using ulogd that much more beneficial than the default /var/log/messages? >It''s more efficient. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Tue, Oct 30, 2007 at 11:06:09PM -0500, Brad Bendily wrote:> Is using ulogd that much more beneficial than the default /var/log/messages?ulogd is the only thing on Linux that is fast enough to keep up with wire speed. A lot of people never quite realise that the network card is the fastest IO device in your system (by over a factor of 10, if it''s a gigabit network). Even just storing the headers, be very sure that your disk bandwidth can take the load when the network is saturated; storing the entire packets requires multiple SCSI/SAS disks to keep up. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On 10/31/07, Andrew Suffield <asuffield@suffields.me.uk> wrote:> On Tue, Oct 30, 2007 at 11:06:09PM -0500, Brad Bendily wrote: > > Is using ulogd that much more beneficial than the default /var/log/messages? > > ulogd is the only thing on Linux that is fast enough to keep up with > wire speed. A lot of people never quite realise that the network card > is the fastest IO device in your system (by over a factor of 10, if > it''s a gigabit network). Even just storing the headers, be very sure > that your disk bandwidth can take the load when the network is > saturated; storing the entire packets requires multiple SCSI/SAS disks > to keep up.hehe, yeah, i just figured that out this morning. I turned on LOGALLNEW a couple of days ago, before I started this thread. I saw another thread that mentioned logging, it reminded me to ask so I started this thread. This morning, the firewall was responding really slow over SSH for typing even. A quick look at top showed syslog-ng was pegging the CPU. So I quickly disabled LOGALLNEW. So, one last confirmation, my policy file mentioned earlier already has "info" as the LOG LEVEL for all the sources, so I''ll get a log entry for any of the sources that are marked as DROP or REJECT? And, if I add the ":info" to all of my other rules, I will get a log entry for any of those as well? And, i should really run ULOG to be optimal for realtime logging? As always, your help/input/advice is an invaluable to me and my ability to support iptables/shorewall in my environment. What I''m try to say is, thanks for the help! Brad B. -- Have Mercy & Say Yeah ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Brad Bendily wrote:> > So, one last confirmation, my policy file mentioned earlier already > has "info" as the LOG LEVEL for all the sources, so I''ll get a log > entry for any of the sources that are marked as DROP or REJECT?And ACCEPT (assuming that you have ''LOG LEVEL'' on those).> And, > if I add the ":info" to all of my other rules, I will get a log entry > for any of those as well?Yes! But if you have an ACCEPT entries for ping and for DNS lookups, I would think twice about logging those: a) Do you really need to log every ping (remember that each echo-request packet is in the NEW state). Think about ping floods. b) Are you really interested in who did DNS lookups to where?> > And, i should really run ULOG to be optimal for realtime logging? >You''ve already seen what can happen if you don''t. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
> > And, i should really run ULOG to be optimal for realtime logging? > > > > You''ve already seen what can happen if you don''t.Doh, I forgot to ask do I need to add anything to my kernel for ULOG support, after looking at the kernel config the line that says: < > ULOG target support When you look at the help for that option it says: CONFIG_IP_NF_TARGET_ULOG: This option enables the old IPv4-only "ipt_ULOG" implementation which has been obsoleted by the new "nfnetlink_log" code (see CONFIG_NETFILTER_NETLINK_LOG). This option adds a `ULOG'' target, which allows you to create rules in any iptables table. The packet is passed to a userspace logging daemon using netlink multicast sockets; unlike the LOG target which can only be viewed through syslog. So, originally I didn''t enable ULOG support (at least that option) because it appears to be outdated. But maybe ULOG will work in Shorewall without enabling anything? But, after looking at a few docs, it seems I do need to enable the ULOG support? BB -- Have Mercy & Say Yeah ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Brad Bendily wrote:> > But, after looking at a few docs, it seems I do need to enable the ULOG support? >Yes. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Brad Bendily wrote: >> Ultimately, what I''m trying to do is make sure I have data to review >> in my logs for any packets that come IN or OUT of our network. The man >> page says that there is no rate limiting when enabling LOGALLNEW, so >> is it true that LOGRATE and LOGBURST won''t help me with limiting when >> enabling LOGALLNEW? > > They ARE rate limited by LOGRATE and LOGBURST but if you use those > parameters, LOGALLNEW is useless for debugging. >What I wrote there is incorrect. There is no rate limiting on LOGALLNEW. The manpage was correct to start with. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/