Skip to content

Enough with the Hoodies: Education without the scare tactics

Growing up, I had DARE & abstinence-only education, which were comprehensive national education programs designed to educate children and keep them safe. They are an easy sell with a “wholesome” and straightforward answer to an otherwise complicated subject. “Just Say NO!” can be readily understood by young and old and easily marketed. Why not for InfoSec? Why not on a national scale?

The ubiquity of electronics has grown exponentially. According to a 2017 article by the Pew Research Center, 33% of all Americans live in a household with three or more smartphones and a whopping number of 80% of households with at least one laptop or desktop.

Breaches are growing at an astounding rate, and records are stolen at a steady clip.

“Sorry! We got breached ☹” they say shrugging their best shrug while their hands are still numb from sitting on them for so long.
“We don’t think it’s a problem, but change your password anyway.” Crossing aforementioned numb fingers “And guess what? You get credit monitoring, and you get credit monitoring, and you get credit monitoring!”

The eventual Krebs article is posted, Forbes picks it up, and your friendly skid tweets about it between rounds on PUBG. I go and show my family who replies “Oh Josh, I have nothing to hide. I don’t care about this hacker crap” Actual freaking quote by the way. The cycle then repeats.

As an ethical hacker, who lives and breathes IT Security daily, it’s hard to convince my family to follow best practices. Sometimes I can, for a while, then it gets “too annoying” or things “keep breaking”. “So,” you ask, “Is there hope for us on a grand scale? What can we, the average person do?”

I am glad that you asked kind stranger! There is hope! What, you may ask, well, it’s a free dark web scan… just kidding, sorry Rudy. Patience. The answer is patience. Security is hard, the concept is easy, but the road is hard.

The US and other governments have educational programs in place, which is a wonderful start. Often, one-off events that typically attract those who are already interested. Let’s keep those, but let’s sponsor daily one-minute segments for news corporations to distribute. Nothing scary, nothing dire, just simple and straightforward.

A segment on verifying links in emails, don’t open strange attachments and don’t reuse the same password. Quick, simple segments that allow for the average person to digest, once a day, and doesn’t overwhelm them. A security “Billy Nye,” if you will, that doesn’t solve everything, and it doesn’t have to because this leaves room for comprehensive embedded security training in schools – which we needed yesterday.

Our families don’t need to obtain certifications and maintain continuing professional education, so we should stop acting as they do. Until we embed security into our education curriculum, we need security information for the masses that is relatable, understandable, and digestible. We need a Bill Nye for InfoSec, a HAK5 Sesame street, and a news segment that doesn’t show any more hoodies.

Seriously, enough with the hoodies.

 

Security Onion Set Up Part 4: Tuning

Once data starts flowing through the sniffing interfaces you are going to be presented with a lot of false positives. It’s essential to reduce the number of false positives because the identification of real indicators can become next to impossible and your hardware will thank you. When I fired up Security Onion on Ubuntu 16.04 for the first time, it was generating around 26 alerts a second using Emerging Threats and Snort rulesets. Now that my installation is tuned it’s generating .023 alerts a second which is far more manageable than 26 a second.

There are two ways to tune alerts, and that’s by disabling a rule or configuring a threshold (rate limiting). Disabling a rule should be done only when you are confident, through investigation, that the rule doesn’t apply to your environment or you have a better way of identifying the indicator as a confirmed positive such as antivirus or a firewall. Adding a rule to the threshold file allows you to track the event by source OR destination IP address, CIDR, and set the rate of alert generation by specifying the number of alerts per seconds. You can also suppress rules which means they’re still active but the data matching them is ignored as opposed to disabling rules which mean data isn’t compared against the rule for a match to generate an alert.

This guidance is version agnostic.

The command to find the rules that are generating a lot of alerts for your starting point is “sudo sostat.” You will have to scroll up a little to find the Top 50 All-time Sguil Events.

Here are the locations of the disablesid and threshold files:

  • /etc/nsm/rules/threshold.conf
  • /etc/nsm/pulledpork/disablesid.conf

My text editor of choice is vi so the commands to access and edit the files are as follows.

  • sudo vi /etc/nsm/rules/threshold.conf
    • Press “i” to insert text
    • Comment out the description of the rule you’re adding by using “#”
    • Add the rules by using gen_id (generator id) and sig_id (signature id)
      • Suppression – suppress gen_id 119, sig_id 34, track by_src or by_dst, ip <IP address or IP block\CIDR>
      • Suppression – suppress gen_id 119, sig_id 34
      • Rate limiting – event_filter gen_id 3, sig_id 30881, type limit, track by_dst, count 1, seconds 60
    • Once you’ve added the rules press escape then “:” followed by wq (write, quit)
  • Run “sudo nsm_sensor_ps-restart –only-snort-alert” adding suppression entries
  • sudo vi /etc/nsm/pulledpork/disablesid.conf
    • Press “i” to insert text
    • Add a description of the rule you’re disabling by using “#” to comment out the text, so the IDS engine doesn’t try to process it
    • Add rules to the file, e.g., 1:2009702 (generator id:signature id)
    • Once you’ve added your rules press escape then “:” followed by wq (write, quit)
  • Run sudo rule-update

If you enter the vi editor without making any changes you must use “:q!” if you pressed “i”; use “:q” if you didn’t use the insert command.

If you’ve spent any time searching Google to tune Security Onion you’ve probably come across a few forum threads that insist on getting your total signature count to under 8000 which assumes you’ve invested time that most people don’t have into looking into the 30000 to 60000 total signatures between Snort and Emerging Threats (configuration dependent). Aiming for a threshold of the overall signature count isn’t the best way to go about tuning Security Onion because you’ll never know every signature you’ll need, so it’s best to rate or disabled signatures based on operational need.

In the next section, I’ll be talking about PCRE which stands for Perl-compatible regular expression. PCRE can be used with simple keywords such as “sensitive_data” without converting it into a regular expression.

Here are signatures that I’ve found to be common false positives across many environments:

  • All sensitive_data signatures using “pcre:”
  • All http_inspect using “pcre:” unless you have a web server
  • SMTP: attempted command buffer overflow (124:1)
  • All stream5 using “pcre:” unless you have a web server
  • TMG Firewall

Worth noting, Security Onion doesn’t always process PCRE entries so you’ll have to resort to “gen_id:sig_id.”

Do you need to block advertisement shenanigans without blocking the advertisements?

If you’ve never heard of malvertising or need a better understanding, then you should read the article on malvertising first. If you’re familiar with malvertising and have run into issues with blocking advertisements, then I might have a solution for you. I recently ran into problems with blocking ads because non-ad images weren’t loading due to being served from an ad network which is ideal from a content delivery aspect, but terrible from a security aspect. (more…)

Security Onion Set Up Part 1: Planning for Version 16.04

The guidance in the article “Security Onion Set Up Part 1: Planning” no longer applies if you’re using the new Security Onion image because it uses Elastic Stack instead of ELSA. Elastic Stack might be a resource hog, but the workflow is superior compared to ELSA in the way you can visualize data in the dashboard and pick from pre-configured searches that touch on almost everything you would need to look at out-of-the-box. (more…)

What’s New With TLS 1.3

TLS 1.3 is the newest version of Transport Layer Security which is a cryptic protocol that allows for your web page traffic to be secured. It works to secure the communications between client and server to include passwords, and other crucial information sent from client to the server, and server to the client. As a result, TLS makes it extremely difficult to gain access to the information sent while it’s traveling to and from the servers.

The first significant difference that you can notice between TLS 1.2 and 1.3, is that the web browsers will begin to load quicker, this is due to TLS reducing the number of “round-trips” required to establish a connection from 2 to 1. This method is useful for reducing the time in which it takes to send client-side data to the server, which is the main reason that the pages load faster. Sessions in previous versions of TLS use client-side certificate id’s, the id is special for that client only, and before the client connects to the server, the server looks up the client’s id in the server’s cache of ids. If the server matches the id with the current client being used, the server then knows to use the same security measures used previously; One downside to this method is that the servers have to have a shared state. As a result of the downside to that, TLS 1.3 changed the way the certificate system works, and essentially makes the certificate self-encrypted, as well as self-authenticated; Therefore, the servers used to fetch the client-side certificate can become stateless. (1)

Some history regarding TLS 1.3 and 1.2 is that TLS 1.2 was enacted in 2008, which allowed for safer web browsing, since then there haven’t been any updates in TLS until now. TLS 1.3 is described as a way to “block” any form of eavesdropping from outside sources, as well as prevent message forgery and other types of crimes. This new way to TLS is all around a better, more secure way to browse the internet, with this new TLS discarding all other forms of cryptographic protocols that are weak.

What does this mean for us? It means that it is now harder for scammer and hackers to intercept any form of communications from the client to server, and server to the client. Change is coming, and it’s happening faster than you can imagine. (2)

References:

TLS 1.3 Protocol Support | Documentation

TLS 1.3 is nearly here