Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Sunday, April 2, 2017

Review: August Doorbell Camera

El Doorbell Del Diablo
Update: After replacing the August Doorbell with a Skybell HD, and having just as many problems with the Skybell, we switched to Nest Doorbell Cam and have had no problems.  The only thing worse than security that doesn't work, is security that sometimes works - because you can't trust it.  Spend the extra money and buy quality security equipment.  Trust me on this...

Last year a friend bought two "smart" doorbells for his home, and decided to keep the one he installed first.  So for a discount, I was able to pick up an August Doorbell Camera.  What followed was a journey lasting several months, ultimately resulting in me buying a different product.

I loved the idea of smart doorbell.  Living in a city which due to budget issues and a pension crisis has only 2/3rds of the police officers it needs, and with my wife such a fan of online stores for everything, we're careful about quickly pulling in mail and packages.  Research has shown that burglars will almost always ring the doorbell before attempting a robbery, so if you can appear to be home - they'll move on.  That, and our very large dog, seemed like a good strategy.

I installed the August Doorbell Camera in August 2016, and immediately began noticing issues with it.  Switches on the smartphone app were not properly synchronized between Android and iOS - in fact in some cases turning a switch ON in Android resulted in the switch being OFF in iOS and vice-versa.  I found that when changing a setting in the app the change wouldn't always register.  The device wanted a -60 dBm Wi-Fi signal - which an RF-savvy person will tell you is really hard to get unless you're practically right on top of the access point.

More than anything else my frustration was with the inconsistency of operation.  August Tech Support (which from what I can tell either isn't located in the US or they keep really odd office hours) would often remotely reboot the device and it would work for a day or so, then begin failing.  What's worse than something that doesn't work?  Something that works intermittently.  I'd get a motion or doorbell ringing alert - and the video file would show "unavailable".  Or I wouldn't get the alert.  Or I'd get the alert but be unable to remotely answer the door.  I never knew what to expect.

I gave up on the August Doorbell Cam on March 31st 2017, over seven months after installation.  During that time I exchanged countless emails with them - easily over 100 total.  To their credit, they tried to help - I received two replacement doorbells, including one after the doorbell just completely gave up and refused to reset or connect to anything.  I never felt I could rely on the device, and in the end I wanted that reliability.

Monday, November 28, 2016

Build a (fire)wall and make China pay for it

I've been gradually building up a Raspberry Pi for use in my shack, and I've also been experimenting with a home control and security systems hosted on Pi platforms.  To be really useful, a home control system needs to be accessible from outside my home, and a remote radio setup would also be nice.  This has led me down a path of learning about how to conveniently but safely expose ports on my Pi platforms to the internet.

At any given moment, there are thousands of attackers active on the internet.  If you expose ports like TCP 80 (web server), or TCP 22 (ssh) you will be attacked, likely within minutes.  These attacks range from sophisticated hack attempts carried out by state-sponsored security teams, to teenagers running automated scanners that look for obvious weaknesses like unmodified default passwords.

Most attacks try to leverage brute-force methods - they start with a presumption that the superuser login is "pi" (the default) and work through a list of obvious passwords like the default "raspberry", or "pi", or "password", or "123456", etc.

Presuming you've changed your superuser password (and ideally your login name) an easy method to add security is to implement fail2ban.  The fail2ban method tracks failed login attempts over time, and if the same IP address fails more than X times within Y minutes, that address is then added to a ban list in iptables.  If your password is non-obvious, this works fairly well.  The problem is that, without additional setup, iptables exist in memory and are wiped on every reboot.  And because they exist in memory, you'll ultimately waste Pi resources trying to exclude billions of IP addresses.  It's possible to preemptively ban ranges and subnets of IP addresses, but you're still talking about nearly 8,000 entries just for a single country like China.  Also; fail2ban only works if someone actually attempts a login - it does nothing about attackers who probe connections without logging in.

The reality is, the number of IP addresses from which I want to allow connection is very small, and (unless I'm traveling) they're all US-based.  So the trick is to only allow connection from IP addresses originating in the US.  Turns out this is possible using GeoIP and some scripting.  The GeoIP method uses a file database of IP address ranges listed by country.  When an ssh client connects, their IP address is compared with the database.  If the IP address is not from the US, it refuses the connection.
I still run fail2ban, to handle any US-based attackers, and to deal with any non-ssh traffic.  Let me know in comments if you use GeoIP for security, and what you think of my strategies.