Hi there, I''m new to this list and to shorewall. In the past, I have been writing iptables command by hand, and needless to say I soon got sick of it everytime I had to add new services. It simply isn''t scalable. So I took a look at shorewall, which was recommended by friends. It certainly looked easy to to setup and has good default secure chains. However, I use vserver (http://www.solucorp.qc.ca/miscprj/s_context.hc), which is basically an enhanced chroot environment which can be used to run services in. The idea is that even with root privileges in such an environment, the underlying host system is still safe. Such an environment is usually run with an IP alias. (and processes in the environment can only bind and use this as a source address) The problem with shorewall and vserver is that rules which apply to different instances of the chroot environment (different IP aliases) do not work properly because the interface is always the loopback interface. So say I have 2 IP aliases on the same interface 192.168.1.1 and 192.168.1.2. If the default policy is to drop packets but say I wish to allow .2 to talk to .1 via udp 53 (as .1 is running a dnscache) I have to do something like iptables -A OUTPUT -o lo -p udp -s 192.168.1.2 -d 192.168.1.1 --dport 53 \ -j ACCEPT iptables -A INPUT -i lo -p udp -s 192.168.1.2 -d 192.168.1.1 --dport 53 \ -j ACCEPT (now you know the amount of work required in manually editing iptables script) This is only for one way communication from .2 to .1, the other way would be similar. I roughly went over shorewall''s scripts and I do not think it supports such a scheme, so I was wondering if the authors would be kind enough to add support as such? Thanks anyway!
--On Thursday, December 05, 2002 01:42:10 PM +0800 Kint <kint@x-tincted.net> wrote:> > The problem with shorewall and vserver is that rules which apply to > different instances of the chroot environment (different IP aliases) do > not work properly because the interface is always the loopback interface. > > So say I have 2 IP aliases on the same interface 192.168.1.1 and > 192.168.1.2. If the default policy is to drop packets but say I wish to > allow .2 to talk to .1 via udp 53 (as .1 is running a dnscache) I have to > do something like > > iptables -A OUTPUT -o lo -p udp -s 192.168.1.2 -d 192.168.1.1 --dport 53 \ > -j ACCEPT > iptables -A INPUT -i lo -p udp -s 192.168.1.2 -d 192.168.1.1 --dport 53 \ > -j ACCEPTShorewall unconditionally passes traffic to/from lo so you would have to insert such rules early in the INPUT/OUTPUT chains and follow them with your own DROP/REJECT policy rule.> > (now you know the amount of work required in manually editing iptables > script) > This is only for one way communication from .2 to .1, the other way would > be similar. I roughly went over shorewall''s scripts and I do not think it > supports such a scheme, so I was wondering if the authors would be kind > enough to add support as such? Thanks anyway!It was a conscious decision to not include ''lo'' support in the design of Shorewall. Such support is a loaded gun waiting for newbies to aim at their own feet. Shorewall already supplies one such loaded gun (the hosts file) and no matter how large the font used to warn people to leave the thing alone, there are always those that just can''t seem to resist. The ''lo'' interface doesn''t really fit very well into Shorewall''s model of the world so trying to add ''lo'' support at this late stage would be risky, especially since that support would have to be added in such a way as to not break existing configurations. When I start thinking about Shorewall II, I''ll revisit this issue. Until then, Shorewall will not support ''lo''. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://shorewall.sf.net ICQ: #60745924 \ teastep@shorewall.net