TryHackMe-Secure Network Architecture

Learn about and implement security best practices for network environments.

Make every campaign better than the last with GetResponse Email Marketing + Landing Pages + Marketing Automation — $49 only

GetResponse | Professional Email Marketing for Everyone

↓↓↓ Click here and earn $5 TryHackMe credit ↓↓↓

TryHackMe | Cyber Security Training

Task 1 Introduction

Networking is one of the most critical components of a corporate environment but can often be overlooked from a security standpoint. A properly designed network permits not only internet usage and device communication but also redundancy, optimization, and security.

Learning Objectives

1. Understand the principles of secure network architecture design
2. Learn and implement common network security concepts and protocols
3. Understand a network’s environment and potential threats

No Answer Nedded

Task 2 Network Segmentation

In this example, we will use the open-source switch: Open vSwitch

Analyzing a VLAN Configuration

Apply what you learned to analyze a VLAN configuration given the output below.

/ # ovs-vsctl show
87c2a3ee-5374-435a-81c2-e8aafa96e3b9
    Bridge br2
        datapath_type: netdev
        Port br2
            Interface br2
                type: internal
    Bridge br1
        datapath_type: netdev
        Port br1
            Interface br1
                type: internal
    Bridge br0
        datapath_type: netdev
        Port eth9
            tag: 30
            Interface eth9
        Port br0
            Interface br0
                type: internal
        Port eth13
            tag: 30
            Interface eth13
        Port eth14
            tag: 30
            Interface eth14
        Port eth15
            tag: 30
            Interface eth15
        Port eth2
            tag: 10
            Interface eth2
        Port eth8
            tag: 30
            Interface eth8
        Port eth3
            tag: 20
            Interface eth3
        Port eth7
            tag: 30
            Interface eth7
        Port eth4
            tag: 20
            Interface eth4
        Port eth10
            tag: 30
            Interface eth10
        Port eth5
            tag: 20
            Interface eth5
        Port eth6
            tag: 30
            Interface eth6
        Port eth12
            tag: 30
            Interface eth12
        Port eth0
            Interface eth0
        Port eth11
            tag: 30
            Interface eth11
        Port eth1
            tag: 10
            Interface eth1
    Bridge br3
        datapath_type: netdev
        Port br3
            Interface br3
                type: internal

Q: How many trunks are present in this configuration?

Ans: 4

Q: What is the VLAN tag ID for interface eth12?

Ans: 30

Task 3 Common Secure Network Architecture

Q: From the above table, what zone would a user connecting to a public web server be in?

Ans: External

Q: From the above table, what zone would a public web server be in?

Ans: DMZ

Q: From the above table, what zone would a core domain controller be placed in?

Ans: Restricted

Task 4 Network Security Policies and Controls

Analyzing Packets and ACLs

Now that we understand the structure of an ACL and what it will look for in a packet, let’s analyze a few packets and ACL policies to determine if they will be accepted or dropped.

Below is each packet and ACL policy required; answer the questions using the resources below.

Packet #1

Internet Protocol Version 4, Src: 10.10.212.209, Dst: 10.10.212.209
    Protocol:TCP (6)
    Header checksum: 0xbfdd [validation disabled]
    [Header checksum status: Unverified]
    Source: 10.10.212.209
    Destination: 10.10.212.209
Transmission Control Protocol, Src Port: 35560, Dst Port: 22, Seq: 1578, Ack: 1670, Len: 148
    Source Port: 35560
    Destination Port: 22

ACL Policy #1

set policy access-list 1 rule 1 action permit

set policy access-list 1 rule 1 source 255.255.255.0

set policy access-list 1 rule 1 source 10.10.212.0/24

Packet #2

Internet Protocol Version 4, Src: 10.10.212.200, Dst: 10.10.212.209
    Protocol:TCP (6)
    Header checksum: 0xbfdd [validation disabled]
    [Header checksum status: Unverified]
    Source: 10.10.212.209
    Destination: 10.10.212.209
Transmission Control Protocol, Src Port: 35560, Dst Port: 22, Seq: 1578, Ack: 1670, Len: 148
    Source Port: 35560
    Destination Port: 2

ACL Policy #2

set policy access-list 1 rule 1 action deny

set policy access-list 1 rule 1 destination 10.10.212.209

Q: According to the corresponding ACL policy, will the first packet result in a drop or accept?

Ans: accept

Q: According to the corresponding ACL policy, will the second packet result in a drop or accept?

Ans: drop

Task 5 Zone-Pair Policies and Filtering

This gives us a good understanding of the expected behavior of our network and a good plan to begin configuring the firewall.

Remember: Not all traffic is IPv4! Depending on your network configuration, you may also need to configure IPv6 rules!

Because of the default action that we set, any protocols that originate on the network and are not defined will be dropped by default.

We will not go over each ruleset and zone-pair; instead, we will cover one zone-pair in each direction and test that the behavior works as expected. In this example, we will configure the LAN and WAN zone-pairs. After the example, you’ll feel confident configuring a small amount of the zone-pairs on your own.

For all VyOS firewall rulesets, we must begin by defining the default action and state rules. We will not cover the intricacies of this configuration as it is not the aim of this room. Rather than repeating seven commands to create each rule, we will rely on the VyOS configuration to define each rule. Below is an example of the base VyOS ruleset. This should be the same at the top of each ruleset you create.

name lan-wan {
  default-action drop
  enable-default-log
  rule 1 {
    action accept
    state {
      established enable
      related enable
    }
  }
  rule 2 {
    action drop
    log enable
    state {
      invalid enable
    }
  }
}

Now let’s add the rule for ICMP.

rule 100 {
    action drop # Define the action for the rule
    log enable # Enable logging to track connection attempts in VyOS
    protocol ipv4-icmp # Protocol to monitor and enforce the action on
 }

Now that we have our first zone-pair ruleset, let’s create the rules for the opposite zone-pair direction: WAN → LAN. Below is the ruleset required to allow ICMP traffic.

 default-action drop
  enable-default-log
  rule 1 {
    action accept
    state {
      established enable
      related enable
    }
  }
  rule 2 {
    action drop
    log enable
    state {
      invalid enable
    }
  }
 rule 100 {
    action accept
    log enable
    protocol ipv4-icmp
 }
}

he zone-pair is now defined with appropriate actions and states. We can now combine the firewall ruleset with a previously configured zone.

Recall: At the beginning of this task, we configured zone policies with a corresponding interface and common name.

Below is the generic syntax for adding a zone-pair.

set zone-policy zone <zone A> from <zone B> firewall <name> <ruleset name>

Below we will set the zone-pair for both the LAN → WAN and WAN → LAN pairs.

    set zone-policy zone LAN from WAN firewall name lan-wan
    set zone-policy zone WAN from LAN firewall name wan-lan

What is the flag found after filling in all blanks on the static site?

Ans: THM{M05tly_53cure}

Task 6 Validating Network Traffic

Q: Does SSL inspection require a man-in-the-middle proxy? (Y/N)

Ans: Y

Q: What platform processes data sent from an SSL proxy?

Ans: Unified Threat Management

Task 7 Addressing Common Attacks

Q: Where does DHCP snooping store leased IP addresses from untrusted hosts?

Ans: DHCP Binding Database

Q: Will a switch drop or accept a DHCPRELEASE packet?

Ans: Drop

Q: Does dynamic ARP inspection use the DHCP binding database? (Y/N)

Ans: Y

Q: Dynamic ARP inspection will match an IP address and what other packet detail?

Ans: MAC Address

Task 8 Conclusion