Access Denied: Protecting Your Internal Network Against Attacks from Untrusted Networks

Our corporate network connects to the offices of several thousand independent retailers who sell our product. All our internal servers, workstations, and employee accounts are part of our CORP domain, and our retailer's workstations, servers, and user accounts are in our RETAIL domain. No trust relationship exists between the domains; we update orders and availability with servers in RETAIL through manual file transfers. Could a malicious user in our RETAIL domain still attack our network?

Without a trust relationship, no user account in RETAIL can access any computer in CORP. However, your configuration doesn't prevent someone with access to a workstation at one of your retailers from attacking computers in CORP. For example, an attacker could guess the password of a CORP user account, such as the Administrator account. The lack of a trust relationship doesn't prevent someone from connecting to a shared folder in another domain by using an account in that domain; the intruder simply uses the Connect using a different user name option in the Map Network Drive dialog box. Also, unless all your internal servers and workstations are hardened like Web servers on the Internet, an attacker could launch Denial of Service (DoS) attacks or release Internet worms.

The problem is a matter of network access rather than domain configuration. If you can send a packet from computer A to computer B, you can attack computer B regardless of domains. The solution is to implement a firewall or other control between an internal network and any untrusted network.

You have several implementation options that don't require you to redesign your entire network. If you have a router between your retailers' computers and your internal network, you can configure the router to let retail workstations access only the RETAIL servers and domain controllers (DCs) based on the IP subnets assigned to your RETAIL workstations. Or if your CORP domain runs Active Directory (AD) and the workstations and servers run Windows 2000, you can use Group Policy to deploy an IP Security (IPSec) policy that refuses packets from computers with an IP address that identifies them as a RETAIL workstation. Or, if the topology of your network doesn't let you use IP addresses to separate RETAIL workstations from other computers, you can deploy an IPSec policy to your CORP computers that requires Authenticated Header mode for all traffic, with Kerberos as the authentication method. Such a policy will prevent communication with any computer outside of CORP, so you need to create a few exceptions to let the CORP and RETAIL servers that handle the orders and availability update process communicate.