[nzlug] Server Consolidation

[Daniel Lawson]

> As far as cutting down on power/heat/noise, the solution might be to put
> ipcop on a smaller machine like a soekris box. Soekris sell 12v 1A power
> supplies for all but their more powerful machines, so I guess you are not
> going to use any more than 12W, probably far less.
>   

These are a bit expensive for what you get, but otherwise are fine. WRAP
boards are another option, as are the Mikrotik devices. I'm sure there's
plenty of other ones too.

I've run one of the soekris boards, with dual radio cards light up, off
an 11AH lithium ion cell for about 24 hours.

> Usual wisdom is not to run your web/ftp/mail etc server on your firewall,
> so the people that suggested just using iptables on the ubuntu box are a
> bit wide of the mark IMHO.
>   

Usual wisdom for home networks? No wonder so many people complain of
power/heat loading.

It may be preferential to not run web/ftp/mail on your firewall, but if
you have incoming  web, ftp and email through to an internal server (eg,
your internet facing services are being forwarded to an internal server)
how is that actually any different from running them on your firewall?

It's far better to actually understand your security model and the 
risks involved, and take an educated risk (slight as it is in this
situation), than to place too much trust on a "firewall" when you're
either punching holes straight through it, or otherwise overly
complicating things (eg, by trying to virtualise your firewall [1] or
adding extra layers of software in between the internet and your
internet-facing services)


 I know this is a home network we're talking about, but the OP was
interested in making things more "commercial focussed". My take on that,
having worked for a fair while doing linux IT work commercially, is to
have a separate firewall entirely, which in this case comes back to
heat/power or price issues, or to just suck it up and put everything on
the one machine.


To the poster who bemoaned the lack of gui based firewall tools:

* firestarter (http://www.fs-security.com/) is a gui tool for firewall admin
* fireflier (http://fireflier.sourceforge.net/) is another one, but
seems like it's out of active development now
* fwbuilder (http://www.fwbuilder.org/) is another gui tool, which also
claims support for  OpenBSD, NetBSD, FreeBSD and MacOS X (eg, not just
iptables)
* ebox (http://ebox-platform.com/) is a whole stack tool for network
service administration.
* guarddog and guidedog are a pair of KDE based tools that do varying
levels of firewall management
* ditto kmyfirewall (http://kmyfirewall.sourceforge.net/)

Those are just the ones that claim to be gui tools, that I saw with a
quick scan over the output from a search in the ubuntu gutsy
repositories with the term 'firewall'. There are also a range of command
line based helpers (eg, tools to manage firewalls) and metalanguages
(scripts you still have to edit by hand).

If you don't want to keep running ubuntu, there are also plenty of
whole-stack distros out there - clark connect and SME server are two
that I can think of immediately, although I haven't used clark connect
since it was based on RedHat 6.2

http://www.clarkconnect.com/
http://www.smeserver.org/

I personally can't vouch for the efficacy of any of the tools above - I
just use vim[2] to edit my firewalls :)

Daniel


[1] I have virtualised firewalls under Xen, using PCI passthrough of the
external network device, on at least two sites. And I regret it
immensely. If the host ever needs a reboot, I lose network access to the
entire site. I cannot access ILO (remote power/KVM management for HP
servers), because I've lost my network access, so if the host isn't
booting, I need to go onsite. If I want to do an OS upgrade safely, I
need to go onsite. Having a separate firewall would stop that. And
having it on the xen dom0 wouldn't help either, but I wouldn't have a
xen dom0 as the border device - I would have no problems with a single
server though.

[2] No vim vs emacs or vim vs vi discussions please ;)