Secure Architecture

• The Need for Secure Segmentation

  • Subnets seem to solve all problems a network may face; why would we use another solution? let’s consider a scenario where a client brings in their own device, a common practice known as BYOD (Bring Your Own Device). The client’s device was infected with a Remote Access Trojan (RAT) that will attempt to traverse the network the device is connected to and exfiltrate any sensitive information. With subnetting in place, there is no restriction in place, so the we should use VLANs as well
• VLANs (Virtual LAN) are used to segment portions of a network at layer two and differentiate devices. 

  • VLANs are configured on a switch by adding a "tag" to a frame. The 802.1q or dot1q tag will designate the VLAN that the traffic originated from.

  
• VLANS:

  • The 802.1 tag provides a standard between vendors that will always define the VLAN of a frame. For example, if our switches are Cisco and our routers are Juniper, they can send tagged frames and digest them equally because it is standardized. 
• Tagging Unknown Traffic

  • The Native VLAN is used for any traffic that is not tagged and passes through a switch. To configure a native VLAN, we must determine what interface and tag to assign them, then set the interface as the default native VLAN. Below is an example of adding a native VLAN in Open vSwitch.

  $ ovs-vsctl set port eth0 tag=10 vlan_mode=native-untagged

  • Now all traffic should be tagged, even with unknown origins.
• Routing Between VLANs

  • But how does a VLAN connect to the internet or access resources in other VLANS? Since they are segmented, they cannot communicate outside their tagged devices. Just as routers are used to communicate between traditional networks, routers can be used to route between VLANs.
• Routing Between VLANs

  • Before modern solutions were introduced, network engineers would physically connect a switch and router separately for each VLAN present. Nowadays, that problem is solved through the ROAS (Router on a Stick) design. VLANs are configured to communicate with a router through a designated interface of a switch, known as a switch port. The connection between the switch and router is known as a trunk. VLANs are routed through the switch port, requiring only one trunk/connection between the switch and router, hence, "on a stick."
• • Routing Between VLANsBefore configuring the router, we must configure a trunk on a pre-existing connection. In our demonstration lab environment, trunks are configured by default as bridges. Each vendor configures their trunks and switch ports differently, some even with propriety protocols; please refer to their specific documentation.
• Routing between VLANs

  • Because all tagged traffic comes from a single connection, the router must be able to keep each tagged frame separate. This is accomplished using virtual sub-interfaces; these will act similar to physical interfaces and are commonly defined by the VLAN ID; the syntax for sub-interfaces is commonly,
  • If all went well and was appropriately configured, we should be able to route traffic between VLANs while keeping traffic tagged and isolated!
• Routing Between VLANS:

  • But are they really isolated? Physically, they are isolated, but because routes exist between them, there is no security boundary, and they are not necessarily isolated. As long as a route exists between two VLANs, any device can communicate between the two.
• With the introduction of VLANs, there is a shift in network architecture design to include security as a key consideration. Security, optimization, and redundancy should all be considered when designing a network, ideally without compromising one component.

  • This brings us to the question, how do we properly implement VLANs as a security boundary? Security zones! Security zones define what or who is in a VLAN and how traffic can travel in and out.
• Security Zones:

  • External: All devices and entities outside of our network or asset control.Example: Devices connecting to a web server
  • DMZ (demilitarized zone): Separates untrusted networks or devices from internal resources. Example: BYOD, remote users/guests, public servers
  • Trusted: Internal networks or devices. A device may be placed in the trusted zone if there is no confidential or sensitive information.  Example: Workstations, B2B
• Security Zones:

  • Restricted: Any high-risk servers or databases. Example: Domain controllers, client information
  • Management: Any devices or services dedicated to network or other device management. This zone is less commonly seen and can be grouped with the audit zone. Example: Virtualization management, backup servers
  • Audit: Any devices or services dedicated to security or monitoring. This zone is less commonly seen and can be grouped with management. Example: SIEM, telemetry
• • While security zones mostly factor in what will happen internally, it is equally important to consider how new traffic or devices will enter the network, be assigned, and interact with internal systems. Most external traffic (HTTP, mail, etc.) will stay in the DMZ, but what if a remote user needs access to an internal resource? We can easily create rules for resources a user or device can access based on MAC, IP addresses, etc. We can then enforce these rules from network security controls
• Topology of Security Zones

  • Security zones and access controls will physically direct how and where traffic goes. But how is it decided what resources users or devices have access to? Traffic rules are often governed by company security policy or compliance as equally as security controls that determine access permissions. 

  
• Policies aid in defining how network traffic is controlled. A network traffic policy may determine how and if a router will route traffic before other routing protocols are employed. IEEE (Institute of Electrical and Electronics Engineers) has standardized a handful of access control and traffic policies, such as QoS (Quality of Service) (802.11e). There are still many other routing and traffic policies that are not standardized by IEEE but are commonly used by all vendors following the same objectives.
• • Traffic FilteringOne of the most common standards of defining traffic filtering: ACL(s) (Access Control List(s)).
  • An ACL is used as a loose standard to create a ruleset for different implementations and access control protocols.
  • An ACL contains ACE(s) (Access Control Entry) or rules that define a list’s profile based on pre-defined criteria (source address, destination address, etc.)
• Traffic Filtering

  • Formally, traffic filtering provides network security, validation, and segmentation by filtering network traffic based on pre-defined criteria.
  • The VyOS access-list policy is the platform’s most basic implementation of filtering. The policy will use ACLs or prefix lists to define the criteria for filtering.
  • Create the new access-list policy, defining the ACL number (1 - 2699)
  • set policy access-list <acl_number>
• Let’s recap, the ACL is defined as an ACL number and is made of separate rules or ACEs that describe the behavior of the ACL. Each ACE can determine the action, destination/source, and the specific address/range to trigger the ACE.
• Below is a diagram showing a valid SSH request permitted by the ACL.

  
• Firewalls

  • At the highest level, basic network firewalls are defined in two categories: stateless vs. stateful. A protocol's category is determined based on its ability to consider the state of a packet. For example, the ACLs used in the previous task would be regarded as a stateless protocol.
  • A stateful firewall can better correlate information in a network connection. This allows the firewall to filter based on protocols, ports, processes, or other information from a device, etc.
• Before configuring a firewall, we need to consider how we can apply the requirements of zones to firewall rules. How can we define different actions based on the protocol and source/destination zone? Zone-pairs!
• Zone-Pairs

  • Zone-pairs are a direction-based and stateful policy that will enforce the traffic in single directions per each VLAN, hence, zone-pair. For example, DMZ → LAN or LAN → DMZ.
  • Each zone in a given topology must have a different zone-pair for each other in the topology and every possible direction. This approach provides the most visibility from a firewall and drastically improves the filtering capabilities.
• Below is an example of setting a default action for the DMZ and assigning the VLAN to the common zone name.

  1. set zone-policy zone dmz default-action drop
  2. set zone-policy zone dmz interface eth0.30

  Repeat this process for each VLAN interface or zone defined in a network.
• Each zone will have a corresponding pair to every other zone. To define each zone-pair, we will write down each possible pair and protocols or actions that we may apply to the zone-pair.

  • Below is an example table of each zone-pair in the above topology and what possible protocols/actions may look like.

  
• A zone pair has a source security zone and a destination security zone. The device examines received first data packets and uses zone pairs to identify data flows. You can use the zone-pair security source any destination any command to define the any-to-any zone pair.
• Zone pairs are used to implement policies. Policies specify what transit traffic is allowed to be initiated and what action the firewall should take. For example, a policy can specify that traffic from users on the inside can be destined to resources on the outside. Here are some rules about interfaces when implementing a zone-based policy firewall: 

  • If both interfaces belong to the same zone-pair and a policy exists, all traffic will be passed.
  • If both interfaces are members of the same zone, all traffic will be passed.

  By default, no traffic is allowed between two different zones.
• Zone-Pairs: Eg VyOS Ruleset

  
• • Lets say a zone-pair between the DMZ and LAN allows an HTTPS connection. Of course, the firewall should accept these connections
  • In this scenario, let’s say there is a threat actor that has landed an implant through phishing on a LAN machine. Assuming host defense mechanisms have failed, how can the implant be detected and monitored? If their beacon is using HTTPS through the DMZ. That will look like primarily legitimate traffic to your firewall and analysts.
  • To solve this issue, we must use SSL/TLS inspection to intercept HTTPS connections.
• SL/TLS Inspection

  • SSL/TLS inspection uses an SSL proxy to intercept protocols, including HTTP, POP3, SMTP, or other SSL/TLS encrypted traffic. Once intercepted, the proxy will decrypt the traffic and send it to be processed by a UTM (Unified Threat Management) platform. UTM solutions will employ deep SSL inspection, feeding the decrypted traffic from the proxy into other UTM services, including but not limited to web filters or IPS (Intrusion Prevention System), to process the information.
• SSL/TLS Inspection:

  • This solution may seem ideal, but what are the downsides? Some of you may have already noted that this requires an SSL proxy or MitM (Man-in-the-Middle). Even if a firewall or vendor has already implemented the solution, it will still act as a MiTM between your devices and the outside world; what if it intercepts potentially plain-text passwords? A corporation must assess the pros and cons of this solution, dependent on its calculated risk. You could allow all applications that you know are safer to prevent potential cons, but this solution will still have disadvantages.
• DHCP Snooping

  • Cisco defines DHCP snooping as "a security feature that acts like a firewall between untrusted hosts and trusted DHCP servers."
  • DHCP snooping was introduced to combat rogue DHCP servers; it will validate and rate-limit DHCP traffic as necessary. If a host is untrusted, its traffic will be filtered and rate-limited.
• DHCP Snooping

  • Although DHCP is a layer three protocol, DHCP snooping operates on the switch at layer two. The switch will store untrusted hosts with leased IP addresses in a DHCP Binding Database. The database is used to validate traffic and can be used by other protocols, such as dynamic ARP inspection, which we will cover later in this task.
• We know how DHCP snooping will gather and store addresses, but how does it determine what to do with traffic? Below is a list of conditions the protocol will inspect to determine if a DHCP packet should be dropped.

  • Any DHCP packet is received from outside of the network.
  • The source MAC address and DHCP client hardware address do not match.
  • A DHCPRELEASE or DHCPDECLINE packet is received on an untrusted interface that does not match an interface that the source address already has registered.
  • A DHCP packet that includes a relay agent address that is not 0.0.0.0
• Dynamic ARP Inspection

  • Cisco defines ARP inspection as "a security feature that validates Address Resolution Protocol (ARP) packets in a network."
  • ARP inspection will validate and rate-limit ARP packets as necessary; if an ARP packet's MAC and IP address do not match, the protocol will intercept, log, and discard the packet.
  • ARP inspection uses the DHCP binding database filled from DHCP snooping as its list of binding IP addresses.
• Let's recap; the DHCP binding database provides the expected MAC and IP address pair of untrusted hosts; ARP inspection will compare the source IP address and MAC address to the binding pair; if they are mismatched, it will drop the packet.
• Below is a diagram showing a valid ARP request that matches both the binding database and request information.