Say my Blog’s name!

Given that the title of this site is “functionally paranoid”, I noticed it had been a while since I had written anything focused on information security.  I thought about what would be a good topic and it hit me – how about my uber paranoid home networking setup?  So, put on your tinfoil hats my friends and buckle up – it’s going to be a wacky ride!

Physical Security

What’s the one thing that everyone forgets when thinking about information security?  Well, one is that there is always some guy named Bob who will mess things up (i.e. humans are the weak link because we can be socially engineered, etc.)  The other thing is that if you have physical access to anything, you can eventually brute force it.  However, there are things you can do to make things more difficult.  Here are some of the pros and cons:

  1.  BIOS passwords – Not something I’m typically impressed with.  Most can be avoided by opening up the machine, closing a jumper and powering it up to reset the NVRAM to factory defaults.  I don’t even bother with them.
  2. Full disk encryption – This one really rings my bell in a positive way.  If you can kill power to the box (either because the bad actor has to physically steal it and they aren’t carrying around a pile of car batteries and an inverter or because you can interrupt power to it some other way), then the disk will be encrypted.  The other beauty of this is that if a drive fails (and they all do eventually) you don’t have to have any privacy concerns about chucking it into an electronics recycler (or if you are a bad, bad person, into a landfill) because that data is effectively gibberish without the key (or without a long time to brute force it).
  3. Two factor auth for logins – I like this one as well.  I’m not a fan of biometrics because if your fingerprint is compromised (yes, it can happen – read about the department of defense background checks that were extracted by a bad agent – they included fingerprint images) you can’t exactly send off for a new finger.  Things like the YubiKey are pretty slick.  They require that you have the physical hardware key as well as the password so unless the bad actor lifted your physical key, they would have a much harder time with physical access to your hardware.

I use full disk encryption and two factor auth via a YubiKey on every piece of gear in my secure home network.

Network Segmentation

This is an area where I could get way more creative, because keeping network traffic isolated to particular subnets or VLANs is a great mechanism to prevent “island hopping”  (thank you Alan Jude and Chris Fisher for TechSnap!) when a bad actor gains access to one of your network resources; however, I’m keeping it simple for now.  The first thing I did was change the default password for administrative access to my ISP-supplied router.  There are some pretty interesting attacks that don’t compromise your machine, but instead use it to run Javascript to log into your non WAN exposed ISP router using the default userid and password and then do things like DNS hijacks, etc. to be able to maliciously impact every device on your network.

Just change the darned password to something else already!  Also, validate that your administrative interface for the thing isn’t exposed to the WAN side of the link.  Believe it or not, some of them ship that way.  I leave the ISP-supplied WiFi access point to provide a network I make available to my guests because it sits entirely outside of my secure network.

The next thing I do is connect the LAN side of the ISP-supplied router to the WAN side of my own router.  I use an APU2 box that I built for around $150 running OpenBSD as my router for my secure network.  I use the wonderful pf firewall that is supplied with OpenBSD to filter packets and map ports as I want to.  It has a very understandable syntax and has great performance.  The LAN side of this router goes to my managed switch (which I hope to replace with switchd running on an OpenBSD box at some point) which serves as the core backbone of my secure network.  Plugged also into this switch is my WiFi access point running in bridge mode for my network so that I can have WiFi access (with a very secure WPA2 password) to my secure network.

I know that any true security expert will scoff that I go to all of this trouble and then hook a WiFi access point up, but this is an area where I tilt the scales away from security towards convenience.  A good long WPA2 password isn’t ideal, but it isn’t crackable in a short period of time without a determined attacker who has lots of horsepower.  For example, a 16-character randomly generated password that uses uppercase, lowercase, numbers and special characters would have so many permutations, that it would take a freakishly long time to brute force.

Privacy

So security is good, but privacy is good as well.  You might not get hacked, but if you aren’t careful about privacy, you will be leaving breadcrumbs all over the internet – which is not good.  To that end, think about who probably knows the most about your online traffic – that’s right, your ISP.  Even if you do everything over HTTPS and use a VPN, you are probably still using them (or heaven forbid Google!) for your DNS resolution.  Enter DNSCrypt Proxy!  This little jewel takes all of your DNS traffic and egresses it to the Internet outside of your ISPs network.  I actually use a public resolver in Europe for mine.

I use Unbound as my DNS resolver on my local network (with all UDP port 53 traffic redirected to it by pf so I don’t have to configure anything on the clients) and then forward the traffic to DNSCrypt Proxy, caching the results in Unbound.  I notice ZERO performance penalty for this and it greatly enhances privacy.  This combination of Unbound and DNSCrypt Proxy works very well together.  You can even have redundancy by having multiple upstream resolvers running on different ports (basically run the DNSCrypt Proxy daemon multiple times pointing to different public resolvers).

I also use Firefox exclusively for my web browsing.  By leveraging the tips on this page, you can lock it down to do a great job of privacy protection.  The fact that your laptop’s battery drain rate can be used to fingerprint your browser completely trips me out but hey – that’s the world we live in.

For times I am not connected to my secure network, I use a non US-based VPN provider (I like AirVPN.org) and choose an endpoint that isn’t in a Fourteen Eyes country for egress.  I  have given thought at various times to doing that using pf on my home network but the performance hit is still a bit too much for me.  Likely that will improve over time.  The nice thing about AirVPN is that it uses the OpenVPN client meaning I can run it on my mobile devices as well.

You can get even more secure with things like the TOR browser bundle, but be careful how you configure it.  You can actually make yourself less secure than you think if you aren’t educated on how everything works.

The Cloud

This is where it starts to get weird for most folks.  They have pretty good security hygiene and maybe are fairly good about privacy, but they end up storing everything in a cloud service.  Remember, another way of saying “the cloud” is “some other guy’s computer”.  If you really to care about your privacy, then you should avoid cloud services like the plague.  However, that starts to get really hard and you have the good old balancing act between security and convenience.

I recently decided I would try to live a cloud-free life and I’ll give you a bit of a synopsis on it.  I discovered a wonderful OpenSource project called FreeNAS.  What this little gem does is allow you to install a FreeBSD/zfs file server appliance on amd64 hardware and have a slick administrative web interface for managing it.  I picked up a nice SuperMicro motherboard and chassis that has 4 hot swap drive bays (and two internal bays that I used to mirror the boot volume on) and am rocking the zfs lifestyle!  (Thanks Alan Jude!)

One of the nicest features of the FreeNAS is that it provides the ability to leverage the FreeBSD jail functionality in an easy to use way.  It also has plugins but the security on those is a bit sketchy (old versions of libraries, etc.) so I decided to roll my own.  I created two jails – one to run OwnCloud (yeah, I know about NextCloud and might switch at some point) and the other to run a full SMTP/IMAP email server stack.  I used Lets Encrypt to generate the SSL certificates and made sure I hit an A on SSLLabs before I did anything else.

OwnCloud includes the ability to install plugins and there are some dandy ones out there.  I installed a notes one that had iOS and Android clients (buh-bye Evernote with your attempted changed privacy policy which you rolled back but I see how you really are now).  I also installed a Calendar plugin that had CalDAV support (see ya’ Google Calendar!) and a CardDAV contacts plugin (later Google Contacts).  I got all of them up and running (along with the mail server Jail – use mxtoolbox to check your work here) and can now stop using the main cloud services I had previously been running.

How did I get around my ISP blocking common IMAP/SMTP ports you ask?  I set up a relay server on a VPS server that I rent for $8 per month.  I started out on one based in the US but my better thinking prevailed and I found a provider in a non fourteen eyes country.  Everything seems to be working OK once I got all of the right security / anti-spam bits in place but only time will tell.

This path isn’t for everyone because you are now fully in charge of the security and reliability of your mail / calendar / contact / note infrastructure.  Also, you just increased your attack surface so be extra careful there!

Backups

This is another fun one.  You go to all of this trouble and then you store your offsite data backup (you DO back up your data offsite, right?!??!?!!) in some cloud service like Carbonite or CrashPlan.  As convenient and cost-friendly as that is, you have no idea how many copies of your data they make in their datacenter operations and even if you leave them, they are probably still floating around in their cloud infrastructure somewhere.

Enter TarSnap – a company that advertises itself as “Online Backups for the Truly Paranoid”.  It brings a tear to my eye – a kindred spirit!  🙂  Thanks again to Alan Jude and Kris Moore from the BSD Now podcast for turning me onto this company.  It has a very easy command syntax (yes, it isn’t a GUI tool – suck it up buttercup, you wanted to learn the shell didn’t you?) and even allows you to compile the thing from source if you want to.

The way it works is that it encrypts the data on your machine before ever sending out to the network.  As long as you keep your private key on the encrypted drive on the machine you are backing up, it’s pretty darned safe although you might want to keep a copy of it somewhere that is physically secure and preferably offsite (perhaps a GPG encrypted file on your mail relay VPS).  The cost is based on the amount of data you store and the network traffic to get it to/from their service.  However, for the type of data I’m storing up there, it isn’t crazy expensive and it de-dupes the heck out of it to further reduce your costs.

Internet of Things

This is an easy one – avoid any “internet of things” device that connects to anything outside of your network!  That way you avoid these poorly implemented security nightmare devices becoming a public menace and joining a DDOS botnet.

OK, if you absolutely can’t live without your internet connected ice cube tray, the best way to secure these devices is to put them completely outside of your secure network.  Hook them up to the WiFi made available by your ISP supplied router (where I put my guest traffic).  It’s still (theoretically) sitting behind a “secure” router but it sure as heck isn’t on your secure network.

You could do other things like having a VLAN dedicated to them and locking them down by MAC address.  The problem is there is always some clever 8th grader in Germany who will still find a way to exploit them and island hop to your other machines.  Best keep them at arm’s length on the outside of your real router (you do run an OpenBSD router, right!?!??!?!)

Conclusion

There are other things that I’ll want to do eventually (perhaps putting my WiFi traffic on its own network segment with host isolation mode, switching to certificates for my WiFi access, or installing an IDS tool like snort), but for now, this is where I stand.  I’d appreciate any feedback or suggestions from folks out there with ideas on how to lock things down more.

This entry was posted in Uncategorized. Bookmark the permalink.

5 Responses to Say my Blog’s name!

  1. Name (required) says:

    > … Firefox exclusively … non US-based VPN provider … doing that using pf on my home network but the performance hit…

    You can make that easily switchable. Run one (or more) SOCKS5 proxies like Dante (sockd) on your router, (each) sending its traffic to an (one of the) IPsec tunnel(s) to your VPS(es). Then you can easily use some extension like “Proxy Selector” in Firefox to select where you want to exit. Works just fine for both IPv6 and IPv4. DNS ends up on DNScrypt anyway (also on the VPS(es), which also run OpenBSD, I hope), so SOCKS5 should be good enough.

    And if you live in a country with no Internet Service Providers, where those who call themselves ISP only provide access to some part of the internet, you can easily route to one of your VPSes what your NSP (/Network/ Service Provider) doesn’t provide, with just PF and a little script which translates hostnames to addresses once in a while (to load the addresses into a PF table, no transparent proxy necessary).

    Well, that was both for convenience, not to “lock things down more”, but the rest is close to what I do, too.

  2. Name (required) says:

    Me again.

    Intersting blog post indeed. I knew others do the same thing, but didn’t see a blog post like this one about it. So, after thinking about a lot of off-topic which I definitely shouldn’t post, one more thing regarding security:

    It seems you don’t use much IPv6 yet as you didn’t mention anything about it. To those who do: Make sure you handle IPv6 (all of it, native IPv6, all kind of tunnels, proxies, etc.) just like any other /public/ connection before you do anything else with it. As in: “block in all inet6” and then allow what you actually want to allow, no matter on which interfaces it reaches you. Kinda common sense, but easily forgotten.

  3. Name (required) says:

    oh well…

    s/block in all inet6/block in inet6/

  4. Pingback: How the Dtrace saved Christmas | BSD Now 175 | Jupiter Broadcasting

  5. My blog name is femme ukraine

Leave a Reply to Name (required) Cancel reply

Your email address will not be published. Required fields are marked *