[2:656]?

[2:656]?

[bmcdowell]

Hello list.  I'm in the process of 'modernizing' my iptables scripts to utilize iptables-save/iptables-restore.  I've imported my script onto a test box, have exported via -save, and now I have a question or two about what I'm seeing.  

For starters, is there a reference for the changes in format?  Google is most unhelpful when trying to search for "[2:656]", for example.

Specifically, I'd like to know what the "2:656" means in the following line:

-----
*filter
:INPUT DROP [2:656]
-----

Why isn't it simply:

-----
*filter
:INPUT DROP
-----

And what would happen if I changed it?


Thanks in advance.



Bob McDowell
Network/Security Engineer 
Cox HealthPlans

Re: [2:656]?

[John Lister]

On 06/06/2011 20:35, bmcdowell@coxhealthplans.com wrote:
> Hello list.  I'm in the process of 'modernizing' my iptables scripts to utilize iptables-save/iptables-restore.  I've imported my script onto a test box, have exported via -save, and now I have a question or two about what I'm seeing. 
>
> For starters, is there a reference for the changes in format?  Google is most unhelpful when trying to search for "[2:656]", for example.
>
> Specifically, I'd like to know what the "2:656" means in the following line:
>
> -----
> *filter
> :INPUT DROP [2:656]
> -----
These are the packet/byte counts for that chain from memory - You can 
simply replace them 0:0 if you are generating scripts and don't care 
about the counts.

John

RE: [2:656]?

[bmcdowell]

Well, that explains why I couldn't search for it!  HA!

Thanks mucho.


Bob McDowell
Network/Security Engineer 
Cox HealthPlans 

-----Original Message-----
From: John Lister [mailto:john.lister@kickstone.com] 
Sent: Monday, June 06, 2011 2:58 PM
To: Bob McDowell
Cc: netfilter@vger.kernel.org
Subject: Re: [2:656]?

On 06/06/2011 20:35, bmcdowell@coxhealthplans.com wrote:
> Hello list.  I'm in the process of 'modernizing' my iptables scripts to utilize iptables-save/iptables-restore.  I've imported my script onto a test box, have exported via -save, and now I have a question or two about what I'm seeing. 
>
> For starters, is there a reference for the changes in format?  Google is most unhelpful when trying to search for "[2:656]", for example.
>
> Specifically, I'd like to know what the "2:656" means in the following line:
>
> -----
> *filter
> :INPUT DROP [2:656]
> -----
These are the packet/byte counts for that chain from memory - You can 
simply replace them 0:0 if you are generating scripts and don't care 
about the counts.

John

Re: ipv6 link local address

[Nikolay S.]

В Пнд, 06/06/2011 в 21:47 +0000, bmcdowell@coxhealthplans.com пишет:
> Hello list.  I'm updating my IBF (invisible bridging firewall) deployments, and I'd like to add support for ip6tables.  In the near-term, I'd like to '-P DROP' everything, but I'd rather not have to reinvent the wheel once/when/if we start supporting this protocol in the DMZ.
> 
> Everything seems to be moving along just fine, except the matter of the link local addressing.  While not specifically a netfilter issue, I do wonder if anyone on the list has dealt with this in the past.  It seems to my somewhat-limited understanding of the protocol that there's simply no way to filter ipv6 without 'speaking' it.  Even in my very early days of learning ipv4 I could have specified a '0.0.0.0' address on the interface, but ipv6 is designed from the ground up to prohibit this behavior.  Ostensibly for issues such as address allotment, any ipv6 enabled interface defaults to being able to converse with any other interface on the same layer 3 link.  For an IBF this is potentially a bad thing, because now my unaddressable device is suddenly addressable, even if only to those on the same local link. The simplest example scenario I can imagine is a compromised FTP/Web server speaking to a vulnerable iptables firewall and re-writing the rules it carries.
> 
> While I can certainly firewall off this traffic easily using netfilter today, I'll not be able to do that forever.  The moment I allow link-local traffic I'll be exposing my bridge interfaces to the same.  Assuming netfilter is never down or misconfigured seems to be a fatal conceit.
> 
> Thoughts?
> 
> 

You can turn off ipv6 on interfaces. This should not prevent bridging
ipv6, but will remove any ipv6 logic from them.

> Thanks in advance.
> 
> Bob McDowell
> Network/Security Engineer 
> Cox HealthPlans
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ipv6 link local address

[Erik Schorr]

On 06/06/2011 11:44 PM, Nikolay S. wrote:
> В Пнд, 06/06/2011 в 21:47 +0000, bmcdowell@coxhealthplans.com пишет:
>> Hello list.  I'm updating my IBF (invisible bridging firewall) deployments, and I'd like to add support for ip6tables.  In the near-term, I'd like to '-P DROP' everything, but I'd rather not have to reinvent the wheel once/when/if we start supporting this protocol in the DMZ.
>>
>> Everything seems to be moving along just fine, except the matter of the link local addressing.  While not specifically a netfilter issue, I do wonder if anyone on the list has dealt with this in the past.  It seems to my somewhat-limited understanding of the protocol that there's simply no way to filter ipv6 without 'speaking' it.  Even in my very early days of learning ipv4 I could have specified a '0.0.0.0' address on the interface, but ipv6 is designed from the ground up to prohibit this behavior.  Ostensibly for issues such as address allotment, any ipv6 enabled interface defaults to being able to converse with any other interface on the same layer 3 link.  For an IBF this is potentially a bad thing, because now my unaddressable device is suddenly addressable, even if only to those on the same local link. The simplest example scenario I can imagine is a compromised FTP/Web server speaking to a vulnerable iptables firewall and re-writing the rules it carries.
>>
>> While I can certainly firewall off this traffic easily using netfilter today, I'll not be able to do that forever.  The moment I allow link-local traffic I'll be exposing my bridge interfaces to the same.  Assuming netfilter is never down or misconfigured seems to be a fatal conceit.
>>
>> Thoughts?
>>
>>
>
> You can turn off ipv6 on interfaces. This should not prevent bridging
> ipv6, but will remove any ipv6 logic from them.

I wish I'd known this.  Could you give an example of how to remove ipv6 
functionality from an interface?  I think this was the only thing 
preventing me from unloading an accidentally-loaded ipv6.ko module.

-- 
Erik Schorr KD6AUT
Advocate and Consultant
VMware/Iptables/Exim/Perl

Re: ipv6 link local address

[Nikolay S.]

В Втр, 07/06/2011 в 00:06 -0700, Erik Schorr пишет:
> On 06/06/2011 11:44 PM, Nikolay S. wrote:
> > В Пнд, 06/06/2011 в 21:47 +0000, bmcdowell@coxhealthplans.com пишет:
> >> Hello list.  I'm updating my IBF (invisible bridging firewall) deployments, and I'd like to add support for ip6tables.  In the near-term, I'd like to '-P DROP' everything, but I'd rather not have to reinvent the wheel once/when/if we start supporting this protocol in the DMZ.
> >>
> >> Everything seems to be moving along just fine, except the matter of the link local addressing.  While not specifically a netfilter issue, I do wonder if anyone on the list has dealt with this in the past.  It seems to my somewhat-limited understanding of the protocol that there's simply no way to filter ipv6 without 'speaking' it.  Even in my very early days of learning ipv4 I could have specified a '0.0.0.0' address on the interface, but ipv6 is designed from the ground up to prohibit this behavior.  Ostensibly for issues such as address allotment, any ipv6 enabled interface defaults to being able to converse with any other interface on the same layer 3 link.  For an IBF this is potentially a bad thing, because now my unaddressable device is suddenly addressable, even if only to those on the same local link. The simplest example scenario I can imagine is a compromised FTP/Web server speaking to a vulnerable iptables firewall and re-writing the rules it carries.
> >>
> >> While I can certainly firewall off this traffic easily using netfilter today, I'll not be able to do that forever.  The moment I allow link-local traffic I'll be exposing my bridge interfaces to the same.  Assuming netfilter is never down or misconfigured seems to be a fatal conceit.
> >>
> >> Thoughts?
> >>
> >>
> >
> > You can turn off ipv6 on interfaces. This should not prevent bridging
> > ipv6, but will remove any ipv6 logic from them.
> 
> I wish I'd known this.  Could you give an example of how to remove ipv6 
> functionality from an interface?  I think this was the only thing 
> preventing me from unloading an accidentally-loaded ipv6.ko module.
> 

Sure

sysctl net.ipv6.conf.{interface|all|default}.disable_ipv6=1

or

echo 1 > /proc/sys/net/ipv6/conf/{interface|all|default}/disable_ipv6

RE: [2:656]?

[Jan Engelhardt]

On Monday 2011-06-06 21:59, bmcdowell@coxhealthplans.com wrote:

>> -----
>> *filter
>> :INPUT DROP [2:656]
>> -----

>Well, that explains why I couldn't search for it!  HA!

Well, it is documented right in iptables-save(8) under -c.

Re: ipv6 link local address

[Jan Engelhardt]

On Tuesday 2011-06-07 09:06, Erik Schorr wrote:
>
>> You can turn off ipv6 on interfaces. This should not prevent bridging
>> ipv6, but will remove any ipv6 logic from them.
>
> I wish I'd known this.  Could you give an example of how to remove ipv6
> functionality from an interface?  I think this was the only thing preventing me
> from unloading an accidentally-loaded ipv6.ko module.

There are no accidents. It's your userspace which triggers it loading.
And what is it actually that you are trying to fix? It smells more
like you have a bug in your environment.

Re: ipv6 link local address

[Jan Engelhardt]

On Tuesday 2011-06-07 11:24, Erik Schorr wrote:
>> There are no accidents. It's your userspace which triggers it loading.
>> And what is it actually that you are trying to fix? It smells more
>> like you have a bug in your environment.
>
>On most Linux distributions and default installations, the ipv6 module gets
>automatically loaded either on startup or when certain utilities try to probe
>ipv6 entities or test for ipv6 connectivity, even when you haven't configured
>any ipv6 interfaces.

Just as tcp and udp - were it compilable as a module - would be,
even if you don't really use any.

>It's nice to be able to unload the module to free up memory and make
>netstat and other programs' output prettier. Prettier in the way
>that you don't have extraneous output that's meaningless when there
>are no ipv6 addresses configured.

You should use ss -4 then if you want to not list IPv6 entries.
And there is an IPv6 address configued, ::1, and IPv6 simply is the
preferred protocolwhen making connections - after all, uptake has
to start somewhere.

>It's impossible to unload the ipv6 module when there's even one
>interface with ipv6 functionality enabled, even when the interface
>is administratively disabled/shutdown.

Because it hooks so deep down into the system, that is only expected.

Re: ipv6 link local address

[Erik Schorr]

On 06/07/2011 02:04 AM, Jan Engelhardt wrote:
>
> On Tuesday 2011-06-07 09:06, Erik Schorr wrote:
>>
>>> You can turn off ipv6 on interfaces. This should not prevent bridging
>>> ipv6, but will remove any ipv6 logic from them.
>>
>> I wish I'd known this.  Could you give an example of how to remove ipv6
>> functionality from an interface?  I think this was the only thing preventing me
>> from unloading an accidentally-loaded ipv6.ko module.
>
> There are no accidents. It's your userspace which triggers it loading.
> And what is it actually that you are trying to fix? It smells more
> like you have a bug in your environment.

On most Linux distributions and default installations, the ipv6 module 
gets automatically loaded either on startup or when certain utilities 
try to probe ipv6 entities or test for ipv6 connectivity, even when you 
haven't configured any ipv6 interfaces.  It's nice to be able to unload 
the module to free up memory and make netstat and other programs' output 
prettier.  Prettier in the way that you don't have extraneous output 
that's meaningless when there are no ipv6 addresses configured.

It's impossible to unload the ipv6 module when there's even one 
interface with ipv6 functionality enabled, even when the interface is 
administratively disabled/shutdown.

-- 
Erik Schorr KD6AUT
Advocate and Consultant
VMware/Iptables/Exim/Perl

AW: ipv6 link local address

[Fiedler Roman]

> On Tuesday 2011-06-07 11:24, Erik Schorr wrote:
...
> >It's impossible to unload the ipv6 module when there's even one
> >interface with ipv6 functionality enabled, even when the interface
> >is administratively disabled/shutdown.
> 
> Because it hooks so deep down into the system, that is only expected.

I think, I have ipv6 compiled into kernel, not module. But

      echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

removes all ipv6 addresses from all devices and seems to disable ipv6.

RE: [2:656]?

[bmcdowell]

Well, to be completely fair, I didn't use '-c' for my save command.  Simply 'iptables-save > file'.



Bob McDowell
Network/Security Engineer 
Cox HealthPlans 
417.269.2848 
bmcdowell@coxhealthplans.com

Confidentiality Notice: This e-mail message (including any attachments) may contain confidential and privileged information, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender by replying to this e-mail message, permanently deleting the original message and destroying any hard copies of the original message that may have been created.


-----Original Message-----
From: Jan Engelhardt [mailto:jengelh@medozas.de] 
Sent: Tuesday, June 07, 2011 4:02 AM
To: Bob McDowell
Cc: john.lister@kickstone.com; netfilter@vger.kernel.org
Subject: RE: [2:656]?

On Monday 2011-06-06 21:59, bmcdowell@coxhealthplans.com wrote:

>> -----
>> *filter
>> :INPUT DROP [2:656]
>> -----

>Well, that explains why I couldn't search for it!  HA!

Well, it is documented right in iptables-save(8) under -c.

RE: ipv6 link local address

[bmcdowell]

Please understand that I do want to be able to use ip6tables to filter forwarded traffic.  I just do not want the interfaces speaking to anyone while they're doing their job.

Perhaps this example can explain it better than I have:  http://www.sjdjweis.com/linux/bridging/


Thanks again.


Bob McDowell
Network/Security Engineer 
Cox HealthPlans 


-----Original Message-----
From: Nikolay S. [mailto:nowhere@hakkenden.ath.cx] 
Sent: Tuesday, June 07, 2011 1:44 AM
To: Bob McDowell
Cc: netfilter@vger.kernel.org
Subject: Re: ipv6 link local address


You can turn off ipv6 on interfaces. This should not prevent bridging
ipv6, but will remove any ipv6 logic from them.

RE: ipv6 link local address

[Nikolay S.]

В Втр, 07/06/2011 в 12:44 +0000, bmcdowell@coxhealthplans.com пишет:
> Please understand that I do want to be able to use ip6tables to filter forwarded traffic.  I just do not want the interfaces speaking to anyone while they're doing their job.
> 
> Perhaps this example can explain it better than I have:  http://www.sjdjweis.com/linux/bridging/
> 
> 
> Thanks again.
> 

You won't. skb's are passed to ip6tables from bridge based on ipv6-
header, not the state of the protocol on slave device. And bridge itself
does not filter incoming frames by L3-header.

> 
> Bob McDowell
> Network/Security Engineer 
> Cox HealthPlans 
> 
> 
> -----Original Message-----
> From: Nikolay S. [mailto:nowhere@hakkenden.ath.cx] 
> Sent: Tuesday, June 07, 2011 1:44 AM
> To: Bob McDowell
> Cc: netfilter@vger.kernel.org
> Subject: Re: ipv6 link local address
> 
> 
> You can turn off ipv6 on interfaces. This should not prevent bridging
> ipv6, but will remove any ipv6 logic from them.
> 
> 

RE: ipv6 link local address

[bmcdowell]

I'm sorry, but that didn't parse.

I won't, what?

Skb's?


Bob McDowell
Network/Security Engineer 
Cox HealthPlans 

-----Original Message-----
From: Nikolay S. [mailto:nowhere@hakkenden.ath.cx] 
Sent: Tuesday, June 07, 2011 9:24 AM
To: Bob McDowell
Cc: netfilter@vger.kernel.org
Subject: RE: ipv6 link local address

В Втр, 07/06/2011 в 12:44 +0000, bmcdowell@coxhealthplans.com пишет:
> Please understand that I do want to be able to use ip6tables to filter forwarded traffic.  I just do not want the interfaces speaking to anyone while they're doing their job.
> 
> Perhaps this example can explain it better than I have:  http://www.sjdjweis.com/linux/bridging/
> 
> 
> Thanks again.
> 

You won't. skb's are passed to ip6tables from bridge based on ipv6-
header, not the state of the protocol on slave device. And bridge itself
does not filter incoming frames by L3-header.

> 
> Bob McDowell
> Network/Security Engineer 
> Cox HealthPlans 
> 
> 
> -----Original Message-----
> From: Nikolay S. [mailto:nowhere@hakkenden.ath.cx] 
> Sent: Tuesday, June 07, 2011 1:44 AM
> To: Bob McDowell
> Cc: netfilter@vger.kernel.org
> Subject: Re: ipv6 link local address
> 
> 
> You can turn off ipv6 on interfaces. This should not prevent bridging
> ipv6, but will remove any ipv6 logic from them.
> 
> 

RE: ipv6 link local address

[Nikolay S.]

В Втр, 07/06/2011 в 14:26 +0000, bmcdowell@coxhealthplans.com пишет:
> I'm sorry, but that didn't parse.
> 
> I won't, what?
> 
> Skb's?

Ability to filter bridged frames with ip6tables :)

> 
> 
> Bob McDowell
> Network/Security Engineer 
> Cox HealthPlans 
> 
> -----Original Message-----
> From: Nikolay S. [mailto:nowhere@hakkenden.ath.cx] 
> Sent: Tuesday, June 07, 2011 9:24 AM
> To: Bob McDowell
> Cc: netfilter@vger.kernel.org
> Subject: RE: ipv6 link local address
> 
> В Втр, 07/06/2011 в 12:44 +0000, bmcdowell@coxhealthplans.com пишет:
> > Please understand that I do want to be able to use ip6tables to filter forwarded traffic.  I just do not want the interfaces speaking to anyone while they're doing their job.
> > 
> > Perhaps this example can explain it better than I have:  http://www.sjdjweis.com/linux/bridging/
> > 
> > 
> > Thanks again.
> > 
> 
> You won't. skb's are passed to ip6tables from bridge based on ipv6-
> header, not the state of the protocol on slave device. And bridge itself
> does not filter incoming frames by L3-header.
> 
> > 
> > Bob McDowell
> > Network/Security Engineer 
> > Cox HealthPlans 
> > 
> > 
> > -----Original Message-----
> > From: Nikolay S. [mailto:nowhere@hakkenden.ath.cx] 
> > Sent: Tuesday, June 07, 2011 1:44 AM
> > To: Bob McDowell
> > Cc: netfilter@vger.kernel.org
> > Subject: Re: ipv6 link local address
> > 
> > 
> > You can turn off ipv6 on interfaces. This should not prevent bridging
> > ipv6, but will remove any ipv6 logic from them.
> > 
> > 
> 
> 

RE: ipv6 link local address

[Jan Engelhardt]

On Tuesday 2011-06-07 16:23, Nikolay S. wrote:

>В Втр, 07/06/2011 в 12:44 +0000, bmcdowell@coxhealthplans.com пишет:
>> Please understand that I do want to be able to use ip6tables to filter forwarded traffic.  I just do not want the interfaces speaking to anyone while they're doing their job.
>> 
>> Perhaps this example can explain it better than I have:  http://www.sjdjweis.com/linux/bridging/
>> 
>> 
>> Thanks again.
>> 
>
>You won't. skb's are passed to ip6tables from bridge based on ipv6-
>header, not the state of the protocol on slave device. And bridge itself
>does not filter incoming frames by L3-header.

Usually does not, but can (ebtables --ip6-source ...).