Homelab Bölüm 11: Final pfSense Firewall Kuralları ve Segmentasyon Hardening

Part 10 ile Windows identity katmanını eklemiştim: Active Directory, DNS, DHCP ve domain-joined client. Bu bölümde lab’i “kurulum sırasında herkes herkesle konuşsun” halinden açık bir firewall policy’ye taşıdım.

Amacım karmaşık kural yazmak değildi. Amacım her izinli yolun açıklanabilir olmasıydı.

Ne İnşa Ettim?

Geçici build-phase allow rule’larını segmentli pfSense policy ile değiştirdim:

Default duruş:    deny by default
Management:       Tailscale + break-glass LAN/WAN erişimi
Jumpbox:          Alpine üzerinden Kali SSH yolu
Client VLAN:      sadece AD, DNS, Wazuh, Windows Update
Container VLAN:   sadece Docker host + n8n explicit egress
Honeypot VLAN:    sadece Wazuh telemetry
Pentest VLAN:     internet egress yok
Isolated VLAN:    ingress yok, egress yok

Tailscale explicit management path'lere daraltıldı.

CLIENT kuralları sadece AD, DNS, Wazuh ve update path'lerini bırakıyor.

Container egress sadece named workload'lara veriliyor.

Neden Önemli?

Segmentasyon sadece VLAN ve subnet değildir. Bir segment, ancak firewall policy’si rolüyle uyumluysa anlamlı hale gelir.

Kurulum aşamasında geniş allow rule’lar faydalıydı. VM’ler update aldı, installer indirdi, domain’e join oldu, package pull yaptı ve hızlı troubleshoot edildi. Ama bu kuralları final halde bırakmak mimarinin güvenlik değerini büyük ölçüde silerdi.

Bu geçiş lab’i daha gerçekçi hale getirdi:

endpoint’ler domain servislerine erişiyor ama tüm lab’e erişmiyor;
Wazuh telemetry alıyor ama bu geniş erişim bahanesi olmuyor;
vulnerable sistemler contained kalıyor;
malware-analysis hostları dışarı kaçamıyor;
management erişimi normal network reachability’den ayrılıyor.

Topoloji Kesiti

Tailscale / MacBook
  |-- pfSense management
  |-- Proxmox management
  |-- Alpine jumpbox
  |-- Wazuh dashboard

DEFENCE / MANAGEMENT
  |-- DC / DNS / DHCP
  |-- Wazuh
  |-- Alpine jumpbox

CLIENT
  |-- Wazuh agent ve Sysmon olan Windows client

CONTAINER
  |-- Docker host
  |-- n8n
  |-- vulnerable container'lar

PENTEST
  |-- Kali
  |-- vulnerable target

HONEYPOT
  |-- T-Pot

ISOLATED
  |-- FLARE-VM
  |-- REMnux

Kurulum Adımları

VLAN 99’u İzole Etmek

Malware-analysis segmenti lab’in en katı policy’si. Bu normal bir user veya server network değil.

ISOLATED -> any: blocked
Diğer VLAN'lar -> ISOLATED: blocked

Her VLAN migrate edilirken block rule broad allow rule'un üstünde olmalı.

Buradaki kritik tasarım noktası şu: malware-analysis isolation hafızaya veya disipline bağlı olmamalı. Ben bir hostun ne yaptığını unutsam bile network path kapalı kalmalı.

Jumpbox’ı Management Yoluna Taşımak

Alpine VM erken kurulum altyapısı olarak başlamıştı. Lab olgunlaşınca onu management tarafına taşıdım ve stabil adres verdim.

Jumpbox: 10.10.10.50
Role:    controlled SSH pivot

Alpine jumpbox management/defence tarafına stabil IP ile taşındı.

Jumpbox rules: pfSense management ve Kali'ye SSH.

Jumpbox, Tailscale’in yerine geçmiyor. Tailscale remote access plane; jumpbox ise içerideki administrative pivot.

Management ve Domain Servislerini Sıkılaştırmak

Management tarafında DC, Wazuh ve jumpbox var. Bu yüzden bu segment kullanışlı kalmalı ama wide open olmamalı.

DC -> Internet:     update/NTP only
DC -> Wazuh:        reserved telemetry path
Jumpbox -> pfSense: SSH/HTTPS
Jumpbox -> Kali:    SSH
Management -> ISOLATED: blocked

Broad access yerine explicit path'lerle management ve DC rules.

Part 10’da Windows DC ve client için Wazuh agent baseline’ını hazırladım. Buradaki firewall kararı: telemetry path’leri any-any erişimin arkasına saklanmıyor, açıkça tanımlanıyor.

Client VLAN’i Sıkılaştırmak

Windows client’ın domain controller ve Wazuh’a ihtiyacı var, tüm lab’e değil.

CLIENT -> DC:     DNS, NTP, Kerberos, LDAP, SMB, RPC
CLIENT -> Wazuh:  Wazuh agent traffic
CLIENT -> Internet: Windows Update HTTP/HTTPS
CLIENT -> ISOLATED: blocked
CLIENT -> everything else: blocked

CLIENT domain ve telemetry servislerine erişebiliyor.

Final CLIENT rule kullanılmayan trafiği kapatıyor.

Bu sayede Windows endpoint AD ve Sysmon çalışmaları için gerçekçi kalıyor ama lab’in geri kalanına ücretsiz pivot olmuyor.

Honeypot Egress’i Kısıtlamak

Honeypot segmenti gözlemlenmeli, güvenilmemeli.

HONEYPOT -> Wazuh: TCP 1514
HONEYPOT -> ISOLATED: blocked
HONEYPOT -> everything else: blocked

HONEYPOT sadece Wazuh'a telemetry gönderebiliyor.

Bu T-Pot’u sensor island yapıyor. Gördüğünü raporlayabiliyor ama lab’e veya internete genel erişim almıyor.

Container Egress’i Kısıtlamak

Docker host update ve image pull için çıkışa ihtiyaç duyuyor. n8n outbound web access istiyor. Vulnerable container’ların internete ihtiyacı yok.

Docker host -> Wazuh: TCP 1514
Docker host -> DC:    DNS
Docker host -> Web:   HTTP/HTTPS
n8n -> DC:            DNS
n8n -> Web:           HTTP/HTTPS
Other containers:     blocked by default

Sadece Docker host ve n8n explicit outbound erişim alıyor.

Buradaki faydalı kural basit: container egress VLAN’a topluca verilmiyor. Named workload bazında veriliyor.

Pentest VLAN’i Kapatmak

Kali’nin bu aşamada direkt internet erişimine ihtiyacı yok. Araştırma ve indirmeleri MacBook’ta yapıyorum, Kali’ye jumpbox üzerinden ulaşıyorum.

Jumpbox -> Kali: SSH allowed
Kali -> Internet: blocked
PENTEST -> ISOLATED: blocked
PENTEST -> everything else: blocked

Bu Kali’yi lab içindeki attack VM olarak tutuyor, general-purpose workstation’a çevirmiyor.

Management ve Break-Glass Erişimi Tanımlamak

Tailscale’i primary management plane olarak tuttum. LAN ve WAN erişimi ise sadece MacBook’tan fallback yolu.

MacBook over Tailscale -> pfSense SSH/HTTPS
MacBook over Tailscale -> Proxmox SSH/8006
MacBook over Tailscale -> Wazuh HTTPS
MacBook over Tailscale -> Jumpbox SSH
Tailscale -> ISOLATED: blocked
Tailscale -> everything else: blocked

Tailscale management destination'larla sınırlı.

WAN break-glass access sadece MacBook alias'ı ile sınırlı.

LAN, genel lab erişimi değil local fallback path olarak kaldı.

Tasarım kararım bilinçliydi: management erişimi sadece home network’te fiziksel olarak bulunmaya değil, authenticated access’e ve bilinen admin hostlara bağlı olmalı.

Karşılaştığım Problemler

Interface yönü önemli. pfSense rule’u trafiğin girdiği interface’te değerlendirir. CLIENT-to-DC rule’u DC’nin interface’inde değil, CLIENT tabında olmalı.

This Firewall interface address’ten daha geniş. Dar management rule’larında LAN address veya WAN address, This Firewall‘dan daha hassas olabilir.

Tailscale source object değil, interface. Tailscale tabında source hâlâ MacBook’un Tailscale IP’si gibi bir IP veya alias.

DHCP reservation, unusual client identifier ile sinir bozabiliyor. Docker host için DHCP server’ın oluşturduğu stabil reservation’ı kabul ettim ve alias’ı o adrese göre yazdım.

Pass rule’lar default allow dururken sadece dokümantasyon gibi kalabilir. Allow list’in anlamlı olması için final deny rule şart.

Ne Öğrendim?

Firewall hardening’in çoğunlukla yön ve sahiplik meselesi olduğunu öğrendim. Her VLAN için üç soruya cevap vermem gerekti:

Bu segment ne tüketebilir?
Bu segment ne yayınlayabilir?
Buradan ne asla erişilebilir olmamalı?

Telemetry’nin de birinci sınıf network path olarak ele alınması gerektiğini öğrendim. Wazuh erişimi geniş rule’lardan yanlışlıkla miras kalmamalı; her ilgili segmentten açıkça izinli olmalı.

En büyük zihinsel değişim convenience ile architecture’ı ayırmak oldu. Build-phase access faydalıdır, ama son kullanma tarihi olmalı.

Doğrulama Kanıtı

Kuralları pratik reachability testleriyle doğruladım:

Kali sadece jumpbox üzerinden SSH ile erişilebilir
Kali direct internet erişimi kapalı
CLIENT domain discovery çalışıyor
CLIENT Wazuh/Sysmon telemetry Wazuh'a ulaşıyor
HONEYPOT Wazuh'a raporlayabiliyor
Docker host ve n8n sadece gerekli egress'i koruyor
ISOLATED routed lab segmentlerinden erişilemez
Tailscale management path'leri çalışıyor

Firewall pass sonrası CLIENT domain controller'ı bulabiliyor.

Sysmon Telemetry Smoke Test

Attack simulation’a geçmeden önce, hardening sonrası endpoint telemetry’nin hâlâ Wazuh’a ulaştığını doğruladım.

Windows client’a Sysmon kurdum, Wazuh agent configuration içine Sysmon Operational channel’ını ekledim, agent’ı restart ettim ve küçük bir PowerShell process event ürettim.

Wazuh Discover içinde şu query client1 event’lerini döndürdü:

data.win.system.providerName:"Microsoft-Windows-Sysmon"

Event’lerde powershell.exe, parent process metadata ve client agent identity görünüyordu. Bu henüz detection engineering değil. Sadece firewall değişikliğinin telemetry path’i bozmadığını kanıtlıyor.

Sırada Ne Var?

Lab’de artık identity, endpoint telemetry, network telemetry ve firewall segmentation hazır. Part 12’de controlled attack simulation ve raporlama aşamasına geçeceğim: küçük bir Atomic Red Team test seti çalıştırmak, Wazuh/Sysmon event’lerini toplamak ve detection’ların gerçekten ne gösterdiğini açıklamak.

Hızlı Referans

Default rule model:
  gerekli service path'leri allow
  ISOLATED'i explicit block
  geri kalan her şeyi block

Core telemetry:
  CLIENT   -> WAZUH TCP 1514
  DC       -> WAZUH TCP 1514
  DOCKER   -> WAZUH TCP 1514
  HONEYPOT -> WAZUH TCP 1514

Core identity:
  CLIENT -> DC DNS/Kerberos/LDAP/SMB/RPC

Management:
  MacBook Tailscale IP -> pfSense / Proxmox / Wazuh / Jumpbox
  MacBook LAN/WAN IP   -> pfSense break-glass only

Ne İnşa Ettim?#

Neden Önemli?#

Topoloji Kesiti#

Kurulum Adımları#

VLAN 99’u İzole Etmek#

Jumpbox’ı Management Yoluna Taşımak#

Management ve Domain Servislerini Sıkılaştırmak#

Client VLAN’i Sıkılaştırmak#

Honeypot Egress’i Kısıtlamak#

Container Egress’i Kısıtlamak#

Pentest VLAN’i Kapatmak#

Management ve Break-Glass Erişimi Tanımlamak#

Karşılaştığım Problemler#

Ne Öğrendim?#

Doğrulama Kanıtı#

Sysmon Telemetry Smoke Test#

Sırada Ne Var?#

Hızlı Referans#