ipt_account / iptables 1.3.8
Hi List,
It appears that ipt_account has vanished from iptables 1.3.8 (it was still there in 1.3.7) could someone please comment on the why?
The changelogs do not mention anything about it, neither does the source, and also I couldn't find anything googling thru the mailing list archives.
T Jacob
Hello,
Quoted 6 lines · Thomas Jacob
It appears that
ipt_accounthas vanished from iptables 1.3.8 (it was still there in 1.3.7) could someone please comment on the why?The changelogs do not mention anything about it
They do, in a rather laconic way though :
<quote>
- Remove extensions for unmaintained/obsolete patchlets </quote>
AFAIK, the concerned extensions are : fuzzy, nth, random (both superseded by statistic), ROUTE, account, BALANCE, childlevel, connlimit, dstlimit, FTOS, IPMARK, ipv4options, IPV4OPTSSTRIP, mport, NETLINK, osf, psd, record_rpc, rpc, TARPIT, TCPLAG, time, TRACE, u32, XOR.
Quoted 6 lines · Pascal Hambourg
[...]
AFAIK, the concerned extensions are : fuzzy, nth, random (both superseded by statistic), ROUTE, account, BALANCE, childlevel, connlimit, dstlimit, FTOS, IPMARK, ipv4options, IPV4OPTSSTRIP, mport, NETLINK, osf, psd,record_rpc, rpc, TARPIT, TCPLAG, time, TRACE, u32, XOR.
Is there something that functionally replaces TARPIT?
Quoted 10 lines · David Ford
Quoted 6 lines · Pascal Hambourg
[...]
AFAIK, the concerned extensions are : fuzzy, nth, random (both superseded by statistic), ROUTE, account, BALANCE, childlevel, connlimit, dstlimit, FTOS, IPMARK, ipv4options, IPV4OPTSSTRIP, mport, NETLINK, osf, psd,record_rpc, rpc, TARPIT, TCPLAG, time, TRACE, u32, XOR.Is there something that functionally replaces TARPIT?
Like, xt_DELUDE?
Jan
Quoted 5 lines · David Ford
Quoted 4 lines · Pascal Hambourg
<quote>
- Remove extensions for unmaintained/obsolete patchlets </quote>
Quoted 8 lines
Quoted 5 lines
AFAIK, the concerned extensions are : fuzzy, nth, random (both superseded by statistic), ROUTE, account, BALANCE, childlevel, connlimit, dstlimit, FTOS, IPMARK, ipv4options, IPV4OPTSSTRIP, mport, NETLINK, osf, psd,
record_rpc, rpc, TARPIT, TCPLAG, time, TRACE, u32, XOR.Is there something that functionally replaces TARPIT?
Uhm, please add a reference next time; only by chance I found the thread origin at the netfilter@ list.
No idea why TARPIT got removed. Maybe it's "unmaintained", but it did not need a lot of maintenance either. Though, people had to patch their kernel.
There is no replacement for TARPIT - it's solid. (And xt_DELUDE does not replace it; it is something inbetween REJECT and TARPIT.)
Jan
Quoted 8 lines · Jan Engelhardt
Uhm, please add a reference next time; only by chance I found the thread origin at the netfilter@ list.
No idea why TARPIT got removed. Maybe it's "unmaintained", but it did not need a lot of maintenance either. Though, people had to patch their kernel.
There is no replacement for TARPIT - it's solid. (And
xt_DELUDEdoes not replace it; it is something inbetween REJECT and TARPIT.)
Maintenance is only one aspect, but it is a problem since we can't even compile test it without patching our kernels. A second problem with most of these matches and targets is that they usually have a broken non-64 bit clean ABI and if we decide to merge them someday we need to fix that and thereby break compatibility before it was even included in the kernel, which is ridiculous.
They should have never gotten into a release and we fixed that now. You can still patch your kernel and iptables as you like.
Quoted 9 lines · Patrick McHardy
Quoted 8 lines · Jan Engelhardt
Uhm, please add a reference next time; only by chance I found the thread origin
at the netfilter@ list.No idea why TARPIT got removed. Maybe it's "unmaintained", but it did not need
a lot of maintenance either. Though, people had to patch their kernel.
Quoted 5 lines
Quoted 2 lines
There is no replacement for TARPIT - it's solid. (And
xt_DELUDEdoes not replace it; it is something inbetween REJECT and TARPIT.)Maintenance is only one aspect, but it is a problem since we can't even compile test it without patching our kernels.
So would not it be better to add TARPIT to the kernel and have the whole package work?
Quoted 5 lines
A second problem
with most of these matches and targets is that they usually have a broken non-64 bit clean ABI and if we decide to merge them someday we need to fix that and thereby break compatibility before it was even included in the kernel, which is ridiculous.
I agree, it should at least be 64 clean.
Quoted 3 lines
They should have never gotten into a release and we fixed that now. You can still patch your kernel and iptables as you like.
Can I also submit a (hopefully cleaned) e.g. TARPIT?
Jan
Quoted 1 line · Jan Engelhardt
Can I also submit a (hopefully cleaned) e.g. TARPIT?
I'd like to see an IPv4/IPv6 compatible TARPIT module in the mainline kernel. But please extend the target so that it could be used from the raw table and let the reply packets skip conntrack. Thus we could benefit from TARPIT even in a full blown conntrack/nat setup as well. (If I recall correctly, that is not possible with the original version.)
Best regards,
Jozsef
-
E-mail : [email protected], [email protected] 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
Quoted 10 lines · Jozsef Kadlecsik
Quoted 1 line · Jan Engelhardt
Can I also submit a (hopefully cleaned) e.g. TARPIT?
I'd like to see an IPv4/IPv6 compatible TARPIT module in the mainline kernel. But please extend the target so that it could be used from the raw table and let the reply packets skip conntrack. Thus we could benefit from TARPIT even in a full blown conntrack/nat setup as well. (If I recall correctly, that is not possible with the original version.)
The easiest way to do this would probably be to optionally attach a notrack conntrack to new packets. Looking at the version in SVN, it also needs:
- use generic checks for table and hook validation
- remove impossible skb->dst NULL ptr check
- remove impossible check for PACKET_OTHERHOST
- not abuse xrlim_allow
- resync TCP packet generation code with ipt_REJECT, especially properly deal with IPsec, not use ip_direct_send but dst_output
- kill ip_direct_send
- kill obsolete ifdefs
Shouldn't be much work, maybe I'll look into this after finishing my conntrack hash patches if no one beats me to it.
Quoted 3 lines · Patrick McHardy
Shouldn't be much work, maybe I'll look into this after finishing my conntrack hash patches if no one beats me to it.
Since you keep me busy with xt_u32 and xt_connlimit, I'll leave it to you for now :)
Jan
Quoted 8 lines · Patrick McHardy
Quoted 5 lines
I'd like to see an IPv4/IPv6 compatible TARPIT module in the mainline kernel. But please extend the target so that it could be used from the raw table and let the reply packets skip conntrack. Thus we could benefit from TARPIT even in a full blown conntrack/nat setup as well. (If I recall correctly, that is not possible with the original version.)
The easiest way to do this would probably be to optionally attach a notrack conntrack to new packets.
Yes, exactly.
Quoted 1 line
Looking at the version in SVN, it also needs:
[...]
Quoted 2 lines
Shouldn't be much work, maybe I'll look into this after finishing my conntrack hash patches if no one beats me to it.
The amount of work you have been doing is simply amazing...
Best regards,
Jozsef
-
E-mail : [email protected], [email protected] 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
experiences with ipt_ACCOUNT (was Re: ipt_account / iptables 1.3.8)
In reply to Pascal HambourgOh well, thanks for the info. A pity, as in kernels up to 2.6.18 the module was doing its job nicely, but I've now tried it with 2.6.21.5 and
there it doesn't even compile anymore.
There's an alternative module called ipt_ACCOUNT however, where the docs say that it does support 2.6.21.
==> http://www.intra2net.com/de/produkte/opensource/ipt_account/
I wonder if anyone would like to share experiences with that particular module in terms of performance and stability in a 70-100kpps load scenario.
Quoted 20 lines · Pascal Hambourg
Hello,
Quoted 6 lines · Thomas Jacob
It appears that
ipt_accounthas vanished from iptables 1.3.8 (it was still there in 1.3.7) could someone please comment on the why?The changelogs do not mention anything about it
They do, in a rather laconic way though :
<quote>
- Remove extensions for unmaintained/obsolete patchlets </quote>AFAIK, the concerned extensions are : fuzzy, nth, random (both superseded by statistic), ROUTE, account, BALANCE, childlevel, connlimit, dstlimit, FTOS, IPMARK, ipv4options, IPV4OPTSSTRIP, mport, NETLINK, osf, psd,
record_rpc, rpc, TARPIT, TCPLAG, time, TRACE, u32, XOR.