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.. (Anton Chuvakin)
2. Re: Firewalls that generate new packets.. (ArkanoiD)
3. Re: Firewalls that generate new packets.. (Darden, Patrick S.)
4. Re: Firewalls that generate new packets.. (Darden, Patrick S.)
5. Re: Firewalls that generate new packets.. (Darren Reed)
6. Re: Firewalls that generate new packets.. (Darren Reed)
7. Re: Firewalls that generate new packets.. (Darren Reed)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Nov 2007 10:04:48 -0800
From: "Anton Chuvakin" <anton@chuvakin.org>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<b2591e2e0711281004n6ff5a99dnf3fca005b391eda6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
> I see buzzwords and marketing a-plenty in that interview. :)
Very true! But there is also some substance, which I thought would
make a fun addition to this discussion.
> WTF is "application-centric classification"?? That's what any
> decent firewall has done since the beginning.
Ehhh, maybe not. I think he (well, his device :-)) implies that he can
quickly look at traffic flowing to the same port and then make an
access control decision based on the detected application type (e.g.
email or IM over HTTP is bad while web surfing over HTTP is OK) and
not just on port (e.g. TCP 25 is bad, but - OMG! - TCP 80 is OK)
Proxies (the ones I've seen, at least) can do decisions like "not
normal HTTP? -> good bye connection" but not 'allow YIM over HTTP, but
not AIM over HTTP'
>And Zuk's implicit
> claim in his first paragraph (that CheckPoint did what they did
> because "current firewalls were ineffective") is disingenous
Yes, this one was a shocker to me too :-)
> What does all that MEAN?
The above is what I got from it.
> If what he's saying is that "everything tunnelling over port 80 hurts"
> well - Duh?
Well, yes, actually. But he seems to also add that he can now make
decisions quickly about what specific content of TCP 80 is OK and
which is not based on app/usage, which is kinda cool.
> Hey Anton? Did you actually read that article?? I am asking you
> this seriously. Because I just read it twice and the only words
Well, I did point some substance above; other pieces that I thought
were interesting:
- "Once the application is identified, it needs to be controlled and
secured, both of which require much deeper inspection into the
information itself. Note that simply blocking the application is not
enough - applications need to be controlled - some are always allowed,
some are always blocked but most require granular policy."
This points at something more interesting that "bad app protocol ->
kill it." If you can actually make sense and then make access ctl
decisions about all the TCP 80 mess, I think this would be pretty
cool, useful and new.
- "a client-facing, forward proxy that inspects outbound traffic"
This to me sounds pretty interesting as well: his device's primary
purpose is not to protect the inside for them Evil Outside (tm) :-)
but to audit and control what gets out and in what shape or form with
a degree of details which is possible-but-very-hard to achieve with
other means.
Finally, I think that by being suspended in whitespace :-) between
tech and marketing realms for a few years, I developed a
'spider-sense' of deciphering what people actually mean by their
marketing. It is not ALL BS, you know :-)
Best,
--
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
------------------------------
Message: 2
Date: Wed, 28 Nov 2007 15:11:47 +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: <20071128121146.GA14616@eltex.net>
Content-Type: text/plain; charset=koi8-r
Well, i can. Fix HTML to be valid XHTML which is basically valid XML
as well. Apply XML-based filtering policy then (you need pretty complicated
one that probably goes beyond the abilities of current XML proxies, as
things like ajax and javascript in general need special handling, but
we already do have some of those in current http firewalls) and you
get it. At least it is the way we are going to do if somebody will
sponsor it as it is a bit too big for a free time hobbyst project :-)
For your "war story", i guess IDS/IPS relied on signature analysis
and no one looked if there are suscpicious persistent https tunnels
or unusual dns traffic? Well, some bad guys may live without that
but they are really really rarely *that* smart ;-)
On Tue, Nov 27, 2007 at 09:19:10PM -0600, Marcin Antkiewicz wrote:
>
> I would not look at Squid as a security device - I cannot imagine a
> security proxy written for HTTP as it stands today. In order to have
> any install base, HTTP proxy can, at most, implement ACLs/user auth with
> content filtering and some spam, maybe some cookie encription/info leakage
> prevention, but cannot really limit the protocol.
>
> And now, we slap a NATing router with some ACLs, AV, caching proxy,
> sieve-like egress filtering and call it a firewall.
>
> Everyoen loves war stories: I do consulting sometimes, and last time it
> was for a place with IDS, IPS, 3 AV subscriptions, HTTP proxy, split
> horizon DNS, 2 (!) layers of firewalls (statefull), encrypted and
> unencrypted wireless, NAC and traffic shaper. The bad guys still got in!
> How you ask? Easy: via HTTP/s, dns, smtp (traffic on all the protocols
> was proxied, in and out).
>
------------------------------
Message: 3
Date: Wed, 28 Nov 2007 08:21:19 -0500
From: "Darden, Patrick S." <darden@armc.org>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>, "Firewall Wizards Security
Mailing List" <firewall-wizards@listserv.cybertrust.com>
Message-ID: <CBE22E5FF427B149A272DD1DDE1075240184E5B1@EX2K3.armc.org>
Content-Type: text/plain; charset="iso-8859-1"
No offense, but both of you are wrong.
Properly configured, a simple firewall
CAN prevent most DOS attacks.
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.
Yes, that sigh of mine was ironic
and facetious ;-) Here's a
hankie to wipe that egg off
your face....
http://www.sans.org/dosstep/index.php?portal=fa88d69a3aede10976f8f2dc977d796e
--p
Darren Reed said:
Marcus J. Ranum wrote:
>
>Let's take MITM and DOS off the table. No firewall will
>protect you against either of those.
>
>
Understanding what DOS is appears to be a problem for a
*lot* of people. Lots of people seem to fail to understand
what the real problem is - the saturation of your network
(connection) with packets that you don't want anything to
do with at a point at which you've got no control over.
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*
As Marcus said, no firewall, be it stateless, stateful, proxy,
or otherwise can help you against DOS.
------------------------------
Message: 4
Date: Wed, 28 Nov 2007 09:29:09 -0500
From: "Darden, Patrick S." <darden@armc.org>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <CBE22E5FF427B149A272DD1DDE1075240184E5B8@EX2K3.armc.org>
Content-Type: text/plain; charset="iso-8859-1"
Marcus J. Ranum
>Let's take MITM and DOS off the table. No firewall will
>protect you against either of those.
I've addressed the MITM and DOS issues. I don't agree
with you, and I have presented my reasoning.
>Does a router with ACL+"established" let unsolicited
>RSTs through? I thought that all that got through was
>SYN, unless it had an ACK. And to do an RST with
>an active connection don't you need the sequence #?
>That would require a MITM, right?
Yep, it will. Any firewall that does not depend on
tcp sequence #s will allow such an attack.
>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.
--Patrick Darden
------------------------------
Message: 5
Date: Tue, 27 Nov 2007 19:56:19 -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>, firewallwizards@kajtek.org
Message-ID: <474CE6E3.3080101@Sun.COM>
Content-Type: text/plain; format=flowed; charset=us-ascii
Marcin Antkiewicz wrote:
> ...
>
>Everyoen loves war stories: I do consulting sometimes, and last time it
>was for a place with IDS, IPS, 3 AV subscriptions, HTTP proxy, split
>horizon DNS, 2 (!) layers of firewalls (statefull), encrypted and
>unencrypted wireless, NAC and traffic shaper. The bad guys still got in!
>How you ask? Easy: via HTTP/s, dns, smtp (traffic on all the protocols
>was proxied, in and out).
>
>
How was each protocol (HTTP, dns, smtp) used to get in?
Exploiting bugs in applications implementing each?
or...?
Darren
------------------------------
Message: 6
Date: Tue, 27 Nov 2007 21:07:11 -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: <474CF77F.8010902@Sun.COM>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Paul D. Robertson wrote:
>On Tue, 27 Nov 2007, Paul Melson wrote:
>
>
>
>>in both directions. State tables allow your firewall to have a deny-all
>>default inbound policy and an allow-all default outbound policy. They allow
>>
>>
>
>With today's proliferation of Trojans and Spyware, anyone with a
>Windows user population above three who has an allow-all default outbound
>policy is an idiot and populations of one to three are likely candidates
>for the club if not associate members.
>
>
To give you an idea of how bad this problem is, I recently did a
fresh install of Microsoft Windows XP + Service pack 2 (I hadn't
caught up with all of the patches yet) and experimented with
surfing the Internet like a normal user - default security settings
for Internet Exploder.
Half a dozen web sites later - no more - and spyware had installed
itself into winlogin. Removal? Safest bet will be a format. How did
it get there? I suspect some popup ad with nasty javascript/activex.
Now what percentage of the Internet population does this represent?
Port 80/443 restrictions mean nothing.
Darren
------------------------------
Message: 7
Date: Tue, 27 Nov 2007 21:18:20 -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: <474CFA1C.90003@Sun.COM>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Paul Melson wrote:
> ...
>
>Not at all. My point is that the convenience of state tracking firewalls
>translates directly into savings for the companies that use them. Because
>without it, you must document and enforce policy for traffic on your network
>in both directions.
>
You're wrong.
I suspect what you're comparing is the ease of configuration.
If you're not documenting and enforcing a policy for your network
traffic in both directions then I'm curious to know why you shouldn't
be put in the incompetant basket. Or to put it another way, if you
don't have a documented security policy then you don't have
anything to enforce with the firewall, so you may as well throw
the firewall away and let everyone run free!
Companies that have an Internet connection without having a
network security policy shouldn't be on the Internet!
>State tables allow your firewall to have a deny-all
>default inbound policy and an allow-all default outbound policy. They allow
>you to assume that the Internet cannot be trusted and that your internal
>network can be.
>
>
I don't see how this is any different to any other firewall.
>Of course these are flawed assumptions.
>
...
I'd encourage you to do more reading, buy some books (remember
those paper things?) and do more reading so that you're actually
knowledgable about the topic and thus don't need to make flawed
assumptions.
Darren
------------------------------
_______________________________________________
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 29
************************************************
No comments:
Post a Comment