Re: External Network / Firewall Setup.

[Jayson Anderson <sonick () sonick com>]

Your topology layout looks fine. In fact, it is the defacto belt and
suspenders approach with a single bastion host. Very common. 
I'm not sure about the Nokia approach as I've never used those devices,
but it could be argued that closed-source by virtue of philosophy
becomes a single point of failure. Key metric of course being response
time both to acknowledgement in announced vulnerabilities, and the time
to publish those all-important fixes. 1 Enterprise X 9am-5pm versus 1
Planet x 24-7 = disparity. Lay out your checks and balances and see what
you come up with, and roll with it. 

One other thing: spare the DMZ the real and perceived anomalys in
traffic flow and application response by making sure to configure your
bastion host(s) with a permanent route for [ALL] internal networks. Of
course your internal networks are all contiguous such that you can do
this with one single aggregate prefix correct ? ;) At 30% saturation on
a 2mB pipe, the redirects that can be generated on that hub are
staggering indeed. Don't bother fiddling around with Layer4 magic
thinking you can predict every packet and icmp type that may need to
flow back towards the internal networks..... just slap on the L3 route
the old fashion way and things will stay happy. Let the filter worry
about what shall and what shant back towards the internal networks,
AFTER the route is identified.  

Now about that single point of failure..... since there is inherently an
uncomfortable amount of those in this classic topology, it would be a
good thing if you can install two more filters in parallel with your
existing two, and then tie the system together with an automatic
failover. Many are tempted to use an IGP here, and the argument is sound
when considering the maturity of L2 open-source failover solutions; but
I have put in a considerable amount of testing and deployment time with
'vrrpd' and found it to be a stellar performer at least on Linux kernel
2.6. vrrpd does not require any kernel patches, no fancy wrappers or
modules; just compile, configure and install and it works to spec by
default. vrrpd is fairly new but is extremely thin and has yet to do
exhibit the slightest de-spec behavior and i've been waiting for some
time. L2 solutions also eliminate the temporary hiccup cause against
current established connections that become discontiguous/broken. 

Good luck, hit me up if you need anything. 

Best Regards, 
Jayson

On Mon, 2005-09-05 at 12:44 +0100, lists () ninjafriendly com wrote:
> Hi all,
>
> Background: We're a .sch.uk with a currently county-managed firewall and webmail
> provision.  We have a 2mb symmettric DSL connection with approx 30% use at any
> one time.  Due to service and reliability issues with the county-managed
> solution we are looking to run our own mailserver, accessible from the
> internet.  On balance, maintaining our own firewall setup is less hassle than
> keeping what we currently have.
>
> I'm currently in the process of working out the firewall requirements, what I
> have so far is this:
>
> Internet
> |
> Router
> |
> Firewall(1)
> |
> HUB---Snort(1)
> | |___Mailserver
> |
> Firewall(2)
> |
> HUB---Snort(2)
> |
> |
> LAN
>
> I suspect this setup may be overkill for the amount of traffic we receive, but
> I'm wary of a single point of failure.  Hardware isn't a problem.
>
> Further info: The mailserver will be running Horde.  I'm hoping to convince
> management to use a PIX or similar for the first firewall and then something
> *nix based for the second, otherwise it will be two *nix boxes (IPcop and
> something BSD based).
>
> Something I'm still unsure about is internal clients connecting to the
> mailserver in the DMZ - how much of a security issue is this?  Should I use the
> DMZ mailserver simply as a relay for an internal mailserver?
>
> Would anyone mind looking this over and telling me if I've screwed up /
> overlooked something?
>
> Thanks
>
> Pete