Investigation in Isolation: 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.

1. 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.
2. Flume immediately sends an NTP request to the server identified in the DHCP response.
3. 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 as data-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 of data-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!