On 3/24/11 2:09 AM, Vieri Di Paola wrote: > Hi, > > According to http://www.shorewall.net/bridge-Shorewall-perl.html: > > <fw> -> <BP zone> rules are not allowed > <non-BP zone> -> <BP zone> rules are not allowed > > "Policies from a non-BP zone to a BP are disallowed. > Rules where the SOURCE is a non-BP zone and the DEST is a BP zone are > disallowed." > > > /etc/shorewall/zones defines a <BP zone> as a "subzone" of a <non-BP zone>: > > #ZONE TYPE OPTIONS > fw firewall > elsewhere ipv4 > world ipv4 > net:world bport > loc:world bport > > So I'm supposing that one CANNOT define rules and policies such as: > > <elsewhere> -> <loc> > > but can define rules such as: > > <elsewhere> -> <world>
Correct. > > Suppose that my loc zone is physically connected to eth0 and net is connected > to eth1 and that I want to allow specific IP addr/port traffic from > <elsewhere> to <net> but block it from <elsewhere> to <loc>. > If I set this in /etc/shorewall/policy: > elsewhere world REJECT > and this in /etc/shorewall/rules: > ACCEPT elsewhere world:<SMTP_SERVER_IP_ADDR> > tcp 25 > then I should be blocking all SMTP traffic except to my SMTP server. > However, I won't be able to explicitly allow tcp 25 traffic to the "loc" > subzone of "world" and disallow tcp 25 traffic to the "net" subzone. Yes > Also, if the net subzone is considered "insecure" then a host in that subzone > could assign itself the same IP address as my SMTP server thus receiving SMTP > traffic illegitimately. Yes > Is this a physdev match limitation? Yes. Read the material at the beginning of http://www.shorewall.net/bridge-Shorewall-perl.html#Shorewall for background on why it works the way that it does. The basic problem is that the IP stack doesn't know which port the packet is going out of until it is about to be sent (ARP packets may need to be sent to learn that). That's too late to make a filtering decision; it was done in earlier kernels and it broke other features like IPSEC and MAC filtration. > Is there a solution to this other than making sure that my net subzone isn't > "insecure"? Sure -- don't use a bridge in a configuration where there are other interfaces if you want to distinguish between destination bridge ports. > > On the other hand, if my /etc/shorewall/policy file contains: > net elsewhere REJECT info > net world REJECT info > and a host from <elsewhere> tries to connect to > <SMTP_SERVER_IP_ADDR> and the latter is within the net bport subzone (ie. > connected to eth1 in > my example) then it should fail, right? Yes. > The connection should succeed if <SMTP_SERVER_IP_ADDR> were > connected to eth0 (loc bport subzone). No. From <elsewhere>, the subzones are indistinguishable. -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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
