--- On Thu, 3/24/11, Tom Eastep <[email protected]> wrote:
> 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. I'm using a bridge (say "SW BOX 1") for loc and net because I have another shorewall router/gateway (say "SW BOX 2") on the net subzone doing traffic marking in a multi-ISP setup. I'm using tcrules in "SW BOX 2" to mark IP addresses within "SW BOX 1"'s loc zone so that loc hosts connect to the internet through a specific DSL provider. If I setup eth0 and eth1 as routed interfaces (no bridge) on "SW BOX 1" I need to do masquerading of the loc zone. I can allow traffic from loc to net and it will reach "SW BOX 2" but a tcpdump shows that packets come from "SW BOX 1"'s external interface IP address. How can I classify and filter traffic via tcrules and rules on "SW BOX 2" when the requests are coming from "SW BOX 1"'s loc zone? My routed setup would look like this: loc: 10.215.0.0 255.255.0.0 "SW BOX 1": eth0: 10.215.144.91 ; eth1 (net): 172.16.0.1 "SW BOX 2": eth0: 172.16.0.2 (multi-ISP gateway) My bridge setup (currently running) is like this: loc: 10.215.0.0 255.255.0.0 "SW BOX 1": br0: eth0, eth1: 10.215.144.91 "SW BOX 2": eth0: 10.215.144.92 (multi-ISP gateway) Thanks Vieri > > > > > 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 ------------------------------------------------------------------------------ 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
