Part Three
Forward Proxies
A proxy is an important part of security. It serves as a checkpoint, either in front of a group of web servers or as a single server that manages all outgoing traffic.
A proxy can improve performance and provides a key security advantage by centralizing inspection and control. When set up right, forward proxies can effectively monitor attacks and C2 traffic, enhancing security for the organization.
Secure Web Gateway (SWG) Functionality
SWGs are cloud-based proxies that filter content. They provide this service in a way that fits the needs of today's flexible workforces and different applications.
Some vendors say their products are more than proxies, while others accept the proxy label. For instance, Cisco calls its SWG product a "cloud-native full proxy."
On-Premises Proxies or Cloud-Hosted Secure Web Gateways
An internet access choke point can improve security. Companies used to use special forward proxies for this, but now many use their Next-Generation Firewalls (NGFWs) to filter and inspect internet traffic.
Secure Web Gateways (SWGs) help improve protection and detection for employee internet use.
Web Content Filters
A forward proxy often includes web content filtering, though it's not necessary. Web filtering can also be a standalone device and is available in Unified Threat Management (UTM) and Next-Generation Firewall (NGFW) devices.
We’ll mainly look at how web content filtering helps with cyber defense, but it also helps with HR and productivity. Its main aim is to reduce the risk of users accessing unsafe content and to improve the detection of compromised devices.
Blocking Billions
A web content filter mainly helps by blocking harmful websites and content. It also prevents access to adult material and hate speech to keep the workplace safe.
Sounds good, but how do we do it? New sites pop up daily. Can we really sort them all? Not quickly—it’ll need regular updates. Also, how easy is it for someone to bypass a blocklist? It's pretty easy.
MIME/Content-Type Blocking/Alerting
Another way to filter web content is by blocking access based on MIME or Content-Type, which indicates the type of file being downloaded via HTTP. This approach originated from SMTP, which allowed sending various types of content, not just plain text.
Proxies can check these headers to find content that needs closer examination in an automated analysis tool or that should be blocked outright.
MIME/Content-Type Illustrated
The screenshot shows Wget being used to download a file and view its headers. The Content-Type header says it's an application/pdf, which matches the file name roadmap.pdf. There are many lists of MIME/Content-Types, but some only include official IANA types, not all commonly used ones.
Network Intrusion Detection Systems
Many organizations rely on Network Intrusion Detection Systems (NIDS) for detection, but many are replacing them with Network Intrusion Prevention Systems (NIPS) or Next-Generation Firewalls (NGFW).
Prevention devices are very different from detection devices, even if they use the same hardware. The difference lies in how they are set up, which changes their purpose.
Perimeter NIDS Placement
Perimeter NIDS often monitors traffic at DMZ and server choke points. It watches data between the firewall and DMZ to protect from both external and internal threats.
Place a monitoring sensor where the firewall connects to the internal network. It helps protect the internal network from outside threats, similar to a DMZ sensor.
Umbrella Sensor
The "umbrella sensor" is often the only one used, but it tries to do too much and becomes ineffective. Cheaper switches with mirror ports make it better to add focused sensors on key networks.
NSM Sensor Placement
Many organizations have a single "umbrella" NIDS/NSM sensor. This is better than nothing, but often suboptimal, as we will learn next.
NIDS Sensor Placement
NIDS Sensor Placement:
This is called an umbrella sensor and works better with more sensors.
This DMZ sensor works well because DMZ networks are small and well-organized.
This is a focused sensor, protecting the general server LAN.
This sensor protects the sensitive internal network, like a credit card processing system.
This is an external sensor for detecting attacks and data leaks.
This is a sensor for client networks, where most companies lack visibility. It's recommended to place one on your most important network, like the one used by top executives.
(In)visibility Analysis: IDS and Trust
Many organizations overlook improper IDS setups. For example, if an IDS monitors internal traffic, it often relies on defining trusted (HOME_NET) and untrusted (EXTERNAL_NET) segments. Most IDS rules focus on threats from the untrusted side.
The image shows how hard it is to spot an internal attack. A compromised host (10.5.11.11) is targeting another device on the same network (10.5.11.22). An IDS can see this traffic but ignores it because it’s from one trusted area to another (from $HOME_NET to $HOME_NET). The slide uses the Snort Pig to represent the IDS, which we will learn about in class.
NIDS and Prevention
The NIDS can't directly prevent attacks, but it can help us improve prevention by showing us threats. When set up correctly, it can quickly detect issues, which aids in our response efforts.
Network Intrusion Prevention Systems
NIDS and NIPS have similar names and can use the same hardware, but they are actually different from each other.
NIDS and IPS are very different mainly due to how they are set up. A false positive in a NIDS is just a minor issue, but in an IPS, it can lead to service outages. Therefore, an IPS needs to be configured to avoid false positives completely.
NIPS -> NGFW
In 2003, Gartner said, “We think IDS is dead,” meaning most IDS systems weren’t useful back then. To be helpful, an IDS needs someone skilled to monitor it, while an IPS can work effectively without constant oversight.
IPS are more similar to firewalls (FW) than to intrusion detection systems (IDS). I'm not saying IPS is obsolete or that you should stop using it, but many are shifting from pure IPS to next-generation firewalls (NGFW). For instance, Sourcefire and TippingPoint, known for their next-gen IPS, also provide NGFW using similar technology.
L7 and Next-Generation Firewall
Firewalls, once basic tools for network security, have evolved recently. We've discussed Stateful Inspection (SI) firewalls, and now it's time to look at a newer type called Next-Generation Firewalls (NGFW).
When I first heard about NGFW, I thought it was just a marketing trick. While it is a type of firewall, NGFW uses special methods that make it better for today’s security needs. However, NGFW should work alongside, not replace, standard firewalls.
Layer 7 Firewalling
NGFWs are different from traditional firewalls mainly because they focus more on Layer 7. While earlier firewalls did use Layer 7 a bit, it was mostly for state management rather than strong firewall features beyond Layer 3/Layer 4.
NGFWs are designed with Layer 7 in focus from the start, while traditional firewalls are struggling to keep up.
Application Identification/Inspection
The main difference between SI and NGFW is that NGFW can analyze Layer 7 more deeply. It's not just about knowing the basics of HTTP, FTP, or SSH protocols; NGFWs also understand specific web applications, including custom and popular ones.
In today's world, where most things are web or mobile apps and use HTTP, it's important to do more than just basic Layer 3/Layer 4 filtering. Advanced protocol understanding is essential for security.
OpenAppId
OpenAppId is a new tool from Sourcefire/Cisco for identifying applications in IDS/IPS systems. It aims to provide an open-source way to recognize specific applications, going beyond basic recognition like "this looks like HTTP" to a deeper understanding of common web applications.
OpenAppId works with Cisco and Sourcefire, especially with Snort, the world's most popular open-source IDS. This means Snort will have a new way to recognize and understand applications.
Application Inspection and Filtering
In a situation where identifying applications is important, an attacker might use common ports like TCP/80 or TCP/443 for their IRC-based command and control (C2) instead of the usual TCP/6667, assuming the target has egress filtering. While standard network security might let this traffic through as normal, a next-generation firewall (NGFW) could recognize it as IRC and block it.
User Visibility and Reputation
NGFWs offer better user tracking and connect with reputation services, unlike traditional firewalls.
In the past, traffic decisions relied on basic IP address and port info. With DHCP commonly used, managing access for specific users or groups became difficult. Usually, this meant putting users in a specific VLAN for consistent IP filtering or setting a static IP for better control. Next-Generation Firewalls (NGFWs) can connect with Identity Providers like Active Directory to improve user-level control.
NGFWs often rely on reputation to make decisions. They connect to reputation services that help assess the security of other systems or networks. We'll cover reputation and threat intelligence more later.
AWS Network Firewall
To use the Network Firewall in a VPC, you'll need to make some changes. First, create a new subnet for the firewall endpoint since it can't filter its own subnet. Then, update the route tables for other subnets to direct their traffic to this new subnet.
The stateful engine uses rules that work with Suricata, an open-source intrusion prevention system. Suricata has a standard way to inspect network traffic using rules. The AWS Network Firewall logs also use Suricata's effective JSON EVE log format.
Only traffic processed by the stateful engine can create flow or alert logs. Alert logs are made only for traffic that triggers ALERT or DROP actions. Delivery times are about 3-6 minutes for CloudWatch Logs and Kinesis Data Firehose, and 8-12 minutes for S3.
AWS Network Firewall: ATT&CK Coverage
The photo shows part of the MITRE Engenuity CTID project, focusing on how AWS security controls map to MITRE ATT&CK. It lists the 14 main tactics from MITRE ATT&CK and highlights the techniques that are relevant to AWS security controls.
AWS Firewall Manager
AWS has many security services, each with its own management interface. While you can manage them individually, a centralized view is more efficient and secure. AWS Firewall Manager gives you this central control, allowing you to oversee and manage these services across different AWS accounts.
Amazon suggests the following about AWS Firewall Manager:
AWS Firewall Manager is a service that helps you set and manage firewall rules across all your AWS accounts and apps. It ensures new applications meet security standards by applying the same rules consistently. This allows you to create and enforce security policies from one central account for your entire infrastructure.
Azure Firewall(s)
Microsoft provides firewall options for Azure, including Standard, Premium, and Basic. All are L3-7 firewalls, but the L7 features vary significantly between versions.
Azure Firewall Basic is a cheaper version of Azure Firewall Standard, designed for small to medium businesses. It supports only two VM instances, limiting scalability. While it includes Microsoft Threat Intelligence, it only provides alerts for matching traffic and does not block it.
There are some known issues with Azure Firewalls. Check these issues in the Microsoft Learn documentation before relying on Azure Firewall to avoid disrupting services or harming security. You can find the issues listed here: Microsoft Learn.
Azure Firewall Standard
The standard Azure Firewall mainly provides stateful inspection for network traffic, focusing on basic filtering by source/destination IP addresses and ports. It can also filter based on fully qualified domain names (FQDNs). The firewall resolves these FQDNs using its DNS service to convert them into IP addresses for blocking at layers 3 and 4.
The Firewall Standard can filter or alert on suspicious IPs and domains using Microsoft Threat Intelligence. It identifies targeted domains in TLS traffic by using TLS Server Name Indication (SNI) without needing TLS inspection, which the Firewall does not support.
Azure Firewall Premium
TLS inspection in Azure Firewall Premium only applies to traffic from internal assets to the internet and between Azure and on-premises environments. It does not cover traffic coming into Azure-hosted applications or services, which requires Azure's Web Application Firewall on the Application Gateway. This limitation is similar to what you'd see with an on-premises forward proxy, so it's not surprising, but it's important to note when considering Firewall Premium.
The L7 security features include built-in intrusion detection and prevention (IDPS) capabilities. Firewall Premium has over 50,000 signatures in more than 50 categories. The IDPS can run in Alert mode, which only detects issues, or Alert and Deny mode, which can block some traffic. If the firewall inspects TLS, the IDPS will analyze the decrypted traffic.
Azure Firewall: ATT&CK Coverage
The photo shows part of the MITRE Engenuity CTID project, focusing on how Azure security controls map to the MITRE ATT&CK framework. It lists 14 key tactics used by attackers and highlights relevant techniques related to Azure security.
Lab 2.3 - Detecting Adversaries with Protocol Inspection
Objectives:
Gain experience with Suricata and application layer protocols.
Become familiar with Suricata's eve.json output.
Detect adversary activity over nonconforming protocols.
Parse JSON data at the command line with jq.
Understand and create simple Suricata rules.
Challenges:
Create a Suricata rule to detect non-TLS traffic sent over TCP port 443. Rule should be added to /labs/suricata/rules/local.rules
Run Suricata against /labs/suricata/protocol_anomaly.pcap using the supplied configuration file /labs/suricata/suricata.yaml
How many alerts were generated for non-TLS traffic over port 443?
TLS traffic was detected on 3 ports besides 443. Identify the three ports.
HTTP traffic with a user-agent of test sent to a port other than 80. What was the port of the HTTP server.
What is the name of the PE32 executable transferred over port 80 with a Content-Type of "text/plain"?
Let's create a Suricata rule to detect non-TLS traffic sent over TCP port 443. Rule should be added to /labs/suricata/rules/ local.rules
Let's open /labs/suricata/rules/local.rules in a text editor such as code.
Now, let's add the following rule to the local.rules file:
Explanation of the Suricata Rule:
This Suricata rule is designed to detect and alert when there is non-TLS traffic on TCP port 443, which is typically expected to carry TLS-encrypted traffic (i.e., HTTPS). Let’s break down the different components:
1. Alert Action
alert: This is the action that Suricata will take when this rule is matched. It will generate an alert in the logs when the specified traffic pattern is detected.
2. Protocol (TCP)
tcp: This rule applies to TCP traffic. Port 443 is normally associated with HTTPS, which uses the TCP protocol.
3. Source and Destination
any any -> any 443: This part defines the traffic direction:any any: The source address (any) and port (any) mean that it applies to traffic from any IP address and any source port.->: This arrow indicates the direction of the traffic (from source to destination).any 443: The destination IP (any) means that it applies to traffic going to any destination IP, but specifically port 443 (which is typically used for HTTPS).
4. Message
msg:"SURICATA Port 443 but not TLS": This is the message that will be logged when this rule is triggered. It indicates that there is traffic going to port 443 but it is not using TLS.
5. Flow
flow:to_server: This specifies that the rule will only trigger for traffic that is flowing to a server. In this case, it refers to traffic going from a client to a server on port 443.
6. Application Layer Protocol
app-layer-protocol:!tls: This is the key part of the rule. It tells Suricata to inspect the application layer protocol and check whether the traffic is not TLS (!tls).If traffic on port 443 is not using TLS (which is expected for HTTPS), it is considered suspicious because port 443 is typically reserved for secure traffic. Non-TLS traffic on this port could indicate misuse or an attempt to bypass security measures (e.g., using non-encrypted HTTP over port 443).
7. SID and Revision
sid:1234567: This is the unique identifier (Signature ID) for this rule, which helps to track and reference it.rev:1: This indicates the revision number of the rule. The rule is currently on its first version (rev:1).
Purpose of the Rule:
Detection of Anomalous Traffic: Port 443 is generally used for HTTPS traffic, which is expected to be encrypted using TLS. If traffic is detected on port 443 that is not TLS-encrypted, it might indicate an attempt to bypass encryption or that some other protocol is being used improperly on this port.
Security Concern: Detecting non-TLS traffic on port 443 is important because attackers could be using this port to disguise malicious or unencrypted traffic, assuming it will go unnoticed on a port typically associated with secure traffic.
Then we'll save the updated local.rules file.
Now, let's run Suricata on /labs/suricata/protocol_anomaly.pcap using /etc/suricata/suricata.yaml.
Q3) How many alerts were generated for non-TLS traffic over port 443?
Let's break down this command:
cat /labs/suricata/logs/eve.json:Reads the contents of the
eve.jsonfile (Suricata's log file) from the specified directory.
| jq 'select(.event_type == "alert") | .':Pipes the content of the file to
jq, a tool for processing JSON.It selects and filters only the entries where the field
"event_type"is equal to"alert"(i.e., it filters for alert events in the logs).
-c:Compresses the output into a single line per JSON object.
| wc -l:Counts the number of lines (i.e., the number of alerts) and outputs the total count
Answer: 15
Q4) TLS traffic was detected on 3 ports besides 443. Identify the three ports.
Answer: 447, 9001, 9003
Q6) HTTP traffic with a user-agent of test sent to a port other than 80. What was the port of the HTTP server.
Answer: 8082
Q7) What is the name of the PE32 executable transferred over port 80 with a Content-Type of "text/plain"?
Answer: /korestros.ri
Last updated
