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: Firewall best practices (Harrell, Matthew)
3. Re: Firewall best practices (Nate Itkin)
4. Re: DNS Names for external services (Frank Knobbe)
5. Re: DNS Names for external services (R. DuFresne)
6. Re: DNS Names for external services (Paul D. Robertson)
7. Re: Firewall review tool for Junipers (Lloyd, Mike)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Apr 2010 15:31:47 -0400
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] Firewall best practices
To: "Harrell, Matthew" <mhar@plex.com>
Cc: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <4BD73BA3.2070008@ranum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Harrell, Matthew wrote:
> This then allows the firewall to scan the data in the packets[...]
I have always been kind of mind-boggled that The Internet makes
abundant use of such crappy security that it's so trivially
susceptible to MITM attacks. And it boggles me further that many
technologists invest in technology for doing exactly this, given
that the expected reaction (years ago!) should have been "time
to fix SSL!" not "oh, cool! a 'secure' socket layer that is
trivially MITMable! how convenient!" If there's anything that
gives us a real indication of where security sits on the trade-off
scale between "nothing at all" and "utter crap" it's the SSL
situation. I guess that having crypto that sucks so badly that
it's breakable is easier than having to actually ask the question,
"if we are 'concerned about data leakage' why are we allowing
outbound encrypted tunnels?"
In Marcus-land the way we'd do it is have crypto that didn't
suck, and firewall rules that permitted outgoing crypto only
to (say, if online banking was an authorized activity during
office hours) a set of supported sites. Yeah, yeah, I know,
Marcus-land isn't a real place...
mjr.
--
Marcus J. Ranum CSO, Tenable Network Security, Inc.
http://www.tenablesecurity.com
------------------------------
Message: 2
Date: Tue, 27 Apr 2010 11:09:21 -0400
From: "Harrell, Matthew" <mhar@plex.com>
Subject: Re: [fw-wiz] Firewall best practices
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Cc: "mjr@ranum.com" <mjr@ranum.com>
Message-ID:
<93005E5F81A573478B3726B1D4CD4D6CC80F3137@ah-exch.plex.com>
Content-Type: text/plain; charset="us-ascii"
That is exactly what they do, at least the ones I'm familiar with. The firewall is acting as the server (it's a proxy, anyway): The CSR is generated there, and the cert is installed there. This then allows the firewall to scan the data in the packets as well as header information for RFC compliance, etc. Some firewalls even allow for the re-encryption of the HTTPS traffic back to the web server. We don't need that functionality, and simply send the packets on to the servers as plain text HTTP. If we need to know whether the traffic arrived at the firewall encrypted, then I configure the firewall to use a different port for the traffic to the back end web server.
--------------------
Matthew Harrell
Plex Systems
(248) 391-8000
mhar@plex.com
________________________________________
From: firewall-wizards-bounces@listserv.icsalabs.com [firewall-wizards-bounces@listserv.icsalabs.com] On Behalf Of John Morrison [john.morrison101@googlemail.com]
Sent: Tuesday, April 27, 2010 5:45 AM
To: Firewall Wizards Security Mailing List
Cc: mjr@ranum.com; Firewall Wizards Security Mailing List
Subject: Re: [fw-wiz] Firewall best practices
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: 3
Date: Tue, 27 Apr 2010 08:43:08 -1000
From: Nate Itkin <fw-wizards@konadogs.net>
Subject: Re: [fw-wiz] Firewall best practices
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20100427184308.GA15009@li92-81.konadogs.net>
Content-Type: text/plain; charset=us-ascii
On Tue, Apr 27, 2010 at 10:45:02AM +0100, 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.
Products that inspect https traffic do so with a man-in-the-middle
strategy. It requires configuring the browser to accept certificates
signed by the firewall's certificate authority.
- Nate Itkin
------------------------------
Message: 4
Date: Tue, 27 Apr 2010 14:08:31 -0500
From: Frank Knobbe <frank@knobbe.us>
Subject: Re: [fw-wiz] DNS Names for external services
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <1272395311.55474.1.camel@localhost>
Content-Type: text/plain; charset="iso-8859-1"
On Mon, 2010-04-26 at 19:46 -0400, Morty Abzug 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).
> Re-read above. GP advocated setting up a honeypot on well-known names
> that *blocks* the source IP.
No, I said "Use it to respond in anyway you see fit for defense of your
network". Blocking was one example. If you don't want to do that, then
don't :) Respond anyway you like.
Cheers,
Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: This is a digitally signed message part
URL: <https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20100427/4a7b7807/attachment-0001.pgp>
------------------------------
Message: 5
Date: Tue, 27 Apr 2010 16:05:10 -0400 (EDT)
From: "R. DuFresne" <dufresne@sysinfo.com>
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: <Pine.LNX.4.64.1004271603410.28813@darkstar.sysinfo.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Does that not depend upon what your honeypot is set to do for defense? At
least one user may well have just gotten spanked and blocked from the
network. Hopefully not the whole netblock the internal user is from
though...
Thanks,
Ron DuFresne
On Fri, 23 Apr 2010, david@lang.hm wrote:
> 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
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
admin & senior security consultant: sysinfo.com
http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
These things happened. They were glorious and they changed the world...,
and then we fucked up the endgame. --Charlie Wilson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFL10N5st+vzJSwZikRAtAhAJ9I91pOqC9bRiVLrXHMY12cUSOakACeIbOl
Y2AbHSaYHgE2Ei+kRZVXfgo=
=K1/K
-----END PGP SIGNATURE-----
------------------------------
Message: 6
Date: Tue, 27 Apr 2010 18:07:30 -0400 (EDT)
From: "Paul D. Robertson" <paul@compuwar.net>
Subject: Re: [fw-wiz] DNS Names for external services
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <Pine.LNX.4.44.1004271806090.29939-100000@bat.clueby4.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 26 Apr 2010, Morty Abzug wrote:
> 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.
>
That's not a problem in my book. Now perhaps your acceptable usage policy
allows users to connect to anything they can dream up- but every single
one I've ever written says what resources my users can use, and if they're
on a fishing trip and they get shut out, then I'm not going to lose any
sleep over it.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
paul@compuwar.net which may have no basis whatsoever in fact."
Moderator: Firewall-Wizards mailing list
Art: http://PaulDRobertson.imagekind.com/
------------------------------
Message: 7
Date: Tue, 27 Apr 2010 08:16:55 -0700 (PDT)
From: "Lloyd, Mike" <drmike@redseal.net>
Subject: Re: [fw-wiz] Firewall review tool for Junipers
To: <firewall-wizards@listserv.icsalabs.com>
Message-ID: <01fe01cae61c$ac46e300$04d4a900$@net>
Content-Type: text/plain; charset="us-ascii"
Fair warning - I build a commercial product for firewall and network
analysis. I will try to focus on the technical issues raised here.
In context of PCI rule assessments:
On Fri Apr 23 15:17:30 EDT 2010, David wrote:
> 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.
Yes, and there are several commercial products that can show you a diff
for an arbitrary time span, for any flavor of firewall you happen to use.
Note, however, that the PCI requirement is not "show that you checked each
delta". As written, the reg says you need documentation for every allowed
access between the major zones (not just the new ones). That is, the
burden is primarily to keep a block of documentation in synch with the
block of rules. As such, it's good, but not enough, to just review a
6-month delta list.
Also, note that the reg requires review of the ruleset vs the
documentation "at least" every six months. The best organizations I've
seen manage this on a daily basis! Every change to the rulebase goes
right along with a change in the stack of documentation - the two are not
allowed to drift. This is a tiny extra effort in a robust change control
process, but can be a huge savings when it's assessment time.
The tricky part is proving the docs match the network. I've seen
companies home-brew this, effectively by trying to prevent any changes
outside process and then demonstrating that each change did indeed do what
the documentation said. That's tough, so my preferred approach is to
throw software, not people, at the task of docs-to-network comparison.
(Done right, I claim this is easily the most efficient and lowest labor
approach, but the software does end up costing money.)
> 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.
It's true that the lack of a standard for firewall rule description is
painful. As many folks here know, firewalls don't even all follow a
uniform architecture. (There are the interface-based, zone-based, and
central rule styles. And then there's all the gore of order of NAT
processing, routing, etc.)
For what it's worth, we work with ascii from almost all firewall or router
types. That is, we had to just deal with the fact that every syntax is
different. (Sometimes - Check Point - there's not even an ascii
representation.) We do normalize them all into an XML format, but we
haven't released that format or the translators separately. We've
discussed releasing it before, but there wasn't a clear community
interest. (Largely, we just heard interest from other vendors who could
benefit from the effort we've spent to normalize configuration languages!)
Do let me know if that's an interesting angle.
> XML does not diff well with line-oriented tools, can anyone point at a
> good tool for looking for differences in XML files?
Sorry, I don't have a great pointer for that. It would make sense. I'm
just suggesting there's more to the problem - even neatly cutting out the
diffs doesn't really solve the problem of "prove the network matches the
documentation".
Mike Lloyd
Chief Scientist
RedSeal Systems, Inc
"You can't find a route around a firewall by reading the firewall."
------------------------------
_______________________________________________
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 13
************************************************
No comments:
Post a Comment