Hi all, I have found problems in p2p traffic detection. The ipp2p module works fine but in shorewall the rules written for this protocols never match because the initials p2p connection (login) match in ''-m state --state RELATED,ESTABLISHED -j ACCEPT'' rule before ''-m ipp2p --ipp2p -j DROP'' rule, so netfilter never filter p2p traffic. I have had to run ''run_iptables -I FORWARD -m ipp2p --ipp2p -j DROP'' in /etc/shorewall/start to make a general filter rule for p2p traffic. I want to improve this part of shorewall but I dont know where to locate the ipp2p rule or what kind of strategy to follow. Note: I have maked some test with ipp2p and ethereal to detect this situation. -- Juan Jes?s Prieto - Consultor?a TI jjprieto@eneotecnologia.com http://www.eneotecnologia.com --------------------------------------- fingerprint: BFC2 0370 7708 F800 0BEC 60A4 EC71 4BB1 CC85 99F5 http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xCC8599F5
Hi all (continuing my workmate email)> I have found problems in p2p traffic detection. The ipp2p module works > fineWell, actually this module doesnt work perfectly. The problem is the latest version doesnt mark initial packets of a P2P conversation (guess some P2P apps only) so following packets are considered part of the "connection". Here is where the problem arises in Shorewall. If this module was capable of detecting the first part of the conversation, there wont be any need for this modification.> but in shorewall the rules written for this protocols never match > because the initials p2p connection (login) match in ''-m state --state > RELATED,ESTABLISHED -j ACCEPT'' ruleAs said, if this rule comes first, further efforts to detect real P2P "orders" are not considered as the packet is already accepted as part of a connection.> before ''-m ipp2p --ipp2p -j DROP'' > rule, so netfilter never filter p2p traffic. I have had to run > ''run_iptables -I FORWARD -m ipp2p --ipp2p -j DROP'' > in /etc/shorewall/start to make a general filter rule for p2p traffic.What my teammate is doing is applying this rule before any shorewall rules. That way he detects those P2P orders and drops the package.> I want to improve this part of shorewall but I dont know where to > locate the ipp2p rule or what kind of strategy to follow.The problem is, it might be hard to place p2p rule before conntrack rule in a flexible manner as the admin states it wants to filter P2P as a rule, not as a zone property. The possibility we are studying is placing it before every conntrack rule on each zone chain (applies to all chains), make it more flexible (define P2P filtering as a zone property) or make it full system (place the rule just after invalid verification right at the beginning). The easier the implementation the harder it would be on CPU resources as you will need to look at more traffic. Kind regards. -- Jaime Nebrera - jnebrera@eneotecnologia.com Consultor TI - ENEO Tecnologia SL Telf.- 95 455 40 62 - 619 04 55 18
Jaime Nebrera wrote:> > What my teammate is doing is applying this rule before any shorewall > rules. That way he detects those P2P orders and drops the package. > >> I want to improve this part of shorewall but I dont know where to >>locate the ipp2p rule or what kind of strategy to follow. > > The problem is, it might be hard to place p2p rule before conntrack > rule in a flexible manner as the admin states it wants to filter P2P as > a rule, not as a zone property. The possibility we are studying is > placing it before every conntrack rule on each zone chain (applies to > all chains), make it more flexible (define P2P filtering as a zone > property) or make it full system (place the rule just after invalid > verification right at the beginning). > > The easier the implementation the harder it would be on CPU resources > as you will need to look at more traffic. >There are a number of issues here. a) Dropping/rejecting packets once a connection is established is open to DOS attack. We have discussed this before on the lists and it has been widely discussed on the Netfilter list. There is a reason why ipp2p and layer7 will never find their way into the code base at kernel.org. b) Shorewall is designed to be a stateful firewall. What you are proposing is stateless filtering. Hence, what you want to do will not fit into the overall Shorewall architecture (translation: it will be a hack). c) I have been aware of this problem for some time. Had I stayed on, I planned to *remove* ipp2p support from the rules and action.template files and only support it for traffic shaping and accounting. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
> c) I have been aware of this problem for some time. Had I stayed on, I > planned to *remove* ipp2p support from the rules and action.template > files and only support it for traffic shaping and accounting. > > -TomMaybe this is the best solution. If somebody need to use it for blocking p2p traffic, he can still uses some of the start, clear, ... files to insert his own ipp2p iptables rules. Regards. -- Juan Jes?s Prieto - Consultor?a TI jjprieto@eneotecnologia.com http://www.eneotecnologia.com --------------------------------------- fingerprint: BFC2 0370 7708 F800 0BEC 60A4 EC71 4BB1 CC85 99F5 http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xCC8599F5
Juan J. Prieto wrote:>>c) I have been aware of this problem for some time. Had I stayed on, I >>planned to *remove* ipp2p support from the rules and action.template >>files and only support it for traffic shaping and accounting. >> >>-Tom > > Maybe this is the best solution. If somebody need to use it for > blocking p2p traffic, he can still uses some of the start, clear, ... > files to insert his own ipp2p iptables rules.Exactly! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Hi,> a) Dropping/rejecting packets once a connection is established is open > to DOS attack. We have discussed this before on the lists and it has > been widely discussed on the Netfilter list. There is a reason why ipp2p > and layer7 will never find their way into the code base at kernel.org.Ok, but then how do we plan on filtering those apps? This is a demand users have. I understand it wont go into the kernel, but at the same time, P2P can be considered a DOS attack by itself :)> b) Shorewall is designed to be a stateful firewall. What you are > proposing is stateless filtering. Hence, what you want to do will not > fit into the overall Shorewall architecture (translation: it will be a > hack).IMHO, I dont agree here. Most people will filter detected P2P apps to a DROP, so no problems with state. You can consider is not state but still is secure. The problem might arise if it was an ACCEPT, then you could see malformed packages trying to exploit this. The solution of marking the packages (connections) is also valid, but as you say only for QoS and such. Most people will just want to get rid of them.> c) I have been aware of this problem for some time. Had I stayed on, I > planned to *remove* ipp2p support from the rules and action.template > files and only support it for traffic shaping and accounting.Ok So to other guys, how do we plan on l7 capabilities for linux firewalls with shorewall? Regards -- Jaime Nebrera - jnebrera@eneotecnologia.com Consultor TI - ENEO Tecnologia SL Telf.- 95 455 40 62 - 619 04 55 18
Jaime Nebrera wrote:> ... >>a) Dropping/rejecting packets once a connection is established is open >>to DOS attack. We have discussed this before on the lists and it has >>been widely discussed on the Netfilter list. There is a reason why ipp2p >>and layer7 will never find their way into the code base at kernel.org. > > Ok, but then how do we plan on filtering those apps? This is a demand > users have. I understand it wont go into the kernel, but at the same > time, P2P can be considered a DOS attack by itself :)When you''re talking about something as complex as P2P traffic, it seems to me that this is best handled by an application layer transparent proxy, similar to the way squid transparent proxying is handled currently.>>b) Shorewall is designed to be a stateful firewall. What you are >>proposing is stateless filtering. Hence, what you want to do will not >>fit into the overall Shorewall architecture (translation: it will be a >>hack). > > > IMHO, I dont agree here. Most people will filter detected P2P apps to > a DROP, so no problems with state. You can consider is not state but > still is secure. The problem might arise if it was an ACCEPT, then you > could see malformed packages trying to exploit this. The solution of > marking the packages (connections) is also valid, but as you say only > for QoS and such. Most people will just want to get rid of them.(I plead complete ignorance when it comes to file sharing applications.) Fill me in here: do these P2P apps do something tricky like changing server ports in order to avoid detection? Surely they have to start somewhere and you can just block them there and forget about them... Anything trickier than blocking should be handled in a proxy or traffic shaper, and just blocking we should be able to handle without special modules, right?> ... > So to other guys, how do we plan on l7 capabilities for linux > firewalls with shorewall?I''ve just read the web pages of both ipp2p and layer7, and although they don''t sound terribly interesting to me, i must admit they would likely be useful to places like universities. Is it possible to provide generic support for netfilter extension modules through some standardised syntax, or perhaps a "shorewall plugin" mechanism which would call appropriate functions at given points? -- Paul <http://paulgear.webhop.net> -- Tired of paying for Microsoft Office? Running an illegal copy and want to make it legal? Try OpenOffice.org! It''s free and does most of the things Microsoft Office does. <http://www.openoffice.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050531/74a629cc/signature.bin
Hi All, Paul Gear wrote:>Jaime Nebrera wrote: > > >>... >> >> >>>a) Dropping/rejecting packets once a connection is established is open >>>to DOS attack. We have discussed this before on the lists and it has >>>been widely discussed on the Netfilter list. There is a reason why ipp2p >>>and layer7 will never find their way into the code base at kernel.org. >>> >>> >> Ok, but then how do we plan on filtering those apps? This is a demand >>users have. I understand it wont go into the kernel, but at the same >>time, P2P can be considered a DOS attack by itself :) >> >> > >When you''re talking about something as complex as P2P traffic, it seems >to me that this is best handled by an application layer transparent >proxy, similar to the way squid transparent proxying is handled currently. > > > >>>b) Shorewall is designed to be a stateful firewall. What you are >>>proposing is stateless filtering. Hence, what you want to do will not >>>fit into the overall Shorewall architecture (translation: it will be a >>>hack). >>> >>> >> IMHO, I dont agree here. Most people will filter detected P2P apps to >>a DROP, so no problems with state. You can consider is not state but >>still is secure. The problem might arise if it was an ACCEPT, then you >>could see malformed packages trying to exploit this. The solution of >>marking the packages (connections) is also valid, but as you say only >>for QoS and such. Most people will just want to get rid of them. >> >> > >(I plead complete ignorance when it comes to file sharing applications.) > Fill me in here: do these P2P apps do something tricky like changing >server ports in order to avoid detection? Surely they have to start >somewhere and you can just block them there and forget about them... >Anything trickier than blocking should be handled in a proxy or traffic >shaper, and just blocking we should be able to handle without special >modules, right? > >No, unfortunately not. Kazaa as example will tunnel the firewall with even a simple http request only. Those protocols use a lot of tricks to avoid being blocked by simple static rules. That''s why there is the ipp2p module. Anyway, IMHO if a user has a need for using the ipp2p module he should use an addon script to add the custom rules in front of the RELATED,ESTABLISHED rules. Maybe we should add a FAQ/small HowTo about it?> > >>... >>So to other guys, how do we plan on l7 capabilities for linux >>firewalls with shorewall? >> >> > >I''ve just read the web pages of both ipp2p and layer7, and although they >don''t sound terribly interesting to me, i must admit they would likely >be useful to places like universities. > >I think such modules can be even interesting for home / small business networks. I''m using the ipp2p module because I provide privately ISP service for my neighborhood. According to the fact that it I''m not an "official" Telco company - (that is not responsible for the traffic that is passing their network) - I wan''t to avoid my users (mostly children) from downloading mp3 and other illegal things via my DSL line.>Is it possible to provide generic support for netfilter extension >modules through some standardised syntax, or perhaps a "shorewall >plugin" mechanism which would call appropriate functions at given points? > > > >------------------------------------------------------------------------ > >_______________________________________________ >Shorewall-devel mailing list >Shorewall-devel@lists.shorewall.net >https://lists.shorewall.net/mailman/listinfo/shorewall-devel > >
Hi,> When you''re talking about something as complex as P2P traffic, it seems > to me that this is best handled by an application layer transparent > proxy, similar to the way squid transparent proxying is handled currently.Well, comercial providers call it DPI, layer 7 or IPS. I dont know wich one is best and easier on resources. I think searching for known patterns is a good choice. Also, dont know of any proxy that currently is handling this.> (I plead complete ignorance when it comes to file sharing applications.) > Fill me in here: do these P2P apps do something tricky like changing > server ports in order to avoid detection? Surely they have to start > somewhere and you can just block them there and forget about them... > Anything trickier than blocking should be handled in a proxy or traffic > shaper, and just blocking we should be able to handle without special > modules, right?These apps are very tricky as they tend to mask themselves in other ports even using other protocols. Most popular way to do so is masking as a connection to port 80 using http protocol. That way is hard to block them using layer 3/4 firewalls. Also, they not only use that port, but search for an available one, thats why it might be hard to do with proxies. Other app that does the same is messenger. Regards -- Jaime Nebrera - jnebrera@eneotecnologia.com Consultor TI - ENEO Tecnologia SL Telf.- 95 455 40 62 - 619 04 55 18
Hi,> No, unfortunately not. Kazaa as example will tunnel the firewall with > even a simple http request only. Those protocols use a lot of tricks to > avoid being blocked by simple static rules. That''s why there is the > ipp2p module. Anyway, IMHO if a user has a need for using the ipp2p > module he should use an addon script to add the custom rules in front of > the RELATED,ESTABLISHED rules. Maybe we should add a FAQ/small HowTo > about it?Agreed, we are even studying the possibility of making a patch to shorewall and make it a configuration option.> I think such modules can be even interesting for home / small business > networks. > I''m using the ipp2p module because I provide privately ISP service for > my neighborhood. According to the fact that it I''m not an "official" > Telco company - (that is not responsible for the traffic that is passing > their network) - I wan''t to avoid my users (mostly children) from > downloading mp3 and other illegal things via my DSL line.Agreed. Even at home, if you share a link you dont want P2P fulling it. Regards -- Jaime Nebrera - jnebrera@eneotecnologia.com Consultor TI - ENEO Tecnologia SL Telf.- 95 455 40 62 - 619 04 55 18
Jaime Nebrera wrote:> Hi, > >>No, unfortunately not. Kazaa as example will tunnel the firewall with >>even a simple http request only. Those protocols use a lot of tricks to >>avoid being blocked by simple static rules. That''s why there is the >>ipp2p module. Anyway, IMHO if a user has a need for using the ipp2p >>module he should use an addon script to add the custom rules in front of >>the RELATED,ESTABLISHED rules. Maybe we should add a FAQ/small HowTo >>about it? > > Agreed, we are even studying the possibility of making a patch to > shorewall and make it a configuration option. >If you do that, please don''t use the rules file for specifying P2P filtering. The rules and policy files follow a very consistent stateful model. Adding stateless filtering to the rules file will be confusing; not the least of the issues will be that rules are no longer evaluated in order. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Hi Tom,> If you do that, please don''t use the rules file for specifying P2P > filtering. The rules and policy files follow a very consistent stateful > model. Adding stateless filtering to the rules file will be confusing; > not the least of the issues will be that rules are no longer evaluated > in order.We wont, it would be more something like a general configuration property, like "Filtering P2P=No/yes" if set to yes, some kind of ipp2p rule will be added before state rule on each zone2zone chain or so. The default will be No so no filtering will be done. -- Jaime Nebrera - jnebrera@eneotecnologia.com Consultor TI - ENEO Tecnologia SL Telf.- 95 455 40 62 - 619 04 55 18
Jaime Nebrera wrote:> Hi Tom, > >>If you do that, please don''t use the rules file for specifying P2P >>filtering. The rules and policy files follow a very consistent stateful >>model. Adding stateless filtering to the rules file will be confusing; >>not the least of the issues will be that rules are no longer evaluated >>in order. > > We wont, it would be more something like a general configuration > property, like "Filtering P2P=No/yes" if set to yes, some kind of ipp2p > rule will be added before state rule on each zone2zone chain or so. > > The default will be No so no filtering will be done. >Sounds like a candidate for a new column in the policy file. That way, you could specify P2P filtration between pairs of zones. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Hi,> Sounds like a candidate for a new column in the policy file. That way, > you could specify P2P filtration between pairs of zones.Yep, that sounds even better :) but still need to be able to set general policy on accept, drop or continue :) Thanks -- Jaime Nebrera - jnebrera@eneotecnologia.com Consultor TI - ENEO Tecnologia SL Telf.- 95 455 40 62 - 619 04 55 18
Jaime Nebrera wrote:> Hi, > >>Sounds like a candidate for a new column in the policy file. That way, >>you could specify P2P filtration between pairs of zones. > > Yep, that sounds even better :) but still need to be able to set > general policy on accept, drop or continue :) >Wouldn''t the "general policy" be specified as the P2P policy for all->all? That could be DROP, ACCEPT, ... Using the policy does bother me a bit because the POLICY and P2P policy would behave differently. POLICY can be overridden by rules whereas P2P policy cannot -- maybe it should be a separate file. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Hi Tom,> Wouldn''t the "general policy" be specified as the P2P policy for > all->all? That could be DROP, ACCEPT, ... > > Using the policy does bother me a bit because the POLICY and P2P policy > would behave differently. POLICY can be overridden by rules whereas P2P > policy cannot -- maybe it should be a separate file.I will discuss it with Juan and Pablo, our main software architects :) and give a more thought answer later on. Still is something we need so we will promote whatever solution is considered best by everybody. Regards -- Jaime Nebrera - jnebrera@eneotecnologia.com Consultor TI - ENEO Tecnologia SL Telf.- 95 455 40 62 - 619 04 55 18
Jaime Nebrera wrote:> Hi Tom, > > >>Wouldn''t the "general policy" be specified as the P2P policy for >>all->all? That could be DROP, ACCEPT, ... >> >>Using the policy does bother me a bit because the POLICY and P2P policy >>would behave differently. POLICY can be overridden by rules whereas P2P >>policy cannot -- maybe it should be a separate file. > > > I will discuss it with Juan and Pablo, our main software architects :) > and give a more thought answer later on. > > Still is something we need so we will promote whatever solution is > considered best by everybody.I too would be a little nervous with the approach of changing the format of the policy file. A separate file for ipp2p policy seems a better approach. -- Paul <http://paulgear.webhop.net> -- Did you know? Email viruses spread using addresses they find on the host computer. You can help to reduce the spread of these viruses by using Bcc: instead of To: on mass mailings, or using mailing list software such as mailman (http://www.list.org/) instead. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050601/395eb0e9/signature.bin
Alexander Wilms wrote:> ... >> (I plead complete ignorance when it comes to file sharing applications.) >> Fill me in here: do these P2P apps do something tricky like changing >> server ports in order to avoid detection? Surely they have to start >> somewhere and you can just block them there and forget about them... >> Anything trickier than blocking should be handled in a proxy or traffic >> shaper, and just blocking we should be able to handle without special >> modules, right? >> >> > No, unfortunately not. Kazaa as example will tunnel the firewall with > even a simple http request only. Those protocols use a lot of tricks to > avoid being blocked by simple static rules. That''s why there is the > ipp2p module. Anyway, IMHO if a user has a need for using the ipp2p > module he should use an addon script to add the custom rules in front of > the RELATED,ESTABLISHED rules. Maybe we should add a FAQ/small HowTo > about it?I think that would be a good start regardless (especially something that says when to use it and when not to), although if the eneotecnologia.com guys want to produce something more "official" then there''s no reason why we can''t support that. -- Paul <http://paulgear.webhop.net> -- Did you know? If you use two dashes followed by a space as your signature separator, good email programs will chop them off automatically, reducing noise in email replies. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050601/08bedf39/signature-0001.bin
Jaime Nebrera wrote:> ... >>(I plead complete ignorance when it comes to file sharing applications.) >> Fill me in here: do these P2P apps do something tricky like changing >>server ports in order to avoid detection? Surely they have to start >>somewhere and you can just block them there and forget about them... >>Anything trickier than blocking should be handled in a proxy or traffic >>shaper, and just blocking we should be able to handle without special >>modules, right? > > > These apps are very tricky as they tend to mask themselves in other > ports even using other protocols. Most popular way to do so is masking > as a connection to port 80 using http protocol. That way is hard to > block them using layer 3/4 firewalls. Also, they not only use that port, > but search for an available one, thats why it might be hard to do with > proxies. Other app that does the same is messenger.How is this a problem if they start on port 80? Just block it in your proxy server and problem solved. No more DoS possibilities. BTW, the argument about people who don''t have proxy servers doesn''t belong here - they should have one. There are very few platforms nowadays that would not be capable of running squid - i ran it on a 16 Mb, 66 MHz 486 for years, now my D-Link ADSL modem/router has better specs than that. If people want to do shaping, this seems like a reasonable thing to add, but like the ipp2p and layer7 web pages say, if you want to block, they are not the right solution. -- Paul <http://paulgear.webhop.net> -- Did you know? Email addresses can be forged easily. This message is signed with GNU Privacy Guard <http://www.gnupg.org> and Enigmail <http://enigmail.mozdev.org> so you can be sure it comes from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050602/f31de5d2/signature.bin
On Wednesday 01 June 2005 14:05, Paul Gear wrote:> > If people want to do shaping, this seems like a reasonable thing to add, > but like the ipp2p and layer7 web pages say, if you want to block, they > are not the right solution.How about we just yank support for it from the rules file and templates in 2.4.0 then? Given that it really doesn''t work anyway, it seems like a reasonable thing to do. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050601/80a4d6c6/attachment-0001.bin
On Wednesday 01 June 2005 15:43, Tom Eastep wrote:> How about we just yank support for it from the rules file and templates in > 2.4.0 then? Given that it really doesn''t work anyway, it seems like a > reasonable thing to do.Turns out that ipp2p was never implemented for actions so there''s nothing to remove there. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050601/96457d2b/attachment.bin
On Wednesday 01 June 2005 23:05, Paul Gear wrote:> Jaime Nebrera wrote: > > ... > > > > How is this a problem if they start on port 80? Just block it in your > proxy server and problem solved.I don''t agree about that: Squid is not enough, you also have to use some "advanced" filters within Squid. On the other hand port 80 and using a http tunnel is just an example. Other protocols/ports can and will be used as well.> No more DoS possibilities. BTW, the > argument about people who don''t have proxy servers doesn''t belong here - > they should have one. There are very few platforms nowadays that would > not be capable of running squid - i ran it on a 16 Mb, 66 MHz 486 for > years, now my D-Link ADSL modem/router has better specs than that. > > If people want to do shaping, this seems like a reasonable thing to add, > but like the ipp2p and layer7 web pages say, if you want to block, they > are not the right solution.Mhhh, I''m a bit surprised. I use ipp2p to block my neighbor''s kids. And it works like a charm. I did many tests with most of the p2p programs. At least I wasn''t able to download/upload anything using it with DROP target. Of course I can''t guarantee that no packet escaped, but the goal of avoiding illegal p2p downloads was reached. see "Does IPP2P match every P2P packet?" in http://www.ipp2p.org/faq_en.html I use Squid, but in this case it is not a solution for me. My Neighbors share the Internet/equipment costs with me, so they should have FULL access to the internet (loc1 net ACCEPT policy). Except doing copyright violations using my static IP. That''s why I have chosen this approach. As I said before, I agree about not integrating it into the core of shorewall, but I think there can/should be a HowTo about integrating it using the extension scripts. I would like to write one, but you know my holiday plans. If nobody else wants to do it, I could do it earliest mid of July. Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050602/74f97c9f/attachment.bin
On Wednesday 01 June 2005 21:37, Alexander Wilms wrote:> > As I said before, I agree about not integrating it into the core of > shorewall, but I think there can/should be a HowTo about integrating it > using the extension scripts. I would like to write one, but you know my > holiday plans. If nobody else wants to do it, I could do it earliest mid of > July.If no one has any objections then, I''ll go ahead and remove the ipp2p code from the rules file processing for 2.4.0. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050602/d125b209/attachment.bin
Tom Eastep wrote:> On Wednesday 01 June 2005 21:37, Alexander Wilms wrote: > > >>As I said before, I agree about not integrating it into the core of >>shorewall, but I think there can/should be a HowTo about integrating it >>using the extension scripts. I would like to write one, but you know my >>holiday plans. If nobody else wants to do it, I could do it earliest mid of >>July. > > > If no one has any objections then, I''ll go ahead and remove the ipp2p code > from the rules file processing for 2.4.0.Sounds fine to me. -- Paul <http://paulgear.webhop.net> -- Did you know? Microsoft Internet Explorer and Outlook have a poor track record for security <http://www.kb.cert.org/vuls/id/713878>. Why not try one of the more secure alternatives from <http://mozilla.org>? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050603/cc62c27d/signature.bin