This article is from the Firewalls FAQ, by Matt Curtin cmcurtin@interhack.net and Marcus J. Ranum mjr@nfr.com with numerous contributions by others.
For firewalls where the emphasis is on security instead of connectivity,
you should consider blocking everything by default, and only specifically
allowing what services you need on a case-by-case basis.
If you block everything, except a specific set of services, then you've
already made your job much easier. Instead of having to worry about every
security problem with everything product and service around, you only need
to worry about every security problem with a specific set of services and
products. :-)
Before turning on a service, you should consider a couple of questions:
* Is the protocol for this product a well-known, published protocol?
* Is the application to service this protocol available for public
inspection of its implementation?
* How well known is the service and product?
* How does allowing this service change the firewall architecture? Will
an attacker see things differently? Could it be exploited to get at my
internal network, or to change things on hosts in my DMZ?
When considering the above questions, keep the following in mind:
* ``Security through obscurity'' is no security at all. Unpublished
protocols have been examined by bad guys and defeated.
* Despite what the marketing representatives say, not every protocol or
service is designed with security in mind. In fact, the number that are
is very few.
* Even in cases where security is a consideration, not all organizations
have competent security staff. Among those who don't, not all are
willing to bring a competent consultant into the project. The end
result is that otherwise-competent, well-intended developers can design
insecure systems.
* The less that a vendor is willing to tell you about how their system
really works, the more likely it is that security (or other) problems
exist. Only vendors with something to hide have a reason to hide their
designs and implementations.
 
Continue to: