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: Proxies, opensource and the general market: what's wrong
with us? (David Lang)
2. Re: Proxies, opensource and the general market: what's wrong
with us? (Magos?nyi ?rp?d)
3. Re: Proxies, opensource and the general market: what's wrong
with us? (ArkanoiD)
4. Re: Proxies, opensource and the general market: what's wrong
with us? (Claudio Telmon)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Apr 2011 18:52:16 -0700
From: David Lang <david@lang.hm>
Subject: Re: [fw-wiz] Proxies, opensource and the general market:
what's wrong with us?
To: <firewall-wizards@listserv.cybertrust.com>
Message-ID: <503aa1e6a026995f7ce330fc715db43a@lang.hm>
Content-Type: text/plain; charset=UTF-8; format=flowed
On Thu, 28 Apr 2011 12:35:58 -0700, Tracy Reed wrote:
> On Thu, Apr 28, 2011 at 08:05:20AM +0200, Magos?nyi ?rp?d spake
> thusly:
>> But it is not. Network perimeter defence is an industry seriously
>> hit by marketing bullshit from some vendors, who could not come out
>> with a decent firewall, so redefined the term to be applicable to
>> their products.
>
> The proliferation of BS is a serious problem. Buzzwords are
> everywhere.
> It is hard to know what really provides value/security and what is
> just
> buzzwords and lengthening the bullet list of features to make the
> product more attractive.
>
>> Doing this they came out with a definition which goes against basic
>> security principles and empties the meaning of the word to the
>> extent which makes nearly pointless to have "firewalls".
>
> I think it would be hard to make the argument that it is pointless to
> have packet filters. How would defining a firewall as a packet filter
> go
> against basic security principles? You could then simply say you need
> a
> firewall (packet filter) AND these various other proxies and tools to
> secure your network. Perhaps we are not really doing ourselves a
> favor
> by overloading the word "firewall" to such an extent?
you are misunderstanding us.
nobody is claiming that packet filters are not firewalls, what we are
arguing against is the idea that is stuck in many people's head that
firewalls are _only_ packet filters.
I work in a banking company, and I have had arguments with architect in
both the operations and development fields that our firewalls are wrong
because they are trying to do more than just restrict by port, that that
is all a firewall is supposed to do, anything else is some other type of
device, but whatever it is, it's not a firewall.
>> This led to a state of affairs where there is practically no
>> discussion about a lot of important questions of network perimeter
>> defense, because the majority of the "firewall" people are kept in a
>> darkness about the issue to the extent that they do not have the
>> background even to ask the right questions.
>
> What are some of the questions that you feel get overlooked?
when people get the mindset that _all_ a firewall is is a packet
filter, the only questions they ask are what ports does a particular
tool use. If they realize that a firewall can do more, they can start to
ask questions about what the protocol is, what enforces it, and if you
are really lucky, what functionality does the protocol offer, and what
subset of what is offered is really needed in this case (because I have
yet to see a protocol defined where all functions are needed in all
cases, outside of single-use situations). It's very common that the
things outside of that subset can be a significant danger, but if you
only think of a firewall as a packet filter, you don't even think of
these sorts of questions, because your firewall couldn't possibly
enforce anything.
>> This means that even though those same vendors now would be in the
>> position to implement actually meaningful features, they do not do
>> it because they have conditioned their consumers to not think about
>> such things.
>
> I think they have simply failed to educate the customer of the value
> of
> those features. The vendors are constantly looking for ways to
> differentiate themselves in what has fast become a commodity market.
> Why doesn't the customer care? If I see two boxes on the shelf with
> the
> same price but one seems to offer more security than the other I'm
> going
> to buy that one. But the additional perceived security just isn't
> there
> for the customer.
you are a _very_ rare consumer. The problem is that the device that
provides more security is either going to be slower, or more expensive
than the device that provides less, simply based on the fact that
implementing security requires checking things, and that takes cpu
cycles, so you either have the same hardware, but are slower, or you
have more expensive hardware to get the same speed.
this ignores the fact that the big name vendors have turned the
benchmarking game into such a fiasco that experienced people discount
their rated numbers by about an order of magnitude to figure what they
will really get when they start turning checking on.
I've had management complain when I purchased proxy firewalls rated at
8Gb/sec to connect to an internet connection slightly under 1Gb/sec,
they ended up replacing them with Cisco devices rated at something like
20+Gb/sec, however if you turned on logging of connections (and
especially logging of blocked connections), it turned out that the Cisco
devices couldn't keep up with the traffic.
>> When you see someone trying to correct this "firewall = packet
>> filter" nonsense, you actually see a vain attempt to correct these
>> mistakes. Because the first step is to meaningfully discuss
>> something is to have meaningful definitions.
>
> I understand and appreciate that a firewall can be more than just a
> packet filter. But to insist that a packet filter is not a firewall
> does
> not seem to accomplish anything because then you have to define
> exactly
> what a firewall really does require to be called a firewall which can
> get quite complicated.
as I've stated above, many people don't accept, let alone appreciate
that a firewall can be more than a packet filter.
even in this thread, the subject of which is opensource proxies, the
response from several people was "you're wrong, just look at X" where X
is a packet filter tool.
> The idea that all of that functionality should be in one box or
> provided
> by one vendor bothers me also. It seems to violate the UNIX
> philosophy
> of do one thing and do it well.
things get rather complicated when you try to split the functionality
between multiple boxes, especially if your application isn't proxy
aware. you either end up with a bunch of boxes daisy-chained, or you end
up with one box splitting the traffic to go to other boxes (and if you
have NAT involved, this can get _really_ fun)
it's also much easier to secure a smaller number of boxes.
that's not saying that multiple systems can't work, but if you can run
the multiple types of security on one system, why would you want to
split them across multiple systems?
the Unix philosophy is not one system to do one thing and do it well,
it's one _tool_ to do one thing and do it well. If I can run many tools
on one system (and have the processing power to do so), that's a really
good thing, because I can then combine the tools in ways that I can't do
if they are on separate systems.
David Lang
------------------------------
Message: 2
Date: Fri, 29 Apr 2011 06:30:32 +0200
From: Magos?nyi ?rp?d <mag@magwas.rulez.org>
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>
Message-ID: <4DBA3EE8.7010705@magwas.rulez.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 2011-04-28 21:35, Tracy Reed wrote:
> On Thu, Apr 28, 2011 at 08:05:20AM +0200, Magos?nyi ?rp?d spake thusly:
>
>> Doing this they came out with a definition which goes against basic
>> security principles and empties the meaning of the word to the
>> extent which makes nearly pointless to have "firewalls".
> I think it would be hard to make the argument that it is pointless to
> have packet filters.
Yes, packet filters are needed to have basic domain separation. But that
can be achieved in the routers as well.
Yes, separation of security controls from operation is a good practice,
but you
1. cannot do meaningful separation without net ops anyway
2. can designate routers to that
Yes, there are still some possible minor functionality losses and other
problems, but honestly I have seen complex firewall setups which would
have been achieved better with some routers. Yes, this is not always the
case, this is why I have used the word "nearly".
> How would defining a firewall as a packet filter go
> against basic security principles? You could then simply say you need a
> firewall (packet filter) AND these various other proxies and tools to
> secure your network. Perhaps we are not really doing ourselves a favor
> by overloading the word "firewall" to such an extent?
SPF technology is what goes against basic security principles, namely
"default deny".
I don't like to argue about words, because they are just labels, and if
there is an agreement on the meaning of the label, it is utterly
unimportant how the label looks like.
This is why it would have been totally perfect to define "firewall" as
packet filter at the beginning. (Only that firewalls were invented to do
things which packet filters cannot.)
But if you redefine a word to mean much less than it have meant before,
you will have a gap.
When the auditor recommends firewall to defend an application, it means
"defend", which is much more than "separate mostly, but leave it wide
open on the biggest attack vectors".
>> This led to a state of affairs where there is practically no
>> discussion about a lot of important questions of network perimeter
>> defense, because the majority of the "firewall" people are kept in a
>> darkness about the issue to the extent that they do not have the
>> background even to ask the right questions.
> What are some of the questions that you feel get overlooked?
>
Information flow control policy, labeling, the relationship of network
perimeter defense to the enterprise data-, application-, and technical
architecture.
You might have noticed that DoD have invented the notion(buzzword) of
"enclave". I haven't seen much discussion even here on how that notion
can be interpreted for various cases in the commercial world.
>> This means that even though those same vendors now would be in the
>> position to implement actually meaningful features, they do not do
>> it because they have conditioned their consumers to not think about
>> such things.
> I think they have simply failed to educate the customer of the value of
> those features. The vendors are constantly looking for ways to
> differentiate themselves in what has fast become a commodity market.
> Why doesn't the customer care? If I see two boxes on the shelf with the
> same price but one seems to offer more security than the other I'm going
> to buy that one. But the additional perceived security just isn't there
> for the customer.
My point is exactly that the lack of customer education from vendors is
the direct result of the marketing campaign which redefined the meaning
of firewall:
After saying so many times that whole classes of security functions
doesn't belong to firewalls, it would be so inconsistent to state that
firewalls should have those functions, that even customers in the US
would have noticed that there is something wrong there.
>> When you see someone trying to correct this "firewall = packet
>> filter" nonsense, you actually see a vain attempt to correct these
>> mistakes. Because the first step is to meaningfully discuss
>> something is to have meaningful definitions.
> I understand and appreciate that a firewall can be more than just a
> packet filter. But to insist that a packet filter is not a firewall does
> not seem to accomplish anything because then you have to define exactly
> what a firewall really does require to be called a firewall which can
> get quite complicated.
>
> The idea that all of that functionality should be in one box or provided
> by one vendor bothers me also. It seems to violate the UNIX philosophy
> of do one thing and do it well.
You have a very valid point here. Do one thing and do it well. This is
why a firewall doesn't do packet filtering or tcp session handling.
It leaves those functions to the operating system; using, defining and
controlling them in the same way an application uses, defines and
controls the underlying database.
------------------------------
Message: 3
Date: Fri, 29 Apr 2011 14:26:13 +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: <20110429102613.GA12161@eltex.net>
Content-Type: text/plain; charset=koi8-r
On Thu, Apr 28, 2011 at 06:21:35PM -0700, david@lang.hm wrote:
> the fact that you need to direct me to use a CVS snapshot because all the
> tarballs are too old is a realy good indicator of the problem.
Just check out HEAD. Or, even better, I will upload new snapshot today.
> I looked at openfwtk when it was first announced, and at that time it
> wasn't ready to replace all the parts of fwtk that I use, so I didn't move
> to it. i've checked back once in a while, but without seeing new releases
> it hasn't seemed like there was anything new to test.
>
> I would suggest moving to git or similar DVCS so that you can create a
> fork for developing each new feature and then as each one gets done, merge
> it in to the main trunk rather than having to either keep development out
> of the main repository, or have each snapshot get a fairly random state of
> functionality between all the development.
CVS branches are ok as well..
------------------------------
Message: 4
Date: Fri, 29 Apr 2011 10:22:45 +0200
From: Claudio Telmon <claudio@telmon.org>
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>
Message-ID: <4DBA7555.5030506@telmon.org>
Content-Type: text/plain; charset=ISO-8859-1
On 04/29/2011 06:30 AM, Magos?nyi ?rp?d wrote:
> You have a very valid point here. Do one thing and do it well. This is
> why a firewall doesn't do packet filtering or tcp session handling.
> It leaves those functions to the operating system; using, defining and
> controlling them in the same way an application uses, defines and
> controls the underlying database.
First, let me say that I probably missed "some" discussions on this, I
didn't really read this mailing for long time (I got bored as most
messages were something like: how can I configure this on a PIX ;) ).
However, to my knowledge packet filters have always been considered
firewalls: the definition has been usually based on function (enforcing
a security policy on network traffic) and not on technology. I also
checked some old books, including Cheswick's and Chapman's "old
testaments", and they all confirm that even a static/stateless packet
filter has always been called "a firewall". Now many think that a packet
filter it's the only kind of firewall because (almost?) every well-known
product is a packet filter.
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. The
tcp/ip stack of an os has a lot of code that is useless for a firewall,
be it a router or a proxy, and that could include bugs. Also, it
executes at a high privilege, with the obvious consequences. And, it may
lack some functionality that can be proper for a firewall, including
detailed logging (you have logging in netfilter, but that's a firewall
component, not part of the os functionality). A proper solution would be
to use a user-level tcp/ip stack: some exist, but nobody uses them for
the obvious reasons.
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.
I wouldn't say that most users think that blocking ports is the only
thing a firewall should/can do. Almost every device has currently this
basic functionality, including routers, load balancers etc., so
companies buying an expensive firewall expect it to do something more.
The problem is, if they know what, and if they get it or not ;)
ciao
- Claudio
--
Claudio Telmon
claudio@telmon.org
http://www.telmon.org
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 57, Issue 14
************************************************
No comments:
Post a Comment