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. 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? PS - At this point I''m not too worried about expiring/removing the manually added rules. Just using crontab for a ''shorewall restart'' every night at 04:00 is good enough for now. ------------------------------------------------------------------------------ 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
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 \________________________________________________ ------------------------------------------------------------------------------ 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
Tom - thank you for your feedback. I had a sneaking suspicion that mucking about with iptables behind Shorewall''s back was not a great idea. However... On Apr 29, 2009, at 09:03 AM, Tom Eastep wrote:> 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 understood from http://shorewall.net/ipsets.html that patching/ rebuilding would be a necessary evil: "Using ipsets requires that you patch your kernel and iptables and that you build and install the ipset utility from http://ipset.netfilter.org/." I had not heard of xtables-addons. For the message archive and anybody else reading this thread: http://xtables-addons.sourceforge.net/ "Xtables-addons is the successor to patch-o-matic(-ng). Likewise, it contains extensions that were not, or are not yet, accepted in the main kernel/iptables packages. Xtables-addons is different from patch- o-matic in that you do not have to patch or recompile the kernel, sometimes recompiling iptables is also not needed." I will need to experiment with this on a test firewall on my own network for a while before implementing on a production firewall at a client site.> > 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 > -------------------------------------------------------------------------------- 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