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: Firewall best practices (Marcus J. Ranum)
2. Re: DNS Names for external services (david@lang.hm)
3. Re: Firewall best practices (david@lang.hm)
4. Re: Firewall review tool for Junipers (david@lang.hm)
5. Re: DNS Names for external services (Andre Lima)
6. Re: DNS Names for external services (Morty Abzug)
7. Re: Firewall best practices (John Morrison)
8. Re: Duplicate Public IP Addresses? (Dave Piscitello)
----------------------------------------------------------------------
Message: 1
Date: Fri, 23 Apr 2010 20:42:39 -0500
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] Firewall best practices
To: Martin Barry <marty@supine.com>
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <4BD24C8F.6000204@ranum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Martin Barry wrote:
> Marcus, are you referring to DPI or proxies or both or something else
> entirely?
I wasn't referring to anything in specific; I think, though,
that we've moved past the point where we can think of firewalls
as just source/dest IP source/dest port and we need to start
characterizing genres and sub-genres of traffic. There was a
time when Jon Postel said that "Email is the new datagram"
but now "HTTP is the new IP" - we've lost the battle on trying
to have HTTP just be a fetch protocol for data; it's now a
much more complicated thing with genres and sub-genres and
probably sub-sub-genres of traffic. We can't meaningfully
"firewall" traffic if "permit source HTTP ANY" includes
VPNs, bidirectional commands, voice data, and who knows
what else?
We're reaping the rewards of ignoring that problem, in the
form of firewall-busting malware that does all the stuff
that yesterday's "firewall friendly application" used to
do. I guess what I'm saying is that we need application
friendly firewalls to undo the damage from the firewall
friendly applications. :) I think that the vendors'
technology strategies largely show an awareness of the
problem; they mostly have some kind of increasingly
powerful layer-7 processing capability either in the
product, in the works, or on the roadmap. They've got
to, because firewall friendly applications are about
as friendly to the firewall as a bullet to the head.
You're completely right about the "if the application
emulates HTTPS traffic" problem. I don't have an answer
to that one other than "we warned everyone that that
was going to be a problem." At this point, it's less
of technical problem than a social one. It seems to me that
an organization cannot claim to be concerned about
security while allowing user-oriented encrypted outgoing
links to any target. That's just foolishness. The fact
that "everyone does it" doesn't make it any less foolish.
Back in the proxy days we advocated tying outgoing
connections to an authenticated user; that's another
important aspect of the problem that gets short shrift.
mjr.
--
Marcus J. Ranum CSO, Tenable Network Security, Inc.
http://www.tenablesecurity.com
------------------------------
Message: 2
Date: Fri, 23 Apr 2010 12:20:17 -0700 (PDT)
From: david@lang.hm
Subject: Re: [fw-wiz] DNS Names for external services
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <alpine.DEB.2.01.1004231218520.12793@asgard.lang.hm>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 23 Apr 2010, Morty wrote:
> On Sat, Apr 17, 2010 at 10:50:31AM -0500, Frank Knobbe wrote:
>
>> Likewise, if you don't run an FTP server (or CVS, or POP3, or...),
>> setup DNS records for those pointing to your honeypot. Use it to
>> respond in anyway you see fit for defense of your network (blocking
>> the IP, etc).
>
> What happens when one of your legit users says "I wonder if we have an
> FTP server?" and tries ftp.$YOURCOMPANY.com just to see if it answers?
if your server is locked down, nothing (other than an additional failed
login)
if your server is vunerable, people who use nmap or similar will find it
anyway and you will be hacked anyway.
David Lang
------------------------------
Message: 3
Date: Fri, 23 Apr 2010 12:18:46 -0700 (PDT)
From: david@lang.hm
Subject: Re: [fw-wiz] Firewall best practices
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Cc: mjr@ranum.com
Message-ID: <alpine.DEB.2.01.1004231218060.12793@asgard.lang.hm>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 23 Apr 2010, Martin Barry wrote:
> $quoted_author = "Marcus J. Ranum" ;
>>
>> That's why firewalls need to go back to doing what they
>> originally did, and parsing/analyzying the traffic that
>> flows through them, rather than "stateful packet
>> inspection" (which, as far as I can tell, means that
>> there's a state-table entry saying "I saw SYN!")
>
> Marcus, are you referring to DPI or proxies or both or something else
> entirely?
>
>
>> If the firewall doesn't understand the data it's passing,
>> it's not a firewall, it's a hub.
>
> If an application emulates HTTPS traffic and is proxy aware, how do you tell
> the difference?
There are firewalls on the market that can decrypt HTTPS traffic (and I
believe be configured to block any traffic that they can't decrypt)
David Lang
------------------------------
Message: 4
Date: Fri, 23 Apr 2010 12:17:30 -0700 (PDT)
From: david@lang.hm
Subject: Re: [fw-wiz] Firewall review tool for Junipers
To: vbwilliams@gmail.com, Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <alpine.DEB.2.01.1004231214400.12793@asgard.lang.hm>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Thu, 22 Apr 2010, Victor Williams wrote:
> Having gone through this already, there is no silver bullet for ruleset
> auditing...it takes human eyes and an explanation on why rulesets are the way
> they are.
Understood, but it's hard to look for changes from 6 months ago in a GUI.
It's much easier if you can get a report that shows you what has changed
so that you can validate the changes.
In the case of Juniper, they have a semi-supported, mostly undocumented
XML import/export function that is the only way I know of to get the
rulesets into a different tool.
XML does not diff well with line-oriented tools, can anyone point at a
good tool for looking for differences in XML files?
David Lang
> For automated configuration collection and archive, as well as comparison,
> Kiwi Cattools will handle configurations with select Juniper devices.
>
> The only way you're going to be able to audit configurations that a QSA would
> be fine with is to manually audit them and comment the rulesets--explain why
> they're needed. Cisco, Secure Computing Sidewinder (now owned by McAfee and
> going by a different name), etc all allow commenting of access lists. The
> last gap analysis we had with a QSA who audited our rulesets indicated that
> our rulesets and justifications would pass an audit because of the
> completeness of the comments.
>
> Hope this helps.
>
> On 4/22/2010 10:00 AM, Wilson wrote:
>> Hi there,
>>
>> Just wanted to get some advice from the forum. What tools do you use
>> to perform firewall policies review on Junipers firewall? One of the
>> driver is to comply with PCIDSS. Due to the number of firewalls I hope
>> there is some proven tools out there that can help with things like
>> gathering configs, identify diff in rulesets etc. I am prepared for
>> manual analysis but want to automate as much as possible, especially
>> this will be a recurring tasks. Anyway welcome any open source or
>> commercial suggestions. Thanks heaps for your help.
>>
>> Cheers,
>>
>> Wil
>> _______________________________________________
>> 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: 5
Date: Sat, 24 Apr 2010 01:50:59 +0100
From: Andre Lima <andreflima@gmail.com>
Subject: Re: [fw-wiz] DNS Names for external services
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <4BD24073.7010700@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> What happens when one of your legit users says "I wonder if we have an
> FTP server?" and tries ftp.$YOURCOMPANY.com just to see if it answers?
>
>
Since it's a honeypot and not a production system, the legit user just
won't be able to sign in and give up by the very first attempt.
- Lima
------------------------------
Message: 6
Date: Mon, 26 Apr 2010 19:46:44 -0400
From: Morty Abzug <morty+fw-wiz@frakir.org>
Subject: Re: [fw-wiz] DNS Names for external services
To: david@lang.hm
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20100426234644.GA20779@red-sonja>
Content-Type: text/plain; charset=us-ascii
On Fri, Apr 23, 2010 at 12:20:17PM -0700, david@lang.hm wrote:
>>> Likewise, if you don't run an FTP server (or CVS, or POP3, or...),
>>> setup DNS records for those pointing to your honeypot. Use it to
>>> respond in anyway you see fit for defense of your network (blocking
>>> the IP, etc).
>> What happens when one of your legit users says "I wonder if we have an
>> FTP server?" and tries ftp.$YOURCOMPANY.com just to see if it answers?
> if your server is locked down, nothing (other than an additional
> failed login)
Re-read above. GP advocated setting up a honeypot on well-known names
that *blocks* the source IP. The problem with this is that if
$legit_user of your company/organization says 'hey, I see
"ftp.$mycompany.com" resolves' and tries it, you will block
$legit_user's source IP.
- Morty
------------------------------
Message: 7
Date: Tue, 27 Apr 2010 10:45:02 +0100
From: John Morrison <john.morrison101@googlemail.com>
Subject: Re: [fw-wiz] Firewall best practices
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Cc: mjr@ranum.com, Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID:
<r2yfd3b86ff1004270245y6c42bd39s3a082b283a6ba467@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
My understanding of https (and other PKI-based encryption) is that
only the holder of the private key can decrypt the data encrypted with
the other (public) key in the pair. My view is that the firewall can
only decrypt and inspect https traffic if it is acting as the server
to the external client. It can't intercept and decrypt https traffic
destined for another device - the real server. If it did https would
be worthless. Any hacker could buy such a firewall to sniff and
decrypt all https traffic.
On 23 April 2010 20:18, <david@lang.hm> wrote:
> On Fri, 23 Apr 2010, Martin Barry wrote:
>
>> $quoted_author = "Marcus J. Ranum" ;
>>>
>>> That's why firewalls need to go back to doing what they
>>> originally did, and parsing/analyzying the traffic that
>>> flows through them, rather than "stateful packet
>>> inspection" (which, as far as I can tell, means that
>>> there's a state-table entry saying "I saw SYN!")
>>
>> Marcus, are you referring to DPI or proxies or both or something else
>> entirely?
>>
>>
>>> If the firewall doesn't understand the data it's passing,
>>> it's not a firewall, it's a hub.
>>
>> If an application emulates HTTPS traffic and is proxy aware, how do you
>> tell
>> the difference?
>
> There are firewalls on the market that can decrypt HTTPS traffic (and I
> believe be configured to block any traffic that they can't decrypt)
>
> David Lang
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
------------------------------
Message: 8
Date: Tue, 27 Apr 2010 09:55:38 -0400
From: Dave Piscitello <dave@corecom.com>
Subject: Re: [fw-wiz] Duplicate Public IP Addresses?
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <4BD6ECDA.9040601@corecom.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Paul D. Robertson wrote:
> I think there's been a fair amount of work on detecting bogus BGP routing
> information since I had to deal with peering routers- and there don't seem
> to be enough incidents to make everyone want to solve anything, like
> getting the IRR to a near complete status.
There's actually quite a bit of research focused on detecting bogus BGP
routing, to deter DDOS attacks for example, see
Mitigating IP Spoofing by Validating BGP Routes Updates
http://paper.ijcsns.org/07_book/200905/20090510.pdf
and for preventing BGP prefix hijacking see
www.ece.purdue.edu/~ychu/publications/conext07_hjk.pdf
FWIW, I found several dozen articles (many from refereed journals) by
simply searching "detecting bogus BGP routing" from Paul's message.
-------------- 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/20100427/6544057f/attachment.bin>
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 48, Issue 11
************************************************
No comments:
Post a Comment