TCP/IP-Based Security - IP Address Security

The base protocol over which Web traffic is carried is the Hypertext Transfer Protocol (HTTP). HTTP is generally carried over TCP/IP, the standard Internet Protocol, in most environments. IIS 7 supports HTTP over TCP/IP version 4 (IPv4), the more common protocol of today’s Internet and the same network-level protocol as every version of IIS to date has supported. IIS 7 also adds support for HTTP over TCP/IP version 6 (IPv6), the protocol version for the next generation of Internet support.

The first consideration regarding blocking or allowing access is whether your target users can get traffic routed to and from your servers. Using an internally routed IP address will help prevent outside parties from accessing an intranet site. If your organization’s routers are correctly configured, an internally routed IP address can be relied on as proof that the client requesting a connection is within your organization. Use external IP addresses with care to identify connecting clients, because they can incorrectly describe the location of the client in many ways. An external IP address may have belonged to one user yesterday, and a different user today. External IP addresses are shared between multiple users, as in the case of an anonymizing proxy, which is designed to hide the identity of a client.

Whitelisting by source IP address—rejecting all connections other than those from addresses of known partners—is mostly reliable, because it is very difficult to forge a TCP connection for any purpose more complex than a simple denial of service attack.

Blacklisting by source IP address—accepting all connections, and rejecting connections from hosts known to be bad—is generally not successful, because attackers are generally able to move to a new host that is not known to be bad.


The ipSecurity element has two attributes:

• allowUnlisted, which affects whether the list of child elements of ipSecurity is checked for known bad or known good source IP addresses. When you set allowUnlisted to false, only the child elements marked with allow can access this Web server, and all others will be denied. When you set allowUnlisted to true, all IP addresses will be allowed to connect except those specifically marked as deny.

• enableReverseDns, which you must set to true if you are going to filter by domain name. Because the reverse DNS lookup can take some time that would delay connections, leave this attribute at its default value of false if you are not interested in filtering by domain name. Remember that many DNS zones do not feature reverse lookups, and Windows does not create reverse lookup zones by default.

As a result, reverse DNS lookup will very often fail. Child elements are added to the ipSecurity collection by the usual add, clear, or remove directives, with the following attributes:

• ipAddress is the numerical IP address of the host or network being allowed or denied access. For instance, 127.0.0.1 would represent the localhost. If you are denying access by default (setting allowUnlisted to false), you will generally want to enable access by 127.0.0.1 and other locally bound IP addresses for testing.

• subnetMask is the numerical subnet mask that defines which network is being referenced by IP address. For instance, to cut off the entire 10.*.*.* network, you would use an ipAddress of 10.0.0.0 and a subnetMask of 255.0.0.0. The default value is 255.255.255.255, which masks to a single IP address.

• domainName is a fully qualified domain name of a host that this rule should apply to.

• allowed will—when set to true—allow all clients that match the rule given, and when set to false will deny all clients that match the rule. The rules are processed in order from first to last, and the first match dictates what is done with the incoming connection.

Source of Information : Microsoft Press Windows Server 2008 Security Resource Kit