Restricting the Scope of the Service

I l @ ve RuBoard

Restricting the scope of a service limits the locations which can access the service. This will limit the area where information can be disclosed. It also provides a level of security by limiting the locations from where an attack can be conducted .

TCP Wrapper

TCP Wrapper was developed by Wietse Venemand has been very popular among the UNIX community. It is a TCP/IP daemon wrapper package. A wrapper is used to give an existing program additional functionality without modifying that existing program. For example, if a higher level of security is desired for the FTP daemon, such as restricting access from a specific host, the wrapper program is put in its place and after access has been granted, the actual FTP server is started. The TCP Wrappers product suite provides an enhanced security mechanism for various services spawned by the Internet Services daemon, inetd . TCP wrapper, tcpd , package allows for the restricting of TCP services to specific interfaces or limiting requests to specific addresses. It does not require any modification to the existing network programs. It is a wrapper which is started from inetd and front-ends the actual service.

TCP Wrapper, tcpd, comes standard with Red Hat and Free BSD. It is available on HP-UX 11i platform as a web upgrade.

TCP Wrappers uses /etc/ hosts .allow and /etc/hosts.deny files as Access Control Lists (ACLs). These access control files are used to match the client and server entries with the request for a service. These files are based on pattern matching and consist of a set of access control rules for different services, which use tcpd.

Whenever a connection is established with inetd for a service, inetd runs the appropriate server program specified in /etc/inetd.conf and waits for other connections. TCP wrapper is installed by replacing the server which it is to protect in the configuration file with tcpd. Inetd then runs the wrapper program tcpd instead of running the server program directly. When inetd invokes tcpd for a service, it will read the /etc/tcpd.conf file and configure itself to effect its behavior for different features at run time.

Xinetd Security

Xinetd has the ability to limit the scope of the systems which will be allowed access to each service. The configuration file for each of the services has to be configured to select where the connections can be made. Connections can be limited to a specific interface. Client can be limited by IP address, either by inclusion or exclusion. Services can also be limited by time of day.

 interface = 192.168.1.1  only_from = 192.168.1.0/24  no_access = 192.168.1.9  access_times = 09:00-16:30 

inetd Security

The HP-UX inetd security feature is an addition to the internet daemon, inetd , and is a standard part of HP-UX. It provides controls similar to those available from tcpd , allowing selective access to services based on the address of the client. It uses the security file, /usr/adm/inetd.sec , to allow or deny access to services by host or network address. Each service can have a set of hostnames, network names , or address ranges which can be allowed or denied . The following line would allow logins the specified IP addresses and deny all others.

 login         allow   10.3-5 192.34.56.5 

Software Features

BIND, v8.1.2, included in HP-UX 11i , is much more configurable than previous releases. The new security features enable entirely new areas of configuration, /etc/bind.conf , with many options that previously applied to all zones which can now be used selectively. These mainly apply to such areas as access control lists and categorized logging.

BIND v8.1.2 protects all DNS client/server transactions with IP address-base ACLs. On a name server, ACLs control who can query the name server, initiate zone transfers from the name server, and request dynamic updates, as well as restrict the name servers to which queries can be sent. IP- address-based access control for queries, zone transfers, and updates may be specified on a zone-by-zone basis.

These access controls rely on the source IP address stated in IP packets to determine the identity of the transaction initiator. If no precautions are taken, IP address spoofing can subvert this control mechanism. This is one manifestation of the well-known security limitations of the existing Internet DNS version 8.1.2.

BIND v9 includes protocol enhancements necessary to securely query and update zones. The IETF is addressing the security limitations of the Internet DNS through the introduction of DNS security protocols, including DNSSec, TSIG, and TKEY. These protocols are implemented in BIND version 9. This version of BIND is a major rewrite of nearly all aspects of the underlying BIND architecture.

DNSSec is specified in the Proposed Standard RFC 2535. It provides data integrity and authentication to security-aware resolvers and applications using cryptographic digital signature. It prevents non-authorized access to DNS, and prevents name-to-address mapping tampering over the wire. These are the type of active network-level attacks to which DNS has been susceptible. DNSSec can also be used to safeguard DHCP dynamic updates. It restricts DHCP updates to those authorized to perform them. It guarantees the integrity of zone data, using digital signatures produced off-line by the owner of the data and stored in SIG Resource Records.

DNS Security Operational Considerations is covered by RFC2541, which covers the operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records.

• TSIG, Transaction SIGnature, can be used to cryptographically authenticate transactions. A key is shared by the resolvers and the name servers, and they use it to sign communications between them. Specifically, the integrity and origin of the data exchanged in a transaction are protected by HMAC-MD5, using a key shared by the servers involved. This key must be securely distributed to the participants by a manual configuration process.

• TKEY is a protocol which addresses the problem of distributing shared keys for TSIG by allowing participants in DNS transactions to establish shared secret material. Note that TSIG requires time synchronization between the name servers involved, and the name of the key (not just the key itself) must match on the servers. In addition, TSIG does not provide zone data integrity or secure binding of public keys.

I l @ ve RuBoard