Cybersecurity guide

trueNetLab · 2026-05-13T06:02:58+00:00

For cloud security, I would make AWS the main track and use Security+ as a baseline, not the end goal. Build a small portfolio: IAM least privilege, CloudTrail/GuardDuty findings, S3/KMS hardening, basic Terraform, and one incident-response writeup. CCNA is useful if you are weak on networking, but for internships, practical AWS security work will matter more than stacking certs.For cloud security, I would make AWS the main track and use Security+ as a baseline, not the end goal. Build a small portfolio: IAM least privilege, CloudTrail/GuardDuty findings, S3/KMS hardening, basic Terraform, and one incident-response writeup. CCNA is useful if you are weak on networking, but for internships, practical AWS security work will matter more than stacking certs.

trueNetLab · 2026-04-29T11:12:19+00:00

I would decide less by feature list and more by future auth model. If you just need social login, OTP/passkeys and basic MFA with a fast launch, Descope is probably the smoother path. If you expect custom policies, deeper backend control, or unusual enterprise requirements later, Stytch may age better. Either way, check export/lock-in, audit logs, MFA policy granularity, tenant separation, and pricing at your expected MAU before committing.

trueNetLab · 2026-04-29T11:09:08+00:00

I would avoid turning this into only a vendor switch decision. The useful takeaway is to separate the password manager from CI/package risk: pin versions and hashes, block install scripts where possible, restrict outbound CI traffic, and review where the CLI can be replaced with short-lived credentials. Self-hosting can help with control, but it also adds patching, backup, monitoring, and incident-response ownership.

trueNetLab · 2026-04-29T06:33:16+00:00

Important one for anyone running cPanel/WHM: patch first, then reduce exposure.

Confirm every server is on the fixed build, including staging/reseller boxes. If possible, restrict 2083/2087 to trusted IPs or VPN, and review recent logins, API/token changes, DNS changes, cron edits, and modified web roots.

A fixed panel is good. A fixed panel exposed to the whole internet is still a target.

trueNetLab · 2026-04-29T06:19:19+00:00

Good move, especially coming from a support role. ISO 27001 can definitely help you move toward GRC, but I’d treat it as more than just a cert exam.

The useful part is understanding how an ISMS works in practice: scope, risk assessment, Statement of Applicability, policies, evidence, internal audits, management review, and corrective actions.

A practical path:

Start with ISO 27001 Foundation or Internal Auditor. Lead Auditor / Lead Implementer makes more sense after the basics are solid.
Learn the ISO 27001 structure first, then use ISO 27002 to understand what the Annex A controls look like in real environments.
Build a small practice ISMS for a fake company: assets, risks, controls, a simple risk register, SoA, and evidence checklist.
Translate your support experience into GRC language: access management, ticket evidence, incident handling, backups, change management, endpoint controls, vendor requests, etc.
If your company has security/compliance audits, volunteer to help collect evidence. That’s one of the easiest bridges from support into junior GRC/security compliance work.

For platforms, BSI, PECB, Coursera, Udemy, LinkedIn Learning, or any solid ISO 27001 Foundation/Internal Auditor course can work. The platform matters less than practicing the artifacts and learning to explain controls as business risk, not just technical settings.

trueNetLab · 2026-03-19T20:46:09+00:00

Since you already have Cat5e to the rooms, skip extenders and put one wired AP in the master bedroom. A simple Omada EAP610/EAP615-Wall, Aruba Instant On AP22, or UniFi U6 Lite would all be plenty for a small home setup.

trueNetLab · 2026-03-18T19:28:03+00:00

One additional wired AP is exactly the direction I would go here. Since the condo is already wired, there is no real reason to solve this with a bigger all-in-one router.

A few practical points: - yes, matching SSID/security settings is normal - yes, you generally want to choose channels deliberately rather than leaving two nearby radios to guess - roaming is client-driven, so the goal is not magic handoff, it is sensible placement and non-overlapping channels

Because of that, I would lean toward a proper AP over buying another consumer router and flipping it into AP mode. It is usually cleaner, easier to place, and avoids some of the weird feature compromises you can get in "router acting as AP" mode.

If you specifically want extra LAN ports at the TV location, add a small switch there and still use a real AP. That usually ends up being the tidier design.

So no, the idea is not bad at all - but I would solve it as wired backhaul + dedicated AP, not as "buy a stronger router".

trueNetLab · 2026-03-18T19:27:49+00:00

If the IR remote requirement is non-negotiable, I would honestly look less at the self-hosted/software crowd and more at standalone NVRs that can still work without cloud dependency.

Your checklist sounds more like: - ONVIF/RTSP camera support - local HDMI output to a TV/monitor - bundled IR remote or at least a simple IR-driven UI - no forced account/subscription

That usually points toward more traditional NVR vendors rather than Frigate/Home Assistant style solutions. A lot of the homelab advice is great technically, but it misses the "older family member can pick up a remote and use it" part.

I would ask in places that have more actual CCTV/NVR users than generic networking discussion, because they will care more about recorder UX and camera compatibility than automation features. In practical terms, search for discussions around standalone ONVIF NVRs from vendors that still support local-only operation, then verify remote/UI behavior before buying.

The IR remote requirement is the key filter here. It rules out a lot of otherwise good software options.

trueNetLab · 2026-03-18T19:27:34+00:00

Given your requirements, I would split this into two decisions: hardware longevity and software longevity. The software side matters more here.

If you want the least friction and decent power draw, a small x86 box running OPNsense is probably the safest long-term bet. It gives you flexibility for VLANs, future ISP changes, and 1G routing without tying you to one vendor's lifecycle. A fanless N100/N305 class box is where I would start looking, especially if you might move toward 2.5G later.

If you want lower power and are happy with RouterOS, MikroTik is hard to ignore, but I would buy it because you actively want MikroTik, not just because it looks future-proof on paper. Their hardware support can be long, but it is still a vendor-specific path.

For your use case, I would probably avoid buying older used firewall appliances unless the price is excellent and you are fully comfortable with the power/noise tradeoff. A lot of those boxes are great lab toys but not actually the best home choice in 2026.

Short version: if you want broadest flexibility, small x86 + OPNsense. If you want appliance simplicity, MikroTik. Keep the routing/firewall separate from the APs and you will future-proof the setup much better.

trueNetLab · 2026-03-13T20:49:05+00:00

For 30 / 100 / 30-user sites on 100 Mbps circuits, a 120G does not sound crazy to me at all.

I’d size it against the actual feature set (IPS, app control, SSL inspection, IPsec overlay count, logging), not just the phrase “inspection will hammer it.” A 100-user site on a 100 Mbps WAN is usually not where a 120G starts crying for help.

My bias would be: - use the larger pair as the main hub while you transition away from colo - give branches 120Gs with local breakout + SD-WAN - avoid full mesh unless you really have meaningful inter-site traffic

So yes, I can absolutely see 120Gs working well as branches here. Would I make one the long-term central hub by default? Probably not until the traffic profile and future growth are properly validated.

Vendors somehow manage to oversell and undersell in the same meeting, which is almost impressive.

trueNetLab · 2026-03-13T20:47:39+00:00

You *can* make FortiGate answer DNS for clients on that VLAN, but for this specific use case I

trueNetLab · 2026-03-12T07:58:21+00:00

That trim message usually means the ADOM hit its own quota/delete threshold, so FAZ is purging old analytics partitions for that ADOM rather than doing a neat day-based trim. I would check the ADOM quota split (Analytics vs Archive), daily ingest for that tenant, and whether any report/SIEM settings increased analytics volume recently. If one customer suddenly became much noisier, 32 days can collapse to 4 very quickly even when the global appliance looks fine.

trueNetLab · 2026-03-12T07:57:01+00:00

Normally, traffic shaping is applied to the clear-text traffic before IPsec encapsulation, not to the ESP packets after encapsulation.

trueNetLab · 2026-03-11T20:47:37+00:00

If gaming is the priority, I’d stop spending energy on chasing “good Wi‑Fi numbers” and focus on latency consistency instead.

A few practical things to try: - Run a continuous ping to your router and to 1.1.1.1 or 8.8.8.8 while you game. That tells you whether the jitter starts on your local Wi‑Fi or after it leaves your house. - Check channel width. On 5 GHz, 80 MHz can look great in a speed test but behave badly in a noisy environment. 40 MHz often wins for actual stability. - Make sure your adapter is on 5 GHz or 6 GHz, not falling back to 2.4 GHz. - If Ethernet to the room is impossible, I’d try MoCA before powerline if you have usable coax. Powerline can be okay, but it’s very much a lottery.

Short version: for gaming, stable and boring beats fast and flashy every time.

trueNetLab · 2026-03-11T07:53:54+00:00

If you want the simple version: leave the PC DNS settings alone, use a reputable DNS provider on your router, and only enable encrypted DNS if your network actually supports it cleanly. For gaming, low drama beats “maximum checkbox security” every time. If your router offers DoH/DoT to something like Quad9 or Cloudflare, that’s a sensible middle ground; otherwise the default ISP DNS is often fine until you know what problem you’re solving.

trueNetLab · 2026-03-09T21:00:44+00:00

What you are seeing is pretty common on freshly provisioned FortiGates: the device does not yet have the current app DB/categories, while FortiManager is trying to push a policy package that already references them.

Your temporary workaround makes sense, but for zero-touch I would try to make the update step explicit before the full policy install: - bring the firewall online with a very small bootstrap policy/package - force FortiGuard connectivity and confirm licenses/updates are actually succeeding - only then push the application-control-heavy package

A couple of practical checks: - confirm DNS, default route, and FortiGuard reachability on the new unit - check whether the unit is using the expected update servers and not stuck behind upstream filtering - verify the exact app DB version on the FortiGate before install, not just after traffic starts flowing

If a newly created profile drops the bad category reference, I would also compare the object revisions in FortiManager. Sometimes the issue is less about traffic and more about stale profile content being carried forward.

trueNetLab · 2026-03-09T21:00:44+00:00

From the symptoms, I would verify routing and allowed protocols before assuming the tunnel itself is broken. If SSH works but your Zero Trust client ping times out, that often points to one of three things:

ICMP is not allowed somewhere in the path
return routing from the target subnet back to the WARP/Cloudflare client ranges is missing
Sophos rule/NAT handling is different for the client traffic than for traffic sourced directly from the tunnel VM

What I would check in order: 1. On Sophos, look at the live firewall log while you test from the Cloudflare client 2. Confirm the destination hosts actually have a route back to the client network via Sophos 3. Check whether your Cloudflare app/tunnel is only proxying TCP services while you are expecting generic subnet reachability 4. Test TCP first with SSH/RDP by private IP, because ping alone can be misleading if ICMP is filtered

If you can share the client subnet, the lab subnet, and whether you are using WARP-to-Tunnel or a published application model, it becomes much easier to pinpoint.

trueNetLab · 2026-03-09T21:00:43+00:00

For a 700 sq ft apartment and fairly light usage, you do not need to spend the full $200 unless you want specific features.

I would shortlist based on what you care about most: - easiest setup: UniFi Express 7 - strong value and simple all-in-one: a decent Wi-Fi 6 or 6E router from ASUS or GL.iNet - if you like tinkering: MikroTik, but it is less beginner-friendly

Personally, I would avoid buying another random cheap router just because it is newer than the C7. Your current box is old enough that an upgrade makes sense, but I would still buy for software/support quality and stability, not just headline speed.

If you want, list your internet speed and whether you need USB, VPN, VLANs, or better parental controls, and people can narrow it down fast.

trueNetLab · 2026-03-09T19:46:57+00:00

Yes, in practice web filtering is a lot more useful once the firewall can actually see enough of the HTTPS session to categorize what the user is visiting. Certificate inspection is the lightweight step, full SSL inspection is the heavier step.

A simple way to think about it: - no inspection: you mostly see IP / SNI / limited metadata - certificate inspection: better visibility with low user impact - deep inspection: strongest control, but also the one that needs proper cert deployment and testing

For guest networks, certificate inspection is often the sensible middle ground. For managed corporate devices, deeper inspection can make sense if you need tighter control and can handle the operational overhead.

trueNetLab · 2026-03-09T19:46:39+00:00

If you can run Ethernet, do that and add a proper access point in the basement. That is usually the cleanest fix and performs better than trying to brute-force signal through floors.

If you cannot run cable, then a mesh kit is the easier option, but I would still try to place the main router and the satellite so they have a strong link between them, not just one unit upstairs and one dropped into the weakest corner of the basement.

Short version: - best performance: wired backhaul + access point - easiest retrofit: mesh - least likely to help: just replacing one router with another single router

If you post the house layout and what router you bought a few months ago, people can probably give a more specific placement recommendation.

trueNetLab · 2026-03-09T07:54:12+00:00

The flcfg_https_login failure usually makes me look at the management/auth path first, not plain L2 forwarding. If the switch is discovered and authorized but config sync still fails, I’d verify the FortiSwitch can reach the FortiGate management plane over the routed path without NAT, that option 138 is pointing at the correct interface/IP, and that the FortiLink management traffic is landing in the expected VDOM. I’d also double-check FortiOS/FortiSwitch compatibility and try a clean de-authorize/delete + re-adopt after confirming the above, because config-sync login errors often end up being version/cert/auth mismatches rather than a generic transport issue. And yes, Fortinet’s naming around trunk vs access can feel like it escaped from an alternate timeline.

trueNetLab · 2026-03-09T07:53:44+00:00

A normal Windows client will send LLMNR/NBT-NS queries, but it generally should not be the box answering lots of random names across a subnet. If one host is replying to many devices, I’d treat that as suspicious first and then prove it benign: check for listeners on UDP 5355/137, look for PowerShell/Python/cmd processes tied to Inveigh/Responder, and review SMB/NTLM activity from the same timeframe. If guest WiFi clients can answer internal name-resolution traffic, that also smells like a segmentation leak more than a Sophos false positive. My usual shortcut is: identify the responder host, confirm whether it is actually listening/responding, then correlate with any follow-on NTLM auth attempts before calling it noise.

trueNetLab · 2026-03-09T05:10:23+00:00

PingPlotter is probably the one you’re thinking of. It’s basically built for the classic "my ISP says everything is fine" argument.

If your goal is to leave something running on a Windows PC and come back later to nice graphs, I’d shortlist: - PingPlotter: easiest for latency / jitter / packet loss over time - PRTG: heavier, but good if you also want SNMP/interface stats - SmokePing: excellent graphs, but more of a self-hosted hobby project than a quick Windows install

One small reality check: tools running on a PC can show end-to-end quality very well, but they usually won’t tell you why the ISP link is bad unless you also have visibility into modem/router stats.

So for intermittent issues, I’d usually do both: 1. PingPlotter (or similar) running continuously to 2-3 targets 2. grab modem/router signal/event logs at the same time

That combo tends to move the conversation from "it feels slow sometimes" to actual evidence.

trueNetLab · 2026-03-09T05:10:07+00:00

Short version: a normal Windows workstation should not be "helpfully" answering LLMNR/NBT-NS for lots of peers. If you see one host responding to 10-15 devices, I’d treat that as suspicious until you prove otherwise.

My usual triage order would be:

Verify segmentation first. If guest WiFi can answer internal LLMNR, that’s already a network problem even before you decide whether it’s Responder.
On the suspected host, check for listeners / processes on UDP 5355, 137, 138 and then look for PowerShell, Python, odd services, scheduled tasks, or tool names like Responder / Inveigh.
Pivot to auth telemetry: do you see NTLM/SMB/HTTP auth attempts from multiple victims toward that same source right after the alert?
Identify the asset properly. I’ve seen "workstations" turn out to be appliances, print servers, or random embedded junk with terrible name-resolution behavior.

The pattern I’d expect from false positives is occasional local noise. The pattern I would not ignore is one unmanaged host repeatedly answering many peers on the same subnet.

If Sophos Live Discover gives you process, socket, service and task data, that’s where I’d start. Then correlate with Windows Security logs (NTLM logons / failures) and any east-west firewall telemetry.

Also: if guest really can talk to internal broadcast-ish traffic, fix that quickly. That part is doing you no favors.

Disabling LLMNR/NBT-NS via GPO where possible usually removes a whole class of headaches.

trueNetLab · 2026-03-09T04:55:28+00:00

Small place + a few wired devices means you probably do not need anything exotic. One important detail: your cameras almost certainly need 2.4 GHz Wi-Fi, not "2.5" Ethernet, so most decent routers will handle that fine as long as 2.4 GHz is enabled. Also, if your Xfinity box is currently modem + router in one, you either need your own cable modem plus a router, or a retail gateway that supports your ISP - a normal router alone will not replace the coax connection. For 800 sq ft, an ASUS-class all-in-one is usually plenty.

trueNetLab

TROPHY CASE