alex wrote:> Please, sorry, Tom but i agin want to talk about RFC1918. > Now i use follow rule in ''rules'' file: > > REJECT! all net:$RFC1918_NETS > > so as norfc1918 interface option don''t work properly for me. > I have questions about this situation. > In what cases this option (norfc1918) would work effective? > Are my config such unique? > May be change its (norfc1918 option) realization so as it can > satisfy all cases?The ''norfc1918'' option is an artifact -- if I were to re-design Shorewall, I would definitely leave it out, You may have noticed that the ''rfc1918'' file no longer appears in the 4.0 documentation. Take that as a hint that the option is gradually being phased out. An rfc1918 macro as follows will do everything that the ''norfc1918'' option did and more: PARAM SOURCE DEST:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 DEST Note -- the above macro only works with Shorewall-perl 4.0.9 or later. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> The 'norfc1918' option is an artifact -- if I were to re-design Shorewall, >I would definitely leave it out, You may have noticed that the 'rfc1918' >file no longer appears in the 4.0 documentation. Take that as a hint that >the > option is gradually being phased out. > > An rfc1918 macro as follows will do everything that the 'norfc1918' option >did and more: > > PARAM SOURCE DEST:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 > PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 DEST > > Note -- the above macro only works with Shorewall-perl 4.0.9 or later. > > -TomI found file 'rfc1918' in directory with other macro files but its name haven't prefix 'macro.' and it have differ syntax from other macros. Please, Tom, give an example of using 'rfc1918' macro. Thank you, Alex ---- Спрос на экспресс-кредиты в Белгазпромбанке растет: кредит «Фирменный» и кредит «Просто деньги» http://www.belgazprombank.by/6788242.html ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
alex wrote:>> The ''norfc1918'' option is an artifact -- if I were to re-design Shorewall, >> I would definitely leave it out, You may have noticed that the ''rfc1918'' >> file no longer appears in the 4.0 documentation. Take that as a hint that >> the >> option is gradually being phased out. >> >> An rfc1918 macro as follows will do everything that the ''norfc1918'' option >> did and more: >> >> PARAM SOURCE DEST:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 >> PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 DEST >> >> Note -- the above macro only works with Shorewall-perl 4.0.9 or later. >> >> -Tom > > I found file ''rfc1918'' in directory with other macro files but its > name haven''t prefix ''macro.'' and it have differ syntax from other macros.It is _not_ a macro. It is a data file that drives the behavior of the ''norfc1918''. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> alex wrote: >>> The ''norfc1918'' option is an artifact -- if I were to re-design >>> Shorewall, I would definitely leave it out, You may have noticed that >>> the ''rfc1918'' file no longer appears in the 4.0 documentation. Take >>> that as a hint that the option is gradually being phased out. >>> >>> An rfc1918 macro as follows will do everything that the ''norfc1918'' >>> option did and more: >>> >>> PARAM SOURCE DEST:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 >>> PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 DEST >>> >>> Note -- the above macro only works with Shorewall-perl 4.0.9 or later. >>> >>> -Tom >> >> I found file ''rfc1918'' in directory with other macro files but its >> name haven''t prefix ''macro.'' and it have differ syntax from other macros. > > It is _not_ a macro. It is a data file that drives the behavior of the > ''norfc1918''.Looks like I did document it after all... man shorewall-rfc1918 -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>>> The 'norfc1918' option is an artifact -- if I were to re-design Shorewall, >>> I would definitely leave it out, You may have noticed that the 'rfc1918' >>> file no longer appears in the 4.0 documentation. Take that as a hint that >>> the >>> option is gradually being phased out. >>> >>> An rfc1918 macro as follows will do everything that the 'norfc1918' option >>> did and more: >>> >>> PARAM SOURCE DEST:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 >>> PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 DEST >>> >>> Note -- the above macro only works with Shorewall-perl 4.0.9 or later. >>> >>> -Tom >> >> I found file 'rfc1918' in directory with other macro files but its >> name haven't prefix 'macro.' and it have differ syntax from other macros. > > It is _not_ a macro. It is a data file that drives the behavior of the >'norfc1918'. > > -TomOk Tom. Now instead my rule in 'rules' file: REJECT! all net:$RFC1918_NETS i create macro 'macro.rfc1918' with content(literally): PARAM SOURCE DEST:$RFC1918_NETS # PARAM SOURCE:$RFC1918_NETS DEST (i comment out second string so as in opposite case i haven't access from internal networks to Internet) And add follow rule in 'rules': rfc1918(REJECT!) all net This work same as old rule. Am i right? Alex ---- Спрос на экспресс-кредиты в Белгазпромбанке растет: кредит «Фирменный» и кредит «Просто деньги» http://www.belgazprombank.by/6788242.html ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
alex wrote:>>>> The ''norfc1918'' option is an artifact -- if I were to re-design Shorewall, >>>> I would definitely leave it out, You may have noticed that the ''rfc1918'' >>>> file no longer appears in the 4.0 documentation. Take that as a hint that >>>> the >>>> option is gradually being phased out. >>>> >>>> An rfc1918 macro as follows will do everything that the ''norfc1918'' option >>>> did and more: >>>> >>>> PARAM SOURCE DEST:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 >>>> PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 DEST >>>> >>>> Note -- the above macro only works with Shorewall-perl 4.0.9 or later. >>>> >>>> -Tom >>> I found file ''rfc1918'' in directory with other macro files but its >>> name haven''t prefix ''macro.'' and it have differ syntax from other macros. >> It is _not_ a macro. It is a data file that drives the behavior of the >> ''norfc1918''. >> >> -Tom > > Ok Tom. > Now instead my rule in ''rules'' file: > > REJECT! all net:$RFC1918_NETS > > i create macro ''macro.rfc1918'' with content(literally): > > PARAM SOURCE DEST:$RFC1918_NETS > # PARAM SOURCE:$RFC1918_NETS DEST > > (i comment out second string so as in opposite case i haven''t > access from internal networks to Internet) > And add follow rule in ''rules'': > > rfc1918(REJECT!) all net > > This work same as old rule. > Am i right?I guess (although the ''!'' is silly). The macro that I described is intended to replace ''norfc1918'' (with RFC1918_STRICT) which doesn''t prevent local hosts from connecting to RFC 1918 addresses in the ''net'' zone. Given that more and more ISPs are using RFC 1918 addressing within their own infrastructure, any general recommendation to do that sort of filtering is probably unwise. My macro (call it Rfc1918), would be used like: Rfc1918(DROP) net all -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> I guess (although the ''!'' is silly).Actually, I don''t know where you are inserting this rule so ''!'' may, in fact, be required. -Tom --=20 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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
On Wed, Mar 26, 2008 at 09:55:50AM -0700, Tom Eastep wrote:> Tom Eastep wrote: > > > I guess (although the ''!'' is silly). > > Actually, I don''t know where you are inserting this rule so ''!'' may, in > fact, be required.Unlikely, though. I''ve done more than a few rather complex shorewall installations, and I don''t think I''ve ever had a use for REJECT! I do vaguely recall needing an ACCEPT! once, but I think even that was a quick hack to fix some poorly designed rules. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Andrew Suffield wrote:> > > I do vaguely recall needing an ACCEPT! once, but I think even that > was a quick hack to fix some poorly designed rules.ACCEPT! has richer semantics than REJECT!. It also suppresses subsequent DNAT/REDIRECT (and I see that I need to update the man page to reflect that). REJECT! is used to exempt a wildcard rule from being optimized away by OPTIMIZE=1. Example: net->dmz policy of "REJECT info" Rules: REJECT:info all all udp 1024 ACCEPT net:1.2.3.4 fw In that case, net->fw UDP 1024 would still be allowed from 1.2.3.4 because the REJECT rule duplicates the policy of net->fw so would not be included in the net2fw chain. Changing the REJECT:info to REJECT!:info does what the rules intend. This has always been a rather ugly wart. The intent of course is to avoid generating rules that duplicate the policy. But sometimes, that isn''t appropriate. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> > > ACCEPT! has richer semantics than REJECT!. It also suppresses subsequent > DNAT/REDIRECT (and I see that I need to update the man page to reflect > that).Please ignore the above. I was thinking of ACCEPT+, not ACCEPT-. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
On Wed, Mar 26, 2008 at 11:22:53AM -0700, Tom Eastep wrote:> Example: > > net->dmz policy of "REJECT info" > > Rules: > > REJECT:info all all udp 1024 > ACCEPT net:1.2.3.4 fw > > In that case, net->fw UDP 1024 would still be allowed from 1.2.3.4 > because the REJECT rule duplicates the policy of net->fw so would not be > included in > the net2fw chain. Changing the REJECT:info to REJECT!:info does what the > rules intend.Isn''t that a bug? Shorewall should never discard a rule like that if it has parameters other than just "all all". ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>>>>> The 'norfc1918' option is an artifact -- if I were to re-design Shorewall, >>>>> I would definitely leave it out, You may have noticed that the 'rfc1918' >>>>> file no longer appears in the 4.0 documentation. Take that as a hint that >>>>> the >>>>> option is gradually being phased out. >>>>> >>>>> An rfc1918 macro as follows will do everything that the 'norfc1918' option >>>>> did and more: >>>>> >>>>> PARAM SOURCE DEST:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 >>>>> PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 DEST >>>>> >>>>> Note -- the above macro only works with Shorewall-perl 4.0.9 or later. >>>>> >>>>> -Tom >>>> I found file 'rfc1918' in directory with other macro files but its >>>> name haven't prefix 'macro.' and it have differ syntax from other macros. >>> It is _not_ a macro. It is a data file that drives the behavior of the >>> 'norfc1918'. >>> >>> -Tom >> >> Ok Tom. >> Now instead my rule in 'rules' file: >> >> REJECT! all net:$RFC1918_NETS >> >> i create macro 'macro.rfc1918' with content(literally): >> >> PARAM SOURCE DEST:$RFC1918_NETS >> # PARAM SOURCE:$RFC1918_NETS DEST >> >> (i comment out second string so as in opposite case i haven't >> access from internal networks to Internet) >> And add follow rule in 'rules': >> >> rfc1918(REJECT!) all net >> >> This work same as old rule. >> Am i right? > > I guess (although the '!' is silly). > > The macro that I described is intended to replace 'norfc1918' (with >RFC1918_STRICT) which doesn't prevent local hosts from connecting to RFC >1918 addresses in the 'net' zone. Given that more and more ISPs are using >RFC 1918 addressing within their own infrastructure, any general >recommendation to do that sort of filtering is probably unwise. > > My macro (call it Rfc1918), would be used like: > > Rfc1918(DROP) net all > > -TomDear Tom, thank you for your detail answer but in my configuration (with Shorewall-4.1.6) ONLY one configuration work such as i want - shorewall don't send packets for RFC1918 networks to Internet. This config you see above (no matter DROP or REJECT but with !) and i see follow: alex@pc:~> ping 192.168.45.123 PING 192.168.45.123 (192.168.45.123) 56(84) bytes of data. From 192.168.5.1: icmp_seq=1 Destination Host Unreachable From 192.168.5.1 icmp_seq=1 Destination Host Unreachable From 192.168.5.1 icmp_seq=2 Destination Host Unreachable Where 192.168.5.1 is my Shorewall default gateway. In ALL another variants that you recommend i see follow: alex@pc:~> ping 192.168.45.123 PING 192.168.45.123 (192.168.45.123) 56(84) bytes of data. From 212.98.160.153: icmp_seq=1 Destination Host Unreachable From 212.98.160.153 icmp_seq=1 Destination Host Unreachable Where 212.98.160.153 is my ISP address. Thank you very much, Alex ---- Кредит на развитие бизнеса от Белгазпромбанка – всегда успешный старт. Кредит «Успешный старт» http://www.belgazprombank.by/6788242.html ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
alex wrote:> > Dear Tom, thank you for your detail answer but in my configuration > (with Shorewall-4.1.6) ONLY one configuration work such as i want - >Then please use it. I don''t want to hear about this topic again. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> alex wrote: >> Dear Tom, thank you for your detail answer but in my configuration >> (with Shorewall-4.1.6) ONLY one configuration work such as i want - >> > > Then please use it. I don''t want to hear about this topic again.My apologies to Alex and the list. I should have cooled down before responding. The reason that the macro didn''t work properly is because it placed RFC1918 addresses in the DEST column rather than in the ORIGINAL DEST column (which is essentially what the ''norfc1918'' option does). For 4.1.7, I''ve taken the following steps: a) The macro file layout has been extended to include an ORIGINAL DEST column. This was requested earlier. Note that ORIGINAL DEST may not be specified in a macro used from within an action body. b) I''ve added a new Rfc1918 macro that has the following body: ---------------------------------------------------------------------------- #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT(S) PORT(S) DEST LIMIT GROUP FORMAT 2 PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 \ DEST PARAM SOURCE DEST - - -\ 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE ----------------------------------------------------------------------------- This macro faithfully reproduces the behavior of ''norfc1918'' when used as shown in my earlier mail. Note: ''FORMAT 2'' indicates that the macro has the ORIGINAL DEST column inserted between the SOURCE PORT(S) and RATE LIMIT columns. I took that approach so that the column would be in its familiar place (as in the rules file). c) The ''norfc1918'' option is deprecated for use with Shorewall-perl. Alex: This macro does not do what you want. You will still have to build your own. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
"Greater is the man who admits his personal shortcomings than the man who boasts to all assembled his superiority and accomplishments in matters of station and profession." --Julius Caesar Dignity is restored! On Thu, 2008-03-27 at 16:18 -0700, Tom Eastep wrote:> Tom Eastep wrote: > > alex wrote: > >> Dear Tom, thank you for your detail answer but in my configuration > >> (with Shorewall-4.1.6) ONLY one configuration work such as i want - > >> > > > > Then please use it. I don''t want to hear about this topic again. > > My apologies to Alex and the list. I should have cooled down before responding. > > The reason that the macro didn''t work properly is because it placed RFC1918 > addresses in the DEST column rather than in the ORIGINAL DEST column (which > is essentially what the ''norfc1918'' option does). > > For 4.1.7, I''ve taken the following steps: > > a) The macro file layout has been extended to include an ORIGINAL DEST > column. This was requested earlier. Note that ORIGINAL DEST may not be > specified in a macro used from within an action body. > > b) I''ve added a new Rfc1918 macro that has the following body: > ---------------------------------------------------------------------------- > #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ > # PORT(S) PORT(S) DEST LIMIT GROUP > FORMAT 2 > PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 \ > DEST > PARAM SOURCE DEST - - -\ > 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 > #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE > ----------------------------------------------------------------------------- > This macro faithfully reproduces the behavior of ''norfc1918'' when used as > shown in my earlier mail. > > Note: ''FORMAT 2'' indicates that the macro has the ORIGINAL DEST column > inserted between the SOURCE PORT(S) and RATE LIMIT columns. > I took that approach so that the column would be in its familiar > place (as in the rules file). > > c) The ''norfc1918'' option is deprecated for use with Shorewall-perl. > > Alex: This macro does not do what you want. You will still have to build > your own. > > -Tom > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It''s the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> Tom Eastep wrote: >> alex wrote: >>> Dear Tom, thank you for your detail answer but in my configuration >>> (with Shorewall-4.1.6) ONLY one configuration work such as i want - >>> >> >> Then please use it. I don't want to hear about this topic again. > > My apologies to Alex and the list. I should have cooled down before >responding. > > The reason that the macro didn't work properly is because it placed >RFC1918 addresses in the DEST column rather than in the ORIGINAL DEST >column (which is essentially what the 'norfc1918' option does). > >For 4.1.7, I've taken the following steps: > > a) The macro file layout has been extended to include an ORIGINAL DEST > column. This was requested earlier. Note that ORIGINAL DEST may not be > specified in a macro used from within an action body. > > b) I've added a new Rfc1918 macro that has the following body: > ---------------------------------------------------------------------------- > #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ > # PORT(S) PORT(S) DEST LIMIT GROUP >FORMAT 2 > PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 \ > DEST > PARAM SOURCE DEST - - -\ > 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 > #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE > ----------------------------------------------------------------------------- > This macro faithfully reproduces the behavior of 'norfc1918' when used >as > shown in my earlier mail. > > Note: 'FORMAT 2' indicates that the macro has the ORIGINAL DEST column > inserted between the SOURCE PORT(S) and RATE LIMIT columns. > I took that approach so that the column would be in its familiar > place (as in the rules file). > > c) The 'norfc1918' option is deprecated for use with Shorewall-perl. > > Alex: This macro does not do what you want. You will still have to build >your own.I am very obliged to you Tom. I understand that you make very BIG work and very busy. But i really think that RFC1918 theme useful for many people and want to help to make it clear and easy in Shorewall (and bugfree of course). Thank you VERY MUCH for your help and excellent work. Shorewall REALLY make iptables (and not only iptables) much more easy. Alex ---- Я тут! Найди своих друзей и знакомых на TUT.BY! http://i.tut.by/ ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
alex wrote:> > I am very obliged to you Tom. I understand that you make very BIG work > and very busy. But i really think that RFC1918 theme useful for many > people and want to help to make it clear and easy in Shorewall (and bugfree > of course).You are welcome, Alex. Using iptables for RFC1918 filtration really isn''t the best approach in many cases. It''s generally better to null-route the RFC 1918 ranges: ip route add unreachable 10.0.0.0/8 ip route add unreachable 172.16.0.0/8 ip route add unreachable 192.168.0.0/16 and enable route filtering on your external interface(s). This approach is not without its hazards though. Consider if you were a customer of an ISP who uses RFC 1918 addresses for its DHCP servers. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
On Fri, Mar 28, 2008 at 06:45:13AM -0700, Tom Eastep wrote:> Using iptables for RFC1918 filtration really isn''t the best approach in > many cases. It''s generally better to null-route the RFC 1918 ranges: > > ip route add unreachable 10.0.0.0/8 > ip route add unreachable 172.16.0.0/8 > ip route add unreachable 192.168.0.0/16 > > and enable route filtering on your external interface(s). > > This approach is not without its hazards though. Consider if you were a > customer of an ISP who uses RFC 1918 addresses for its DHCP servers.Although that is trivially fixed by adding specific routes for the addresses of those servers. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Andrew Suffield wrote:> On Fri, Mar 28, 2008 at 06:45:13AM -0700, Tom Eastep wrote: >> >> This approach is not without its hazards though. Consider if you were a >> customer of an ISP who uses RFC 1918 addresses for its DHCP servers. > > Although that is trivially fixed by adding specific routes for the > addresses of those servers.Of course. But I''m reluctant to provide a feature for adding those routes because I suspect that it would increase the support load significantly. There seems to be a general lack of understanding of addressing and routing and the kernel''s bizarrely worded Martian reporting doesn''t help make problem diagnosis any easier. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> I am very obliged to you Tom. I understand that you make very BIG work >> and very busy. But i really think that RFC1918 theme useful for many >> people and want to help to make it clear and easy in Shorewall (and >>bugfree >> of course). > > You are welcome, Alex. > > Using iptables for RFC1918 filtration really isn't the best approach in >many cases. It's generally better to null-route the RFC 1918 ranges: > > ip route add unreachable 10.0.0.0/8 > ip route add unreachable 172.16.0.0/8 > ip route add unreachable 192.168.0.0/16 > > and enable route filtering on your external interface(s). > > This approach is not without its hazards though. Consider if you were a >customer of an ISP who uses RFC 1918 addresses for its DHCP servers.Thank you very much for help Tom. I made follow: 1. add options 'routefilter' and 'logmartians' for external interface in 'interfaces' file 2. add your lines above to 'init' file (i create it self) in Shorewall config directory (only change 172.16.0.0/8 to 172.16.0.0/12) 3. Comment out my rfc1918 rule in 'rules' file. Restart Shorewall and all work OK. Only one remark. Information about 'init' file i found only in releasenotes.txt for 4.1.6 (for setting up 'ifb' module) and i found 'initdone' file in Shorewall config directory and without manfile also. For me not very clearly as it use. Thank you, Alex ---- Я тут! Найди своих друзей и знакомых на TUT.BY! http://i.tut.by/ ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
alex wrote:> Only one remark. Information about ''init'' file i found only in > releasenotes.txt for 4.1.6 (for setting up ''ifb'' module) and i found > ''initdone'' file in Shorewall config directory and without manfile also. > For me not very clearly as it use.http://www.shorewall.net/shorewall_extension_scripts.htm -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Hello, This is small feature request. I am currently running Shorewall 4.0.8 on SLES 10 sp1, Opensuse 10.3, and Ubuntu 6.06-7.04. The Webmin macro currently looks like PARAM - - 10000 tcp, which works great for standard web access. When using the clustering feature of webmin it requires the use of ports 10000-10100 tcp to make stateful, or "fast", RPC connections. Reference: http://doxfer.com/Webmin/WebminServersIndex I would like to request that this macro be modified to look like PARAM - - 10000-10100 tcp for future releases. This would allow upgrades to happen via scripting without modification to the rules file or the Webmin macro. Thank you for your time and consideration, - Jared ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Jared Trog wrote:> This is small feature request. I am currently running Shorewall 4.0.8 > on SLES 10 sp1, Opensuse 10.3, and Ubuntu 6.06-7.04. The Webmin macro > currently looks like > > PARAM - - 10000 tcp, > > which works great for standard web access. When using the clustering > feature of webmin it requires the use of ports 10000-10100 tcp to make > stateful, or "fast", RPC connections. Reference: http://doxfer.com/Webmin/WebminServersIndex > > I would like to request that this macro be modified to look like > > PARAM - - 10000-10100 tcp > > for future releases. This would allow upgrades to happen via scripting > without modification to the rules file or the Webmin macro.Unfortunately, that would break configurations that do the following: Webmin/DNAT net loc:192.168.1.3 DNAT net loc:192.168.1.4 tcp 10001 DNAT net loc:192.168.1.5 tcp 10002 If you want the Webmin macro to do that, copy it to /etc/shorewall and modify your copy. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
On Fri, Mar 28, 2008 at 12:42:14PM -0700, Tom Eastep wrote:> If you want the Webmin macro to do that, copy it to /etc/shorewall and > modify your copy.Or just write out the line in full in your rules file. I''ve never been very impressed with one-line macros, they don''t really accomplish anything that /etc/services doesn''t already do. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Andrew Suffield wrote:> > Or just write out the line in full in your rules file. I''ve never been > very impressed with one-line macros, they don''t really accomplish > anything that /etc/services doesn''t already do.I never use them either. But I see a lot of this sort of thing from people who use /etc/services without having any other clues: ACCEPT net fw tcp 21 ACCEPT net fw udp 21 Of course these same users are also likely to include: ACCEPT net fw tcp 20 ACCEPT net fw udp 20 Ignorance of how things work is rampant... -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> Using iptables for RFC1918 filtration really isn't the best approach in >>many cases. It's generally better to null-route the RFC 1918 ranges: >> >> ip route add unreachable 10.0.0.0/8 >> ip route add unreachable 172.16.0.0/8 >> ip route add unreachable 192.168.0.0/16 >> >> and enable route filtering on your external interface(s). >> >> This approach is not without its hazards though. Consider if you were a >>customer of an ISP who uses RFC 1918 addresses for its DHCP servers. > > Thank you very much for help Tom. > I made follow: > > 1. add options 'routefilter' and 'logmartians' for external interface > in 'interfaces' file > 2. add your lines above to 'init' file (i create it self) in Shorewall > config directory (only change 172.16.0.0/8 to 172.16.0.0/12)Sorry Tom but for this configuration i have one question. Where i must to insert 'ip route del unreachable ...' commands? I try 'stop' and 'stopped' files but they work for 'shorewall stop' but not for 'shorewall restart'. When i run 'shorewall restart' i see messages: ... Processing /etc/shorewall/init ... RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists ... Therefore i make conclusion that 'stop'/'stopped' don't work in this case. Thank you, Alex ---- Доставка на дом и в офис пиццы, суши, шашлыка, напитков круглосуточно. Закажи сейчас! http://www.pizza.by (017) 266-35-07, (029) 690-93-93, 555-93-93 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
> > Or just write out the line in full in your rules file. I''ve never been > > very impressed with one-line macros, they don''t really accomplish > > anything that /etc/services doesn''t already do. > > I never use them either. But I see a lot of this sort of thing from people > who use /etc/services without having any other clues: > > ACCEPT net fw tcp 21 > ACCEPT net fw udp 21 > > Of course these same users are also likely to include: > > ACCEPT net fw tcp 20 > ACCEPT net fw udp 20 > > Ignorance of how things work is rampant...trying to avoid ignorance here, are you saying that the above rules are bad? Is this: ACCEPT serv ext tcp ftp Different from this: ACCEPT serv ext tcp 21 ? BB ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Brad Bendily wrote:>> > Or just write out the line in full in your rules file. I''ve never been >> > very impressed with one-line macros, they don''t really accomplish >> > anything that /etc/services doesn''t already do. >> >> I never use them either. But I see a lot of this sort of thing from people >> who use /etc/services without having any other clues: >> >> ACCEPT net fw tcp 21 >> ACCEPT net fw udp 21 >> >> Of course these same users are also likely to include: >> >> ACCEPT net fw tcp 20 >> ACCEPT net fw udp 20 >> >> Ignorance of how things work is rampant... > > trying to avoid ignorance here, are you saying that the above rules are bad?Three of them are. FTP uses TCP exclusively, so the two UDP rules are senseless. And FTP uses port 20 as the SOURCE port for new active-mode connections, so listing it in the DEST PORT(S) column is also silly. There are reasons to list it in the SOURCE PORT(S) column, even when using the FTP helpers; see http://www.shorewall.net/FTP.html> > Is this: > ACCEPT serv ext tcp ftp > > Different from this: > ACCEPT serv ext tcp 21They are the same on any well-behaved system. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
On Mon, Mar 31, 2008 at 08:07:35AM -0700, Tom Eastep wrote:> Brad Bendily wrote: >>> > Or just write out the line in full in your rules file. I''ve never been >>> > very impressed with one-line macros, they don''t really accomplish >>> > anything that /etc/services doesn''t already do. >>> >>> I never use them either. But I see a lot of this sort of thing from people >>> who use /etc/services without having any other clues: >>> >>> ACCEPT net fw tcp 21 >>> ACCEPT net fw udp 21 >>> >>> Of course these same users are also likely to include: >>> >>> ACCEPT net fw tcp 20 >>> ACCEPT net fw udp 20 >>> >>> Ignorance of how things work is rampant... >> >> trying to avoid ignorance here, are you saying that the above rules are bad? > > Three of them are. FTP uses TCP exclusively, so the two UDP rules are > senseless. And FTP uses port 20 as the SOURCE port for new active-mode > connections, so listing it in the DEST PORT(S) column is also silly.UDP 21 is actually the common port for the obsolete (and resoundingly stupid) FSP. Not that anybody should be using it. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Ahh, yes, I didn''t even think about the udp part. Of course I don''t have udp rules for my ftp rules. On Mon, Mar 31, 2008 at 10:17 AM, Andrew Suffield <asuffield@suffields.me.uk> wrote:> On Mon, Mar 31, 2008 at 08:07:35AM -0700, Tom Eastep wrote: > > Brad Bendily wrote: > >>> > Or just write out the line in full in your rules file. I''ve never been > >>> > very impressed with one-line macros, they don''t really accomplish > >>> > anything that /etc/services doesn''t already do. > >>> > >>> I never use them either. But I see a lot of this sort of thing from people > >>> who use /etc/services without having any other clues: > >>> > >>> ACCEPT net fw tcp 21 > >>> ACCEPT net fw udp 21 > >>> > >>> Of course these same users are also likely to include: > >>> > >>> ACCEPT net fw tcp 20 > >>> ACCEPT net fw udp 20 > >>> > >>> Ignorance of how things work is rampant... > >> > >> trying to avoid ignorance here, are you saying that the above rules are bad? > > > > Three of them are. FTP uses TCP exclusively, so the two UDP rules are > > senseless. And FTP uses port 20 as the SOURCE port for new active-mode > > connections, so listing it in the DEST PORT(S) column is also silly. > > UDP 21 is actually the common port for the obsolete (and resoundingly > stupid) FSP. Not that anybody should be using it. > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It''s the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >-- Have Mercy & Say Yeah ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
alex wrote:>>> Using iptables for RFC1918 filtration really isn''t the best approach in >>> many cases. It''s generally better to null-route the RFC 1918 ranges: >>> >>> ip route add unreachable 10.0.0.0/8 >>> ip route add unreachable 172.16.0.0/8 >>> ip route add unreachable 192.168.0.0/16 >>> >>> and enable route filtering on your external interface(s). >>> >>> This approach is not without its hazards though. Consider if you were a >>> customer of an ISP who uses RFC 1918 addresses for its DHCP servers. >> Thank you very much for help Tom. >> I made follow: >> >> 1. add options ''routefilter'' and ''logmartians'' for external interface >> in ''interfaces'' file >> 2. add your lines above to ''init'' file (i create it self) in Shorewall >> config directory (only change 172.16.0.0/8 to 172.16.0.0/12) > > Sorry Tom but for this configuration i have one question. Where i > must to insert ''ip route del unreachable ...'' commands? I try ''stop'' > and ''stopped'' files but they work for ''shorewall stop'' but not for > ''shorewall restart''. When i run ''shorewall restart'' i see messages: > > ... > Processing /etc/shorewall/init ... > RTNETLINK answers: File exists > RTNETLINK answers: File exists > RTNETLINK answers: File exists > ... > > Therefore i make conclusion that ''stop''/''stopped'' don''t work in > this case.The ''stop'' and ''stopped'' scripts are not run by the ''restart'' command. ''restart'' is exactly the same command as ''start''. Rather than ''ip route add'' use ''ip route replace'' which will add the route if it doesn''t exist but will be silent if the route is already there. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace