ChipMaster at Play

User since 2020-09-03 20:56:31 profile updated 2021-05-03 11:41:21

ChipMaster at Play
A C.H.I.P. wired up to tell time (visually & audibly) plus play some music!

This just in: I'm making a Poor Man's IDS for my personal cyber-defense! See below.

Welcome web travelers. When I was very young, in the 1970s, my dad woke me up, in the middle of the night, took me to his office and showed me how he could type a BASIC program to count to ten into a terminal connected to a mainframe computer. I was entranced! A machine that did anything you told it to do! WOW! Sometime later a TRS-80 model I level 2 came home. I have been passionate about computers, especially writing software, ever since. So much so I had a boss give me the title "Chip Master". I am the "SysOp" of this site.

Since cyber criminals and big-tech companies combined are an ever increasing threat to all of our digital lives, which could spill over into our physical world, I'm taking steps to keep an eye on what my devices are chirping across the net and to whom. I'm recording my steps into this so maybe I can be of help to other security / privacy conscious users.

Poor Man's IDS:

There are a few different classes of "Intrusion Detection Systems" (IDS). Since the bulk of malware or corporation sponsored leaks require communicating across the Internet I'm starting with a central network based approach. Corporate sponsored security problems can be many starting with things like Alexa, Siri, ... sending your voice across the web for processing on their AI systems and who knows what else. But it can also be as simple as accidentally providing malware entry via "ad servers", JavaScript hosting services or unwanted privacy leaks with disconnected traffic tracking (ala g00gle Analytics).

A couple of scenarios that came to light recently:

  1. If you turn off the data services (cell,WiFi) on your android device for a week or so when you turn it back on the device becomes virtually comatose due to the flood of network traffic it produces. Give it some time, depending on how long its been off and it will start to become responsive again. What is getting passed around? Is it bad? We don't know.

  2. We recently had an SSD die in a laptop of ours and we needed to temporarily replace it with a slow (aka power efficient) spinning disk. We found several of the well known news sites would bog down and literally lock the machine up for minutes, sometimes requiring me to SSH in and kill FireFox. The performance suck was entirely hard drive saturation. What was it doing reading our entire HDD? Sending it across the web? "Star Fleet Strength!" (Start Trek Movie #1). killall firefox I love that command.

So phase 1 of this project is to be able to watch network traffic and block access to sources I choose. Basically putting me in control of my computing environment again. I might block sources for any number of reasons, including I just don't like them, like ad servers. If you haven't figured out already that "ad servers" are a source of malware you haven't been reading enough computer security news or paying attention to your own devices' behavior. I do know that #2 above was caused by something from the ad services. They don't seem to vet their stuff. But knowing how to disable software package X's auto-update can be incredibly handy too.

WARN: What I'm doing here is not an install and forget sort of solution. There are commercial products out there that will attempt to protect you to some extent, without any need to understand what is really happening. What I'm building up here are tools for the truly paranoid and those individuals who want to get their hands dirty and reassert control.

You can't trust code that you did not totally create yourself. Especially code from companies that employ people like me.
-- Ken Thompson @ '83 Turing Award

Recipe 1:

  • 1x Netgear WiFi + router appliance
  • 1x Shibby Tomato firmware for the Netgear.
  • 1x USB HDD/SSD for the Netgear
  • Custom firewall rules
  • Another Linux host (workstation, server, SBC, ...) running a SyslogD with remote access enabled.
  • Various custom software to analyze the data.

I've become a fan of the Netgear router line. If you buy the "open source" approved versions, Netgear actually encourages customizing the firmware or loading a completely different version. They have a website for tinkerers to exchange tips and firmware loads @ MyOpenRouter.com. I fell in love With Shibby's Tomato firmware because its packed with some seriously useful networking features, clean, compact, well thought out with some very simple but powerful add-ons for the Linux aware user. I can almost do everything with it I could do with a PC running Linux.

Speaking of Linux PCs: basically any Linux capable device that can sit between your network and your Internet connection can be used to accomplish these things. To some degree the Netgear complicates things for me, as compared to another Linux device like a PC or SBC, due to the limited RAM and storage resources. The simplest possible setup would be a single Linux machine (even SBC) attached directly to the Internet running as your workstation and firewall, combined. SBCs don't usually make good firewall / router devices due to the lack of network ports. But there are some out there with multiple ports. A functioning discarded PC with two or more network ports is an excellent choice, although larger than most would like these days.

NOTE: **This is a work in progress. I'm documenting things as I go and as time allows. As I dive into the flood of data the road is likely to have many twists and turns.

My initial setup to get a look at the data is pretty simple. I want to grab DNS queries and correlate them to inbound and outbound network connections. I want to match the connection IP addresses to the DNS queries by a few different factors: internal host, time & external address. To do this I'm going to ask dnsmasq on the router to log the DNS queries. I'm then going to add iptables rules to log brief information about connections being made. Lastly I will setup remote logging via syslogd from the Netgear to another Linux box with more resources. But I also setup logging to an attached hard drive as a backup. It could have also been a primary source of data by either sharing the disk or accessing it over SSH.

OK. The dnsmasq setup is accomplished in the "advanced | DHCP/DNS" settings of the Tomato control panel. The part that matters looks like this:
DNSmasq settings

I circled the section that I changed. The logging option is not directly supported by the GUI but since Tomato allows me to pass any valid DNSmasq config file settings, I did. The log-queries is what I wanted. But the highlighted, rem'd out section has some other settings that could be helpful. The big one is log-facility which would allow us to specify the locally attached HDD as a destination. But since I want the iptables data too and it gets logged to syslogd and I want to hand it off to another machine for processing I want all logs to go through syslogd. In this scenario the log-facility could still be used to change the "service name" and "level" see man 3 syslog for explanations of those.

NOTE: I noticed when I ssh'd to the router last, that the log-async option is enabled internally and not needed to be set here. This option is what it sounds like.

The packet savvy may already have guessed a couple of avoidance issues with the DNS logging approach. This only works if the software running behind the router uses the router for DNS. This can be, and I do enforce it with iptables rules. The rise of "DNS over HTTPS" is another possible avoidance tactic which can also be observed and blocked to force it through dnsmasq for later analysis. Although most devices will honor the DNS settings provided by the router via DHCP I've observed software and hardware pre-programmed to use something else, like: g00gle.

Tomato made the iptables part of the setup stupid-simple. Go to the "administration | logging" settings and everything I needed to change was right there:
Tomato SyslogD settings

Obviously you need to turn on logging to begin with, which is the log internally setting. Since I've chosen to put the local log on a USB attached HDD, instead of writing to the internal RAM disk, I increased the max size.... I set the custom log file... and log to remote... settings accordingly. The IP address and port need to point to a machine open to receive logs. More on that in a bit. After that I then set the connection logging settings to both. That's probably self explanatory.

If you want/need to write your own iptables rules those last two settings create a rule like this:

iptables -A FOWARD -m state --state NEW -j LOG --log-prefix "CONNECTED "

I can't explain the details of iptables at the moment. But for those familiar with its operation you will likely know how to adapt that to suit. Simply: what this does is cause the packet filter to log things like source & destination address and port numbers when a new connection is observed... well mostly. I discovered there are some occasions where what looks like a new connection is actually a part of an existing connection. I'll get into that later.

The --log-prefix part of the rule creates a prefix in the logged line sent to syslog. It can be used to make for easier greping. You could mark direction of travel. But I use it to mark how the firewall handled it: BLOCKed, REJECTed or ACCEPTed. This will allow me to watch what I'm blocking separately from what is allowed to flow through the firewall.

As far as the server receiving the syslog data: this can get complicated due to the number of different log daemons out there and the varying ways to configure them. Throw in the many different distributions and there is an impossible number of variables to address. You'll have to check for guidance from your distribution. I use Devuan (a Debian derivative) with the inetutils-syslogd package. I may change the logger now that I'm doing something more extravagant with logging. I set the -r switch in the /etc/default/inetutils-syslogd config file and made sure the appropriate firewall hole is there to receive log lines from the Netgear (router).

--- more to come ---

C.H.I.P. Related Links:

SBCs that interest me since C.H.I.P. died:

  • OrangePi Zero Teensy, very affordable and very useful.
  • NanoPi Fire 2a LTS can almost compete with the C.H.I.P. in flexibility but at about 2.5x the price. Still less coin than a RaspberryPI.
  • Beagle Bone Black may actually be able to take the place of CHIP in a PocketCHIP.
  • RaspberryPi They have apparently partnered with M$. I have no use for such things and they are hostile to anyone speaking ill of M$. So its a mutual dislike.

My Current favorite MCU:

ATmega328P (aka Arduino chip). I like to use them either on the discontinued, but cloned everywhere, "Pro Mini" boards or just the bare 28pin dip.

My favorite is likely to change as I find more units to play with. But this little guy is seriously flexible and affordable!

More to follow...