Klauss, Could you Might be you can sponsor the development ... Regards Sébastien Klaus escribió: > 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 > > > _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
