Shorewall devel - Feb 2004 - Error: Rate Limiting only available with ACCEPT, DNAT[-], REDIRECT[-] and LOG

I think it would be nice to be able to rate limit an action, too..

suppose I have an action named Accept_good_source :

ACCEPT - - tcp - 1024:65535
ACCEPT - - udp - 1024:65535

and that i want to use it in an action called AllowCVS,
i can''t limit the cvs usage, but only the general use of 
Accept_good_source...

same goes for userset...

as each rule will give one iptables command,
I believe there is no limitation ...

Is that right ?

I tried :

@@ -3086,8 +3090,8 @@
                fi
                ;;
            *)
-               [ -n "$ratelimit" ] && fatal_error \
-                   "Rate Limiting only available with ACCEPT, DNAT[-],
REDIRECT[-] and LOG"
+       #       [ -n "$ratelimit" ] && fatal_error \
+       #           "Rate Limiting only available with ACCEPT, DNAT[-],
REDIRECT[-] and LOG"
                ;;
        esac
     fi


and it seems to work at first look.

I guess commenting thoses 2 lines might harm something,
I don''t know what though... 

bye


-- 
xavier

On Friday 13 February 2004 02:52 pm, xavier wrote:
> I think it would be nice to be able to rate limit an action, too..
>
> suppose I have an action named Accept_good_source :
>
> ACCEPT - - tcp - 1024:65535
> ACCEPT - - udp - 1024:65535
>
> and that i want to use it in an action called AllowCVS,
> i can''t limit the cvs usage, but only the general use of
> Accept_good_source...
>
> same goes for userset...
>
> as each rule will give one iptables command,
> I believe there is no limitation ...
>
> Is that right ?
>
> I tried :
>
> @@ -3086,8 +3090,8 @@
>                 fi
>                 ;;
>             *)
> -               [ -n "$ratelimit" ] && fatal_error \
> -                   "Rate Limiting only available with ACCEPT,
DNAT[-],
> REDIRECT[-] and LOG" +       #       [ -n "$ratelimit" ]
&& fatal_error \
> +       #           "Rate Limiting only available with ACCEPT,
DNAT[-],
> REDIRECT[-] and LOG" ;;
>         esac
>      fi
>
>
> and it seems to work at first look.
>
> I guess commenting thoses 2 lines might harm something,
> I don''t know what though...
The reason that code is there is that I think rate limiting is absurd when 
used with DROP or REJECT. With the advent of actions, the code that you 
commented out isn''t quite right; see the 2.0.0 code by contrast...

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Fri, Feb 13, 2004 at 05:52:33PM -0500, xavier wrote:
|
|I think it would be nice to be able to rate limit an action, too..

[...]

|same goes for userset...


actually, no, --uid-owner can go only on OUTPUT chain.



-- 
xavier

On Sat, 14 Feb 2004, xavier wrote:
> On Fri, Feb 13, 2004 at 05:52:33PM -0500, xavier wrote:
> |
> |I think it would be nice to be able to rate limit an action, too..
>
> [...]
>
> |same goes for userset...
>
>
> actually, no, --uid-owner can go only on OUTPUT chain.
>
In 2.0, usersets can be used both in the invoking of an action and in the
body of the action itself.

-Tom
--
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Sat, 14 Feb 2004, Tom Eastep wrote:
> On Sat, 14 Feb 2004, xavier wrote:
>
> > On Fri, Feb 13, 2004 at 05:52:33PM -0500, xavier wrote:
> > |
> > |I think it would be nice to be able to rate limit an action, too..
> >
> > [...]
> >
> > |same goes for userset...
> >
> >
> > actually, no, --uid-owner can go only on OUTPUT chain.
> >
>
> In 2.0, usersets can be used both in the invoking of an action and in the
> body of the action itself.
>
Netfilter/iptables does the right thing for that:

[root@ursa 1.4]# iptables -N foo
[root@ursa 1.4]# iptables -A foo -m owner --uid-owner teastep -j ACCEPT
[root@ursa 1.4]# iptables -A OUTPUT -j foo
[root@ursa 1.4]# iptables -A FORWARD -j foo
iptables: Invalid argument
[root@ursa 1.4]#

-Tom
--
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

|The reason that code is there is that I think rate limiting is absurd when 
|used with DROP or REJECT. With the advent of actions, the code that you 
|commented out isn''t quite right; see the 2.0.0 code by contrast...

I agree saying that drop limiting is pointless,
however, I think there is a point limiting rejects.

rejects generate packets, load on the server as well as on the network,
and worse, it could be answers to spoofed packets. 
(so in this case we want to limit a potential dos to
an innocent which never sent anything)

consider the following iptables rules : 

iptables -A in_eth1 -p tcp          --dport 3128 -m limit --limit 20/s
--limit-burst 200  -j ACCEPT
iptables -A in_eth1 -p tcp          --dport 3128   -m limit --limit 1/s
--limit-burst 10 -j LOG --log-level debug --log-prefix ''oflow proxy:
''
iptables -A in_eth1 -p tcp          --dport 3128   -m limit --limit 10/s
--limit-burst 10  -j REJECT
iptables -A in_eth1 -p tcp          --dport 3128   -j DROP


in this case, it''s good, because the user knows his connexion is being
refused.
(having packets dropped in this case is irritating... connexion is hanging..
it''s not friendly), and i don''t flood the network with
1000''s of packets.

what do you think about it ?

bye


-- 
xavier

On Saturday 14 February 2004 08:38 pm, xavier wrote:
>
> what do you think about it ?
>
Makes sense...

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net