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 assessment (Nate Itkin)
2. RE: Different Authentication For vpngroups On PIX (Paul Melson)
3. RE: PIX assessment (Paul Melson)
--__--__--
Message: 1
Date: Wed, 5 Oct 2005 09:13:44 -1000
From: Nate Itkin <firewall-wizards@konadogs.net>
To: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] PIX assessment
Reply-To: firewall-wizards@konadogs.net
> On Mon, Sep 26, 2005 at 06:43:56AM -0700, vulnerable wrote:
> hello all.
> I'm doing an assessment on the config of a pix running 6.3. Me not
> being much of a pix expert have a few questions.
> From reading documentation it is my understanding that if you have
> traffic flowing from inside (higher security level) to dmz (lower
> security level) interface then you will not require either an ACL or a
> static statement permitting this.
By default, all connections initiated on a network with a higher security
level are allowed out, and you configure any restrictions required.
> However, this particular config is
> declaring transparent static's that the documentation I've read says
> is unnecessary. Any reasons why they may be doing this? I'm going
> through a rather long config (3000+ lines), and running some perl mojo
> I find that there are over 300 statics defined for addresses behind
> the inside interface. Useless? Something that perhaps the PDM does?
The static command creates a one-to-one address translation rule (called
a static translation slot or "xlate"). Translation slots do not permit
or deny traffic. The default ACL that permits all connections initiated
on a network with a higher security level allows the traffic to pass. The
translation slots may have been created to map specific hosts and/or ports
on the higher security interface(s) to specific hosts and/or ports on the
lower security interface(s).
> Oh, I've also been trying to track down the latest rev of pixOS 6.3.
> Can't find it anywhere on cisco's public site.
You get to pay Cisco unless you have a maintenance contract.
> Also, I've been using the enterastream documentation (1) as a
> reference, is there anything else out there that is worth looking at?
> 1) http://www.enterastream.com/whitepapers/cisco/pix/pix-practical-guide.html
Manuals for the PIX Firewall Software can be found here:
http://www.cisco.com/en/US/products/sw/secursw/ps2120/tsd_products_support_series_home.html
- Nate Itkin
--__--__--
Message: 2
From: "Paul Melson" <pmelson@gmail.com>
To: "'Mike Bydalek'" <mbydalek@contentconnections.com>,
<firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Different Authentication For vpngroups On PIX
Date: Wed, 5 Oct 2005 15:16:31 -0400
-----Original Message-----
> Let me then take this and change my question a little. What I am trying
to do is have
> a server automatically VPN in, backup some files, and then disconnect. In
order to do > this, one of the options is storing the user/pass on the
server (not the best idea in
> the world, but if I have to, I have to). So, what would then be the best
way to setup
> for this scenario?
This type of thing is probably better handled through a typical peer-to-peer
tunnel if it's possible. (http://www.cisco.com/warp/public/707/2000.html)
Then you can use certificates to authenticate the endpoints to each other
and you don't support a 'hack' like having to attrib +r the VPN Client .PCF
file to keep the client from removing the RADIUS password (which is the
other option - very much NOT recommended).
PaulM
--__--__--
Message: 3
From: "Paul Melson" <pmelson@gmail.com>
To: "'vulnerable'" <vulnerable@gmail.com>,
<firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] PIX assessment
Date: Wed, 5 Oct 2005 15:16:31 -0400
-----Original Message-----
Subject: [fw-wiz] PIX assessment
> From reading documentation it is my understanding that if you have traffic
flowing from
> inside (higher security level) to dmz (lower security level) interface
then you will
> not require either an ACL or a static statement permitting this. However,
this
> particular config is declaring transparent static's that the documentation
I've read
> says is unnecessary. Any reasons why they may be doing this? I'm going
through a
> rather long config (3000+ lines), and running some perl mojo I find that
there are over
> 300 statics defined for addresses behind the inside interface. Useless?
Something
> that perhaps the PDM does?
Don't get static statements and access-lists confused. A static, nat, or
global command is a NAT command and nothing more. It is security-neutral.
An access-list that is assigned to an interface via an access-group command
becomes a filter for packets arriving at that interface. An access-list
without an access-group command can be used to configure VPN tunnels (crypto
map match) global NAT pools, etc.
Without seeing the commands in some sort of context, I don't know that they
are unnecessary, though if there are 300 of them then there may be a more
efficient way to write them. Maybe you've got some
safe-for-public-consumption examples you can share?
> Oh, I've also been trying to track down the latest rev of pixOS 6.3.
> Can't find it anywhere on cisco's public site.
Last I checked, it's not public. I believe you will need a CCO login that's
associated with one or more Cisco products that can run PIX OS. The
customer should have something like this if they ever had a SmartNet
contract for their PIX or even registered it. They should still be able to
download PIX OS updates even if SmartNet has lapsed.
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