Müşterilerin doğrudan eriştiği portlarla başlayın: 443 üzerindeki HTTPS, 80 üzerindeki yönlendirme, API ağ geçidi portları ve kendiniz barındırıyorsanız DNS veya SMTP. Ardından veritabanları, önbellekler ve mesaj kuyrukları gibi tüm altyapıyı çökertebilecek dahili bağımlılıkları kapsayın. Son olarak SSH, RDP ve Docker API gibi yönetim portlarının internetten erişilebilir olmadığını doğrulamak için bunları izleyin.
Portları Numaraya Göre Değil, Etkiye Göre Sıralayın
Dinleme yapan her hizmeti aynı anda izlemek gürültülü uyarılar üretir ve net bir sahiplik bırakmaz. Bunun yerine bir kontrol eklemeden önce her portu üç soruya göre puanlayın:
- Müşteri ve gelir etkisi. Bu port yanıt vermeyi bırakırsa kullanıcılar hata görür mü, ödeme başarısız olur mu veya API istemcileri zaman aşımına uğrar mı?
- Tek hata noktası. Arkasında tek bir birincil veritabanı, tek bir mesaj aracısı (broker) veya tek bir yük dengeleyici mi var, yoksa trafik otomatik olarak yedeğe mi geçiyor?
- Maruziyet riski. Bu port genel internetten erişilebilir hâle gelirse, bu bir güvenlik olayı olur mu?
İlk iki soruda yüksek puan alan bir port erişilebilirlik katmanına girer. Üçüncü soruda yüksek puan alan bir port ise “açık” olmanın uyarı koşulu olduğu maruziyet katmanına girer.
Katman 1: Genel Giriş Noktaları
Bunları ilk olarak, genellikle birkaç bölgeden 30–60 saniyelik aralıklarla oluşturun:
- 443 (HTTPS): birincil giriş kapınız. Yalnızca TCP bağlantısını değil, TLS el sıkışmasını da doğrulayın.
- 80 (HTTP): 443'e bir yönlendirmeyle yanıt vermelidir. Bozuk bir yönlendirme, eski bağlantılardan gelen kullanıcıları ortada bırakır.
- İş ortaklarının veya mobil uygulamaların doğrudan çağırdığı API ağ geçidi portları (örneğin 8443 veya ayrılmış bir gRPC portu).
- Kendi yetkili DNS sunucunuzu barındırıyorsanız TCP ve UDP üzerinden 53. Sorguların çoğunu UDP taşırken büyük yanıtları ve bölge aktarımlarını TCP üstlenir; bu nedenle her ikisini de kontrol edin.
- İşlemsel e-postaları kendi aktarıcılarınızdan gönderiyorsanız 25, 465 veya 587. SMTP sessizce başarısız olursa parola sıfırlama e-postaları ve faturalar gelmeyi keser.
Çok konumlu kontroller önemlidir; çünkü bir güvenlik duvarı veya CDN değişikliği bir portu bir bölgede açık, başka bir bölgede filtrelenmiş bırakabilir.
Katman 2: Dahili Bağımlılıklar
Bu hizmetler genel erişime açık olmamalıdır; bu nedenle bunları ağın içinden veya güvenlik duvarınızda açıkça izin listesine alınmış bir izleme IP'sinden kontrol edin:
- 5432 (PostgreSQL) ve 3306 (MySQL): hem birincil hem de replika uç noktaları.
- 6379 (Redis): önbellekler çoğu zaman sessizce arızalanır, ardından arkalarındaki veritabanını aşırı yükler.
- 5672 (RabbitMQ) ve 9092 (Kafka): takılan bir mesaj aracısı tüm asenkron işleri biriktirir.
- Hizmet katmanlarının önündeki dahili yük dengeleyici dinleyicileri.
Yalnızca çalışıyor/çalışmıyor durumunu değil, bağlantı süresini de takip edin. Bir bağlantıyı 5 ms yerine 800 ms'de kabul eden bir veritabanı portu çoğu zaman bağlantı havuzunun tükendiğine veya ana bilgisayarın doygunluğa ulaştığına işaret eder.
Katman 3: Kapalı Kalması Gereken Portlar
Son katman mantığı tersine çevirir. Bu portlar genel internetten erişilebilir olduğunda uyarı verirsiniz:
| Port | Hizmet | Genel erişime açık olmasının neden riskli olduğu |
|---|---|---|
| 22 | SSH | Sürekli kaba kuvvet ve kimlik bilgisi doldurma (credential stuffing) hedefi |
| 3389 | RDP | Sık görülen fidye yazılımı giriş noktası |
| 2375 / 2376 | Docker API | 2375 kimlik doğrulamasızdır ve ana bilgisayar düzeyinde kontrol sağlar |
| 6443 | Kubernetes API | İzin verilen IP aralıklarıyla veya özel ağla sınırlandırılmalıdır |
| 9200 | Elasticsearch | Açığa çıkan verilerin yaygın kaynağı |
| 27017 | MongoDB | Açık bırakıldığında geçmişte toplu olarak taranıp silinmiştir |
Bu kontrolleri harici konumlardan her 5–15 dakikada bir çalıştırın. Bu, gevşetilmiş bir güvenlik grubunu, yanlış yapılandırılmış bir Helm chart'ını veya unutulmuş bir hata ayıklama portunu yakalar.
UpScanX ile Nasıl Hayata Geçirilir?
UpScanX port izleme, 15'ten fazla küresel konumdan TCP ve UDP kontrolleri çalıştırır; bu da aşamalı bir geçişe uygundur:
- 1. hafta: Bağlantı kabul eden ancak bozuk yanıtlar döndüren bir portun da uyarı vermesi için protokole özgü yanıt doğrulamasıyla Katman 1 kontrollerini ekleyin.
- 2. hafta: Ağınızın izleme erişimine izin verdiği her yerde, bağlantı süresi ve yanıt gecikmesi takibini kullanarak Katman 2 kontrollerini ekleyin. Normal bağlantı süresinin yaklaşık 2–3 katında uyarı verin.
- 3. hafta: Katman 3 için bir yapılandırma referansı kaydedin ve port durumu değişikliği tespitini etkinleştirin. Sürüm tespitli hizmet parmak izi çıkarma da nginx çalıştırması gereken ancak aniden başka bir şey olarak tanımlanan bir portu işaretler.
Katman 1 uyarılarını müdahale ekiplerinin takip ettiği Slack veya Microsoft Teams'e yönlendirin; Katman 3 maruziyet uyarılarını ise e-posta veya webhook ile güvenlik ekibinize gönderin. Her açık portta neyin doğrulanacağı için kritik açık port izleme kontrol listemize göz atın.
Temel Çıkarımlar
- Port numarasına göre değil; müşteri etkisine, tek hata noktalarına ve maruziyet riskine göre önceliklendirin.
- Önce genel giriş noktalarını, ardından dahili veri bağımlılıklarını, sonra yönetim portlarını izleyin.
- Bozulmayı erken yakalamak için yalnızca erişilebilirliği değil, bağlantı gecikmesini de takip edin.
- Büyük altyapı değişikliklerinden sonra listeyi yeniden gözden geçirin; yeni hizmetler sessizce yeni portlar ekler.