Shorewall users - Dec 2011 - How to install Shorewall on a remote system...

On my first day of installing Shorewall on a remote system I locked myself
out, as advertised in the Quick Start Guides:
http://www.shorewall.net/shorewall_quickstart_guide.htm

*Do not attempt to install Shorewall on a remote system. You are virtually
assured to lock yourself out of that system.*

Luckily the hardware reboot procedure unlocked my system and I went back
into installing Shorewall, after taking some precautions.

* Please put this warning in the Beginners Documentation:
http://www.shorewall.net/GettingStarted.html
This is where I started from and I didn''t see the warning.  (However, I
had
already thought of the possibility of locking myself out, so I took my
chances knowingly).
* Replace the "don''t do this" warning with a "how to do
it" section.  Many
of us use rented servers that are accessible only remotely and do not come
with a firewall.  What are we to do?  Not use a firewall?

Here is the "how-to" that I followed after my lock-out experience:

*Before installing Shorewall on a remote system, take these precautions.
Otherwise, you are virtually assured to lock yourself out of that system.*

* Make sure that Shorewall is not started automatically at boot (startup=0
in /etc/default/shorewall).  That way, if I misconfigure shorewall, I can
recover with a reboot.
* When experimenting with Shorewall, I setup a root cronjob that reboots
the system at a certain time (usually 10 minutes into the future from when
I want to try the new firewall).  That way, if I lock myself out, I can
just wait a few minutes until the software reboot removes the firewall,
instead of resorting to a hardware reboot.
* I familiarized myself with the shorewall start, stop, clear, try, save,
restore commands.
* Don''t try to fix a firewall by installing another firewall.  I think
I
locked myself out by trying to reinstall my previous home-made iptables
configuration while Shorewall was in an unsatisfactory "try" state. 
My
existing ssh connection froze.  I still don''t know why this happened.
* I plan to familiarize myself with my server''s rescue proceedures.  I
already learned about the hardware reboot the hard way.
* Setup a firewall early, while the server is not used for much else.  That
will cut down on disruptions.
* Setup backup procedures sooner rather than later.


------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev

Hi,

Am 28.12.2011 15:05, schrieb Alex Athanasopoulos:
> Many of us use rented servers that are accessible only remotely and 
> do
> not come with a firewall.  What are we to do?  Not use a firewall?
Let me ask you a questtion: If you only have a rented server serving 
services to the outside world, why would you intend to use a packet 
filter? (Don't confuse a packet filter like IPTables with a *real* 
firewall where you would have to thinkl about stuff like IDS, Proxies 
and so on.)

1. Services which need to serve the outside world *cannot* be protected 
by a packet filter, as you have to set the rules to ACCEPT for that 
service. You have to care to the security within the service.
2. Services which don't need to serve the outside world *must* *not* 
listen to it, so they don't need a packet filter blocking access to 
them. The packet filter just puts another layer of software around 
closed ports, and as _every_ piece of software tends to have bugs, 
setting up an unneeded packet filter may cause more problems than it 
solves.

The company hosting your server needs a firewall, that is true, but you 
having a single server? Also a company having to protect *their* SMZ 
and/or internal network need a firewall, but again, these are not 
comparable scenarios.

Don't get me wrong: I don't intend to be impolite or get you away from 
installing shorewall on your server. I'm just curious...

Best regards Jan


------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Good questions.  In this case, the server runs proxmox and contains
multiple openvz containers.
I only have one public IP address and the packet filter does other things
besides being a firewall:
* It implements NAT for the containers, so they can have internet access.
* It allows me to forward different services to different containers, for
example forward SMTP traffic to a mail container, HTTP traffic to a reverse
http proxy container, etc.
  * I can ssh directly from my home to any of the containers, by port
forwarding different ports to the ssh port of each container.  That way I
use the hardware node less and it''s less susceptible to being
compromised.
  * I can have a community web site in its own container, and give others
root access to it without giving them any access to the rest of the
server.  My whole reason for getting this server was to host a busy
community site while keeping some of the machine for myself.  Maybe this is
all overkill, but it''s interesting.

Just the NAT and port-forwarding alone are worth the effort of installing
Shorewall.  It took me several hours to figure this out by using iptables
alone.  And since, besides these other things, Shorewall includes a
"firewall", why not use it?

So you are right, my firewall needs may not be great, but this setup allows
me to be a bit more security oriented.
I was prompted to install Shorewall by a mail-server-setup tutorial.

Incidentally, is a setup like this trustworthy, e.g. for using one of these
containers for my private personal files, or is it "like raising foxes in
the corner of your hen house" (FAQ 2)?  I personally do not trust it yet,
but I may change my mind as I get more experience.

I would also like to add, that in a home network, a modern modem-router
acts as a firewall anyway, so why would one use a second firewall on top of
that?  I''ve logged into my home router and I see that it has quite an
elaborate iptables configuration.

-Alex

On Wed, Dec 28, 2011 at 4:36 PM, Jan Kohnert <
nospam001-lists@jankoh.dyndns.org> wrote:
> Let me ask you a questtion: If you only have a rented server serving
> services to the outside world, why would you intend to use a packet
> filter? (Don''t confuse a packet filter like IPTables with a *real*
> firewall where you would have to thinkl about stuff like IDS, Proxies
> and so on.)
>
> 1. Services which need to serve the outside world *cannot* be protected
> by a packet filter, as you have to set the rules to ACCEPT for that
> service. You have to care to the security within the service.
>
Yes, but the rest of the containers can be protected from these vulnerable
services.

> 2. Services which don''t need to serve the outside world *must*
*not*
> listen to it, so they don''t need a packet filter blocking access
to
> them. The packet filter just puts another layer of software around
> closed ports, and as _every_ piece of software tends to have bugs,
> setting up an unneeded packet filter may cause more problems than it
> solves.
>
>
Since I haven''t written the services that I use, I don''t know
exactly what
they do with my network. A packet filter is a tool to supervise these
services.


------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don''t need a
complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Alex Athanasopoulos wrote:
>Do not attempt to install Shorewall on a remote system. You are 
>virtually assured to lock yourself out of that system.
>
>Luckily the hardware reboot procedure unlocked my system and I went 
>back into installing Shorewall, after taking some precautions.
Yes, there are certain things where there are 2 types of people - 
those that have done it, and those that haven''t ... yet !
Like configuring a router remotely, can be tricky. Out of band access 
can be exceedingly useful then. In my previous job, I made sure the 
remote sites had redundant links - partly to give continuity of 
service, partly to allow better remote diagnostics. Eg rather than 
"site down - could be link, router, LAN, something else", if I can 
use the backup link and log into the router remotely then I can pin 
it down to (eg) the WAN link.
>* Make sure that Shorewall is not started automatically at boot 
>(startup=0 in /etc/default/shorewall).  That way, if I misconfigure 
>shorewall, I can recover with a reboot.
>* When experimenting with Shorewall, I setup a root cronjob that 
>reboots the system at a certain time (usually 10 minutes into the 
>future from when I want to try the new firewall).  That way, if I 
>lock myself out, I can just wait a few minutes until the software 
>reboot removes the firewall, instead of resorting to a hardware 
>reboot.
You could also try a short script (run from cron) that will do 
"shorewall clear", sleep for a few minutes, and then reboot. If 
shorewall clear does the trick (which it mostly should) then you can 
get back in and kill the job before it reboots.
>* I familiarized myself with the shorewall start, stop, clear, try, 
>save, restore commands.
There are also saqfe-start and safe-restart. These will apply the 
changes, and then prompt you if you want to keep them. If you reply 
with no, or don''t reply because you''ve locked yourself out,
then it
will timeout and revert to the previous running config.
>* Setup backup procedures sooner rather than later.
Nah, everyone knows that backup procedures are what you think about 
after you''ve had an incident. I know that''s the best time to
sell
backup to customers - when they suddenly realise the value of them. 
Of course, if we are able to rescue their data that isn''t backed up, 
then that''s a bonus.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don''t need a
complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Hi Alex,

 

I’m in the same situation with a Proxmox server at a provider. First I did a
configuration similar to you but now I got 7 public IP-address and trying to
configure ProxyARP. I made my notes in a word doc
(http://www.mediafire.com/?95ewi61jv8spa1k ) to remember different settings.
Feel free to see if my notes can help you. NB! It just the first section I
got to work! The other stuff are just working material… 

 

I was following different guides on net how to configure Shorewall and
Proxmox but I can’t say I understand everything in detail…

 

 

Med vänlig hälsning / Best regards

Måns Åman

 

Riverman

Fogdev. 40

S-128 41 BAGARMOSSEN

 

Tel: +46 (0)8 50004424   Mob:  +46 (0)76 3077101

Norge: +47 21608106     UK: +44 (0)8450045468

 

From: Alex Athanasopoulos [mailto:alex@melato.org] 
Sent: den 28 december 2011 17:08
To: Shorewall Users
Subject: Re: [Shorewall-users] How to install Shorewall on a remote
system...

 

Good questions.  In this case, the server runs proxmox and contains multiple
openvz containers.
I only have one public IP address and the packet filter does other things
besides being a firewall:
* It implements NAT for the containers, so they can have internet access.
* It allows me to forward different services to different containers, for
example forward SMTP traffic to a mail container, HTTP traffic to a reverse
http proxy container, etc.
  * I can ssh directly from my home to any of the containers, by port
forwarding different ports to the ssh port of each container.  That way I
use the hardware node less and it''s less susceptible to being
compromised.
  * I can have a community web site in its own container, and give others
root access to it without giving them any access to the rest of the server.
My whole reason for getting this server was to host a busy community site
while keeping some of the machine for myself.  Maybe this is all overkill,
but it''s interesting.

Just the NAT and port-forwarding alone are worth the effort of installing
Shorewall.  It took me several hours to figure this out by using iptables
alone.  And since, besides these other things, Shorewall includes a
"firewall", why not use it?

So you are right, my firewall needs may not be great, but this setup allows
me to be a bit more security oriented.
I was prompted to install Shorewall by a mail-server-setup tutorial.

Incidentally, is a setup like this trustworthy, e.g. for using one of these
containers for my private personal files, or is it "like raising foxes in
the corner of your hen house" (FAQ 2)?  I personally do not trust it yet,
but I may change my mind as I get more experience.

I would also like to add, that in a home network, a modern modem-router acts
as a firewall anyway, so why would one use a second firewall on top of that?
I''ve logged into my home router and I see that it has quite an
elaborate
iptables configuration.

-Alex

On Wed, Dec 28, 2011 at 4:36 PM, Jan Kohnert
<nospam001-lists@jankoh.dyndns.org> wrote:

Let me ask you a questtion: If you only have a rented server serving
services to the outside world, why would you intend to use a packet
filter? (Don''t confuse a packet filter like IPTables with a *real*
firewall where you would have to thinkl about stuff like IDS, Proxies
and so on.)

1. Services which need to serve the outside world *cannot* be protected
by a packet filter, as you have to set the rules to ACCEPT for that
service. You have to care to the security within the service.


Yes, but the rest of the containers can be protected from these vulnerable
services.
 

2. Services which don''t need to serve the outside world *must* *not*
listen to it, so they don''t need a packet filter blocking access to
them. The packet filter just puts another layer of software around
closed ports, and as _every_ piece of software tends to have bugs,
setting up an unneeded packet filter may cause more problems than it
solves.


Since I haven''t written the services that I use, I don''t know
exactly what
they do with my network. A packet filter is a tool to supervise these
services.




-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4708 - Release Date: 12/28/11


------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don''t need a
complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

> Here is the "how-to" that I followed after my lock-out
experience:
Here''s my how-to based on common sense:

1) Start a tmux session and get root

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don''t need a
complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

> > Here is the "how-to" that I followed after my lock-out
experience:
> 
> Here''s my how-to based on common sense:
> 
> 1) Start a tmux session and get root
LOL sorry, apparently a software upgrade changed "close window" to
"send immediately".

(Perhaps I should write another howto for preventing this...)

So, second attempt:

1) Start a tmux session (so you won''t lose your shell on disconnect /
timeout) and make sure you''re root
2) type the following: ''shorewall start; sleep 5m; shorewall
clear''

voila, worst case scenario is that you have locked yourself out for 5
minutes.

You can add all kinds of logging into shorewall to make sure that being
locked out happens only one time.

Mark

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don''t need a
complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

On Sat, 2011-12-31 at 04:42 +0100, Mark wrote:
> > > Here is the "how-to" that I followed after my lock-out
experience:
> > 
> > Here''s my how-to based on common sense:
> > 
> > 1) Start a tmux session and get root
> 
> LOL sorry, apparently a software upgrade changed "close window"
to
> "send immediately".
> 
> (Perhaps I should write another howto for preventing this...)
> 
> So, second attempt:
> 
> 1) Start a tmux session (so you won''t lose your shell on
disconnect /
> timeout) and make sure you''re root
> 2) type the following: ''shorewall start; sleep 5m; shorewall
clear''
This is very similar to what ''shorewall safe-start'' does,
except that:

a) safe-start prompts you to ask if you want to keep the config or   
   clear.

b) The timeout is currently fixed at 60 seconds.

In the next release, I''ll add an option to specify the timeout
interval.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________




------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don''t need a
complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Hi Tom,
> > 1) Start a tmux session (so you won''t lose your shell on
> > disconnect / timeout) and make sure you''re root
> > 2) type the following: ''shorewall start; sleep 5m; shorewall
> > clear''  
> 
> This is very similar to what ''shorewall safe-start'' does,
except that:
> 
> a) safe-start prompts you to ask if you want to keep the config or   
>    clear.
> 
> b) The timeout is currently fixed at 60 seconds.
I wasn''t aware of this; thanks for the info. Does it also work if the
connection with the shell is terminated? Usually any shell command that
implements a sleep timer without forking is terminated, killing any
timer or pending routine.

Of course on a plain shell one could simply disown the command (e.g.
via ''shorewall safe-clear &!'' when using zsh, or
''shorewall safe-clear
& disown'' on bash) but then you won''t be able to answer
the command,
making it equivalent to answering ''n''. In such a case
it''s better to
execute the command ''shorewall safe-clear'' from within tmux or
GNU
screen.

Have a good new year,
- Mark


Note: I understand that many people are probably already aware of the
above comments but I''ll accept the risk of sounding pedantic. Perhaps
some day they can save someone from suddenly having to take a dreadful
trip to a data center simply to unload a firewall. I know all about
these wonderful incidents that force one to spend free evenings in an
unplanned and not particularly welcome way...)


------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don''t need a
complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

On Sat, Dec 31, 2011 at 07:58:21PM +0100, Mark wrote:
> 
> I wasn''t aware of this; thanks for the info. Does it also work if
the
> connection with the shell is terminated? Usually any shell command that
> implements a sleep timer without forking is terminated, killing any
> timer or pending routine.
> 
What about if you run the command in a screen session?  Then you
shouldn''t have an issue, since you can just reconnect to the session
after re-establishing your connection.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don''t need a
complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox