Açık Veritabanı Portları (MySQL, PostgreSQL, MongoDB, Redis)

SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama
SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama

Tüm Kayıtlar

Sitenizi Tarayın

Sitenizi bu zafiyete karşı kontrol edin

Otomatik bir tarama başlatın ve sitenizin etkilenip etkilenmediğini görün — sade dille bulgular ve çözümlerle.

Taramaya Başla
KategoriGüvenlik Yanlış Yapılandırması / Hatalı Erişim Kontrolü
Tipik Önem DerecesiKritik
OWASPA05:2021 – Güvenlik Yanlış Yapılandırması
CWECWE-284 – Hatalı Erişim Kontrolü; CWE-16 – Yapılandırma
Diğer adlarıAçık veritabanı portları, herkese açık veritabanı, kimlik doğrulamasız veritabanı erişimi
Etkilenen varsayılan portlarMySQL: 3306 · PostgreSQL: 5432 · MongoDB: 27017 · Redis: 6379
Etkilenen sistemlerAğ katmanı erişim denetimi olmaksızın veritabanı servisleri çalıştıran bulut VM'leri, özel sunucular ve konteynerler

Genel Bakış

MySQL, PostgreSQL, MongoDB ve Redis gibi veritabanı yönetim sistemleri varsayılan olarak bilinen TCP portlarında dinler. Bu portlar genel internetten veya güvenilmeyen iç ağ segmentlerinden erişilebilir durumdaysa, saldırganlar herhangi bir uygulama katmanı güvenlik denetiminden geçmeksizin doğrudan veritabanı servisiyle etkileşime girebilir. Veritabanının kendi kimlik doğrulama ve yetkilendirme yapılandırmasına bağlı olarak, bu durum kimlik bilgisi kaba kuvvet saldırısından tamamen kimlik doğrulamasız veri erişimine kadar uzanan bir risk aralığı oluşturur.

Redis özellikle yıllarca varsayılan olarak kimlik doğrulaması devre dışı bırakılmış biçimde gönderilmiştir. 2017–2018 yılları arasında çok sayıda MongoDB dağıtımı kimlik bilgisi olmaksızın herkese açık hale gelmiş; bu durum toplu veri hırsızlığı ve fidye kampanyalarıyla sonuçlanmıştır. Bu olaylar, ağ katmanı açığının, veritabanının kendi erişim denetimindeki herhangi bir zayıflığın sömürülmesi için eşiği dramatik biçimde düşüren bir ön koşul olduğunu açıkça ortaya koymaktadır.

Nasıl çalışır?

Otomatik internet tarayıcıları IPv4 ve IPv6 adres alanını sürekli olarak açık portlar için tarar. Bir veritabanı portu yanıt verdiğinde saldırganlar öngörülebilir bir saldırı zinciri izler:

  • Servis parmak izi alma: İlk TCP el sıkışması ve sunucu başlığı (örn. MySQL'in ilk el sıkışma paketi, Redis'in satır içi PING yanıtı) veritabanı türünü ve sürümünü doğrulayarak hedefli sömürüye olanak tanır.
  • Kimlik doğrulama atlama veya kaba kuvvet: Önce varsayılan kimlik bilgileri denenir (root ve boş şifre — MySQL'de; Redis <6.0'da kimlik doğrulama yok; eski MongoDB'de anonim erişim). Önceki ihlallerden türetilen kimlik bilgisi doldurma listeleri bu süreci daha da ileriye taşır.
  • Kimlik doğrulamasız erişim (Redis / eski MongoDB): Redis 6.0 öncesinde varsayılan olarak kimlik doğrulama bulunmaz. Saldırgan CONFIG SET dir ve CONFIG SET dbfilename komutlarını ardından SAVE komutuyla kullanarak sunucu dosya sistemine rastgele dosya yazabilir; bu yöntem genellikle SSH yetkili anahtarları veya uzaktan kod yürütme için cron işleri yerleştirmek amacıyla kullanılır.
  • Veri sızdırma: Kimlik doğrulama sağlandıktan (veya kimlik doğrulama yokken) sonra tam veri kümesi numaralandırması ve çıkarılması standart istemci araçları ya da komut dosyalı sorgular kullanılarak son derece kolaydır.
  • Fidye yazılımı / veri imhası: Otomatik araçlar, açık MongoDB ve Redis örneklerini büyük ölçekte hedef alarak veritabanlarını silip fidye notu bırakmak için yaygın biçimde kullanılmıştır.
  • Yanal hareket: Ele geçirilen bir veritabanı sunucusu çoğunlukla ek iç sistemlere erişim sağlayan kimlik bilgilerine veya ağ erişimine sahiptir; bu da daha fazla yayılımı mümkün kılar.

Yaygın kök nedenler şunlardır: bulut güvenlik grubu veya güvenlik duvarı kurallarının veritabanı portlarına 0.0.0.0/0 girişine izin vermesi; veritabanı konteynerlerini tüm ağ arayüzlerine bağlayan yanlış yapılandırılmış Docker veya Kubernetes servis açıkları; ve ağ mimarisinde en az ayrıcalık ilkesinin uygulanmaması (yani veritabanı alt ağı / DMZ ayrımının olmaması).

İş etkisi

Açık bir veritabanı portunun sömürülmesi, o veritabanında depolanan tüm verilerin tam olarak ele geçirilmesiyle sonuçlanabilir. Spesifik sonuçlar şunlardır:

  • Veri ihlali: Kişisel olarak tanımlanabilir bilgiler (PII), ödeme kartı verileri, sağlık kayıtları, kimlik doğrulama kimlik bilgileri ve özel iş verileri dakikalar içinde sızdırılabilir.
  • Düzenleyici cezalar: Kişisel verilerin açığa çıkması; GDPR Madde 32 (uygun teknik önlemler), HIPAA Güvenlik Kuralı §164.312, PCI DSS Gereksinim 1 (güvenlik duvarı kontrolleri) ve benzeri çerçeveleri ihlal eder; potansiyel para cezaları ve zorunlu ihlal bildirimleri söz konusu olabilir.
  • Veri imhası ve fidye yazılımı: Otomatik saldırı kampanyaları rutin olarak veritabanı içeriklerini siler ve iade için ödeme talep eder. Yedek yoksa kurtarma imkânsız olabilir.
  • Uzaktan kod yürütme: Dosya sistemi yazımını mümkün kılan Redis yanlış yapılandırmaları, işletim sistemi düzeyinde uzaktan kod yürütme elde etmek için kapsamlı biçimde sömürülmüş; etki veritabanının çok ötesine geçmiştir.
  • İtibar kaybı: Açıkça erişilebilir bir veritabanına atfedilebilen bir ihlalin kamuoyuna duyurulması, temel güvenlik ihmalini işaret ettiğinden özellikle zararlıdır.

Nasıl düzeltilir?

  1. Ağ çevresinde veritabanı portlarını engelleyin: Güvenlik duvarı kurallarını, bulut güvenlik gruplarını (AWS Security Groups, Azure NSG'ler, GCP Güvenlik Duvarı Kuralları) veya ana makine tabanlı güvenlik duvarını (iptables/nftables/ufw) açıkça güvenilir uygulama sunucusu IP adresleri veya CIDR aralıkları dışındaki her kaynaktan gelen tüm bağlantıları veritabanı portlarına reddedecek şekilde yapılandırın. Veritabanı portlarında asla 0.0.0.0/0 girişine izin vermeyin.
  2. Veritabanı servislerini yalnızca yerel ana makineye veya özel arayüzlere bağlayın: MySQL/MariaDB my.cnf dosyasında bind-address = 127.0.0.1; PostgreSQL postgresql.conf dosyasında listen_addresses = 'localhost'; Redis redis.conf dosyasında bind 127.0.0.1; MongoDB mongod.conf dosyasında net.bindIp: 127.0.0.1 ayarlarını yapın (çapraz sunucu replikasyonu gerekmiyorsa).
  3. Güçlü kimlik doğrulamayı etkinleştirin ve zorunlu kılın: Redis 6+'da güçlü requirepass kullanın (veya ACL tabanlı kimlik doğrulamayı etkinleştirin); PostgreSQL'in pg_hba.conf dosyasında scram-sha-256 kimlik doğrulamasını kullandığından emin olun; MySQL anonim hesaplarını devre dışı bırakın ve parola politikasını uygulayın; MongoDB kimlik doğrulamasını etkinleştirin (security.authorization: enabled).
  4. Veritabanlarını ayrı bir özel alt ağa yerleştirin: Ağ mimarisi, veritabanı düğümlerinin internetten doğrudan yolu olmayan bir alt ağ/VPC'de bulunmasını sağlamalıdır. Uygulama sunucuları yalnızca özel IP'ler üzerinden iletişim kurmalıdır.
  5. Uzaktan yönetim için şifreli tüneller kullanın: Tüm DBA erişimi SSH tüneli, VPN veya bastion host üzerinden gerçekleştirilmelidir; asla veritabanı portu internete açılmamalıdır.
  6. Güncel sürümlere yükseltin: Tüm veritabanı yazılımlarının güvenlik iyileştirmelerinden yararlanmak için desteklenen ve yamalı bir sürümde olduğundan emin olun (örn. Redis 6.0+ zorunlu kimlik doğrulama, MongoDB 4.0+ TLS zorunluluğu).
  7. İstemci bağlantıları için TLS/SSL etkinleştirin: Erişilebilen herhangi bir ağ yolunda kimlik bilgisi ele geçirilmesini önlemek amacıyla veritabanlarını şifreli bağlantılar gerektirecek şekilde yapılandırın.
  8. Düzenli denetim yapın: Altyapınızı yanlışlıkla açığa çıkan veritabanı portları için düzenli olarak tarayın. Sensagraph, izlenen varlıklardaki açık veritabanı servis portlarını sürekli olarak tespit eder.

Referanslar

Sıkça sorulan sorular

Redis güvenilir iç ağlar için tasarlanmış olup 6.0 sürümünden önce varsayılan olarak kimlik doğrulama etkinleştirilmemiş biçimde gönderilmiştir. Ağ erişimine sahip kimlik doğrulamasız bir saldırgan, sunucunun dosya sistemindeki dosyaları yeniden yazan yönetimsel komutlar verebilir; örneğin root kullanıcısının authorized_keys dosyasına bir SSH genel anahtarı yazarak herhangi bir kimlik bilgisi olmaksızın tam işletim sistemi uzaktan kod yürütme erişimi elde edebilir.

Hayır. Güçlü bir şifre riski azaltır ancak tamamen ortadan kaldırmaz. Kimlik bilgisi kaba kuvvet saldırısı, parola püskürtme, eski veritabanı sürümlerindeki protokol düzeyindeki güvenlik açıkları ve veritabanının kendi kimlik doğrulama mantığındaki gelecekteki sıfır günlük açıklara karşı savunmasızlık devam eder. Ağ katmanı engelleme, kimlik doğrulama gücünden bağımsız ayrı ve zorunlu bir derinlemesine savunma katmanıdır.

Otomatik internet genelinde tarama araçları (Shodan, Censys ve kitle tarayıcıları gibi), yaygın veritabanı portları için tüm yönlendirilebilir IPv4 ve IPv6 adreslerini sürekli tarar. Açık bir veritabanı portuyla çevrimiçi olan yeni dağıtılmış bir bulut örneği, yayına girdikten dakikalar içinde keşfedilebilir ve araştırılabilir.

Hayır. Bu, gizlilik yoluyla güvenlik yaklaşımıdır. Modern internet tarayıcıları tam port aralığı taraması yapar ve servisleri yalnızca port numarasına göre değil protokol başlığına göre tanımlar. Varsayılan dışı portlar keşfi en fazla birkaç dakika geciktirir ve asla güvenlik kontrolü olarak değerlendirilmemelidir.

Veritabanını internet ağ geçidi rotası olmayan özel bir alt ağa yerleştirin. Ayrı bir alt ağdaki uygulama sunucuları, yalnızca uygulama sunucularının adreslerine veritabanı portunda izin veren güvenlik grubu veya ACL kurallarıyla korunan özel IP'ler üzerinden veritabanıyla iletişim kurar. Yönetimsel erişim yalnızca VPN veya SSH bastion host aracılığıyla gerçekleştirilir.