Send firewall-wizards mailing list submissions to
firewall-wizards@honor.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@honor.icsalabs.com
You can reach the person managing the list at
firewall-wizards-admin@honor.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: Pix VPN endpoint and split-tunnel (Paul Melson)
2. RE: Pix VPN endpoint and split-tunnel (Hughes, Chris)
3. RE: Pix VPN endpoint and split-tunnel (Paul Melson)
4. Legal Release for Security Work (Christopher Hicks)
5. RE: Rule management process (Paul Melson)
--__--__--
Message: 1
From: "Paul Melson" <pmelson@gmail.com>
To: "'Hughes, Chris'" <Chris.Hughes@thalescomminc.com>,
<firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Pix VPN endpoint and split-tunnel
Date: Wed, 12 Oct 2005 10:45:10 -0400
-----Original Message-----
Subject: [fw-wiz] Pix VPN endpoint and split-tunnel
> I am trying to configure a cisco pix as a vpn endpoint for the cisco vpn
client and
> would like to force the client to use the corporate network for internet
access. I
> don't want to allow split-tunnel. I cant find any info on how to do this.
Is split
> tunnel the only way to give a vpn client internet access once they are
connected?
The short answer is yes. PIX-fu rule #1: the PIX is not a router. It can't
take traffic that arrives on one interface and pass it back out that same
interface, even when the traffic arrives via VPN tunnel. That said, you can
sort of solve this problem by having the clients use a proxy server while
connected via full tunnel. There may or may not be an elegant way to
automate this for your road warriors, but this would really be independent
of anything the PIX or VPN client do. (Think login scripts, Group Policy,
etc.)
If it's a big enough issue that you're willing to spend time and resources
on it, I would recommend looking at the VPN3K concentrators (or ASA 5500?).
They can do exactly what you're asking for, plus they possess a number of
other features for managing VPN client users that the PIX doesn't have.
(Like dynamic VPN profile assignment via RADIUS.)
PaulM
--__--__--
Message: 2
Subject: RE: [fw-wiz] Pix VPN endpoint and split-tunnel
Date: Wed, 12 Oct 2005 11:23:47 -0400
From: "Hughes, Chris" <Chris.Hughes@thalescomminc.com>
To: "Paul Melson" <pmelson@gmail.com>,
<firewall-wizards@honor.icsalabs.com>
That's pretty much what I read. I thought they may have provided a fix
by now. As for the workarounds, this is for a business partner network
and I've already presented them with the "spend" option and they don't
want to.
Another reply I got here from Simon expressed the possibility that PIX
7.x supports this. (split horizon?)
Anybody?
- Chris=20
-----Original Message-----
From: Paul Melson [mailto:pmelson@gmail.com]=20
Sent: Wednesday, October 12, 2005 10:45 AM
To: Hughes, Chris; firewall-wizards@honor.icsalabs.com
Subject: RE: [fw-wiz] Pix VPN endpoint and split-tunnel
-----Original Message-----
Subject: [fw-wiz] Pix VPN endpoint and split-tunnel
> I am trying to configure a cisco pix as a vpn endpoint for the cisco
vpn
client and=20
> would like to force the client to use the corporate network for
internet
access. I=20
> don't want to allow split-tunnel. I cant find any info on how to do
this.
Is split=20
> tunnel the only way to give a vpn client internet access once they are
connected?
The short answer is yes. PIX-fu rule #1: the PIX is not a router. It
can't
take traffic that arrives on one interface and pass it back out that
same
interface, even when the traffic arrives via VPN tunnel. That said, you
can
sort of solve this problem by having the clients use a proxy server
while
connected via full tunnel. There may or may not be an elegant way to
automate this for your road warriors, but this would really be
independent
of anything the PIX or VPN client do. (Think login scripts, Group
Policy,
etc.)
If it's a big enough issue that you're willing to spend time and
resources
on it, I would recommend looking at the VPN3K concentrators (or ASA
5500?).
They can do exactly what you're asking for, plus they possess a number
of
other features for managing VPN client users that the PIX doesn't have.
(Like dynamic VPN profile assignment via RADIUS.)
PaulM
This email and any files transmitted with it are confidential and are int=
ended solely for the use of the individual or entity to whom they are add=
ressed. This communication represents the originator's personal views and=
opinions, which do not necessarily reflect those of Thales Communication=
s, Inc. If you are not the original recipient or the person responsible f=
or delivering the email to the intended recipient, be advised that you ha=
ve received this email in error, and that any use, dissemination, forward=
ing, printing, or copying of this email is strictly prohibited. If you re=
ceived this email in error, please immediately notify Administrator2@Thal=
escomminc.com.
--__--__--
Message: 3
From: "Paul Melson" <pmelson@gmail.com>
To: "'Hughes, Chris'" <Chris.Hughes@thalescomminc.com>,
<firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Pix VPN endpoint and split-tunnel
Date: Wed, 12 Oct 2005 14:44:04 -0400
-----Original Message-----
Subject: RE: [fw-wiz] Pix VPN endpoint and split-tunnel
> That's pretty much what I read. I thought they may have provided a fix by
now. As for
> the workarounds, this is for a business partner network and I've already
presented them
> with the "spend" option and they don't want to.
>
> Another reply I got here from Simon expressed the possibility that PIX 7.x
supports
> this. (split horizon?)
RIPv2 (and therefore split horizon routing) are available as part of Cisco
ASA 7.0. It's my understanding that this is actually an adaptation of the
VPN3K software. But unless something has changed recently, this software
will only work on the ASA 5500 models, which will still cost your business
partner money. Sorry, no free lunch for them.
PaulM
--__--__--
Message: 4
Date: Thu, 13 Oct 2005 05:28:32 -0400 (EDT)
From: Christopher Hicks <chicks@chicks.net>
To: Firewall Wizards Mailing List <firewall-wizards@honor.icsalabs.com>
Cc: Marcus J Ranum <mjr@ranum.com>
Subject: [fw-wiz] Legal Release for Security Work
I've been asked to do some pure security consulting. This is a bit
unusual for me since usually security consulting ends up being part of
appdev or other consulting. Given that this is a new relationship and I
don't have the comfort of having done previous business with these folks
I'd like to work up something that covers the bases legally speaking.
Does anybody have a boilerplate for this sort of thing lying around that
you'd be willing to share? I don't want the result to be lawyer-sounding,
but I will merrily translate the lawyer into human if that's all you've
got. :)
--
</chris>
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
--__--__--
Message: 5
From: "Paul Melson" <pmelson@gmail.com>
To: "'Bret Watson'" <bret.watson@ticm.com>,
<firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Rule management process
Date: Thu, 13 Oct 2005 09:25:03 -0400
-----Original Message-----
Subject: [fw-wiz] Rule management process
> we are in the last stages of our SSE-CMM lvl1 process improvement.
> One last thing I'm a little stuck on is developing a process for ensuring
our rule set > is i. sensible, ii. optimised and iii. does not have unused
rules.
>
> Has anyone else done something like this ?
I would start with documenting a specific scope and business need for all
current rules and require that all future rules be documented in the same
way. This doesn't need to be especially long or detailed, just a summary of
what business function the rule serves to support. If it's a specific
project or application, note that as well. Depending on the type(s) of
firewall(s) being documented, it may be possible - and is in fact a good
idea - to put some version of this information in a comment field in the
actual firewall config. This will help in administration and auditing down
the road. It may also be a good idea to consider some sort of review and
approval process. It never hurts to have work double-checked for both
technical and design missteps *before* it's put into production.
As far as optimizing the rule set, I would think about doing regular audits
of your firewall configs (at least annually). This can be documented in a
short report and should reference any change requests or other documentation
of remediation efforts that you undertake. The goal should be to make sure
that you don't have redundant or obsolete rules (see below), and that rules
follow the theory of least privilege.
As far as unused rules go, the process and documentation you create for
managing new rule creation should help reduce these, but things expire.
Again, depending on the firewall(s) you're working with, the devices
themselves may keep track of how often the rule is used. (If you want to
talk specifics, list members can help with that, too.) This is the best
avenue to pursue because it means not having to search through possibly even
gigs of log data trying to match traffic to rules. Plus, anytime you can
document something right from the source, that's a good thing.
Since you're doing SSE-CMM Level 1 right now, you have a lot of flexibility
to define and experiment with what works for you. I'd recommend trying a
few different things along the way. You should also focus on doing the
planning and documentation that would be appropriate for Level 2 as you go.
If your organization pursues higher levels of SSE-CMM, you'll be glad you
spent the time trying to find what works well for you instead of just
getting it done. It will make the difference between SSE-CMM being a
valuable undertaking for you and it just being more overhead to your actual
work.
PaulM
--__--__--
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest
No comments:
Post a Comment