Investigation in Isolation: Flume Smart Home Water Monitor
Digging into the network behavior of the Flume Smart Home Water Monitor
The Flume Smart Home Water Monitor is a device that straps to your water meter and measures the flow to identify patterns of usage. By detecting your typical water consumption, it will be able to pinpoint when leaks occur – and notifying you when it detects any anomalies in the behavior.
I bought a Flume at an opportune time: just as they'd inked a co-marketing relationship with Sense, but before they changed their pricing structure. In this post, as usual, I'll isolate the Flume's network activity in the interest of securing it and restricting it, while not compromising its functionality.
About the Device
The Flume consists of two main components: the meter, which uses a rubber elastic strap to secure to your water meter, and a "bridge" that speaks to it – presumably over Bluetooth. The bridge joins your WiFi network and reports information to Flume's cloud service.
The setup was extremely quick and painless. My water meter is under a trap door in the basement of my house. The installation and configuration of the meter and bridge took less than 30 minutes from start to finish. It was able to start reporting data to the Flume cloud without any fuss.
Booting Up
While I didn't capture the onboarding steps, I did power cycle the bridge before writing this article to capture the bootup behavior.
- A standard DHCP offer. The MAC of my bridge identifies itself as belonging to "Espressif Inc.," a common sight for WiFi IOT devices. The Fingerbank API concurs that the DHCP fingerprint belongs to
Internet of Things (IoT)/Generic IoT/Espressif
. - Flume immediately sends an NTP request to the server identified in the DHCP response.
- Flume sends a DNS query for
mqtt.prod.flumetech.com
, which (at least in my case) returns an IP address within Google's GCP. The TTL for the DNS response is five minutes.
Sending Telemetry
As you probably surmised by the hostname Flume resolves, the data sent to Flume is sent using MQTT. It opens a socket to 1883/tcp and sends an MQTT "Connect" command.
Note: I am by no means an MQTT expert, so I will not pass judgment on whether my observations are evidence of unusual implementation choices... they're merely observations.
The MQTT Connect message uses version 3.1.1, and the Flume implementation does not use transport encryption. This means that the MQTT password sent during the Connect message is sent in cleartext. (Not a big fan.)
After connecting, the Flume subscribes to two "Topics" from the Flume MQTT broker. The Topic IDs persist between reboots, so the topics must be hardcoded into the device. From this point on, there are Publish messages sent from both the Flume and the cloud. The Publish message contents range from about 200-400 bytes each, and are sent at very odd intervals. The time lapse between Publish messages ranges from a handful of seconds to many minutes – I saw gaps of as many as 13 minutes during my 24 hour sample.
The MQTT socket is kept open with MQTT application-layer pings. These are sent every 21 seconds.
128T Configuration
Since other devices in my network use MQTT, I'd already configured a session-type
for MQTT traffic:
admin@labsystem1.fiedler# show config run authority session-type MQTT
config
authority
session-type MQTT
name MQTT
description "MQ Telemetry Transport"
service-class OAM
timeout 360000
transport tcp
protocol tcp
port-range 8883
start-port 8883
end-port 8883
exit
port-range 1883
start-port 1883
end-port 1883
exit
exit
exit
exit
exit
Currently, my Flume bridge has access to the cloud broker in GCP through a generic internet
service I've created. If I wanted to lock down the Flume to a specific set of targets, I'd create a service along these lines:
*admin@labsystem1.fiedler# show config candidate authority service FLUME
config
authority
service FLUME
name FLUME
description "Flume cloud service"
address mqtt.prod.flumetech.com
access-policy flume.iot
source flume.iot
exit
service-policy data-best-effort
exit
exit
exit
A few points on this candidate configuration:
- The address is specified as an FQDN. This is referred to as a DNS-based service in the world of 128T. For applications such as this one, the drawbacks to DNS-based services do not really apply.
- I've specified the
service-policy
asdata-best-effort
. This Flume water sensor isn't really mission critical for me (although I'm saying that without having experienced a detected water leak...). Moreover, the MQTT messages are sent using the QoS Level flag "fire and forget." The specified MQTT QoS policy seems to line up with the spirit ofdata-best-effort
.
Conclusion
Although I'm unhappy with the cleartext password, the Flume device has been quite interesting to monitor. The network impact is nominal, and the implementation otherwise is quite succinct and easy to secure. The Flume device honors the DNS and NTP servers it receives in the DHCP request (the same cannot be said for a number of IoT devices), and is a good network citizen.
Happy monitoring!