RE: firewalls and the incoming traffic problem

[Itai Dor-on <silicom () netvision net il>]

I tend to disagree with your point of view regarding the propose of the firewall system.
In my opinion the "firewall" system is mainly a platform for developing "security components" that handle
specific application security issues.

> From your post I understand that you see firewalls mainly as pure "packet filters".
A firewall should provide the engine (Os) to develop on  

> The proxy/nonproxy discussion is becoming increasingly
> irrelevant, as a result. Let's assume I'm using some kind
> of turbo-whomping stateful filter -- in that case I need to
> worry A Whole Lot about the implementation of my Email
> service. If I'm allowing the whole world to reach port
> 25 on my mail server, then the whole world can probe
> it for bugs, and, if I'm running a buggy mailer, I have a
> real problem. If I'm using a proxy firewall, the proxy
> may perform some additional checks, and may block
> some well-known attacks, but the problem is still there.

Well, Not at all but on the contrary. Due to the current-near future Internet Infrastructure we are 
limited by the current TCP/IP protocol security limitations and with that we have to deal with.
It is not practical, under the current implementation for any vendor to support all known Internet 
service that are Home made.

Thus, Security handling should rely on the specific software vendor (Which know or don't know his 
own material best).
Any vendor writing applications that are Internet aware should take security exploits in his product under 
consideration. and support  it. 

I don't think that the direction of technologies like proxy/statefull inspection should change under 
the current Internet infrastrucutre.BUT the software market should reinvent itself by selling or supporting 
security as an added value/feature to the base product. 

 
Suppose  I am customer that runs firewall-1 as my main security defense and I was doing a 
market research for a new Internet mail server.

If  had to make a discussion between one product that does all the basic things and it's security 
is supported by the vendor throughout a special implementation on the firewall-1 product AND another 
very sophisticated mail server which is not supported.

I would consider the availability time to be prime factor for decision. thus selecting the first.

The whole concept must change firewall vendors should supply the a very sophisticated-but 
not application aware   
OS (like some one we know -  M...). It should provide the tools/programming language for an 
easy development of packet/session content examination built  by various vendors.

To think of developing a pro-actively secure solution is not-serious in this era of time.
Providing a sophisticated platform for quick development of security defense components 
is the only way to go at the moment.


Bye.

Itai Dor-on
 
p.s

I apologize in advance for my English grammar.



"Three may keep a secret, if two of them are dead"

- Benjamin Franklin, 1735
 
-----Original Message-----
From:   Marcus J. Ranum [SMTP:mjr () nfr net]
Sent:   à 28 ñôèîáø 1997 13:32
To:     firewall-wizards () nfr net
Subject:        firewalls and the incoming traffic problem

I'm concerned that firewall technologies are going to
reach an impasse in the next couple of years over what
I am calling the "incoming traffic problem."  Briefly, the
problem:
        - Firewalls are good at providing access control
        on return traffic that is in response to a request
        that originated behind the firewall
        - Firewalls are poor at providing access control
        on "unsolicited" incoming traffic to generic
        services that are "required" as part of being on
        the Internet
        - The number of generic services is increasing
        slowly
        - The number of implementations of the generic
        services is increasing dramatically

Let's take Email as the perfect example. If I have a mail
server behind a firewall, and I want to receive Email,
I have to allow it in to my mail server somehow. More
importantly, for Email to work the way we want it to, I
have to allow Email from virtually any site in to that
mail server. Therefore, the firewall's protection is reduced
as regards my Email service. (I'll come back to the proxy
nonproxy issue later) So, we're back to worrying about
sendmail - or are we? Nowadays there are zillions of
implementations of SMTP, on many different O/S platforms,
and it's likely that there are security holes (of one sort or
another) in many of them.

The proxy/nonproxy discussion is becoming increasingly
irrelevant, as a result. Let's assume I'm using some kind
of turbo-whomping stateful filter -- in that case I need to
worry A Whole Lot about the implementation of my Email
service. If I'm allowing the whole world to reach port
25 on my mail server, then the whole world can probe
it for bugs, and, if I'm running a buggy mailer, I have a
real problem. If I'm using a proxy firewall, the proxy
may perform some additional checks, and may block
some well-known attacks, but the problem is still there.
What if I have a proxy firewall built by a UNIX guru,
which knows about mail to: /bin/sh, but which doesn't
know about mail to: c:\autoexec.bat? Those are the
easy cases -- what about the bug in bubbmail1.2 for
Windows NT, where if you send mail addressed to
to: <admincommand: reboot> it will reboot the
machine? A little feature that crept in there...

<<application/ms-tnef>>