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.
Monday, November 28, 2016
Wednesday, September 14, 2016
Nexus 6 Review: Wi-Fi Done Right
I've been a Droid user for many years. Started out with the Droid 1 then onto a Droid 2, Droid RAZR Maxx, Droid Ultra, a very short-lived and painful experience with the Droid Turbo, then a Droid Maxx which is essentially a slightly fatter Ultra with more battery. When my battery's capacity started to run short, I started looking at other phones. I decided to get a Nexus 6 (unlocked from Amazon) when Google announced that they would roll out Wi-Fi Assistant to all Nexus phones.
Wi-Fi Assistant was originally a Google Fi feature that applies a VPN to open Wi-Fi access points - without user intervention. In fact, Wi-Fi Assistant is now (once you have the Play Services 9.6 update) capable of securing all open Wi-Fi, even ones where you manually connect. This is a huge move by Google that will hit the cellular carriers hard because if I'm able to use public Wi-Fi with confidence, and my phone is latching on to open Wi-Fi by itself - why do I need a large data plan?
This all takes Wi-Fi a step closer to being a viable alternative to cellular data, although there are still many issues. The problem is that managing a Closed SSID network is painful and complex, and Open SSID networks are subject to abuse. Wi-Fi also suffers from a handoff problem (i.e. it has no handoff method) and it's fairly easy to do a man-in-the-middle attack in coffeeshops - without 802.1X there's no way to know if that "xfinitywifi" hotspot is really Comcast or not. Wi-Fi Assistant solves that problem by providing a VPN back to Google's servers.
So far I'm very happy with the Nexus 6. It's a two year old design but it feels quite snappy. Google's clearly still putting effort into development, and the Android is pure - no Verizon or Motorola/Lenovo weirdness. It's a bit larger than I'm used to, so I'm glad I didn't get the Nexus 6P, but I have large hands so it works for me. Wi-Fi in the 5 GHz band using 802.11ac on the Nexus 6 is fast. It easily maxed out my 75 Mbps DSL connection in a speed test.
For a while I'd been using an iPad in the evening because the screen was much better than my Droid Maxx. Now the iPad sits forgotten for days at a time, as I find the Nexus 6 screen good enough to handle almost anything.
Wi-Fi Assistant was originally a Google Fi feature that applies a VPN to open Wi-Fi access points - without user intervention. In fact, Wi-Fi Assistant is now (once you have the Play Services 9.6 update) capable of securing all open Wi-Fi, even ones where you manually connect. This is a huge move by Google that will hit the cellular carriers hard because if I'm able to use public Wi-Fi with confidence, and my phone is latching on to open Wi-Fi by itself - why do I need a large data plan?
This all takes Wi-Fi a step closer to being a viable alternative to cellular data, although there are still many issues. The problem is that managing a Closed SSID network is painful and complex, and Open SSID networks are subject to abuse. Wi-Fi also suffers from a handoff problem (i.e. it has no handoff method) and it's fairly easy to do a man-in-the-middle attack in coffeeshops - without 802.1X there's no way to know if that "xfinitywifi" hotspot is really Comcast or not. Wi-Fi Assistant solves that problem by providing a VPN back to Google's servers.
zOMG so fast! |
For a while I'd been using an iPad in the evening because the screen was much better than my Droid Maxx. Now the iPad sits forgotten for days at a time, as I find the Nexus 6 screen good enough to handle almost anything.
Sunday, September 4, 2016
K6BJ - 100 Years of amateur radio in Santa Cruz
The K6BJ amateur radio group is celebrating it's centennial on September 17th, and the Santa Cruz Museum of Art & History. Information can be found at www.k6bj.org - come to the coast and celebrate a century of amateur radio tradition in Santa Cruz County!
Santa Cruz Museum of Art and History
705 Front Street
Santa Cruz, CA 95060
- September 17, 11:00am - 3:30pm
- FREE Admission
Santa Cruz Museum of Art and History
705 Front Street
Santa Cruz, CA 95060
Subscribe to:
Posts (Atom)