Search This Blog

Friday, November 30, 2007

firewall-wizards Digest, Vol 19, Issue 35

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. Dark Reading: Firewalls Ready for Evolutionary Shift
(George Capehart)
2. Re: Firewalls that generate new packets.. (Darden, Patrick S.)
3. Re: Firewalls that generate new packets.. (Darden, Patrick S.)
4. Re: Firewalls that generate new packets..
(lordchariot@embarqmail.com)
5. Re: Firewalls that generate new packets.. (Timothy Shea)
6. Re: Firewalls that generate new packets.. (Paul D. Robertson)
7. Re: Firewalls that generate new packets.. (Darden, Patrick S.)


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

Message: 1
Date: Thu, 29 Nov 2007 19:45:59 -0500
From: George Capehart <capegeo@opengroup.org>
Subject: [fw-wiz] Dark Reading: Firewalls Ready for Evolutionary
Shift
To: firewall-wizards@listserv.cybertrust.com
Message-ID: <474F5D47.5030302@opengroup.org>
Content-Type: text/plain; charset=ISO-8859-1

Some light reading for the weekend . . . Thought it'd stir the pot a
bit more for the "Firewalls that generate new packets . . ." thread. ;>

http://www.darkreading.com/document.asp?doc_id=140121&f_src=drweekly

Enjoy.

/g

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

Message: 2
Date: Thu, 29 Nov 2007 08:33:10 -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: <CBE22E5FF427B149A272DD1DDE1075240184E5D3@EX2K3.armc.org>
Content-Type: text/plain; charset="iso-8859-1"


I believe you are missing the point. Three types of DOS

1. bandwidth flood--several dos and most ddos, smurf,
stacheldraht, only way to protect against them is to
prevent them, only way to prevent them is if all networks
protect others from themselves.

2. purposely (mal)shaped packets--teardrop, ping of death, etc.;
any good firewall prevents known examples.

3. application shaped--e.g. sending a continuous stream of
connection packets to an apache web server, letting them time
out at 15 minutes, thus keeping others from connecting; etc.
Most security features provide *very limited* relief from this,
limiting the # of connections from the same sip, decreasing
tcp timeout from 15 mins to 30 seconds, etc.

Helpful?

--Patrick Darden

-----Original Message-----

>....
>http://www.sans.org/dosstep/index.php?portal=fa88d69a3aede10976f8f2dc977d796e
>
>

I see nothing in that article that explains how a firewall
can be used to defend against a DOS (or DDOS) attack.

All I see is how to avoid yourself from being used as the
source of one - where source IP addresses are forged.

When I've got an army of 100,000 pc's scattered around
the globe ready to try and connect() to your web server
(without spoofing an IP#), how does anything in that
article help?

Darren

_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards


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

Message: 3
Date: Thu, 29 Nov 2007 08:52:59 -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: <CBE22E5FF427B149A272DD1DDE1075240184E5D5@EX2K3.armc.org>
Content-Type: text/plain; charset="iso-8859-1"


Paul D. Robertson

>The list is still moderated, and the moderator approves some stuff
>immediately, mulls over others, discards some and rejects others. Since
>the list has always been moderated I'm not sure why folks aren't
>remembering this...

Paul, you told me this off the list, plus a lot more. And I agreed to
abide by your rules. My message was not a reprimand, it was an explanation
of why one of my messages appeared a bit retarded.

My message was not meant to be implied criticism,

As I told you privately, I understand that you are the moderator and I
understand why you filterd my messages to the list, even if I do not
think you were right. I also acknowledge the need for a moderator
as everyone thinks they are right and their messages are perfect. And
some of them need to be pulled for sure.


>You're assuming a blind attack, a very dangerous assumption. Even with a
>blind attack, you're assuming that (a) the attacker's prediction efforts
>are stymied by hard-to-predict sequence numbers and (b) the attacker
>(or defender) lacking enough bandwidth to brute force the sequence number
>or the likey sequence number space.

I am not assuming a blind attack. I was positing an example situation
that highlighted the importance of TCP sequence numbers. Please do not
put words in my mouth.


>"Prearranged formula decided on during the TCP handshake?"

>Wanna show me where in the TCP spec there's some forumla negotiation?
>AFAIR the spec (RFC793) handles the progression of ISN+1 and SND.NXT and
>RCV.NXT in the specification not the handshake, what am I missing?

Not my words. However, I think you understand things very well:
random number--random number+1; then rinse and repeat isn't it?
Wikipedia has a very vague reference to it as: "If the SYN flag
is present then this is the initial sequence number and the first
data byte is the sequence number plus 1."

I don't have my reference books handy, unfortunately. But that is how
I remember it....


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

Message: 4
Date: Thu, 29 Nov 2007 12:06:34 -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: <6D63D4CB9DE247A49478E198B6C9954F@lordchariot.com>
Content-Type: text/plain; charset="us-ascii"

I think this came out yesterday. Amongst other recommendations are these
snippets.

SANS Top-20 2007 Security Risks (2007 Annual Update)

http://www.sans.org/top20/

<...snip...>
Z1.4. How to Protect against the vulnerabilities

Protecting against zero day vulnerability exploitation is a matter of great
concern for most system administrators. To reduce the impact of a zero day
attack, follow best business practices such as:

* Adopt a deny-all stance on firewalls and perimeter devices that protect
internal networks
* Separate public-facing servers from internal systems
<...snip...>


Sigh. Do you think anyone will start listening yet?


Patrick M. Hausen wrote:
> E.g. does PIX still have these implied rules that say: if I
> configure port X from here to there, this automatically implies
> the same access to all interfaces with a lower security level than
> 'there'? This is the case in 6.x - now, whoever at Cisco came
> up with this concept should be shot.
>
> I have not looked at 7.x or ASA, yet.

Patrick, I've been wondering the same thing. I have customers with ASA and
they still seem to have an allow-all default (judging from the number of
them I've run across that are actively botted.)
I would like to confirm if the ASA still has the default allow-all outbound
policy.


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

Message: 5
Date: Thu, 29 Nov 2007 07:52:50 -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: <2FC9ED94-9AA0-4732-818A-6B54B840AF65@tshea.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

I agree. As a practical matter I do take outgoing and inbound proxies
as "security devices" and usually insist that its managed by the same
group that manages the firewalls. I would add to your comments that
an outgoing proxy (such as squid or bluecoat) allows you to eliminate
the dreaded "completely open outbound default" rule found on many
corporate firewalls and allows a higher degree of auditing. Both
security minded purposes.

But the arguments over what is and what is not a security device is a
pet peeve of mind. Its waaay past time we stop thinking what is and
what is not a "security device" and think how we configure and manage
each piece in the environment with security in mind. The firewall,
the server, the router, the load balancer, the OS, the application
code, processes, and, heck, even the switch and the wiring. The
"firewall" is becoming less and less important (and useful) as a tool
in the grand scheme of things.

t.s


On Nov 28, 2007, at 8:08 AM, Darden, Patrick S. wrote:

>
> I disagree slightly with what you say. Squid can do the
> following security oriented things:
>
> 0 sanitizes http commands going through it (dos, espec
> unintentional doses by corrupt clients or bad networks)
> 0 can limit sizes to limit buffer overflows
> 0 can anonymize or even edit headers to limit access to
> user-agent, link, www-authenticate, referer, from, server,
> accept-charset, etc.
> 0 filter out known signatures for malware such as pop-ups,
> hijack scripts, cross-site scripting, etc.
>
> That's just what I can think of off the top of my head.... You
> can use Squid as an outgoing proxy for your users, or an incoming
> cache for your servers, and both ways would provide different
> security possibilities.
>
> I am NOT saying Squid is the end-all be-all, not even advocating
> its use at all. I was merely using it as an example of an
> application proxy. SOCKS might make more sense than Squid,
> from a purely security perspective....
>
> --p
>
>
> Marcin Antkiewicz
>> I am well aware that Squid does not do all of the previous--
>> it is an application proxy. Application level proxies, or
>> the equivalent, are the best form of deep packet inspectors.
>> The rest of the Stateful with deep packet inspection would be
>> what is more traditionally thought of as a firewall. They
>> would not substitute for one another, but instead complement
>> each other.
>
> 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. Squid and most
> popular
> http proxies are http caches/load balancers but not security devices.
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

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

Message: 6
Date: Thu, 29 Nov 2007 23:40:03 -0500 (EST)
From: "Paul D. Robertson" <paul@compuwar.net>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <Pine.LNX.4.44.0711292329530.16249-100000@bat.clueby4.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 29 Nov 2007, Darden, Patrick S. wrote:

> >You're assuming a blind attack, a very dangerous assumption. Even with a
> >blind attack, you're assuming that (a) the attacker's prediction efforts
> >are stymied by hard-to-predict sequence numbers and (b) the attacker
> >(or defender) lacking enough bandwidth to brute force the sequence number
> >or the likey sequence number space.
>
> I am not assuming a blind attack. I was positing an example situation
> that highlighted the importance of TCP sequence numbers. Please do not
> put words in my mouth.

But the predictability of ISNs are only important in blind attacks- if the
attacker can sniff the ISNs, then the sequence numbers have no
value to a connection under attack as far as I can tell. So if your
scenario doesn't assume a blind attack what am I missing?

Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
paul@compuwar.net which may have no basis whatsoever in fact."

http://www.fluiditgroup.com/blog/pdr/

Art: http://PaulDRobertson.imagekind.com/

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

Message: 7
Date: Fri, 30 Nov 2007 08:04:53 -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: <CBE22E5FF427B149A272DD1DDE1075240184E5E2@EX2K3.armc.org>
Content-Type: text/plain; charset="iso-8859-1"


I couldn't agree with you more. Every single server, service,
device, anything at all on your network should be included
in your security strategy....

I think many of us have had "embedded" devices cause problems,
whether it was an MRI running an old outdated linux, an
ultrasound device running Win NT 3.5, or whatever --
they are on the network and must be considered: antivirus,
trojans, heck even old fashioned unintentional network DOS
via nic malfunctions like beaconing or maybe misconfigured
broadcasting.

--Patrick Darden


-----Original Message-----
From: firewall-wizards-bounces@listserv.icsalabs.com
[mailto:firewall-wizards-bounces@listserv.icsalabs.com]On Behalf Of
Timothy Shea

But the arguments over what is and what is not a security device is a
pet peeve of mind. Its waaay past time we stop thinking what is and
what is not a "security device" and think how we configure and manage
each piece in the environment with security in mind. The firewall,
the server, the router, the load balancer, the OS, the application
code, processes, and, heck, even the switch and the wiring. The
"firewall" is becoming less and less important (and useful) as a tool
in the grand scheme of things.


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

_______________________________________________
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 35
************************************************

No comments: