Hi,
I just setup a bridge with kernel 2.6.20 and followed
the instructions at
http://www.shorewall.net/NewBridge.html.
Since zone definitions are now IP-based and not
ports-based then doesn''t this imply a weaker security
mechanism?
In the NewBridge.html example, hosts 192.168.1.{10,11}
would have to be somehow "trusted" otherwise they
could just change their IP address accordingly and
Shorewall would treat it as part of the loc zone
instead of net.
The maclist option may help a bit but security would
still be an issue.
Am I missing something or is it a natural consequence
of the now-reduced physdev feature?
I have another different issue regarding the 2.6.20
bridge setup.
In pre-2.6.20 with identical Shorewall configuration
settings, hosts in the loc zone that did not have a
static route for a 10.215.0.0 remote destination but
had the shorewall bridge as their gateway (thus using
it as a "router") would communicate with the remote
subnets because of the routeback option.
After following the NewBridge.html instructions in a
2.6.20 system, only 10.215.144.0 hosts in the loc zone
get routed to the remote 10.215.0.0 subnets. Other
ranges fail (eg. 10.215.145.0 and our netmask is
255.255.252.0).
I would gladly post a shorewall dump but I won''t be
able to until Monday.
Maybe the information I post below is enough.
10.215.237.251 and 10.215.5.95 are remote hosts that
10.215.145.245 (in loc zone) is trying to reach
through gateway 10.215.144.6.
Host 10.215.145.245 only has a default gateway set to
the Shorewall bridge 10.215.144.91.
(this odd use of a routing bridge is for temporary
convenience only)
In the logs I see this:
Jun 1 13:38:36 inf-fw2 Shorewall:loc2net:DROP:IN=br0
OUT=br0 PHYSIN=eth1 SRC=10.215.145.245
DST=10.215.237.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127
ID=44720 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=46592
Jun 1 13:46:03 inf-fw2 Shorewall:loc2net:DROP:IN=br0
OUT=br0 PHYSIN=eth1 SRC=10.215.145.245 DST=10.215.5.95
LEN=92 TOS=0x00 PREC=0x00 TTL=17 ID=50143 PROTO=ICMP
TYPE=8 CODE=0 ID=512 SEQ=62208
# cat /etc/shorewall/hosts
#ZONE HOST(S)
OPTIONS
loc br0:10.215.144.0/22!10.215.144.92
routeback
# cat /etc/shorewall/interfaces
#ZONE INTERFACE BROADCAST OPTIONS
net br0 detect
routefilter,tcpflags
#net br0 10.215.147.255
Interface configuration:
bridge_br0="eth0 eth1"
config_br0=( "10.215.144.91 netmask 255.255.252.0" )
brctl_br0=( "stp on" )
routes_br0=(
"-net 10.215.0.0 netmask 255.255.0.0 gw 10.215.144.6"
"default via 10.215.144.92"
)
(10.215.144.92 is a router beyond the shorewall
bridge)
# uname -a
Linux inf-fw2 2.6.20-gentoo-r8 #1 SMP Wed May 23
14:53:30 CEST 2007 i686 AMD Athlon(TM) XP 1800+
AuthenticAMD GNU/Linux
If you need a shorewall dump please let me know and I
will post it as soon as I can.
Thanks
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news,
photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Vieri Di Paola wrote:> Hi, > > I just setup a bridge with kernel 2.6.20 and followed > the instructions at > http://www.shorewall.net/NewBridge.html. > > Since zone definitions are now IP-based and not > ports-based then doesn''t this imply a weaker security > mechanism? > In the NewBridge.html example, hosts 192.168.1.{10,11} > would have to be somehow "trusted" otherwise they > could just change their IP address accordingly and > Shorewall would treat it as part of the loc zone > instead of net. > The maclist option may help a bit but security would > still be an issue. > > Am I missing something or is it a natural consequence > of the now-reduced physdev feature? > > I have another different issue regarding the 2.6.20 > bridge setup. > In pre-2.6.20 with identical Shorewall configuration > settings, hosts in the loc zone that did not have a > static route for a 10.215.0.0 remote destination but > had the shorewall bridge as their gateway (thus using > it as a "router") would communicate with the remote > subnets because of the routeback option. > After following the NewBridge.html instructions in a > 2.6.20 system, only 10.215.144.0 hosts in the loc zone > get routed to the remote 10.215.0.0 subnets. Other > ranges fail (eg. 10.215.145.0 and our netmask is > 255.255.252.0). > > I would gladly post a shorewall dump but I won''t be > able to until Monday. > Maybe the information I post below is enough. > > 10.215.237.251 and 10.215.5.95 are remote hosts that > 10.215.145.245 (in loc zone) is trying to reach > through gateway 10.215.144.6. > Host 10.215.145.245 only has a default gateway set to > the Shorewall bridge 10.215.144.91. > (this odd use of a routing bridge is for temporary > convenience only) > > In the logs I see this: > > Jun 1 13:38:36 inf-fw2 Shorewall:loc2net:DROP:IN=br0 > OUT=br0 PHYSIN=eth1 SRC=10.215.145.245 > DST=10.215.237.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 > ID=44720 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=46592 > Jun 1 13:46:03 inf-fw2 Shorewall:loc2net:DROP:IN=br0 > OUT=br0 PHYSIN=eth1 SRC=10.215.145.245 DST=10.215.5.95 > LEN=92 TOS=0x00 PREC=0x00 TTL=17 ID=50143 PROTO=ICMP > TYPE=8 CODE=0 ID=512 SEQ=62208 > > # cat /etc/shorewall/hosts > #ZONE HOST(S) > OPTIONS > loc br0:10.215.144.0/22!10.215.144.92 > routeback >This /22 doesn''t cover the /16 from your routing below. /sbin/shorewall ipcalc 10.215.144.0/22 CIDR=10.215.144.0/22 NETMASK=255.255.252.0 NETWORK=10.215.144.0 BROADCAST=10.215.147.255 has 10.215.237.251 and 10.215.5.95 outside of your loc zone. Did you want a /16 here? Your treating the whole /16 as loc right?> # cat /etc/shorewall/interfaces > #ZONE INTERFACE BROADCAST OPTIONS > net br0 detect > routefilter,tcpflags > #net br0 10.215.147.255 > > Interface configuration: > > bridge_br0="eth0 eth1" > config_br0=( "10.215.144.91 netmask 255.255.252.0" ) > brctl_br0=( "stp on" ) > routes_br0=( > "-net 10.215.0.0 netmask 255.255.0.0 gw 10.215.144.6"this is the /16... from above> "default via 10.215.144.92" > )Hope that is the issue. Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
--- Jerry Vonau <jvonau@shaw.ca> wrote:> > # cat /etc/shorewall/hosts > > #ZONE HOST(S) > > OPTIONS > > loc br0:10.215.144.0/22!10.215.144.92 > > routeback > 10.215.237.251 and 10.215.5.95 outside of your > loc zone. > Did you want a /16 here? Your treating the whole /16 > as loc right?I understand Jerry. Actually, the loc zone should just be 10.215.144.0/22. The rest of the 10.215.0.0 are in remote subnets that can be reached through 10.215.144.6 which is within loc. However, since I defined 10.215.144.0/22 for the loc zone then anything outside of it is considered net and the policy is DROP. As far as shorewall is concerned, the remote 10.215.0.0 should be within loc as well. That was my mistake. Thank you for pointing it out. ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Vieri Di Paola wrote:> I just setup a bridge with kernel 2.6.20 and followed > the instructions at > http://www.shorewall.net/NewBridge.html. > > Since zone definitions are now IP-based and not > ports-based then doesn''t this imply a weaker security > mechanism?Yes, it does. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
--- Tom Eastep <teastep@shorewall.net> wrote:> Vieri Di Paola wrote: > > > I just setup a bridge with kernel 2.6.20 and > followed > > the instructions at > > http://www.shorewall.net/NewBridge.html. > > > > Since zone definitions are now IP-based and not > > ports-based then doesn''t this imply a weaker > security > > mechanism? > > Yes, it does.Too bad for me that they introduced a major handicap. In my case, I need the bridge but I also need an IPsec tunnel which only works on 2.6.20 when bridged. I found a custom solution but it''s not as good a security policy as it should be. Thanks for confirming my fears. ____________________________________________________________________________________ Get the Yahoo! toolbar and be alerted to new email wherever you''re surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Vieri Di Paola wrote:> > Too bad for me that they introduced a major handicap. > In my case, I need the bridge but I also need an IPsec > tunnel which only works on 2.6.20 when bridged.It turns out that fixing IPSec required that physdev match be modified in the way that it was. I''m beginning to think about how to make use of the reduced-function physdev match in Shorewall. Whatever I do will only be supported by Shorewall Perl. I will probably introduce a new type of zone to represent bridge ports. Current functionality will be available *from* this new type of zone to any other zone but traffic from other zone types will not be allowed to the new zone type. Rather the new zone type must be nested in a normal ipv4 zone that that is defined only by the bridge itself (and possibly by address groups, a la the current ''NewBridge'' technique) and rules/policies whose destination is the bridge will be governed by the parent zone. Something along the following lines: /etc/shorewall/zones: fw firewall net ipv4 lan ipv4 a:lan port b:lan port /etc/shorewall/interfaces: net eth0 - ... lan br0 - ... /etc/shorewall/hosts: a br0:eth1 ... b br0:eth1 ... fw->lan and net->lan rules/policies would be allowed but fw->a/b and net->a/b would not be allowed. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Tom Eastep wrote:> Vieri Di Paola wrote: > >> Too bad for me that they introduced a major handicap. >> In my case, I need the bridge but I also need an IPsec >> tunnel which only works on 2.6.20 when bridged. > > It turns out that fixing IPSec required that physdev match be modified in > the way that it was. > > I''m beginning to think about how to make use of the reduced-function physdev > match in Shorewall. Whatever I do will only be supported by Shorewall Perl. > > I will probably introduce a new type of zone to represent bridge ports. > Current functionality will be available *from* this new type of zone to any > other zone but traffic from other zone types will not be allowed to the new > zone type. Rather the new zone type must be nested in a normal ipv4 zone > that that is defined only by the bridge itself (and possibly by address > groups, a la the current ''NewBridge'' technique) and rules/policies whose > destination is the bridge will be governed by the parent zone. > > Something along the following lines: > > /etc/shorewall/zones: > > fw firewall > net ipv4 > lan ipv4 > a:lan port > b:lan port > > /etc/shorewall/interfaces: > > net eth0 - ... > lan br0 - ... > > /etc/shorewall/hosts: > > a br0:eth1 ... > b br0:eth1 ... >That should have been: b eth0:eth2 ---- -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
--- Tom Eastep <teastep@shorewall.net> wrote:> Tom Eastep wrote: > > Vieri Di Paola wrote: > > > >> Too bad for me that they introduced a major > handicap. > >> In my case, I need the bridge but I also need an > IPsec > >> tunnel which only works on 2.6.20 when bridged. > > > > It turns out that fixing IPSec required that > physdev match be modified in > > the way that it was. > > > > I''m beginning to think about how to make use of > the reduced-function physdev > > match in Shorewall. Whatever I do will only be > supported by Shorewall Perl.I''ll be glad to test it when and if the time comes. Vieri ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it''s updated for today''s economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/