Hello Ed, On Sep 3, 2011, at 1:31 PM, Ed W wrote: > > I'm not sure I understand the criteria for what types of macros should > be in upstream? There is a macro for "SMTP", which is arguably just a > reminder of the port number for smtp. There is a macro for SMB, which is > useful because it covers the range of tcp and udp ports. There is a > selection of NTP* macros, which cover variations of direction and > ports. So upstream already ships very simple macros and macros like > "Web" which cover groups of protocols. Where is the line on what is > appropriate and what is not?
The line has moved over time. Today, I would object to "Web" on the same grounds that I'm objecting to "Mail". But it's been around for years and I also don't want to break peoples running configurations by removing a macro that they are using. "SMB" (and "SMBBI") are different because you can't, in general, remove any of their rules and not cause problems for most users of the macro. > > I asked previously if anyone has a genuine example where the macro would > "cause harm"? The original claim was that this would cause naive users > to open additional unneeded ports - I'm not disputing the general case, > but this *specific* case - I don't (currently) see that there are real > situations where a naive user will cause themselves harm using this? > Please consider the specific example here, not just the general idea of > "group macros", (which I'm not arguing in favour of) What you are saying is that it is okay to have extra ports open in your firewall so long as you don't currently have applications that use those ports? I don't want that to be the official position of the Shorewall project. > > I also claimed an benefit in the case of REJECT - a sensible group macro > in that case can be more secure for a naive user than said user trying > to figure out all the corner cases to block (blocking the easy stuff is > easy, it's the corner cases which go wrong) A RejectAllMail macro might make sense. > > If I examine the situations where I have requirement to filter mail, in > 100% of *my* situations I would need to write all 7 lines (either ACCEPT > or REJECT as appropriate). I wouldn't. Here is a rule from my configuration: ACCEPT lan,wlan dmz tcp ssh,smtp,ssmtp,submission,www,ftp,imaps,domain,https,5901:5903 That generates one Netfilter rule. Using individual lines would generate 12 rules (and a require a lot more typing). Now one of the reasons that I recently changed the compiler's internal representation of rules is that I would like to be able to efficiently combine multiple simple macro invocations into fewer rules. I haven't implemented that yet (been busy implementing disable/enable :-) ). > I'm struggling to imagine more than a > handful of situations where I wouldn't use the whole group... Typing is > bad and leads to cut and paste errors... (I have under 100 servers, so > I'm not going to claim my experience is definitive, but I have given it > some examination) I dislike POP, I don't offer that service, and I don't want those ports open. > I would like to ask you to reconsider your opinions - please discuss in > the context of what is the criteria for including in upstream macros, > not just personal preference In this small project, there are no written criteria for such things. As a result, my personal convictions carry considerable weight. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
