De-Coder’s Ring

Software doesn’t have to be hard

Category: suricata

Spilling the beans…

Today, I’m at ILTA’s LegalSec Summit 2017.    Giving a talk later about Threat Automation:

Me

Talk

I’m excited about sharing some information about Threat Intelligence, automation and application on a network sensor.  That’s all good stuff.

What I’m really happy about, is that I can be totally open with the technology.  My goal is to educate folks on how they can do what my company does on a daily basis.  As an open source advocate, and a giant fan of a lot of the technology that I use every day (duh!), it’s good to show others how to do it.  We don’t provide anything that qualifies as super cool intellectual property….  we have some, but anyone can build the basics to run in their shop.  The challenge comes with the human capital needed to build and run this stuff.   That’s a big part of the challenge.

Slow Down: Wrong Cables

I made a bone head move this week.   I went onsite to a new customer, who we love, to install a new network sensor.  It’s been a crazy hectic few weeks with the growth we’re having @ Perch Security, but that’s not really a valid excuse.  I’m owning up to my mistake, and reflecting on it.. thankfully, our customers are super cool and they get it.

Normally, I label our sensors for easy installation.

Dang, look at that sticker

That way, our customers know which port to plug into their management network, and which port is going to be watching their mirror/span/tap.  The installation went well.  The sensor was talking to my cloud.  The problem was, the sensor was only seeing broadcast data.  No typical network traffic (HTTP, SMTP, etc.  see:  post ).  Obviously it was a mirror configuration problem.  After all, if the sensor has an IP address and can talk out, the management port CAN’T be plugged into the mirror port.  It’s not my problem, it’s the switch!    (Uh oh, bad assumption right there, it turns out).     I would have known that, if I had the right ports plugged into the right ports on the switch.   Ugh.

Of course, this time we had a lot of new things

  • New hardware build, so unfamiliar with layout of the back
  • No stickers (cause it fell off in transit, argh!)
  • No indicator on the back of the sensor to which port is which

All of these things were in place because I was rushing around like a dying chicken.  That’s a thing, right?

Now it’s time to reflect.   How do I set us up for success going forward?     I have instructions.  I have labels.   I have the know how to do it all.

I just need to slow down.  Slow down.  Slow down.

(( Thank you for reading my self reflection for the week.  If you don’t hire me some day because of this post, that’s OK.. I ain’t perfect  ))

 

Recursive Alerts

I don’t often play SOC analyst, but when I do, I see some funny things…  some scary things… and a lot of mundane things.

One of the interesting things we’ve seen recently in the Perch SOC is what I’ll call a ‘recursive alert

What’s an alert?

I built a sensor for customers around the open source tool, Suricata.  It’s magical, wonderful, and freaking fast. The developers are awesome folks, and they deserve lots of money/beer/bourbon when you see them.  See other items related:  Suricata NSM Fields  , Suricata Stats to Influx DB/Grafana , Installing Filebeat to ship data to Elasticsearch

Suricata can monitor network traffic, looking for specific rules.  Rules can be built to look for IP addresses, domain names, packet content (strings, binary, etc).   If  a rule matches some traffic, then Suricata will generate an alert record.   These records have Network layer 3/4 information (source and destination IP addresses, ports), as well as protocol information.  It can also put the ‘printable payload’ in the alert record.  This is the ASCII printable contents of the packet that triggered the alert.  It also prints out the hex, in case it’s not printable/binary content.  This is truly wonderful when it comes troubleshoot.

Meta Alert

(Building up towards a recursive alert, hang tight)

A few days ago, our SOC lead and I were triaging a bunch of new alerts from a customer of ours.  These were bad news, we were kind of scared.  Like, honestly scared because this meant there was a major breach or infection.  In the years I’ve been doing network security, I’ve never seen this many hits on rules.. this many diverse hits on rules.. at the same time…. between two hosts.. wait a second.. something is wrong.

Multiple exploit kits, multiple content matches on web sites. ok, something funny.  Turns out, one end of the TCP connection was a backup server (keeping the type quiet for now), the other end was a Nessus server.  ah ha!  The rules were triggering on the metadata/configuration files in Nessus!   Nessus is a vulnerability scanner.  It has TONS of information about exploits..  when those files were backed up across the network, my sensor triggered!   The rules matched, but why the heck was the backed up data going in clear text over the network?   SSL/TLS is easy!  SCP/SSH is easy!  Come on vendors, pick up your game.

Recursive Alerts

Now here’s where we get recursive!  Some suricata rules look for content.  Actual, raw strings of content within packets.  They can be chained together (think this:  See “one” followed by “two” followed by “three”) for specificity, because we all hate False Positives!!  Now, imagine the ‘rules’ file that contains the … rules.   It gets backed up on the network, and BAM, the rule detected itself.   Recursive rules.  Self detecting rules.  Did it get incepted?

Lesson of the day

Use encryption on the wire when backing up everything.  Simple.

 

 

 

© 2017 De-Coder’s Ring

Theme by Anders NorenUp ↑