Re: Proxies, opensource and the general market : what's wrong with us?

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