CERT-In : Sensor for MSME networks for logs

If you are an MSME and are looking at complying to the CERT-In directives on logs, then, a sensor we’ve built for generating and storing logs of the entire network, might just be what you are looking for.

What do the CERT-In directives on logs state

All service providers, intermediaries, data centres, body corporate and
Government organisations shall mandatorily enable logs of all their ICT
systems and maintain them securely for a rolling period of 180 days and
the same shall be maintained within the Indian jurisdiction. These should
be provided to CERT-In along with reporting of any incident or when
ordered / directed by CERT-In.

Challenges faced in incident response environments (MSME) with no logs

The idea of building a sensor stemmed from our experiences of incident response in environments with zero security posture.

CERT-In sensor MSME logs

The same sensor can capture network packets and generate logs per the CERT-In directives.

At the btNOG-9 Conference on the 14th October 2022, I’ll be presenting Incident Response on a shoestring budget

In the presentation, I’ll share the challenges we faced in incident response environments with zero security posture, i.e. lacking logs, etc. The presentation will then focus on the solution – a sensor we built using open-source software such as Suricata and Zeek, logging DNS queries etc.

By deploying a sensor in the network, MSMEs can comply with the CERT-In directives and also facilitate incident responders to investigate security incidents.

Incident responders can leverage the rich logs by intercepting and ingesting packets into tools such as Zeek. If you are new to Zeek, check the blog post, Packets don’t lie – Threat Hunting with Zeek and the APNIC Academy page where a recording of the webinar will be available soon.

For a broader deep dive into why Network Security Monitoring is important in the context of incident response, check my presentation on Packets don’t lie – Network Security Monitoring (NSM) for the masses

Aside from the folks at BtCIRT, I am hoping there would be a bunch of other folks from a security background interested in incident response.

Packets don’t lie – Threat Hunting with Zeek

Earlier today, I presented a webinar on ‘Packets don’t lie – Threat Hunting with Zeek.

Thanks to the kind folks at APNIC for initiating the request and starting the email thread.

The gist of the presentation was about using Zeek to look for anomalies. Before jumping into Zeek, I introduced Network Security Monitoring. Spoke about conn.log and dns.log and used PCAPs from Stratosphere IPS Project to demonstrate threat hunting with Zeek.

Zeek logs are a great source in the context of threat hunting and Incident Response.

A total of 203 folks had registered for the webinar, and around 55-60 attended. That’s been my experience with online webinars and workshops – many folks will register, but a small fraction attend.

While one hour webinar is a brief period to talk about all-things-zeek, I hope the webinar gives a quick introduction to getting started.

But the most important thing was the interactive Q&A session at the end.

The webinar was recorded and should be available in a few days. I will update the blog post with a link to the recording and the slides.

Also, since I am on the topic of Zeek, ZeekWeek 2022 is an in-person event on October 12th – 14th in Austin, TX.

An excellent line-up of speakers, and the schedule is packed with goodness.

Little Snitch – Capturing traffic of a specific process

While investigating a bit of oddity with the Skype app on Mac OS X, I wanted to capture all traffic from only the Skype processes.

But first, a little background on the issue. All DNS traffic from my systems is routed through a WireGuard tunnel. The peer endpoint at the other end runs a recursive resolver with DNS Response Policy Zones (DNS RPZ).

The issue is – that as soon as the WireGuard tunnel is disabled, Skype will try connecting to Google DNS(8.8.8.8) and www.bing.com. Perhaps Skype bypasses the local recursive resolver set on the system and sends the DNS queries for its hosts to Google DNS directly? I cannot ascertain that yet, and it warrants a thorough investigation.

I was alerted to this by Little Snitch after I refreshed the rules. A ritual that I seem to follow every few months.

Little Snitch Network Monitor contains a hidden gem. The ability to capture traffic of a specific process.

For example, by right-clicking on any process, you should see the option to Capture Traffic. That should open a terminal window prompting for the sudo password.

After capturing traffic and interrupting should result in a PCAP on the Desktop. Neat!

Little Snitch documentation about this feature.

APNIC 52 – Threat Hunting using DNS

I presented on how we at my $dayjob do Threat Hunting using DNS at APNIC 52.

This is the same presentation I gave at SANOG 37, but luckily, I had the full quota of 20 minutes to complete the presentation without rushing into it.

Here is the video of the presentation,

Happy hunting!

SANOG 37 – Threat Hunting using DNS

PC: Mohan Thomas

At SANOG 37, I had the opportunity to share some of the ways in which we have been doing Threat Hunting using DNS at my $dayjob.

Here is the video of the presentation.

I also had a little demo but I decided to improvise and add slides instead, since the program was running a little behind schedule and I was the only one standing between everyone and their lunch. trouble was also lurking.

That aside, the same paper ‘Threat Hunting using DNS’ has been accepted at APNIC 52 and hopefully, I will be able to demo the juicy bits.

Network Security Monitoring(NSM) @ Home

Over the course of the last year, the Flat Network at home has become an important extension of the enterprise network.

Figure 1 – A simple representation of a flat network

What is a flat network?

  • The network is not segmented i.e computers/devices can access any other computer/device in the network
  • A simple design with the goal to reduce cost, maintenance and administration

From a security perspective, the design poses a few challenges,

  • Systems/devices that are part of the network can communicate with one another – malware working the way laterally and propagating
  • Lack of visibility into the nature of communication between devices/systems in the network and the Internet – Getting answers to questions such as which IP addresses on the Internet does the smart bulb (or replace it with any Internet of Trash device) connect to or why is the Windows OS connecting to an IP address in China etc

Both of the above are traditionally addressed using Network Security Monitoring (NSM)

At my $dayjob, we implement NSM for enterprises and that requires investment on hardware, configuration and maintenance.

In the context of a home network, one wouldn’t be happy or interested in spending a large amount of money to setup a full fledged NSM at home (unless you are like me).

That’s exactly where the Corelight@Home project comes in.

Corelight is excited to announce the Corelight@Home program, bringing Corelight’s enterprise-class Network Detection and Response to home networks. While it is not a commercially available or officially supported product, it has all the same capabilities you’ll find in our Corelight Sensors. It combines all the goodness of open source Zeek and Suricata plus most of the value-added features of Corelight Sensors, FREE for home use. Put it all together on cheap, dependable hardware, and you can shine a light on suddenly vital home networks.

Source – https://corelight.blog/2020/11/19/corelight-at-home/

And the best part, it has been designed to be deployed on a RaspberryPi.

So, apart from the investment of a RaspberryPi, one will also need a network switch which can mirror packets or a network tap. Considering the goal of implementing NSM in the home network for cheap, a network switch is the only choice.

In India, the cheapest that I could find was the Netgear GS310TP for Rs. 8800 (inclusive GST) or around $120

Figure 2 – Netgear GS310TP

If you already have a managed/smart switch suggest that you check the manual and see if it supports port mirroring.

Figure 3 – Flat network with a NSM sensor (Raspberry Pi)

The next thing is to sign-up for the Corelight@Home program

After receiving the login details, setup the RaspberryPi based on instructions in the Software Sensor Docs.

The next step is configuring the network switch to mirror packets (port mirroring). The simplest configuration is to mirror the uplink port (port on the network switch where the Internet router is connected) to the sensor port (port on the network switch which connects the RaspberryPi )

With the sensor configuration done, the last bit that remains is to ship the Zeek logs to Splunk or Humio for pretty dashboards.

Corelight Software Sensor supports a large number of exports,

  • Splunk (via the HTTP Event Collector) or Humio
  • Kafka
  • JSON over TCP
  • Syslog
  • Redis

The idea behind the implementation in the home network was to have visibility into the home network for cheap. Considering that, and the assumption that most won’t have decent compute to run an ELK stack etc, I went with Humio. They provide a Free SaaS tier with 2 GB inject per day and retention of one week.

Figure 4 – Humio dashboard with network insights

Note – One can also negate the Corelight Software Sensor and setup Zeek, Suricata and configure the RaspberryPi as a sensor. Aside from the simplicity of getting started with an NSM, the Corelight Software Sensor also provides more insight into encrypted traffic, built-in integration into Zeek and Suricata such that pivoting between them is easy.