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 (D Sharp)
2. VPN Issue with Certs and fragmentation (Bell Simon (RBNA/CIT1.12))
3. Re: Isolating internal servers behind firewalls (Behm, Jeffrey L.)
4. Re: VPN Issue with Certs and fragmentation (Robby Cauwerts)
5. PIX 501 to PIX 515 IPSec VPN failure, when the 515 already
has a VPN (Jerry B. Altzman)
----------------------------------------------------------------------
Message: 1
Date: Tue, 11 Sep 2007 10:11:52 -0700
From: D Sharp <drsharp@pacbell.net>
Subject: Re: [fw-wiz] Isolating internal servers behind firewalls
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <46E6CC58.5010108@pacbell.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Dan Lynch wrote:
>Greetings list,
>
>I'm looking for opinions on internal enterprise network firewalling. Our
>environment is almost exclusively Microsoft Active Directory-based.
>There are general purpose file servers, AD domain controllers, SMS
>servers, Exchange servers, and MS-SQL-based datase app servers. In all
>about 80+ servers for over 2500 users on about 2000 client machines, all
>running Windows XP.
>
>
>
Currently we are pushing 4500 desktops and 350+ servers. In house
developers and offshore.
Just a few UNIX servers.
>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?
>
>
>
My perspective, yes have done this and wil continue to.
The benefits should be aligned or justified by known risks. Thus you
should have the support of your risk group/IT auditors.
The threats you are protected from have more to do with how you
implement the filters to achieve the risk reduction.
MS Windows and other vendors have made this extermely difficult. Its not
just port 139 or 445. Its Oracle OEM with poor port documentation, or
VMware with its vague port documentation.
Don't know if this will ever happen again, but the Symantec port attack
provides some insight:
Hit by a single corporate laptop from remote (the AV was not up to
date) which infected all the non network filtered servers and many desktops.
The only non-infected Windows servers left, were those in
non-production behind a firewall, where we only allowed them to pull
their AV updates, no pushes. And no file shares to production.
In the cleanup, the Windows group identified the blocking of push
capability as a hinderance to their speed to recovery. They felt that
they would have to spend to much time using remote desktop into the each
server to trigger the AV updates and verifying the updates. But then
the AV software does support scheduled pulls for AV updates.
Maybe your company needs the meltdown of its Windows infrastucture to
help your argument.
But be sure you can capture the likely root cause, otherwise you will
likely face the "you can't prove that implementing LAN segmentation
would prevent anything".
>On the other hand, the server team counters that
>
>- troubleshooting problems becomes more difficult
>
>
I found this comes down to, we need help debugging possible server
problems, but don't want to ask others for help.
>- firewall restrictions on which workstations can perform administration
>makes general maintenance inconvenient, esp. in an emergency
>
>
This can be identified and made part of the DR recovery.
Or this is really that you have not assisted them with defining where
administration can be performed and or how it can be identified/tracked.
>- the threats we're countering are exceedingly rare
>
>
I guess this is the "Black Swan" issue. Its difficult for me (server
admins) to quantify, so just accept the risk.
But then the server admins are not the "Risk" group, nor are they the
likely 'data owners'.
>- a broken (or hacked) firewall config breaks all access to servers if
>consolidated behind firewalls
>
>
I am having to deal with the following at present:
a: Filters slow the deployment process of servers on the network.
IE. we now have VMware and can deploy in hours, yet filters take days to
develope. Windows group wants 'all standard' Windows ports opened across
enterprise to provide them with agility/speed.
b: Windows group has deployed a chassis mangement server. But wants
to use that mangement software to manage all printers, and query network
devices. So they would like all 'standard' ports opened throughout the
enterprise, so that new devices under management do not require firewall
changes.
Summary:
Can segmenting/filtering network level provide a greater level of
risk reduction?
It depends.
If you don't have a written policy on restricting access to
what is needed, then you have not justified to the company this is needed.
If you don't get buy in from managment level above server
adminstration, then its just a inter-departmental argument or agreement.
If you don't review every port request for risk, and deny
those that are risky, then you are just tracking the traffic good/bad.
Do you intend to expend the resources it takes to ensure the
above?
Yours,
Duncan Sharp
>Any and all thoughts are appreciated.
>
>
>Dan Lynch, CISSP
>Information Technology Analyst
>County of Placer
>Auburn, CA
>_______________________________________________
>firewall-wizards mailing list
>firewall-wizards@listserv.icsalabs.com
>https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
>
>
------------------------------
Message: 2
Date: Tue, 11 Sep 2007 13:48:04 -0500
From: "Bell Simon (RBNA/CIT1.12)" <Simon.Bell@us.bosch.com>
Subject: [fw-wiz] VPN Issue with Certs and fragmentation
To: <firewall-wizards@listserv.cybertrust.com>
Message-ID:
<46BC68B9582AE944BE04A833806C85A501413175@mtpmail03.us.bosch.com>
Content-Type: text/plain; charset="us-ascii"
We occasionally have customers call in reporting that they're never
prompted for credentials when attempting to connect to the VPN. This
happens most often when they're at a hotel/public hotspot. However, if
they use a profile based on a preshared key instead of a cert
authentication, they connection works w/o issue. I've captured traffic
off a failed user and it looks like during a cert auth IPSec tunnel
there's a fair amount of packet fragmentation. I'm guessing then that a
router in-between is probably just dropping those packets causing phase1
to fail. Has anyone else seen something similar to this? I'm thinking
dropping the MTU on either our public interface or on the client
directly.
Any other suggestions shared experiences would be great,
Simon
------------------------------
Message: 3
Date: Tue, 11 Sep 2007 22:24:18 -0500
From: "Behm, Jeffrey L." <BehmJL@bv.com>
Subject: Re: [fw-wiz] Isolating internal servers behind firewalls
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.cybertrust.com>
Message-ID:
<0C3670BC9169B244AA6E7B2E436180D1F9BC84@TSMC-MAIL-04.na.bvcorp.net>
Content-Type: text/plain; charset="iso-8859-1"
On Tue 9/11/2007 12:11 PM, D Sharp said:
Summary:
> Can segmenting/filtering network level provide a greater level of risk reduction?
> If you don't review every port request for risk, and deny
> those that are risky, then you are just tracking the traffic good/bad.
Although "risky" is a relative, and not a universally defined, term, the question remains: "Is Windows file sharing risky?"
1) If one thinks Windows file sharing is risky, then that traffic to the protected servers must be denied. If it is denied, then why have Windows file servers?
2) If one thinks Windows file sharing is not risky, then I have no basis to argue the point any further.
I suppose you could prevent meltdown by blocking everything that is risky, but then you have a network that doesn't function, either.
I used to think that segmenting/filtering *could* provide a greater level of risk reduction. In a perfect environment, it could. However, in the real world, where $$$ talk, I don't believe that is the case(maybe I'm already becoming too crusty at age 42?). Environments are sometimes very dynamic, and maintenance of the environment gets pushed down to the low man/woman on the totem pole, because the senior folks are too busy fighting the fire du' jour, or designing the next big thing, and don't have time to mess with such mundane tasks as maintenance of rules. Those (less expensive folks) left to do the maintenance typically have less experience, and are more apt to make a human error when implementing the filtering rules. One typo that goes unchecked (because checking it costs even more $$$), and the firewall is wide open.
Jeff (no personal attacks were implied - hopefully it comes across that way)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4993 bytes
Desc: not available
Url : https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20070911/af5224ac/attachment-0001.bin
------------------------------
Message: 4
Date: Wed, 12 Sep 2007 09:05:44 +0200
From: "Robby Cauwerts" <robby@cauwerts.be>
Subject: Re: [fw-wiz] VPN Issue with Certs and fragmentation
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.cybertrust.com>
Message-ID:
<2ca18af0709120005t7bcfea57k4fcc7aae5c4ed9be@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On 9/11/07, Bell Simon (RBNA/CIT1.12) <Simon.Bell@us.bosch.com> wrote:
>
> We occasionally have customers call in reporting that they're never
> prompted for credentials when attempting to connect to the VPN. This
> happens most often when they're at a hotel/public hotspot. However, if
> they use a profile based on a preshared key instead of a cert
> authentication, they connection works w/o issue. I've captured traffic
> off a failed user and it looks like during a cert auth IPSec tunnel
> there's a fair amount of packet fragmentation.
>
The fragmentation can be solved by using IKE over tcp.
What type of vpn (vendor) are you using?
Br.
Robby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20070912/27fd73c5/attachment-0001.html
------------------------------
Message: 5
Date: Wed, 12 Sep 2007 10:54:36 -0400
From: "Jerry B. Altzman" <jbaltz@altzman.com>
Subject: [fw-wiz] PIX 501 to PIX 515 IPSec VPN failure, when the 515
already has a VPN
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <46E7FDAC.9050407@altzman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I wonder if any of you have encountered this problem before with
PIX<->PIX VPNs.
A client of mine has 3 firewalls: a Fortigate, a 515 and a 501. The 515
and FG already have an IPSec lan-to-lan VPN between them that works fine.
We'd like to set up a mesh of L2L VPNs, but first steps first: we need
to connect the 515 to the new 501.
I've gone through the configurations, followed the directions from
cisco's website, cleared everything out and done everything *but*
restarted the 515 (which is in production and might cause some
consternation if it were rebooted willy-nilly)
I've watched the logging output, and it doesn't seem that the 501/515
pair even attempt to do the phase 1 IPSec negotiations. It's just that
NOTHING happens at all.
Has anyone seen this? Any received wisdom on this? My search-engine-fu
must be weak, I've not managed to tease out a solution to this from the
all-seeing GoogleEye.
Thanks!
//jbaltz
--
jerry b. altzman jbaltz@altzman.com
www.jbaltz.com
thank you for contributing to the heat death of the universe.
------------------------------
_______________________________________________
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 11
************************************************
No comments:
Post a Comment