filtering on the interface driver

Hi, Any one tried to set packet filtering on the ethernet interface
driver ?
what i'm trying to set the source address filtering not by netfilter,
just
on the ethernet interface drivers. thanks in advance.

Cheers.

(E-Mail Removed) wrote:
> Hi, Any one tried to set packet filtering on the ethernet interface
> driver ?
> what i'm trying to set the source address filtering not by netfilter,
> just
> on the ethernet interface drivers. thanks in advance.
>
> Cheers.
>

What are you attempting to achieve?

The filtering in the driver itself is not a
clean way to do the filtering.

You may have a look at ebtables, if the need
is to filter a bridged connection.

--

Tauno Voipio
tauno voipio (at) iki fi

On 10 13 , 5 30 , Tauno Voipio <tauno.voi...@INVALIDiki.fi> wrote:
> shetra...@gmail.com wrote:
> > Hi, Any one tried to set packet filtering on the ethernet interface
> > driver ?
> > what i'm trying to set the source address filtering not by netfilter,
> > just
> > on the ethernet interface drivers. thanks in advance.
>
> > Cheers.
>
> What are you attempting to achieve?
>
> The filtering in the driver itself is not a
> clean way to do the filtering.
>
> You may have a look at ebtables, if the need
> is to filter a bridged connection.
>
> --
>
> Tauno Voipio
> tauno voipio (at) iki fi

Here's my ideas

What i want to packet filtering on the ethernet interface levels is
that to prevent
the CPU usages from the UDP/ICMPs packet attcking. some of cases 100M
packet
processing cause the 20% more CPU usages, even if it has filter
address from the netfilter.

Cheers.

(E-Mail Removed) wrote:

> What i want to packet filtering on the ethernet interface levels
> is that to prevent the CPU usages from the UDP/ICMPs packet
> attcking. some of cases 100M packet processing cause the 20% more
> CPU usages, even if it has filter address from the netfilter.

Sounds as if you need to enable filtering by reverse path source
validation:

echo 1 > /proc/sys/net/ipv4/conf/ethX/rp_filter (X=whatever)
or
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

This is described in /usr/src/linux-2.6.18/net/ipv4/Kconfig
and in
rfc1812, 5.3.8 Source Address Validation

--
Clifford Kite

Hello,

Clifford Kite a écrit :
>
> Sounds as if you need to enable filtering by reverse path source
> validation:

I didn't understand this in the OP's request but the need for early
filtering in order to limit the CPU usage under heavy attack.

> echo 1 > /proc/sys/net/ipv4/conf/ethX/rp_filter (X=whatever)
> or
> echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

You mean "and" instead of "or". Documentation/networking/ip-sysctl.txt
says :

conf/all/rp_filter must also be set to TRUE to do source validation
on the interface

Yes, I know other kernel parameters work as a logical "or", this can be
confusing...

Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
> Hello,

> Clifford Kite a écrit :
>>
>> Sounds as if you need to enable filtering by reverse path source
>> validation:

> I didn't understand this in the OP's request but the need for early
> filtering in order to limit the CPU usage under heavy attack.

I don't know what "early filtering" means but being naive simply thought
that enabling rp_filter might be better than alternatives using netfilter.
Perhaps neither will work to limit CPU usage.

>> echo 1 > /proc/sys/net/ipv4/conf/ethX/rp_filter (X=whatever)
>> or
>> echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

> You mean "and" instead of "or". Documentation/networking/ip-sysctl.txt
> says :

> conf/all/rp_filter must also be set to TRUE to do source validation
> on the interface

Right, I misinterpreted this in net/ipv4/Kconfig:

To turn
rp_filter off use:

echo 0 > /proc/sys/net/ipv4/conf/<device>/rp_filter
or
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

Clearly, and belatedly , if entering 0 (FALSE) in either of these turns
rp_filter "off" then both must contain 1 (TRUE) in order for rp_filter
to be "on."

> Yes, I know other kernel parameters work as a logical "or", this can be
> confusing...

Or not...

--
Clifford Kite

Clifford Kite a écrit :
> Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
>>Clifford Kite a écrit :
>>
>>>Sounds as if you need to enable filtering by reverse path source
>>>validation:
>
>>I didn't understand this in the OP's request but the need for early
>>filtering in order to limit the CPU usage under heavy attack.
>
> I don't know what "early filtering" means but being naive simply thought
> that enabling rp_filter might be better than alternatives using netfilter.

Unfortunately, I'm afraid that enabling rp_filter won't help against a
flooding attack from legitimate (rp_filter-wise) source addresses.

> Perhaps neither will work to limit CPU usage.

Maybe you're right. By "early filtering" I meant filtering as early as
possible before operations in Netfilter and the TCP/IP stack which I
believe are the most CPU consuming, such as connection tracking, routing
decision, packet reassembly... I guess this may be achieved by adding
iptables filtering rules in the PREROUTING chain of the 'raw' table,
even though it is not very clean.

> in net/ipv4/Kconfig:
>
> To turn rp_filter off use:
>
> echo 0 > /proc/sys/net/ipv4/conf/<device>/rp_filter
> or
> echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

By the way, I had never paid attention to the text just before :

If you turn on IP forwarding, you will also get the rp_filter, which
automatically rejects incoming packets if the routing table entry
for their source address doesn't match the network interface they're
arriving on.

Isn't this confusing in suggesting that enabling ip_forward
automatically enables rp_filter ? Documentation/networking/ip-sysctl.txt
says that rp_filter is disabled by default - regardless of ip_forward -
which is compliant with RFC 1812 § 5.3.8 which requires that source
address validation MUST be disabled by default. I checked on a 2.6.20
kernel that changing ip_forward has no effect on rp_filter.

(E-Mail Removed) wrote:
> On 10 13 , 5 30 , Tauno Voipio <tauno.voi...@INVALIDiki.fi> wrote:
>
>>shetra...@gmail.com wrote:
>>
>>>Hi, Any one tried to set packet filtering on the ethernet interface
>>>driver ?
>>>what i'm trying to set the source address filtering not by netfilter,
>>>just
>>>on the ethernet interface drivers. thanks in advance.
>>
>>>Cheers.
>>
>>What are you attempting to achieve?
>>
>>The filtering in the driver itself is not a
>>clean way to do the filtering.
>>
>>You may have a look at ebtables, if the need
>>is to filter a bridged connection.
>>
>>--
>>
>>Tauno Voipio
>>tauno voipio (at) iki fi
>
>
> Here's my ideas
>
> What i want to packet filtering on the ethernet interface levels is
> that to prevent
> the CPU usages from the UDP/ICMPs packet attcking. some of cases 100M
> packet
> processing cause the 20% more CPU usages, even if it has filter
> address from the netfilter.

If you want to filter according to the IP packet or
its payload (TCP, UDP etc), you're not winning anything
compared to the iptables filtering, as the payload
of the Ethernet packet (IP, ARP etc) needs to be
analyzed before filtering, and the iptables handling
is in the right places in the analyzing chain.

A different story is if the disturbing Ethernet frames
are some non-IP traffic. ebtables should help here without
the need to re-invent another wheel.

--

Tauno Voipio
tauno voipio (at) iki fi

On 10 15 , 2 02 , Tauno Voipio <tauno.voi...@INVALIDiki.fi> wrote:
> shetra...@gmail.com wrote:
> > On 10 13 , 5 30 , Tauno Voipio <tauno.voi...@INVALIDiki.fi> wrote:
>
> >>shetra...@gmail.com wrote:
>
> >>>Hi, Any one tried to set packet filtering on the ethernet interface
> >>>driver ?
> >>>what i'm trying to set the source address filtering not by netfilter,
> >>>just
> >>>on the ethernet interface drivers. thanks in advance.
>
> >>>Cheers.
>
> >>What are you attempting to achieve?
>
> >>The filtering in the driver itself is not a
> >>clean way to do the filtering.
>
> >>You may have a look at ebtables, if the need
> >>is to filter a bridged connection.
>
> >>--
>
> >>Tauno Voipio
> >>tauno voipio (at) iki fi
>
> > Here's my ideas
>
> > What i want to packet filtering on the ethernet interface levels is
> > that to prevent
> > the CPU usages from the UDP/ICMPs packet attcking. some of cases 100M
> > packet
> > processing cause the 20% more CPU usages, even if it has filter
> > address from the netfilter.
>
> If you want to filter according to the IP packet or
> its payload (TCP, UDP etc), you're not winning anything
> compared to the iptables filtering, as the payload
> of the Ethernet packet (IP, ARP etc) needs to be
> analyzed before filtering, and the iptables handling
> is in the right places in the analyzing chain.
>
> A different story is if the disturbing Ethernet frames
> are some non-IP traffic. ebtables should help here without
> the need to re-invent another wheel.
>
> --
>
> Tauno Voipio
> tauno voipio (at) iki fi- -
>
> - -

Thanks all members

yes, tried to set by the ebtables, the layer 2 filtering but i
wouldn't help.
the traditional packet filtering rule set like layer 3 and 7 consuming
the
CPU too lot, especially UDP/ICMP attacking. i guess, this wan't enough
to filtering by source address on the 2/7 layers. yes, layer 7 usually
concerning
the regular expression matters.

so, i'm looking for the more effective filtering method without using
hardware off-loading
method.

let it suppose the some of attacking schemas.

1. 50 valid ip address sending massive UDP packets the linux box with
100M bandwidth.
2. the linux box could droping the all packets from that source
address(with iptables/ebtables)
3. what it means that it still processing on the kernel
4. its CPU comsuming LOT!
5. and possible HANG.

anyhow thank you all members to concerning this stuffs.

Cheers

In article <1ZrQi.167$(E-Mail Removed)>, Tauno Voipio <(E-Mail Removed)> wrote:
>(E-Mail Removed) wrote:
>> On 10 13 , 5 30 , Tauno Voipio <tauno.voi...@INVALIDiki.fi> wrote:
>>
>>>shetra...@gmail.com wrote:
>>>
>>>>Hi, Any one tried to set packet filtering on the ethernet interface
>>>>driver ?
>>>>what i'm trying to set the source address filtering not by netfilter,
>>>>just
>>>>on the ethernet interface drivers. thanks in advance.
>>>
>>>>Cheers.
>>>
>>>What are you attempting to achieve?
>>>
>>>The filtering in the driver itself is not a
>>>clean way to do the filtering.

Well, but you have access closest to a wire
and can intercept everything that is going on,
regadless of anything else.

>>>You may have a look at ebtables, if the need
>>>is to filter a bridged connection.
>>>
>>>--
>>>
>>>Tauno Voipio
>>>tauno voipio (at) iki fi
>>
>>
>> Here's my ideas
>>
>> What i want to packet filtering on the ethernet interface levels is
>> that to prevent
>> the CPU usages from the UDP/ICMPs packet attcking. some of cases 100M
>> packet
>> processing cause the 20% more CPU usages, even if it has filter
>> address from the netfilter.
>
>If you want to filter according to the IP packet or
>its payload (TCP, UDP etc), you're not winning anything
>compared to the iptables filtering, as the payload
>of the Ethernet packet (IP, ARP etc) needs to be
>analyzed before filtering, and the iptables handling
>is in the right places in the analyzing chain.
>
>A different story is if the disturbing Ethernet frames
>are some non-IP traffic. ebtables should help here without
>the need to re-invent another wheel.
>

--
Get yourself the most powerful tool for usenet you ever heard of.

Version 4.0.1 Hail Democracy Release has been released.

Important feature additions and various improvements
and optimizations.

Web page:

http://newsmaestro.sourceforge.net/
or
http://tarkus01.by.ru/

NewsMaestro download page:

http://newsmaestro.sourceforge.net/D...nformation.htm