Advice on a firewall distro

On 2006-12-15, David Brown <(E-Mail Removed)> wrote:
> I'm planning an update for the firewall and routing in our company
<zap>
> together something that can be mostly administered by a web interface,
<zap>

whenever I heard the term 'firewall' and 'web interface' in the same
sentence something make me want to puke...

> I'd also like to run a few services on the firewall machine - web proxy,

Bad idea. The firewall must do the firewalling and nothing else. Have
servers behind it provide the 'services' and let the firewall do what he is
supposed to do: keep bad things out.

Davide

--
You can go a long way with a grunt, you can go a lot farther with a
grunt and an EtherKiller -- BOFH

Hi,

I'm planning an update for the firewall and routing in our company
network. We have something like 30 PC's, and in conjunction with some
new requirements (separated internal networks, DMZ for web/mail server),
I am looking at getting a PC with lots of network ports to do the
firewalling and routing - our current firewall (a ZyWall 10) is not
flexible enough.

I currently administer a Debian server, a Ubuntu server, and a very old
Red Hat machine (and also an NT 4 server, but I don't see NT as a good
choice for a firewall OS...). I'm also used to appliance-type
firewalls, including ZyXEL ZyWall 10, LinkSys WRT54GL wireless routers,
and assorted other devices in other networks. I'm hoping to put
together something that can be mostly administered by a web interface,
for convenience, but I'm quite happy with ssh, bash scripts, man pages,
configuration files, etc. - indeed, I need to have such access as I
doubt any pre-defined firewall distro would cover everything I want. At
the moment, my two ideas are either to start with something like IPCop
and build out, or to use Ubuntu server (for familiarity) and configure
things manually.

My planned setup is shown below. I'm open to any hints, experiences, or
comments (including telling me I'm daft to use just one machine, and
should split it up).

Red1:
Ethernet to ADSL modem (currently 6Mb/600kb)

Red2:
Ethernet to second ADSL modem on a different line
(dedicated to a particular route, but I'd like to have
it available as a backup if the first line goes down)

Green1:
Internal network

Green2:
Second internal network, separated from Green1

Blue:
Networked LinkSys radio routers

Orange:
DMZ for the web and email server(s)


I'd also like to run a few services on the firewall machine - web proxy,
ftp proxy, dns (for the internal network, plus proxying for external
access), and openVPN. I am considering email proxies (with spam and
virus checking), but will probably just put them on an orange zone
server, and block any pop3 or imap requests from the Green zones.

tia,

David

On Fri, 15 Dec 2006 14:14:04 +0100, David Brown wrote:
>I currently administer a Debian server, a Ubuntu server, and a very old
>Red Hat machine (and also an NT 4 server, but I don't see NT as a good
>choice for a firewall OS...).

My personal choice would be OpenBSD, but I think it's better to use
something you are familiar with.

>I'm also used to appliance-type firewalls, including ZyXEL ZyWall 10,
>LinkSys WRT54GL wireless routers, and assorted other devices in other
>networks. I'm hoping to put together something that can be mostly
>administered by a web interface, for convenience,

Convenience and security often don't mix. IMHO, firewalls shouldn't run
any service. Maybe DHCP for a home network, but not more.
Administration should be done at the console or with a serial
connection.

--
Maurice

Davide Bianchi wrote:
> On 2006-12-15, David Brown <(E-Mail Removed)> wrote:
>> I'm planning an update for the firewall and routing in our company
> <zap>
>> together something that can be mostly administered by a web interface,
> <zap>
>
> whenever I heard the term 'firewall' and 'web interface' in the same
> sentence something make me want to puke...
>

I guess I did ask for this kind of comment!

I understand that attitude, and I would rule out anything that
*required* a web interface. To me, a web interface is a nice front end
to the configuration files and log files. If the web interface makes my
job easier, then that's a good thing - assuming the cost in security or
reliability is not noticeable. I want to be able to make configuration
changes that suit *my* requirements, not just those the web interface
designer thinks I want - but I also appreciate being able to make
standard settings in a web browser's text box without having to study
man pages. I want to be able to look through log files - but ready-made
graphs give me useful information quickly.

>> I'd also like to run a few services on the firewall machine - web proxy,
>
> Bad idea. The firewall must do the firewalling and nothing else. Have
> servers behind it provide the 'services' and let the firewall do what he is
> supposed to do: keep bad things out.
>
> Davide
>

Again, I appreciate the arguments for minimising the services on the
firewall. Fewer services means fewer security risks, and as a central
connection in the network, it is vital that the firewall machine is not
compromised. Services which require multiple user accounts (such as
common email setups, or file sharing) are right out - there should be no
accounts on a firewall machine for which logons are enabled, and for
which the user name is guessable. But the heart of the firewall is the
iptables setup - when that is correct, the risk to services on the
firewall is the same as the risk if these services are on a different
server (though the resulting damage may be greater). I'd expect that
risk to be very close to zero - if it is not, then the service will not
be running anywhere on my network.

Any security system is a balance between its security and reliability on
one side, and its usefulness (including services to its users, and its
ease of configuration, administration and maintenance, and to a lesser
extent, costs) on the other. A block-everything and do nothing else
firewall is one extreme, while an open network is another. I am not
necessarily looking to maximize security outright - I'm looking to
maximize security while having a useful placement of services.

On the other hand, it is quite possible that I'll keep the old ZyWall
firewall between the internet and the new firewall, doing nothing but
firewalling.

Thanks for your comments,

David

Maurice Janssen wrote:
> On Fri, 15 Dec 2006 14:14:04 +0100, David Brown wrote:
>> I currently administer a Debian server, a Ubuntu server, and a very old
>> Red Hat machine (and also an NT 4 server, but I don't see NT as a good
>> choice for a firewall OS...).
>
> My personal choice would be OpenBSD, but I think it's better to use
> something you are familiar with.
>

I've also heard that BSD (I can't remember which flavour(s)) are the
best choice for maximal security, but as you say, familiarity is
important. A misconfigured BSD system is unlikely to be a good idea!

>> I'm also used to appliance-type firewalls, including ZyXEL ZyWall 10,
>> LinkSys WRT54GL wireless routers, and assorted other devices in other
>> networks. I'm hoping to put together something that can be mostly
>> administered by a web interface, for convenience,
>
> Convenience and security often don't mix. IMHO, firewalls shouldn't run
> any service. Maybe DHCP for a home network, but not more.
> Administration should be done at the console or with a serial
> connection.
>

I'm willing to pay the price of a little security for a lot more
convenience (after all, that's exactly what you do with a firewall in
the first place - it's not as secure as a severed network cable, but
gives you a lot more functionality!). But the balance has to be right.
It could well be that I'll keep the old ZyWall firewall in place as a
first-stop firewall, although I don't see how it could help prevent an
attack (any incoming packets blocked by the ZyWall would have been
blocked by the linux firewall's iptables anyway). It would help limit
damage in the event of a compromised firewall - even if an attacker
figured out a way to get root access on the firewall machine, they could
not open other ports in or out without also breaking the security of the
ZyWall.

On Fri, 15 Dec 2006 14:14:04 +0100, David Brown wrote:

[putolin]

>
> My planned setup is shown below. I'm open to any hints, experiences, or
> comments (including telling me I'm daft to use just one machine, and
> should split it up).
>
> Red1:
> Ethernet to ADSL modem (currently 6Mb/600kb)
>
> Red2:
> Ethernet to second ADSL modem on a different line
> (dedicated to a particular route, but I'd like to have
> it available as a backup if the first line goes down)
>
> Green1:
> Internal network
>
> Green2:
> Second internal network, separated from Green1
>
> Blue:
> Networked LinkSys radio routers
>
> Orange:
> DMZ for the web and email server(s)
>

The DMZ should be Yellow, Orange definitely won't work as an orange subnet
will drop too many TCP packets. Orange is only good for UDP.

--
Dancin' in the ruins tonight
Tayo'y Mga Pinoy

On Fri, 15 Dec 2006 15:43:06 +0100, David Brown wrote:

> I'm willing to pay the price of a little security for a lot more
> convenience (after all, that's exactly what you do with a firewall in

Dude, goto your boss and tell him you are not qualified for this task.
I hope you were kidding about convenience over security.

> blocked by the linux firewall's iptables anyway). It would help limit
> damage in the event of a compromised firewall - even if an attacker
> figured out a way to get root access on the firewall machine, they could
> not open other ports in or out without also breaking the security of the
> ZyWall.

First things first. You don't allow packets to stop on the firewall. If
they are coming in and not going out another interface then they should be
dropped, no exceptions. The only way to access the firewall is to plug
into it with a keyboard and monitor.


--

Regards
Robert

Smile... it increases your face value!


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On Sat, 16 Dec 2006 00:46:15 -0500, Robert wrote:

> On Fri, 15 Dec 2006 15:43:06 +0100, David Brown wrote:
>
>> I'm willing to pay the price of a little security for a lot more
>> convenience (after all, that's exactly what you do with a firewall in
>
> Dude, goto your boss and tell him you are not qualified for this task.
> I hope you were kidding about convenience over security.
>

I was exagerating a little to make a point - there is no way to get a
perfectly secure setup that still does something useful. The only
guarenteed perfectly secure and reliable way to secure yourself from the
big bad internet is to have no connection at all.

Since I *do* want a connection, and I need computers on the inside to be
able to access services outside our network, and computers on the outside
need to access services in the DMZ, then I am of necessity
compromising security to provide that access. I'm under no illusions
about making a perfectly secure setup - if anyone tells me they can
provide that sort of security, then they'll have to work very hard to
persuade me that *they* are qualified.

What I need is a system that is secure to the point where a security
breach is so unlikely that it is a negligible risk compared to all the
other risks a company deals with regarding their data, such as physical
break-ins, fire, or user error or malvolence. Any time or money spent
getting significantly beyond that level is time and money wasted.

If you want to tell me that I can't get there without having a physically
separate firewall device that is as simple as possible, then that's fine -
I'll listen to that advice. That's why I'm asking, and I'm grateful for
any such advice. I haven't any doubt that a dedicated minimilistic
low-level packet firewall is the most secure for doing that part of the job
- but I am not convinced that it is necessary. There are good reasons why
people want a complete solution that covers low-level packet firewalling
with higher level security functions such as http proxying and filtering,
log file analysis, and intrusion detection systems. I'm looking to find a
sensible balance.


>> blocked by the linux firewall's iptables anyway). It would help limit
>> damage in the event of a compromised firewall - even if an attacker
>> figured out a way to get root access on the firewall machine, they could
>> not open other ports in or out without also breaking the security of the
>> ZyWall.
>
> First things first. You don't allow packets to stop on the firewall. If
> they are coming in and not going out another interface then they should be
> dropped, no exceptions. The only way to access the firewall is to plug
> into it with a keyboard and monitor.
>

That is what the ZyWall would do - it doesn't handle the packets itself.

Thanks for your comments,

David

On Sat, 16 Dec 2006 14:55:20 +0000, David Brown wrote:

>>> I'm willing to pay the price of a little security for a lot more
>>> convenience (after all, that's exactly what you do with a firewall in
>>
>> Dude, goto your boss and tell him you are not qualified for this task.
>> I hope you were kidding about convenience over security.
>
> I was exagerating a little to make a point - there is no way to get a
> perfectly secure setup that still does something useful. The only
> guarenteed perfectly secure and reliable way to secure yourself from the
> big bad internet is to have no connection at all.

I will agree with this.

> Since I *do* want a connection, and I need computers on the inside to be
> able to access services outside our network, and computers on the outside
> need to access services in the DMZ, then I am of necessity
> compromising security to provide that access. I'm under no illusions
> about making a perfectly secure setup - if anyone tells me they can
> provide that sort of security, then they'll have to work very hard to
> persuade me that *they* are qualified.
>
> What I need is a system that is secure to the point where a security
> breach is so unlikely that it is a negligible risk compared to all the
> other risks a company deals with regarding their data, such as physical
> break-ins, fire, or user error or malvolence. Any time or money spent
> getting significantly beyond that level is time and money wasted.

You are not going to get this with a bridged network. You said yourself
that the ZyWall is limited, do you trust it to do everything for you? If
I understand you that is what you intend to do. With the ZyWall and the
bridge you are just adding points of failure. You would want to limit this
as well.

> If you want to tell me that I can't get there without having a physically
> separate firewall device that is as simple as possible, then that's fine -

No, what I am saying is you don't need that ZyWall box and should not use
a bridge. You are the one saying you need the ZyWall. I am saying that
you can do everything on one device with a connection to all your
networks. One that you have total control over, not hoping the company
you bought the ZyWall from didn't over look something.

> I'll listen to that advice. That's why I'm asking, and I'm grateful for
> any such advice. I haven't any doubt that a dedicated minimilistic
> low-level packet firewall is the most secure for doing that part of the
> job - but I am not convinced that it is necessary. There are good
> reasons why people want a complete solution that covers low-level packet
> firewalling with higher level security functions such as http proxying
> and filtering, log file analysis, and intrusion detection systems. I'm
> looking to find a sensible balance.

Here is what I would do;

Chose what OS you want to use, I use Linux here. Install 3 interfaces in
the box and set then up as follows:

eth0 - Internet
eth1 - DMZ
eth2 - LAN

Setup the firewall to do stateful packet inspection (Linux setup).

eth0: DROP all new connection that are not destine for the DMZ services you have
defined. Allow all ESTABLISHED/RELATED connections. This will allow new
connection to your DMZ services but drop any to your LAN.

eth1: DROP all new connection trying to leave the DMZ. The only packets
that leave the DMZ are the ones that are ESTABLISHED/RELATED. That way if
one of the boxes gets hacked they cannot infect the rest of the world or
your LAN. Updates to that box should be pushed from the LAN. This will
allow connection into the DMZ but will drop all new requests leaving the
DMZ

eth2: Allow all NEW connection that are allowed by company policy. Allow
all ESTABLISHED/RELATED connection. This will allow your users to get out
to the Internet and the DMZ.

Set your policies on the firewall box to DROP INPUT OUTPUT and FORWARD
that way nothing is coming to or going from that box. Since no one has
access to this box the box will not be able to be attacked.

Set your FORWARD tables to allow what you want everything else will be
dropped.

There is a lot more to this, this is just the high level view and this
setup is working here fine for some time now.

>>> blocked by the linux firewall's iptables anyway). It would help limit
>>> damage in the event of a compromised firewall - even if an attacker
>>> figured out a way to get root access on the firewall machine, they
>>> could not open other ports in or out without also breaking the
>>> security of the ZyWall.
>>
>> First things first. You don't allow packets to stop on the firewall.
>> If they are coming in and not going out another interface then they
>> should be dropped, no exceptions. The only way to access the firewall
>> is to plug into it with a keyboard and monitor.
>>
>>
> That is what the ZyWall would do - it doesn't handle the packets itself.

And the above does the same with one less POF and nothing is bridged.

> Thanks for your comments,

Sure thing


--

Regards
Robert

Smile... it increases your face value!


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On Sat, 16 Dec 2006 11:55:39 -0500, Robert wrote:

> On Sat, 16 Dec 2006 14:55:20 +0000, David Brown wrote:
>
>>>> I'm willing to pay the price of a little security for a lot more
>>>> convenience (after all, that's exactly what you do with a firewall in
>>>
>>> Dude, goto your boss and tell him you are not qualified for this task.
>>> I hope you were kidding about convenience over security.
>>
>> I was exagerating a little to make a point - there is no way to get a
>> perfectly secure setup that still does something useful. The only
>> guarenteed perfectly secure and reliable way to secure yourself from the
>> big bad internet is to have no connection at all.
>
> I will agree with this.
>
>> Since I *do* want a connection, and I need computers on the inside to be
>> able to access services outside our network, and computers on the outside
>> need to access services in the DMZ, then I am of necessity
>> compromising security to provide that access. I'm under no illusions
>> about making a perfectly secure setup - if anyone tells me they can
>> provide that sort of security, then they'll have to work very hard to
>> persuade me that *they* are qualified.
>>
>> What I need is a system that is secure to the point where a security
>> breach is so unlikely that it is a negligible risk compared to all the
>> other risks a company deals with regarding their data, such as physical
>> break-ins, fire, or user error or malvolence. Any time or money spent
>> getting significantly beyond that level is time and money wasted.
>
> You are not going to get this with a bridged network. You said yourself
> that the ZyWall is limited, do you trust it to do everything for you? If
> I understand you that is what you intend to do. With the ZyWall and the
> bridge you are just adding points of failure. You would want to limit this
> as well.
>
>> If you want to tell me that I can't get there without having a physically
>> separate firewall device that is as simple as possible, then that's fine -
>
> No, what I am saying is you don't need that ZyWall box and should not use
> a bridge. You are the one saying you need the ZyWall. I am saying that
> you can do everything on one device with a connection to all your
> networks. One that you have total control over, not hoping the company
> you bought the ZyWall from didn't over look something.
>

I'm not sure I was entirely clear about describing what I was thinking.
For comparison, I'll try to describe what we have today (simplified to omit
the second "red" connection with its separate firewall):

The ZyWALL 10 is a NAT router with a stateful packet filter, and
configurable rules for blocking or allowing access acording to IP
addresses and ports. The basic setup is that everything coming in is
blocked, and everything going out (from LAN side to WAN side) is allowed.
This gives me the basic requirements to allow PC's on the internal access
to the internet, while keeping them invisible and protected from
unexpected packets from the outside. I have additional rules limiting
some accesses from the internal network (no email that hasn't passed
through the email server, for example), and I have port forwarding for
certain services (web, email, and openvpn for specific IP addresses)
passing connections through to a server on the internal network.

I have no reason not to trust the ZyWALL, having used it (and other
ZyXEL products) for years, and had no sign of attacks getting past it.
However, it is somewhat limited - I don't have any possibility of using a
DMZ (and clearly I would much rather have the web and mail services
separated from the internal network), I can't divide up the network as I
want without additional firewall/routers, I can't control traffic shaping
as I'd like, I can't get the detailed logs I want (when someone uses all
the internet connection bandwidth, I want to know who to shout at!), I
can't enforce proxying, caching or filtering on traffic, and I'm not
convinced it can handle the higher bandwidths of a more modern internet
link. I don't have total control over it, as it is a closed source
product, but I believe it is doing a solid job within its capabilities.

In the new arrangement, I was not thinking of using the ZyWALL as a
bridge, but as a NAT router with only one machine (the new linux
firewall/router) on the LAN side. I would set the rules to initially
block all ports in either direction, and then open for specific services
in the required direction. Thus incoming packets would be blocked at the
ZyWALL unless they were intended for one of the servers (in the DMZ of the
linux firewall). Outgoing packets would be blocked unless they are on
ports that are allowed (such as http).



>> I'll listen to that advice. That's why I'm asking, and I'm grateful for
>> any such advice. I haven't any doubt that a dedicated minimilistic
>> low-level packet firewall is the most secure for doing that part of the
>> job - but I am not convinced that it is necessary. There are good
>> reasons why people want a complete solution that covers low-level packet
>> firewalling with higher level security functions such as http proxying
>> and filtering, log file analysis, and intrusion detection systems. I'm
>> looking to find a sensible balance.
>
> Here is what I would do;
>
> Chose what OS you want to use, I use Linux here. Install 3 interfaces in
> the box and set then up as follows:
>
> eth0 - Internet
> eth1 - DMZ
> eth2 - LAN
>
> Setup the firewall to do stateful packet inspection (Linux setup).
>
> eth0: DROP all new connection that are not destine for the DMZ services you have
> defined. Allow all ESTABLISHED/RELATED connections. This will allow new
> connection to your DMZ services but drop any to your LAN.
>
> eth1: DROP all new connection trying to leave the DMZ. The only packets
> that leave the DMZ are the ones that are ESTABLISHED/RELATED. That way if
> one of the boxes gets hacked they cannot infect the rest of the world or
> your LAN. Updates to that box should be pushed from the LAN. This will
> allow connection into the DMZ but will drop all new requests leaving the
> DMZ
>
> eth2: Allow all NEW connection that are allowed by company policy. Allow
> all ESTABLISHED/RELATED connection. This will allow your users to get out
> to the Internet and the DMZ.
>
> Set your policies on the firewall box to DROP INPUT OUTPUT and FORWARD
> that way nothing is coming to or going from that box. Since no one has
> access to this box the box will not be able to be attacked.
>
> Set your FORWARD tables to allow what you want everything else will be
> dropped.
>
> There is a lot more to this, this is just the high level view and this
> setup is working here fine for some time now.
>

What you describe here is, I believe, pretty much a standard three-way
firewall. I have not configured such an arrangement myself, and would have
to check on the details before setting one up, but I understand the
principles and the way it works. It is possible that this could be part
of my solution, with the box I originally described (without the DMZ port)
attached to eth2 above.

You didn't include any mention of NAT above. Is that because you avoid
using it (and if so, how and why? I see NAT as an integral part of a
firewall solution, as well as a practical way to connect lots of machines
to the internet), or because you consider a NAT router in addition
(presumably on the eth2 side)?



>>>> blocked by the linux firewall's iptables anyway). It would help limit
>>>> damage in the event of a compromised firewall - even if an attacker
>>>> figured out a way to get root access on the firewall machine, they
>>>> could not open other ports in or out without also breaking the
>>>> security of the ZyWall.
>>>
>>> First things first. You don't allow packets to stop on the firewall.
>>> If they are coming in and not going out another interface then they
>>> should be dropped, no exceptions. The only way to access the firewall
>>> is to plug into it with a keyboard and monitor.
>>>
>>>
>> That is what the ZyWall would do - it doesn't handle the packets itself.
>
> And the above does the same with one less POF and nothing is bridged.
>
>> Thanks for your comments,
>
> Sure thing
>

mvh.,

David