Question about xt_ipp2p module

Question about xt_ipp2p module

[Dmitry Korzhevin]

[-- Attachment #1: Type: text/plain, Size: 2929 bytes --]

Hi,

I'm using Debian 6.0.7 x86_64. I have installed xtables with xt_ipp2p 
and seems i did something wrong, because my rules doesn't drop 
bittorrent traffic. Please help

Installation:

apt-get install module-assistant xtables-addons-source
module-assistant prepare
module-assistant auto-install xtables-addons-source
depmod -a
modprobe xt_ipp2p

lsmod | grep p2p

xt_ipp2p                6297  3
compat_xtables          3111  1 xt_ipp2p

I have added rules to all iptables chains:

iptables -I FORWARD 1 -m ipp2p --bit -j DROP
iptables -I INPUT 1 -m ipp2p --bit -j DROP
iptables -I OUTPUT 1 -m ipp2p --bit -j DROP

Here is my iptables rules:

# Generated by iptables-save v1.4.8 on Tue Mar 26 20:45:56 2013
*nat
:PREROUTING ACCEPT [654835:50597876]
:POSTROUTING ACCEPT [436798:25728576]
:OUTPUT ACCEPT [436371:25593024]
-A POSTROUTING -s 10.3.0.0/16 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.2.0.0/16 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.1.0.0/16 -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue Mar 26 20:45:56 2013
# Generated by iptables-save v1.4.8 on Tue Mar 26 20:45:56 2013
*filter
:INPUT ACCEPT [1986:141808]
:FORWARD ACCEPT [89:11517]
:OUTPUT ACCEPT [1796:190899]
:sshguard - [0:0]
-A INPUT -m ipp2p --bit -j DROP
-A INPUT -j sshguard
-A FORWARD -m ipp2p --bit -j DROP
-A OUTPUT -m ipp2p --bit -j DROP
COMMIT
# Completed on Tue Mar 26 20:45:56 2013



This server rules, after my VPN (ipsec) connection and start downloading 
torrent:

iptables -nL -v --line-numbers
Chain INPUT (policy ACCEPT 70 packets, 8404 bytes)
num   pkts bytes target     prot opt in     out     source  destination
1       26  2466 DROP       all  --  *      *       0.0.0.0/0  0.0.0.0/0 
           ipp2p --bit
2      17M 4140M sshguard   all  --  *      *       0.0.0.0/0  0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source  destination
1       33  2970 ACCEPT     all  --  eth0   *       10.2.0.2  0.0.0.0/0 
           policy match dir in pol ipsec reqid 116 proto 50
2       26 10983 ACCEPT     all  --  *      eth0    0.0.0.0/0  10.2.0.2 
            policy match dir out pol ipsec reqid 116 proto 50
3        0     0 DROP       all  --  *      *       0.0.0.0/0  0.0.0.0/0 
           ipp2p --bit

Chain OUTPUT (policy ACCEPT 51 packets, 18004 bytes)
num   pkts bytes target     prot opt in     out     source  destination
1        0     0 DROP       all  --  *      *       0.0.0.0/0  0.0.0.0/0 
           ipp2p --bit

Chain sshguard (1 references)
num   pkts bytes target     prot opt in     out     source  destination


Seems ipsec rules has higer priority than my rule in chain FORWARD.




Best Regards,
Dmitry

---
Dmitry KORZHEVIN
System Administrator
STIDIA S.A. - Luxembourg

e: dmitry.korzhevin@stidia.com
m: +38 093 874 5453
w: http://www.stidia.com


[-- Attachment #2: Криптографическая подпись S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4488 bytes --]

Re: Question about xt_ipp2p module

[Andrew Beverley]

On Tue, 2013-03-26 at 21:53 +0200, Dmitry Korzhevin wrote:
> Hi,
> 
> I'm using Debian 6.0.7 x86_64. I have installed xtables with xt_ipp2p 
> and seems i did something wrong, because my rules doesn't drop 
> bittorrent traffic.

My gut instinct is it's not working because ipp2p is old software and
may not match the bittorrent stream that you are using.

> 1       33  2970 ACCEPT     all  --  eth0   *       10.2.0.2 
>   0.0.0.0/0           policy match dir in pol ipsec reqid 116 proto 50
> 2       26 10983 ACCEPT     all  --  *      eth0    0.0.0.0/0 
>   10.2.0.2            policy match dir out pol ipsec reqid 116 proto 50
> 3        0     0 DROP       all  --  *      *       0.0.0.0/0 
>   0.0.0.0/0           ipp2p --bit

Nonetheless, given that the default policy is ACCEPT, why not just
delete rules 1 and 2 to check whether that is the problem?

Are you forwarding the bittorrent traffic to another machine or
downloading it locally? I see that you are using rules in both the INPUT
and FORWARD chains.

Andy

Re: Question about xt_ipp2p module

[Jan Engelhardt]

On Wednesday 2013-03-27 10:19, Dmitry Korzhevin wrote:
>
> 1 33  2970 ACCEPT     all  --  eth0   *       10.2.0.2   0.0.0.0/0      policy
> match dir in pol ipsec reqid 116 proto 50
> 2       26 10983 ACCEPT     all  --  *      eth0    0.0.0.0/0
>  10.2.0.2            policy match dir out pol ipsec reqid 116 proto 50
>
>
> But, this rules is inserted automaticaly by strongswan ipsec daemon, after my
> connection..

So turn it off in strongswan?

Re: Question about xt_ipp2p module

[Andrew Beverley]

On Wed, 2013-03-27 at 14:32 +0100, Jan Engelhardt wrote:
> On Wednesday 2013-03-27 10:19, Dmitry Korzhevin wrote:
> >
> > 1 33  2970 ACCEPT     all  --  eth0   *       10.2.0.2   0.0.0.0/0      policy
> > match dir in pol ipsec reqid 116 proto 50
> > 2       26 10983 ACCEPT     all  --  *      eth0    0.0.0.0/0
> >  10.2.0.2            policy match dir out pol ipsec reqid 116 proto 50
> >
> >
> > But, this rules is inserted automaticaly by strongswan ipsec daemon, after my
> > connection..
> 
> So turn it off in strongswan?

Or if you can't do that, then just delete the rules once they're in
there, or reinsert your own rules at a higher priority.

Andy

Re: Question about xt_ipp2p module

[Jan Engelhardt]

On Wednesday 2013-03-27 18:52, Andrew Beverley wrote:
>> > 2       26 10983 ACCEPT     all  --  *      eth0    0.0.0.0/0
>> >  10.2.0.2            policy match dir out pol ipsec reqid 116 proto 50
>> >
>> >
>> > But, this rules is inserted automaticaly by strongswan ipsec daemon, after my
>> > connection..
>> 
>> So turn it off in strongswan?
>
>Or if you can't do that, then just delete the rules once they're in
>there, or reinsert your own rules at a higher priority.

Well, strongswan has this leftfirewall=yes option that probably causes this,
but I have not yet found a reason to use it, because you can just use -m policy
on your own. While you do not know the reqid, it probably does not matter
because strongswan would add ACCEPT rules for all of them anyway.

Re: Question about xt_ipp2p module

[Andrew Beverley]

On Wed, 2013-03-27 at 11:19 +0200, Dmitry Korzhevin wrote:
> 26.03.2013 23:28, Andrew Beverley пишет:
> > On Tue, 2013-03-26 at 21:53 +0200, Dmitry Korzhevin wrote:
> >> Hi,
> >>
> >> I'm using Debian 6.0.7 x86_64. I have installed xtables with xt_ipp2p
> >> and seems i did something wrong, because my rules doesn't drop
> >> bittorrent traffic.
> >
> > My gut instinct is it's not working because ipp2p is old software and
> > may not match the bittorrent stream that you are using.
> >
> >> 1       33  2970 ACCEPT     all  --  eth0   *       10.2.0.2
> >>    0.0.0.0/0           policy match dir in pol ipsec reqid 116 proto 50
> >> 2       26 10983 ACCEPT     all  --  *      eth0    0.0.0.0/0
> >>    10.2.0.2            policy match dir out pol ipsec reqid 116 proto 50
> >> 3        0     0 DROP       all  --  *      *       0.0.0.0/0
> >>    0.0.0.0/0           ipp2p --bit
> >
> > Nonetheless, given that the default policy is ACCEPT, why not just
> > delete rules 1 and 2 to check whether that is the problem?
> >
> > Are you forwarding the bittorrent traffic to another machine or
> > downloading it locally? I see that you are using rules in both the INPUT
> > and FORWARD chains.
>
> Thank you for answer! But, i'm testing this netfilter module according 
> various internet howtos, where people claim that this  module can block 
> bittorrent traffic.

Yes, but that doesn't mean that it is guaranteed to match every
bittorrent implementation.

An alternative way of matching bittorrent traffic is to use the
connlimit module to look for lots of connections from a client above
ports 1024. This is pretty brutal and prone to false-positives, but it
may work for you. There is an example here:

http://andybev.com/index.php/Fair_traffic_shaping_an_ADSL_line_for_a_local_network_using_Linux

BTW: Please don't top-post.

Andy