I''m beginning to think again about what will be different in 2.0. Here are some thoughts. a) User-defined actions will be emphasized. - A library of actions will be available with names such as: AcceptSSH AcceptDNS DropWindows (drops all SMB noise) DropBroadcasts (Silently drop all Broadcast traffic) ... The possibilities are nearly endless but should make configuration easier (at the expense of a less efficient ruleset). - The ability to specify a user-defined action as a policy - The samples will have customized policy actions. For example, SMB will be silently dropped from the net but rejected from local networks. b) The common.def file and /etc/shorewall/common will disappear along with /etc/shorewall/icmpdef. c) Specific tunnel support disappears to be replaced with generic tunnels and examples/documentation. d) All ''unclean'' support will be removed. f) Shorewall will get out of the routing business. This means that the HAVEROUTE column in /etc/shorewall/proxyarp will be removed and the behavior will be like HAVEROUTE=Yes. g) NAT_BEFORE_RULES disappears and the behavior will be like NAT_BEFORE_RULES="No". Comments and suggestions welcome. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> I''m beginning to think again about what will be different in 2.0. Here > are some thoughts. > ... > b) The common.def file and /etc/shorewall/common will disappear along with > /etc/shorewall/icmpdef.I presume the tasks will be taken over by some sort of default custom actions?> ... > d) All ''unclean'' support will be removed.Curious as to why this is so. Is it ineffective in its current form? Is the task being managed by the kernel in future versions?> ... > g) NAT_BEFORE_RULES disappears and the behavior will be like > NAT_BEFORE_RULES="No".Will that have any implications for rule compatibility?> Comments and suggestions welcome.One thing i''d like to see is RFC1918 egress filtering. All that would be required, i think, is to use the RFC1918 chain (or a variation on it) in the forward & output chains. I''ve been planning to have a go at it myself, but i''ve not had the leisure yet. -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20040112/58f0bc57/attachment.bin
On Mon, 12 Jan 2004, Paul Gear wrote:> Tom Eastep wrote: > > I''m beginning to think again about what will be different in 2.0. Here > > are some thoughts. > > ... > > b) The common.def file and /etc/shorewall/common will disappear along with > > /etc/shorewall/icmpdef. > > I presume the tasks will be taken over by some sort of default custom > actions? >Exactly.> > ... > > d) All ''unclean'' support will be removed. > > Curious as to why this is so. Is it ineffective in its current form? > Is the task being managed by the kernel in future versions? >The underlying kernel functionality *does not exist* in the 2.6 kernels.> > ... > > g) NAT_BEFORE_RULES disappears and the behavior will be like > > NAT_BEFORE_RULES="No". > > Will that have any implications for rule compatibility? >There is the possibility that people have rules which don''t do anything on 1.* Shorewall but that will do DNAT on 2.*.> > Comments and suggestions welcome. > > One thing i''d like to see is RFC1918 egress filtering. All that would > be required, i think, is to use the RFC1918 chain (or a variation on it) > in the forward & output chains.You mean that you want to ensure that you aren''t sending packets with an RFC1918 source address? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> ... >>>... >>>g) NAT_BEFORE_RULES disappears and the behavior will be like >>> NAT_BEFORE_RULES="No". >> >>Will that have any implications for rule compatibility? >> > > > There is the possibility that people have rules which don''t do anything on > 1.* Shorewall but that will do DNAT on 2.*.Can you give an example? I''m struggling to conceive how that could work...>>>Comments and suggestions welcome. >> >>One thing i''d like to see is RFC1918 egress filtering. All that would >>be required, i think, is to use the RFC1918 chain (or a variation on it) >>in the forward & output chains. > > > You mean that you want to ensure that you aren''t sending packets with an > RFC1918 source address?Yes. I also think it would be an easy way to limit the internal hosts which can masq to the Internet. e.g. I use 10.* internally, but i only want 10.1.200.0/24 to have access to the Internet. So i put that in the masq file and cut out the routing of all other 10.0.0.0/8 addresses by putting an RFC1918 filter on the output. -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20040112/313f8521/attachment.bin
On Sun, 2004-01-11 at 14:23, Tom Eastep wrote:> On Mon, 12 Jan 2004, Paul Gear wrote: > > One thing i''d like to see is RFC1918 egress filtering. All that would > > be required, i think, is to use the RFC1918 chain (or a variation on it) > > in the forward & output chains. > > You mean that you want to ensure that you aren''t sending packets with an > RFC1918 source address?Tom, I think he is talking about egress filtering on border routers. Egress Filtering http://www.sans.org/y2k/egress.htm -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
On Mon, 12 Jan 2004, Paul Gear wrote:> > Yes. I also think it would be an easy way to limit the internal hosts > which can masq to the Internet. e.g. I use 10.* internally, but i only > want 10.1.200.0/24 to have access to the Internet. So i put that in the > masq file and cut out the routing of all other 10.0.0.0/8 addresses by > putting an RFC1918 filter on the output. >But that won''t work. If you invoke the rfc1918 chain in FORWARD, it would block all of the masq traffic! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Sun, 2004-01-11 at 14:55, Mike Noyes wrote:> On Sun, 2004-01-11 at 14:23, Tom Eastep wrote: > > On Mon, 12 Jan 2004, Paul Gear wrote: > > > One thing i''d like to see is RFC1918 egress filtering. All that would > > > be required, i think, is to use the RFC1918 chain (or a variation on it) > > > in the forward & output chains. > > > > You mean that you want to ensure that you aren''t sending packets with an > > RFC1918 source address? > > Tom, > I think he is talking about egress filtering on border routers. > > Egress Filtering > http://www.sans.org/y2k/egress.htmAdditional info: Google string: ISP egress filtering ftp://ftp.rfc-editor.org/in-notes/rfc2827.txt -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
Could you apply RFC1918 to outgoing traffic for the network card on the public side? The internal traffic should already be wrapped by NAT to look like its coming from the public IP right? Mike On Sun, 2004-01-11 at 15:52, Tom Eastep wrote:> On Mon, 12 Jan 2004, Paul Gear wrote: > > > > > Yes. I also think it would be an easy way to limit the internal hosts > > which can masq to the Internet. e.g. I use 10.* internally, but i only > > want 10.1.200.0/24 to have access to the Internet. So i put that in the > > masq file and cut out the routing of all other 10.0.0.0/8 addresses by > > putting an RFC1918 filter on the output. > > > > But that won''t work. If you invoke the rfc1918 chain in FORWARD, it would > block all of the masq traffic! > > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.shorewall.net > https://lists.shorewall.net/mailman/listinfo/shorewall-devel
Would it also be useful to stop non-routeable ports at the firewall for incoming / outgoing traffic as part of the default options? Currently I block 135-139 from going through the firewall either direction. Are these the only "standard" non-routeable ports? Mike On Sun, 2004-01-11 at 15:41, Paul Gear wrote:> Tom Eastep wrote: > > ... > >>>... > >>>g) NAT_BEFORE_RULES disappears and the behavior will be like > >>> NAT_BEFORE_RULES="No". > >> > >>Will that have any implications for rule compatibility? > >> > > > > > > There is the possibility that people have rules which don''t do anything on > > 1.* Shorewall but that will do DNAT on 2.*. > > Can you give an example? I''m struggling to conceive how that could work... > > >>>Comments and suggestions welcome. > >> > >>One thing i''d like to see is RFC1918 egress filtering. All that would > >>be required, i think, is to use the RFC1918 chain (or a variation on it) > >>in the forward & output chains. > > > > > > You mean that you want to ensure that you aren''t sending packets with an > > RFC1918 source address? > > Yes. I also think it would be an easy way to limit the internal hosts > which can masq to the Internet. e.g. I use 10.* internally, but i only > want 10.1.200.0/24 to have access to the Internet. So i put that in the > masq file and cut out the routing of all other 10.0.0.0/8 addresses by > putting an RFC1918 filter on the output. > > -- > Paul > http://paulgear.webhop.net
On Sun, 11 Jan 2004, Mike Morrell wrote:> Could you apply RFC1918 to outgoing traffic for the network card on > the public side? The internal traffic should already be wrapped by NAT > to look like its coming from the public IP right? >We could do that but it would be a different chain from the existing rfc1918 chain because it would have to be applied out of the POSTROUTING nat chain. I really dislike doing filtering in the nat table; for one thing, the REJECT target can''t be used in that table. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Sun, 11 Jan 2004, Mike Morrell wrote:> Would it also be useful to stop non-routeable ports at the firewall > for incoming / outgoing traffic as part of the default options? > Currently I block 135-139 from going through the firewall either > direction. Are these the only "standard" non-routeable ports? >I haven''t a clue what you are talking about. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Sun, 11 Jan 2004, Tom Eastep wrote:> On Sun, 11 Jan 2004, Mike Morrell wrote: > > > Would it also be useful to stop non-routeable ports at the firewall > > for incoming / outgoing traffic as part of the default options? > > Currently I block 135-139 from going through the firewall either > > direction. Are these the only "standard" non-routeable ports? > > > > I haven''t a clue what you are talking about. >What I''m saying is that I know of no concept of "non-routable ports". I agree that in many firewall applications you don''t want SMB moise to be passed through and that the sample configurations should silently block outgoing SMB. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> I''m beginning to think again about what will be different in 2.0. Here > are some thoughts.I''d like to ask for IPv6 support, and second the suggestion for RFC1918 egress filtering. --eric
On Mon, 12 Jan 2004, Eric E. Bowles wrote:> > I''m beginning to think again about what will be different in 2.0. Here > > are some thoughts. > > I''d like to ask for IPv6 support,Shorewall has already been adapted for IPV6 in the form of 6wall.> and second the suggestion for RFC1918 egress filtering.Grumble.... :-) -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote: | I''m beginning to think again about what will be different in 2.0. Here | are some thoughts. What I''ve always thought would be interesting, albeit maybe too difficult for 2.0, is something similar to a init.d directory. Maybe this can already be done, I''ve not delved too much into the possibility (and I converted the docs?...lol) The setup would be like: /etc/shorewall/rules.d/ With configs numbered in the order they should be added: 00local-servers 01dmz-servers 02samba-rules 03dns-rules etc. With that, certain levels of shorewall startups could exist: shorewall start servers shorewall stop samba-rules etc. This incremental parsing would add flexibility to the setup. However, this is just my idea of what I''d like to see. Maybe it''s a bit too early for such an overhaul in code ;-) Users could share their startup files. A bit like adding a plugin function I suppose. My 2 cents Tom. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAAhocNQvzkbg+TpsRAhujAJ4pgTVYAnDcLr8XHHtJ0P9GQyH+hACfSz49 MkU10CcrUcEF6XNGPCm3H5g=wYtA -----END PGP SIGNATURE-----
> Shorewall has already been adapted for IPV6 in the form of 6wall.Yes, I''m aware of that, but it would be nice if its functionality could be consolidated into a single Shorewall distribution. --eric
> Maybe this can already be done, I''ve not delved too much into the > possibility (and I converted the docs?...lol) > > The setup would be like: > > /etc/shorewall/rules.d/ > > With configs numbered in the order they should be added: > > 00local-servers > 01dmz-servers > 02samba-rules > 03dns-rules > etc.I''d like something like this too. Simon
On Sunday 11 January 2004 11:10 pm, Simon Matter wrote:> > Maybe this can already be done, I''ve not delved too much into the > > possibility (and I converted the docs?...lol) > > > > The setup would be like: > > > > /etc/shorewall/rules.d/ > > > > With configs numbered in the order they should be added: > > > > 00local-servers > > 01dmz-servers > > 02samba-rules > > 03dns-rules > > etc. > > I''d like something like this too.I believe that this is a totally new product rather than an evolutionary change to Shorewall. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Sunday 11 January 2004 07:53 pm, Eric E. Bowles wrote:> > Shorewall has already been adapted for IPV6 in the form of 6wall. > > Yes, I''m aware of that, but it would be nice if its functionality > could be consolidated into a single Shorewall distribution.By keeping them separate, both products are much cleaner than they would be if we tried to glue them together. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Friday 09 January 2004 05:34 pm, Tom Eastep wrote:> > c) Specific tunnel support disappears to be replaced with generic tunnels > and examples/documentation. >I''ve reconsidered this one -- while I don''t intend to add any new tunnel types in the future, I think I''ll leave this as it is. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote:>>> 00local-servers >>> 01dmz-servers >>> 02samba-rules >>> 03dns-rules >>> etc. >> >>I''d like something like this too. > > > I believe that this is a totally new product rather than an evolutionary > change to Shorewall.The only justification I can make is that my rules file here has grown quite large. A pool of rule files would be easier on the brain. I could prob hack the code to do this, but I thought I''d throw the idea out there. - -- "If at first you don''t succeed, destroy all evidence that you tried." Paul <snafu@forkbomb.dhs.org> BLOG: http://forkbomb.dhs.org/bs/ GPG Key: http://forkbomb.dhs.org/bs/snafu.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAAwLsNQvzkbg+TpsRAhotAJ9sVevezpPa4RQQdZ7eP2xAnYR9EgCfX4kJ Fk5aUIiFVGo6TZwUYdENyzU=+oLX -----END PGP SIGNATURE-----
Tom Eastep wrote:> On Sun, 11 Jan 2004, Mike Morrell wrote: > > >> Could you apply RFC1918 to outgoing traffic for the network card on >>the public side? The internal traffic should already be wrapped by NAT >>to look like its coming from the public IP right? >> > > > We could do that but it would be a different chain from the existing > rfc1918 chain because it would have to be applied out of the POSTROUTING > nat chain. I really dislike doing filtering in the nat table; for one > thing, the REJECT target can''t be used in that table.Is there any other way to prevent outgoing traffic from RFC1918 addresses? I know a lot of people consider it irresponsible to allow RFC1918 out of your network, and i don''t want to be that. BTW, thinking about this a little, i''d really like to prevent outgoing traffic both *from* and *to* RFC1918 addresses. The former would prevent local traffic leaving that i don''t want to leave, and the latter would prevent replies to other badly-configured hosts on interfaces that can''t have the norfc1918 option for whatever reason. -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20040113/961248d2/attachment.bin
Tom Eastep wrote:> On Mon, 12 Jan 2004, Paul Gear wrote: > > >>Yes. I also think it would be an easy way to limit the internal hosts >>which can masq to the Internet. e.g. I use 10.* internally, but i only >>want 10.1.200.0/24 to have access to the Internet. So i put that in the >>masq file and cut out the routing of all other 10.0.0.0/8 addresses by >>putting an RFC1918 filter on the output. >> > > > But that won''t work. If you invoke the rfc1918 chain in FORWARD, it would > block all of the masq traffic!Obviously i don''t want to do that. Is there a way we can jump into the forward chain after the masq bit? -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20040113/5031a45d/attachment.bin
Tom, [Re: adding IPv6 support]> By keeping them separate, both products are much cleaner than they would > be if we tried to glue them together.That would be true if you''re trying to merge the 6wall and Shorewall source code. But if you''re designing Shorewall 2 from scratch (and I''m not sure if you are), then it would be better if both IPv4 and IPv6 were equally supported from the beginning, for greater consistency of the whole product. With the current situation, 6wall (is it being actively maintained?) will always trail Shorewall 1.X in released features. Understandably, this is also affected by the varying degrees of support between iptables vs. ip6tables. Hopefully, pkttables will unify this some day. --eric
On Tuesday 13 January 2004 04:58 am, Eric E. Bowles wrote:> Tom, > > [Re: adding IPv6 support] > > > By keeping them separate, both products are much cleaner than they would > > be if we tried to glue them together. > > That would be true if you''re trying to merge the 6wall and Shorewall > source code. But if you''re designing Shorewall 2 from scratch (and I''m > not sure if you are),I am not. And IIRC, Eric de Thouars''s original effort at 6wall was to add IPv6 functionality to Shorewall which turned out to be difficult to impossible.> then it would be better if both IPv4 and IPv6 were > equally supported from the beginning, for greater consistency of the whole > product. > > With the current situation, 6wall (is it being actively maintained?) > will always trail Shorewall 1.X in released features. Understandably, > this is also affected by the varying degrees of support between iptables > vs. ip6tables.That is one of the problems -- the other problem is that I used ":" as a separator all over the configuration files which makes parsing IPv4 addresses a real PITA.> Hopefully, pkttables will unify this some day.At which point, I''ll probably let someone else worry about it... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Tue, 2004-01-13 at 02:57, Paul Gear wrote:> BTW, thinking about this a little, i''d really like to prevent outgoing > traffic both *from* and *to* RFC1918 addresses. The former would > prevent local traffic leaving that i don''t want to leave, and the latter > would prevent replies to other badly-configured hosts on interfaces that > can''t have the norfc1918 option for whatever reason.Paul, RFC 1918 isn''t the problem. Egress/Ingress filtering encompasses all addresses not part of the LAN protected by the border router and firewall. All traffic that has an invalid destination (ingress) or origin (egress) should be dropped. http://www.sans.org/y2k/egress.htm ftp://ftp.rfc-editor.org/in-notes/rfc2827.txt ftp://ftp.rfc-editor.org/in-notes/bcp/bcp38.txt -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
On Tue, 2004-01-13 at 10:00, Mike Noyes wrote:> All traffic that has an invalid destination (ingress) or > origin (egress) should be dropped.Correction: All traffic that has an invalid destination or origin should be dropped at the border router. LAN Ingress: Invalid source IP - drop Destination IP not known to be part of the defined LAN - drop LAN Egress: Any IP address not part of the defined LAN - drop -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
On Tuesday 13 January 2004 10:24 am, Mike Noyes wrote:> On Tue, 2004-01-13 at 10:00, Mike Noyes wrote: > > All traffic that has an invalid destination (ingress) or > > origin (egress) should be dropped. > > Correction: > All traffic that has an invalid destination or origin should be dropped > at the border router. > > LAN Ingress: Invalid source IP - drop > Destination IP not known to be part of the defined LAN - > drop > > LAN Egress: Any IP address not part of the defined LAN - dropShorewall can currently be configured to do all of this. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Tue, 2004-01-13 at 12:49, Tom Eastep wrote:> On Tuesday 13 January 2004 10:24 am, Mike Noyes wrote: > > All traffic that has an invalid destination or origin should be dropped > > at the border router. > > > > LAN Ingress: Invalid source IP - drop > > Destination IP not known to be part of the defined LAN - > > drop > > > > LAN Egress: Any IP address not part of the defined LAN - drop > > Shorewall can currently be configured to do all of this.Tom, Thanks for the clarification. Why are people requesting egress filtering then? Are they just looking for an easy way to configure this? -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
On Tuesday 13 January 2004 01:07 pm, Mike Noyes wrote:> On Tue, 2004-01-13 at 12:49, Tom Eastep wrote: > > On Tuesday 13 January 2004 10:24 am, Mike Noyes wrote: > > > All traffic that has an invalid destination or origin should be dropped > > > at the border router. > > > > > > LAN Ingress: Invalid source IP - drop > > > Destination IP not known to be part of the defined LAN - > > > drop > > > > > > LAN Egress: Any IP address not part of the defined LAN - drop > > > > Shorewall can currently be configured to do all of this. > > Tom, > Thanks for the clarification. Why are people requesting egress filtering > then? Are they just looking for an easy way to configure this?Yes -- the original request was simply for egress RFC1918 filtering. The OP (Paul Gear, IIRC) uses Shorewall to protect some system that are allowed internet access and some that aren''t. He currently enforces this by only masquerading those systems that are allowed net access and now wants a quick and dirty way to prohibit the other RFC1918 systems from sending packets to the net. Clearly this can be done by creating multiple local zones with different policies toward the net -- but that''s not as easy (for him) as specifying an option on an interface in /etc/shorewall/interfaces. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Tue, 2004-01-13 at 13:22, Tom Eastep wrote:> On Tuesday 13 January 2004 01:07 pm, Mike Noyes wrote: > > Thanks for the clarification. Why are people requesting egress filtering > > then? Are they just looking for an easy way to configure this? > > Yes -- the original request was simply for egress RFC1918 filtering. The OP > (Paul Gear, IIRC) uses Shorewall to protect some system that are allowed > internet access and some that aren''t. He currently enforces this by only > masquerading those systems that are allowed net access and now wants a quick > and dirty way to prohibit the other RFC1918 systems from sending packets to > the net. > > Clearly this can be done by creating multiple local zones with different > policies toward the net -- but that''s not as easy (for him) as specifying an > option on an interface in /etc/shorewall/interfaces.Tom, Do you think ingress & egress filtering howto is a solution to Paul''s request? -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
Tom Eastep wrote:> ... >>Tom, >>Thanks for the clarification. Why are people requesting egress filtering >>then? Are they just looking for an easy way to configure this? > > > Yes -- the original request was simply for egress RFC1918 filtering. The OP > (Paul Gear, IIRC) uses Shorewall to protect some system that are allowed > internet access and some that aren''t. He currently enforces this by only > masquerading those systems that are allowed net access and now wants a quick > and dirty way to prohibit the other RFC1918 systems from sending packets to > the net. > > Clearly this can be done by creating multiple local zones with different > policies toward the net -- but that''s not as easy (for him) as specifying an > option on an interface in /etc/shorewall/interfaces.I''m not looking for a quick & dirty solution. (I am looking for an easy solution, since that''s what shorewall''s all about: making iptables easy.) I already define an ethX:0.0.0.0/0 zone as a catch-all that has no access, and try to keep my rules as tight as possible. The reason i asked about the feature is: 1. In the case where i use a large subnet internally, but only want a small portion of it able to be access the Net via NAT, i need a way of ensuring that no non-masqed RFC1918 traffic is routed. 2. In the case where a connection comes in from an RFC1918 address on an interface where the norfc1918 option is not set, i want to have a way of specifying that traffic should not be sent out TO those addresses. Without writing custom start code, i''m not aware of any way to achieve this. -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20040114/25a2a01f/attachment.bin
Tom; I have been thinking how it might be possible to add support to Shorewall for new Netfilter features without having to change Shorewall every time a new feature becomes available. To implement this a new file /etc/shorewall/extensions needs to be created. It would contain two fields: Extension - A unique name given to the feature. This will be referenced in the /etc/shorewall/rules. Parameters - The iptables parameters required to support the new feature. The /etc/shorewall/rules file would have an extra field, Extension. This would contain the name of an entry in /etc/shorewall/exetensions. On processing the Extension field, Shorewall would add the corresponding Parameters from /etc/shorewall/extensions to the generated iptables rule. As an example, the following code would silently drop a ping of length 92 bytes. /etc/shorewall/extensions Extension Parameters LEN92 -m length --length 92 /etc/shorewall/rules Action Src Dest Proto Dst-Prt Src-Prt Orig-Dst Rate User Extension DROP wan fw icmp 8 - - - - LEN92 A more flexible approach would be to pass the length over from the rule. /etc/shorewall/extensions Extension Parameters LEN -m length --length $1 /etc/shorewall/rules Action Src Dest Proto Dst-Prt Src-Prt Orig-Dst Rate User Extension DROP wan fw icmp 8 - - - - LEN(92) Variable $1 being expanded before the parameters are inserted into the rule. I don''t know how easy this would be to implement or how useful it would be to other Shorewall users. Regards Steven.