Web sunucunuzun yarın ele geçirildiğini varsayalım. Buradan başka hangi cihazlara erişilebilir? Bu sorunun yanıtı, olayın tek bir hizmetle sınırlı kalmasını veya işletmenin diğer bölümlerini de tehlikeye atmasını etkiler. Bir yama bilinen bir güvenlik açığına karşı koruma sağlar. İyi tasarlanmış bir ağ ise olası sonuçları da sınırlar.
Örneğimiz kurgusal bir müşteri portalıdır: kullanıcılar oturum açar, siparişleri görüntüler ve belgeleri indirir. Uygulama, tanımlanmış bir veritabanı bağlantısına ihtiyaç duyar. Bu, NAS yönetimine, yedekleme sunucusuna veya sanallaştırma ana makinesine de erişmesi gerektiği anlamına gelmez. Bu ayrım teknik kurallarla uygulanmalıdır.
Ele geçirilen hizmet mevcut yolları kullanır
Bir güvenlik açığı, yabancı kodun web uygulamasının yetkileriyle çalışmasına izin verebilir. Sonrasında neler yapılabileceği; ağ kurallarına, hizmet hesaplarına, kayıtlı kimlik bilgilerine ve başka güvenlik açıklarına bağlıdır. Ağ üzerinden ulaşılabilir olmak, başarılı erişim anlamına gelmez. Ele geçirilen bir web sunucusu da tüm LAN’ı otomatik olarak kontrol altına almaz.
Erişilebilen iç hizmetler gereğinden geniş yetkilerle birleştiğinde risk büyür. Saldırganın aşması gereken sınırlar azalır. Başka sistemlere doğru bu olası ilerlemeye yanal hareket denir. Bu nedenle tasarım sırasında bir uygulamanın zaten ele geçirilmiş olduğunu varsaymak yararlıdır.
A ağı: portal düz bir şirket ağında bulunur
İlk yapıda portal, veritabanı, dosya depolama alanı ve yönetim arayüzleri aynı ağı paylaşır. Çevre güvenlik duvarı gelen bağlantıları sınırlar. Ancak iç sistemler arasında geniş izinler vardır veya yeterli ayrım yoktur. Bu yüzden web sunucusu, görevi için gerekenden daha fazla sisteme ulaşabilir.
Ortak kullanılan bir yönetici hesabı durumu ağırlaştırır. Yazma izniyle bağlanmış bir yedekleme dizini ya da uygulama dizininde tutulan geniş yetkili kimlik bilgileri de aynı etkiyi yaratır. Ele geçirilen hizmet yedekleme yönetimini veya tüm yedek kopyaları değiştirebiliyorsa çalışan bir yedek çok az güvence sağlar.
B ağı: bölgeler ve kurallar bağlantıları sınırlar
İkinci yapıda internet istekleri önce tanımlanmış bir ön uca veya ters proxy’ye ulaşır. Bu bileşen, ayrı bir web segmentindeki gerekli uygulamaya bağlanabilir. Uygulamaya yalnızca belirlenmiş veritabanı hedefine giden zorunlu bağlantı verilir. Yönetim, yedekleme sistemleri ve diğer iç hizmetler ayrı bölgelerde bulunur; web segmentinden gereksiz erişimler engellenir.
VLAN, ağı mantıksal olarak böler. Bu ayrımın etkili bir güvenlik sınırına dönüşmesini bağlantıların denetimi belirler. VLAN’lar arasında aşırı izinli yönlendirme, ayrılmış ağları büyük ölçüde yeniden birbirine bağlar. Aynı VLAN içindeki tek tek iş yükleri arasında da ek filtreleme gerekebilir.
OPNsense veya Sophos Firewall, uygun kuralların uygulanabileceği platformlara örnektir; başka uygun ürünler de kullanılabilir. Önemli olan somut kaynaklar, hedefler, hizmetler, sorumluluklar ve doğrulanmış uygulamadır. Kullanım şekli ve mevcut işlevler platforma göre değişir. Tek başına bir ürün adı, test edilmiş bir güvenlik mimarisini tanımlamaz.
Ters proxy ve WAF korumanın parçaları olmaya devam eder
Bir ters proxy, genel erişimleri bir araya getirebilir, TLS bağlantılarını işleyebilir ve istekleri seçilen arka uçlara yönlendirebilir. HAProxy bu amaçla HTTP ve TCP modlarını da destekler. Bu, her tür protokol için genel bir proxy işlevi anlamına gelmez. Öne yerleştirilmiş bir web uygulaması güvenlik duvarı, yani WAF, belirli zararlı web isteklerini tanıyıp reddedebilir.
Bu bileşenler güvenli uygulamaların, zamanında güncellemelerin veya kısıtlı arka uç erişiminin yerini tutmaz. Hatalı kurallar ya da erişilebilen başka bir giriş yolu korumaların aşılmasına neden olabilir. Bu nedenle örnekte proxy arkasında ele geçirilen bir uygulama da yalnızca açıkça ihtiyaç duyduğu hedeflere ulaşabilmelidir.
Giden ve iç trafiği de değerlendirin
Asıl soru yalnızca web sunucusuna kimin bağlanabileceği değildir. Sunucunun kendisi hangi hedeflere bağlantı başlatabilir? NAS’ın yönetim arayüzüne ulaşabilir mi? İnternetteki her hedefle iletişim kurması gerekiyor mu? Diğer konteynerlerin gerçekten hangi iç hizmetlere ihtiyacı var?
Giden trafik, yani egress planlanırken ad çözümleme, zaman eşitleme, güncellemeler ve dış arayüzler de ele alınır. Gerekli hedeflere özel izin verilir. İç sistemler arasında gerçekleşen ve çoğu zaman doğu-batı trafiği olarak adlandırılan iletişim de açık kurallar gerektirir. IPv6 ve alternatif yollar aynı amaçlanan ayrımı korumalıdır.
Bir bağlantı planı; kaynağı, hedefi, gerekli hizmeti, amacı ve sorumlu kişiyi kaydeder. Ardından izin verilen ve engellenen yollar kontrollü biçimde test edilir. Günlükler ve izleme, beklenmedik başarılı bağlantıları da şüpheli engellenmiş girişimleri de görünür kılmalıdır. Etkisi doğrulanmamış bir kural henüz güvenilir bir kanıt değildir.
Sanal makineler ve konteynerler uygun sınırlara ihtiyaç duyar
Bir sanal makinenin kendi konuk işletim sistemi vardır; konteynerler genellikle ana makinenin çekirdeğini paylaşır. Her iki model için de uygun ağ ve yetki yapılandırması gerekir. Proxmox VE, ana makineler ve konuk sistemler için güvenlik duvarı kuralları sunar. Hangi katmanların ve işlevlerin etkili olduğu, kullanılan güvenlik duvarı arka ucuna ve gerçekten etkinleştirilen seçeneklere de bağlıdır.
Docker’da aynı bridge ağındaki konteynerler birbiriyle iletişim kurabilir. Giden bağlantılar otomatik olarak yalnızca genel hedeflerle sınırlanmaz. Yayımlanan portlar ek girişler oluşturabilir. Host ağ modunda konteynerler ana makinenin ağ ad alanını paylaşır; bu durumda ayrı bir ağ izolasyonu yoktur.
Ek ayrıcalıklar, gereksiz bağlanmış ana makine dizinleri ve Docker soketine erişim, bir olayın sonuçlarını önemli ölçüde genişletebilir. Bu nedenle ayrı uygulama ağları, asgari yetkiler, uygun ana makine güvenlik duvarı kuralları ve kontrollü DNS ve egress yolları birlikte tasarlanmalıdır. Burada da belirleyici olan gerçekten çalışan yapılandırmadır.
Küçük işletmeler için yönetilebilir bir başlangıç
- Hizmetleri envantere alın: genel uygulamaları, bağımlılıkları ve sorumlu kişileri belgeleyin.
- Bölgeleri tanımlayın: genel iş yüklerini, verileri, yönetimi ve yedekleri koruma ihtiyaçlarına göre ayırın.
- Bağlantıları gerekçelendirin: yalnızca tanımlanmış kaynaklara, hedeflere ve hizmetlere izin verin; işletim açısından uygun yerlerde kalanını engelleyin.
- Yönetimi koruyun: güvenilir erişim yolları, uygun VPN ve çok faktörlü kimlik doğrulama yöntemleri ile ayrı hesaplar kullanın.
- İşletimi kapsayın: güncellemeleri, merkezi günlükleri, uyarıları ve geri yüklemesi test edilmiş, bağımsız korunan yedekleri planlayın.
- Etkiyi doğrulayın: kuralları düzenli inceleyin, istisnaları süreyle sınırlayın ve değişikliklerden sonra yeniden test edin.
Değişiklikler hazırlık, uygun bir bakım aralığı ve geri dönüş imkânı gerektirir. Genel bir engelleme, meşru uygulamaları veya kendi yönetim erişiminizi kesebilir. Bu yüzden önce bağımlılıkları belirleyin, ardından geçişi kontrollü gerçekleştirin ve işlevlerin çalıştığını sorumlularla birlikte doğrulayın.
Bir uygulamanın ele geçirilmesi tüm ağı beraberinde sürüklemek zorunda değildir
PHP güvenlik açıklarına verilen yanıt ve yapay zekâ destekli envanter çalışması hakkındaki PHP2Shell yazıları güncel çıkış noktasını oluşturur. NAS, Docker ve genel hizmetlerin ek kontrolü kalıcı bir mimari soruya götürür: Her hizmetin gerçekten hangi bağlantılara ve yetkilere ihtiyacı var?
DAXS; envanter, iletişim planı, uygulama ve doğrulanabilir işletim konularında destek sağlar. Uygulama ister yerelde, ister özel bulutta, ister genel bir bulut platformunda çalışsın, koruma sınırları gerçek ihtiyaca uygun olmalıdır. Somut ortamınızı birlikte değerlendirelim.
Kaynaklar: OPNsense: kurallar ve durum bilgili filtreleme · Sophos Firewall: bölgeler, kurallar ve günlükleme · HAProxy: HTTP ve TCP modları · Docker: bridge ağları · Docker: host ağ modu · Docker: daemon, yetkiler ve güvenlik sınırları · Proxmox VE: güvenlik duvarı belgeleri · NCSC: yayılmayı sınırlamak, yönetimi ve yedekleri korumak.
