معماری Zero-Trust برای SSH و VPN

بعد از چند incident کوچک فهمیدم فقط بستن پورت 22 کافی نیست. باید کل مسیر دسترسی admin را بازطراحی کنم.

#اصول

• هیچ trust پیش‌فرضی — حتی داخل LAN
• Least privilege — هر کلید فقط یک role
• Audit — هر session لاگ شود

«Security is a process, not a product.» — Bruce Schneier

#لایهٔ ۱: SSH hardening

فایل /etc/ssh/sshd_config.d/99-hardening.conf:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
AllowUsers deploy admin

کلیدها با comment معنادار:

ssh-keygen -t ed25519 -C "masoud@laptop-2026" -f ~/.ssh/id_ed25519_personal

#لایهٔ ۲: WireGuard mesh

[Interface]
PrivateKey = <REDACTED>
Address = 10.66.0.2/32
DNS = 10.66.0.1

[Peer]
PublicKey = <SERVER_PUBKEY>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.66.0.0/24
PersistentKeepalive = 25

#لایهٔ ۳: firewall

nft add rule inet filter input ip saddr 10.66.0.0/24 tcp dport 22 accept
nft add rule inet filter input tcp dport 22 drop

#rollout checklist

• کلیدهای قدیمی revoke
• PasswordAuth off
• VPN قبل از بستن SSH public
• session recording با tlog
• تست disaster: «لپ‌تاپ گم شد»

#مقایسهٔ قبل/بعد

#لینک‌های مرتبط

• سخت‌کردن SSH
• جداسازی سرویس با Docker
• RFC: https://datatracker.ietf.org/doc/html/rfc4251

#نتیجه

دسترسی مستقیم از اینترنت حذف شد. هزینهٔ operational کمی بالا رفت، اما سطح ریسک به‌شکل محسوسی پایین آمد.