About ipp2p, Right now, the battle against p2p is lost with l7 detection from ipp2p, l7 filter and others. Why ?? It is a known fact that pattern matching does not work with full encrypted P2P handshakes based on DHT key exchange algorithms with byte padding. You have absolutely no byte pattern and no fixed packet lengths in the stream. So something like a flow history will fail or might have a very high false +ve rate. The thing is that there are proprietary solutions which can detect fully encrypted p2p streams based on a heuristic approach. (AFAIK ipoque is selling a proprietary library for this which is integrated in some firewall vendors). I have not seen any open source development into this direction. Klaus, (former) maintainer of ipp2p Marco Aurelio wrote: > As you might have seen, these are words from ipp2p author: > > """ > > I have seen some pieces of code from ipoque which can detect encypted bittorrent > and edonkey traffic. Unforunately, this code will not work with > iptables, because it needs > more information about the flow history and the history of an ip address. > > Right now, I do not have the time and the money to develop a filter > like this, but > if you are interested in a developement in this direction, please contact me. > > """ > > I *think* that we need something like a "bittorrent helper" in the > kernel to keep this extra information about the flow history and then > an iptables plugin to match. What do you think? Maybe we could contact > him to know what kind of information is it? > > > On Nov 12, 2007 9:17 AM, sawar <sawar@xxxxxxxxxx> wrote: >> Rtorrent which I use sometimes have ability to completely disable plain text >> communication : >> >> man rtorrent >> allow_incoming (allow incoming encrypted connections), >> try_outgoing (use encryption for outgoing connections), require (disable >> unencrypted handshakes), require_RC4 (also disable plaintext >> transmission after the initial encrypted handshake), enable_retry (if the >> initial outgoing connection fails, retry with encryption turned on if it was >> off or off if it was on), prefer_plain text (choose plaintext when peer >> offers a choice between plaintext transmission and RC4 encryption, otherwise >> RC4 will be used). >> >> and many other clients have similar abilities. >> I'm afraid that full encrypted and enabled by default communication is only a >> matter of time and we will lose this "fight" very soon. >> >> >>> Some clients P2P clients are nice about there encryption and negotiate >>> encryption ahead of time using plain communication. I.E. Limewire, >>> Azureus. However, some just start TLS and that is all you can see. >>> >>> Looking at ipp2ps signatures, I don't see anything that leads me to >>> believe they track that kind of info. >>> >>> >>> >>> David Bierce >>> >>> On Nov 11, 2007, at 9:48 PM, Mohan Sundaram wrote: >>>> sAwAr wrote: >>>>> Hi >>>>> I believe that whole question is in topic. Is there any way to >>>>> recognize ( and then shape ) p2p traffic which is encrypted? >>>>> Modern p2p clients have this ability moreover some of them have >>>>> this enabled by default. Now I'm using ipp2p for iptables but as I >>>>> know this doesn't recognize encrypted traffic. >>>>> Thanks in advance. >>>>> Pozdrawiam >>>>> Szymon Turkiewicz >>>> Have not tried this. An idea. P2P initiations are not encrypted >>>> AFAIK. Thus connections can be marked and related traffic shaped. If >>>> initiation is also encrypted, then I think we have a serious problem. >>>> >>>> Mohan >>>> _______________________________________________ >>>> LARTC mailing list >>>> LARTC@xxxxxxxxxxxxxxx >>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >>> _______________________________________________ >>> LARTC mailing list >>> LARTC@xxxxxxxxxxxxxxx >>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >> _______________________________________________ >> LARTC mailing list >> LARTC@xxxxxxxxxxxxxxx >> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >> > > > _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
