logging question

logging question

[Eric Moore]

I have a debian unstable machine I'm trying to get selinux to work on.
I've gotten a policy to build, installed the userland tools, loaded
it, etc.  It's working, because I can swithc into enforcing mode, and
things break (presumably due to my havng screwed up the policy).  But
I never sdeem to get any logging messages of what was denied and why
(In or out of enforcing mode).  What's the best way for me to get
the kernel to log the appropriate messages somewhere?

Thanks.

-- 
Eric

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: logging question

[Stephen Smalley]

On Mon, 2005-10-17 at 12:26 -0400, Eric Moore wrote:
> I have a debian unstable machine I'm trying to get selinux to work on.
> I've gotten a policy to build, installed the userland tools, loaded
> it, etc.  It's working, because I can swithc into enforcing mode, and
> things break (presumably due to my havng screwed up the policy).  But
> I never sdeem to get any logging messages of what was denied and why
> (In or out of enforcing mode).  What's the best way for me to get
> the kernel to log the appropriate messages somewhere?

In 2.6, SELinux was converted over to using the native kernel audit
subsystem for logging its denials.  So:
- Does your kernel have auditing enabled (CONFIG_AUDIT=y)?  If not, time
to rebuild your kernel.
- Are you running auditd?  If so, look in /var/log/audit/audit.log or
wherever /etc/auditd.conf directs audit messages.  If not, look
in /var/log/messages or wherever /etc/syslog.conf directs kern.warn
messages.
- If you still don't have anything logged in either location, run 'make
clean enableaudit load' in your policy directory to clear all
"dontaudit" rules from the loaded policy so that no log messages are
suppressed (normally, certain denials are silently denied to avoid
filling your logs with noise from known probing by library and
applications that is common but not needed for operation).  Then do a
'make clean load' later to re-include those dontaudit rules after you've
collected your log messages.
  
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: logging question

[Russell Coker]

On Tuesday 18 October 2005 02:39, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > (In or out of enforcing mode).  What's the best way for me to get
> > the kernel to log the appropriate messages somewhere?
>
> In 2.6, SELinux was converted over to using the native kernel audit
> subsystem for logging its denials.  So:
> - Does your kernel have auditing enabled (CONFIG_AUDIT=y)?  If not, time
> to rebuild your kernel.

The Debian kernel binary packages are built with SE Linux enabled but auditing 
disabled.  I have sent several messages to the relevant people about this 
matter and had no positive response.  Several 2.6.x kernels have been 
released in this state.

> - Are you running auditd?  If so, look in /var/log/audit/audit.log or
> wherever /etc/auditd.conf directs audit messages.  If not, look
> in /var/log/messages or wherever /etc/syslog.conf directs kern.warn
> messages.

auditd is not yet packaged for Debian.  The first person to volunteer gave up 
because it was too difficult.  I gave it a go but found that the kernel 
headers packaged with Debian did not support the interfaces needed by auditd 
(this was my impression at the time and I'm going from memory - this 
statement may not be entirely correct).  When I get back from AUUG2005 I'll 
give it another go.

Incidentally being able to build from the standard headers is a requirement 
for Debian.  All Debian packages get automatically built for architectures 
other than the one used for the initial build, so the headers in question 
need to be installed in all build machines.  I could hack the compile process 
for i386 but not for all the rest (I tried it before in the old-selinux days 
and it wasn't fun).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: logging question

[Luke Kenneth Casson Leighton]

raising a bug request with the debian guys, hope you don't mind me
taking the liberty, russell...


On Tue, Oct 18, 2005 at 07:52:25AM +1000, Russell Coker wrote:
> On Tuesday 18 October 2005 02:39, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > > (In or out of enforcing mode).  What's the best way for me to get
> > > the kernel to log the appropriate messages somewhere?
> >
> > In 2.6, SELinux was converted over to using the native kernel audit
> > subsystem for logging its denials.  So:
> > - Does your kernel have auditing enabled (CONFIG_AUDIT=y)?  If not, time
> > to rebuild your kernel.
> 
> The Debian kernel binary packages are built with SE Linux enabled but auditing 
> disabled.  I have sent several messages to the relevant people about this 
> matter and had no positive response.  Several 2.6.x kernels have been 
> released in this state.
> 
> > - Are you running auditd?  If so, look in /var/log/audit/audit.log or
> > wherever /etc/auditd.conf directs audit messages.  If not, look
> > in /var/log/messages or wherever /etc/syslog.conf directs kern.warn
> > messages.
> 
> auditd is not yet packaged for Debian.  The first person to volunteer gave up 
> because it was too difficult.  I gave it a go but found that the kernel 
> headers packaged with Debian did not support the interfaces needed by auditd 
> (this was my impression at the time and I'm going from memory - this 
> statement may not be entirely correct).  When I get back from AUUG2005 I'll 
> give it another go.
> 
> Incidentally being able to build from the standard headers is a requirement 
> for Debian.  All Debian packages get automatically built for architectures 
> other than the one used for the initial build, so the headers in question 
> need to be installed in all build machines.  I could hack the compile process 
> for i386 but not for all the rest (I tried it before in the old-selinux days 
> and it wasn't fun).
> 
> -- 
> http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
> http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
> http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
> http://www.coker.com.au/~russell/  My home page
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: logging question

[Stephen Smalley]

On Tue, 2005-10-18 at 07:52 +1000, Russell Coker wrote:
> On Tuesday 18 October 2005 02:39, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > > (In or out of enforcing mode).  What's the best way for me to get
> > > the kernel to log the appropriate messages somewhere?
> >
> > In 2.6, SELinux was converted over to using the native kernel audit
> > subsystem for logging its denials.  So:
> > - Does your kernel have auditing enabled (CONFIG_AUDIT=y)?  If not, time
> > to rebuild your kernel.
> 
> The Debian kernel binary packages are built with SE Linux enabled but auditing 
> disabled.  I have sent several messages to the relevant people about this 
> matter and had no positive response.  Several 2.6.x kernels have been 
> released in this state.

They may be concerned about the performance overhead of the audit
infrastructure, but most of that is from CONFIG_AUDIT_SYSCALL=y, not
just CONFIG_AUDIT=y, and SELinux only requires the latter to perform
basic auditing of permission denials (the former can be useful in
getting more information about the syscalls and is needed by auditd, but
not strictly by SELinux).

Other option is to make the #undef CONFIG_AUDIT case revert to using
printks like the original SELinux code.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: logging question

[Russell Coker]

On Tuesday 18 October 2005 21:56, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> They may be concerned about the performance overhead of the audit
> infrastructure, but most of that is from CONFIG_AUDIT_SYSCALL=y, not
> just CONFIG_AUDIT=y, and SELinux only requires the latter to perform
> basic auditing of permission denials (the former can be useful in
> getting more information about the syscalls and is needed by auditd, but
> not strictly by SELinux).
>
> Other option is to make the #undef CONFIG_AUDIT case revert to using
> printks like the original SELinux code.

Of course doing that would either give very poor information on the action 
that caused the AVC message or require some kernel coding work to deliver a 
moderate amount of information (what we used to get before the audit code was 
used), and certainly nothing like the amount of information that we get now 
that SE Linux uses the audit framework.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: logging question

[Manoj Srivastava]

On Tue, 18 Oct 2005 07:52:25 +1000, Russell Coker <russell@coker.com.au> said: 

> The Debian kernel binary packages are built with SE Linux enabled
> but auditing disabled.  I have sent several messages to the relevant
> people about this matter and had no positive response.  Several
> 2.6.x kernels have been released in this state.

        The latest 2.6.14 kernels have CONFIG_AUDIT=y, as well as
 CONFIG_AUDITSYSCALL=y

        Is a new release of libsepol imminent, or should I go fetch
 the 1.9.X release from CVS and upload that to Debian?

        manoj
ps: Sorry for being tardy on the Debian SELinux front, but I am just
coming out of a health issue, and had been unable to spend time on SELINUX
-- 
Time is an illusion perpetrated by the manufacturers of space.
Manoj Srivastava   <manoj.srivastava@stdc.com>    <srivasta@acm.org> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: logging question

[Luke Kenneth Casson Leighton]

hiya manoj,

was wondering where you got to.  someone on the debian kernel team
contacted me last month, wondering who the debian / selinux point of
contact was.

do you know the people to speak to such that a debian-selinux mailing
list can be set up because that's the "natural" place people would
expect to look for ... and it don't exist.

l.

On Sat, Oct 29, 2005 at 11:00:24AM -0500, Manoj Srivastava wrote:
> On Tue, 18 Oct 2005 07:52:25 +1000, Russell Coker <russell@coker.com.au> said: 
> 
> > The Debian kernel binary packages are built with SE Linux enabled
> > but auditing disabled.  I have sent several messages to the relevant
> > people about this matter and had no positive response.  Several
> > 2.6.x kernels have been released in this state.
> 
>         The latest 2.6.14 kernels have CONFIG_AUDIT=y, as well as
>  CONFIG_AUDITSYSCALL=y
> 
>         Is a new release of libsepol imminent, or should I go fetch
>  the 1.9.X release from CVS and upload that to Debian?
> 
>         manoj
> ps: Sorry for being tardy on the Debian SELinux front, but I am just
> coming out of a health issue, and had been unable to spend time on SELINUX
> -- 
> Time is an illusion perpetrated by the manufacturers of space.
> Manoj Srivastava   <manoj.srivastava@stdc.com>    <srivasta@acm.org> 
> 1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: logging question

[Dale Amon]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

On Sat, Oct 29, 2005 at 11:00:24AM -0500, Manoj Srivastava wrote:
> ps: Sorry for being tardy on the Debian SELinux front, but I am just
> coming out of a health issue, and had been unable to spend time on SELINUX

Manoj, glad to hear you are feeling better. I spent 
some time about a month ago trying to get Debian
selinux running on a test system but had to give up
for the time being when my window of unallocated
time ran out.

I have two projects coming up on which I would love
to be able to deploy SELinux, but I would have to
do it on Sarge dists since these will be real life
critical services. I hope to get back to testing
Debian SELinux in the coming month and I am sure
your assistance will be invaluable.

-- 
------------------------------------------------------
             Artemis Systems Development
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Logging question

[dave beach]

Hi, I have been using iptables for quite some time now but only recently
have decided to do things a bit differently. I'm trying to ulog various
things, and am having an unexpected problem ulogging packets outbound on
eth0 (the external interface). I don't have a problem constructing the rule,
just in figuring out in which table/chain to place it.

I'm clearly still not fully understanding table/chain traversal. It was my
understanding that every outbound packet, no matter where its origin or
destination, would pass through the nat/POSTROUTING chain, so this is where
my ulog rule came in to try and log all outbound packets. After seeing this
wasn't working (at all, although a similar rule to ulog all packets outbound
on eth1 (the internal interface) placed right after it seems to work like a
charm), I noticed in Oskar's excellent tutorial the statement that some
packets may not in fact pass through nat/POSTROUTING at all.

Without posting my entire iptables script, I guess I have several general
questions:

1) Can the "flow" diagram in section 3.1 of Oskar's tutorial be relied upon?
I would have thought so, and it has seemed reliable in practice, but the
failure of this one logging rule is now making me doubt that.

2) Under what circumstances would packets not traverse the nat/POSTROUTING
chain, as hinted at by Oskar in the tutorial?

3) Where would be a more appropriate place to put a ulog rule to capture
details of all outbound packets on eth0, and why would that not be the same
place as one to capture details of all outbound packets on eth1? I suspect
the answer to this is intimately related to the answers to 1 and 2 above.

Any help would be appreciated; I can post my iptables script if it would be
useful.

Re: Logging question

[Samuel Jean]

On Wed, February 9, 2005 9:08 am, dave beach said:

Hi dave!

> [...]
> Without posting my entire iptables script, I guess I have several general
> questions:
>
> 1) Can the "flow" diagram in section 3.1 of Oskar's tutorial be relied
> upon?
> I would have thought so, and it has seemed reliable in practice, but the
> failure of this one logging rule is now making me doubt that.

At some point, the diagram is right. There's just one thing missing and I
think that's where you got stuck.

There's an invisible hook called conntrack which happens right before NAT
table. See answer below...

>
> 2) Under what circumstances would packets not traverse the nat/POSTROUTING
> chain, as hinted at by Oskar in the tutorial?

Here's a good one from this same tutorial. Let me bring you to
section 3.3:

"Note that, as we have said before, only the first packet in a stream will
hit this chain. After this, the rest of the packets will automatically
have the same action taken on them as the first packet."

That means, every packets that are NEW to the conntrack will get through
NAT table. Subsequent packet won't pass thru because it's useless and may
lead to inconsistency. Let's say you have a flow of data in progress, you
DNAT'ed that flow up to some host into your LAN. If you change the DNAT
rule while there's a current flow using it, that won't affect the flow
"in progress".

As long as the entry (called tuple here) belongs to the conntrack, there
won't be any other (NAT) action taken on it.

>
> 3) Where would be a more appropriate place to put a ulog rule to capture
> details of all outbound packets on eth0, and why would that not be the
> same
> place as one to capture details of all outbound packets on eth1? I suspect
> the answer to this is intimately related to the answers to 1 and 2 above.

The POSTROUTING hook from the _mangle_ table is appropriate. This one
is always concerned.

>
> Any help would be appreciated; I can post my iptables script if it would
> be
> useful.

HTH,
Samuel

RE: Logging question

[dave beach]

Thanks, Samuel.

So, if I understand correctly, the reason that nothing at all is being
logged out eth0 (via the rule in the nat/POSTROUTING chain) is because all
those packets are related to packets previously seen by the state machine
and thus don't traverse that chain.

Okay, but that leaves me with the question about why I'd see so many packets
logged out eth1 via a similar rule in the same place. The above explanation
seems to tell me that each and every packet so logged would be the "first",
and thus new.

I guess the way to test this would be to move BOTH rules to
mangle/POSTROUTING. I'd expect, based on the above, to see the packets
logged out eth1 to jump dramatically. Does this sound generally correct?


-----Original Message-----
From: Samuel Jean [mailto:sj-netfilter@cookinglinux.org] 
Sent: February 9, 2005 10:36 AM
To: dave beach
Cc: netfilter@lists.netfilter.org
Subject: Re: Logging question

On Wed, February 9, 2005 9:08 am, dave beach said:

Hi dave!

> [...]
> Without posting my entire iptables script, I guess I have several 
> general
> questions:
>
> 1) Can the "flow" diagram in section 3.1 of Oskar's tutorial be relied 
> upon?
> I would have thought so, and it has seemed reliable in practice, but 
> the failure of this one logging rule is now making me doubt that.

At some point, the diagram is right. There's just one thing missing and I
think that's where you got stuck.

There's an invisible hook called conntrack which happens right before NAT
table. See answer below...

>
> 2) Under what circumstances would packets not traverse the 
> nat/POSTROUTING chain, as hinted at by Oskar in the tutorial?

Here's a good one from this same tutorial. Let me bring you to section 3.3:

"Note that, as we have said before, only the first packet in a stream will
hit this chain. After this, the rest of the packets will automatically have
the same action taken on them as the first packet."

That means, every packets that are NEW to the conntrack will get through NAT
table. Subsequent packet won't pass thru because it's useless and may lead
to inconsistency. Let's say you have a flow of data in progress, you DNAT'ed
that flow up to some host into your LAN. If you change the DNAT rule while
there's a current flow using it, that won't affect the flow "in progress".

As long as the entry (called tuple here) belongs to the conntrack, there
won't be any other (NAT) action taken on it.

>
> 3) Where would be a more appropriate place to put a ulog rule to 
> capture details of all outbound packets on eth0, and why would that 
> not be the same place as one to capture details of all outbound 
> packets on eth1? I suspect the answer to this is intimately related to 
> the answers to 1 and 2 above.

The POSTROUTING hook from the _mangle_ table is appropriate. This one is
always concerned.

>
> Any help would be appreciated; I can post my iptables script if it 
> would be useful.

HTH,
Samuel

RE: Logging question

[Samuel Jean]

On Wed, February 9, 2005 10:35 am, dave beach said:
> Thanks, Samuel.
>
> So, if I understand correctly, the reason that nothing at all is being
> logged out eth0 (via the rule in the nat/POSTROUTING chain) is because all
> those packets are related to packets previously seen by the state machine
> and thus don't traverse that chain.

Unless you tell my that you put the logging rule _after_ the DNAT rule.
I assume the above is right, but a bit unbeleivable. If that's really
what happen (entries already exist), you can verify if my
assumption/explanation is right by unloading the ip_conntrack module
(and everything depending on). And test again with fresh conntrack.

>
> Okay, but that leaves me with the question about why I'd see so many
> packets
> logged out eth1 via a similar rule in the same place. The above
> explanation
> seems to tell me that each and every packet so logged would be the
> "first",
> and thus new.

Perhaps you've put your eth1 logging after eth1 DNAT and you see log for
the eth0 NAT. Is that possible case ?

>
> I guess the way to test this would be to move BOTH rules to
> mangle/POSTROUTING. I'd expect, based on the above, to see the packets
> logged out eth1 to jump dramatically. Does this sound generally correct?

Both logging rules at top of this chain should tell you the truth.

Cheers,
Samuel

RE: Logging question

[dave beach]

Here are the actual rules in the nat/POSTROUTING chain from my rc.firewall
script ($EXT_INT is eth0, $INT_INT is eth1, $EXT_IP is the ip address bound
to eth0):

#
###############################
# STEP 5.11 - nat/POSTROUTING #
###############################
#
#   SNAT all packets to the firewall's external interface addr
#
      $IPTABLES -t nat -A POSTROUTING -o $EXT_INT -j SNAT --to-source
$EXT_IP
#
#   Log the outbound data
#
       $IPTABLES -t nat -A POSTROUTING -o $EXT_INT -j ULOG --ulog-nlgroup 4
--ulog-prefix "RAW OUT: " --ulog-qthreshold 1
       $IPTABLES -t nat -A POSTROUTING -o $INT_INT -j ULOG --ulog-nlgroup 5
--ulog-prefix "RAW OUT: " --ulog-qthreshold 1
#

My expectation when I wrote these rules was that they'd provide me with
complete logs for all packets outbound on eth0 and eth1, right before they
went out on the wire. In reality, they are generating no logs whatsoever for
eth0 and what I thought were complete logs for eth1. I'm no longer sure
about the latter.

As you've suggested, I'll try moving the logging rules to the
mangle/POSTROUTING chain and see what happens. It's not where my tidy mind
would prefer to have the rules, but that obviously gets trumped by needing
to have them where they work.

-----Original Message-----
From: Samuel Jean [mailto:sj-netfilter@cookinglinux.org] 
Sent: February 9, 2005 11:11 AM
To: dave beach
Cc: netfilter@lists.netfilter.org
Subject: RE: Logging question

On Wed, February 9, 2005 10:35 am, dave beach said:
> Thanks, Samuel.
>
> So, if I understand correctly, the reason that nothing at all is being 
> logged out eth0 (via the rule in the nat/POSTROUTING chain) is because 
> all those packets are related to packets previously seen by the state 
> machine and thus don't traverse that chain.

Unless you tell my that you put the logging rule _after_ the DNAT rule.
I assume the above is right, but a bit unbeleivable. If that's really what
happen (entries already exist), you can verify if my assumption/explanation
is right by unloading the ip_conntrack module (and everything depending on).
And test again with fresh conntrack.

>
> Okay, but that leaves me with the question about why I'd see so many 
> packets logged out eth1 via a similar rule in the same place. The 
> above explanation seems to tell me that each and every packet so 
> logged would be the "first", and thus new.

Perhaps you've put your eth1 logging after eth1 DNAT and you see log for the
eth0 NAT. Is that possible case ?

>
> I guess the way to test this would be to move BOTH rules to 
> mangle/POSTROUTING. I'd expect, based on the above, to see the packets 
> logged out eth1 to jump dramatically. Does this sound generally correct?

Both logging rules at top of this chain should tell you the truth.

Cheers,
Samuel

RE: Logging question

[Samuel Jean]

On Wed, February 9, 2005 11:32 am, dave beach said:
> Here are the actual rules in the nat/POSTROUTING chain from my rc.firewall
> script ($EXT_INT is eth0, $INT_INT is eth1, $EXT_IP is the ip address
> bound
> to eth0):
>
> #
> ###############################
> # STEP 5.11 - nat/POSTROUTING #
> ###############################
> #
> #   SNAT all packets to the firewall's external interface addr
> #
>       $IPTABLES -t nat -A POSTROUTING -o $EXT_INT -j SNAT --to-source
> $EXT_IP
> #
> #   Log the outbound data
> #
>        $IPTABLES -t nat -A POSTROUTING -o $EXT_INT -j ULOG --ulog-nlgroup
> 4
> --ulog-prefix "RAW OUT: " --ulog-qthreshold 1
>        $IPTABLES -t nat -A POSTROUTING -o $INT_INT -j ULOG --ulog-nlgroup
> 5
> --ulog-prefix "RAW OUT: " --ulog-qthreshold 1
> #
>

As a side note, it becomes obvious now why you don't get any log for eth0:

The packet going out on eth0 get SNAT'ed and suddently stop iterating
through that chain, its next step : the wire road.

The reason on why you got all the log for eth1 is that such outgoing packets
_don't_ match the requierement for being SNAT'ed. They, obviously, continue
iterating: they don't match the eth0 logging rule, but they next match
the eth1 rule.

All of this would work if eth0 logging rule was on top. Also, eth1 logging
rule position doesn't matter in this case.

Sorry if you already got it.

Have a nice day,

Samuel

RE: Logging question

[dave beach]

That actually occurred to me - but it raised the question, and I apologize
if it's a silly one, of why the SNATted packets would jump out of the chain.
It didn't strike me as the same sort of a situation as a target match, where
rule position can be critical.

Of course, any minute now I'll actually TRY a few things and stop writing
messages about questions. 

-----Original Message-----
From: Samuel Jean [mailto:sj-netfilter@cookinglinux.org] 
Sent: February 9, 2005 12:08 PM
To: dave beach
Cc: netfilter@lists.netfilter.org
Subject: RE: Logging question

On Wed, February 9, 2005 11:32 am, dave beach said:
> Here are the actual rules in the nat/POSTROUTING chain from my 
> rc.firewall script ($EXT_INT is eth0, $INT_INT is eth1, $EXT_IP is the 
> ip address bound to eth0):
>
> #
> ###############################
> # STEP 5.11 - nat/POSTROUTING #
> ###############################
> #
> #   SNAT all packets to the firewall's external interface addr
> #
>       $IPTABLES -t nat -A POSTROUTING -o $EXT_INT -j SNAT --to-source 
> $EXT_IP #
> #   Log the outbound data
> #
>        $IPTABLES -t nat -A POSTROUTING -o $EXT_INT -j ULOG 
> --ulog-nlgroup
> 4
> --ulog-prefix "RAW OUT: " --ulog-qthreshold 1
>        $IPTABLES -t nat -A POSTROUTING -o $INT_INT -j ULOG 
> --ulog-nlgroup
> 5
> --ulog-prefix "RAW OUT: " --ulog-qthreshold 1 #
>

As a side note, it becomes obvious now why you don't get any log for eth0:

The packet going out on eth0 get SNAT'ed and suddently stop iterating
through that chain, its next step : the wire road.

The reason on why you got all the log for eth1 is that such outgoing packets
_don't_ match the requierement for being SNAT'ed. They, obviously, continue
iterating: they don't match the eth0 logging rule, but they next match the
eth1 rule.

All of this would work if eth0 logging rule was on top. Also, eth1 logging
rule position doesn't matter in this case.

Sorry if you already got it.

Have a nice day,

Samuel

RE: Logging question

[dave beach]

 
Hi Samuel -

> Of course, any minute now I'll actually TRY a few things and stop writing
messages about questions.

Seems to be working now after moving the logging rules to mangle/POSTROUTING
from nat/POSTROUTING; thanks very much for your help.