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: static nat for inside returning traffic (Chris Myers)
3. Re: Firewalls that generate new packets.. (Dave Piscitello)
4. Re: Firewalls that generate new packets.. (jdgorin@computer.org)
5. Re: Firewalls that generate new packets.. (jdgorin@computer.org)
6. Re: Firewalls that generate new packets..
(lordchariot@embarqmail.com)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Nov 2007 17:39:24 +0300
From: ArkanoiD <ark@eltex.net>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20071119143924.GA27871@eltex.net>
Content-Type: text/plain; charset=koi8-r
On Sat, Nov 17, 2007 at 11:14:14AM -0600, Timothy Shea wrote:
> And organizations like the
> familiarity of the Pix (ASA) because everything else they have are
> Cisco devices.
Which always made me wonder: Pix have almost nothing common with IOS
routers except Cisco label on it. For ASA, things chaged a bit, but the
"firewall" part of the device is still the same.
------------------------------
Message: 2
Date: Tue, 20 Nov 2007 17:21:18 -0600
From: Chris Myers <clmmacunix@charter.net>
Subject: Re: [fw-wiz] static nat for inside returning traffic
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <8B167B74-BEB4-4B55-9C07-177A7F83E7C4@charter.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Either way NAPT or NAT you need a Static NAT from the a routable IP
address from your outside interface subnet to an internal IP address
if it is part of the RFC1918 for 1:1 NAT. You will need an ACL on the
outside pointed to the <external routable IP> from whatever. This is
only for hosts initiated to this host. The NAPT would add the port in
the static policy. The all 0's route (default route) will take care of
the outbound initiated access for your inside host. No need to put a
route in for any hosts on the Internet, and your global nat policy
will do the outbound NAT for your inside host going anywhere (many to
one NAT).
access-list foo permit tcp any host <external routable IP> eq
<whatever port> "the 'any' in this acl can be a host as well.
use: host <internet IP>
static (inside,outside) <external routable IP> <internal rfc 1918
addr> netmask 255.25.255.255
Just in case: if your inside host is a routable IP subnet (and paid
for) don't need NAT and you can put an outside ACL pointed directly to
the routable host on the inside. I am assuming you have a subnet on
the RFC1918.
Hope this clarifies it.
Thanks
Chris
On Nov 14, 2007, at 12:43 PM, Robert Fenech wrote:
> Hi Sean,
>
> I might be wrong but if you want to connect to an internal host from
> an external source you have to configure your PIX with static NAT and
> create appropriate access-rule entries. Hiding your internal host
> behind the PIX's external interface IP or any another global IP (PAT)
> to that
> matter would not work.
>
> However one thing you can do is port forwarding, whereby connections
> originating from an external source destined to the PIX's external
> interface IP (or any other global IP) on a specific port are forwarded
> to a specific internal host.
>
> On Nov 14, 2007 12:45 AM, Shahin Ansari <zohal52@yahoo.com> wrote:
>> Greetings-
>> I come across an issue which I can not explain and need your help
>> please.
>> I was trying to provide access to an inside host from outside. I
>> put in a
>> 1:1 static nat for the outside host, made sure there is a route for
>> both
>> hosts, and updated the outside interface access-list. But there
>> was no
>> connection. I also did not see any message in the logs. Just fyi,
>> this was
>> pix platform running 6.3(x). What seems to have fixed the issue
>> was an
>> static for the inside host. Which I did not think I need since
>> there is a
>> default nat statement on my inside interface translating everything
>> to an
>> global address. Any thoughts?
>> Sean
>>
>>
>> ________________________________
>> Be a better sports nut! Let your teams follow you with Yahoo
>> Mobile. Try it
>> now.
>>
>>
>> _______________________________________________
>> 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: Tue, 20 Nov 2007 08:49:35 -0500
From: Dave Piscitello <dave@corecom.com>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: jdgorin@computer.org
Cc: firewall-wizards@listserv.cybertrust.com
Message-ID: <4742E5EF.90206@corecom.com>
Content-Type: text/plain; charset="iso-8859-1"
ZOMG! That's true, they are not crappy.
Of course, if they are popularized and marketed as disruptive
technologies they will be "enhanced" and will devolve to crappy quite
rapidly and join the crappy club of HTTP/SIP/SNMP/SMTP/FTP/SSH/IPSEC...
jdgorin@computer.org wrote:
> Hi Dave,
>
> That's an easy challenge to answer:
> RFC 862 - ECHO Protocol
> RFC 863 - DISCARD Protocol
> RFC 864 - CHARGEN Protocol
>
> Those protocols are not crappy ;-)
> But, you can do nasty things with them...
>
> JDG
>
>> Dave Piscitello wrote:
>>
>> 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/20071120/121a6cc1/attachment-0001.bin
------------------------------
Message: 4
Date: Tue, 20 Nov 2007 14:22:58 +0100
From: jdgorin@computer.org
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: firewall-wizards@listserv.cybertrust.com
Cc: dave@corecom.com
Message-ID: <1195564978.4742dfb209c65@imp.free.fr>
Content-Type: text/plain; charset=ISO-8859-1
Hi Dave,
That's an easy challenge to answer:
RFC 862 - ECHO Protocol
RFC 863 - DISCARD Protocol
RFC 864 - CHARGEN Protocol
Those protocols are not crappy ;-)
But, you can do nasty things with them...
JDG
> Dave Piscitello wrote:
>
> 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).
------------------------------
Message: 5
Date: Tue, 20 Nov 2007 14:33:19 +0100
From: jdgorin@computer.org
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: firewall-wizards@listserv.cybertrust.com
Message-ID: <1195565599.4742e21fbd1d2@imp.free.fr>
Content-Type: text/plain; charset=ISO-8859-1
> Timothy Shea wrote:
>
> 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
Sorry Timothy, but if you refer to proxies firewall, the content *have to* be
inspected because proxy are at the application level...
The received packet goes up all the stack from IP to application level (HTTP,
SMTP, FTP, whatever...), then in an application gateway (it's just a new word
for a proxy, and it's the part which analyze, or inspect, the packet's content
compliance with the protocol definition and the security rules to enforce) then
a new protocol data unit goes out the application gateway and sends down the
stack to the IP level.
So, it's a full new packet going out of the proxy firewall.
Usually, deep packet inspection firewalls (a flavor of packet filters) do what
you describe.
JDG
------------------------------
Message: 6
Date: Thu, 15 Nov 2007 09:12:27 -0500
From: <lordchariot@embarqmail.com>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: "'Firewall Wizards Security Mailing List'"
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <6744EF532CAF48E49101B3E67413A8F6@lordchariot.com>
Content-Type: text/plain; charset="us-ascii"
That's pretty much the delineation between Packet-filtering firewalls and
Application-layer proxies.
Here's the lame analogy I use to explain it to management.
Let's say I need to cross the US-Canada border. If I drive, I get to the
border crossing, show my passport, talk to the guard and explain where/why
I'm going and usually just continue with a 'Have a Nice Visit' Comment. If
they are a 'Deep Inspection' border guard, sometimes they open the trunk to
take a peak inside, but since I'm not that suspicious, I've never had my
luggage opened despite the fact I could easily have smuggled contraband.
If my car (my packet) had anything attached to it that could be hazardous,
it would more than likely to get through and activate its maliciousness on
the other side.
If I fly instead. I leave my packet (car) at the airport. I go through
multiple identity checks. I have my payload (luggage) x-rayed, sometimes
opened and searched, my carry on gets swabbed for 'badness', every pocket,
zipper and crevass of my laptop case gets rubber-gloved. Sometimes they even
find my lighter. I finally get on the flight, go through the other side, go
through customs again, rent a car and drive to my destination. The original
packet (car) remains at home, but my payload and myself have been re-written
to the shiny new rental car.
Basically, I've been proxied. I told you it was lame, but it works for my
family and neighbors when I tell them what I do.
> -----Original Message-----
> From: firewall-wizards-bounces@listserv.icsalabs.com
> [mailto:firewall-wizards-bounces@listserv.icsalabs.com] On
> Behalf Of Kelly Robinson
> Sent: Tuesday, November 13, 2007 10:59 PM
> To: firewall-wizards@listserv.icsalabs.com
> Subject: [fw-wiz] Firewalls that generate new packets..
>
> 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
End of firewall-wizards Digest, Vol 19, Issue 15
************************************************
No comments:
Post a Comment