Changing Network Configuration


There are several reasons why you might need to change the network configuration of your server: Your company has changed ISPs, and the server is moving from your intranet to the Internet are possible scenarios.

One of the more frequent reasons is that you have built your server in a test environment behind a firewall. Servers are typically built from original distribution CDs that, over time, become outdated. This has the drawback of generating a first cut of the machine that could present several critical vulnerabilities to the network.

It is essential to mitigate the exposures before the machine can be compromised. As we will see in Chapter 12, "Intrusion Detection," detecting breaches on a server requires having a proper uncompromised image of the system environment. If the machine is exploited before the snapshot has been taken, you may never expose the threat. Building servers behind a paranoid NAT-capable firewall provides additional protection while the system is vulnerable.

Network Parameters

Typically, a machine relies on four main items to enable it to have conversations on a network: a TCP/IP address, subnet mask, routing address, and name server information. Additional information such as the network domain name and domain search order facilitate name resolution but are not essential locally within the server.

In the workstation world, much of this information is provided by DHCP. Servers are usually configured with static information to provide more control over their access and their behavior. In many cases, servers accept connections on specific ports, have a conversation, and close the port. Servers typically do not initiate conversations.

Communications within a subnet depend on a machine's address residing within a common address space defined by a mapping of the TCP/IP subnet and the associated subnet mask. If the matching bit patterns are compatible and machines are on a common network segment, conversations are possible. As an example, machines present behind a NAT firewall are often given a network subnet in the 192.168.x.0 with a network mask of 255.255.255.0, where the NAT device is usually 192.168.x.1. Servers and workstations behind the device are able to communicate with each other using bare TCP/IP addresses without the need to define a gateway address or a name server.

A default gateway, or routing node address, is required only if the machine in question requires access to other machines outside the current network subnet. This is true for answering to conversations initiated outside the current subnet as well. Though a packet can reach a server from the other side of the routing node, the return packets require a hand-off address if the outbound target TCP/IP address is not within the server's own subnet space.

Domain name, domain name search order, and DNS server definitions are all related to the way machines resolve human-legible addresses back into network addresses. They provide the opportunity of managing outbound conversations.

Using YaST to Manage the Network Configuration

YaST provides a graphical method for modifying network settings. When changes are made, YaST ensures the necessary updates are made to the appropriate files throughout the system. You can invoke the X Windows System version by clicking on the YaST icon in the menu system or by invoking yast2 from the command line. You can also use the LAN shortcut with either yast or yast2 to go directly to the network setup menu.

DEMILITARIZED ZONES (DMZS)

A DMZ is a network that is surrounded on all sides by firewalls. This prevents any traffic from reaching the machines within the DMZ unless they are specifically allowed.

Permissions for TCP/IP conversations to traverse the firewalls are called firewall rules. These rules require that the source and target TCP/IP addresses, the protocols, and ports be specified for each allowed conversation.

Typically, a firewall is placed between a hostile network (usually the Internet) and Internet-facing machines such a mail, DNS, and web servers. Traffic within the DMZ is controlled with the local server firewall configuration.

The DMZ machines are in turn considered hostile hosts and are further separated from a company's network by yet another series of firewalls. This back-end firewall controls what, if any, protocols are allowed to access the production network environment. Often web servers require access to a production database. This database server should be in a separate DMZ to further protect its content.

In short, a DMZ is an implementation of a layered defense. The more layers of properly configured protection you have, the better you are protected.


Before proceeding, you need to know what you are changing, why you are changing it, and the new values for each parameter. Table 2.2 shows a typical network configuration change form.

Table 2.2. Athena Network Configuration Worksheet

SETTING

OLD VALUE

NEW VALUE

COMMENTS

Server Name

Athena

N/C

Name is unique and ready in external DNS server

TCP/IP Address

192.168.1.242

10.1.2.13

DMZ address reserved for web server

Subnet Mask

255.255.255.0

255.255.255.128

DMZ is a Class C

Default Gateway

192.168.1.1

10.1.2.1

Address of outbound firewall

ADDITIONAL INFORMATION

Domain Name

UniversalExport.ca

N/C

No change

Domain Search 1

universalexport.ca

UniversalExport.ca

Consistency change

Name Server 1

24.226.1.93

10.1.2.10

Managed DNS collection in DMZ

Name Server 2

24.226.1.146

N/A

Only required on the DNS server in the DMZ


The current configuration screen for a server is shown in Figure 2.15. The upper portion of the window shows that there are no unconfigured network cards. The lower portion shows the network cards that have been previously configured and available for changing.

Figure 2.15. Initial LAN configuration screen in YaST.


Clicking the Change button brings up an intermediary window showing the network cards resident within the machine. In the case of servers with a single NIC, the required card is already highlighted, and you can select Edit to continue with the reconfiguration. If your server has additional interfaces, select the one you want to change; then select the Edit button.

You are presented with a window similar to that shown in Figure 2.16. The basic TCP/IP information is there for you to edit. At this stage, you can replace the configured IP address with the server's new permanent address. Ensure that the appropriate subnet mask is also configured.

Figure 2.16. YaST network configuration window.


Selecting the Routing button presents you with the window shown in Figure 2.17. At this stage, complex routing is not required, and you can simply update the unique address for the current default gateway and replace it with the DMZ firewall address as per Table 2.2. The firewall will filter outbound packets to ensure that they are of the appropriate type over known and allowed protocols. Select OK to accept the change and return to the network configuration window.

Figure 2.17. YaST Default Gateway configuration screen.


The final step in the reconfiguration is to define the Domain Name Services accessible from this machine. In some configurations, it is acceptable to have servers able to resolve names Internetwide. In most circumstances, having tight control over name resolution can quickly help you identify an improper configuration, an unidentified requirement or, more importantly, suspicious traffic that might indicate a compromised server.

By pointing name resolution to a single DNS server that does not look beyond itself for name resolution, you have better control over the resulting conversations. In the case of the sample web server, it responds to conversations directly by IP address through ports initiated by requests outside the firewall. The restrictive DNS configuration in the DMZ will prevent any unexpected server-generated conversations from name-resolving hosts and potentially exposing data externally. You can achieve the same effect through a local hosts file and not specifying a DNS server. The current approach, however, allows for consistency within the DMZ and a single location to maintain for updates.

You can incorporate the changes identified in Table 2.2 by making the appropriate modification to the window presented by clicking the Host Name button. You can see an example of the configuration window in Figure 2.18. After you have completed modifications, click OK.

Figure 2.18. Host name and name server configuration.


You can apply the combined changes to the system by selecting the Next button on the Network Configuration screen and the Finish button on the resulting network Card Configuration window.

YaST then applies the updates to the appropriate files across the server. YaST will then automatically restart your network services to incorporate the change.You should then be in a position to test access to the server from the new network as well as the name resolution restrictions incorporated in the design.



    SUSE LINUX Enterprise Server 9 Administrator's Handbook
    SUSE LINUX Enterprise Server 9 Administrators Handbook
    ISBN: 067232735X
    EAN: 2147483647
    Year: 2003
    Pages: 134

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net