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: Firewalls that generate new packets.. (ArkanoiD)
2. Re: Issue with replacing SonicWall VPN with Cisco ASA VPN
devices (Chris Myers)
3. Re: Firewalls that generate new packets.. (Dave Piscitello)
4. Re: Firewalls that generate new packets.. (Timothy Shea)
5. Re: Firewalls that generate new packets.. (pkc_mls)
----------------------------------------------------------------------
Message: 1
Date: Sat, 17 Nov 2007 21:08:21 +0300
From: ArkanoiD <ark@eltex.net>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: dave@corecom.com, Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20071117180821.GA29545@eltex.net>
Content-Type: text/plain; charset=koi8-r
As another blatant advertisement, my http logs indicate that some people
still downoad OpenFWTK snapshots from milliways.chance.ru/~ark ,
though i explicitly stated that those are outdated. Referrer field
is often firewall-wizards archive. Please do not,
openfwtk home is http://www.sourceforge.net/projects/openfwtk !
On Sat, Nov 17, 2007 at 10:05:34AM -0500, Dave Piscitello wrote:
>
> Commercial examples include Watchguard FireboxX and Secure Computing
> Sidewinder. The original firewall toolkit evolved into one of my
> favorite firewalls, the TIS Gauntlet. Network Associates bought TIS,
> then NAI sold the Gauntlet to Secure Computing, who I believe offered
> the Gauntlet on Solaris but has phased out the product. Sad, I really
> loved running Gauntlet on BSD.
>
> Matthew Hannigan wrote:
> >On Wed, Nov 14, 2007 at 02:58:37PM +1100, Kelly Robinson wrote:
> >>Some firewalls, after receiving a packet, generate a new packet and
> >>populate
> >>it with data from the original, rather than forwarding the same packet
> >>that
> >>was received. What are the advantages and disadvantages of this approach?
> >>And does anyone have any examples of any firewalls that do this on the
> >>market?
> >
> >I guess all proxying fireawalls like the original fwtk do this.
> >
> >Advantage:
> >
> >Your firewall is more trusted not to do funky stuff
> >that might upset internal servers.
> >
> >Directly concomitant disadvantage:
> >
> >The packet may not be an entirely faithful
> >version of the original (besides the obvious
> >source addr/port)
> >
> >
> >
> >
> >_______________________________________________
> >firewall-wizards mailing list
> >firewall-wizards@listserv.icsalabs.com
> >https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
> >
>
> email protected and scanned by AdvascanTM - keeping email useful -
> www.advascan.com
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
------------------------------
Message: 2
Date: Sun, 18 Nov 2007 21:19:05 -0600
From: Chris Myers <clmmacunix@charter.net>
Subject: Re: [fw-wiz] Issue with replacing SonicWall VPN with Cisco
ASA VPN devices
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Cc: "Behm, Jeffrey L." <BehmJL@bv.com>, michael@wanderingbark.net,
firewall-wizards-bounces@listserv.icsalabs.com
Message-ID: <C954C76A-BE36-4BA4-9965-2D38EE86398D@charter.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
You will setup the ACL's you will have named for your crypto-map map
<whatever> match address vpn_acl_HQ. They will have to be subnets
because you are defining trusted subnets for the site-2-site. (access-
list vpn_acl_HQ permit ip 10.1.1.1 255.255.255.0 10.0.0.0
255.255.255.0). Even with the intra/inter-face same security level you
will still have to setup No NAT (nat (inside) 0 access-list nonat)
(access-list nonat permit ip 10.1.1.1 255.255.255.0 10.0.0.0
255.255.255.0) policies for the traffic to not nat over the VPN. I am
assuming you are using the 'outside' interface for the VPN peer, hence
security levels will be different. The only risk involved with this is
if the branch offices are using there own internet connection where
you get all the virus' (all 0's route out there own router to the
internet) and not using HTTP/HTTPS over the VPN to HQ, which it sounds
like, because this will give carte blanche to any worm or attack that
is successful in the branch office to propogate to the HQ. If you are
only using the HQ for certain traffic, then define that traffic and
only allow it over the VPN via ACL and not use 'ip' for the ACL. If
this is not feasible, then get another PIX and use it strictly for VPN
let the IP traffic traverse it for simplistic setup reasons and create
a transit between the two boxes on a dmz or inside interface with
specific ACL's for the traffic you want to hit the HQ.
Hope this helps!
On Sep 27, 2007, at 10:46 AM, robbie.jacka@regions.com wrote:
> Caveat: this has only been fixed in 7.2(1) and later, if memory
> serves.
>
> Robbie
>
>
>
>
> Anthony
> <ez4me2c3d@gmail.
>
> com> To
> Sent by: Firewall Wizards Security
> Mailing
> firewall-wizards- List
> bounces@listserv. <firewall-wizards@listserv.icsalabs
> icsalabs.com .com>
> cc
> "Behm, Jeffrey L." <BehmJL@bv.com
> >,
> 09/26/2007 07:33 firewall-wizards-bounces@listserv.i
> PM csalabs.com,
> michael@wanderingbark.net
>
> Subject
> Please respond to Re: [fw-wiz] Issue with
> replacing
> Firewall Wizards SonicWall VPN with Cisco ASA
> VPN
> Security Mailing devices
> List
> <firewall-wizards
> @listserv.icsalab
> s.com>
>
>
>
>
>
>
> Robbie,
> The ASA code 7.x has addressed VPN hairpinning with the
> same-security-traffic permit intra-interface command.
> I've done it several times with great success. And with proper ACLs
> and
> routes you can direct the traffic where ever you want.
>
> Jeff,
> What you are trying to do is possible on the ASAs. You're basically
> setting up a hub/spoke vpn model with l2l's between HQ and remote
> offices. Cisco.com has documents on how to set this up.
>
> References:
> http://www.cisco.com/en/US/partner/products/ps6120/products_configuration_example09186a00807f9a89.shtml
>
> http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2030/products_configuration_example09186a00804675ac.shtml
>
> General Configuration Examples
> http://www.cisco.com/en/US/partner/products/ps6120/prod_configuration_examples_list.html
>
>
> Anthony
>
>
> robbie.jacka@regions.com wrote:
>> The biggest possible issue is hairpinning the internet-bound traffic
> inside
>> of the 5520, not tunneling the traffic back from the 5505s. PIX 6.x
>> has
>> traditionally had a problem with this, if I recall correctly, and
>> I'm not
>> sure that it's been fixed in PIX 7.x/ASA code
>>
>> Robbie
>>
>>
>>
>>
>
>> Michael Cox
>
>> <michael@wanderin
>
>> gbark.net>
> To
>> Sent by:
> firewall-wizards@listserv.icsalabs.
>> firewall-wizards- com
>
>> bounces@listserv.
> cc
>> icsalabs.com "Behm, Jeffrey L." <BehmJL@bv.com
>> >
>
>>
> Subject
>> Re: [fw-wiz] Issue with
>> replacing
>
>> 09/26/2007 09:25 SonicWall VPN with Cisco ASA
>> VPN
>
>> AM devices
>
>>
>
>>
>
>> Please respond to
>
>> Firewall Wizards
>
>> Security Mailing
>
>> List
>
>> <firewall-wizards
>
>> @listserv.icsalab
>
>> s.com>
>
>>
>
>>
>
>>
>>
>>
>>
>> For clarification, are there clients connecting to the 5505's, or
>> is it
>> just a site-to-site setup?
>>
>> In any case, what you want to do should be possible. When you
>> define the
>> ACL for what traffic goes down the tunnel from the branch to the hub,
>> simply do "permit ip <LAN network address> <LAN netmask> any".
>> Reverse
>> this on the hub.
>>
>> I'm stumped as to why they think this is a security issue.
>>
>> Maybe TAC didn't understand what you want to do (or maybe I don't).
>>
>> Regards,
>> Michael
>>
>> On Tuesday 25 September 2007 09:03, Behm, Jeffrey L. wrote:
>>
>>> Hello Wizards,
>>>
>>> Our network team is replacing the client's SonicWall devices with
>>> Cisco ASA 5505 (remote office) and 5520 (HQ) devices. The SonicWall
>>> devices were basically used as VPN endpoints in remote offices to be
>>> concentrated back to the corporate HQ. All traffic not destined for
>>> the local LAN in the remote offices was sent to the corporate office
>>> via the "Route all traffic through this SA" functionality in the
>>> SonicWall. This worked well for the environment, but now there is
>>> the
>>> need to replace these devices, and Cisco ASA devices have been
>>> chosen.
>>>
>>> They are now trying to duplicate that functionality via the Cisco
>>> devices, but in talking with Cisco TAC, they say such a
>>> configuration
>>> is not possible, and even if it were, it would not be a security
>>> best
>>> practice. Implementation of the Cisco device has broken all Internet
>>> connectivity from the remote offices, since the only traffic allowed
>>> out to/from the Internet is through HQ (with the exception of the
>>> site to site VPN traffic to allow connectivity between remote
>>> offices
>>> and HQ). Remote offices can see everything on the HQ LAN, because
>>> the
>>> Cisco device is configured with IP information that allows it to
>>> route traffic to HQ.
>>>
>>> I can see some of Cisco's arguments regarding it not being a
>>> security
>>> best practice, but in the scenario of centralized management and
>>> monitoring of Internet-bound traffic, has anyone successfully
>>> configured the Cisco devices to mimic the "Route all traffic through
>>> this SA" functionality present in the SonicWall devices? I
>>> understand
>>> they could open up the Cisco devices to allow traffic out from each
>>> office, but that would require monitoring every remote office, and
>>> deviates from the centralized monitoring/management path we are
>>> currently traversing. I haven't personally been involved in this
>>> implementation, but was approached by the network team due to my
>>> security background, so I can get more details from the network team
>>> if necessary.
>>>
>>> We are simply trying to mimic in the Cisco devices the "Route all
>>> traffic through this SA" functionality present in the SonicWall
>>> devices.
>>>
>>> Thoughts?
>>>
>>> Jeff
>>> _______________________________________________
>>> firewall-wizards mailing list
>>> firewall-wizards@listserv.icsalabs.com
>>> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>>>
>> _______________________________________________
>> firewall-wizards mailing list
>> firewall-wizards@listserv.icsalabs.com
>> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>>
>>
>> _______________________________________________
>> firewall-wizards mailing list
>> firewall-wizards@listserv.icsalabs.com
>> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>>
>>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
------------------------------
Message: 3
Date: Sat, 17 Nov 2007 20:17:41 -0500
From: Dave Piscitello <dave@corecom.com>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <473F92B5.1080209@corecom.com>
Content-Type: text/plain; charset="iso-8859-1"
LOLZ
I can quickly identify LOTS of crappy protocols running over TCP/IP and
UDP/IP.
Give me an example of one you think is *not* crappy:-)
Paul Melson wrote:
> The downside is that this can break crappy protocols (or even normal
> protocols in the case of a misconfigured firewall).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dave.vcf
Type: text/x-vcard
Size: 220 bytes
Desc: not available
Url : https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20071117/6bd0afce/attachment-0001.bin
------------------------------
Message: 4
Date: Sat, 17 Nov 2007 11:14:14 -0600
From: Timothy Shea <tim@tshea.net>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <49AD9E70-5E0D-479E-BB25-3825F163205B@tshea.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hi Kelly,
Lets say I am kind of disappointed. I figured that your question kick
off a "proxy" versus "everything else" type "discussion". It didn't .
Ah the 90s.... good times good times...
What I believe you are referring too when you talk about "generate a
new packet ... " is a proxy firewall. This is a piece of code that
will take the original packet, suck out the contents, (the content may
be inspected at this point but rarely happens), build a new packet,
blow the content back into the new packet, and send it along its way
(assuming it meets other criteria such as being allowed, valid, etc).
Commercial examples of this type of firewall are Sidewinder or
Symantec Enterprise Firewall (formally known as Raptor). The other
type of firewall (and market leader) would be "stateful". Examples of
this would be Checkpoint, Pix (ASA), and pretty much every kitchen
appliance these days.
What would be the advantage of this approach? Well - the primary
advantage would be that there is no "direct" path to the service that
you need to talk to. This is helpful especially in the days where IP
stacks were poorly written and attacks against them were more
realistic. If you use an application specific proxy (http, smtp, etc)
then you have an improved level of packet validation. This could be
helpful to protect against potential unknown attacks against
applications. There are a few more but I don't think they are that
relevant.
What would be a disadvantage? Some say performance. I never bought
that argument. Its a sizing issue. The firewalls I've dealt with
that handled the highest amount of packets were proxies. Other say
price. This is a true argument - commercial proxy firewalls were
traditionally a higher pricepoint than their stateful counterparts.
I've done a lot of firewall conversions in the last few years. The
primary reason organizations cited as a reason to move away from proxy
firewalls was management. If you have to manage more than, say, one
firewall - the management interfaces of the two market leaders in the
proxy space have always fallen down (read: royally sucks). Checkpoint
has always done a better job at this. And organizations like the
familiarity of the Pix (ASA) because everything else they have are
Cisco devices. Whether its a better option in "securing" whatever you
are trying to "secure" rarely enters the discussion.
In the end, stateful and proxy firewalls will both do the job that we
ask firewalls to do and are only one component of an overall security
architecture.
cue "discussion"
t.s
On Nov 13, 2007, at 9:58 PM, Kelly Robinson wrote:
> Some firewalls, after receiving a packet, generate a new packet and
> populate it with data from the original, rather than forwarding the
> same packet that was received. What are the advantages and
> disadvantages of this approach? And does anyone have any examples of
> any firewalls that do this on the market?
>
> Thanks
>
> - k
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
------------------------------
Message: 5
Date: Thu, 15 Nov 2007 15:54:25 +0100
From: pkc_mls <pkc_mls@yahoo.fr>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <473C5DA1.1080903@yahoo.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Kelly Robinson a ?crit :
> Some firewalls, after receiving a packet, generate a new packet and
> populate it with data from the original, rather than forwarding the
> same packet that was received. What are the advantages and
> disadvantages of this approach? And does anyone have any examples of
> any firewalls that do this on the market?
>
depending on where the packet has to be forwarded, sometimes you need to
change settings (for example fragmentation or mss), so the firewall
needs to rearrange, unfragment the communications.
in most cases you can set how the firewall behaves.
> Thanks
>
> - k
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 19, Issue 14
************************************************
No comments:
Post a Comment