<![CDATA[TalkativeTurtles - Networking & Cybersecurity]]>

<![CDATA[TalkativeTurtles - Networking & Cybersecurity]]> https://talkativeturtles.club/ Wed, 05 Aug 2026 13:58:00 +0000 MyBB <![CDATA[Tailscale vs self-hosted WireGuard - which did you choose and why?]]> https://talkativeturtles.club/showthread.php?tid=129 Mon, 29 Jun 2026 20:52:08 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=129
Why I moved to Tailscale:

NAT traversal just works. WireGuard requires at least one public endpoint. Tailscale handles the CGNAT case without me thinking about it.
Device management is actually pleasant. Adding a new machine is under 2 minutes.
MagicDNS is underrated. Referring to machines by name instead of IP removes a whole class of confusion.

What I gave up:

Control plane is in Tailscale hands. If you have strict self-sovereignty requirements this is a non-starter.
Headscale exists but the setup overhead partially defeats the convenience argument.
The free tier is 3 users and used to be more generous.

NAT traversal just works. WireGuard requires at least one public endpoint. Tailscale handles the CGNAT case without me thinking about it.
Device management is actually pleasant. Adding a new machine is under 2 minutes.
MagicDNS is underrated. Referring to machines by name instead of IP removes a whole class of confusion.

What I gave up:

Control plane is in Tailscale hands. If you have strict self-sovereignty requirements this is a non-starter.
Headscale exists but the setup overhead partially defeats the convenience argument.
The free tier is 3 users and used to be more generous.

Verdict: Tailscale for personal use and small teams, self-hosted WireGuard when the org has a dedicated network person and a reason to avoid third-party control planes.

What are you running?]]> <![CDATA[Home lab network segmentation - how far do you actually go?]]> https://talkativeturtles.club/showthread.php?tid=117 Mon, 29 Jun 2026 20:35:25 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=117
Currently:

Main LAN - trusted devices, laptops, workstations
IoT VLAN - smart plugs, lights, thermostat, isolated with no internet except updates
Guest WiFi - completely separate, internet only

Thinking about adding:

A media VLAN for consoles and streaming sticks - semi-trusted, can reach Plex server only
A lab VLAN for VMs and containers I experiment with

Main LAN - trusted devices, laptops, workstations
IoT VLAN - smart plugs, lights, thermostat, isolated with no internet except updates
Guest WiFi - completely separate, internet only

Thinking about adding:

A media VLAN for consoles and streaming sticks - semi-trusted, can reach Plex server only
A lab VLAN for VMs and containers I experiment with

At what point does this stop being useful and start being overhead you never maintain properly? I know people who have 10+ VLANs and their firewall rules are a mess.

What is your segmentation like and where did you draw the line?]]> <![CDATA[Pi-hole for network-wide ad blocking - tips, filter lists, and gotchas]]> https://talkativeturtles.club/showthread.php?tid=59 Mon, 22 Jun 2026 12:59:51 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=59
A few things I've learned:

Hardware: A Pi Zero 2 W is more than enough for a home network. Alternatively, run it in Docker on whatever box is already on 24/7.

Filter lists worth using:

Steven Black's Unified Hosts (the default)
OISD Full - very comprehensive, regularly maintained
Hagezi's Multi Pro - aggressive but well-curated

Steven Black's Unified Hosts (the default)
OISD Full - very comprehensive, regularly maintained
Hagezi's Multi Pro - aggressive but well-curated

Avoid adding too many lists. The diminishing returns kick in fast and you'll start breaking sites you actually want to use. Start with 2-3 good lists.

Whitelist early and often. Some CDNs double as ad networks. Keep a note of what you've whitelisted and why.

Set up a secondary DNS. Pi-hole as primary, either another Pi-hole or your router's upstream as secondary. If Pi-hole goes down you still have connectivity.

Gravity updates: Set a weekly cron to run pihole -g to pull fresh blocklists.

Anyone running Unbound alongside Pi-hole for recursive DNS? Worth the extra setup?]]> <![CDATA[WireGuard vs OpenVPN vs Tailscale - what VPN setup are you running?]]> https://talkativeturtles.club/showthread.php?tid=58 Mon, 22 Jun 2026 12:52:51 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=58
WireGuard seems like the obvious modern choice - kernel-level on Linux, faster handshakes, smaller codebase (easier to audit), and the configs are tiny. The downside is managing key distribution manually and the lack of dynamic routing out of the box.

OpenVPN is battle-tested and supported everywhere. It's slower and the config files look like XML nightmares but it just works and there's a client for every platform.

Tailscale is interesting because it uses WireGuard under the hood but handles the key exchange and routing automatically via their coordination server. Free tier is generous. The trade-off is you're relying on their servers for control plane stuff - fine for personal use, maybe not for corporate.

I'm leaning toward WireGuard directly on an OPNsense box since I want full control and my use case is simple (a few trusted devices).

What are you running? Any pitfalls to watch out for? Is Tailscale actually worth it for home use or is rolling your own WireGuard not that painful?]]>
WireGuard seems like the obvious modern choice - kernel-level on Linux, faster handshakes, smaller codebase (easier to audit), and the configs are tiny. The downside is managing key distribution manually and the lack of dynamic routing out of the box.

OpenVPN is battle-tested and supported everywhere. It's slower and the config files look like XML nightmares but it just works and there's a client for every platform.

Tailscale is interesting because it uses WireGuard under the hood but handles the key exchange and routing automatically via their coordination server. Free tier is generous. The trade-off is you're relying on their servers for control plane stuff - fine for personal use, maybe not for corporate.

I'm leaning toward WireGuard directly on an OPNsense box since I want full control and my use case is simple (a few trusted devices).

What are you running? Any pitfalls to watch out for? Is Tailscale actually worth it for home use or is rolling your own WireGuard not that painful?]]> <![CDATA[Understanding TLS - what actually happens in an HTTPS connection]]> https://talkativeturtles.club/showthread.php?tid=101 Mon, 22 Jun 2026 12:06:40 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=101
The TLS handshake (simplified)

1. Client Hello - your browser sends: supported TLS versions, supported cipher suites (algorithms), a random number

2. Server Hello - server responds with: chosen TLS version and cipher suite, its certificate (contains the public key), another random number

3. Certificate verification - your browser checks the certificate:

Is it signed by a trusted Certificate Authority (CA)?
Is the domain name in the certificate the one you requested?
Has it expired?
Has it been revoked (OCSP check)?

4. Key exchange - both sides use the two random numbers plus the key exchange algorithm (usually ECDHE) to independently derive the same session key. The private key is never sent over the wire.

5. Symmetric encryption begins - all subsequent data is encrypted with the session key (AES-GCM typically). Asymmetric crypto (RSA/ECDSA) was only used to establish the session key.

Why this matters for developers:

Certificate pinning - you can assert that only a specific certificate is trusted, defeating CA compromise
HSTS - tells browsers to always use HTTPS for your domain, preventing downgrade attacks
TLS 1.3 vs 1.2 - 1.3 reduces the handshake to 1 round trip (vs 2), meaningfully faster
Mixed content - a single HTTP resource on an HTTPS page breaks the security model

Happy to go deeper on any part of this.]]>
The TLS handshake (simplified)

1. Client Hello - your browser sends: supported TLS versions, supported cipher suites (algorithms), a random number

2. Server Hello - server responds with: chosen TLS version and cipher suite, its certificate (contains the public key), another random number

3. Certificate verification - your browser checks the certificate:

Is it signed by a trusted Certificate Authority (CA)?
Is the domain name in the certificate the one you requested?
Has it expired?
Has it been revoked (OCSP check)?

Certificate pinning - you can assert that only a specific certificate is trusted, defeating CA compromise
HSTS - tells browsers to always use HTTPS for your domain, preventing downgrade attacks
TLS 1.3 vs 1.2 - 1.3 reduces the handshake to 1 round trip (vs 2), meaningfully faster
Mixed content - a single HTTP resource on an HTTPS page breaks the security model

Happy to go deeper on any part of this.]]> <![CDATA[SSH hardening checklist - locking down a new server]]> https://talkativeturtles.club/showthread.php?tid=100 Mon, 22 Jun 2026 11:55:45 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=100
Change the default SSH port (optional but reduces noise)

Code:
# /etc/ssh/sshd_config

Port 2222  # or any non-standard port

This doesn't improve security against targeted attacks but cuts automated scan noise by 90%.

Disable root login

Code:
PermitRootLogin no

Always. SSH in as a regular user and sudo when needed.

Disable password authentication (keys only)

Code:
PasswordAuthentication no

PubkeyAuthentication yes

Do this AFTER you've confirmed key-based login works. Locking yourself out is annoying.

Limit the login grace period

Code:
LoginGraceTime 20

MaxAuthTries 3

Specify allowed users

Code:
AllowUsers yourusername

Only accounts listed here can SSH in.

Disable unused features

Code:
X11Forwarding no

AllowAgentForwarding no

AllowTcpForwarding no  # unless you need tunnels

PermitTunnel no

Use a modern key algorithm
Generate keys with ssh-keygen -t ed25519. If you have old RSA keys on the server, keep them but prefer ed25519 for new ones.

Install fail2ban

Code:
sudo apt install fail2ban

# Default config jails SSH after 5 failed attempts

sudo systemctl enable --now fail2ban

After all changes:

Code:
sudo sshd -t          # test config syntax before reloading

sudo systemctl reload sshd

Keep your current session open and test login in a new terminal before closing anything. Never reload SSH blind.]]>
Change the default SSH port (optional but reduces noise)

Code:
# /etc/ssh/sshd_config

Port 2222  # or any non-standard port

This doesn't improve security against targeted attacks but cuts automated scan noise by 90%.

Disable root login

Code:
PermitRootLogin no

Always. SSH in as a regular user and sudo when needed.

Disable password authentication (keys only)

Code:
PasswordAuthentication no

PubkeyAuthentication yes

Do this AFTER you've confirmed key-based login works. Locking yourself out is annoying.

Limit the login grace period

Code:
LoginGraceTime 20

MaxAuthTries 3

Specify allowed users

Code:
AllowUsers yourusername

Only accounts listed here can SSH in.

Disable unused features

Code:
X11Forwarding no

AllowAgentForwarding no

AllowTcpForwarding no  # unless you need tunnels

PermitTunnel no

Use a modern key algorithm
Generate keys with ssh-keygen -t ed25519. If you have old RSA keys on the server, keep them but prefer ed25519 for new ones.

Install fail2ban

Code:
sudo apt install fail2ban

# Default config jails SSH after 5 failed attempts

sudo systemctl enable --now fail2ban

After all changes:

Code:
sudo sshd -t          # test config syntax before reloading

sudo systemctl reload sshd

Keep your current session open and test login in a new terminal before closing anything. Never reload SSH blind.]]> <![CDATA[Home lab setups - what are you running?]]> https://talkativeturtles.club/showthread.php?tid=35 Sun, 21 Jun 2026 09:42:20 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=35
My current setup:

Mikrotik hEX router - running RouterOS, configured VLANs for IoT, trusted, and guest networks
Unmanaged TP-Link switch for the wired side
Proxmox box on old Optiplex 7050 - running pfSense VM, a few Debian VMs for services, and a Kali VM for playing around
Pi-hole on a Pi 4 for DNS filtering
Wireguard VPN for remote access

Mikrotik hEX router - running RouterOS, configured VLANs for IoT, trusted, and guest networks
Unmanaged TP-Link switch for the wired side
Proxmox box on old Optiplex 7050 - running pfSense VM, a few Debian VMs for services, and a Kali VM for playing around
Pi-hole on a Pi 4 for DNS filtering
Wireguard VPN for remote access

Considering adding an IDS (Suricata on pfSense) and a SIEM (probably Wazuh or Graylog) but I keep talking myself out of the complexity.

What does your home lab look like? Also curious what people use for remote access - Wireguard, Tailscale, ZeroTier?]]> <![CDATA[[Resources] CTF Platforms & Cybersecurity Learning]]> https://talkativeturtles.club/showthread.php?tid=34 Sun, 21 Jun 2026 09:42:20 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=34 CTF Platforms (Capture the Flag)

HackTheBox (hackthebox.com) - Real-world labs, active community, great for pentesting practice
TryHackMe (tryhackme.com) - More guided, good for beginners, browser-based VMs
PicoCTF (picoctf.org) - Carnegie Mellon's CTF, archived challenges always available
CTFtime (ctftime.org) - Calendar of upcoming CTF competitions worldwide
pwn.college - Arizona State, fantastic for binary exploitation

Free Learning Platforms

OWASP WebGoat - Deliberately insecure web app for learning web vulns
PortSwigger Web Academy (portswigger.net/web-security) - Best free web app security course, full stop
Cybrary - Mix of free and paid courses
SANS Cyber Aces - Free intro to OS, networking, sys admin security

Certifications Worth Considering

CompTIA Security+ - Good entry-level, vendor-neutral
CompTIA Network+ - If you want to nail networking fundamentals first
CEH (Certified Ethical Hacker) - Industry recognised but heavily theory-based
OSCP (Offensive Security) - Hands-on, respected in pentesting roles, hard

Books

"The Web Application Hacker's Handbook"
"Hacking: The Art of Exploitation" - Erickson
"Penetration Testing" - Georgia Weidman

]]> CTF Platforms (Capture the Flag)

HackTheBox (hackthebox.com) - Real-world labs, active community, great for pentesting practice
TryHackMe (tryhackme.com) - More guided, good for beginners, browser-based VMs
PicoCTF (picoctf.org) - Carnegie Mellon's CTF, archived challenges always available
CTFtime (ctftime.org) - Calendar of upcoming CTF competitions worldwide
pwn.college - Arizona State, fantastic for binary exploitation

Free Learning Platforms

OWASP WebGoat - Deliberately insecure web app for learning web vulns
PortSwigger Web Academy (portswigger.net/web-security) - Best free web app security course, full stop
Cybrary - Mix of free and paid courses
SANS Cyber Aces - Free intro to OS, networking, sys admin security

Certifications Worth Considering

CompTIA Security+ - Good entry-level, vendor-neutral
CompTIA Network+ - If you want to nail networking fundamentals first
CEH (Certified Ethical Hacker) - Industry recognised but heavily theory-based
OSCP (Offensive Security) - Hands-on, respected in pentesting roles, hard

Books

"The Web Application Hacker's Handbook"
"Hacking: The Art of Exploitation" - Erickson
"Penetration Testing" - Georgia Weidman

]]> <![CDATA[[Rules] Networking & Cybersecurity — Forum Rules]]> https://talkativeturtles.club/showthread.php?tid=7 Sun, 21 Jun 2026 09:34:07 +0000 Zero Two]]> https://talkativeturtles.club/showthread.php?tid=7 Networking & Cybersecurity covers protocols, infrastructure, security research, CTFs, pentesting, and defensive practices.

Posting Rules:

This is a strictly ethical community. Discussion of offensive security techniques is permitted only in educational, CTF, or clearly authorized contexts. Do not ask for help attacking systems you do not own.
No tools or techniques for malicious purposes. Posts requesting help with unauthorized access, credential theft, DDoS, or malware will be removed and the account banned.
Redact sensitive data. If sharing logs, configs, or packet captures, remove IP addresses, credentials, and personal data that are not yours.
Include your topology. Networking questions need your equipment, ISP setup, and relevant IP scheme (use private ranges in examples).
Cite your sources for security advisories and CVEs.

Remember: "I own the network" claims are not verifiable. Posts that appear to target real systems will be removed regardless of stated intent.]]> Networking & Cybersecurity covers protocols, infrastructure, security research, CTFs, pentesting, and defensive practices.

Posting Rules:

This is a strictly ethical community. Discussion of offensive security techniques is permitted only in educational, CTF, or clearly authorized contexts. Do not ask for help attacking systems you do not own.
No tools or techniques for malicious purposes. Posts requesting help with unauthorized access, credential theft, DDoS, or malware will be removed and the account banned.
Redact sensitive data. If sharing logs, configs, or packet captures, remove IP addresses, credentials, and personal data that are not yours.
Include your topology. Networking questions need your equipment, ISP setup, and relevant IP scheme (use private ranges in examples).
Cite your sources for security advisories and CVEs.

Remember: "I own the network" claims are not verifiable. Posts that appear to target real systems will be removed regardless of stated intent.]]>