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!

Storage Refresh 2016 – Time to Build! (Part 2)

IMG_0254

Part 1: http://www.vskilled.com/2015/07/storage-refresh-2016-the-plan/

The hard drives have arrived today from NCIX and it’s now time to build it out to finally increase the storage capacity in my home lab. I’ve made only minor changes to the original plan; I ended up shying away from the Seagate 8TB archive hard drives I had originally planned on buying to use strictly for backup purposes. Much like 3TB drives, I just don’t have any confidence in them long-term.

DeviceCurrent Drive LayoutCurrent CapacityDesired Drive LayoutDesired Capacity
NAS 1 (Thecus N5550)5 x 2TB (RAID 5)7.21TB5 x 4TB (RAID 5)16TB~
NAS 2 (Thecus N5550)1x4TB, 2x2TB, 1x1TB, 1x640GB (JBOD)8.9TB5 x 2TB (RAID 5)7.25TB~
VMH01 (Dell C1100)1 x 1TB1TB2 x 8TB, 2 x 2TB (JBOD)20TB~

The end result stays the same. I’m looking to end up with two large data/media storage pools with about 22TB of usable storage. A considerably large increase from my existing data capacity of 7.21TB.

The challenge now is performing a safe and successful data migration to the new storage. Normally I use NAS2 as my backup/archive NAS. I am going to remove the drives from it and move some of them into my VMH01 (Dell C1100) and create a temporary datastore to backup of all the data on there. That way I can safely create a backup of the data and still be semi-protected by RAID.

After some careful scavenging through some documentation I found that I would probably be able to swap the disks from NAS2 and move them into NAS1 without losing any configuration or data. However this is risky, so I will store a 3rd copy of my data on a JBOD  on “BackupSrv”. In this case the risk is worth the reward if it pays off because I will be saving myself from having to copy the data from the BackupSrv JBOD again, and worst case scenario I still have the data on the drives so I can just swap then back if I needed to roll-back the change.

The Step-by-Step Action Plan:

  1. NAS2: Destroy JBOD, power-off, remove drives
  2. VMH01: Add 1x4TB, 1x2TB, 1x1TB. (Add to BackupSrv VM)
  3. BackupSrv: Create JBOD datastore for backup
  4. NAS2: Add 5x4TB NAS drives, build raid, re-configure NFS, rsync, ftp, etc
  5. NAS1: Full rsync backup to BackupSrv & NAS2, verify data
  6. Power-off both NAS1 and NAS2.
  7. Swap disks from NAS2 into NAS1, NAS1 into NAS2. Power on, cross fingers.
  8. Verify data and shares. It works!
  9. Data Migration Completed
  10. Cleanup: Reconfigure Rsync Backup Schedules
  11. Cleanup: Update Home Lab page, CMDB, Wiki
  12. Cleanup: Permissions on shares

* – Veeam Backup Repository moved temporarily to NAS1 (approx 600GB~)
* – NFS datastores + permissions will be lost during a RAID rebuild
* – Printer Scan-to-FTP Setup

 

Lets take a look at our storage now:

000204_2015-11-09 08_47

 

Excellent. Now I have a large RAID5 14.5TB share for media/data storage, another RAID5 7.26TB share for more data storage, and another 7TB of disks in JBOD for archive/backups. I have a LSI MegaRaid MR SAS 9260-8i 8 Port SAS Raid Card on the way to properly archive/backup JBOD the drives so that I can present the disks more cleanly to a backup VM.

New ESXi Server Build – VMH02 Replacement

IMG_0184

This build was originally meant to be a remote ESXi server for my parents place, but I’ve ended up liking this new build so much I’m going to have to keep it for myself. So what I’ll be doing is finishing up this build for my lab and swapping my current 2nd ESXi host (VMH02) to be my MediaPC, and finally re-purposing the MediaPC hardware as an ESXi host for the original plan of the remote lab.

I sort-of figured in the beginning of this remote lab project that I could end up falling in love with the build and deciding to keep it, and well… here we are. I really like the new case (Cooler Master HAF XB EVO ATX) and I’ll be buying another of them for the remote ESXi lab. It’s big/open, lots of fan slots, easy to use and cable manage. That and now that I know how to work with the case properly on the next build it will be super easy to plan out and execute.

ComponentPart NameCost (CAD)
~$560
CPUIntel® Core™ i7-950 Processor$50 (used)
MotherboardASUS Rampage III Extreme LGA 1366 Intel X58 SATA 6Gb/s USB 3.0 ATX Intel Motherboard $50 (used)
RAMKingston HyperX Fury Memory Black 16GB 2X8GB DDR3-1866 CL10 - and -
Corsair Vengeance 16GB 2X8GB DDR3-1866
$120
Power SupplyThermaltake TR2 500W Power Supply Cable Management ATX12V V2.3 24PIN With 120mm Fan$50 (have)
CaseCooler Master HAF XB EVO ATX$110
NetworkIntel I350-T4 PCI-Express PCI-E Four RJ45 Gigabit Ports Server Adapter NIC$60
Fans / MiscNZXT Hue 3 RGB Color Changing LED Controller, 2 x 80mm (buy), 1 x 200mm (have), Thermal Compound$50
CPU CoolerCorsair Cooling Hydro Series H60$70

Once replaced the new VMH02 will be an Intel i7-950 with 32GB of RAM. A small upgrade from the previous i7-920 with 20GB of RAM. I was able to get the used Motherboard, CPU, and 16GB Corsair RAM of RAM (see table above) from a buddy for $120 total.  That alone saved me easily about $600, compared to buying new.

Build Progress:

I’ll another update in the coming days on build progress. 🙂