These full days, protecting the network perimeter is really a foregone conclusion. However, there’s longer a monolithic perimeter-there tend to be multiple perimeters to safeguard no. Unauthorized attempts to cross perimeters are frequent, and the necessity to defend against threats is crucial to safeguard your assets.

In virtually any perimeter defense an essential component is firewalls-the proverbial guard towers in your fortifications. They’re in charge of controlling and inspecting the traffic getting into chiefly, and moving away from, the network. And when they encounter unauthorized threats or traffic, the network is protected by them.

In this Threat Trends release, we’ll be considering Cisco Secure Firewall .  Specifically, we’ll be discussing its Secure IPS component and the Snort rules it utilizes, examining what’s encountered and blocked regularly.

To get this done, we’ll look at Snort telemetry via Secure Firewalls, examine probably the most encountered rules frequently, rule categories, and examine these rules through the lens of the MITRE ATT&CK framework. The target is to highlight the normal threats that organizations encounter and block with Secure Firewall.

Snort and detection policies

Before diving in to the telemetry, let’s briefly cover how Snort rules are employed within Secure Firewall. (An in depth explanation of Snort rules are available in the Snort FAQ .)

Secure Firewall version 7.0 supports Snort 3 because the default inspection engine. Snort 3 provides better scalability and performance than its predecessor, Snort 2, using less memory and supporting more intrusion rules and a more substantial network map.

Snort is configurable highly, offering thousands of rules to detect various kinds of activity. However, simply enabling all of them isn’t recommended-doing so wouldn’t normally only bring about an unmanageable tsunami of alerts but could drastically impact network performance.

To create managing rulesets easier, Snort rules are organized into policies. You can find four base policies open to help with initial operation and configuration, though you can make your own also. The four base policies are:

1. 1. Connectivity over Security

1. 1. Balanced

1. 1. Security over Connectivity

1. 1. Maximum Detection

These policies add additional rulesets because they reduction in permissiveness. The “Connectivity over Security” policy is roofed in “Balanced” alongside additional rulesets. “Connectivity over Security” and “Balanced” rules come in turn contained in “Security over Connectivity,” along with further rulesets, etc.

Which policy you select depends on the surroundings you’re protecting. Cisco recommends utilizing the Balanced policy generally in most environments to get the very best combination of security with the cheapest amount of false positive alerts. However, you might like to think about the other policies, depending on where in fact the firewall is deployed. (Secure Firewall even provides automated recommendations to tune your ruleset to your environment, reducing false-positives and increasing network performance.)

The ultimate policy, Maximum Detection, is made for testing environments mainly, since it can result in a high amount of false positive alerts. We usually do not advise that customers enable this policy because of this.

Finally, you can find rules that not participate in any policies.  These rules could be put into custom policies, being tailored for specific situations, and will be located by looking for product names, CVEs, or other keywords.

Methodology

The purpose of this analysis would be to showcase the normal threats that organizations encountered and blocked with Secure Firewall between April-September 2021 (Q2-Q3 2021). To get this done, we’ve examined product telemetry that organizations have distributed to us on an opt-in basis, which includes been aggregated and anonymized before undertaking the analysis.

The Snort rules we’re considering will be the standard text rules and Shared Object rules , both supplied by Talos Intelligence . It’s worth noting that the usage of Snort and Secure IPS is one component utilized by Secure Firewall to detect threats. You can find other protection mechanisms, such as for example Malware Defense , that may block further threats.

Since you want to see which threats organizations encounter frequently, we’re analyzing rules in policies 1-3 above described, filtering out rules from the utmost Detection policy and the ones that do not participate in any policies. Because the lion’s share of deployments utilize one of these brilliant policies, this will provide a clearer picture of what most organizations are facing, while filtering out most false positives also.

When blocking malicious activity, different attacks and rules produce different amounts of alerts, which will make comparing them difficult. For instance, alerts made by one firewall under a DDoS attack can simply dwarf the amount of alerts generated from the single exploit that hits a huge selection of organizations. Simply considering the raw numbers in cases like this would give the misconception that DDoS attacks have a lot better impact over the base of organizations.

To handle this, we’ll use distinct counts of organizations encountering rules. In case a rule triggers at a specific organization, then we once count that organization only. This not merely reduces the impact of noisy alerts in the info, but it we can show what percentage of organizations have encountered a specific rule. In essence, between April and September we are able to say that X percent of organizations encountered a specific rule.

Finally, the trends discussed show what Secure Firewall is detecting here. This might sound self-evident, but it’s vital that you note that what’s seen isn’t necessarily indicative of the bigger threat landscape. A firewall will probably see more of a specific type of attack, while an endpoint protection application shall see more of different things, as would a contact gateway.

MITRE ATT&CK

To start out, let’s look at Tactics and Techniques from the MITRE ATT&CK framework . Lots of the rules released within the last few years, in addition to older, encountered rules frequently, have already been mapped to MITRE ATT&CK. (However, as mapping is partial, the following ought to be taken as conservative estimates.)

Tactic	Percent of organizations	Techniques seen (to be able of frequency)
Initial Access [ TA0001 ]	90.9%	Exploit Public-Facing Application [ T1190 ]
		Drive-by Compromise [ T1189 ]
		Valid Accounts [ T1178 ]
		Phishing [ T1566 ]
Execution [ TA0002 ]	64.2%	Native API [ T1106 ]
		Command and Scripting Interpreter [ T1059 ]
		User Execution [ T1204 ]
		Shared Modules [ T1129 ]
		Windows Management Instrumentation [ T1047 ]
Command & Control [ TA0011 ]	48.7%	Web Service [ T1102 ]
		Dynamic Resolution [ T1568 ]
Discovery [ TA0007 ]	46.9%	File and Directory Discovery [ T1083 ]
		Application Window Discovery [ T1010 ]
		Network Service Scanning [ T1046 ]
		Remote System Discovery [ T1018 ]
		Network Sniffing [ T1040 ]
		Account Discovery [ T1087 ]
Credential Access [ TA0006 ]	64.2%	OS Credential Dumping [ T1003 ]
		Unsecured Credentials [ T1552 ]
		Network Sniffing [ T1040 ]
		Forced Authentication [ T1187 ]
		Input Capture [ T1056 ]
Privilege Escalation [ TA0004 ]	41.1%	Exploitation for Privilege Escalation [ T1086 ]
		Access Token Manipulation [ T1134 ]
		Hijack Execution Flow [ T1574 ]
		Valid Accounts [ T1078 ]
Defense Evasion [ TA0005 ]	26.7%	Access Token Manipulation [ T1134 ]
		Obfuscated Files or Information [ T1027 ]
		Deobfuscate/Decode Files or Information [ T1140 ]
		Rootkit [ T1014 ]
		Signed Binary Proxy Execution [ T1218 ]
		Hijack Execution Flow [ T1574 ]
		Valid Accounts [ T1078 ]
		XSL Script Processing [ T1220 ]
		Use Alternate Authentication Material [ T1550 ]
Impact [ TA0040 ]	13.4%	Resource Hijacking [ T1496 ]
Persistence [ TA0003 ]	7.3%	Hijack Execution Flow [ T1574 ]
		Valid Accounts [ T1078 ]
		Browser Extensions [ T1176 ]
		Server Software Component [ T1505 ]
Lateral Movement [ TA0008 ]	5.8%	Remote Services [ T1021 ]
		Use Alternate Authentication Material [ T1550 ]
Exfiltration [ TA0010 ]	2.8%	Automated Exfiltration [ T1020 ]
		Exfiltration Over C2 Channel [ T1041 ]
Collection [ TA0009 ]	0.8%	Input Capture [ T1056 ]

Naturally, a firewall is more prone to see more Initial Access attempts given its position on the network perimeter, where 90.9 percent of organizations saw alerts because of this tactic. Organizations saw exploit attempts against public-facing applications, such as for example Apache Struts, Bash, and Exchange Servers. Drive-by Compromise techniques, such as for example detecting connection attempts to spoofed SMB and websites share access attempts, were frequently encountered also.

Execution attempts were seen by 64.2 percent of organizations. Common rules that alerted on such activity covered vulnerabilities in content management systems (CMSes), the Zeroshell Linux vulnerability, and an Apache Struts code execution vulnerability. (Apache Struts also features prominently under Privilege Escalation and Defensive Evasion.)

Control and command activity came in third, where 48.7 percent of organizations saw traffic of the type. A lot of this traffic is made up of suspicious DNS queries, which indicate known or likely Control and Command sites.

Discovery tactics such as for example wanting to traverse administration files in a CMS was frequently seen. DNS BIND information disclosure attempts were also encountered.

In the Credential Access tactic, credential dumping attacks seem to be targeting routers and IoT devices such as for example CCTV cameras. Specifically, organizations saw alerts for attempts to exploit vulnerabilities that may provide admin credentials or attempts to gain access to PHP configuration files.

Snort categories

Now we’ll drill down deeper in to the ruleset and discuss a number of the frequently encountered rules. To get this done, we’ll examine the many rule categories in Snort. Beyond the policies described above, Snort rules are organized into categories that group similar rules together also. These category groups could be enabled and disabled in Secure Firewall as needed then.

So let’s discuss a few of the most encountered categories and the guidelines in them commonly.

SERVER-WEBAPP

Our most typical category lines up with encountered MITRE ATT&amp largely;CK technique, Exploit Public-Facing Application. This category is among the more varied of the bunch aswell, including rules to detect unwelcome connections to a multitude of applications.

CMSes were a favorite target. Alerts for a vulnerability in PHPUnit, a used PHP testing framework utilized by many CMSes widely, and alerts for a vulnerability in the Drupal CMS framework were regularly seen.

Alerts for vulnerabilities in the net interfaces or authentication processes of several routers and IoT devices were a normal occurrence. Unsurprisingly, the newest vulnerability is connected with the Hafnium attacks discovered last March, which exploited Microsoft Exchange zero-day vulnerabilities.

OS_OTHER

Most alerts observed in this category in this timeframe originated from rules made to detect several vulnerabilities commonly known as ShellShock . These vulnerabilities can provide an attacker unauthorized usage of vulnerable os’s that use Bash.

Why are a group of exploits from 2014 turning up so prominently in 2021? It’s likely because these old vulnerabilities have made their way into automated scanners or botnets that hit every open HTTP server they are able to find and launch a laundry set of exploits.

SERVER-OTHER

Several SSL-related exploits comprise a lot of the experience in this category. Specifically, the Heartbleed vulnerability from 2014. Like ShellShock, the exploit because of this vulnerability is present in lots of automated hacking tools.

Rules	Rule description	CVEs (if applicable)
30524	OpenSSL TLSv1.1 heartbeat read overrun attempt	CVE-2014-0160

SERVER-APACHE

The alerts observed in this category are made of vulnerabilities in Apache Struts predominantly.

SQL

Alerts in the SQL category have a tendency to center around injection attempts. However, handful of these have CVEs assigned in their mind, likely because of being the total consequence of poor database security practices, than an inherit flaw in the program itself rather.

Rules	Rule description	CVEs (if applicable)
19438	url ending in comment characters – possible sql injection attempt	CVE-2012-2998
19439	1 = 1 – possible sql injection attempt
16431	generic sql with comments injection attempt – GET parameter
49666	HTTP URI blind injection attempt
19440	1 = 0 – possible sql injection attempt

Other categories

While this summarizes some of the most seen categories, there are lots of other categories beyond this. For instance, CNC traffic from botnets such as for example Ursnif, Remcos, and Lokibot appeared in the MALWARE-CNC category. And SMB exploits and overflow attempts featured in OS-WINDOWS regularly.

Defending the perimeter

As of this true point it could appear as if network perimeters are under constant attack. While true largely, this does vary between organizations and which specific perimeter the firewall is defending. Each day and others just a few some see a large number of alerts.

It’s important to remember that many organizations might not utilize the applications or devices that Secure Firewall can alert on. That’s the reason IPS tuning is essential to lessen analyst alert fatigue. The known simple truth is that lots of exploit attempts are completed within an automated fashion, where in fact the attacker launches an instrument containing many exploits. In these full cases, they’re most likely wanting to see what realy works for future attacks.

But beyond this, it’s vital that you carefully consider which systems and applications are public-facing. Make sure to keep these systems up-to-date with the most recent patches at the earliest opportunity to avoid compromise whenever a new vulnerability is discovered.

Finally, a firewall with IPS capabilities, such as for example Cisco Secure Firewall , can go quite a distance towards blocking these attacks. Can be your organization prepared to see, try, or purchase a Cisco Secure Firewall ? Today get started!

---

We’d want to hear everything you think. Ask a relevant question, Comment Below, and Stay Linked to Cisco Secure on social! Cisco Secure Social Channels Instagram
Facebook
Twitter
LinkedIn