Search This Blog

Friday, November 30, 2007

firewall-wizards Digest, Vol 19, Issue 37

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.. (Fetch, Brandon)
2. Re: Firewalls that generate new packets.. (Darden, Patrick S.)
3. ***SPAM*** Re: Firewalls that generate new packets..
(Dave Piscitello)
4. First there was Personal Firewall Day... (Dave Piscitello)
5. Re: How to find hidden host within LAN (Fiamingo, Frank)
6. Re: Dark Reading: Firewalls Ready for Evolutionary Shift
(Jim Seymour)


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

Message: 1
Date: Fri, 30 Nov 2007 13:14:30 -0500
From: "Fetch, Brandon" <bfetch@tpg.com>
Subject: Re: [fw-wiz] Firewalls that generate new packets..
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>, <darrenr@reed.wattle.id.au>
Message-ID:
<AA8E89377DCB1C498CF19E343CA49D8E2DB0D7@NYEXCHSVR01.texpac.com>
Content-Type: text/plain; charset="us-ascii"

Paul,
I'd have to agree with that position. If the system is not available,
its services have been denied. Whether that's through packet buffer
exhaustion (node issue), circuit saturation (path to node issue), or
sending RSTs using impersonated sequence numbers (protocol on node
issue), a DoS is a DoS is a DoS.

Not to rile Mr. mjr anymore than he already has (tiger, balls, kicking,
oh my!) I think a lot of what a firewall was originally "in place"/used
for was to obscure or prevent the exploitation of inherently insecure
systems from the "nefarious public".

Granted, and I'm with mjr on this one, by putting a screen door in front
of what you're trying to protect from the physical impact of raindrops
is still going to get wet in the end so what's the point other than
marketing?

Which I hope is a humorous analogy to close this dead horse of a thread.
:)

Enjoy!
Brandon

-----Original Message-----
From: firewall-wizards-bounces@listserv.icsalabs.com
[mailto:firewall-wizards-bounces@listserv.icsalabs.com] On Behalf Of
Paul D. Robertson
Sent: Friday, November 30, 2007 7:51 AM
To: darrenr@reed.wattle.id.au; Firewall Wizards Security Mailing List
Subject: Re: [fw-wiz] Firewalls that generate new packets..

On Fri, 30 Nov 2007, Darren Reed wrote:

> I definately don't classify (2) as a DOS problem. An
application/operating

System crashes, availability is 0, how is that not a DoS? If we're
going
to use a standard vocabulary (and I think we must) then we can't
individually pick what the words mean.

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/

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


This message is intended only for the person(s) to which it is addressed
and may contain privileged, confidential and/or insider information.
If you have received this communication in error, please notify us
immediately by replying to the message and deleting it from your computer.
Any disclosure, copying, distribution, or the taking of any action concerning
the contents of this message and any attachment(s) by anyone other
than the named recipient(s) is strictly prohibited.

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

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


To be honest I was not assuming on or off a shared network for this
scenario, I just hadn't considered it one way or the other.

Shared and unshared mean less and less anyways... with semi-automated
tools like Caine and Abel, and my favorite Dsniff (quick plug for it
"dsniff is a collection of tools for network auditing and
penetration testing" that automates MITM attacks, shows the
ineffectiveness of depending on switches (vs hubs) for security,
and more) http://monkey.org/~dugsong/dsniff/

But in any case, blind attacks (attacks that take place on the internet
vs. a wan, man, lan, etc.) would still be the majority of the cases,
wouldn't they? A good IDS will find a local MITM attack such as
the ones we are discussing, unless it is also blind (iow they don't
do any arp poisoning/mac spoofing). Then, yes we would be left
depending on the random # generation of the OS and the lack of
brute force of the hacker.

RFC1948, which most OSes seem to ignore, would make it much much
more difficult even with only mediocre randomness. It advocates
one-way MD5 hashes....

The seminal paper on this would probably be "Strange Attractors
and TCP/IP Sequence Number Analysis", the update to which is
at: http://lcamtuf.coredump.cx/newtcp/

This is good reading--it compares many OSes randomness with
respect to tcp sequence numbers, posits the brute force
necessary to hack them, and does so in a very readible
manner.

One crucial part of it is "Current Risks of tcp/ip spoofing"
at http://lcamtuf.coredump.cx/newtcp/#risks


--p

-----Original Message-----
From: firewall-wizards-bounces@listserv.icsalabs.com
[mailto:firewall-wizards-bounces@listserv.icsalabs.com]On Behalf Of Paul
D. Robertson
Sent: Thursday, November 29, 2007 11:40 PM
To: Firewall Wizards Security Mailing List
Subject: Re: [fw-wiz] Firewalls that generate new packets..


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/

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


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

Message: 3
Date: Fri, 30 Nov 2007 16:45:37 -0500
From: Dave Piscitello <dave@corecom.com>
Subject: [fw-wiz] ***SPAM*** Re: Firewalls that generate new
packets..
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <47508481.5070907@corecom.com>
Content-Type: text/plain; charset="iso-8859-1"

If I understand your email, you are saying firewalls are good at (2). I
doubt if anyone disagrees with you but that's not a huge accomplishment
for a firewall in 2007.

(1) is the huge problem area. BCP38 does encourage behavior that would
mitigate some but not all DDOS attacks of this kind. Think Estonia.

(3) is also a more important problem today than (2).

So I'm not certain that you've done much to debunk the "firewalls can't
prevent DDOS attacks" assertion.

Darden, Patrick S. wrote:
> 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
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
-------------- 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/20071130/41048c35/attachment-0001.bin


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

Message: 4
Date: Fri, 30 Nov 2007 16:51:44 -0500
From: Dave Piscitello <dave@corecom.com>
Subject: [fw-wiz] First there was Personal Firewall Day...
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <475085F0.8070305@corecom.com>
Content-Type: text/plain; charset="iso-8859-1"

Wouldn't it be nice to try to sponsor

"Disable your DEFAULT ANY OUTBOUND policy" Day?

Would it be that hard to generate buzz about this?

-------------- 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/20071130/1029da85/attachment-0001.bin


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

Message: 5
Date: Fri, 30 Nov 2007 15:51:02 -0500
From: "Fiamingo, Frank" <FiamingF@strsoh.org>
Subject: Re: [fw-wiz] How to find hidden host within LAN
To: <desant1@tin.it>, "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.cybertrust.com>
Message-ID:
<FA4F85CD8D0D31478AB8A2C44EB8BF25012B6BBD@benjamin.strsoh.org>
Content-Type: text/plain; charset="us-ascii"

I've seen this on our network in recent months also. It ususally has to
do with virtual machines that default to using 192.168.x.x (VMware) and
10.211.55.x (Parallels) addresses. They either exit their physical
machine not properly NATed for your network, or when they interact with
some applications, such as MS Exchange, the Exchange server may try to
reply to the original 192.168.x.x or 10.211.55.x address. Apparently
this original source address must be buried somewhere in the data
portion of the packet. Either problem makes the origin very difficult
to trace, because you can't route to, or ping, that source address.

Frank

-----Original Message-----
From: firewall-wizards-bounces@listserv.cybertrust.com
[mailto:firewall-wizards-bounces@listserv.cybertrust.com] On Behalf Of
desant1@tin.it
Sent: Sunday, November 25, 2007 9:42 AM
To: firewall-wizards@listserv.cybertrust.com
Subject: [fw-wiz] How to find hidden host within LAN

Hi everybody
I'm using RH ES4 with iptables as gateway/firewall for my
LAN.
In the last week i notice in the iptables logs that a host within
my lan is doing a lot of traffic.
The destination/source address of the
packets and the used port suggest that this host is using peerToPeer
application (emule or similar).
The problem is that i'm not able to
identify this host within my LAN:
I can see his IP address (192.168.x.
y) and i can find his mac address througth ARP, but i can't ping it and
there is no host within my lan with this Mac address.
I can't
traceroute it.
Can someone help me to find this hidden host?
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards


CONFIDENTIALITY NOTICE: STRS Ohio intends this e-mail message and any attachments to be used only by the person(s) or entity to which it is addressed. This message may contain confidential and/or legally privileged information. If the reader is not the intended recipient of this message or an employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are prohibited from printing, copying, storing, disseminating or distributing this communication. If you received this communication in error, please delete it from your computer and notify the sender by reply e-mail.


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

Message: 6
Date: Fri, 30 Nov 2007 09:00:29 -0500 (EST)
From: jseymour@linxnet.com (Jim Seymour)
Subject: Re: [fw-wiz] Dark Reading: Firewalls Ready for Evolutionary
Shift
To: firewall-wizards@listserv.icsalabs.com
Message-ID: <20071130140029.67A7AE15B@jimsun.linxnet.com>


"Marcus J. Ranum" <mjr@ranum.com> wrote:
>
> George Capehart wrote:
> >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
>
[snip]
> "Next Generation firewalls"? Gosh, oh, golly - it sounds like what
> they're calling "Next Generation firewalls" are kinda sorta like
> "what firewalls were supposed to do all along."
[snip]

Everything that's old is new again?

Hasn't this been on the horizon a couple years or so, now? ISTR
starting to hear about application proxies again a couple years ago or
so. I recall laughing, at the time, about how it seemed "security
experts" and admins were going to re-discover something that's been
around for, well, quite a long time.

How sad.

Not to haul this thread off-subject or off-topic, but, ironically:
Coincident with this discussion, here, there is running on another
mailing list to which I'm subscribed a discussion about the email spam
and email-borne malware problem and somebody suggested (paraphrased)
"Maybe if some of the relevant RFC's "should"s and "should not"s were
be turned into "must"s and "must not"s?" Such as "HELO/EHLO MUST
consist of." The other idea floated was that Postel's Robustness
Principle is archaic.

Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.linxnet.com/contact/scform.php>.

Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.linxnet.com/contact/scform.php>.


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

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

No comments: