Hi, can I propose a new standard rule file: macro.MAIL ############################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE RATE USER/ # PORT(S) PORT(S) LIMIT GROUP IMAP(PARAM) - - - IMAPS(PARAM) - - - POP3(PARAM) - - - POP3S(PARAM) - - - SMTP(PARAM) - - - SMTPS(PARAM) - - - Submission(PARAM) - - - I think it''s normal where we want to allow "mail" to allow all mail protocols. Additionally there might be a case for including the Submission in the examples here?: http://www.shorewall.net/ports.htm#SMTP Thanks Ed W ------------------------------------------------------------------------------ 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
On Wed, 2011-08-31 at 16:05 +0100, Ed W wrote:> Hi, can I propose a new standard rule file: macro.MAIL > > ############################################################################### > #ACTION SOURCE DEST PROTO DEST SOURCE RATE USER/ > # PORT(S) PORT(S) LIMIT GROUP > IMAP(PARAM) - - - > IMAPS(PARAM) - - - > > POP3(PARAM) - - - > POP3S(PARAM) - - - > > SMTP(PARAM) - - - > SMTPS(PARAM) - - - > Submission(PARAM) - - - > > > I think it''s normal where we want to allow "mail" to allow all mail > protocols.I have mixed feelings about omnibus macros like this; I think they encourage naive users to open many more ports than are really needed.> Additionally there might be a case for including the Submission in the > examples here?: > http://www.shorewall.net/ports.htm#SMTP >That web page was created prior to the invention of Shorewall macros; a case could be made that *every* macro should be documented there but that isn''t going to happen. I would prefer to change that page such that it instructs the user how to find the macro that handles a particular application rather than to expand it with selected applications. Anyone else have an opinion? -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
On 31/08/2011 17:41, Tom Eastep wrote:> On Wed, 2011-08-31 at 16:05 +0100, Ed W wrote: >> I think it''s normal where we want to allow "mail" to allow all mail >> protocols. > I have mixed feelings about omnibus macros like this; I think they > encourage naive users to open many more ports than are really needed. >There is an argument that for some naive users they can also *reduce* the number of ports if big "recipe" macros are available, because if it''s not easy to figure out, then those naive users tend to open great swathes of ports instead..? I would argue that for this very specific situation (mail), there are few modern mail servers that have security issues (even sendmail is decent these days..), and I can think of really very situations where you would want to open fewer than all of these ports, if you wanted to allow mail either in or out. Can anyone think of a real situation where it''s worse than just "neutral" that you open an extra "IMAPS" port where you only intended to open IMAP? Or where it''s useful to limit outbound clients to some subset of pop/imap/smtp? I guess I can think of a few corner cases, but none where it wouldn''t be fairly obvious that the "Mail" macro was the wrong choice? Actually, tell you where I have seen this fail - I''m seen some wifi hotspots that appear to want to *block* email, but they only remembered to block half the ports... "Mail(REJECT)" as a rule is likely to be a win for the naive user - I bet otherwise few would remember about Submission/IMAPS/POPS... Cheers Ed W ------------------------------------------------------------------------------ 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
On 02/09/11 11:20, Ed W wrote:> ... >> I have mixed feelings about omnibus macros like this; I think they >> encourage naive users to open many more ports than are really needed. > There is an argument that for some naive users they can also *reduce* > the number of ports if big "recipe" macros are available, because if > it''s not easy to figure out, then those naive users tend to open great > swathes of ports instead..? > ... > Actually, tell you where I have seen this fail - I''m seen some wifi > hotspots that appear to want to *block* email, but they only remembered > to block half the ports... "Mail(REJECT)" as a rule is likely to be a > win for the naive user - I bet otherwise few would remember about > Submission/IMAPS/POPS...My feelings about this are entirely unmixed: if you''re a naive user, you shouldn''t be configuring firewalls. I almost don''t use macros at all - i configure the exact numeric ports for nearly all services. Paul ------------------------------------------------------------------------------ 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
On Wed, 2011-08-31 at 09:41 -0700, Tom Eastep wrote:> > I have mixed feelings about omnibus macros like this; I think they > encourage naive users to open many more ports than are really needed.Agreed> Anyone else have an opinion? > >Do not want. If macro.MAIL is what you want, you can still add it to your own config. I have a few personal macros that I use, that I push to my servers with puppet. HTH, James ------------------------------------------------------------------------------ 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
On 02/09/2011 13:44, James Shubin wrote:> On Wed, 2011-08-31 at 09:41 -0700, Tom Eastep wrote: >> I have mixed feelings about omnibus macros like this; I think they >> encourage naive users to open many more ports than are really needed. > Agreed >> Anyone else have an opinion? >> >> > Do not want. > > If macro.MAIL is what you want, you can still add it to your own config. > I have a few personal macros that I use, that I push to my servers with > puppet. >If they are useful enough for you, then why not toss them upstream so that everyone might benefit? 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? 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) 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) 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''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 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 Thanks Ed W ------------------------------------------------------------------------------ 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
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 preferenceIn 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
Hi> The line has moved over time. Today, I would object to "Web" on the same grounds that I''m objecting to "Mail".OK, suggestion withdrawn. I still think that naive users will forget some of the ports relating to mail - perhaps that''s someone else''s problem to solve - I did like your Protocols page though and perhaps the complete list of ports might make the cut in that page? Arguably it''s most important for blocking stuff Just to comment on a couple of the points you raised. These are just opinions, please feel free to ignore:> 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.Well, you are twisting my words... My expectation is that if you want to allow SMTP & IMAP, then you would use exactly those rules, ie you have a specific expectation that you aren''t enabling POP. However, I would argue many users either want to allow "mail" out of their system, or want to allow "mail" into their mailserver (specific expectation of delivery and pickup). In these cases the group rule is more about completeness - I would compare it to an NTP macro where it would be easy to forget the TCP side since it''s infrequently used. Before GMail, few people could probably tell you all the SMTP ports, in particular the submission/encrypted ports. I suspect that gmail has been the main responsibility in popularising encrypted access. I have many travelling users and they used to argue that gmail was a "benefit" because gmail email used to still send from behind locked down wifi hotspots (gmail *require* you to setup to use the encrypted ports). On the other hand we offer all smtp options, BUT mail programs used to default to the unencrypted versions (that were blocked by the simple wifi policy). My point being that these group rules would have correctly locked down those access points as the admin desired (ok, it was kind of beneficial that the admin was an idiot, but the firewall didn''t meet his desired policy)> ACCEPT lan,wlan dmz tcp ssh,smtp,ssmtp,submission,www,ftp,imaps,domain,https,5901:5903Aha - good point. I had overlooked that it''s possible to put multiple ports on one line. This is obviously more efficient> 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.Optimisation of simple rules would be very clever!> I haven''t implemented that yet (been busy implementing disable/enable :-) ).Fair enough! Thanks!> I dislike POP, I don''t offer that service, and I don''t want those ports open.Just to be clear, I would argue that this is a clear case of wanting A and not B. I hope that at least most users would therefore not use the bulk policy due to the existence of "not B" being part of their policy. Anyway, proposal withdrawn. Have a good day all Ed W ------------------------------------------------------------------------------ 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