Although Shorewall provides safeguards against it, people seem to regularly shoot themselves in the foot when doing remote system administration. I''ve been thinking about this problem and wonder if a change to the way that "shorewall stop" behaves might help. Today, "shorewall stop" stops all traffic except to/from those destinations listed in /etc/shorewall/routestopped. An alternative behavior would be: a) Established connections and their related traffic would still be enabled. This means that "shorewall stop" wouldn''t kill the ssh session from which you inadvertently issued the command.On the other hand, all other established connections would continue to work as well. b) All connection attempts FROM the firewall would be allowed. This would enable, for example, DNS lookups. c) New connections would still be accepted to/from those hosts listed in /etc/shorewall/routestopped. Comments? -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> Although Shorewall provides safeguards against it, people seem to > regularly shoot themselves in the foot when doing remote system > administration. I''ve been thinking about this problem and wonder if a > change to the way that "shorewall stop" behaves might help. > > Today, "shorewall stop" stops all traffic except to/from those > destinations listed in /etc/shorewall/routestopped. An alternative > behavior would be: > > a) Established connections and their related traffic would still be > enabled. This means that "shorewall stop" wouldn''t kill the ssh session > from which you inadvertently issued the command.On the other hand, all > other established connections would continue to work as well.I''m not sure I like this.> > b) All connection attempts FROM the firewall would be allowed. This > would enable, for example, DNS lookups.Seems not bad to me.> > c) New connections would still be accepted to/from those hosts listed in > /etc/shorewall/routestopped.Why not add additional parameters to /etc/shorewall/routestopped so you can also define protocols and ports for which you want to allow new connections. Maybe many people would like to add a internet interface restricted to tcp/22 to make at least ssh possible. Simon> > Comments? > -Tom > -- > Tom Eastep \ Shorewall - iptables made easy > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.shorewall.net > http://lists.shorewall.net/mailman/listinfo/shorewall-devel >
On Fri, 2003-07-25 at 09:53, Simon Matter wrote:> > Why not add additional parameters to /etc/shorewall/routestopped so you > can also define protocols and ports for which you want to allow new > connections. Maybe many people would like to add a internet interface > restricted to tcp/22 to make at least ssh possible. >I thought of that also. I think it needs to be combined with "b)" in my original proposal though. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> On Fri, 2003-07-25 at 09:53, Simon Matter wrote: > >> >> Why not add additional parameters to /etc/shorewall/routestopped so you >> can also define protocols and ports for which you want to allow new >> connections. Maybe many people would like to add a internet interface >> restricted to tcp/22 to make at least ssh possible. >> > > I thought of that also. I think it needs to be combined with "b)" in my > original proposal though.Exactly, that''s what I meant. I was thinking some time ago whether it was better to rename the actions like this: clear -> stop stop -> panic I''m a long time shorewall user so I know how to use clear but in the beginning I was trapped alot using stop instead of clear. Simon> > -Tom > -- > Tom Eastep \ Shorewall - iptables made easy > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > >
Hello,> > > > Why not add additional parameters to /etc/shorewall/routestopped so > you > > can also define protocols and ports for which you want to allow new > > connections. Maybe many people would like to add a internet > interface > > restricted to tcp/22 to make at least ssh possible. > > > > I thought of that also. I think it needs to be combined with "b)" in > my > original proposal though. > > -TomYes .. Just a tcp 22 connection would suffice inbound from the internet interface (But allowing certain other critical ports "Such as 80 for a webserver" to continue operating would be even better) .. If thats even easy or feasible .. Of course as Tom put it .. Its basically people "Like Me" shooting themselves in the foot. -- Francesca C Smith Lady Linux Internet Services 1801 Bolton Street # 1 Baltimore, MD 21217
On Fri, 2003-07-25 at 10:13, Francesca C. Smith wrote:> > > Yes .. Just a tcp 22 connection would suffice inbound from the internet > interface (But allowing certain other critical ports "Such as 80 for a > webserver" to continue operating would be even better) .. If thats even > easy or feasible .. Of course as Tom put it .. Its basically people > "Like Me" shooting themselves in the foot.The proposed solution will allow ports *to the firewall* to be opened individually; I don''t want to consider doing things like port forwarding while the firewall is stopped. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
As someone that had already got a cab to put a shorewall up back again, I''ve learned through time to put at least my IP address in the routestopped file. anyway, there goes my two cents... shorewall-devel-bounces@lists.shorewall.net wrote on 25/07/2003 13:40:14:> Although Shorewall provides safeguards against it, people seem to > regularly shoot themselves in the foot when doing remote system > administration. I''ve been thinking about this problem and wonder if a > change to the way that "shorewall stop" behaves might help. > > Today, "shorewall stop" stops all traffic except to/from those > destinations listed in /etc/shorewall/routestopped. An alternative > behavior would be: > > a) Established connections and their related traffic would still be > enabled. This means that "shorewall stop" wouldn''t kill the ssh session > from which you inadvertently issued the command.On the other hand, all > other established connections would continue to work as well.I don''t like much this option because, in case of an attack, it would still let the intruder in (or am I wrong?).> > b) All connection attempts FROM the firewall would be allowed. This > would enable, for example, DNS lookups.ok for me...> > c) New connections would still be accepted to/from those hosts listed in > /etc/shorewall/routestopped.ok, but I would like to be able to tell which ports from which hosts it would be allowed. And no FORWARD, please. never. A stopped firewall doesn''t forward anything. ________________________ Eduardo Ferreira Icatu Holding S.A. Supervisor de TI (5521) 3804-8606
Oh .. I use Shorewall on non port forwarded stand-alone stuff like DNS servers and such .. Yes .. and port forwarding rules would not apply to this scenario ... But I agree totally that its a "Keep It Simple" thing Francesca On Fri, 2003-07-25 at 13:38, Tom Eastep wrote:> On Fri, 2003-07-25 at 10:13, Francesca C. Smith wrote: > > > > > > > Yes .. Just a tcp 22 connection would suffice inbound from the internet > > interface (But allowing certain other critical ports "Such as 80 for a > > webserver" to continue operating would be even better) .. If thats even > > easy or feasible .. Of course as Tom put it .. Its basically people > > "Like Me" shooting themselves in the foot. > > The proposed solution will allow ports *to the firewall* to be opened > individually; I don''t want to consider doing things like port forwarding > while the firewall is stopped. > > -Tom-- Francesca C Smith Lady Linux Internet Services 1801 Bolton Street # 1 Baltimore, MD 21217
I wonder if changing the way commands work is a good idea. Adding a new command, safe_stop, to what you describe below might be worthwhile. I generally just install shorewall and leave it alone so I don''t have much experience with the difference between stop and clear, reset, and other option. So, I went to your site and found the page called "Starting/Stopping and Monitoring the Firewall". I know you have lots of documentation, but describing the command "shorewall stop" as "stops the firewall" does not tell me what happens to existing connections. The same for the other commands. In the chart just under the state machine there is a nice, incomplete, list of some of the shorewall commands. Clear is not in the chart. It would be nice if there was a third column that said what happens to existing connections and what happens to new connection attempts. So, I guess what I am saying is that maybe the problem people have with the stop and clear commands have more to do with not fully understanding what happens to their connections when the state is entered. Maybe they don''t quite understand why they would use the state. Expanding the documentation give another opportunity to again point out the routestopped feature. I think shorewall is almost perfect, not to big, not too many features, not too many command options, so I would rather not see an existing command changed. If you really need a new stop option, then maybe create a new command to invoke it. As I was playing with the shorewall command, to see what the list of options on my version, I realized that an expanded build-in help would be nice, and another opportunity to avoid adding a new command: shorewall help stop stop shuts down all existing connections except any to/from routestopped entries use it when .... shorewall help clear clear does something else... use it when you .... I hope these ideas are useful. Thanks, -- Steve Herber herber@thing.com work: 206-221-7262 Security Engineer, UW Medicine, IT Services home: 425-454-2399 On 25 Jul 2003, Tom Eastep wrote:> Although Shorewall provides safeguards against it, people seem to > regularly shoot themselves in the foot when doing remote system > administration. I''ve been thinking about this problem and wonder if a > change to the way that "shorewall stop" behaves might help. > > Today, "shorewall stop" stops all traffic except to/from those > destinations listed in /etc/shorewall/routestopped. An alternative > behavior would be: > > a) Established connections and their related traffic would still be > enabled. This means that "shorewall stop" wouldn''t kill the ssh session > from which you inadvertently issued the command.On the other hand, all > other established connections would continue to work as well. > > b) All connection attempts FROM the firewall would be allowed. This > would enable, for example, DNS lookups. > > c) New connections would still be accepted to/from those hosts listed in > /etc/shorewall/routestopped. > > Comments? > -Tom >
Steve, On Fri, 2003-07-25 at 11:16, Steve Herber wrote:> I wonder if changing the way commands work is a good idea. Adding a > new command, safe_stop, to what you describe below might be worthwhile.I think having two different "stopped" states is a bad idea.> > I generally just install shorewall and leave it alone so I don''t have > much experience with the difference between stop and clear, reset, and > other option. So, I went to your site and found the page called > "Starting/Stopping and Monitoring the Firewall". I know you have lots of > documentation, but describing the command "shorewall stop" as "stops the > firewall" does not tell me what happens to existing connections. The same for > the other commands. In the chart just under the state machine > there is a nice, incomplete, list of some of the shorewall commands. Clear is > not in the chart. It would be nice if there was a third column that said what > happens to existing connections and what happens to new connection attempts.I''ve cleaned it up a bit.> > So, I guess what I am saying is that maybe the problem people have with the stop > and clear commands have more to do with not fully understanding what happens to > their connections when the state is entered. Maybe they don''t quite understand > why they would use the state. Expanding the documentation give another > opportunity to again point out the routestopped feature.I think that like yourself, most users have never seen that page so I don''t have a great deal of enthusiasm for spending time improving it.> > I think shorewall is almost perfect, not to big, not too many features, not too > many command options, so I would rather not see an existing command changed. > If you really need a new stop option, then maybe create a new command to invoke > it.We''re not really talking so much about explicit "shorewall stop" commands as we are the implicit "stop" when an error occurs in one of the other commands.> > As I was playing with the shorewall command, to see what the list of options on > my version, I realized that an expanded build-in help would be nice, and another > opportunity to avoid adding a new command: > > shorewall help stop > stop shuts down all existing connections > except any to/from routestopped entries > use it when .... > > shorewall help clear > clear does something else... > use it when you .... >If someone wants to send me a patch, I''ll merge it and maintain the improved help when I do future changes. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Fri, 2003-07-25 at 10:03, Simon Matter wrote:> > I was thinking some time ago whether it was better to rename the actions > like this: > > clear -> stop > stop -> panic > > I''m a long time shorewall user so I know how to use clear but in the > beginning I was trapped alot using stop instead of clear. >Any change in the names of the commands will have to be deferred to a major release. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Fri, 2003-07-25 at 10:38, Tom Eastep wrote:> On Fri, 2003-07-25 at 10:13, Francesca C. Smith wrote: > > > > > > > Yes .. Just a tcp 22 connection would suffice inbound from the internet > > interface (But allowing certain other critical ports "Such as 80 for a > > webserver" to continue operating would be even better) .. If thats even > > easy or feasible .. Of course as Tom put it .. Its basically people > > "Like Me" shooting themselves in the foot. > > The proposed solution will allow ports *to the firewall* to be opened > individually; I don''t want to consider doing things like port forwarding > while the firewall is stopped. >I''ve spent some time looking at this over the lunch hour and the semantics of the proposal are a little messy: a) To maintain compatibility with existing ''routestopped'' files, when no prototol/port are specified then the interface:addresses are placed in a pool of groups that can freely communicate with each other and with the firewall. b) When a protocol (and optionally a port) are specified, then that protocol[:port] is opened only from the specified host(s) to the firewall. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Fri, 2003-07-25 at 13:24, Tom Eastep wrote:> > > > I''ve spent some time looking at this over the lunch hour and the > semantics of the proposal are a little messy: > > a) To maintain compatibility with existing ''routestopped'' files, when no > prototol/port are specified then the interface:addresses are placed in a > pool of groups that can freely communicate with each other and with the > firewall. > > b) When a protocol (and optionally a port) are specified, then that > protocol[:port] is opened only from the specified host(s) to the > firewall. >Also, the "All connection attempts from the firewall are allowed" part of my original proposal is nonsense unless we have an ESTABLISHED rule for traffic to the firewall; otherwise, replies are blocked :-( -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Fri, 2003-07-25 at 13:29, Tom Eastep wrote:> > Also, the "All connection attempts from the firewall are allowed" part > of my original proposal is nonsense unless we have an ESTABLISHED rule > for traffic to the firewall; otherwise, replies are blocked :-( >In other words, I don''t believe that Simon''s alternative to my original proposal is workable after all. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Fri, 2003-07-25 at 16:50, Paul Gear wrote:> (Resend - for some reason the mailing list won''t accept my messages at > the moment.) > > Tom Eastep wrote: > > Although Shorewall provides safeguards against it, people seem to > > regularly shoot themselves in the foot when doing remote system > > administration. I''ve been thinking about this problem and wonder if a > > change to the way that "shorewall stop" behaves might help. > > ... > > I''ve read through this entire thread, and i think Tom''s second take is > right: the semantics are too hard. > > I have to ask the question: what sort of problem are you trying to > solve?The original post that started this thread was off-list; the OP asked about the viability of an "Are you sure?" prompt in response to "shorewall stop". I got the feeling that an ill-advised "shorewall stop" had resulted in a drive across town at an awkward time of day :-) There are a number of problems associated with adding a prompt so I began to think about how I might go about making the "stopped state" a little more open so that it would not cut off a remote administrator.> Why do people use ''shorewall stop''?It doesn''t need to be an explicit "shorewall stop" -- if one of the other commands like "restart" fails, an implicit "shorewall stop" gets executed. The current design allows people to protect themselves in the case of "restart" by using "try" but there are no such protections available for "add", "reset", "refresh", ...> I personally don''t ever use it.Nor do I -- and it is very infrequently that I find myself needing to do remote administration of my firewall; but then I only have one firewall, it is in my home, and I don''t travel much :-)> The only things i do are start, restart, and clear. I either want > the firewall working, or out of the way totally. However, if i ever do > want the firewall to lock down, i want it to lock down *hard*, and i > wouldn''t want any external (i.e. not on routestopped interfaces) traffic > flow at all, whether from, to, or through the firewall.Those were my feelings when I designed it. Plus, the code to lock down the firewall must be foolproof and errors in configuration files must simply be ignored.> > Having the firewall stopped means different things to different people, > and a ''one size fits all'' command is probably not what you want. So my > suggestion is: > > - deprecate the stop command > > - introduce two new commands, ''restrict'', which is able to be configured > the way people want it (e.g. allow external ssh, allow traffic from the > firewall, allow existing connections); and ''block'', which results in the > present behaviour of stop (or something close to it)This is similar to Steve Herber''s proposal and essentially results in two different "stopped" states; you would call them "restricted" and "blocked". If one is willing to accept that the "restricted" state always allows ESTABLISHED and RELATED packets, then this setup is possible today by using alternate configurations; the "restricted" state is reached by starting a special configuration and "shorewall restrict" is a synonym for "shorewall -c /etc/shorewall.restricted restart". If the restricted state does not accept ESTABLISHED and RELATED packets then the code to implement the restricted state begins to look a lot like Seawall where each rule has to have a companion rule to handle replies (gag). Plus, I get to support parallel rule definition mechanisms for the "started" and "restricted" states. That idea doesn''t appeal to me much. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom: I noticed that you have updated the "Starting/Stopping" web page. It it much more informative. Thanks. I have hacked a version of a help command into my current version and I have a simple questions: Do you want the help text in-line in the shorewall file, like the usage command, or would an external file, /etc/shorewall/help be preferred? The advantage of an external file is two fold. Alternate language text can be supplied without touching the shorewall command file and enhancements to the help command, paging, interactive help, and so on, would not increase the size of the base command. As part of that, if you do want an external file, then we could move the usage message into it also. Finally, if they are in an external file, then short stub help and usage commands could be coded to check for the existence of the external file, complain if not found, and then exec the external file passing in any exit value that you want returned. Other than some of these coding questions, I am working on the text of the messages and I would like to get it into your next version. I just missed the recent release. Do you have any shorewall man pages yet? Thanks, -- Steve Herber herber@thing.com work: 206-221-7262 Security Engineer, UW Medicine, IT Services home: 425-454-2399
Steve, On Sat, 26 Jul 2003 17:14:16 -0700 (PDT), Steve Herber <herber@thing.com> wrote:> > I have hacked a version of a help command into my current version and I > have a simple questions: > > Do you want the help text in-line in the shorewall file, like the usage > command, or would an external file, /etc/shorewall/help be preferred?Let''s go with an external file, /usr/share/shorewall/helptext. Since it won''t be a configuration file, it shouldn''t go into /etc/shorewall.> > As part of that, if you do want an external file, then we could move the > usage message into it also. > > Finally, if they are in an external file, then short stub help and usage > commands could be coded to check for the existence of the external file, > complain if not found, and then exec the external file passing in any > exit > value that you want returned.I think that we should make the helptext file optional -- if it isn''t present, the behavior should be as it is today. I suspect that LEAF users might choose to omit the file.> > Do you have any shorewall man pages yet? >Lorenzo Martignoni has a ''shorewall'' man page that he distributes with the Debian package. I haven''t gotten around to integrating it into the standard distribution (one more thing to update when I change something...). Thanks so much for your help -- I''ll look forward to getting it into the next release. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net