Sunday, May 01, 2011

firewall-wizards Digest, Vol 58, Issue 1

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: proxy firewalls -vs- packet filters (Graham Allan)
2. Re: Proxies, opensource and the general market: what's wrong
with us? (ArkanoiD)
3. Re: Proxies, opensource and the general market: what's wrong
with us? (ArkanoiD)
4. OpenFWTK snapshot (ArkanoiD)
5. Re: Proxies, opensource and the general market: what's wrong
with us? (Fetch, Brandon)
6. Re: Proxies, opensource and the general market: what's wrong
with us? (Darren Reed)


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

Message: 1
Date: Fri, 29 Apr 2011 11:30:49 -0500
From: Graham Allan <allan@physics.umn.edu>
Subject: Re: [fw-wiz] proxy firewalls -vs- packet filters
To: "Marcus J. Ranum" <mjr@ranum.com>,
firewall-wizards@listserv.cybertrust.com
Message-ID: <20110429163049.GA19201@physics.umn.edu>
Content-Type: text/plain; charset=us-ascii

On Thu, Apr 28, 2011 at 07:36:31PM -0400, Marcus J. Ranum wrote:
> Bennett Todd wrote:
>> Probably a naive question, but is there any possibility ipv6 might
>> tear open a gap in the range of available firewall products that
>> user-space application layer proxy firewalls could fill faster than
>> the heuristics for packet filtering can run over enough toes to
>> discover the necessary subtlties?
>
> Probably a snarky answer, but I thought that when the switchover
> to iPv6 happens, nobody'll need firewalls anymore.

Presumably the reason why so many of the firewall venders are thinking
ahead, and not bothering to support IPv6. Who could possibly need that?

G.
--
-------------------------------------------------------------------------
Graham Allan
School of Physics and Astronomy - University of Minnesota
-------------------------------------------------------------------------


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

Message: 2
Date: Fri, 29 Apr 2011 18:09:27 +0400
From: ArkanoiD <ark@eltex.net>
Subject: Re: [fw-wiz] Proxies, opensource and the general market:
what's wrong with us?
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20110429140927.GA13621@eltex.net>
Content-Type: text/plain; charset=koi8-r

On Fri, Apr 29, 2011 at 10:22:45AM +0200, Claudio Telmon wrote:
>
> Proxies have been mostly put on top of an operating system's tcp/ip
> stack, but I wouldn't say that this is a benefit, it's just simpler.

Actually it *IS* a benefit. By eliminating direct packet flow you do not
need to care about bad things sneaking in TCP and below, actually it is the only
way to *reliably* ensure that we see similar data on the firewall and the endpoint.

> Also, having more devices (e.g. separating a packet filter from a proxy,
> and from a VPN concentrator, etc.) means more complexity and more
> errors/bugs.

Sometimes it is just more reliability, depends on how you do implement that :-)

I see little to no reason to combine VPN concentrator and firewall in the single box,
despite the fact it is most popular way to do it.


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

Message: 3
Date: Fri, 29 Apr 2011 18:44:12 +0400
From: ArkanoiD <ark@eltex.net>
Subject: Re: [fw-wiz] Proxies, opensource and the general market:
what's wrong with us?
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20110429144412.GA4473@eltex.net>
Content-Type: text/plain; charset=koi8-r

Could you please share it?

I started hacking something like that with clish, but it was never finished.

On Thu, Apr 28, 2011 at 06:27:16PM -0700, david@lang.hm wrote:
> one other SSH related thing, a SSH enabled version of cmd-gw
>
> I hacked in support for simple authentication (validating the user with
> authsrv) and then added the ability to do some tests and simple work
> through it (do a ps to see what proxies are running, show what the rules
> are for a given proxy, execute hping2 to see if you can get to the
> destination on a given port, etc) and it has proven to be a wonderful tool
> by allowing other teams to execute commands from the firewalls without
> having to give them local logins. One thing that I have found is that I
> need the ability to set permissions per command, not just allowing or
> disallowing users (similar to how ftp-gw could be configured to allow get
> but not put)
>
> David Lang
>
>
> On Fri, 29 Apr 2011, ArkanoiD wrote:
>
> >On Thu, Apr 28, 2011 at 11:01:45AM -0700, david@lang.hm wrote:
> >>
> >>Ok, I'll take a look at that.
> >>
> >Please use CVS snapshot, the current one should be ok (I will probably
> >mark it
> >with some tag), tarballs and rpms are too old.
> >
> >>for an ssh proxy, what I minimally need is the ability to be a direct
> >>replacement for tn-gw and ftp-gw without it enabling tunneling.
> >
> >That might be relatively easy if we are not going to dive deep in key
> >management.
> >I hope I will make some hack (at least better one that patched openssh I
> >used before) soon.
> >
> >>something like tn-gw where the user connects to the firewall then
> >>specifies where to go from there for an interactive terminal session, with
> >>port forwarding
> >>disabled
> >
> >Yes, it was the only thing it did provide.
> >
> >>something like ftp-gw where an authenticated user is able to transfer
> >>files through the connection and log what's moved
> >>
> >>both of these authenticated to authsrv
> >>
> >>future enhancements:
> >>
> >>optionally allow port forwarding
> >>
> >>add the ability to do firewalling for the ports forwarded through ssh
> >>
> >>add the ability to specify what commands can be executed to a destination
> >>through the proxy (as opposed to the default login)
> >>
> >>add key management (for incoming, support using the ssh identity as the
> >>userid, with our without additional authentication with authsrv, for
> >>outbound, support different client certs for different userids, possibly
> >>for different userid/destination pairs) potentially doing the keyserver
> >>relay back to the client. This is the lowest priority item for me.
> >
> >Sounds reasonable.
> >
> >>>>I actually don't have an objection to the firewall being a collection of
> >>>>different tools gathered togeather (that's just good code re-use in the
> >>>>best opensource tradition), it may require some tweaks to code, or some
> >>>>scripts to create the appropriate config files for some of the tools,
> >>>>but
> >>>>that is far better than having to completely re-write the tools.
> >>>
> >>>That's why I was talking about "kickstart" -- a set of configuration
> >>>templates that eases this task.
> >>
> >>actually, I was not thinking in terms of templates, but rather something
> >>that would let you define access in terms of groups like the traditional
> >>authsrv entries in netperm-table and have a script that would create the
> >>corresponding config for squid (picking an example). I actually have
> >>something along these lines today that is a script running out fo
> >>cron that checks the timestamp on netperm-table and anytime it
> >>changes it looks for authsrv lines with http or https types and creates
> >>files for the groups allowing those groups to go to the destinations
> >>specified and then kicks squid with a reconfigure (I ahve other processes
> >>to do authentication for IPs to populate what the sources for each group
> >>are). This allows the use of a fairly mature tool without the people
> >>implementing the permissions having to worry about learning a different
> >>config file format. they just make authsrv entries and everything else is
> >>taken care of for them.
> >
> >There is a tool like that to configure djbdns forwarder service (dnsctl).
> >Maybe other companion tools might be useful, to configure, say, packet
> >filtering
> >(or VPN, or whatever else).
> >
> >
> >
> >_______________________________________________
> >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
>
> email protected and scanned by AdvascanTM - keeping email useful -
> www.advascan.com
>

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

Message: 4
Date: Fri, 29 Apr 2011 18:50:11 +0400
From: ArkanoiD <ark@eltex.net>
Subject: [fw-wiz] OpenFWTK snapshot
To: firewall-wizards@listserv.cybertrust.com
Message-ID: <20110429145010.GA3298@eltex.net>
Content-Type: text/plain; charset=koi8-r

For those of you curious enough to download it: the one on the sourceforge was almost year old,
so better try the new one I just uploaded.

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

Message: 5
Date: Fri, 29 Apr 2011 18:51:24 -0500
From: "Fetch, Brandon" <bfetch@tpg.com>
Subject: Re: [fw-wiz] Proxies, opensource and the general market:
what's wrong with us?
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>,
"firewall-wizards@listserv.cybertrust.com"
<firewall-wizards@listserv.cybertrust.com>
Message-ID:
<A22AB7AA11C57342918639C100566F244E8F13E760@TXMAIL.texpac.com>
Content-Type: text/plain; charset="iso-8859-1"

(Top-post - BAH, get over it. :) )

Catching up on the thread belies what (I think) are a few themes we're discussing:
1. Acceptance (and extension usage) of OSS products in the enterprise
2. The comparative advancement of these OSS products relative to the commercial ones (feature creep/bloat)
3. Usability & application of each product type (OSS vs. commercial)

Acceptance:
I can say from my experience in both a Big-4 and my current employer (check the from field), there's a tendency to always have a "throat to choke". Part of this (I'm hopeful) is based on team preservation (I'd rather we blame an outside vendor than the employee directly) but I'd bet it's more akin to CYA than anything else.

Clich? yes, but "No one's ever been fired for buying IBM..."

Advancement:
As with all commercial products, there's always a need to "build the better mousetrap" and to remain above your competitors regardless if the feature is needed/used/implemented. This compares favorably with OSS products in that there's no time (or code) wasted in implementing or supporting these ancillary (and entirely tangential sometimes) features.

Even though you're not matching "checkbox for checkbox" with commercial products you're bound to have a better performing product that's focused on what you're using it for.

Usability & application:
This goes back to advancement in that the more complicated products you're using the greater likelihood you have of royally screwing things up(tm). Though I've not used OSS products extensively in production environments, my experience has been they do have a tendency to adhere to the more geeky of users and won't give you a pretty face to interact with. A lot of times this suits the ultimate end-user just fine but when you're dealing with corporate segmentation of duties (which is definitely more prevalent in bigger companies) you may be stuck with the pretty GUI vs. a CLI.

I'll touch on application just a bit by rolling back the discussion to the root design of "your" network. If you're running an entirely flat network with huge broadcast domains everywhere and minimal segmentation then yes, I can see how folks will need these types of commercial products that can do tens of gigabits worth of performance. However, with proper segmentation (and requisite understanding) of your data flows you can not only reduce the total utilization of individual devices & ports but you also gain the capability to apply controls at each of these points as well.

Oh, and you can use a lot of these OSS products as the controls running on commodity hardware with (reasonably) no (or minimal) ill affects.

I don't recall who did it from the replies but someone implemented proxy controls at choke points internally within their network. The stakeholders of these now proxied services were crying foul yet they could not prove with metrics there was any impact to their applications.

This is what a fully segmented network gets you: improved performance with control. Whether that control takes the form of L3/4 ACLs on your routing/switching gear or if it means putting a proxy in front of suspect services you now have that capability and can do so in an optimum fashion.

I'd much rather sit down and spend the time to re-purpose some 3 year old servers with a multi-port NICs to run distributed Snort than spend $50k/year for the next 3 years on installing a "flow aware" IPS. But in this case my employer deems that cost an appropriate trade-off relative to my expense in time lost developing the OSS design. I'm not the one making these decisions but I wouldn't be a good conservator of my company's ward if I were to only make the Snort recommendation.

Coming from a "corporate security weenie" I can say businesses predominantly like "solutions", checkboxes, and throats to choke but unfortunately a lot of times OSS products can only give us 2 of those 3.

Sorry for the long (and top-posted) reply.
Brandon

-----Original Message-----
From: firewall-wizards-bounces@listserv.icsalabs.com [mailto:firewall-wizards-bounces@listserv.icsalabs.com] On Behalf Of ArkanoiD
Sent: Sunday, April 24, 2011 1:28 PM
To: firewall-wizards@listserv.cybertrust.com
Subject: [fw-wiz] Proxies, opensource and the general market: what's wrong with us?

In early days, proxy firewalls and opensource (or just "crystal box" :-) solutions dominated the market.

Now both are either extinct or forced to an ulgy low end (for opensource, it usually means having no
security-centric framework, no common API, no real code review -- just a bunch of "functionally fit"
free things installed on a linux box with some simple web interface). For proxy firewalls the future is
even more questionable. Multiple state-of-the-art technology leaders were merging (quite obviously being
unable to stay competitive with cheapo crap) until there was only One left.. SC, later bought by McAfee.
And now McAfee is owned by Intel and it seems to show no interest in high end firewall solutions at all,
they seem to think they just bought an "antivirus company".

I asked guys on LinkedIn (having to admit LinkedIn security community sucks big time, some sane people are still there :-)
, if they still have some interest in opensource firewall solutions. The short answer
was "NO". The long ones were:

-- It is all about performance, we want as many Gbits per $ as possible, so ASIC is only way

-- It is all about features and support, no free solution fits.


And the second point seems to be pretty valid. We have *NO* product that is a match for current "market leaders".
It does not mean it is impossible: it is quite obviously possible, but we still do not have it.

You may take OpenFWTK, Prelude, Snort, ClamAV, some unix of you choice and.. still not get really the same.
Protocol support is not that good, no common management interface and not really ready for enterprise which
is not full of geeks at all, management overhead and TCO are going to jump up beyond any reasonable limit.

OpenDLP is just a sad joke, running a bunch of regexps against your data is not the thing to be called DLP.

As I am still running the OpenFWTK project, I have to admit I get little to *NO* support form Opensource community.
The single reason the project is still alive is occasional donations and paid feature requests from *commercial* vendors who
use some OpenFWTK components in their products. Maybe once a year or two I receive a bug report or even a patch or some half-baked
piece of documentation. I appreciate that, but most of the times I never hear from those people again.
Despite that, Sourceforge shows several downloads/checkouts daily, but the feedback is close to zero. Once I googled for
OpenFWTK I found some japanese site with patches they did not bother even to send me, and there was no contact email and
no way to send them any questions as comment form was protected with captcha in japanese!


_______________________________________________
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: 6
Date: Fri, 29 Apr 2011 12:50:35 -0700
From: Darren Reed <darren.reed@oracle.com>
Subject: Re: [fw-wiz] Proxies, opensource and the general market:
what's wrong with us?
To: firewall-wizards@listserv.cybertrust.com
Message-ID: <4DBB168B.40503@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I think that what's happened is the relevant open source
security tools for today are no longer proxies or packet
filters but plugins for your web browser.

Why?

Your DSL/cable modem will have firewall/NAT stuff in it
for home and for corporate, you've got dedicated hardware.
Its role is to allow you to use things like DLNA and Bonjour
and other services inside your home network whilst providing
protection from hackers that want to mount your IPC$.

With more sophisticated content, the threat model has moved
past basic access to the system and into the content itself.

Proxies and virus software can, to some extent, deal with this
but I now find myself relying more on two other open source
tools: "no script" and "request policy". At the time I started
using "request policy", if it wasn't already available then
I would have started writing one myself. What's lacking with
these two tools is the enterprise solution where a configuration
is delivered to users in a manner that they can't play with it.

IMHO, the problem space for open source security solutions that
are relevant to today has moved on..

Darren

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

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


End of firewall-wizards Digest, Vol 58, Issue 1
***********************************************

No comments:

Post a Comment