Prevent Brute Force Hacking Attempts

I'd like to prevent brute force password hacking attempts against my Indigo Server instance. My feature request is to implement (temporary or permanent, configurable) IP address blocking in Indigo Server after X (configurable) number of failed login attempts. I assume this isn't a highly requested feature, but I don't think the average user is well versed enough in network or application hardening to know to ask for this. Even so, it's the responsibility of the Indigo team to ensure their users are as secure as possible, especially for home automation software. I don't say that to be critical of the Indigo team or the product, I know there are quite a few things that have been done to make the software secure and I very much appreciate that effort. But brute force hacking is an easily executed attack that can be done by any script kiddie, and implementing IP address blocking can reduce the that risk to an acceptable level. By taking it a step further by making the block duration and failed attempt count configurable, users can decide what settings make the most sense for them and their level of risk tolerance.

My setup is using port forwarding with an Apache reverse proxy for remote access, not a reflector. I acknowledge that it's possible that using the reflector service could mitigate (or completely eliminate?) this risk, but the reflector service is a "black box" to me, and I won't use services for home automation that I don't control unless I absolutely have to.

Currently, Indigo Server logs invalid access attempts when they're detected. For example:

Code: Select all

access denied "http://10.0.0.12:8176/" from admin @ 1.2.3.4


This is useful if you're viewing the Indigo logs in real-time and are ready to ban the IP address manually at your gateway, but the reality is that the log entries only show you past attempts at logging in by an attacker.

I understand that there are other options available to block IP addresses when certain criteria are met, such as fail2ban. I enabled fail2ban on my Apache server to catch HTTP 401 events and block the offending IP address. This works well, but it immediately blocks my phone's public IP address as soon as I try to use Indigo Touch. In this scenario, I'm logged into Indigo Touch with a valid user and password, but fail2ban is blocking my IP because it appears that the app frequently triggers an HTTP 401 request with every other request that's sent to Indigo Server. Here's an excerpt from my Apache log that's being matched by fail2ban:

Code: Select all

my.phones.public.ip - - [01/Mar/2020:09:04:30 -0500] "POST /serverrequest HTTP/1.1" 401 6744 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"
my.phones.public.ip - - [01/Mar/2020:09:04:31 -0500] "POST /serverrequest HTTP/1.1" 200 727 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"

my.phones.public.ip - - [01/Mar/2020:09:04:34 -0500] "POST /serverrequest HTTP/1.1" 401 6744 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"
my.phones.public.ip - - [01/Mar/2020:09:04:34 -0500] "POST /serverrequest HTTP/1.1" 200 727 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"

my.phones.public.ip - - [01/Mar/2020:09:04:37 -0500] "POST /serverrequest HTTP/1.1" 401 6744 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"
my.phones.public.ip - - [01/Mar/2020:09:04:37 -0500] "POST /serverrequest HTTP/1.1" 200 727 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"

my.phones.public.ip - - [01/Mar/2020:09:04:40 -0500] "POST /serverrequest HTTP/1.1" 401 6744 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"
my.phones.public.ip - - [01/Mar/2020:09:04:40 -0500] "POST /serverrequest HTTP/1.1" 200 727 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"

my.phones.public.ip - - [01/Mar/2020:09:04:43 -0500] "POST /serverrequest HTTP/1.1" 401 6744 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"
my.phones.public.ip - - [01/Mar/2020:09:04:43 -0500] "POST /serverrequest HTTP/1.1" 200 727 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"

my.phones.public.ip - - [01/Mar/2020:09:04:46 -0500] "POST /serverrequest HTTP/1.1" 401 6744 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"
my.phones.public.ip - - [01/Mar/2020:09:04:46 -0500] "POST /serverrequest HTTP/1.1" 200 727 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"

my.phones.public.ip - - [01/Mar/2020:09:04:49 -0500] "POST /serverrequest HTTP/1.1" 401 6744 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"
my.phones.public.ip - - [01/Mar/2020:09:04:49 -0500] "POST /serverrequest HTTP/1.1" 200 727 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"

my.phones.public.ip - - [01/Mar/2020:09:04:52 -0500] "POST /serverrequest HTTP/1.1" 401 6744 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"
my.phones.public.ip - - [01/Mar/2020:09:04:52 -0500] "POST /serverrequest HTTP/1.1" 200 727 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"

my.phones.public.ip - - [01/Mar/2020:09:04:55 -0500] "POST /serverrequest HTTP/1.1" 401 6744 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"
my.phones.public.ip - - [01/Mar/2020:09:04:56 -0500] "POST /serverrequest HTTP/1.1" 200 6647 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"

my.phones.public.ip - - [01/Mar/2020:09:04:58 -0500] "POST /serverrequest HTTP/1.1" 401 824 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"
my.phones.public.ip - - [01/Mar/2020:09:04:59 -0500] "POST /serverrequest HTTP/1.1" 200 6647 "-" "Indigo%20Touch/2.1.2 CFNetwork/1121.2.2 Darwin/19.3.0"


I've grouped them together to show how the requests come in as pairs in regular intervals. In this instance, the Indigo Touch app was open and showing the Control Pages view, but I wasn't interacting with it, which make me think these logs are a result of a polling mechanism, presumably for reachability checking. These constant HTTP 401 responses make it necessary to define a custom jail in fail2ban to exclude requests from Indigo Touch. This technically works, but an attacker targeting Indigo Server could pretty easily figure out how to masquerade as the Indigo Touch client in the request so it could bypass the fail2ban regex that's been put in place. The other issue is that this configuration is somewhat fragile, and will break if anything changes with the Indigo Server request URL or Indigo Touch user agent string.

If IP address blocking can't be built into Indigo Server, then my fallback feature request is to prevent the Indigo Touch client from triggering frequent HTTP 401 responses even when the user is logged in, which will allow the use of fail2ban to prevent brute force hacking attempts.

Why don’t you just drop the port forwarding and use a VPN? Then you have complete control.

[matt (support)]

Reflectors help avoid the problem a bit through obfuscation, in that no where are reflector subdomain names published and if always accessed via HTTPS the reflector subdomain can remain a secret only your devices know. That in combination with a reasonably difficult password should give good protection.

We do have on our request (and ToDo) list a big overhaul of Indigo's built-in Web server. At that time we will be investigating the security model and will likely be improving things and considering new functionality.

Thanks for the update, Matt. It sounds like you guys have got this on your radar.

Why don’t you just drop the port forwarding and use a VPN? Then you have complete control.

I chose not to use VPN because I didn't want to have to manually connect to it before I can use the Indigo Touch app. But, as I was thinking through my response to your comment, I realized that if my company can enable on-demand VPN, then I probably can, too. Fast forward a week or so and I've got an on-demand VPN connection from my phone using OpenVPN with rules to connect to VPN for specific domains if I'm not on my home network. It's not perfect, and I may hit some limitations if I want to transfer a significant amount of data since it's not hardware-offloaded on the server side, but it's a seamless setup that means I don't need to worry about starting/stopping a VPN connection. Thanks for the hint! This definitely a more secure solution than port forwarding.