return

return

[Peter Marshall]

I was just wondering if anyone here uses "return" in their rules .. I
understand what it is for .. just wondering if it is efficient to use.

ex.

-A Forward -s 192.168.200.5 -o eth1 -j subchain1
-A Forward -s 192.168.200.0/24 -o eth1 -j subchain2

-A subchain1 -d 200.200.200.200 --dport 1234 -j ACCEPT
-A subchain1 -d 200.200.300.300 --dport 4321 -j ACCEPT
-A subchain1 -j RETURN

-A subchain2 .......... blah blah blah ....

Or would you just write the rules different ?

Also, I was wondering is there a way to specify multiple source ip address ?

ex -s 192.168.200.5, 192.168.200.20 .....

Thank you,
Peter.


Peter Marshall, BCS
Network Administrator, CARIS
115 Waggoners Lane, Fredericton NB, E3B 2L4 CANADA
Phone:  (506) 458-8533 (Reception)

RE: return

[Piszcz, Justin Michael]

I do after reading this message:

Now that I've got ipt_recent installed and running, I'd be grateful for
comments or rule samples that could work best to ameliorate syn-floods.
(The site I'm working on has been the target of moderate-to-large-sized
syn-floods for a few months now, ongoing.)

I've been using this approach:

-N syn-flood
-A syn-flood -m limit --limit 6/s --limit-burst 10 -j RETURN
-A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
-A syn-flood -j DROP

-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -i eth0 -p tcp --syn -j syn-flood

...and, on the high-traffic site involved, have had occasions when the
machine became unreachable, the server load too high.

Someone suggested ipt_recent could handle this matter more accurately. 
I found a rule on the web that someone was using, and tried that a few
minutes ago, with this approach:

-N syn-flood
-A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
-A syn-flood -j DROP

-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -i eth0 -p tcp --syn -m recent --hitcount 10 --update \
   --seconds 60 -j syn-flood

...but very soon _no one_ could get a server connection, with that.

My 'mental model' of how ipt_recent is working must not be correct --
at least, I don't understand why the '--limit' ruleset seems to allow
normal traffic under most conditions but the '-m recent' rule kept
normal users from getting in, just a few minutes ago.

If anyone knows what I'm missing in my understanding of this, or has a
ruleset that works well to ameliorate syn-flooding, please let me know.

Thanks kindly,

-- 

 -- Jeff --   <http://www.wellnow.com>

 "There's nothing left in the world to prove.  All that's worth doing
  is to love one another, using whatever means are available to serve."



-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Peter Marshall
Sent: Friday, June 04, 2004 9:39 AM
To: netfilter
Subject: return

I was just wondering if anyone here uses "return" in their rules .. I
understand what it is for .. just wondering if it is efficient to use.

ex.

-A Forward -s 192.168.200.5 -o eth1 -j subchain1
-A Forward -s 192.168.200.0/24 -o eth1 -j subchain2

-A subchain1 -d 200.200.200.200 --dport 1234 -j ACCEPT
-A subchain1 -d 200.200.300.300 --dport 4321 -j ACCEPT
-A subchain1 -j RETURN

-A subchain2 .......... blah blah blah ....

Or would you just write the rules different ?

Also, I was wondering is there a way to specify multiple source ip
address ?

ex -s 192.168.200.5, 192.168.200.20 .....

Thank you,
Peter.


Peter Marshall, BCS
Network Administrator, CARIS
115 Waggoners Lane, Fredericton NB, E3B 2L4 CANADA
Phone:  (506) 458-8533 (Reception)

Re: return

[Frank Gruellich]

* Peter Marshall <peter.marshall@caris.com>  4. Jun 04:
> I was just wondering if anyone here uses "return" in their rules ..

Not really, but I know when I should use it.

> -A Forward -s 192.168.200.5 -o eth1 -j subchain1
> -A Forward -s 192.168.200.0/24 -o eth1 -j subchain2
> 
> -A subchain1 -d 200.200.200.200 --dport 1234 -j ACCEPT

BTW: this rule will not work.  --dport without -p is not valid.

> -A subchain1 -d 200.200.300.300 --dport 4321 -j ACCEPT
> -A subchain1 -j RETURN

Well, if this is the last rule in subchain1 it is useless, as RETURN is
something like the default polycy of userdefined chain.  If you want to
apply a large ruleset to a whole subnet expect a couple of host (e.g.
cause you don't like them) you could do something like:

$IPT -N subchain1
# not for the bad hosts
$IPT -A subchain1 -j RETURN    -s 192.168.0.23
$IPT -A subchain1 -j RETURN    -s 192.168.0.55
$IPT -A subchain1 -j ACCEPT    -p tcp --dport 4662
# lot more $IPT -A subchain1 ...
$IPT -A FORWARD   -j subchain1 -s 192.168.0.0/24
$IPT -A FORWARD   -j ACCEPT    -p tcp --dport 80

> Also, I was wondering is there a way to specify multiple source ip address ?
> ex -s 192.168.200.5, 192.168.200.20 .....

Not with unpatched iptables.  Use two rules or search the pom.

HTH,
 regards, Frank.
-- 
Sigmentation fault

Re: return

[Peter Marshall]

I don't mean to sound rude .. but your response ( as far as I can tell ..
and I apologize if I am missing something) has nothing to do with my
question .. at all ...

Peter

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "Peter Marshall" <peter.marshall@caris.com>; "netfilter"
<netfilter@lists.netfilter.org>
Sent: Friday, June 04, 2004 10:49 AM
Subject: RE: return


I do after reading this message:

Now that I've got ipt_recent installed and running, I'd be grateful for
comments or rule samples that could work best to ameliorate syn-floods.
(The site I'm working on has been the target of moderate-to-large-sized
syn-floods for a few months now, ongoing.)

I've been using this approach:

-N syn-flood
-A syn-flood -m limit --limit 6/s --limit-burst 10 -j RETURN
-A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
-A syn-flood -j DROP

-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -i eth0 -p tcp --syn -j syn-flood

...and, on the high-traffic site involved, have had occasions when the
machine became unreachable, the server load too high.

Someone suggested ipt_recent could handle this matter more accurately.
I found a rule on the web that someone was using, and tried that a few
minutes ago, with this approach:

-N syn-flood
-A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
-A syn-flood -j DROP

-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -i eth0 -p tcp --syn -m recent --hitcount 10 --update \
   --seconds 60 -j syn-flood

...but very soon _no one_ could get a server connection, with that.

My 'mental model' of how ipt_recent is working must not be correct --
at least, I don't understand why the '--limit' ruleset seems to allow
normal traffic under most conditions but the '-m recent' rule kept
normal users from getting in, just a few minutes ago.

If anyone knows what I'm missing in my understanding of this, or has a
ruleset that works well to ameliorate syn-flooding, please let me know.

Thanks kindly,

-- 

 -- Jeff --   <http://www.wellnow.com>

 "There's nothing left in the world to prove.  All that's worth doing
  is to love one another, using whatever means are available to serve."



-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Peter Marshall
Sent: Friday, June 04, 2004 9:39 AM
To: netfilter
Subject: return

I was just wondering if anyone here uses "return" in their rules .. I
understand what it is for .. just wondering if it is efficient to use.

ex.

-A Forward -s 192.168.200.5 -o eth1 -j subchain1
-A Forward -s 192.168.200.0/24 -o eth1 -j subchain2

-A subchain1 -d 200.200.200.200 --dport 1234 -j ACCEPT
-A subchain1 -d 200.200.300.300 --dport 4321 -j ACCEPT
-A subchain1 -j RETURN

-A subchain2 .......... blah blah blah ....

Or would you just write the rules different ?

Also, I was wondering is there a way to specify multiple source ip
address ?

ex -s 192.168.200.5, 192.168.200.20 .....

Thank you,
Peter.


Peter Marshall, BCS
Network Administrator, CARIS
115 Waggoners Lane, Fredericton NB, E3B 2L4 CANADA
Phone:  (506) 458-8533 (Reception)

RE: return

[Piszcz, Justin Michael]

The first time I used RETURN was today.

-A syn-flood -m limit --limit 6/s --limit-burst 10 -j RETURN

As I pasted in the message below, as it is useful in these situations in
which you need to limit packets per second.


-----Original Message-----
From: Peter Marshall [mailto:peter.marshall@caris.com] 
Sent: Friday, June 04, 2004 10:02 AM
To: Piszcz, Justin Michael; netfilter
Subject: Re: return

I don't mean to sound rude .. but your response ( as far as I can tell
..
and I apologize if I am missing something) has nothing to do with my
question .. at all ...

Peter

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "Peter Marshall" <peter.marshall@caris.com>; "netfilter"
<netfilter@lists.netfilter.org>
Sent: Friday, June 04, 2004 10:49 AM
Subject: RE: return


I do after reading this message:

Now that I've got ipt_recent installed and running, I'd be grateful for
comments or rule samples that could work best to ameliorate syn-floods.
(The site I'm working on has been the target of moderate-to-large-sized
syn-floods for a few months now, ongoing.)

I've been using this approach:

-N syn-flood
-A syn-flood -m limit --limit 6/s --limit-burst 10 -j RETURN
-A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
-A syn-flood -j DROP

-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -i eth0 -p tcp --syn -j syn-flood

...and, on the high-traffic site involved, have had occasions when the
machine became unreachable, the server load too high.

Someone suggested ipt_recent could handle this matter more accurately.
I found a rule on the web that someone was using, and tried that a few
minutes ago, with this approach:

-N syn-flood
-A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
-A syn-flood -j DROP

-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -i eth0 -p tcp --syn -m recent --hitcount 10 --update \
   --seconds 60 -j syn-flood

...but very soon _no one_ could get a server connection, with that.

My 'mental model' of how ipt_recent is working must not be correct --
at least, I don't understand why the '--limit' ruleset seems to allow
normal traffic under most conditions but the '-m recent' rule kept
normal users from getting in, just a few minutes ago.

If anyone knows what I'm missing in my understanding of this, or has a
ruleset that works well to ameliorate syn-flooding, please let me know.

Thanks kindly,

-- 

 -- Jeff --   <http://www.wellnow.com>

 "There's nothing left in the world to prove.  All that's worth doing
  is to love one another, using whatever means are available to serve."



-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Peter Marshall
Sent: Friday, June 04, 2004 9:39 AM
To: netfilter
Subject: return

I was just wondering if anyone here uses "return" in their rules .. I
understand what it is for .. just wondering if it is efficient to use.

ex.

-A Forward -s 192.168.200.5 -o eth1 -j subchain1
-A Forward -s 192.168.200.0/24 -o eth1 -j subchain2

-A subchain1 -d 200.200.200.200 --dport 1234 -j ACCEPT
-A subchain1 -d 200.200.300.300 --dport 4321 -j ACCEPT
-A subchain1 -j RETURN

-A subchain2 .......... blah blah blah ....

Or would you just write the rules different ?

Also, I was wondering is there a way to specify multiple source ip
address ?

ex -s 192.168.200.5, 192.168.200.20 .....

Thank you,
Peter.


Peter Marshall, BCS
Network Administrator, CARIS
115 Waggoners Lane, Fredericton NB, E3B 2L4 CANADA
Phone:  (506) 458-8533 (Reception)

Re: return

[Peter Marshall]

oops .. that was a typo ... (the missing -p tcp) ...

However, assuming that was there ....
I thought the return uses the default policy if and only if it was attached
to either input, forward, or output chains ....
my understanding of it for other chains, is that it would just "return" the
chain it came from ....

so in my case, if nothing was matched at the end of subchain1, then it would
just jump back to the chain that called it (forwared), and continue parseing
the rules .....

So ... if this is trued (and if it is not, please let me know), is this an
efficiant way to do this ... if it is not, then let me know.

My problem is, there are some useres who require nats to other companies ...
somtimes a couple of users require the same rule set .... so assuming that
my nat tables are correct ( i did not include them), I wanted to do the
following.

-A Forward -s 192.168.200.5 -o eth1 -j subchain1
-A Forward -s 192.168.200.6 -o eth1 -j subchain1
-A Forward -s 192.168.200.0/24 -o eth1 -j subchain2

-A subchain1 -d 200.200.200.200 --dport 1234 -j ACCEPT
-A subchain1 -d 200.200.300.300 --dport 4321 -j ACCEPT
-A subchain1 -j RETURN

-A subchain2 .......... blah blah blah ....

If I did a "Reject" or "Drop" at the end of subchain1, then the 200.5 and
200.6 users would never get to subchain2 (they would drop into subchain1
because it matches their source ...)

Thank you again for the help.

Peter

----- Original Message ----- 
From: "Frank Gruellich" <frank@home.manuelm.org>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Friday, June 04, 2004 10:58 AM
Subject: Re: return


* Peter Marshall <peter.marshall@caris.com>  4. Jun 04:
> I was just wondering if anyone here uses "return" in their rules ..

Not really, but I know when I should use it.

> -A Forward -s 192.168.200.5 -o eth1 -j subchain1
> -A Forward -s 192.168.200.0/24 -o eth1 -j subchain2
>
> -A subchain1 -d 200.200.200.200 --dport 1234 -j ACCEPT

BTW: this rule will not work.  --dport without -p is not valid.

> -A subchain1 -d 200.200.300.300 --dport 4321 -j ACCEPT
> -A subchain1 -j RETURN

Well, if this is the last rule in subchain1 it is useless, as RETURN is
something like the default polycy of userdefined chain.  If you want to
apply a large ruleset to a whole subnet expect a couple of host (e.g.
cause you don't like them) you could do something like:

$IPT -N subchain1
# not for the bad hosts
$IPT -A subchain1 -j RETURN    -s 192.168.0.23
$IPT -A subchain1 -j RETURN    -s 192.168.0.55
$IPT -A subchain1 -j ACCEPT    -p tcp --dport 4662
# lot more $IPT -A subchain1 ...
$IPT -A FORWARD   -j subchain1 -s 192.168.0.0/24
$IPT -A FORWARD   -j ACCEPT    -p tcp --dport 80

> Also, I was wondering is there a way to specify multiple source ip address
?
> ex -s 192.168.200.5, 192.168.200.20 .....

Not with unpatched iptables.  Use two rules or search the pom.

HTH,
 regards, Frank.
-- 
Sigmentation fault

Re: return

[Peter Marshall]

Oh, I see ....
But would that not just return you to the parent chain of syn-flood ????

Thank you for the reply
Peter

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "Peter Marshall" <peter.marshall@caris.com>; "netfilter"
<netfilter@lists.netfilter.org>
Sent: Friday, June 04, 2004 11:14 AM
Subject: RE: return


The first time I used RETURN was today.

-A syn-flood -m limit --limit 6/s --limit-burst 10 -j RETURN

As I pasted in the message below, as it is useful in these situations in
which you need to limit packets per second.


-----Original Message-----
From: Peter Marshall [mailto:peter.marshall@caris.com]
Sent: Friday, June 04, 2004 10:02 AM
To: Piszcz, Justin Michael; netfilter
Subject: Re: return

I don't mean to sound rude .. but your response ( as far as I can tell
..
and I apologize if I am missing something) has nothing to do with my
question .. at all ...

Peter

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "Peter Marshall" <peter.marshall@caris.com>; "netfilter"
<netfilter@lists.netfilter.org>
Sent: Friday, June 04, 2004 10:49 AM
Subject: RE: return


I do after reading this message:

Now that I've got ipt_recent installed and running, I'd be grateful for
comments or rule samples that could work best to ameliorate syn-floods.
(The site I'm working on has been the target of moderate-to-large-sized
syn-floods for a few months now, ongoing.)

I've been using this approach:

-N syn-flood
-A syn-flood -m limit --limit 6/s --limit-burst 10 -j RETURN
-A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
-A syn-flood -j DROP

-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -i eth0 -p tcp --syn -j syn-flood

...and, on the high-traffic site involved, have had occasions when the
machine became unreachable, the server load too high.

Someone suggested ipt_recent could handle this matter more accurately.
I found a rule on the web that someone was using, and tried that a few
minutes ago, with this approach:

-N syn-flood
-A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
-A syn-flood -j DROP

-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -i eth0 -p tcp --syn -m recent --hitcount 10 --update \
   --seconds 60 -j syn-flood

...but very soon _no one_ could get a server connection, with that.

My 'mental model' of how ipt_recent is working must not be correct --
at least, I don't understand why the '--limit' ruleset seems to allow
normal traffic under most conditions but the '-m recent' rule kept
normal users from getting in, just a few minutes ago.

If anyone knows what I'm missing in my understanding of this, or has a
ruleset that works well to ameliorate syn-flooding, please let me know.

Thanks kindly,

-- 

 -- Jeff --   <http://www.wellnow.com>

 "There's nothing left in the world to prove.  All that's worth doing
  is to love one another, using whatever means are available to serve."



-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Peter Marshall
Sent: Friday, June 04, 2004 9:39 AM
To: netfilter
Subject: return

I was just wondering if anyone here uses "return" in their rules .. I
understand what it is for .. just wondering if it is efficient to use.

ex.

-A Forward -s 192.168.200.5 -o eth1 -j subchain1
-A Forward -s 192.168.200.0/24 -o eth1 -j subchain2

-A subchain1 -d 200.200.200.200 --dport 1234 -j ACCEPT
-A subchain1 -d 200.200.300.300 --dport 4321 -j ACCEPT
-A subchain1 -j RETURN

-A subchain2 .......... blah blah blah ....

Or would you just write the rules different ?

Also, I was wondering is there a way to specify multiple source ip
address ?

ex -s 192.168.200.5, 192.168.200.20 .....

Thank you,
Peter.


Peter Marshall, BCS
Network Administrator, CARIS
115 Waggoners Lane, Fredericton NB, E3B 2L4 CANADA
Phone:  (506) 458-8533 (Reception)

RE: return

[Piszcz, Justin Michael]

I am not sure how it works, however I have tested these rules and they
_DO_ block the IP's that exceed their packets/second limit for specific
ports, etc.


-----Original Message-----
From: Peter Marshall [mailto:peter.marshall@caris.com] 
Sent: Friday, June 04, 2004 10:28 AM
To: Piszcz, Justin Michael; netfilter
Subject: Re: return

Oh, I see ....
But would that not just return you to the parent chain of syn-flood ????

Thank you for the reply
Peter

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "Peter Marshall" <peter.marshall@caris.com>; "netfilter"
<netfilter@lists.netfilter.org>
Sent: Friday, June 04, 2004 11:14 AM
Subject: RE: return


The first time I used RETURN was today.

-A syn-flood -m limit --limit 6/s --limit-burst 10 -j RETURN

As I pasted in the message below, as it is useful in these situations in
which you need to limit packets per second.


-----Original Message-----
From: Peter Marshall [mailto:peter.marshall@caris.com]
Sent: Friday, June 04, 2004 10:02 AM
To: Piszcz, Justin Michael; netfilter
Subject: Re: return

I don't mean to sound rude .. but your response ( as far as I can tell
..
and I apologize if I am missing something) has nothing to do with my
question .. at all ...

Peter

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "Peter Marshall" <peter.marshall@caris.com>; "netfilter"
<netfilter@lists.netfilter.org>
Sent: Friday, June 04, 2004 10:49 AM
Subject: RE: return


I do after reading this message:

Now that I've got ipt_recent installed and running, I'd be grateful for
comments or rule samples that could work best to ameliorate syn-floods.
(The site I'm working on has been the target of moderate-to-large-sized
syn-floods for a few months now, ongoing.)

I've been using this approach:

-N syn-flood
-A syn-flood -m limit --limit 6/s --limit-burst 10 -j RETURN
-A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
-A syn-flood -j DROP

-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -i eth0 -p tcp --syn -j syn-flood

...and, on the high-traffic site involved, have had occasions when the
machine became unreachable, the server load too high.

Someone suggested ipt_recent could handle this matter more accurately.
I found a rule on the web that someone was using, and tried that a few
minutes ago, with this approach:

-N syn-flood
-A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
-A syn-flood -j DROP

-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -i eth0 -p tcp --syn -m recent --hitcount 10 --update \
   --seconds 60 -j syn-flood

...but very soon _no one_ could get a server connection, with that.

My 'mental model' of how ipt_recent is working must not be correct --
at least, I don't understand why the '--limit' ruleset seems to allow
normal traffic under most conditions but the '-m recent' rule kept
normal users from getting in, just a few minutes ago.

If anyone knows what I'm missing in my understanding of this, or has a
ruleset that works well to ameliorate syn-flooding, please let me know.

Thanks kindly,

-- 

 -- Jeff --   <http://www.wellnow.com>

 "There's nothing left in the world to prove.  All that's worth doing
  is to love one another, using whatever means are available to serve."



-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Peter Marshall
Sent: Friday, June 04, 2004 9:39 AM
To: netfilter
Subject: return

I was just wondering if anyone here uses "return" in their rules .. I
understand what it is for .. just wondering if it is efficient to use.

ex.

-A Forward -s 192.168.200.5 -o eth1 -j subchain1
-A Forward -s 192.168.200.0/24 -o eth1 -j subchain2

-A subchain1 -d 200.200.200.200 --dport 1234 -j ACCEPT
-A subchain1 -d 200.200.300.300 --dport 4321 -j ACCEPT
-A subchain1 -j RETURN

-A subchain2 .......... blah blah blah ....

Or would you just write the rules different ?

Also, I was wondering is there a way to specify multiple source ip
address ?

ex -s 192.168.200.5, 192.168.200.20 .....

Thank you,
Peter.


Peter Marshall, BCS
Network Administrator, CARIS
115 Waggoners Lane, Fredericton NB, E3B 2L4 CANADA
Phone:  (506) 458-8533 (Reception)

RE: return

[Ludo Stellingwerff]

Hi,

These rules could give you a high machine load because you log every
package that exceeds your limit.

I think this would help:

> -N syn-flood
> -A syn-flood -m limit --limit 6/s --limit-burst 10 -j RETURN
  -A syn-flood -m limit --limit 1/s --limit-burst 1 -j DROP
> -A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
> -A syn-flood -j DROP
> 
> -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
> 
> -A INPUT -i eth0 -p tcp --syn -j syn-flood
> 
This would limit logging of syn-flood packages to 1 packet per second.

Greetings,
Ludo.

On Fri, 2004-06-04 at 15:49, Piszcz, Justin Michael wrote:
> I do after reading this message:
> 
> Now that I've got ipt_recent installed and running, I'd be grateful for
> comments or rule samples that could work best to ameliorate syn-floods.
> (The site I'm working on has been the target of moderate-to-large-sized
> syn-floods for a few months now, ongoing.)
> 
> I've been using this approach:
> 
> -N syn-flood
> -A syn-flood -m limit --limit 6/s --limit-burst 10 -j RETURN
> -A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
> -A syn-flood -j DROP
> 
> -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
> 
> -A INPUT -i eth0 -p tcp --syn -j syn-flood
> 
> ...and, on the high-traffic site involved, have had occasions when the
> machine became unreachable, the server load too high.
> 
> Someone suggested ipt_recent could handle this matter more accurately. 
> I found a rule on the web that someone was using, and tried that a few
> minutes ago, with this approach:
> 
> -N syn-flood
> -A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
> -A syn-flood -j DROP
> 
> -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
> 
> -A INPUT -i eth0 -p tcp --syn -m recent --hitcount 10 --update \
>    --seconds 60 -j syn-flood
> 
> ...but very soon _no one_ could get a server connection, with that.
> 
> My 'mental model' of how ipt_recent is working must not be correct --
> at least, I don't understand why the '--limit' ruleset seems to allow
> normal traffic under most conditions but the '-m recent' rule kept
> normal users from getting in, just a few minutes ago.
> 
> If anyone knows what I'm missing in my understanding of this, or has a
> ruleset that works well to ameliorate syn-flooding, please let me know.
> 
> Thanks kindly,

Re: return

[John A. Sullivan III]

On Fri, 2004-06-04 at 09:39, Peter Marshall wrote:
> I was just wondering if anyone here uses "return" in their rules .. I
> understand what it is for .. just wondering if it is efficient to use.
> 
> ex.
> 
> -A Forward -s 192.168.200.5 -o eth1 -j subchain1
> -A Forward -s 192.168.200.0/24 -o eth1 -j subchain2
> 
> -A subchain1 -d 200.200.200.200 --dport 1234 -j ACCEPT
> -A subchain1 -d 200.200.300.300 --dport 4321 -j ACCEPT
> -A subchain1 -j RETURN
> 
> -A subchain2 .......... blah blah blah ....
> 
> Or would you just write the rules different ?
> 
> Also, I was wondering is there a way to specify multiple source ip address ?
> 
> ex -s 192.168.200.5, 192.168.200.20 .....
<snip>
I use return all the time; it is great for handling exceptions
especially given that one cannot use multiple source or destination
addresses in rule.  For example, suppose that you had a rule you wanted
to apply to all of the 192.168.200.0/24 network except for 192.168.200.5
and 192.168.200.20.  You could use the iprange patch and break the
source into 192.168.200.1-4, 192.168.200.6-19 and 192.168.200.21-254, or
you could not patch at all and break the ranges into a multitude of
subnets to exclude those two addresses or you could do something like
the following:

iptables -N SpecialChain
iptables -A FORWARD -s 192.168.200.0/24 -j SpecialChain
iptables -A SpecialChain -j ACCEPT
iptables -I SpecialChain 1 -s 192.168.200.5 -j RETURN
iptables -I SpecialChain 1 -s 192.168.200.20 -j RETURN

For a real world example, one of the great advantages of the ISCS
project (http://iscs.sourceforge.net) for remote access is that we can
maintain extended user authentication across an entire VPN WAN.  In
other words, if a user authenticates to an ISCS PEP (Policy Enforcement
Point - gateway) in their home office and is granted iptables access
control rights based upon the fields of their X.509 cert, the user can
now be granted or denied access anywhere in the could in any office
based upon that same authentication.  They do not need to connect
directly to the PEP protecting the resources in a remote office nor do
they need to be assigned a locally assigned IP address and have
authentication in remote offices based upon their spoofable IP address. 
Their remote access if truly granted based upon their extended
authentication anywhere they go in the VPN WAN.  We do this with return
rules.

The PEP protecting the user has the responsibility for all
authentication anywhere on the VPN WAN (how we manage the rule set sized
required for this is another interesting story).  When the packet
arrives at the remote PEP from an ipsec interface, the PEP trusts that
the sending PEP authenticated it and thus simply allows it.  This would
create a gaping security hole if we did not except from this general
accept rule, all the networks which the remote PEP was responsible for
authenticating.  Thus we do something like:

iptables -N VPN_ALLOW
iptables -A FORWARD -i ipsec+ -j VPN_ALLOW
iptables -A FORWARD -j ACCESS_GROUPS
iptables -A VPN_ALLOW -j ACCEPT
iptables -I VPN_ALLOW -s 192.168.1.0/24 -j RETURN
iptables -I VPN_ALLOW -s 24.76.89.223 -j RETURN

This accepts all previously authenticated traffic but returns all
non-authenticated traffic to the authentication chain series.

So, yes, we use RETURN frequently and frequently because we cannot use
multiple source and destination addresses.  Good luck with it - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

Return

[Miguel Bolanos]

Greetings to all.

I'm pretty sorry for been away during the past weeks... months? I've
just been pretty busy trying to make a living. anyways... seems like i
finally have spare time again, so.. I'm "back"
best wishes

Mike

-- 
----------------------miguel bolanos, systems administrator, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
       -since 1995                             http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------

Re: return

[Erick Hanns Teppo]

Re:Hello,

I wanted to follow up on the funding request you shared with us
previously. If you haven't yet secured the necessary financing,
we would like to invite you to revisit our offer and explore how
we can collaborate to achieve your goals this year.

At Lex Capital Group, we are seeking to expand and establish our
business interests internationally, focusing on sectors such as
Oil and Gas, Construction, Real Estate, Tourism and Hospitality,
Stock Trading, Mining, Transportation, Healthcare, Communication
Services, Agriculture, Forestry, and Fishing. We are also open to
exploring other industries with strong potential for a solid
return on investment (ROI).

If you are seeking funding or partnership opportunities in any of
these sectors or have a viable business idea in another high-
potential industry, please let us know. We are eager to discuss
how we can support your vision and help bring it to life.

Let me know if you'd like MORE information to explore this
opportunity further. Our commitment remains steadfast in
supporting credible ventures that promise growth and mutual
success.

Looking forward to your response.

Best regards,
Erick Hanns Teppo
Group Investment Director
Lex Capital Group