Gebhard's Site
Gebhard's ramblings and content links.

Home Network – Geek Style

gebhard , ,

This is a little blog post describing my home network setup and the thoughts and principles behind it. I hope it may be of use to somebody having similar goals.

Design Decisions

General

  • affordable
  • should scale well for a private LAN
  • trade-off between security and usability
  • extendable
  • should offer places to learn
  • “Women acceptance Factor ready” aka should simply work

Technical

  1. Network Securiy Monitoring: offer a way to sniff all traffic to uplink provider (except directly connected devices to uplink / ISP router)
  2. segmented: use separate segments for different usage scenarios
  3. ISP / ISP hardware independent: only to have to change little and basic stuff on the uplink router to the ISP, should work with normal stock ISP routers
  4. VPN functionality on demand (but make sure, #1 still works)
  5. simple DMZ functionality
  6. Internet of (shitty and broken) Things should work
  7. run a honeypot / dshield sensor
  8. flexible and extensible main router
  9. Cloud (doesn’t mean anything, but cloud is a must nowadays …)

The initial Plan

… was to have separated VLANs / IP subnets for different purposes. But testing revealed this would break #6: there are so many IoT apps on mobiles which work only if the mobile is connected to the same IP subnet as the IoT device. But I wanted at least some control – especially how the devices are allowed to connect to the Internet, but without having to manage each device independently. So as a compromise I devided a /24 net into chunks of 32 IP addresses, this gives eight different “segments” which can talk without restrictions to other devices / to the other “segments” but have limited / controlled connectivity to the Internet. This was the basis for further plans.

#1: NSM

My NSM of choice became foxfound. The original repo can be found here, my derived here. There are still some issues to be fixed, see issues in the original and in my repo.

#2: Segments

Where possible I use different IP subnets / VLANs to separate traffic. But the basic design decision for the main network had to be weakened, see above.

Separare networks exist for the following purposes:

  • LAN:
    • main LAN
    • guest network
    • DMZ
    • VPN LAN (traffic from every device connected to this network should be automatically routed and tunneled to a VPN exit node)
  • WAN / uplink:
    • network to uplink / ISP router
    • network to VPN router

#3: ISP hardware

The uplink router from the ISP isn’t configured that much … it should be interchangeable. Main modifications:

  • IP network settings
  • router IP
  • exposed host (for honeypot / dshield sensor)
  • routing information

If the device breaks or the ISP changes: a new device should be up and running without any hassle. A typical vendor for such hardware would be AVM, product being FRITZ!Box.

#4: VPN functionality

To provide VPN functionality without breaking #1 and #3 I chose to get a separate device. After some reading and asking aunt Google my decision was this device: GL.iNet GL-MT300N-V2. It is small, cheap, configurable, understands OpenVPN profiles.

One little drawback: LAN and WAN ports are not allowed to be on the same subnet.

#5: DMZ functionality

This is taken into account twofold:

  • honeypot / dshield sensor: ISP hardware allows to define an exposed host (so all traffic initiated from the Internet can be directed to one system); this traffic doesn’t has to go through the NSM
  • other toys: separate DMZ VLAN on main router; this traffic should go through NSM

#6: IoT stuff

see above: eight segments with defined outgoing traffic rules on main router

#7: Honeypot / dshield sensor

For details see above. The basic installaion is the official Raspberry Pi software from SANS ISC, which can be found here.

#8: Main Router

This was easy, especial it one wants to support OpenSource hardware and software and need a flexible, powerful but affordable device: Turris Omnia.

#9: Cloud

well – yes.

Network Layout

The mildly obfuscated layout of my current home network obeying above design decisions is as follows:

 

 

Network Overview

  • WAN (192.168.a.0/24): this network is used for everything which has to connect to the uplink / ISP router directly
  • VPN (192.168.b.0/24): only used to connect the VPN gateway between the uplink / ISP router (WAN port) and the main home router (LAN port) – because LAN and WAN interface of the VPN gateway must not be on the same subnet
  • LAN / Mobile (192.168.z.0/24): the main home LAN and WiFi net, used for PCs, mobiles, IoT devices, … (segmented in eight different IP ranges with different default rules for Internet traffic)
  • Guest (192.168.y.0/24): WiFi only network for friendly guests’ devices
  • DMZ (10.10.w.0/24): DMZ network, only used for testing
  • VPN (192.168.x.0/24): WiFi only network, devices with IPs from 192.168.x.128/25 will be routed through VPN gateway automatically

Device Overview

  • uplink / ISP router: stock AVM FRITZ!Box (requirements: LAN interface, configurable LAN networks and router IP, static routes, exposed host functionality)
  • Pi dshield: Raspberry Pi used for honeypot and dshield sensor (configured as exposed host on uplink / ISP router)
  • Switch: configurable swich (requirements: configurable port links (which port is allowed to speak to which port), have separate admin interface, have SPAN functionality); this is a MikroTik RouterBoard 250GS (highly configurable and cheap, for alternative devices see e.g. WireShark Wiki, Security Onion Wiki)
  • Main Router: Turris Omnia (because: Open Source, highly configurable, well supported, etc.)
  • VPN Router: GL.iNet GL-MT300N-V2 (because: cheap, configurable, works with OpenVPN profiles, …); has some drawbacks, but works in this configuration
  • NSM: Raspberry Pi with Foxhound NSM;

Special Configuration

  • uplink / ISP router:
    • networks behind main router have to be configured with static routes on the uplink / ISP router
    • exposed host configured for honeypot / dshield sensor
    • all outgoing traffic allowed
  • VPN router:
    • networks behind main router have to be configured with static routes on the VPN router
    • configured with ProtonVPN OpenVPN profiles
    • WiFi disabled
    • because the LAN and WAN interface can’t be on the same subnet, the separate VPN network 192.168.b.0/24 is needed
  • main router:
    • DNS / NTP servers
    • source based routing: from 192.168.x.128/25 to VPN router LAN interface
    • firewall: basic outgoing connections customized for each segment of LAN / mobile network (e.g. IoT -> Internet http, https; Office -> Internet http, https, smtps, impas, …)
    • on the WAN interface two networks are configured: the direct network to the LAN interface of the uplink / ISP router and the network for the LAN interface of the VPN router
  • switch:
    • port 1: SPAN port of port 3
    • port 2: WAN interface, connection to uplink / ISP router
    • port 3: internal interface; connection to main home router
    • port 4: WAN interface for VPN traffic to VPN gateway
    • port 5: admin interface, connected to LAN
    • traffic allowed between port 2, 3, 4
  • honeypot / dshield sensor:
    • Raspberry Pi
    • WiFi disabled
  • NSM:
    • Raspberry Pi
    • WiFi is used for admin access via LAN
    • connected WD PiDrive for storage of full packet captures

Further Considerations

  • central syslog server on NAS
  • central ELK stack on NAS for syslog analysis
  • make sure to inform all parties which connect to the network that their traffic is being captured and analyzed