firewall-wizards Digest, Vol 19, Issue 30

Send firewall-wizards mailing list submissions to
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.. (Darren Reed)
2. Re: Firewalls that generate new packets.. (Darren Reed)
3. Re: Firewalls that generate new packets.. (Patrick M. Hausen)
4. Re: Firewalls that generate new packets.. (Patrick M. Hausen)
5. Re: Firewalls that generate new packets.. (Patrick M. Hausen)
6. Re: Firewalls that generate new packets.. (Jerry B. Altzman)
7. Re: DMZ to INSIDE Communication (Ian Mahuron)

----------------------------------------------------------------------

Message: 1
Date: Wed, 28 Nov 2007 11:16:50 -0800
From: Darren Reed <darrenr@reed.wattle.id.au>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <474DBEA2.4080704@reed.wattle.id.au>
Content-Type: text/plain; charset=ISO-8859-1

Darden, Patrick S. wrote:
> Marcus J. Ranum
> ...
>> The hard thing I had to wrap my brain around was the
>> observation that between a router+ACLs combined
>> with the state that is held in the TCP stack of the
>> target, you've got exactly the same thing (and often
>> quite a bit better!) than a "stateful" firewall.
>>
>
> I respecfully disagree for all the reasons I have outlined
> before.... Sum: tcp sequence #s make a difference.
>

So long as you mean "tcp sequence#s" to mean modelling the entire
TCP connection state, yes. The implication that you're missing is that
the TCP window also needs to be tracked (including whether or not
window scaling is being used), along with which flags appeared at
which sequence numbers so you know what to expect next. e.g
the SYN and FIN flags impact sequence numbers without there being
an explicit change in the headers.

If you go to the extreme of only allowing in sequence TCP packets
and ensure that retransmitted data is always the same as the original,
you could argue that the "stateful inspection" mode here becomes a
layer 5 firewall rather than layer 3 or 4. And that's without a proxy :)

Darren

------------------------------

Message: 2
Date: Tue, 27 Nov 2007 21:23:22 -0800
From: Darren Reed <Darren.Reed@Sun.COM>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <474CFB4A.9080803@Sun.COM>
Content-Type: text/plain; format=flowed; charset=us-ascii

Marcus J. Ranum wrote:

>Jim Seymour wrote:
>
>
>>What
>>you're telling me is just skip the firewall entirely, and put together
>>a comprehensive set of "firewall router" packet filtering rules.
>>
>>
>
>That's not what I'm saying. I'm saying is that the action is all
>at layer-7 these days. Use a router (or 2 tin cans and some string)
>to apply broad, simple, controls at the network layer and make
>sure you are directing traffic to locked down layer-7 services
>on machines that you think can handle them.
>
>Firewalls have always consisted (in my mind, anyhow..) of
>"block and carry" - think of the basic stuff the firewall does
>as blocking big chunks of traffic so that your layer-7 picture
>is refined to the point where you can effectively reason
>about it. In that model a proxy is just a "carry" tool for
>layer-7 traffic - and you can then reason about the security
>controls (if you're using more than just a plug-board
>proxy, which is axiomatically the same as a router
>permit port ACL) in the proxy.
>
>

Before getting too carried away that all "layer 7" firewalls
are the ultimate, how many of them are "layer 7" and how
many of them are "layer 5"?

If I can run IPoverDNS through your "layer 7 firewall", is it
really being a "layer 7 firewall" or a "layer 5 firewall"?

Darren

------------------------------

Message: 3
Date: Wed, 28 Nov 2007 08:51:16 +0100
From: "Patrick M. Hausen" <hausen@punkt.de>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20071128075115.GB95835@hugo10.ka.punkt.de>
Content-Type: text/plain; charset=iso-8859-1

Hello!

On Tue, Nov 27, 2007 at 10:39:04PM -0500, jason@tacorp.com wrote:
> If I opened up port 80 into a
> web server and the state was tracked the reply packet would be able to
> pass back out of the firewall without having to have a rule allowing
> packets from the webserver sourced from port 80 out. Why should I need to
> put two rules in (one for the incoming traffic, and one for the reply)
> when I can rely on the state of the packet for the reply?

Who said, you can't? But how do you know that it's HTTP that
is flowing over port 80?

You should have <something> in place that enforces that it's HTTP
and not some propriatary encrypted data stream for e.g. a bot.
Or if we change the subject to egress filtering and "trusted"
internal users, how about a proprietary encrypted "Internet telephony"
application - hm, what product to pick as an example ...? ;-)

Of course, all sorts of applications can be made "firewall friendly"
and it's possible to tunnel IP through perfectly valid HTTP
or even DNS - but as Marcus put it lately, when he corrected me on
this list - why make it easier for the bad guys?

Firewalls have never been about "ports", yet the security industry
has brainwashed everone with half an understanding of how TCP/IP
works into believing they were.

My customers keep asking me things like "internal user A wants to
run application X, vendor says it uses port Y - is this port
dangerous or can we open it up?" Well ...

Kind regards,
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
--
punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
info@punkt.de

http://www.punkt.de
Gf: J?rgen Egeling AG Mannheim 108285

------------------------------

Message: 4
Date: Wed, 28 Nov 2007 09:00:38 +0100
From: "Patrick M. Hausen" <hausen@punkt.de>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20071128080038.GC95835@hugo10.ka.punkt.de>
Content-Type: text/plain; charset=iso-8859-1

Hi, all,

On Tue, Nov 27, 2007 at 07:23:24PM -0800, Darren Reed wrote:

> What's more, people seem to think that you can just filter
> out DOS attacks. Will someone please give me a cricket
> bat (or baseball bat) so I can apply some proper instruction?
> *sigh*

Sorry to be nitpicking, but can we make that DDOS, then?

At least I use to think of DOS as "ping of death" or
"carefully crafted application packet of death" in contrast
to DDOS as "simply swamp your uplink by thousand of bots".

Firewalls can protect against the former.

Kind regards,
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
--
punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
info@punkt.de

http://www.punkt.de
Gf: J?rgen Egeling AG Mannheim 108285

------------------------------

Message: 5
Date: Wed, 28 Nov 2007 09:52:50 +0100
From: "Patrick M. Hausen" <hausen@punkt.de>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20071128085249.GD95835@hugo10.ka.punkt.de>
Content-Type: text/plain; charset=iso-8859-1

Hi,

On Tue, Nov 27, 2007 at 07:55:05PM -0500, Marcus J. Ranum wrote:

> Or is it a device that does security at higher layers,
> including some layer-7 awareness? If it's doing layer-7
> stuff, can it be excused from worrying about fragment
> re-assembly (how could it possibly?) or re-ordering?

How can it do any useful stuff on layer-7 without reassembling
the _resulting_ data stream first?

Think of overlapping fragments or Michael Olsson's clever partial
ACK attack to FTP ...

Well, I know that you know ... but what's the point of your above
statement, then?

Kind regards,
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
--
punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
info@punkt.de

http://www.punkt.de
Gf: J?rgen Egeling AG Mannheim 108285

------------------------------

Message: 6
Date: Wed, 28 Nov 2007 14:36:43 -0500
From: "Jerry B. Altzman" <jbaltz@altzman.com>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <474DC34B.9020402@altzman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

on 2007-11-28 08:21 Darden, Patrick S. said the following:
> No offense, but both of you are wrong.
> Properly configured, a simple firewall
> CAN prevent most DOS attacks.

I am really confused here. I've read BCP38 (which your paper obliquely
references). I guess you mean: if I have a firewall, I can prevent DOS
attacks from *originating from my network*, as opposed to what I see as
the more popular interpretation of "help you against DOS attacks" to
mean "mitigate the damage of DOS attacks inbound on my network".

> Check out this SANS bulletin on
> "Defeating DDOS". Yes, that is my
> name in the credits. Special task
> force back in 2000. Sigh, and still
> people don't know that you can use
> a simple firewall to defeat most
> DOS attacks... as long as you are
> protecting the world from YOUR
> network.

I can do all the source filtering I want, but if I'm receiving 500 Mpps
of DDOS, my firewall's gonna keel over and die. (Maybe I'm off by 10 dB
or so...)

Any plan of action that depends on the compliance of vendors and
everyone else on the Internet is...well, I'd love the IOS command that
would allow me to configure my neighbor's router.

> --p

//jbaltz
--
jerry b. altzman jbaltz@altzman.com

www.jbaltz.com
thank you for contributing to the heat death of the universe.

------------------------------

Message: 7
Date: Wed, 24 Oct 2007 07:24:48 -0700
From: "Ian Mahuron" <mahuron@gmail.com>
Subject: Re: [fw-wiz] DMZ to INSIDE Communication
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<cbf3fe810710240724q55868c86s6534abaa4b94c320@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Sorry for the late reply.

Chris, you've confused the idea of a real IP vs a NAT IP. The real IP
(Cisco calls this the local IP) is the IP you've configured on the
host. That NAT would be the alternative IP you're exposing on other
interfaces. I don't mean to nitpick but I believe this will help you
to better communicate should you need to use this list in the future
(or should someone other than you have to work with the wonky names in
your policy!).

The missing static sticks out like a sore thumb. This seems to catch
every new PIX/ASA admin so don't feel bad. Hopefully you found the
problem by reading the manual. It's very important to understand how
translation works on a PIX/ASA. Every connection requires an xlate.
This means that each ACE in an interface ACL will need a matching
static or nat.

There is rarely ever a good reason to perform translation between your
DMZ and inside networks. Your firewall is perfectly capable of
routing between the networks. You should require, at most, one static
for them to communicate. This would read something along the lines
of:

static (inside, DMZ) <inside netid> <inside netid> netmask <inside netmask>

This is often referred to as an identity NAT.

Granular identity NATs should be avoided. Some people appear to use
them as an added security measure but this is poor practice.

If you haven't already, you should apply an ACL to your DMZ and inside
interfaces.

Finally, Anthony is absolutely correct. AFAIK, there is _no way_ to
have a functioning dmz _and_ inside (assuming you want them to be able
to chat) with a base license on a 5505. I spent a good hour trying to
work around it. It's too bad as it would make for a very sweet budget
firewall. The license that removes this limitation is considerably
more money (2x).

Ian

On 10/15/07, Anthony <ez4me2c3d@gmail.com> wrote:
> So you weren't running into the issue of the base license not allowing
> DMZ initiated traffic to the inside network?
>
> "With the Base platform, communication between the DMZ VLAN and the
> Inside VLAN is restricted: the Inside VLAN is permitted to send traffic
> to the DMZ VLAN, but the DMZ VLAN is not permitted to send traffic to
> the Inside VLAN."
>
> http://cisco.com/en/US/docs/security/asa/asa72/getting_started/asa5505/quick/guide/vlans.html#wp1101628
>
> Anthony
>
> chris mr wrote:
> > Thanks for your help...
> >
> > I had to add another static into the ASA and ACL on DMZ in.
> >
> > mail.domain.com = 12.x.x.x
> > EXCHANGE1 = natted ip of Exchange on inside
> >
> > static (inside,DMZ) tcp 12.x.x.x smtp EXCHANGE1 smtp netmask 255.255.255.255
> >
> >
> > ____________________________________________________________________________________
> > Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
> > http://autos.yahoo.com/index.html
> >
> >
> >
> > _______________________________________________
> > 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

End of firewall-wizards Digest, Vol 19, Issue 30
************************************************