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(126.96.36.199) 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!
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.
Over the course of the last year, the Flat Network at home has become an important extension of the enterprise 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).
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.
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
If you already have a managed/smart switch suggest that you check the manual and see if it supports port mirroring.
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
JSON over TCP
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.
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.