To my surprise, the most clicked post ever on this blog is this:
Network Sniffing for Everyone:
Getting to Know Your Things (As in Internet of Things)
… a step-by-step guide to sniff the network traffic of your ‘things’ contacting their mothership, plus a brief introduction to networking. I wanted to show how you can trace your networked devices’ traffic without any specialized equipment but being creative with what many users might already have, by turning a Windows PC into a router with Internet Connection Sharing.
Recently, an army of captured things took down part of the internet, and this reminded me of this post. No, this is not one more gloomy article about the Internet of Things. I just needed to use this Internet Sharing feature for the very purpose it was actually invented.
The Chief Engineer had finally set up the perfect test lab for programming and testing freely programmable UVR16x2 control systems (successor of UVR1611). But this test lab was located in a spot not equipped with wired ethernet, and the control unit’s data logger and ethernet gateway, so-called CMI (Control and Monitoring Interface), only has a LAN interface and no WLAN.
So an ages-old test laptop was revived to serve as a router (improving its ecological footprint in passing): This notebook connects to the standard ‘office’ network via WLAN: This wireless connection is thus the internet connection that can be shared with a device connected to the notebook’s LAN interface, e.g. via a cross-over cable. As explained in detail in the older article the router-laptop then allows for sniffing the traffic – but above all it allows the ‘thing’ to connect to the internet at all.
This is the setup:
The router laptop is automatically configured with IP address 192.168.137.1 and hands out addresses in the 192.168.137.x network as a DHCP server, while using an IP address provided by the internet router for its WLAN adapter (indicated here as commonly used 192.168.0.x addresses). If Windows 10 is used on the router-notebook, you might need to re-enable ICS after a reboot.
The control unit is connected to the CMI via CAN bus – so the combination of test laptop, CMI, and UVR16x2 control unit is similar to the setup used for investigating CAN monitoring recently.
The CMI ‘thing’ is tucked away in a private subnet dedicated to it, and it cannot be accessed directly from any ‘Office PC’ – except the router PC itself. A standard office PC (green) effectively has to access the CMI via the same ‘cloud’ route as an Internet User (red). This makes the setup a realistic test for future remote support – when the CMI plus control unit has been shipped to its proud owner and is configured on the final local network.
The private subnet setup is also a simple workaround in case several things can not get along well with each other: For example, an internet TV service flooded CMI’s predecessor BL-NET with packets that were hard to digest – so BL-NET refused to work without a further reboot. Putting the sensitive device in a private subnet – using a ‘spare part’ router, solved the problem.
elkemental Force 
Elke, I have posted a solution to the algebra thing. I hope you have some fun with it.
You are amazing.
Thanks a lot, Dave!!
What is amazing is that all this is even possible. The idea that you configure such a network is a testament to those engineers that developed these protocols. Funnily enough, just this morning whilst driving to work and listening to an interview with Airbus who was developing anti-malware and anti-ransomware solutions, it occurred to me that the transparent infrastructure of the internet and IoT protocols is also its very Achilles heal. And the next thought was, we should develop private and bespoke hardware protocols for sensitive equipment such as satellites, arms, nuclear power stations etc. Just a thought.
I am wary of ‘private’ security protocols. If protocols are publicly documented, they can be scrutinized relentlessly by academics and researchers. Private protocols may contain simple mistakes and loopholes nobody has ever checked for. Bruce Schneier says Security is putting a safe into your enemies’ hands, together with a specification of the protection mechanism used, but a private protocol on the other hand is like hiding the safe in the wood in a place you consider secure and telling nobody.
I had a look at private protocols for some critical hardware some time ago and I e.g. really wondererd why on earth somebody would delevelop their own hash algorithm. Now they are all moving to standardized stuff. When asking about the need to use a private protocol I sometimes also heard ‘Oh, we did not know that protocol XY does exist, so we just developed our own version.’ One colleague of mine attribute that to software engineers aspiring to be artists, developing their own unique things, than doing the boring grunt work of reviewing and reusing software that is already available.
That makes sense. Just remembered you are a security expert!!!
Not sure if I still count as an expert in anything, given my weird portfolio of services ;-), but I still do also security consulting (re Public Key Infrastructure)