Security World: firewall-wizards Digest, Vol 49, Issue 6

Monday, May 10, 2010

firewall-wizards Digest, Vol 49, Issue 6

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: Firewall best practices (david@lang.hm)
2. Re: DNS Names for external services (david@lang.hm)

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

Message: 1
Date: Sun, 9 May 2010 12:44:27 -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.1005091241570.26536@asgard.lang.hm>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

The firewall needs to know the cert at one end of the connection (it can
be either end, so if it knows the client cert you are using it will work
as well)

In some cases the firewall makes up a cert on the fly, with the browser
set to trust any cert the firewall signs, and the firewall is a full
man-in-the-middle proxy.

In other cases the firewall works on a copy of the traffic and decrypts it
with the known certs (there are some PKI modes this will not work on)

David Lang

On Tue, 27 Apr 2010, John Morrison wrote:

> 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
>>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>

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

Message: 2
Date: Sun, 9 May 2010 12:54:10 -0700 (PDT)
From: david@lang.hm
Subject: Re: [fw-wiz] DNS Names for external services
To: Morty Abzug <morty@frakir.org>
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <alpine.DEB.2.01.1005091253180.26536@asgard.lang.hm>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 26 Apr 2010, Morty Abzug wrote:

> 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.