Network Security Field Notes: Start Here

The Short Version

Start with five controls: know every important asset and admin account, require strong multi-factor authentication, restrict management paths, collect useful logs, and prove that protected backups restore. Segmentation, endpoint protection, and vulnerability management build on that foundation. A new security appliance cannot compensate for unknown devices, shared owner accounts, untested recovery, or an exposed management interface.

For a home lab or small organization, the first successful outcome is not “zero trust” or a perfect score. It is being able to answer four questions quickly: what exists, who can administer it, what can communicate with it, and how it will be recovered. The CISA Cross-Sector Cybersecurity Performance Goals and NIST Cybersecurity Framework 2.0 organize the same work across govern, identify, protect, detect, respond, and recover.

Network security is not one product, one firewall rule, one antivirus agent, or one dashboard. It is a set of habits and layers that make a network harder to abuse, easier to monitor, and faster to recover when something goes wrong. The TechGeeks security section is going to focus on practical security for real environments: home labs, small businesses, ISP operations, PisoWiFi deployments, WordPress sites, routers, switches, servers, and cloud services.

This post is the starting point. It explains the security model we will use across future articles and gives you a realistic first checklist you can apply before buying anything.

Security Starts With Knowing What Exists

You cannot protect what you cannot see. Before talking about advanced tools, start with an inventory:

• Routers, firewalls, switches, and access points.
• Servers, NAS devices, cameras, printers, and controllers.
• Cloud accounts, DNS providers, hosting accounts, and SaaS services.
• WordPress sites, plugins, themes, admin accounts, and backups.
• ISP devices, CPE equipment, tower gear, and customer-facing portals.
• Admin laptops and phones used to manage everything else.

An inventory does not have to be perfect on day one. It just needs to exist and improve over time. A simple spreadsheet is better than a mystery network.

Give the inventory fields that support decisions: owner, purpose, physical or cloud location, IP address or hostname, operating system or firmware, support status, data sensitivity, management URL, backup method, and last review date. Add an “unknown” state instead of guessing. Reconcile the list against DHCP leases, switch clients, wireless associations, hypervisor inventory, cloud billing, DNS zones, and password-manager entries.

Discovery tools can miss powered-off devices, isolated VLANs, unmanaged cloud accounts, and equipment that does not answer probes. Treat scanning as one input, not proof that the inventory is complete. Do not scan networks you do not own or lack permission to assess.

Identity Is The New Edge

Old network security thinking focused heavily on the perimeter. Firewalls still matter, but identity is often the real control point now. If an attacker gets an admin password, a Google account, a WordPress account, a router login, or an SSH key, the network edge may not matter much.

At minimum, protect important accounts with:

• Unique passwords stored in a password manager.
• Multi-factor authentication wherever possible.
• Separate admin accounts instead of using daily accounts for administration.
• Removed accounts for former users, contractors, and old test logins.
• Documented recovery methods that do not depend on one person.

For small environments, identity cleanup is often the highest-value security work because it removes easy paths attackers love.

Prefer phishing-resistant authentication such as passkeys or hardware-backed FIDO credentials where the service supports it. Store recovery codes away from the device used for normal login, and keep at least two authorized recovery paths for critical registrar, cloud, firewall, and hosting accounts. A shared family or company owner account may be hard to eliminate, but daily administration should still use named accounts so logs identify who made a change.

Segment The Network

Flat networks are convenient until something gets compromised. Segmentation limits the blast radius. A guest phone should not reach a server. A camera should not reach accounting machines. A PisoWiFi customer should not reach router management. A lab VM should not have the same trust as production infrastructure.

Common segments include:

• Management: routers, switches, access points, controllers, hypervisors, and admin interfaces.
• Trusted users: staff devices or family devices that need normal access.
• Guest: internet-only access with client isolation.
• IoT and cameras: limited access, usually only to required services.
• Servers: controlled inbound and outbound access.
• Customer access: PisoWiFi or ISP customer networks separated from operations.

Segmentation is only useful when paired with firewall policy. VLANs create lanes. Firewall rules decide who can cross lanes.

Start with a small number of trust zones. Every new VLAN adds DHCP, DNS, firewall, discovery, monitoring, and troubleshooting work. For each permitted path, record source, destination, protocol and port, business or household reason, owner, and review date. NIST SP 800-207 is a useful boundary check: network location alone should not create implicit trust in a user, device, or service.

Firewall Rules Should Be Boring And Clear

A good firewall policy is not a giant pile of exceptions. It should be readable. Start with default deny between sensitive segments, then allow only what is needed. Name rules clearly, group them by purpose, and remove temporary rules when the temporary need ends.

For example, management interfaces should usually be reachable only from an admin segment or VPN. Servers should expose only required ports. Customer networks should be internet-only unless there is a specific reason. DNS should be controlled so clients use the resolver you expect.

A Safe Firewall Change Workflow

1. Export the current configuration and confirm where the backup is stored.
2. Write the desired source, destination, service, and expected deny behavior before opening the interface.
3. Keep one known-good local or console administration path available.
4. Apply one narrow rule and test from an allowed client and a client that should remain blocked.
5. Review firewall logs to confirm the intended rule, not a broader rule, handled the traffic.
6. Remove the temporary rule or restore the saved configuration if the change has unexpected reach.

NIST SP 800-41 Rev. 1 covers selecting, configuring, testing, deploying, and managing firewall policy. The publication is older than current products, but the operational discipline remains relevant. Interface screenshots and menu names are vendor-specific; the rule intent and verification should survive a platform change.

Logging Turns Guesswork Into Evidence

Security without logs becomes storytelling. You need enough visibility to answer basic questions:

• Who logged in?
• From where?
• What changed?
• Which device is scanning or making unusual outbound connections?
• Which firewall rules are being hit?
• Which WordPress admin actions happened recently?

You do not need a full enterprise SIEM to start. Router logs, firewall logs, WordPress login logs, DNS logs, and basic uptime monitoring already provide useful clues. The key is to collect them before the incident.

Synchronize system time before trusting a timeline. Send critical logs to a different system so an attacker or failed device cannot erase the only copy. Set retention from the actual investigation need and privacy risk: DNS queries, authentication records, camera events, and customer addresses can expose sensitive behavior. Restrict access, encrypt backups, and delete logs when the retention purpose ends.

Test alerts with a harmless event such as a failed login from a test account or a denied connection between lab segments. A dashboard that stays green during a controlled failure is not useful evidence. Record the alert time, delivery channel, source log, and person responsible for acting on it.

Patching And Backups Are Security Controls

Patching closes known holes. Backups make recovery possible. Both are security work. A network with perfect firewall rules but no backups is still fragile.

Use a routine:

• Track firmware and plugin updates.
• Update during planned windows when possible.
• Back up configurations before updates.
• Keep offline or protected backups for critical systems.
• Test restores, not just backup creation.

For WordPress, this means keeping plugins lean, removing unused plugins, updating the active ones, and keeping a clean recovery path. For routers and firewalls, it means exporting configs after meaningful changes.

A snapshot on the same server is a fast rollback point, not a complete backup. Keep protected copies outside the system being protected and define a recovery point objective: how much recent data can be lost. Then define a recovery time objective: how long the service may remain unavailable. Those two numbers decide backup frequency and restore priority more usefully than a product logo.

Have An Incident Plan Before You Need It

An incident plan does not need to be complicated. It should answer:

• Who decides when something is an incident?
• Who has admin access?
• How do we isolate a device or segment?
• Where are backups?
• How do we preserve logs?
• Who needs to be notified?

During an incident, emotions run hot and time feels compressed. A short plan gives you rails to run on.

Include legal and business boundaries before collecting evidence. Preserve logs and system state when investigation matters, but do not access employee, customer, tenant, or neighbor systems without authority. Notification duties vary by jurisdiction, contract, and data type. A home-lab checklist is not a substitute for legal counsel, an insurer's incident process, or law-enforcement guidance when those apply.

Verification Checklist

• An inventory review can identify the owner, support state, management path, and backup for every critical device and cloud account.
• A guest or IoT client cannot reach router, switch, hypervisor, NAS, or WordPress administration interfaces.
• A named administrator can sign in with MFA, and a documented recovery method works without relying on one phone.
• A controlled failed login and firewall deny appear in the expected log store with correct timestamps.
• A representative file, application database, router config, and website backup restore to an isolated test location.
• Internet-facing systems have a recorded patch owner, maintenance window, and current support source.
• The incident contact list and one-page isolation procedure are available when the normal cloud account or password vault is unavailable.

This page is documentation-backed guidance, not a report of a TechGeeks penetration test or security audit. Passing the checklist demonstrates that selected controls work in the tested paths. It does not prove that no unknown asset, vulnerable application, stolen session, supply-chain issue, or misconfiguration remains.

The First Ten Things To Do

1. List every admin account.
2. Turn on multi-factor authentication for critical accounts.
3. Remove unused WordPress plugins, themes, and users.
4. Back up router, firewall, switch, and website configs.
5. Separate guest, customer, IoT, server, and management traffic.
6. Restrict management access to admin networks or VPN.
7. Enable useful logging on firewalls, routers, and WordPress.
8. Patch the systems that face the internet.
9. Document public DNS, hosting, and registrar access.
10. Write a one-page recovery plan.

Future security posts will go deeper into each of these areas. We will cover firewall examples, VLAN security, WordPress hardening, VPN access, log review, backups, malware cleanup, secure remote access, and practical threat modeling for small networks and ISP-style environments.

Related TechGeeks Resources

• Networking Field Notes: Start Here
• Router Security Settings Audit
• Homelab VLAN Design: Simple Network Segmentation That Works
• WireGuard Home VPN: Secure Remote Access for Your Homelab
• Homelab Backup Strategy: Restore Tests, NAS, and Offsite Copies

References

• NIST Cybersecurity Framework 2.0
• CISA Cross-Sector Cybersecurity Performance Goals
• CISA StopRansomware Guide
• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy
• NIST SP 800-207: Zero Trust Architecture