I''ve been digging through the various manuals and am a bit irritated with limitation on the rules system Why do I have to specify a source zone to allow a source IP range on all zones? There is no iptables requirement for anything more than a source address, so I don''t understand why all:<ip> does not just add an accept rule into the head of the INPUT chain or even simply assume expanding that rule to all zones. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
That''s a good question and I''ve wondered that myself a time or two... On Jun 13, 2009, at 7:55, Colin Alston <colin.alston@thusa.co.za> wrote:> I''ve been digging through the various manuals and am a bit irritated > with limitation on the rules system > > Why do I have to specify a source zone to allow a source IP range on > all zones? There is no iptables requirement for anything more than a > source address, so I don''t understand why all:<ip> does not just add > an accept rule into the head of the INPUT chain or even simply > assume expanding that rule to all zones. > --- > --- > --- > --------------------------------------------------------------------- > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
Colin Alston wrote:> I''ve been digging through the various manuals and am a bit irritated > with limitation on the rules system > > Why do I have to specify a source zone to allow a source IP range on all > zones? There is no iptables requirement for anything more than a source > address, so I don''t understand why all:<ip> does not just add an accept > rule into the head of the INPUT chain or even simply assume expanding > that rule to all zones.Shorewall uses the keyword ''all'' rather than ''any'' to mean "All zones". It is implemented by expanding ''all'' into a list of all of the zones. By definition, SOURCE = ''all:<ip>'' implies that packets with the given source IP address can originate both on the firewall itself and outside of the firewall. Clearly, that isn''t possible in any sane network. Similarly, where ipsec is involved, the rule says "I don''t care whether traffic from this IP address is encrypted or not". So I believe a rule with such a SOURCE would imply that the user isn''t thinking clearly about his firewall requirements. ''all-:<ip>'' is somewhat more palatable in that it at least restricts <ip> to non-firewall zones. But the bottom line is that ''all-:<ip>'' will, in most configurations, generate extra rules that can''t possiblly be validly matched. And that isn''t a good thing in a firewall. -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 \________________________________________________ ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
On Sat, Jun 13, 2009 at 5:24 PM, Tom Eastep <teastep@shorewall.net> wrote:> > By definition, SOURCE = ''all:<ip>'' implies that packets with the given > source IP address can originate both on the firewall itself and outside > of the firewall. Clearly, that isn''t possible in any sane network. > Similarly, where ipsec is involved, the rule says "I don''t care whether > traffic from this IP address is encrypted or not". So I believe a rule > with such a SOURCE would imply that the user isn''t thinking clearly > about his firewall requirements. > >I don''t think this answers my question very well Tom. If people care about their IPSec tunnels then they should manage their firewall more appropriately for sure, but I''m of the opinion that that is the exception. The case I have is more of where I''d like to push generic rules without needing to know the naming or configuration of each and every zone and it''s interior or internet facing delegation. I can gleam that information from existing state, but this seems unnecessarily complex when an all:<ip> rule would suffice. In that case no one particularly cares if the traffic originates on $FW or interior zones, those rules just will never match. Simply put, if there are 3 internet facing zones and one local one it just overcomplicates the configuration to have the same rule repeated 3 times. In addition to this, the very fact that I''m creating a host specific rule should point to the fact that I''m aware of the host being trusted. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
Colin Alston wrote:> On Sat, Jun 13, 2009 at 5:24 PM, Tom Eastep <teastep@shorewall.net> wrote: > >> By definition, SOURCE = ''all:<ip>'' implies that packets with the given >> source IP address can originate both on the firewall itself and outside >> of the firewall. Clearly, that isn''t possible in any sane network. >> Similarly, where ipsec is involved, the rule says "I don''t care whether >> traffic from this IP address is encrypted or not". So I believe a rule >> with such a SOURCE would imply that the user isn''t thinking clearly >> about his firewall requirements. >> >> > I don''t think this answers my question very well Tom. > ... > The case I have is more of where I''d like to push generic rules without > needing to know the naming or configuration of each and every zone and it''s > interior or internet facing delegation. I can gleam that information from > existing state, but this seems unnecessarily complex when an all:<ip> rule > would suffice. In that case no one particularly cares if the traffic > originates on $FW or interior zones, those rules just will never match. > > Simply put, if there are 3 internet facing zones and one local one it just > overcomplicates the configuration to have the same rule repeated 3 times.If i''m understanding your issue correctly, Colin, i see a few different ways to progress this: 1. Define your rule on the INPUT chain manually using a startup script. 2. Define a parent zone which holds your 3 "internet facing zones" (i''m not sure exactly what you mean by that, however), and define your rule using the parent zone. This may not be an ideal solution, as parent/child zone behaviour is not always as obvious as it looks. 3. Assume that there is a more appropriate Shorewall construct and explain the specific instance further. Tom will likely have a suggestion very quickly. 4. Admit that the way you are thinking about your problem is not the way Shorewall is designed to work and use another iptables preprocessor. Since starting to work with Shorewall, i''ve never been irritated by one of its design features, which suggests that my brain works the way Tom''s does, and yours doesn''t. ;-) Sometimes it''s just simpler to find another product that works closer to the way you think. Paul ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
Paul Gear wrote:> Since starting to work with Shorewall, i''ve never been irritated by one > of its design features, which suggests that my brain works the way Tom''s > does, and yours doesn''t. ;-) Sometimes it''s just simpler to find > another product that works closer to the way you think. >I agree with Paul. Shorewall imposes a certain discipline when specifying your firewall behavior. If you chafe under that discipline, then possibly Shorewall isn''t for you. -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 \________________________________________________ ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects