I agree. I understand that the hub is Linux based so would be good to be able to trigger local shell scripts, then anything is possible.

@anton said in Flic hub network security:

Hello, I am one of the developers of the hub.

Thanks for your time to look at his.

First of all I would like to ask what kind of technique you are using to decide if a UDP port is open or closed?

nmap -sS -sU -T4 -A -v -PE -PP -PS80,443 -PA3389 -PU40125 -PY -g 53 --script "default or (discovery and safe)" flic

UDP is connectionless so by design they don’t really behave like TCP when doing port scans. With TCP you often either get a Connection Reset response or no response at all if you try to connect to a closed port, at which point you can assume that the port is actually closed. With UDP it does not work like that since you are not guaranteed to get a response in either scenario. And even if a port is temporarily open it does not mean that you actually have a service on the other side listening.

I seem to remember that tools like NMAP use ICMP responses to decide if a UDP port is open (correct me if I’m wrong). But this generates a lot of false positives since a lot of ports are not really bound to a permanent service, but rather temporary ports used by both the Linux OS (DNS requests, NTP requests, etc..) and our host application for different features (like action executions etc). This is normal UDP behavior and not an indication of a security flaw.

Hence the question. It is hard to determine why a UDP port is open so I was interested to find out what should be listening and why.

I am not suggesting that I have found a flaw, just the potential to discover one and without some background on what the hub does, it is is guesswork at this point. I usually only work with Open Source and in that case, I can work it out for myself but as far as I know, the flic hub code is hidden so only people on your team can investigate.

The note about amplification attacks relates to services where a small request can be sent which creates a large response (see https://www.us-cert.gov/ncas/alerts/TA14-017A).

The assumption is that most flic hub users are not security experts therefore it is the responsibility of the device supplier to make sure that the user cannot be exploited. Many IoT vendors are also not thinking about security and the overall outcome is an unsafe and unreliable internet and this is what is behind my question.

@sawtaytoes said in Running custom apps on the Flic Hub:

I think you're onto something @stuart. I could see where that'd be useful. You'd still have to have a centralized server for your configuration settings, but you'd manage that yourself and the Flic hub is literally just that, a dumb hub. No matter what happens to any button, it sends an HTTP request in a specific format to a certain address. That gives you all the power you need, and you can control everything from a Raspberry Pi or even an ESP8266.
In this way (provided I understood you), you lose the Flic app connections to 3rd party manufacturers and have to roll your own solutions.

Yes, that is exactly what I am proposing.The solution I have set up consists of a hub with 8 buttons, each configured with a URL which calls the micro-service using the URL noted before. Then te hub is essentially dumb and I can run what I want. It would be ideal to run this simple web service as a docker within the hub as that provides the security that Flic want whilst giving me the flexibility to do what I want.

For now I am running the prototype on a VM but will probably move to a container if I start to use it for anything important.

I have my own solutions too, but I'd prefer to do everything through the official app (provided I'm understanding you). I'm sure that's the intention on Flic's end as well. My friends and family wouldn't be able to use a Flic hub and do the same things as me if they have to flash a Raspberry Pi with my own custom software that they now have to maintain.

Yes, but once you have set up the micro-service to run some scripts, there is no reason that this would need maintaining if the requirement doesnt change (depending on your coding skill level). Users could easily share their own scripts and recipes as well.

A significant benefit of this is that it will still work even if you have no internet connection.

I can share the micro-service on Github if you like. It is rudimentary but works and is easily extensible.

Because of the current limitation of mobile-only configuration; why not allow uploading a JSON config file? I can generate these in any programming language and maintain them on GitHub instead of having to put them all individually in the Flic Hub; otherwise, this is going to be completely unusable.

This would work in some situations but I would want to create my own arbitrary script files to do whatever and JSON would be too restrictive. But for my prototype web-service, it would be easy to implement such a facility.

I've written about the scaling issue here:
https://medium.com/flicblog/controlling-iot-devices-with-the-flic-of-a-button-1349c81bddef

I think for this first iteration, scaling the number of buttons is something power users are going to be doing. In the future, that shouldn't be the case, but for now, it's something only affecting folks like me with whole house solutions and 40+ buttons. That's the intention right? Or am I using them in a strange way?

The web-service prototype would also enable as many hubs as you want so you have effectively infinite buttons. See the proposed URL - specifies hub as well as button and action.
(This could just as easily be a JSON string instead of a GET)

I'd like a way to actually use the hub, but I don't know if I'll be able to with its current software as I've detailed here:
https://community.flic.io/topic/17298/feature-request-flic-hub-and-app-enhancements-for-scale

Responding so some of your points, to test the web-service, I have presented a simple web page so I am able to execute the same action as if I had pressed the button. Of course, you could call the URL from one of the many Android apps that just send web requests. I had thought about how access is restricted so it would be easy to add API tokens or authentication to ensure only the right people can do the things.

I agree that some more Flic config (debouncem triple click etc) would be useful; to enable better tuning in.

To be able to create a programmatic response to flic actions from the hub, I have created a quick http listener that takes a query string and lets me run whatever scripts I want on another computer.

This takes a get request as follows:

http://flic-hub-listener/actions?hubname=one&flicname=one&action=click

The issue is that I have 4 flics on one hub, each with 3 actions therefore I need to paste a modified action in 12 times to make this work.

As mentioned in my earlier post(https://community.flic.io/post/18066) it would be much easier if I can create actions for all buttons on the hub, for example a URL with variables for hub name, flic name and action like this:

http://flic-hub-listener/actions?hubname={hub_name}&flicname={button_name}&action={button_action}

This will be much more robust and easier to manage for those of us who want to build their own scripts with the hub instead of using the supplied apps. These variables may be a benefit to other apps as well.

So I had about 10 hours from the battery pack FYI.

A flic has a battery built in but the hub doesn't.

If you want the hub to run without mains, you can run it from a USB mobile phone power bank that delivers enough current (I am using http://www.storkz.com/puridea-s5blunewus.html).

It should do a day or two, I will post back when mine runs out.

@oskar A further thought would be to set up an action for all buttons on a hub which calls a URL with variables to indicate which button and trigger. For example, this would enable me to construct a URL like this on the hub itself (not per button):

https://my-listener/{button_name}/{button_action}

This would simplify management and just require a button adding without having to fiddle with the settings for each one.
As a developer, this would make it easier and more reliable to run arbitrary scripts elsewhere.

Otherwise I may be better off just using an RPi 3 as described here: https://community.flic.io/topic/10/flic-for-pi3

@oskar - do you have any thoughts on this?

Thanks @oskar

I am using a WileyFox Swift 2 Plus (Android 7.1.2) device.

I have tried resetting bluetooth on the phone to no avail therefore applied the user data reset but a phone reboot was what ultimately resolved the issue.

I will post back here if I have further related issues.

My hubs arrived yesterday. I have set one up, updated it to 1.1.0 through the mobile app, configured wireless and attached one flic. The indicator light was amber.

After switching off and on, I could not access it and the indicator light is red. I have connected wireless and wired, same result.

On the mobile app, I have removed the hub and tried to re-connect, the app detects the hub, asks for the password from the base of the device and after a couple of minutes from pressing connect,the message "Connection timed out" appears.

I have tried pressing the reset button but this makes no difference. I am unsure of the exact reset process as it doesn't seem to be documented anywhere so just tried pressing it for a few seconds whilst switched on.

Can you clarify what the correct process is to re-set a flic hub?

Thanks @oskar

There are a few ways to achieve this but there are some challenges that we need to get past first. Right now the hub is only configurable using mobile apps, which can be quite limited if you want to write custom scripts.

Config via mobile - A web interface on the hub would be an advantage. You could use a variation of https://github.com/openwrt/luci/wiki which is a lightweight, fast and robust interface. It has the advantage that you can add functionality as you go without having to think of everything at the start which works well for a developing product.

There is also the security aspect of letting hardware on a local network execute arbitrary code.
We are currently trying to figure out a way to make this available in an easy-to-use way while maintaining a secure platform.

Security is an issue and more prevalent in IoT as many users do not have the knowledge of the issues and generally end up with convenience which is almost always at the cost of security. (I posted a separate topic about security yesterday)

Thinking about the Flic Hub security, you could run arbitrary code in a docker which prevents any of the code affecting the base hub. It also creates a situation that the docker image can be exported and shared with others, creating lower-level apps with more power. As a point of reference, AsteroidOS have containers on smart watches (https://asteroidos.org/).

Regarding network security, either a user manages this by deploying another device on their network which if anything creates further risk, or the user posts to an external server which has it's own implications. So from a user perspective, having one device to run the code is likely to be less risky than the other options.

SJM