Home Lab Rebuild

It’s been long overdue for some changes to my home lab. The latest full outage on Sept 4, 2017 due to a power brown-out had me realizing that some improvements can be made. There has not been any major changes to the lab since 2015. In 2016 I upgraded the storage in NAS1, memory upgrade for VMH02, added Ubiquiti UAP-AC-LITE access points, and a security camera.

Now I’m going back to the drawing board and doing a fresh rebuild. The goal this time around is to be simple and redundant.

  1. Hardware firewall: I have custom built a 1U Supermicro server that will be used as the new firewall. It has a Intel Xeon X3470 CPU, 8GB RAM, quad gigabit LAN ports and a 200W low power supply. I’ve also replaced the stock passive CPU heat-sink with the Thermaltake Engine 27 low profile heat-sink. It’s a well balanced combination of performance, power and noise. In the old lab design the virtualized firewall introduced too many dependencies and greatly increased the complexity of the network. During a power outage scenario it also requires me to have a VM host and storage online which does not last long on UPS batteries. Having a low power hardware firewall allows me more flexibility and faster recovery from a total lab black-out.
  2. Additional UPS backup power: There will now be a third UPS battery for the home lab. I will dedicate one UPS for the core networking equipment and try to keep the load on it under 25% to maximize the battery life. The rest of the gear will be balanced over the other two UPS batteries.
  3. Standard Virtual Switches: I will be removing the Virtual Distributed Switch and LACP on the ESXi hosts.  This is a tough call but I have weighed the options. The VDS in my environment is overkill. I have two hosts, with only one of them on at a time. In my scenario the VDS’s only purpose is configuration sync. I don’t use traffic shaping, private VLANs, LLDP, etc! The only loss I will take by moving down to a VSS is having to manually maintain the port groups exactly the same on each host and no LACP. That doesn’t concern me because that hardly ever changes.

Continue reading…

Migration from Cisco 1000v to VMware Virtual Distributed Switch (Part 2)

home_network3

This is part 2 of a series. Click here to see Part 1. I apologise for taking so long to get Part 2 posted. Sometimes I just don’t have the time or effort I would like to have with the blog.

000193_2015-10-29 10_06

This portion of the guide focuses on the second half of the VSS to VDS migrations. We needed to move the VMs to a VSS so that you can migrate both VMs and hosts to the new vCenter cleanly. Then we will be moving the VMs back to a VDS from their VSS configuration.

Keep in mind this migration is being done LIVE with production virtual machines running on the hosts. Obviously, this must be executed carefully or you will have a lot of explaining to do. Do not make these changes without understanding the full impact to your environment. Continue reading…

Firewall Swap & Windows Telemetry Data

I recently switched over from Sophos UTM to Untangle NG for my personal use firewall at home. During the process I basically had to rebuild all of my firewall rules and general network policy configurations. This allowed to me “start fresh” as my previous configuration had gotten quite bloated and complicated over time.

It’s clear that Microsoft has no intentions of telling us what exactly is sent in this telemetry data, how long it’s stored, and why when it’s disabled it continues to send data. Not to mention which obvious third parties have access to the data. For this reason, part of the new network policies I wanted to include was blocking telemetry data from getting sent back to the Microsoft mother-ship. Continue reading…

Virtual Firewall and Networking – Planning Guide

This is a planning guide on how to create a robust, redundant, virtual network for your home-lab environment including a virtual firewall. This requires a lot of existing hardware and expertise. This is not recommended the faint of heart and will challenge you. Using a physical firewall is the easy choice.

Cisco_Nexus_3000_Series_1

I have structured this guide around how I have my own network configured for the vSkilled home lab. I have been running in this configuration for literally years without incident. You should first weigh the pros and cons for your own environment and then decide if this design is the right choice for YOU. Just because it works for me, does not mean it will work for you. There are many mixed opinions between running your firewall physically or virtually. Neither is right or wrong. That really depends entirely on your skill level and the equipment you have available. You should decide on a network topology which you are most comfortable troubleshooting and fixing when it breaks.

Continue reading…

Firewalls for Home Use

A question I see often is what firewall is the best for a home/residential environment? Before I get into that, we must realize that the majority of non tech-savvy people do not even have a firewall, or they have one but it’s not enabled/configured correctly, or they’re just not sure. In an age where we see more weaponized vulnerabilities and threats year after year – this is a huge problem. The problem though, is as big as an issue for consumers as it is for businesses such as ISPs and network device manufactures.

Home router firmware hasn’t change much over time. In early 2016, The Wall Street Journal looked at the security capabilities of the top 20 home routers. Only six of those had up-to-date firmware at that time, and just two of them had good password processes. The recent ASUS settlement with the Federal Trade Commision over the critical security flaws in their home routers is further proof that home router manufacturers don’t take security seriously. Today’s home router selections don’t offer you the flexibility to set up your network the way you see fit. They also don’t provide you visibility into the devices that are connecting to your network says Untangle.

There is a wide array of security practices that would probably make you shake your head.  Just the other day I was at my parents place and found that the ISP provided modem/gateway’s firewall was set to “NAT only”. The firewall was disabled and it even stated that this was the default option and that enabling the firewall was “optional”. I would highly suspect that this is the default configuration for all of the ISP’s customers. This means the firewall functionality and security legwork is responsibility of the end-device. Scary! Continue reading…

Home Labs: Remote Access and Security

I am sure that most who have a lab environment in their home also have a way of remotely accessing it – either from at work, with friends or family, vacation, etc. The problem with any remote access into a secure network is that you are quite literally punching a hole into your network from a security sense to allow that to happen.

People seem to have a lot of mixed feelings about allowing Remote Desktop Protocol (RDP) into their home network from the Internet. As a general blanket statement without context, I would completely agree. Opening RDP (port 3389) directly to the Internet without any other security measures in place is asking for trouble. The default RDP port will be constantly brute forced, port scanned, exploited, and the list goes on.

With that said there are steps you can take to have secure remote access to your home network using RDP, SSH, etc.

Many of these concerns can be minimized or eliminated using some of these best practices:

  1. Restrict access using firewalls
  2. Change the listening port for Remote Desktop Protocol
  3. Use two-factor authentication
  4. Use strong passwords
  5. Set an account lockout policy

1 – Restrict access using firewalls

Having a proper firewall and firewall rules in place is critical for protecting your network from outside threats. And I’m not talking about the built-in firewall on your ISP’s provided/rented crappy router/modem – these are a very poor excuse and implementation of a “firewall”- not to mention your ISP normally hard codes back-doors and default logins. I’m talking about a real firewall either physical or virtual, for example; Cisco ASA, Cisco Meraki, Untangle, PF Sense, Sophos UTM/XGUbiquiti, etc. Any of these will give you the tools required to properly firewall your home network. All of these firewalls will require a ‘geek’ to properly setup – keep in mind this article is targeted to home lab hobbyists.

basic_networkTo the right is a good example of a very basic home network with a firewall. Anything before the firewall we treat as untrusted. The firewall is literally the barrier between your network and the big, bad, Internet. There you will define your firewall rules to allow remote access and other functionality (or lack-thereof).

Personally, I use Sophos UTM (see my homelab) with a DNAT (Destination Network Address Translation) rule to redirect the external facing remote access port to a specific server and port on my internal network. This allows me to create a matching condition (For traffic from, Using service/port, Going to) to apply an action (Change the destination to, And the service to) to define what happens when something wants to connect to my network. Using that logic I can (and do) restrict the IP blocks allowed to connect to my remote access port, what times of day, etc.

This allows me to both A; define a custom externally facing port without having to change the port on the server internally, and B; create firewall rules to restrict access even further from specific traffic sources, destinations and services.

The real-world implementation of this will vary based on your choice of firewall, your skills and personal preferences.

2 – Change the listening port for Remote Desktop Protocol

Changing the listening port of RDP is a quick and easy method of implementing security through obscurity. Doing so will help to hide your RDP port from threats who scan networks looking for computers listening on the default Remote Desktop port (TCP 3389).

There are a number of ways to accomplish this. 1 – port redirection on your firewall/router, 2 – modifying the registry keys of the Windows computer locally, or 3 – using a Windows TS Gateway. Choose the method that works best for you.

3 – Use two-factor authentication

Using 2FA (two-factor authentication) is a no brainier these days. Two-factor authentication provides a second layer of security to any type of login, requiring extra information or a physical device to log in, in addition to your password. This protects user logins from remote attacks that may exploit stolen credentials.DuoScreen_740
I use Duo Security Personal edition on my remote RDP access to my home environment. I have configured Duo to only prompt 2FA if the source IP is external. That way I don’t need to use 2FA for local RDP sessions from within my LAN – which would just be annoying. Any time I want to login I just connect, enter my credentials, answer the 2FA prompt on my phone, and I’m in. The Duo Dashboard also has a wide range options, logging, and device fingerprinting. Duo works on a huge number of operating systems and platforms so you can integrate it into, almost, literally any part of your network as you deem fit.

If you are not already using 2FA in your network, start using it! It’s free and extremely easy to setup.

4 – Use strong passwords

While this one may seem like common sense, you would be surprised. A strong password should be at least 8 characters long using a combination of upper and lower case characters – including a mix of both numbers and symbols. Setting an insecure password on anything, let alone a remote entry point to your network could spell disaster.

One of the best ways to ensure that you use unique and strong passwords for systems and websites is to use a password manager. I personally use and recommend Dashlane.

5 – Set an account lockout policy

Brute force attacks are common problem for external facing ports and services. Remember that two-factor authentication only comes into effect once the password is correctly entered and will not prevent a brute force attack. Setting your computer to lock an account for a period of time after a number of incorrect guesses will help prevent attackers from using automated password guessing tools to break into your account.

  • Go to Start–> Programs –>Administrative Tools–> Local Security Policy
  • Under Account Policies –>Account Lockout Policies, set values for all three options.
    • 3 invalid attempts with 3 minute lockout durations are reasonable choices.

Conclusion

Hopefully these tips can help you to increase the security of your home network and remote access methods. If you know what you are doing and if done correctly you can have secure remote entry into your home network. This is not meant to be a be-all-end-all guide as there is no one size fits all for network security. This guide doesn’t even begin to dive into the more complex aspects of network security such as advanced threat protection, intrusion prevention, spoof & protocol protection, and so on.

Have more home lab security tips to share? Post them in the comments below!