 |
|
 |
 |
|
1/5/2004 Securing a Solaris Server - Network Topology
|
|
For most people, the network topology that they use is already set. This section is to help them to understand the strengths and weaknesses of the topology they have to work with. The network administrator should be able to provide further assistance and clarification.
For the lucky few who are building a network from scratch, there's enough information here to give you a general idea of what you want to do, but probably not enough to actually do it. I suggest that you work with your network people, your ISP, a good vendor representative, or a reputable consultant, as this will greatly improve your chances of creating a secure and functional network.
The O'Reilly book Building Internet Firewalls (1) has additional information on network topologies.
The general network topology that I've assumed in the rest of this web page, is a server with one or more network interfaces that are connected to the Internet, without any filters.
If your border router is performing packet level filtering, or if your server is behind a firewall, your server will be more secure from outside attacks. It will not be any more secure from inside attacks. Unfortunately, most disastrous intrusions occur due to inside attacks.
Several general network topologies are available. I have created diagrams of three network topologies that show, in general, how most networks are configured. Each of these will be briefly discussed.
In this topology, you either own, or rent, a server and place it at an ISP. There is a direct connection from the ISP's router (or switch) to your system, usually over a 100 Megabit connection. This topology places the highest possible security demands on your server, as it is fully and directly accessible from the Internet. The high speed of the connection will also allow large amounts of data to be transferred if an intrusion occurs.
In this topology, the router is not performing packet filtering. Typically, the decision to not filter packets would be made because the router doesn't have enough CPU power to perform packet filtering. The decision could also be made because the configuration management for the router tables would get too complex, or because a political decision has been made that no packet filtering will be performed. Often, the router will be a DSL or Cable modem. This topology is often used in a Small Office/Home Office (SOHO) network.
Many educational institutions also use this topology, even though they usually use high-speed leased lines, with several Megabits per second bandwidth, coupled with powerful routers and switches, and is an example of a political decision to use this topology.
With this topology, all systems on your network are fully and directly accessible from the Internet. The security demands on each system on your network are similar to those for a Co-located Server. The only improvement over the Co-located Server is that the bandwidth through which a compromised system can be exploited is usually lower. In most cases, this network topology is acceptable, only if there are a very small number of systems on your network.
Careful configuration of network routes can improve the security of this topology, but it's a complex task.
VPN connections are possible with this network configuration.
The Mac and PC desktops are kept in separate subnets from the rest of the systems, as these systems send more broadcasts. Also, PC systems running Windows are more difficult to secure than UNIX systems.
The Authentication Server and the Internal File Server should both be connected to dedicated switched ports. Both systems should not have any direct communications with external systems.
Properly authenticated users (login and password) of the Dial-in Server should be allowed connections to external systems, in a manner similar to the internal desktop systems, and should receive the same degree of protection. File sharing should only be done to dial-in systems that are appropriately authorized (a separate issue from authentication). Optimally, only secured connections (ssh) to the internal systems should be allowed.
This network topology is capable of being very secure. Both the border router and the main router are performing packet filtering. If a firewall is not used, the Medium Office Network configuration can be used, as the second router provides little additional security.
The Firewall system should be capable of monitoring the state of the connection. This monitoring gives a high assurance that connections aren't being made to unprotected internal ports.
Some people feel that a Firewall system gives a false sense of security, and that it's better to not use them and make sure that all the systems are properly secured. Other people feel that nothing can replace a properly configured Firewall. I fall between these two camps. I feel that a Firewall is useful in adding to the security of a network, but that it should not be relied upon to give complete security.
If additional protection of, and from, the Dial-in Server is desired, it could be connected to a port on the Firewall, thus providing additional protection for both the internal network, and the dial-up user. This may be useful if a user password becomes compromised.
If there exists a portion of the network where there is external access to the switch and/or the communication fabric, that that network should also be connected through the firewall. This lack of security is most often found on wireless networks.
If VPN is used in this configuration, it should be done in the border router. A connection request should not be allowed to enter the border router from the ISP, unless it's for one of the external servers, or for the Firewall. Also, no RPC or UDP requests should be accepted from the ISP, unless they're for one of the external servers that's supposed to receive them, or responses to DNS or NTP requests.
In theory, the capabilities of both the Border Router and the Main Router can be combined into a single router, but this complicates the configuration.
| Prev | Index | Next |
If you have any comments or suggestions, please E-mail webmaster@accs.com
