Mega Review: Fingbox Network Security and Troubleshooting Device

Earlier this year, I visited CeBIT where I stopped by the Fing stand and had a chat about their app and Fingbox device. The Fingbox was pitched as a network security and troubleshooting device which worked with the Fing app, adding additional functionality such as detecting network intruders, tracking who is online, blocking devices, testing internet and Wi-Fi speeds, detecting Wi-Fi attacks and detecting nearby Wi-Fi devices. It seemed like an interesting concept which had some merit so after a few e-mails, thanks to Fing, I was able to secure a Fingbox for review.

Unlike some other reviews of the Fingbox, this one is performed under the Review Challenge terms. As a result, I am not an affiliate, I do not receive any commission and I can provide my honest and comprehensive opinion.

Unboxing

The device comes packed in a nice, custom-designed glossy colour cardboard cube-shaped box with wrap-around. The design follows a mostly blue-white-black-grey minimalist colour scheme, featuring the Fingbox itself and a run-down of the features and content of the box. The unit claims to be designed in Italy and assembled in Taiwan.

The box comes with seals on the front two edges to hold the box together and provide assurance that it is complete. Cutting these seals allows the inner section of the box to slide out.

It seems that Fing have made unboxing this device a bit of an “experience”. Underneath the top flap that has the logo …

… is the Fingbox itself. Removing the Fingbox shows that it was propped up above the blue silicone surround.

The only detraction is the slight tear in the cardboard box, which might be a result of some rough handling. Underneath that is the set-up guide …

… and finally, underneath that is the cables, plugs and power adapter. All of the cables are white in colour to match with the colour scheme of the Fingbox (a nice touch) and even the Ethernet lead is a rather un-common flat type for that “extra-neat” look.

So once fully unpacked and unwrapped, the whole package contains the following:

Looking at the underside of the Fingbox, it has the Australian Regulatory Compliance Mark, making it approved for use in Australia. The model number is FIN-B-001, with the shell featuring a conspicuous cut-out area for cable connections.

The rear port panel contains a USB A port (reserved for future expansion), a Gigabit Ethernet port (backwards compatible), a Micro-USB B power supply port and a reset button.

The blue silicone surround has a hole in one side to allow cables through and is thick enough to add some level of protection to the Fingbox against being dropped. It also does a nice job of hiding the cable connections for aesthetic effect which may also make it only ever so slightly more difficult to unplug. It also obscures the port activity LEDs and reset button on the rear of the unit.

The unit nestles nicely into the shell and the cables run out neatly from the hole. It looks rather elegant, almost like something you’d want to show off and, in some ways, similar in appearance to a smart-speaker.

The power adapter comes from Shenzhen SOY Technology, date coded Week 45 of 2017 with an efficiency level of VI. It does carry the Australian Regulatory Compliance Mark, making it appropriate for use in Australia. It is a regular 5V 2A USB power supply ending in a microUSB-B plug, the hard-wired cable being an advantage to reducing the number of connections that need to be made. The plug is easily changed to the Australian plug by pressing down on the dimple and untwisting the existing plug and doing the reverse with the appropriate adapter plate. The size of the adapter is also very sensible, being small enough not to obstruct adjacent outlets.

The flat pre-moulded Ethernet lead is a nice inclusion, rated at CAT6 and having all pairs connected to permit Gigabit Ethernet connectivity.

Methodology

In order to test the Fingbox, I set up an additional NAT-ed network behind my production network with access to the internet using an old TP-Link TL-WR740N (2.4Ghz, 802.11n, 1×1 in 40Mhz mode). This router broadcasted a wireless network with SSID ‘All_or_NoFing’ to which I connected my usual mobile devices. The Fingbox was connected to an Intel PCIe dual-Gigabit Ethernet card on my main PC, configured to transparently bridge into a LAN port on the rear of the TL-WR740N. Wireshark was used to observe the packets flowing to and from the Fingbox, recording .pcapng files for later filtering and analysis.

Setup of the Fingbox and testing was performed mainly with Fing App versions 6.7.1, 7.0.1, 7.0.2 and 7.0.3 on Android 5.1 and 7.0 as the upgrades were issued during the review time period, and also via the Fing Web App.

Afterward, the Fingbox was reset and moved over to my production network hosted by a Gigabit Ethernet port on a dual-band 802.11ac triple-stream capable AP for further testing. In total, the testing spanned a little over three weeks.

Initial Set-Up

The set-up guide included is an impressively simple and short guide. However, if this isn’t enough for you, there is also a full PDF user guide online.

Following this, setting up the Fingbox was so simple that almost anyone could do it. The note that it could take 15 minutes for first-time set-up was rather accurate, as it seemed my Fingbox was doing things “on its own” judging from its multi-coloured LED dance. This included contacting the back-end servers and performing its own firmware update, which proceeded without incident. In total, not helped by the variable-performing LTE-based connection I’m using, the initial start-up took around 12 minutes.

As I am a Fing app user and already had Fing installed, it was quite simple to add the Fingbox to my account. Even if you don’t have an account, getting the app and setting one up takes no more than a couple of minutes. As a result, I’d have to commend Fing for such a smooth and trouble-free set-up procedure. Once set-up, additional features are available within the Fing app and the settings can be manipulated if necessary (see following Feature sections).

The welcome e-mail provides additional inspiration to explore these additional features.

Overall Impressions

The Fingbox seems to be a rather unique blend of convenience and functionality. While the Fingbox does claim to be a Network Security and Troubleshooting device, it is not advertised as a firewall even though it can perform some of the features traditionally performed with a firewall such as being able to block a device from the network or from reaching the internet. Instead of being in the path of the Internet connection as a traditional firewall would be, it instead works with an existing router by being connected as a client via an Ethernet port. It’s capable of working on a single subnet and has its own wireless monitoring capabilities but is not an access point either. While it’s a client on the local network, it cannot be administered locally and relies on a cloud-connection.

This results in the Fingbox having several advantages and disadvantages. On the plus side, by being merely a client on the network, the device doesn’t inspect and will not have complete visibility of all the data travelling through to the internet for the most part. This is a good thing when it comes to privacy. It reduces the processing requirements on the device which also ensures that the device does not impede the performance of your internet connection. Compared to setting up rules on a router, the ability to access it from the app through the cloud “anywhere” even when you’re away from home is a benefit. It also works with most routers, so it can be used to add functionality to older or more basic units that don’t have more advanced blocking or monitoring functionality available and can be used even if you upgrade your network in the future. Finally, if you do something silly or the Fingbox is causing problems, it’s easy to unplug and check. On the downside, as it cannot inspect all of the traffic, so it isn’t capable of more advanced firewalling features. It can be disabled quite simply by unplugging it from the network. It is also not functional without an active internet connection and cloud servers and its protection is based on ARP spoofing/poisoning which is not entirely foolproof.

However, since it is marketed for mostly home and SOHO usage, ease of use and convenience is probably more important than absolute security. To that end, the app and the integration with the Fingbox focus on making network administration tasks easy. For example, new devices are defaulted to allowed access with a notification pop-up and e-mail for users to manually decide what to do with the device. On the plus side, aside from being a security device, the Fingbox offers a number of useful tools such as an Internet Speed test in case you suspect your ISP is having issues, Vulnerability Scan to check router settings, Wi-Fi speed test to confirm throughput and coverage, Bandwidth Analysis tool to check who’s hogging the bandwidth, Digital Presence to show who’s home and DigitalFence to detect nearby Wi-Fi devices. This adds value, especially in the home context, although more advanced features such as remote access to the network are unfortunately not provided and are instead marketed through the Domotz Pro agent and services.

In usage, I found the unit to be mildly warm and stable in operation, requiring no interventions, although the Fing app was a little sluggish at times. Administration of the unit can be achieved through the Fing app as well as the Fing Web App via any web browser. For additional peace-of-mind, the unit claims to have a two-year warranty and does not require any ongoing subscription fees. However, as with all cloud-connected devices, their lifetime is highly dependent on the lifetime of the company that supports them, so while the unit may last 5 to 10 years, whether the service will continue to run for that long is not known. On the upside, the unit is very much set-and-forget, with automated firmware updates ensuring that as Fing improves the functionality of the device, updates should happen seamlessly.

In my experience, while the unit does look good, the LEDs on the unit were not that useful. Depending on how you position your Fingbox, they may not be at a convenient location to view especially as the unit has to be below-eye-level on a desk to be easily seen and no wall-mounting options are provided. The different coloured blinking and chasing patterns are confusing at first but are fully detailed in the knowledge base. Luckily, anything important is normally notified via the app or via e-mail and the LEDs can be turned off or dimmed in case they are distracting.

Deactivating a Fingbox is also slightly less-than-obvious, but can be done through the networks list. I can confirm that once deactivated, it can be reactivated following the same steps as used initially to onboard the device – useful to know in case you’re changing networks.

In the following features sections, I will look at the key Fingbox features, how they work and give a more detailed opinion on their strengths and weaknesses.

Features: Network Scanning & Device Identification

Unlike the Fing app which launches a scan manually, having a Fingbox means that your network is scanned twice (ten seconds apart) every minute as shown in the excerpt below looking at ARP queries for a single address. These results are updated and recorded into your Fing account.

This allows you to have immediate visibility as to which devices are online, and the ability to perform the normal Fing diagnostics on each host. Additionally, there is now an event log which allows you to view historical information about events pertaining to that device, and the added internet pause/block device features.

If a new device is detected, a phone notification is generated and an e-mail notification sent to alert you to take action. By default, new devices are permitted to connect, until you choose to block them.

Additional useful abilities include sending alerts for status changes (good for ensuring always-online devices are up), associating devices with users (for Digital Presence), blocking/pausing access, scanning for services and wake up devices with Wake-on-LAN. There is also the ability to set auto-WoL to automatically send magic packets to a device if it is discovered to be offline to try and reawaken it – useful after a power outage. This feature seems to send five packets in every scan (60 second interval). Service scan lists can be modified in settings. Scan results can be exported as HTML, TXT or XML.

Enabling the device recognition features allows Fing to upload information and use their database to identify devices – thus allowing for a list of device names and MAC address/OUIs to be resolved into a device make and model. This isn’t always accurate, but the results can be rather interesting especially with DigitalFence data.

As Fing had been acquired by Domotz in 2016, the Fingbox now features the ability to install a Domotz Pro agent for paid remote device access and diagnostics, extending the features available to the Fingbox. This is accessible as the last option in the device page for the Fingbox in the discovery list.

Features: Pause Internet & Block Device

By clicking on a scanned device, you are able to either pause internet or block device. Pausing the internet access allows for the device to continue accessing other devices on your network, whereas blocking the device interferes with communication to any host on the network. Pauses and blocks can be scheduled to start and expire at certain times.

The pause internet feature works through ARP spoofing, convincing the target device that the gateway is instead the Fingbox, such that all traffic outside the network that should reach the gateway is instead routed to the Fingbox where it is discarded. This means that accesses to other addresses within the network would still complete successfully, however if your router is used to share storage or printers, an internet pause will often make these unavailable as well as they share the same address as the gateway.

The block device feature also works via ARP spoofing, but in a different way using gratuitous ARP which tries to convince everyone on the network that a given IP address (occupied by the blocked device) is at the Fingbox while also convincing the device that the main gateway is at the Fingbox, thus causing all traffic destined to and from the blocked device to be routed to the Fingbox and convincing the device that it is causing an address conflict.

These measures work relatively well against devices, although are not entirely bulletproof as detailed later in the Resilience section.

Features: Vulnerability Test

The vulnerability test feature allows Fingbox to schedule and run a remote port-scan of your connection and check your router’s uPnP settings to discover open ports and close them. As I was behind a multiple-NAT connection (carrier grade NAT + mobile phone tethering NAT + home router NAT + experiment router NAT), there was no way I could even have any open ports, thus the scan came up clean every time. There are some services online which offer to remotely scan your service ports, however, they do not and cannot deal with your local router’s uPnP settings.

Features: Internet Speed Test & Outage Monitoring

As the Fingbox is a cloud-based device, during its operation, it attempts to maintain an open socket to their server at all times. This puts it in an ideal position to monitor for internet connectivity outages, which it reports once it exceeds about five minutes.

Fingbox uses M-Lab as its internet speed measurement partner and due to the differences in server location, server availability and network connectivity, the results may differ slightly to those performed by other services. The speed test can be manually initiated from the screen or scheduled up to six times a day with a granularity of an hour. The test time is “randomised” within the hour to avoid synchronised speed tests and the limit of six tests per day is also likely to avoid overloading servers. As M-Lab has a presence in Sydney, I found that most of my speed tests corroborated well with my own experiences, although with occasional spikes in the data when the test server switched to Mumbai, India (possibly due to test server unavailability). A graph and averaged results are provided along with a full history, which is useful if you suspect your ISP is sub-par or there are issues with your connection.

The internet connection speed is also benchmarked by Fingpedia to provide a statistic as to how your connection compares to others. Sadly, mine isn’t doing so well …

A good feature is the ability to export reports via e-mail for your own records, which allow you to keep an independent record of the speed test and outage data. It would be nice if this could be scheduled.

Features: Wi-Fi Speed Test

The Wi-Fi Speed Test feature allows you to benchmark the speed of your Wi-Fi network between your mobile phone and the Fingbox. This is averaged over the length of the test, providing a bandwidth figure and an indication as to whether this is sufficient for streaming SD, HD or 4K material.

This is then stored in a history list, which unfortunately only records the time, result and device performing the test. It would have been much better if the log also stored a location identifier or there was a “floorplan” facility to draw up a floor plan and produce a “heat map” style diagram of coverage.

From the packet capture, it seems that the speed test is performed as a stream of UDP packets from the phone to the Wi-Fi AP which your phone is connected to, carried through to the Fingbox over Ethernet. This will usually result in a more conservative reading, as most phones support fewer spatial streams and have lower transmit powers compared to the access point.

As a result, it cannot be relied upon as a measure of the absolute speed that your Wi-Fi network is capable of, as this depends on the devices at each end, their sensitivity, the signal to noise ratio, their supported bandwidths and modulations, the number of spatial streams, etc. It is, however, a better measure of Wi-Fi coverage than just looking at signal levels, and as a result, I find this feature quite useful to verify that your placement of AP is adequate for achieving the required level of throughput in the areas where the network is to be used.

Features: Bandwidth Analysis

The Bandwidth Analysis feature allows you to select a number of devices to monitor to see how much data they are transacting during the monitored period. By default, bandwidth monitoring is not running as it requires data to be temporarily re-routed through the Fingbox through ARP spoofing which can affect internet performance. There seems to be a slight delay before any traffic is counted – due to the precious nature of my LTE quota, I didn’t actually use this feature much. Of note is that some routers do have their own data throughput statistics or accounting features which could provide similar data on a continuous basis.

Features: Digital Presence

The Digital Presence feature allows you to see graphically when certain users are at home based on the detection of their associated personal device on the network. This produces a line graph which indicates the presence/absence of that device on the network, with additional details visible in the Event Log. This feature worked fine, although this assumes that the user automatically re-connects to the Wi-Fi when they are in-range. At the moment, the graph does not seem to be zoom-able and each user is limited to just one portable device signalling presence (rather than multiple devices). The devices that can be selected for presence determination also seem limited to known portable devices.

Features: DigitalFence and Wi-Fi Attack Detection

The Fingbox’s DigitalFence feature promises to be able to identify nearby Wi-Fi devices which are switched on and determine when they are present, the patterns to their visit and how long they are around. This is likely based on using promiscuous mode on the internal Wi-Fi adapter and listening out for frames from active devices, such as beacons from APs, probe request frames from scanning devices that are not connected, association requests and data frames. With this, it can be possible to determine the MAC addresses of devices which are nearby with Wi-Fi switched on, whether they are connected or not. This is advertised as even capable of keeping track of a dog walker that comes by every day.

In practice, the DigitalFence feature works, but has its own limitations. For one, un-connected devices running more modern operating systems have now switched to anonymised probe frames using a random MAC address to improve privacy as such systems began to be used by marketers and others to track and collect “foot traffic” information. As a result, these devices will often result in a large number of anonymous detections which are not highly useful. Luckily, these can be filtered out.

Another limitation has to do with the accuracy of detection. Devices which connect over the 5Ghz band may be detected intermittently by their “scans” in-between connections, whereas those on 2.4Ghz tend to be more reliably detected. However, when looking at watched devices, the times when a device is visible to the Fingbox or not will depend on the signal strength, position of the Fingbox relative to the device and interference in the band. As a result, devices which are continuously online have appeared in the Event Log as coming in and out of range, while others are sometimes seldom detected and the times cannot be relied upon as being accurate compared to monitoring those that are connected within your own network through Digital Presence. This may have to do with limitations in monitoring multiple channels as well. As a result, if you want the DigitalFence feature to work as well as possible, it’s probably a good idea to install it up high in view of as much area as possible and not too close to your own AP (so that your own signals do not swamp out the weaker ones of interest). Of course, if the Wi-Fi radio in the target device is switched off, then it is not possible to use the DigitalFence feature to detect their presence.

On the upside, the DigitalFence has a set of useful filters which help identify devices that have been heard in range as well as keep an eye on them, which makes it easier to make sense of the data. This includes being able to exclude certain devices, SSIDs, limit by range (signal strength) or dates.

From what I can determine, there doesn’t seem to be a way to disable the DigitalFence feature in the app, in case you don’t want to be collecting this data for various reasons, as it may also interfere with the Wi-Fi attack detection. However, maybe having this option would be a good idea (especially due to the wording of the privacy policy).

The Wi-Fi attack detection feature was also of interest, so I decided to actively attack my own network to observe how the Fingbox responded. The first test was a relatively standard broadcast deauthentication, which was detected successfully. A targeted deauthentication was also detected successfully. In both instances, alerts were generated on the Fing app and an e-mail alert was sent, however the messages were somewhat lacking in technical detail (e.g. originating MAC, which could easily be spoofed). Unfortunately, there is no way that the Fingbox can defend against these attacks, so the unit merely serves as a warning that an attack is occurring or has occurred within the past 24 hours.

Stepping up the challenge, I also decided to test its detection of an “evil twin” by setting up another AP with identical SSID. This too, was detected and a warning was issued, this time with the evil twin’s MAC. In all cases, the detection time was variable, taking anywhere from three to five minutes before receiving the alert. The alerts are also listed in the app – although there is no way to dismiss them, if attacks do not continue, they will automatically be removed after a day.

However, attempting a reaver-wps attack did not provoke any response from the Fingbox even when the WPS of the router was locked by excessive attempts. This could have been detected and logged by looking at the WPS state information in the AP beacons.

Logically, the Fingbox will not protect against “passive” attacks which only require an attacker to listen (e.g. capturing the WPA/WPA2 handshake without forcing deauthentication for an offline attack) or an attack which originates on the 5Ghz band owing to a lack of 5Ghz radio in the Fingbox. The Fingbox could also be blind to very short attacks or geographically large and dispersed wireless networks. This is because the Fingbox may not be in range to hear the attack and the hardware (see Teardown) is really only capable of monitoring a channel at a time and thus needs to hop between channels.

Is the Fingbox Safe? Is it Secure?

Before trusting your network’s security to another device, it’s important to analyse the device’s operation to ensure it is safe to use and follows best practices for security. In order to do this, I analysed the packet captures and ran some tests to try and see how the Fingbox is configured, whether the protocols used are safe and how resilient it is.

DNS Resolution

During the course of operation, the device issued DNS resolution requests for the following addresses:

api.snapcraft.io
api.fing.io
api.orchestration.domotz.com
ntp.ubuntu.com
geoip.fing.io
signing.orchestration.domotz.com
fastly.cdn.snapcraft.io
messaging.orchestration.domotz.com
daisy.ubuntu.com
mlab-ns.appspot.com
neubot.mlab.mlab1.syd02.measurement-lab.org
ndt.iupui.mlab1.syd02.measurement-lab.org

The addresses observed will vary depending on where the Fingbox is located but suggest that the device may be running a version of Ubuntu (Core, possibly) and utilises Domotz, Snapcraft and M-Lab infrastructure. No unusual behaviour here, with the exception that during an internet outage, it seemed that the DNS got a little desperate and made some requests for:

api.fing.io.localdomain
ntp.ubuntu.com.localdomain

This doesn’t seem to be a good idea, as it could result in unintended redirection to local machines having those names, although whether this could be an issue depends on the design of the software on the Fingbox.

Connection Peers

By looking at a 24-hour packet capture, I filtered out all the local broadcast, multicast, ARP traffic on and found connections made to the following IP addresses (sorted by address):

The addresses are mostly as expected – some local addresses mainly due to uPnP traffic and a device of mine with two IP addresses on two subnets over the same interface, 216.58.x.x and 8.8.8.8 belong to Google (M-Lab servers), 52.x.x.x/54.x.x.x are Amazon AWS (Fing and Domotz back-end) and 91.189.x.x belong to Snapcraft and Canonical. Nothing too unusual to see here.

Protocols

Examining the packet captures, it seems that all communication to and from the Fingbox through the internet uses TLS 1.2. The only exception to this is the Internet Speed test through M-Lab which also uses ICMP packets to measure ping time and NTP requests for time. This should make the device safe to man-in-the-middle injection attacks and potentially even to impersonated servers if the certificates are correctly configured.

Locally, it does not seem that the Fing app directly communicates with the Fingbox. The Fingbox utilises UDP for Wi-Fi Speed tests, which is based on device upload to the Fingbox. Other than this, the Fingbox utilises ARP for its scanning and blocking capabilities, mDNS/DNS/SSDP to detect hostnames and services and is capable of service port scans as well. It uses DHCP to acquire a local address, judging by the Wireshark dissector, it seems to be using systemd.

Open Ports

A full port-scan was performed using nmap, the truncated and redacted results show that two ports were detected open – an SSH port and one for uPnP. While the port for uPnP is understandable for discovery and set-up, the SSH port seems a bit mysterious. According to some sources, it is not possible to log into this, but I would feel safer if it was closed altogether as apparently Domotz boxes do have an individually unique credential.

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 [Removed] (RSA)
|   256 [Removed] (ECDSA)
|_  256 [Removed] (ED25519)
1900/udp open  upnp?
| upnp-info:
| 192.168.0.101
|     Server: FingBox v1 UPnP/1.0
|_    Location: http://192.168.0.101:44444/fingbox/FingBox.xml
MAC Address: F0:23:B9:XX:XX:XX (Ieee Registration Authority)
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
TCP Sequence Prediction: Difficulty=260 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Resilience

Unfortunately, the Fingbox loses some marks when it comes to resilience. By leveraging its own ARP spoofing technique, it was possible to convince the Fingbox to route its internet traffic through another computer, thus cutting off internet access to the Fingbox. While the Fingbox does continue to scan the network and otherwise maintain any active function (e.g. blocking) at that time, it is unable to be configured locally or remotely when under this attack. A little ironic, I’d say, as it may be possible to defend against these attacks by recording/restoring known-good ARP results or creating a static ARP binding entry once the gateway is discovered.

The Fingbox is also a little confusing, as its interesting LED lights and colourful modern design make it both eye-catching and an ideal candidate for placing somewhere easily visible, but this also lends itself to potentially being tampered with or unplugged. The network and internet blocking features depend on a periodic injection of forged ARP packets to maintain the blocked status, thus simply by removing the device and waiting for the ARP tables to be “naturally” repaired (or by disconnecting/reconnecting the device to force new ARP packets on the network) any blocked device will regain access to the network. I suppose this can be a disadvantage compared to integrating these functions into an integrated gateway device where it would not be possible to “unplug” the device without losing access entirely.

Further issues could arise noting the hardware design in the teardown section which suggests it could be amenable to physical tampering with modified firmware (assuming over-the-air updates are correctly secured), with the integration of the wireless radio potentially providing a path for out-of-band data exfiltration over a moderate range. This possibility has not been directly investigated.

Even at the per-device level, there are defensive measures that can be taken by more advanced and persistent network intruders and block evaders, such as static ARP binding to protect against forged ARP packets and MAC spoofing to try and evade existing blocks or impersonate approved devices. By default, new devices are permitted to access the network until blocked. While some other conventional network protection technologies are also vulnerable to MAC spoofing, ARP binding would render the Fingbox rather ineffective and could explain part of the reason why it does not work with a small number of routers.

That being said, the Fingbox was stable throughout the test period even under my meddling and did not need any interventions such as a reboot, which is a good thing for placing it in premises which may be remote and normally unattended.

Policies

For the most part, when it comes to these appliances, we have to take the manufacturer’s word when it comes to what is being done with the data. Fing’s Privacy Policy is available online and claims not to resell or otherwise reuse any collected data outside of providing the service. They also summarise their security measures which consists of a number of layered defences and implementation of best practices. For registered Fingbox users, the collected data (excerpted from their policy) includes:

  • Technical information, including the IP address used to connect your device to the Internet, your login information, browser type and version, time zone setting, browser plug-in types and versions, operating system and platform, type of device;
  • Information on MAC addresses and Wi-Fi networks you collect through the App or the Box. Please note that this Privacy Policy does not exempt you from any obligations you may incur should you collect individuals’ personal data.
  • Information about your visit, including the full Uniform Resource Locators (URL) clickstream to, through and from our site (including date and time); Networks viewed or searched for; app response times, download errors, length of visits to certain pages, app interaction information (such as scrolling, clicks, and mouse-overs), and methods used to browse away from the App.

Fing also reserves the right to combine this data with information from third parties. This in itself seems to be quite a lot of data and could be potentially troublesome for individuals (e.g. with the Digital Fence feature) if it were to be found to be breaching local laws due to its data collection. Google did fall afoul of this in the past as they collected more than just the Wi-Fi packet metadata – without knowing exactly what the Fingbox does, it would be hard to know if we comply with any legal obligations as it might unintentionally collect “private” data from passers-by, neighbours, etc. This could also be problematic if you run scans on public networks.

Additionally, Fing also has a Terms of Service document which seems mostly standard boilerplate material, although confusingly, the section on Limited Warranty for hardware seems to list the warranty as being 12 months rather than the two years claimed on the product page. Maybe this is a recent change.

Bandwidth Consumption

Because the Fingbox relies on a cloud infrastructure, some users with restrictive bandwidth limits (such as myself on mobile LTE broadband) might be worried about bandwidth consumption. With a transparent Ethernet bridge, I was able to capture all of the packets heading to and from the Fingbox for analysis.

Most of the traffic from the Fingbox is local in nature – ARP requests and responses, multicast/mDNS queries, etc. These types of traffic do not leave your local network and do not consume any bandwidth from your ISP, so it is excluded from the analysis.

The traffic that does count include the update of the state data on Fing’s servers and those of the Internet Speed feature which produces traffic to and from your nearest M-Lab server. Taking a 24-hour packet capture and filtering out all ARP, multicast and local-subnet traffic while running six bandwidth tests a day (maximum) resulted in a .pcapng packet capture file of 185MB. The actual traffic is probably slightly less due to the overhead of the packet capture file.

Filtering all the traffic to the M-Lab servers used resulted in a .pcapng file of just 5.5MB over the same period. As a result, running the Fingbox alone without the Internet Speed feature does not consume significant amounts of bandwidth quota from your ISP, although this may vary depending on the size of your subnet, the amount of configuration actions taken, the number of devices discovered, the number of devices nearby detected by Digital Fence, etc. All in all, this seems quite efficient.

If you’re also worried about background traffic on your internal network, assuming you’re running a regular /24 subnet as most residential customers would, the scans run twice separated by 10 seconds every minute. The observed rate was about 27.7 ARP packets per second at 60 bytes captured per packet yields a net of 1.662kB/s of data during the scan period. This can be reduced in the Fingbox settings, but as this didn’t cause me any problems, I did not try it. The downside to broadcast ARP scans is that it could impact on the battery life of Wi-Fi connected devices, bringing them out of sleep mode more often to reply to ARP packets. This may be the reason why scans are run twice in every minute period to ensure ARP replies are not missing, but its secondary function is to ensure device ARP tables are always refreshed so to ensure blocking and unblocking occurs relatively promptly.

Power Consumption

As the Fingbox is a network appliance, it’s best left on all the time. Users might be wondering just how much power the Fingbox consumes. Using my Tektronix PA1000 Power Analyzer in IEC Standby Power qualification with a synthetic 230V pure-sine-wave supply shows that the active power consumption averaged over 15 minutes is steady at around 2.7W. This isn’t particularly high.

In a year, the unit will consume just under 24kWh of energy, at the market electricity price of $0.32/kWh, it costs just AU$7.68 a year in power bills to run. Of course, this will vary depending on your energy provider and discounts provided. Alternatively, you could turn the Fingbox off when it’s not needed without taking down your network, but you will lose all functionality while it’s powered down.

Note that as the device is active during the test, it’s not expected to pass the test. The use of the test mode is only used to permit time-averaging of readings and determination of power consumption trend.

Unit Teardown

The curious (including myself) would always like to know what’s inside the devices that we own, so that we can better understand how they work, how they have been designed, how they can be modified and whether there are any security or safety issues. To open the Fingbox, three Torx screws must be undone using a long-barrel screwdriver to separate the casing.

The top part of the case is, in itself, an assembly held together by one screw. The assembly consists of the top logo section, a clear plastic light-pipe section that routes the LED light from the PCB to the ring around the logo and a black plate which prevents LED light bleed.

The bottom half contains the main PCB, which is about two-thirds of the footprint. Interesting features on the board include the presence of three buttons, labelled Power, Reset and Uboot. This suggests maybe that the device is using Uboot as a bootloader and can be convinced to load other builds of Linux. There seems to be a footprint for a memory card that is not populated. Next to this is an NXP PCA9635 I2C-bus controlled LED driver. The majority of the remaining components are LEDs, MOSFETs, capacitors, resistors, an oscillator and a number of unidentified 5-pin SMD components. There is also a label with the Ethernet and Wireless MAC addresses, along with a QC label.

Below the PCB, there is an antenna for the onboard Wi-Fi chipset (in black) which is used for the DigitalFence feature.

From the top-side, we can see most of the components. A low-profile SG24301G transformer for the Ethernet can be found next to the Realtek RTL8211E Gigabit Ethernet Transceiver. This is next to an AXP8036 Power Management IC which supplies power to the CPU. The wireless chipset is a soldered-down Atheros AR9271-AL3A-based USB 802.11n 1×1 802.11n module, with a connector used to attach the antenna. This particular chipset is one of my favourites, as it’s highly featureful (e.g. promiscuous mode), low-cost, relatively reliable and well-supported by ath9k_htc in Linux. I suspect why there isn’t a 5Ghz-capable Fingbox (yet) is that it’s not easy sourcing chipsets which are well-supported for these features, has good sensitivity, is dual-band capable and still in production – as my ventures with different current Mediatek and Realtek chipsets have shown. The antenna connector is supported by tape to prevent it from working loose in transit. The main Flash memory is a Samsung KLM8G (1GiB) eMMC, with two K4B4G1646E-BCMA DDR3 1866Mhz CAS13 memory chips for a total of 1GiB of RAM. Additionally, there is an Atmel 24C02N (256kiB) I2C EEPROM, along with a few unidentified smaller SMD ICs which are likely to be power related. There is a fitted three-pin header which appears to be a UART connection with the pins labelled.

On the top edge of the PCB, we can see a vertical USB-A port, a RJ45 connector, a microUSB-B connector with additional bracing for strength and a button labelled Recovery (externally labelled Reset). While the port itself is not used in the normal operation of the Fingbox and is listed as for “future expansion”, it may be involved in the initial firmware loading onto the eMMC.

The heatsink is adhered onto the SoC using thermal tape. The identity of the chip is an Allwinner Technology H3, an SoC from a Chinese manufacturer that features a quad-core ARM Cortex-A7 with Mali 400 MP2 GPU. The SoC was originally intended for the 4K over-the-top set-top-box market, but has found its way into a number of single-board computers for hobbyists as well.

In summary, the design is rather well-thought-out and its screw-based construction makes it easy to open and repair if necessary. The addition of bracing to the microUSB port should improve the robustness and the heatsink on the SoC should improve reliability and lifetime. The PCB markings seem to suggest that if the Fing service was to be discontinued in the future, the device might be amenable to being repurposed as it shares some commonalities with other single-board computers used by hobbyists. This is a double-edged sword, as it could also mean that the device might be able to be tampered with given physical access to the buttons and ports. That being said, I haven’t tried this myself.

Conclusion

The Fingbox seems to be a rather unique blend of aesthetics, functionality and convenience. It is a rather elegant unit which is extremely easy to set-up and use, offering a number of firewall-like abilities such as blocking devices from the network or the internet, as well as a number of useful tools to record user presence, diagnose network connectivity performance problems, security vulnerabilities and detect nearby Wi-Fi devices and Wi-Fi attacks. It does this without inspecting all of your traffic and without slowing down your internet connection. As a cloud-based unit, it offers set-and-forget functionality, keeping itself up-to-date automatically and requiring no ongoing subscription fees. The flexibility of being able to use this device with almost any router and being able to keep its functions even if you upgrade your network is a plus. Because of its cloud-nature, network administration can happen anywhere as long as you have your Fing account and either the Fing app or access to the Fing Web App via a web browser. The unit itself is backed by a two-year warranty and judging by the internals, is relatively well built.

However, because of its reliance on ARP spoofing for its blocking and traffic redirection abilities, the security offered can be bypassed with some effort and unplugging the unit would render any protection disabled. The continuous network scanning results in a slight increase in broadcast traffic load which may affect the battery life of sleeping Wi-Fi devices. The unit does not have a 5Ghz Wi-Fi radio and is not capable of perceiving threats or nearby devices solely on the 5Ghz band. The default behaviour to accept newly discovered devices until manually blocked also makes the unit ineffective against persistent attackers. The limitation of working only on a single subnet also means the Fingbox may not be able to work with users connected to router-provided “guest” networks where they are on a separate subnet. However, in most home and SOHO contexts, these observations may not be a major issue, as the number of users is often quite low and the devices are mostly trusted. While some of the tools may lack completeness, the Fingbox should continue to receive updates and improvements throughout its lifetime, provided the manufacturer continues to provide the service.

As a result, despite its limitations, the Fingbox is still a highly convenient, useful and valuable tool that I intend to keep running on my production network. If it even saves me once from having to run home to boot-up a box or stops a single device from consuming my monthly LTE quota remotely without having to physically unplug a cable or change my router’s settings, it would be worth it. Just having that constant vigilant eye on the network letting you know about new devices or giving you alerts when certain devices go down is especially invaluable when your network is used for more than just computers and phones – for example, in a modern smart-home, knowing when your surveillance cameras or NVR/DVR goes down could be quite important.

Many thanks to Fing for providing such an interesting device for review. Users interested in getting a Fingbox for themselves can do so through the official Fing website where there are occasional promotional discounts, by clicking the button inside the Fing app to shop via Fing or Amazon or by buying through a reseller. At the present time, it is listed for AU$189 for Australian customers.

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing, Telecommunications and tagged , , , , , , , . Bookmark the permalink.

One Response to Mega Review: Fingbox Network Security and Troubleshooting Device

  1. sparcie says:

    I’m unsure how I feel about a device like this. If you understand it’s limitations and what it can and can’t do it does have some features that could be useful, but I worry about many end users not understanding. They may assume it’s providing much more protection than it really is and become complacent.

    I’m not a big fan of it using ARP spoofing/poisoning to perform it’s function. Future measures to prevent these types of attacks could defeat the functionality of this device. It’s also not really going to keep any experienced attackers out as they’ll be able to defeat it.

    I must be getting old, cloud based devices don’t appeal to me at all. I don’t like devices that could die simply by a company pulling official support, and have the potential to collect serious amounts of data about users either from the start or after a firmware update.

Error: Comment is Missing!