İki yıl önce, kendi evimde kurduğum küçük bir Kubernetes kümesini internete açmaya karar verdiğimde, ilk 7 dakikada SSH portuma 3 farklı IP adresinden brute-force saldırısı başladığını gördüm. Bu olay, homelab’ımızı dış dünyaya açmanın ne kadar hızlı bir şekilde hedef haline getirebileceğini ve güvenlik adımlarının ne kadar kritik olduğunu bana bir kez daha hatırlattı. Bu yazıda, kendi deneyimlerimden yola çıkarak, homelab’ınızı internete açmadan önce mutlaka uygulamanız gereken 7 kritik güvenlik adımını detaylandıracağım.
Homelab’ınızı internete açmak, size esneklik ve erişilebilirlik sağlasa da, beraberinde ciddi güvenlik risklerini de getirir. Bu adımlar, sadece basit bir kontrol listesi değil, yıllar içinde edindiğim tecrübelerin ve yaşadığım bazı “yangınların” birer dersidir. Her adım, potansiyel bir saldırı vektörünü kapatmaya ve sistemlerinizi daha dirençli hale getirmeye odaklanıyor.
Ağ Segmentasyonu ve Firewall Kuralları Neden Kritik?
Bir homelab’ı internete açarken ilk ve en önemli adım, ağınızı mantıksal olarak bölümlere ayırmak ve bu bölümler arasındaki trafiği sıkı kurallarla yönetmektir. Ben kendi homelab’imde kritik servisleri (veri tabanları, yönetim arayüzleri) internete açık olan web servislerinden VLAN’lar aracılığıyla ayırıyorum. Bu, bir web uygulamasında zafiyet bulunsa bile, saldırganın iç ağdaki diğer sistemlere kolayca erişememesini sağlar.
Firewall kuralları, ağ segmentasyonunu tamamlayan temel bir katmandır. Sadece ihtiyacınız olan portları ve protokolleri dış dünyaya açmalı, geri kalan her şeyi varsayılan olarak engellemelisiniz. Örneğin, bir web sunucusu için sadece 80 (HTTP) ve 443 (HTTPS) portlarını açarken, SSH (22) portunu sadece belirli bir IP adresinden veya VPN üzerinden erişime açık tutmak mantıklıdır. Ben genellikle ufw (Uncomplicated Firewall) kullanıyorum çünkü hızlı ve anlaşılır bir sentaksı var.
# Sadece SSH (22), HTTP (80) ve HTTPS (443) portlarına izin ver
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp from 192.168.1.100 # Sadece belirli IP'den SSH izni
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enableGeçen yıl bir müşterinin test ortamında, sanal bir makineye yanlışlıkla tüm portları açan bir firewall kuralı tanımladığımı fark ettim. Yaklaşık 4 saat sonra bir uyarı aldım: PostgreSQL portu (5432) üzerinden dışarıdan bağlantı denemeleri vardı. Neyse ki, bu sadece bir test sunucusuydu ve kritik bir veri içermiyordu ama bu olay bana, firewall kurallarını her zaman “en az yetki” prensibiyle tanımlamam gerektiğini bir kez daha gösterdi. Ağ segmentasyonu ve doğru firewall kuralları, saldırı yüzeyinizi minimize etmenin ilk ve en etkili yoludur.
Güvenli Uzaktan Erişim Nasıl Sağlanır?
Homelab’ınıza internet üzerinden erişim sağlamanın en güvenli yolu, doğrudan portları açmak yerine bir VPN veya SSH bastion host kullanmaktır. Doğrudan SSH portunu (varsayılan 22) internete açmak, yukarıda bahsettiğim gibi saniyeler içinde hedef haline gelmenize neden olur. Ben kendi homelab’imde WireGuard tabanlı bir VPN kullanıyorum. Bu, tüm trafiğimi şifreleyerek ve sadece VPN tüneli üzerinden erişime izin vererek, dışarıdan gelebilecek birçok tehdidi engelliyor.
SSH anahtarları kullanmak, parola tabanlı kimlik doğrulamasından çok daha güvenlidir. Kendi sunucularımda password authentication no ayarını yapıp sadece güçlü, şifre korumalı SSH anahtarları ile erişime izin veriyorum. Ayrıca, bir SSH bastion host kurarak, tüm dış SSH erişimlerini tek bir noktadan yönetiyor ve iç ağdaki diğer sunuculara sadece bu bastion üzerinden atlayarak erişiyorum. Bu, iç sunucuların SSH portlarının internete kapalı kalmasını sağlıyor.
# /etc/ssh/sshd_config dosyasında yapılması gereken kritik ayarlar
Port 22222 # Varsayılan 22 yerine farklı bir port
PasswordAuthentication no # Parola ile erişimi kapat
PermitRootLogin no # Root kullanıcısının direkt girişini engelle
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers mustafa # Sadece belirli kullanıcılara izin ver
# fail2ban için basit bir konfigürasyon (jail.local)
[sshd]
enabled = true
port = 22222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600 # 1 saat yasaklaBir yan ürünümün backend sunucusunda, SSH portunu farklı bir porta taşımış olsam da fail2ban kurmayı unutmuştum. Yaklaşık bir hafta sonra logları incelerken, onlarca farklı IP adresinden sürekli olarak SSH denemeleri olduğunu fark ettim. Bu, bana basit bir fail2ban kurulumunun bile ne kadar önemli olduğunu bir kez daha gösterdi. Güvenli uzaktan erişim, homelab’ınızın dış dünyaya açılan kapısını sağlam tutmanın anahtarıdır.
Servislerin Minimum Yetkiyle Çalışması Neden Önemli?
Homelab’ınızda çalışan her servis, potansiyel bir güvenlik açığıdır. Bu servislerin minimum yetki prensibiyle çalışmasını sağlamak, olası bir zafiyet durumunda saldırganın sisteminizde yapabileceği zararı büyük ölçüde sınırlar. Bir web sunucusu, bir veritabanı sunucusu veya bir container uygulaması olsun, hiçbir servis root yetkileriyle çalışmamalıdır.
Ben genellikle systemd unit’leri kullanarak servisleri belirli bir kullanıcı ve grup altında çalıştırıyorum. Örneğin, Nginx web sunucusu www-data kullanıcısı altında çalışırken, PostgreSQL postgres kullanıcısı altında çalışır. Bu kullanıcıların sistemde başka hiçbir yetkisi olmamalıdır. Ayrıca, systemd’nin CapabilityBoundingSet, PrivateTmp, NoNewPrivileges gibi güvenlik özelliklerini aktif olarak kullanıyorum.
# Örnek bir systemd unit dosyası (/etc/systemd/system/myservice.service)
[Unit]
Description=My Awesome Service
After=network.target
[Service]
ExecStart=/usr/local/bin/myservice
User=myserviceuser # Servisi bu kullanıcı altında çalıştır
Group=myservicegroup # Servisi bu grup altında çalıştır
WorkingDirectory=/opt/myservice
ReadWritePaths=/opt/myservice/data # Sadece bu dizine yazma izni ver
CapabilityBoundingSet=CAP_NET_BIND_SERVICE # Sadece gerekli yetkileri ver
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
[Install]
WantedBy=multi-user.targetBir üretim ERP’sinde çalışırken, bir servis yanlışlıkla root yetkileriyle çalışacak şekilde yapılandırılmıştı. Bir zafiyet keşfedildiğinde, saldırganın sistemi tamamen ele geçirmesi saniyeler sürdü. Bu, bana servislerin yetki izolasyonunun sadece bir iyi uygulama değil, aynı zamanda hayati bir güvenlik önlemi olduğunu öğretti. Container’lar için de aynı prensip geçerli; Docker container’larını non-root kullanıcılarla çalıştırmak ve container’a sadece gerekli yetkileri vermek kritik öneme sahiptir.
Güncel Tutma ve CVE Takibi Neden Gerekli?
Yazılımları güncel tutmak, güvenlik yamalarını zamanında uygulamak ve CVE (Common Vulnerabilities and Exposures) bildirimlerini takip etmek, homelab’ınızın güvenliğini sağlamanın sürekli bir parçasıdır. Geliştiriciler, sürekli olarak yeni güvenlik açıklarını keşfeder ve bunlar için yamalar yayınlar. Bu yamaları uygulamamak, sisteminizi bilinen zafiyetlere karşı savunmasız bırakır.
Ben genellikle Linux sunucularımda unattended-upgrades paketini kurarak güvenlik güncellemelerinin otomatik olarak uygulanmasını sağlıyorum. Ancak bu, her zaman yeterli değildir. Özellikle kritik servisler ve çekirdek (kernel) güncellemeleri için manuel kontrol ve dikkatli bir planlama yapıyorum. CVE veritabanlarını ve ilgili güvenlik listelerini (örneğin, NVD - National Vulnerability Database) düzenli olarak takip ediyorum.
Bir keresinde, bir hafta sonu bir sunucumda kurulu olan bir HTTP proxy yazılımının eski bir versiyonunu kullandığımı fark ettim. O yazılımda yaklaşık 3 ay önce kritik bir uzaktan kod çalıştırma (RCE) zafiyeti kapatılmıştı. Şans eseri, bu zafiyet henüz kötüye kullanılmamıştı. Bu durum, otomatik güncellemelerin yanı sıra, kurulu tüm yazılımların versiyonlarını ve bilinen CVE’lerini düzenli olarak kontrol etmenin ne kadar önemli olduğunu gösterdi. dpkg -l komutuyla kurulu paketleri listeler ve ara sıra manuel olarak kontrol ederim.
# Debian/Ubuntu için otomatik güvenlik güncellemelerini etkinleştirme
sudo apt update
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades # Kurulum sihirbazını çalıştırGüncel kalmak, sürekli bir çaba gerektirir ancak bu çaba, potansiyel bir siber saldırının yaratacağı maliyet ve itibarı düşününce kesinlikle değerlidir. Eski bir yazılım veya güncellenmemiş bir kernel, homelab’ınızı bir “açık kapı” haline getirebilir.
Loglama ve İzleme (Observability) Neden Hayati?
Bir homelab’ı internete açtığınızda, sistemlerinizde neler olup bittiğini anlamak için güçlü bir loglama ve izleme altyapısına sahip olmalısınız. Saldırılar genellikle anlık olmaz; saldırganlar sistemde iz bırakmaya çalışır. Bu izleri tespit etmek ve bunlara tepki vermek için loglara ve metrik verilere ihtiyacınız vardır. Ben kendi sistemlerimde journald ile merkezi log toplama ve Prometheus/Grafana ile metrik izleme yapıyorum.
journald, Linux sistemlerinde logları toplamak ve yönetmek için harika bir araçtır. Tüm servislerin ve sistem bileşenlerinin loglarını tek bir yerden erişilebilir kılar. Ayrıca, auditd servisiyle sistem çağrılarını, dosya erişimlerini ve yetki yükseltme denemelerini izleyerek daha derinlemesine güvenlik denetimi sağlıyorum. Bir saldırı anında veya sonrasında, bu loglar adli analiz için kritik öneme sahiptir.
graph TD; A["Web Sunucusu (Nginx)"] --> B["journald"]; C["Veritabanı (PostgreSQL)"] --> B; D["Uygulama Servisi"] --> B; B --> E["Grafana (Log Viewer)"]; F["Prometheus Exporter"] --> G["Prometheus Server"]; G --> E; E -- "Uyarılar" --> H["Mustafa'nın Telefonu"];
Prometheus ve Grafana kombinasyonu, homelab’ımdaki her şeyin (CPU, bellek, disk I/O, ağ trafiği, uygulama metrikleri) anlık durumunu görselleştirmemi sağlıyor. Belirlenen eşik değerleri aşıldığında (örneğin, bir sunucunun CPU kullanımı %90’ın üzerine çıktığında veya disk doluluğu %80’i aştığında), bana anında bildirim gönderiliyor. Bu, anomali tespiti için vazgeçilmezdir.
# Belirli bir servisin son 100 logunu görüntüleme
journalctl -u nginx.service -n 100
# Belirli bir zaman aralığındaki başarısız SSH denemelerini bulma
journalctl _COMM=sshd | grep "Failed password" | tail -n 20
# auditd ile dosya erişimlerini izleme (örnek kural)
# /etc/audit/rules.d/10-custom.rules
# -w /etc/passwd -p wa -k passwd_changes
# sudo service auditd restartGeçtiğimiz kış, kendi sunucularımda bir Redis sunucusunun aniden yüksek CPU tüketmeye başladığını fark ettim. Grafana dashboard’umda anomali net bir şekilde görünüyordu. Logları incelediğimde, dışarıdan gelen çok sayıda bağlantı denemesi olduğunu ve Redis’in bir miktar brute-force saldırısına maruz kaldığını gördüm. Eğer izleme sistemim olmasaydı, bu durumu çok daha geç fark edebilir ve daha ciddi sorunlarla karşılaşabilirdim. Loglama ve izleme, homelab’ınızın “gözleri ve kulaklarıdır.”
Güçlü Şifre Politikaları ve Çok Faktörlü Kimlik Doğrulama (MFA) Neden Şart?
Homelab’ınızdaki tüm hesaplar için güçlü ve benzersiz şifreler kullanmak ve mümkün olan her yerde Çok Faktörlü Kimlik Doğrulama (MFA) uygulamak, siber güvenliğin temel direklerinden biridir. Zayıf şifreler, bir saldırganın sisteminize erişmesi için en kolay yollardan biridir. Çoğu zaman, kullanıcılar aynı şifreyi birden fazla yerde kullanır ve bu da “credential stuffing” saldırılarına zemin hazırlar.
Ben tüm şifrelerimi bir şifre yöneticisi (örneğin, Bitwarden veya Keepass) kullanarak oluşturuyor ve yönetiyorum. Bu sayede her servis için 16 karakterden uzun, karmaşık ve benzersiz şifreler kullanabiliyorum. Ayrıca, SSH erişimi, sunucu panelleri, web servisleri ve hatta VPN bağlantıları dahil olmak üzere mümkün olan her yerde MFA (örneğin, TOTP tabanlı Google Authenticator veya FIDO2 güvenlik anahtarları) kullanıyorum.
Bir müşteri projesinde, eski bir sistemde bir kullanıcının şifresini yaklaşık 10 dakika içinde “rockyou.txt” gibi yaygın bir parola listesiyle kırmayı başardım. Bu, bana şifre politikalarının sadece bir kural değil, gerçekten bir güvenlik katmanı olduğunu gösterdi. Özellikle internete açık herhangi bir servisin kullanıcı hesapları için MFA zorunluluğu getirmek, erişim güvenliğini dramatik şekilde artırır.
# Debian/Ubuntu'da PAM ile TOTP MFA kurulumu (basit örnek)
sudo apt install libpam-google-authenticator
# Her kullanıcı kendi ev dizininde google-authenticator komutunu çalıştırır
# Bu, /home/kullanici/.google_authenticator dosyasını oluşturur ve QR kodunu gösterir.
# /etc/pam.d/sshd dosyasına aşağıdaki satırı ekleyin:
# auth required pam_google_authenticator.soGüçlü şifreler ve MFA, homelab’ınızın dışarıdan gelebilecek yetkisiz erişim denemelerine karşı ilk ve en kritik savunma hattını oluşturur. Bu iki prensip olmadan, diğer tüm güvenlik önlemleri zayıf kalır.
Yedekleme ve Kurtarma Planı Neden Olmazsa Olmaz?
Tüm güvenlik önlemlerine rağmen, bir saldırı veya donanım arızası her zaman mümkündür. İşte bu yüzden, kapsamlı bir yedekleme ve kurtarma planına sahip olmak homelab’ınız için olmazsa olmazdır. Verilerinizin düzenli olarak yedeklenmesi ve bu yedeklerin güvenli bir yerde saklanması, felaket durumunda verilerinizi kaybetmenizi engeller.
Ben kendi homelab’imde kritik verileri günlük olarak borgbackup ile şifreli bir şekilde harici bir diske veya bulut depolama alanına yedekliyorum. borgbackup, deduplication özelliği sayesinde yedekleme boyutunu minimize ederken, verilerin bütünlüğünü ve gizliliğini de sağlar. Ayrıca, yedekleme planımın bir parçası olarak, zaman zaman bu yedeklerden geri yükleme denemeleri yaparak kurtarma planımın işe yaradığından emin oluyorum.
Geçen yıl, bir RAID dizisindeki disklerden biri bozuldu ve sunucumdaki tüm veriler erişilemez hale geldi. Neyse ki, düzenli yedeklemelerim vardı ve yaklaşık 6 saat içinde tüm sistemi yeni disklere geri yükleyebildim. Bu olay, bana sadece yedeklemenin değil, aynı zamanda yedeklerin periyodik olarak test edilmesinin de ne kadar önemli olduğunu gösterdi. Bir yedek, işe yaramıyorsa hiçbir anlam ifade etmez.
# borgbackup ile basit bir yedekleme komutu
# Önce bir repository oluşturulur: borg init --encryption=repokey-blake2 /mnt/backup/my_repo
# Ardından yedek alınır:
borg create --stats --progress /mnt/backup/my_repo::'{hostname}-{now}' /home/mustafa/data /var/www/htmlYedekleme ve kurtarma planı, güvenlik zincirindeki son halkadır. Tüm önleyici tedbirlerin başarısız olması durumunda, verilerinizi koruyacak ve operasyonlarınızın devamlılığını sağlayacak tek şey budur. Bu yüzden, bu adımı asla göz ardı etmeyin.
Güvenlik Denetimleri ve Sürekli İyileştirme Nasıl Yapılır?
Homelab güvenliği, bir kez yapılıp biten bir süreç değildir; sürekli bir denetim ve iyileştirme döngüsüdür. Yeni zafiyetler ortaya çıktıkça, yazılımlar güncellendikçe veya yeni servisler ekledikçe, güvenlik duruşunuzu yeniden değerlendirmeniz gerekir. Düzenli güvenlik denetimleri yapmak ve bulunan zafiyetleri gidermek, homelab’ınızın uzun vadeli güvenliğini sağlar.
Ben kendi homelab’imde basit güvenlik tarayıcıları (örneğin, nmap ile port taramaları veya nikto ile web zafiyet taramaları) kullanarak dışarıdan nasıl göründüğümü kontrol ediyorum. Ayrıca, auditd loglarını düzenli olarak gözden geçirerek veya logwatch gibi araçlarla özet raporlar alarak olağandışı aktiviteleri tespit etmeye çalışıyorum. Bu, bir saldırganın içeriden veya dışarıdan sistemime sızmaya çalışıp çalışmadığını anlamama yardımcı oluyor.
Homelab’ıma yeni bir servis eklediğimde, varsayılan olarak tüm güvenlik adımlarını (firewall, yetki, loglama) uyguluyorum ve yayınlamadan önce mutlaka bir iç güvenlik denetimi yapıyorum. Birkaç yıl önce, kendi Android spam uygulamamın backend’ine yeni bir API eklediğimde, rate limiting (istek sınırlaması) uygulamayı unutmuştum. Bir süre sonra API’ye çok sayıda istek geldiğini fark ettim ve bu durum, sunucunun performansını olumsuz etkiliyordu. Bu basit hata, bana her yeni eklentinin veya değişikliğin güvenlik açısından dikkatlice değerlendirilmesi gerektiğini hatırlattı.
# Kendi homelab sunucumda dışarıdan açık portları tarama
nmap -sV -p- localhost
# veya
nmap -sV -p- <DIŞ_IP_ADRESİM> # İnternet üzerinden dışarıdan nasıl göründüğümü kontrol etmek içinGüvenlik denetimleri ve sürekli iyileştirme, homelab’ınızın değişen tehdit ortamına uyum sağlamasını ve uzun vadede güvende kalmasını sağlar. Unutmayın, güvenlik bir varış noktası değil, sürekli bir yolculuktur.
Sonuç: Homelab Güvenliği Bir Zihniyet Meselesidir
Homelab’ımı internete açtığım ilk günlerde yaşadığım brute-force saldırısı, bana güvenlik konusunda proaktif olmanın ne kadar kritik olduğunu öğretti. Bu 7 adım, benim yıllar içinde edindiğim tecrübelerin ve karşılaştığım sorunların bir özetidir. Ağ segmentasyonundan yedeklemeye, her adım homelab’ınızın siber saldırılara karşı daha dirençli olmasını sağlamak içindir.
Unutmamak gerekir ki, hiçbir sistem %100 güvenli değildir. Ancak bu adımları uygulayarak, saldırı yüzeyinizi önemli ölçüde azaltır, olası bir saldırının etkisini minimize eder ve sistemlerinizin sürekli olarak izlenmesini sağlarsınız. Homelab’ınızı internete açarken gösterdiğiniz bu özen, sadece kendi verilerinizi değil, aynı zamanda bağlı olduğunuz ağları ve diğer kullanıcıları da korumanıza yardımcı olur. Güvenlik, bir ürün değil, bir zihniyet meselesidir; sürekli dikkat ve öğrenme gerektirir.