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:5903 Aha - 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 _______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
