David Tilley wrote: > In earlier versions of Shorewall, I used dynamic zones to allow ports > to be forwarded for users that authenticated to the firewall. By so > doing, for example, I could let my users reach Outlook Web Access on > the internal Exchange server without actually exposing an MS product > directly to the Internet. Once they authenticated to Apache, a small > hyper-paranoid utility would use shorewall(8) to add their IP to a > dynamic zone called OWA. Then I had a rule that looked something like > 'DNAT owa loc:192.168.0.4 tcp 443' > > Now I'm trying to recreate this functionality in 4.2.x-Perl without > dynamic zone support... and without patching/rebuilding my kernel for > ipset support.
I should note that you need neither patch nor rebuild your kernel for ipset support. You simply build and install xtables-addons. Note that you need to specify --libxtdir=/usr/libexec/ to ./configure for your iptables to be able to find the xtables-addons iptables modules. If you don't do that, then you need to build and install your own copy of iptables in /usr/local/sbin and ensure that Shorewall uses that copy (either via PATH or IPTABLES in shorewall.conf). I highly recommend that you do that rather than relying on inserting rules manually into the Shorewall ruleset. Note that Dynamic zones (ipset based) are returning to Shorewall-perl in Shorewall 4.4 (they are available now in the 4.3 development releases). It appears I can add my own rules with iptables, > blending them in after Shorewall has done its thing. Specifically if I > issue the following two commands on an already-running firewall I seem > to get the desired behavior: > > > iptables -t filter -I net2loc 2 -s $CLIENTIP -d 192.168.0.4 -p tcp - > m multiport --dports 443,3389 -m conntrack --ctorigdst $FWPUBIP -j > ACCEPT > > iptables -t nat -I net_dnat 1 -s $CLIENTIP -d $FWPUBIP -p tcp -m > multiport --dports 443,3389 -j DNAT --to-destination 192.168.0.4 > > > $FWPUBIP = one of the static public IP's of the firewall > $CLIENTIP = IP of a user who has authenticated to Apache and should > now enjoy the port forwarding > 192.168.0.4 = the internal private server > > > The above appears to work great, but I ask the experts... what obvious > thing have I overlooked? How paranoid will I need to be about future > Shorewall versions changing the table/chain structures? Any other > comments? Drawbacks include: - Your approach requires two rules per authenticated IP address. If you have FASTACCEPT=No, then the rule in net2loc will be traversed for every net->loc packet (not just connection requests). - The ACCEPT rule in net2loc will precede any rule created as a result of specifying a LIMIT:BURST in /etc/shorewall/policy. - Assuming that you have only a single 'net' interface, then when you upgrade to Shorewall 4.4, the rules that you insert into net2loc will precede rules generated by options like 'tcpflags,blacklist,dhcp,...' in /etc/shorewall/interfaces. - If you need to restart your firewall for some reason, all dynamically-added rules will be lost. -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
------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
