Changli Gao | 1 Dec 02:26 2009
Picon

Re: Add seperated timeout for the connections that only receive packets in one direction

On Mon, Nov 30, 2009 at 7:10 PM, Patrick McHardy <kaber <at> trash.net> wrote:
> Changli Gao wrote:
>> Case 2:
>>
>> Attacker ---+
>>                 +-- Linux Router --> WAN
>> Victim-------+
>>
>> If we do sth. like RPF before entering conntrack, the packets in the
>> other direction won't be in.
>
> RPF doesn't help since its also done after conntrack.
>

I didn't mean RPF. I meaned some other thing like RPF before conntrack.

--

-- 
Regards,
Changli Gao(xiaosuo <at> gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jozsef Kadlecsik | 1 Dec 10:14 2009
Picon

Re: Add seperated timeout for the connections that only receive packets in one direction

On Mon, 30 Nov 2009, Changli Gao wrote:

> Think about this topologic:
> 
> Attacker -> router1 -> router2 -> ... -> Linux Router -> Apache.
> 
> the packets in the other direction won't be sent to the Linux Router,
> as the other routers will routed them to the other place.

Sorry, I don't get it. 

If the attacker forges the source IP of the packet so that Apache thinks 
it's a local machine from its own point of view and answers it on the LAN, 
then that's the fault of the Linux Router operator: ingress and egress 
filtering is a must, period.

If the attacker forges the source IP of the packet otherwise so that 
Apache thinks it's a non local machine, then Apache will send the answer 
via the Linux Router regardless of the routing table of any router out 
there.

> Case 2:
> 
> Attacker ---+
>                 +-- Linux Router --> WAN
> Victim-------+
> 
> If we do sth. like RPF before entering conntrack, the packets in the
> other direction won't be in.

(Continue reading)

Changli Gao | 1 Dec 10:29 2009
Picon

Re: Add seperated timeout for the connections that only receive packets in one direction

On Tue, Dec 1, 2009 at 5:14 PM, Jozsef Kadlecsik
<kadlec <at> blackhole.kfki.hu> wrote:
> On Mon, 30 Nov 2009, Changli Gao wrote:
>
>> Think about this topologic:
>>
>> Attacker -> router1 -> router2 -> ... -> Linux Router -> Apache.
>>
>> the packets in the other direction won't be sent to the Linux Router,
>> as the other routers will routed them to the other place.
>
> Sorry, I don't get it.

There is a assumption: the final receiver doesn't reply any packet for
this packet in the invalid state.

--

-- 
Regards,
Changli Gao(xiaosuo <at> gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jozsef Kadlecsik | 1 Dec 10:45 2009
Picon

Re: Add seperated timeout for the connections that only receive packets in one direction

On Tue, 1 Dec 2009, Changli Gao wrote:

> On Tue, Dec 1, 2009 at 5:14 PM, Jozsef Kadlecsik
> <kadlec <at> blackhole.kfki.hu> wrote:
> > On Mon, 30 Nov 2009, Changli Gao wrote:
> >
> >> Think about this topologic:
> >>
> >> Attacker -> router1 -> router2 -> ... -> Linux Router -> Apache.
> >>
> >> the packets in the other direction won't be sent to the Linux Router,
> >> as the other routers will routed them to the other place.
> >
> > Sorry, I don't get it.
> 
> There is a assumption: the final receiver doesn't reply any packet for
> this packet in the invalid state.

Who's assumption? Mine? Yours? For which case did you answer this?

Please describe a complete example, not bits here and there and leaving 
out conditions.

Best regards,
Jozsef
-
E-mail  : kadlec <at> blackhole.kfki.hu, kadlec <at> mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary
(Continue reading)

Patrick McHardy | 1 Dec 11:05 2009
Picon

Re: [PATCH] Add refcounts to LED target

Jan Engelhardt wrote:
> On Sunday 2009-11-29 12:33, Adam Nielsen wrote:
> 
>>>> static bool led_tg_check(const struct xt_tgchk_param *par)
>>>> {
>>>> 	struct xt_led_info *ledinfo = par->targinfo;
>>>> -	struct xt_led_info_internal *ledinternal;
>>>> +	struct xt_led_info_internal *ledinternal = ledinfo->internal_data;
>>>> 	int err;
>>> You cannot rely on ledinfo->internal_data having any meaningful
>>> value when iptables prepares the rule.
>> Hmm ok, so in led_tg_check (the .checkentry function) how do you tell whether
>> the xt_tgchk_param is pointing to an existing ruleset or not?  Or is it always
>> referring to a new ruleset and you have to handle it yourself?
> 
> You always have to do a lookup on some structure that has xt_LED.ko 
> lifetime (similar to what xt_recent/xt_rateest does).
> 
>> I guess my question comes from this point of view:
>>
>>  $ iptables -A scroll_lock -j LED --led-trigger-id http
>>
>> This calls led_tg_check() with a new xt_tgchk_param structure.
>>
>>  $ iptables -I INPUT 1 -p tcp --sport 80 -j scroll_lock
>>
>> Now led_tg_check() gets called again with an xt_tgchk_param structure
>> containing the trigger name etc. even though this was not specified on the
>> command line.  Where does that second xt_tgchk_param come from if it's not a
>> pointer to the first one?
(Continue reading)

Fred Leeflang | 1 Dec 11:44 2009

nflog_bind_group() question

Hi devs,

We've recently implemented NFLOG support in vuurmuur, I've written an
article on the effort here
http://wordpress.3dn.nl/2009/11/25/iptabes-nflog-support-in-vuurmuur/

I'm curious about something I found out in the process. I've had
ulogd2 running alongside vuurmuur for a while and configured it to
listen to a specific nflog-group. When I had ulogd2 running I would
not be able to run vuurmuur_log which also listens to an nflog-group.
It took me a while to realize that it would not work because of having
ulogd2 running and both trying to listen to the SAME nflog-group.

Does this mean that it's not possible for two applications at the same
time to get netfilter_log messages from the same nflog-group?

-Fred
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patrick McHardy | 1 Dec 11:49 2009
Picon

Re: nflog_bind_group() question

Fred Leeflang wrote:
> Hi devs,
> 
> We've recently implemented NFLOG support in vuurmuur, I've written an
> article on the effort here
> http://wordpress.3dn.nl/2009/11/25/iptabes-nflog-support-in-vuurmuur/
> 
> I'm curious about something I found out in the process. I've had
> ulogd2 running alongside vuurmuur for a while and configured it to
> listen to a specific nflog-group. When I had ulogd2 running I would
> not be able to run vuurmuur_log which also listens to an nflog-group.
> It took me a while to realize that it would not work because of having
> ulogd2 running and both trying to listen to the SAME nflog-group.
> 
> Does this mean that it's not possible for two applications at the same
> time to get netfilter_log messages from the same nflog-group?

That is correct, nfnetlink_log uses unicast messages to the process
bound to the group. I'd also prefer if we had used multicast messaging,
but that can't be easily changed now.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

dansirbu101 | 2 Dec 23:06 2009
Picon

postrouting - it fails after change pkt via libipq

Hi,

    I have wrote a program to handle some IP packets using libipq (linux 2.6.10 / iptables 1.3.3).
    So I setup the NAT table with :

iptables -t nat -I PREROUTING -p sctp -j QUEUE
iptables -t nat -I POSTROUTING -p sctp -j QUEUE

    The incoming packet go OK through my user space program and have the DST address changed to get
forwarded to the server location. Now the server replies back, the rsp packet arrives within the
POSTROUTING rule and gets sent by the kernel to my userspace program.
     Userspace program applies the required changes - meaning it changes the SRC address and
sends it back to the kernel. The ip_set_verdict response > 0 => which means success.
     So far so good.

     The problem is that the mangled packet does not come out ..... (tcpdump does not capture it neither
on the local machine neither on the receiver machine) ! 
     So to me is like the kernel is "dropping" the packet ......

      Any idea how can I debug this ?!?
      I have no option to upgrade to a latest linux kernel - unfortunately. 

BR,
Dan S.

      __________________________________________________________________
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Wiktor Kolodziej | 3 Dec 11:54 2009
Picon

[xtables-addons] extensions in a non-modular kernel

Hello,

Is there any easy way to compile extensions into a non-modular kernel?

I've found in Jan's "An Introduction to Xtables-addons" that this is
possible, but can you please give me some more info how to do it?
What do you mean by "editing some kernel Makefile to descend into
xtables-addons/extensions" ?

Wiktor
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patrick McHardy | 3 Dec 21:19 2009
Picon

netfilter 00/08: Netfilter Update

Hi Dave,

following is a small netfilter update for 2.6.32, containing:

- various cleanups by Changli Gao, Hannes Eder and Joe Perches

- a patch from Pablo to improve TCP window tracking behaviour
  when connection tracking is out-of-sync with the connection
  endpoints.

- INPUT chain support for the xt_socket match

- a fix for dumping the revision 1 data of the conntrack match
  by Florian Westphal.

- Removal of some unnecessary code by myself and Eric

Please apply or pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git master

Thanks!

 include/linux/netfilter/nf_conntrack_tcp.h     |    3 +
 net/ipv4/netfilter/arp_tables.c                |   22 ++++----
 net/ipv4/netfilter/ip_queue.c                  |    5 +-
 net/ipv4/netfilter/ip_tables.c                 |   46 +++++++++---------
 net/ipv4/netfilter/ipt_CLUSTERIP.c             |   20 ++++----
 net/ipv4/netfilter/ipt_ECN.c                   |    8 ++--
 net/ipv4/netfilter/ipt_LOG.c                   |   22 ++++----
(Continue reading)


Gmane