* Re: [PATCH] slob: push the min alignment to long long
From: Matt Mackall @ 2011-06-15 22:53 UTC (permalink / raw)
To: David Miller; +Cc: penberg, sebastian, cl, linux-mm, netfilter
In-Reply-To: <20110615.181148.650483947691740732.davem@davemloft.net>
On Wed, 2011-06-15 at 18:11 -0400, David Miller wrote:
> From: Matt Mackall <mpm@selenic.com>
> Date: Wed, 15 Jun 2011 15:55:55 -0500
>
> > In general, I think the right thing is to require every arch to
> > explicitly document its alignment requirements via defines in the kernel
> > headers so that random hackers don't have to scour the internet for
> > datasheets on obscure architectures they don't care about.
>
> Blink... because the compiler doesn't provide a portable way to
> do this, right? :-)
Because I, on x86, cannot deduce the alignment requirements of, say,
CRIS without doing significant research. So answering a question like
"are there any architectures where assumption X fails" is obnoxiously
hard, rather than being a grep.
I also don't think it's a given there's a portable way to deduce the
alignment requirements due to the existence of arch-specific quirks. If
an arch wants to kmalloc its weird crypto or SIMD context and those want
128-bit alignment, we're not going to want to embed that knowledge in
the generic code, but instead tweak an arch define.
Also note that not having generic defaults forces each new architectures
to (nominally) examine each assumption rather than discover they
inherited an incorrect default somewhere down the road.
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: come back the traffic on same interface which it input
From: Usuário do Sistema @ 2011-06-16 0:37 UTC (permalink / raw)
To: Steven Kath; +Cc: Mail List - Netfilter
In-Reply-To: <1308164291.32634.26.camel@lt>
Thank you Steven, it's working as your as below
Em 15 de junho de 2011 15:58, Steven Kath <steven.kath@vyatta.com> escreveu:
> On Tue, 2011-06-14 at 23:31 -0300, Usuário do Sistema wrote:
>> hello everyone, I have two ISPs in my firewall that are ADSLs lines. I
>> wish that all trafic input in wan1 ( ISP1 ) come back on it. but this
>> isn't happening because the firewall gateway is ISP2 ( wan2 ) so all
>> input traffic by ISP1 ( wan1 ) doesn't work because the firewall
>> forwards all traffic as it as your gateway wich is ISP2
>>
>> for exemplo, I have a http service on this firewall and when I attempt
>> access it from Internet doesn't work because it's on my ISP1.
>>
>> how I can do for all input traffic on wan1 come back on it and not on
>> wan2 wich is the firewall gateway ??
>>
>> any tips are welcome
>
> Here is a good start for a simple implementation:
>
> http://lartc.org/howto/lartc.rpdb.multiple-links.html
>
> If you need to be more selective, you can use iptables markings to get
> finer control:
>
> http://linux-ip.net/html/adv-multi-internet.html
>
>
>
^ permalink raw reply
* Re: [PATCH] slob: push the min alignment to long long
From: Pekka Enberg @ 2011-06-16 6:59 UTC (permalink / raw)
To: Matt Mackall; +Cc: David Miller, sebastian, cl, linux-mm, netfilter
In-Reply-To: <1308178420.15617.447.camel@calx>
On Thu, Jun 16, 2011 at 1:53 AM, Matt Mackall <mpm@selenic.com> wrote:
>> Blink... because the compiler doesn't provide a portable way to
>> do this, right? :-)
>
> Because I, on x86, cannot deduce the alignment requirements of, say,
> CRIS without doing significant research. So answering a question like
> "are there any architectures where assumption X fails" is obnoxiously
> hard, rather than being a grep.
>
> I also don't think it's a given there's a portable way to deduce the
> alignment requirements due to the existence of arch-specific quirks. If
> an arch wants to kmalloc its weird crypto or SIMD context and those want
> 128-bit alignment, we're not going to want to embed that knowledge in
> the generic code, but instead tweak an arch define.
>
> Also note that not having generic defaults forces each new architectures
> to (nominally) examine each assumption rather than discover they
> inherited an incorrect default somewhere down the road.
I don't agree. I think we should either provide defaults that work for
everyone and let architectures override them (which AFAICT Christoph's
patch does) or we flat out #error if architectures don't specify
alignment requirements. The current solution seems to be the worst one
from practical point of view.
This doesn't seem to be a *regression* per se so I'll queue
Christoph's patch for 3.1 and mark it for 3.0-stable.
Pekka
^ permalink raw reply
* Re: [GIT PULL net-next-2.6] IPVS
From: Patrick McHardy @ 2011-06-16 15:05 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Wensong Zhang,
Julian Anastasov, Pablo Neira Ayuso
In-Reply-To: <1308095001-21002-1-git-send-email-horms@verge.net.au>
On 15.06.2011 01:43, Simon Horman wrote:
> Hi Patrick, Hi Pablo,
>
> please consider pulling
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next-2.6.git
> master
>
> It includes four clean-ups by Hans
> and an enhancement of the FTP helper by Julian.
>
> I have based the pull request on next-2.6 as
> nf-next-2.6 seems to be a little old. Please let me
> know if a different base would suit you better.
>
> Hans Schillstrom (4):
> IPVS remove unused var from migration to netns
> IPVS: rename of netns init and cleanup functions.
> IPVS: labels at pos 0
> IPVS: remove unused init and cleanup functions.
>
> Julian Anastasov (1):
> ipvs: support more FTP PASV responses
>
Pulled, thanks Simon.
^ permalink raw reply
* Re: [GIT PULL nf-2.6] IPVS
From: Patrick McHardy @ 2011-06-16 15:11 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Wensong Zhang,
Julian Anastasov, Pablo Neira Ayuso
In-Reply-To: <1307954861-21592-1-git-send-email-horms@verge.net.au>
On 13.06.2011 10:47, Simon Horman wrote:
> Hi Pablo,
>
> please consider pulling
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-2.6.git master
> to get the following fix from Hans.
>
> I believe this change should be considered for -stable.
Just send it to the stable people once it hits upstream. I'll
send it to Dave tonight.
> Hans Schillstrom (1):
> IPVS netns exit causes crash in conntrac
Pulled, thanks Simon.
^ permalink raw reply
* Re: [PATCH] netfilter/ip_tables: fix compile with debug
From: Patrick McHardy @ 2011-06-16 15:17 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: netfilter-devel, netfilter
In-Reply-To: <1308169381-10067-1-git-send-email-sebastian@breakpoint.cc>
On 15.06.2011 22:23, Sebastian Andrzej Siewior wrote:
> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Applied, thanks. We should really convert this stuff to pr_debug to
make sure these problems are found even without debugging enabled.
^ permalink raw reply
* Re: [PATCH] slob: push the min alignment to long long
From: Matt Mackall @ 2011-06-16 15:23 UTC (permalink / raw)
To: Pekka Enberg; +Cc: David Miller, sebastian, cl, linux-mm, netfilter
In-Reply-To: <BANLkTikOM6=fWnUA1bNZOM-jwg=o=CL8Ug@mail.gmail.com>
On Thu, 2011-06-16 at 09:59 +0300, Pekka Enberg wrote:
> On Thu, Jun 16, 2011 at 1:53 AM, Matt Mackall <mpm@selenic.com> wrote:
> >> Blink... because the compiler doesn't provide a portable way to
> >> do this, right? :-)
> >
> > Because I, on x86, cannot deduce the alignment requirements of, say,
> > CRIS without doing significant research. So answering a question like
> > "are there any architectures where assumption X fails" is obnoxiously
> > hard, rather than being a grep.
> >
> > I also don't think it's a given there's a portable way to deduce the
> > alignment requirements due to the existence of arch-specific quirks. If
> > an arch wants to kmalloc its weird crypto or SIMD context and those want
> > 128-bit alignment, we're not going to want to embed that knowledge in
> > the generic code, but instead tweak an arch define.
> >
> > Also note that not having generic defaults forces each new architectures
> > to (nominally) examine each assumption rather than discover they
> > inherited an incorrect default somewhere down the road.
>
> I don't agree. I think we should either provide defaults that work for
> everyone and let architectures override them (which AFAICT Christoph's
> patch does) or we flat out #error if architectures don't specify
> alignment requirements.
Uh, isn't the latter precisely what I say above?
> The current solution seems to be the worst one
> from practical point of view.
Good, because no one's advocating for it.
> This doesn't seem to be a *regression* per se so I'll queue
> Christoph's patch for 3.1 and mark it for 3.0-stable.
> Pekka
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] slob: push the min alignment to long long
From: Pekka Enberg @ 2011-06-16 15:28 UTC (permalink / raw)
To: Matt Mackall; +Cc: David Miller, sebastian, cl, linux-mm, netfilter
In-Reply-To: <1308237823.15617.451.camel@calx>
On Thu, 2011-06-16 at 10:23 -0500, Matt Mackall wrote:
> > I don't agree. I think we should either provide defaults that work for
> > everyone and let architectures override them (which AFAICT Christoph's
> > patch does) or we flat out #error if architectures don't specify
> > alignment requirements.
>
> Uh, isn't the latter precisely what I say above?
>
> > The current solution seems to be the worst one
> > from practical point of view.
>
> Good, because no one's advocating for it.
Sorry, I totally misunderstood what you wrote!
Pekka
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] slob: push the min alignment to long long
From: Pekka Enberg @ 2011-06-16 16:48 UTC (permalink / raw)
To: Christoph Lameter
Cc: Sebastian Andrzej Siewior, Matt Mackall, linux-mm,
David S. Miller, netfilter, Pekka Enberg
In-Reply-To: <alpine.DEB.2.00.1106141614480.10017@router.home>
On Wed, Jun 15, 2011 at 12:16 AM, Christoph Lameter <cl@linux.com> wrote:
> Maybe this would work too?
>
>
> Subject: slauob: Unify alignment definition
>
> Every slab has its on alignment definition in include/linux/sl?b_def.h. Extract those
> and define a common set in include/linux/slab.h.
>
> SLOB: As notes sometimes we need double word alignment on 32 bit. This gives all
> structures allocated by SLOB a unsigned long long alignment like the others do.
>
> SLAB: If ARCH_SLAB_MINALIGN is not set SLAB would set ARCH_SLAB_MINALIGN to
> zero meaning no alignment at all. Give it the default unsigned long long alignment.
>
> Signed-off-by: Christoph Lameter <cl@linux.com>
Applied, thanks!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [GIT PULL nf-2.6] IPVS
From: Simon Horman @ 2011-06-16 22:06 UTC (permalink / raw)
To: Patrick McHardy
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Wensong Zhang,
Julian Anastasov, Pablo Neira Ayuso
In-Reply-To: <4DFA1D0E.5070908@trash.net>
On Thu, Jun 16, 2011 at 05:11:10PM +0200, Patrick McHardy wrote:
> On 13.06.2011 10:47, Simon Horman wrote:
> > Hi Pablo,
> >
> > please consider pulling
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-2.6.git master
> > to get the following fix from Hans.
> >
> > I believe this change should be considered for -stable.
>
> Just send it to the stable people once it hits upstream. I'll
> send it to Dave tonight.
Understood, will do.
^ permalink raw reply
* how ulogd 2 works with conntrack
From: icukeng @ 2011-06-17 9:07 UTC (permalink / raw)
To: netfilter
I found in git code that ulogd use nfct_catch. As far as I understood
this function loops over the events until callback return
NFCT_CB_STOP. But in ulogd code there is only NFCT_CB_CONTINUE.
So how ulogd returns from nfct_catch loop? Or it isn't?
^ permalink raw reply
* pcap files reading with iptables
From: andrey @ 2011-06-17 14:44 UTC (permalink / raw)
To: netfilter
Hello,
I have tried to classify pcap files using layer7 userspace filter.
In order to do that I need to set a rule in iptables that QUEUE the
traffic.
Since iptables does not read pcap files, I have used tcpreplay to
replay the traffic form the pcap file.
tcpreplay is replaying the data from the pcap file on the interface
card.
I have checked with wireshark if the packets get through and they do.
My problem is that iptables seems to not receive the packets.
What could be the problem? Do the packets get dropped somewhere?
I do not have much knowledge in this field, please help me.
I am using:
Ubuntu 10.10 (Maverick)
Linux kernel 2.6.35-28-generic
iptables
iptables v1.4.4
Regards,
Andrey
^ permalink raw reply
* Re: pcap files reading with iptables
From: Jan Engelhardt @ 2011-06-17 15:31 UTC (permalink / raw)
To: andrey; +Cc: netfilter
In-Reply-To: <9ac1a49b24c19951f264d6bee409fef9@cs.dal.ca>
On Friday 2011-06-17 16:44, andrey wrote:
> Hello,
>
> I have tried to classify pcap files using layer7 userspace filter.
> In order to do that I need to set a rule in iptables that QUEUE the traffic.
> Since iptables does not read pcap files, I have used tcpreplay to replay the
> traffic form the pcap file.
> tcpreplay is replaying the data from the pcap file on the interface card.
> I have checked with wireshark if the packets get through and they do.
> My problem is that iptables seems to not receive the packets.
> What could be the problem? Do the packets get dropped somewhere?
AF_PACKET sockets bypass Netfilter. (Which is why, on the receive paths,
you still see packets with tcpdump despite having applied an iptables
filter.)
^ permalink raw reply
* Use ebtables to forward 802.1x frames ?
From: Nick Carter @ 2011-06-17 21:01 UTC (permalink / raw)
To: netfilter
Hi,
Its been suggested to me that ebtables can be used to forward 802.1x
frames. I need to do this to bridge a virtual machine supplicant to
an external authenticator switch. As far as I can see ebtables acts
as a frame filter. With this rule:
sudo ebtables -t filter -A INPUT -p 0x888E -i vnet0 -j ACCEPT --log
I get a match
Jun 17 19:48:47 mill kernel: [ 1271.665003] IN=vnet0 OUT= MAC source
= 52:54:00:e3:ec:01 MAC dest = 01:80:c2:00:00:03 proto = 0x888e
But the frame (skb) continues in the default manner and is returned
back from the bridge code, rather than being forwarded.
br_handle_frame()
...
if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
NULL, br_handle_local_finish))
return NULL; /* frame consumed by filter */
else {
return skb; /* continue processing */
}
}
forward:
Is it possible to use ebtables and override the kernels default
bridging behaviour and forward frames that would normally be dropped ?
Maybe grabbing the frame and reinjecting it elsewhere....
Thanks for any insight,
Nick
^ permalink raw reply
* Untagged Frames
From: Jonathan Tripathy @ 2011-06-17 21:06 UTC (permalink / raw)
To: netfilter
Hi Everyone,
Does ebtables have the facility to make sure that any frames entering a
bridge must be untagged (i.e. have no 802.1q tag)?
Thanks
^ permalink raw reply
* Re: Use ebtables to forward 802.1x frames ?
From: Jan Engelhardt @ 2011-06-18 7:19 UTC (permalink / raw)
To: Nick Carter; +Cc: netfilter
In-Reply-To: <BANLkTi=eN=K9RMbBh4QQpZD4CO6uWBNBWg@mail.gmail.com>
On Friday 2011-06-17 23:01, Nick Carter wrote:
>Hi,
>
>Its been suggested to me that ebtables can be used to forward 802.1x
>frames.
Nope, ebtables [ebtables.ko] can filter/change them. For mere bridging
activity, brctl [bridge.ko] is used, and forwarding is done by routing
[net/*/route.c].
>I need to do this to bridge a virtual machine supplicant to
>an external authenticator switch. As far as I can see ebtables acts
>as a frame filter. With this rule:
>sudo ebtables -t filter -A INPUT -p 0x888E -i vnet0 -j ACCEPT --log
As a filter yes, and you indicated to that command that you do not
want to discard the packet - which then so occurred.
>I get a match
>Jun 17 19:48:47 mill kernel: [ 1271.665003] IN=vnet0 OUT= MAC source
>= 52:54:00:e3:ec:01 MAC dest = 01:80:c2:00:00:03 proto = 0x888e
>But the frame (skb) continues in the default manner and is returned
>back from the bridge code, rather than being forwarded.
>br_handle_frame()
>...
> if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
> NULL, br_handle_local_finish))
> return NULL; /* frame consumed by filter */
> else {
> return skb; /* continue processing */
> }
> }
>forward:
The "..." part contains:
if (is_link_local(dest))
which checks whether dstmac is local - and if that is the case, ethernet
frames are not bridged, but delivered to the local L3 routing.
^ permalink raw reply
* Re: Untagged Frames
From: Pascal Hambourg @ 2011-06-18 8:29 UTC (permalink / raw)
To: Jonathan Tripathy; +Cc: netfilter
In-Reply-To: <4DFBC1CD.3000205@abpni.co.uk>
Hello,
Jonathan Tripathy a écrit :
>
> Does ebtables have the facility to make sure that any frames entering a
> bridge must be untagged (i.e. have no 802.1q tag)?
I guess that it can be done by matching the 802.1q ethertype 0x8100.
^ permalink raw reply
* Re: Untagged Frames
From: Pascal Hambourg @ 2011-06-18 9:12 UTC (permalink / raw)
To: Jonathan Tripathy; +Cc: netfilter
In-Reply-To: <46C13AA90DB8844DAB79680243857F0F0B005A@server1.ABPNI.local>
Jonathan Tripathy a écrit :
>>
>> Does ebtables have the facility to make sure that any frames entering a
>> bridge must be untagged (i.e. have no 802.1q tag)?
>
> I guess that it can be done by matching the 802.1q ethertype 0x8100.
>
> ------------------------------------------------------------------------------
>
> So I'm guessing if I only wanted to allow untagged frames going into my
> bridge, I could do:
>
> ebtables -I FORWARD -p ! 0x8100 -i <IF of port connected to bridge> -j
> ACCEPT
FORWARD = frames going through the bridge, not all frames entering it.
> Is that correct? I don't need to use physdev (like I do in iptables) or
> anything, do I?
-i in ebtables is the same as --physdev-in in iptables : both are used
to match the bridge port (physical interface). If you want to match the
logical bridge interface, use --logical-in in ebtables or -i in iptables.
PS : You should avoid sending HTML to the mailing list.
^ permalink raw reply
* Using interface name as a command line option to create a iptables rule
From: Adishesh M @ 2011-06-20 11:55 UTC (permalink / raw)
To: netfilter
Hi,
Is it mandatory (or recommended) to use interface as option to enable
a particular port using iptables filter table.
If we don뇺 use interface name while forming a rule, then are we
compromising anything with respect to security?
For example
We have two interfaces eth0 and eth1 with ip address as given below.
We want to enable ssh service on eth1 and some other service on eth2.
For this we are using below rules
Option 1:
iptables 됧 INPUT DROP
iptables -A INPUT -i eth0 -d 192.168.229.131 둃 tcp --dport 22 -j ACCEPT
iptables -A INPUT -i eth1 -d 192.168.124.135 -p udp --dport 5060 -j ACCEPT
iptables 되 INPUT 됡 DROP
Option 2:
Iptables 됧 INPUT DROP
Iptables 되 INPUT 둃 tcp --dport 22 -j ACCEPT
Iptables 되 INPUT -d 192.168.124.135 -p udp --dport 5060 -j ACCEPT
Iptables 되 INPUT 됡 DROP
In the above examples, which is more secure option?
[root@adim ~]# ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 1000
link/ether 00:0c:29:53:6a:e0 brd ff:ff:ff:ff:ff:ff
inet 192.168.229.131/24 brd 192.168.229.255 scope global eth0
inet6 fe80::20c:29ff:fe53:6ae0/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 1000
link/ether 00:0c:29:53:6a:f4 brd ff:ff:ff:ff:ff:ff
inet 192.168.124.135/24 brd 192.168.124.255 scope global eth1
inet6 fe80::20c:29ff:fe53:6af4/64 scope link
valid_lft forever preferred_lft forever
^ permalink raw reply
* Re: Using interface name as a command line option to create a iptables rule
From: Jan Engelhardt @ 2011-06-20 12:01 UTC (permalink / raw)
To: Adishesh M; +Cc: netfilter
In-Reply-To: <BANLkTi=A5NWc3YR2fZk7Q6tw-xJ_BAz2Ug@mail.gmail.com>
On Monday 2011-06-20 13:55, Adishesh M wrote:
>Hi,
>
>Is it mandatory (or recommended) to use interface as option to enable
>a particular port using iptables filter table.
>
>If we don’t use interface name while forming a rule, then are we
>compromising anything with respect to security?
They do different things, and hence there is no universal answer.
At times you want all packets of one given interface,
at other times, you want packets with one address on all interfaces.
The two sets certainly can be different (mathematically), so choose
wisely. Especially since addresses can occur on any interface.
^ permalink raw reply
* Re: Using interface name as a command line option to create a iptables rule
From: icukeng @ 2011-06-20 15:39 UTC (permalink / raw)
To: Adishesh M; +Cc: netfilter
In-Reply-To: <BANLkTi=A5NWc3YR2fZk7Q6tw-xJ_BAz2Ug@mail.gmail.com>
if ssh listens only on 192.168.229.131 at port 22 these rules are equivalent.
otherwise some user from another network (on another nic) can connect.
Another nuance is possibility of ip/arp spoofing - you can get
192.168.229.131 from eth1.
2011/6/20 Adishesh M <adisheshsm@gmail.com>:
> Hi,
>
> Is it mandatory (or recommended) to use interface as option to enable
> a particular port using iptables filter table.
>
> If we don’t use interface name while forming a rule, then are we
> compromising anything with respect to security?
>
>
> For example
>
> We have two interfaces eth0 and eth1 with ip address as given below.
> We want to enable ssh service on eth1 and some other service on eth2.
> For this we are using below rules
>
> Option 1:
> iptables –P INPUT DROP
> iptables -A INPUT -i eth0 -d 192.168.229.131 –p tcp --dport 22 -j ACCEPT
> iptables -A INPUT -i eth1 -d 192.168.124.135 -p udp --dport 5060 -j ACCEPT
> iptables –A INPUT –J DROP
>
> Option 2:
> Iptables –P INPUT DROP
> Iptables –A INPUT –p tcp --dport 22 -j ACCEPT
> Iptables –A INPUT -d 192.168.124.135 -p udp --dport 5060 -j ACCEPT
> Iptables –A INPUT –J DROP
>
> In the above examples, which is more secure option?
>
>
>
>
> [root@adim ~]# ip addr list
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UNKNOWN qlen 1000
> link/ether 00:0c:29:53:6a:e0 brd ff:ff:ff:ff:ff:ff
> inet 192.168.229.131/24 brd 192.168.229.255 scope global eth0
> inet6 fe80::20c:29ff:fe53:6ae0/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UNKNOWN qlen 1000
> link/ether 00:0c:29:53:6a:f4 brd ff:ff:ff:ff:ff:ff
> inet 192.168.124.135/24 brd 192.168.124.255 scope global eth1
> inet6 fe80::20c:29ff:fe53:6af4/64 scope link
> valid_lft forever preferred_lft forever
> --
> 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
>
^ permalink raw reply
* Re: Using interface name as a command line option to create a iptables rule
From: Jan Engelhardt @ 2011-06-20 16:09 UTC (permalink / raw)
To: icukeng@gmail.com; +Cc: Adishesh M, netfilter
In-Reply-To: <BANLkTimcN_Jw6zOuxeKTEFg8yVvjLqMh0A@mail.gmail.com>
On Monday 2011-06-20 17:39, icukeng@gmail.com wrote:
>if ssh listens only on 192.168.229.131 at port 22 these rules are equivalent.
>otherwise some user from another network (on another nic) can connect.
>
>Another nuance is possibility of ip/arp spoofing - you can get
>192.168.229.131 from eth1.
You can even get them without spoofing, by load-balancing, in which case
the rules are not equivalent either.
^ permalink raw reply
* ip6tables HL bug ?
From: Christian S. Perone @ 2011-06-20 18:47 UTC (permalink / raw)
To: netfilter
Does someone knows why is ip6tables showing this error:
# ip6tables -t mangle -A POSTROUTING -j HL --hl-inc 1
ip6tables v1.3.5: HL: increasing by 0?
If I use the hl-set with 2 as argument for instance:
# ip6tables -t mangle -A POSTROUTING -o eth0 -p icmpv6 --icmpv6-type
router-advertisement -j HL --hl-set 2
# ipt6tables -t mangle -L
(...)
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
HL ipv6-icmp anywhere anywhere
ipv6-icmp router-advertisement HL set to 0
See that the value read is always interpreted as "zero", in
libip6t_HL.c we have:
if (value == 0)
{
exit_error(PARAMETER_PROBLEM,"HL: increasing by 0?");
}
So the problem is only thrown when the value is zero, the question is,
why is ip6tables reading the argument as zero ?
Does someone knows if this is a known bug ?
Details:
Kernel 2.6.17, powerpc
ip6tables v1.3.5
Thank you !
--
"Forgive, O Lord, my little jokes on Thee, and I'll forgive Thy great
big joke on me."
http://pyevolve.sourceforge.net/wordpress/
^ permalink raw reply
* [PATCH] Remove redundant linux/version.h includes from net/
From: Jesper Juhl @ 2011-06-20 22:13 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, coreteam, netfilter, netfilter-devel,
linux-kernel, Dmitry Kozlov
It was suggested by "make versioncheck" that the follwing includes of
linux/version.h are redundant:
/home/jj/src/linux-2.6/net/caif/caif_dev.c: 14 linux/version.h not needed.
/home/jj/src/linux-2.6/net/caif/chnl_net.c: 10 linux/version.h not needed.
/home/jj/src/linux-2.6/net/ipv4/gre.c: 19 linux/version.h not needed.
/home/jj/src/linux-2.6/net/netfilter/ipset/ip_set_core.c: 20 linux/version.h not needed.
/home/jj/src/linux-2.6/net/netfilter/xt_set.c: 16 linux/version.h not needed.
and it seems that it is right.
Beyond manually inspecting the source files I also did a few build
tests with various configs to confirm that including the header in
those files is indeed not needed.
Here's a patch to remove the pointless includes.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
net/caif/caif_dev.c | 1 -
net/caif/chnl_net.c | 1 -
net/ipv4/gre.c | 1 -
net/netfilter/ipset/ip_set_core.c | 1 -
net/netfilter/xt_set.c | 1 -
5 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
index 682c0fe..7c2fa0a 100644
--- a/net/caif/caif_dev.c
+++ b/net/caif/caif_dev.c
@@ -11,7 +11,6 @@
#define pr_fmt(fmt) KBUILD_MODNAME ":%s(): " fmt, __func__
-#include <linux/version.h>
#include <linux/kernel.h>
#include <linux/if_arp.h>
#include <linux/net.h>
diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c
index adbb424..8237766 100644
--- a/net/caif/chnl_net.c
+++ b/net/caif/chnl_net.c
@@ -7,7 +7,6 @@
#define pr_fmt(fmt) KBUILD_MODNAME ":%s(): " fmt, __func__
-#include <linux/version.h>
#include <linux/fs.h>
#include <linux/init.h>
#include <linux/module.h>
diff --git a/net/ipv4/gre.c b/net/ipv4/gre.c
index c6933f2..9dbe108 100644
--- a/net/ipv4/gre.c
+++ b/net/ipv4/gre.c
@@ -16,7 +16,6 @@
#include <linux/skbuff.h>
#include <linux/in.h>
#include <linux/netdevice.h>
-#include <linux/version.h>
#include <linux/spinlock.h>
#include <net/protocol.h>
#include <net/gre.h>
diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c
index 42aa64b..40c9645 100644
--- a/net/netfilter/ipset/ip_set_core.c
+++ b/net/netfilter/ipset/ip_set_core.c
@@ -17,7 +17,6 @@
#include <linux/spinlock.h>
#include <linux/netlink.h>
#include <linux/rculist.h>
-#include <linux/version.h>
#include <net/netlink.h>
#include <linux/netfilter.h>
diff --git a/net/netfilter/xt_set.c b/net/netfilter/xt_set.c
index b3babae..5c23c44 100644
--- a/net/netfilter/xt_set.c
+++ b/net/netfilter/xt_set.c
@@ -13,7 +13,6 @@
#include <linux/module.h>
#include <linux/skbuff.h>
-#include <linux/version.h>
#include <linux/netfilter/x_tables.h>
#include <linux/netfilter/xt_set.h>
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* IPTables Filtering traffic before Natting HOW TO?
From: Auro Benas @ 2011-06-20 22:45 UTC (permalink / raw)
To: netfilter
Dear Readers,
I'm sorry to waste your time but I'm in death point of developing and
today is 12Th day that I passed more than 13 hours a day on reading
about IPTables and trying to make it work, i
started dream about PREROUTING and POSTROUTING and I'm almost fused.
I'm not an expert but I'm writing this message with hope that some one
will be so kind to reply and help me or at least indicate me the way.
- What am I trying to get?
I'm developing a DMZ with IPTable (from now on I'll refer as
IPGServer) that behind the IPGServer will be between 10 to 30 apache
servers witch will be connected to the Internet.
1 - I need AS FIRST OF ALL that the IPGServer do the job as IP BLACK
LIST filter.
2 - I need AS SECOND that IPGServer route ONLY the filtered and
allowed connections to the servers inside the DMZ.
3 - I need that the routing of the connections/request that was made
by visitors with 10 to 30 third level domains (example:
xx1.domain.com, xx2.domain.com, --- x30.domain.com)
are recognize, converted to the apropriate private IP (I don't use DNS
server as suggested to do that I found file HOSTS more clean and fast
as solution) and forwarded to the apache
destination server so xx1.domain.com --> 10.10.0.1 and so on.
- My Data Flow Logic (I omitted some fases as input, output, forward
in what follows):
Client - Internet (Request xx1.domain.com) -->
IPGServer-eth0 (Ex:62.10.30.30) -->
Filter Source IP (IF match black list DROP ELSE log connections and
forward to destination server) -->
IPGServer-eth1 (10.0.0.1)-->
PREROUTING -s xx1.domain.com DNAT --to 10.10.0.1 -->
Internal Netowrk/switch -->
Apache Web Server accept, process and send reply back to
IPGServer-eth1 (10.0.0.1) -->
POSTROUTING -s 10.10.0.1 --> SNAT xx1.domain.com -->
eth0 (Ex:62.10.30.30) -->
Internet (Request xx1.domain.com) -->
Final Client --|
- What have I accive till now?
Well I accived to make the DMZ working as it must do with all the
MASQUERADE stuff, PREROUTING, POSTORUTING, etc.
I found the HOSTS file to configure to avoid DNS server configuration
and network overuse.
My APACHE WEB Servers are contacted from the Internet and thay can
connect outside (Ex: sudo apt-get update - and so on).
DMZ is really nice stuff and it works GREAT!
- What is my problem than?
Well in the DATA FLOW of the IPTAbles:
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables
I see that the first table that is "touched" by the incoming packet is
the PREROUTING and I you can believe me it works precisely in this
way, I tested and retested this tenths of
times
So I conclude that PREROUTING is my MAIN problem!!!!!
Why??
Well How do I filter witch IPs are allowed and witch no to pass inside
the private network if PREROUTING exlude my FILTER table?
Why I need PREROUTING?
I'll not teaching you nothing new but I need it to NAT the third level
domains and redirect tham to the defined APACHE WEB server that stay
in the private network.
I'm unable to do this.
I readed and re readed the HOWTO guides that I found on netfilter.org as:
http://netfilter.org/documentation/HOWTO//NAT-HOWTO.txt
Mylast hope before contacting you guys was the point 9 ( 9. Mixing NAT
and Packet Filtering) in this guide:
http://netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.txt
but I'm sorry I surrender I really don't understand how that works.
I hope to get a reply to solve my problem because I'm really don't
know what I'm doing wrong or what I'm not doing.
Thank you in advance for any suggestion or solution related to my problem.
Best regards,
Auro B.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox