Task A: Routing

In this task, we are configuring static routing in the network to ensure that all hosts within the "talos.edu" network can communicate with each other via an optimal path, while adhering to specific requirements.

Requirement 1:

Router R1: We add static routes to R1 to enable it to forward traffic within the "talos.edu" network optimally. The following routes are added:

192.168.1.0/24 via eth1

192.168.2.0/24 via eth2

These routes ensure that R1 forwards traffic within the "talos.edu" network based on the destination subnet. We chose these routes based on the topology of the network.

Router R2: Similar to R1, we add static routes to R2 for the "talos.edu" subnets via the appropriate interfaces.

Router R3: R3 serves as the default gateway for the "talos.edu" network, and we configure it with static routes for the "talos.edu" subnets and a default route to the Internet router. The routes are as follows:

192.168.1.0/24 via eth0

192.168.2.0/24 via eth1

Default route: 0.0.0.0/0 via eth2

These routes ensure that R3 can route traffic within the "talos.edu" network and forward traffic to the Internet when necessary.

Router R4: We add routes to R4 to reach the "talos.edu" subnets via the appropriate interfaces.

Requirement 2:

We configure the routers as follows:

R3 is set as the default gateway of the "talos.edu" network.

The Internet router is configured as the default gateway for R3 and "minerva," the router for

Delos.

We ensure that the configurations do not create routing loops by verifying the logical path of traffic.

We also perform testing to confirm that hosts within "talos.edu" can communicate through an optimal path and that default gateways are correctly set using tools like ping and traceroute.

Task B: DHCP SERVER

Configuring DHCP Server on Node Minerva:

To efficiently manage IP address distribution within your network, it`s essential to set up a DHCP (Dynamic Host Configuration Protocol) server. This server allows clients to dynamically request and obtain various network settings, including IP addresses, subnet masks, gateway details, DNS server addresses, and other network parameters.

The first step is to install and configure DHCP server software like ISC DHCP or DHCPd on Node Minerva. With this software, you can specify IP address ranges, subnet configurations, lease durations, and designate the network interfaces to monitor for incoming DHCP requests.

Customizing DHCP Settings:

In the configuration files, such as dhcpd.conf for ISC DHCP, you can define DHCP pools, lease durations, and specific client settings. Each pool can be tailored to meet the unique needs of different client groups. You can customize the IP address range, default gateway, DNS server addresses, and domain names for each pool. Adapting these parameters to your network`s requirements is crucial.

Assigning Static IP Addresses:

While DHCP typically provides dynamic IP addresses to clients, there are instances when you need to assign specific devices static IP addresses. For example, it`s advisable to assign constant IP addresses to servers and critical network devices that provide essential services such as DNS, HTTP, or SMTP.

To achieve this, you`ll need to set up DHCP reservations in your DHCP server`s settings. These reservations link a client`s MAC address to a specific IP address, ensuring that the client consistently obtains the same IP address during DHCP lease renewal.

Customized DHCP Configurations for Different Services:

To optimize network performance, the DHCP server should be configured to meet the diverse needs of clients. For instance:

DNS-Only Configuration: Configure the DHCP server to provide DNS server IP addresses to clients requiring DNS services, enabling them to resolve domain names efficiently.

HTTP-Only Configuration: Customize the DHCP server to provide the necessary gateway and DNS server settings for clients who require web access.

Email Configuration: For clients relying on email services (SMTP), configure the DHCP server to offer the essential gateway and DNS server addresses to facilitate email communication.

Task C: Firewall

Configuring Firewall on Node R3:

Effective network traffic management and protection against security threats and unauthorized access demand the proper configuration of a firewall. In this task, we will outline the prerequisites for setting up the firewall on Node R3.

Allowing Traffic to DMZ Addresses from Anywhere:

To enable traffic from external sources to reach DMZ addresses, it is essential to create firewall rules that allow inbound connections to specific ports on DMZ servers. These rules should clearly define which services can be accessed from external sources.

For example, if a web server is hosted in the DMZ, a rule should be set to permit inbound traffic on port 80 (HTTP). Similarly, if there`s an email server in the DMZ, a rule should be established for SMTP traffic on port 25. These rules govern the flow of traffic into the DMZ from external sources.

Enabling DHCP Client Service on Delos Clients:

To obtain dynamic IP address configurations from Node Minerva`s DHCP server, Delos network clients must have the DHCP client service activated. This service operates on client devices, allowing them to request and receive IP address configurations from the DHCP server.

This setup is crucial for clients to seamlessly connect to the network and automatically receive the necessary network settings.

Enabling DMZ Servers to Initiate Communication:

Outbound firewall rules need to be set up for DMZ servers to initiate communication in response to client requests. These rules grant DMZ servers the ability to respond to requests from clients.

For instance, the firewall should accept outbound traffic from the DMZ to the internal network when a client in the internal network initiates a connection to a web server in the DMZ.

Facilitating Access to DMZ Servers for Internal Hosts:

To ensure smooth communication between internal and DMZ networks, specific rules must be established to allow internal hosts to access DMZ servers. These rules should specify the services and permitted ports.

Create rules that permit traffic on corresponding ports (e.g., 53 for DNS, 80 for HTTP, and 25 for SMTP) from the internal network to the DMZ if internal hosts require access to DMZ`s DNS, web, and SMTP servers.

Regulating Internal Host Communication:

Generally, internal hosts within the same network segment should be able to communicate with each other without restrictions. Typically, this internal-to-internal traffic doesn`t require firewall rules.

Allowing Internal Nodes to Connect to External Servers:

Configuring NAT (Network Address Translation) and stateful inspection rules is essential to enable internal nodes to connect to external servers. Stateful inspection keeps track of connection states, permitting only valid responses from external servers, while NAT allows internal nodes to use a shared external IP address for outbound connections.

This setup enhances security by ensuring that outbound connections are initiated, and only relevant incoming responses are allowed.

Providing SSH Access to Node R3:

To configure SSH (Secure Shell) access to Node R3, it is necessary to establish firewall rules that permit SSH communication, often on port 22, from the designated client subnet. These rules should authorize SSH access to Node R3 for network monitoring and administration.

To further enhance security, consider implementing secure authentication methods such as SSH key pairs or strong passwords.