Incoming service guidelines

Enabling incoming services creates a conduit into your network. The following are some guidelines for assessing security risks as you add incoming services to a Firebox configuration:

A network is only as secure as the least secure service allowed into it.
Services you do not understand should not be trusted.
Services with no built-in authentication and those not designed for use on the Internet are risky.
Services that send passwords in the clear (FTP, telnet, POP) are very risky.
Services with built-in strong authentication (such as ssh) are reasonably safe. If the service does not have built-in authentication, you can mitigate the risk by using user authentication with that service.
Services such as DNS, SMTP, anonymous FTP, and HTTP are safe only if they are used in their intended manner.
Allowing a service to access only a single internal host is safer than allowing the service to access several or all hosts.
Allowing a service from a restricted set of hosts is somewhat safer than allowing the service from anywhere.
Allowing a service to the optional network is safer than allowing it to the trusted network.
Allowing incoming services from a virtual private network (VPN), where the organization at the other end is known and authenticated, is generally safer than allowing incoming services from the Internet at large.

Each safety precaution you implement makes your network significantly safer. Following three or four precautions is much safer than following one or none.

Related topics:

Configuring Filtered Services

Selecting Services for your Security Policy Objectives

Outgoing service guidelines

Service Precedence

Adding and Configuring Services

Defining Service Properties

Return to Top