firewall-wizards@listserv.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com
You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Re: Isolating internal servers behind firewalls (Timothy Shea)
2. Re: Managing multiple Cisco Pix's (Victor Williams)
3. Firewall Testing (Shahin Ansari)
----------------------------------------------------------------------
Message: 1
Date: Sat, 8 Sep 2007 10:42:49 -0500
From: Timothy Shea <tim@tshea.net>
Subject: Re: [fw-wiz] Isolating internal servers behind firewalls
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <C9A9B1C9-B471-42B4-9440-0E8464261F4F@tshea.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On May 7, 2007, at 2:35 PM, Dan Lynch wrote:
> Greetings list,
>
Hi!
[description of a stereotypical microsoft shop deleted]
> How prevalent is it to segregate internal use servers away from
> internal
> clients behind firewalls? What benefits might we gain from the
> practice?
> What threats are we protected from?
>
> The firewall/security group argues that servers and clients should
> exist
> in separate security zones, and that consolidating servers behind
> firewalls allows us to
Ahhhh... yes ... "security zones"... I know where this is going....
Let me guess - recent college graduates with a degree in Information
Security here?
> - Control which clients connect to which servers on what ports
Bullocks! The very ports you have to open are usually the very ports
that suffer the biggest issues (microsoft rpc or MSSQL ports for
example) so putting in a firewall is not going to help. And how is
your organization going to define what ports are opened from where?
Are all your accountants in the same place? doubtful. Are all your
engineers in the same place? doubtful. Do you have a accurate map of
data flows and servers? Doubtful. Then again - maybe you have all
these things...
> - Centralized administration of that network access
I fail to see how centralizing admin of network controls is relevant
to the the argument
> - Centralized logging of network access
While I generally encourage logging - this will generate A LOT of logs.
> - a single point for intrusion detection and prevention measures
IDS/IPS are not firewalls and vice versa (although there is some
morphing going on) - completely separate discussion.
>
> On the other hand, the server team counters that
>
> - troubleshooting problems becomes more difficult
> - firewall restrictions on which workstations can perform
> administration
> makes general maintenance inconvenient, esp. in an emergency
Cry me a river.
> - the threats we're countering are exceedingly rare
You plan for the threats you aren't encountering.
> - a broken (or hacked) firewall config breaks all access to servers if
> consolidated behind firewalls
>
So can a broken switch, a broken router, a broken UPS, someone
knocking out a power cord. Sigh ... in general server people look
at firewalls as mysterious black boxes that they don't control nor
understand. This is an operational problem - have good procedures
and its not an issue (of course many have problems with this).
My general take is that central enterprise servers are managed better
and are patched more frequently then desktops or non-enterprise
servers (in companies that I've worked in). So the risk of something
or someone messing with those servers is lower. I encourage frequent
audits of the environment, centralized logging of changes, and
aggressive patching of servers.
There is also bandwidth concerns. The firewall you would need to put
in to say support a 10gig ethernet connection is going to be expensive.
I do encourage segmenting off vendor managed systems, labs,
development environments, and systems that are critical to the
company such as manufacturing or ATMs (all depending on the industry).
I'm coming from medium to large companies that generally have
operations in more than one country so your mileage may very from my
opinions.
t.s
------------------------------
Message: 2
Date: Sat, 08 Sep 2007 12:37:39 -0500
From: Victor Williams <vbwilliams@neb.rr.com>
Subject: Re: [fw-wiz] Managing multiple Cisco Pix's
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <46E2DDE3.9050101@neb.rr.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Then why not do LAN failover? That's a pretty well documented feature
of PIX OS 7 and up.
James Burns wrote:
> Sorry, to clarify:
>
> We will have two firewalls at either side of our campus serving the
> same internal network, but with different /external/ addresses - this
> is necessary because of the way that our provider has arranged things.
>
> Each runs OSPF. Both units are, in effect, active - but no traffic
> will be passed via the "backup" until the primary goes down, because
> of the way that the routing is configured.
>
> Cisco allows for active/active failover between Pix units, but ONLY if
> they are running multiple security contexts, and we do not do this,
> nor need to. What we're looking for is an elegant and preferably
> inexpensive way of keeping the ruleset up-to-date on both boxes
> without the need to manually edit on both every time a rule is
> added/amended.
>
> Hope this makes things clearer!
>
> James
>
------------------------------
Message: 3
Date: Sun, 9 Sep 2007 09:04:54 -0700 (PDT)
From: Shahin Ansari <zohal52@yahoo.com>
Subject: [fw-wiz] Firewall Testing
To: firewall-wizards@listserv.cybertrust.com
Message-ID: <717714.87846.qm@web30709.mail.mud.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"
Greetings-
I have some questions regarding firewall testing:
1- Seems I am losing some syslog messages. I have kiwi on a xp pc, and most of time it is running at 100% so I know it is running full speed, and it is overloaded. My Goal is to capture the critical messages, and I am thinking of rate-limiting the other categories which I do not care about in hope to see the more critical messages. Any other suggestions?
2- I do have a good paper about capacity and througput testing of the firewall I am using, but it uses a commercial product. I love to see some papers about how folks use nmap, or nessus to test different aspects, like session ramp rate, max connections, max concurrent connections, embryonic limit, and other features a firwall admin should test?
---------------------------------
Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20070909/17d892a9/attachment-0001.html
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 17, Issue 8
***********************************************
No comments:
Post a Comment