.env Dosyası Sızıntısı ve Bot Taramaları: Açıkta Kalan Yapılandırma ve Yedek Dosyaları Nasıl Korunur?

İnternete açık herhangi bir web sunucusunun erişim loglarını birkaç dakika incelediğinizde, sitenizde hiç bulunmayan adreslere yapılan çok sayıda istek görürsünüz: /.env, /.git/config, /backup.zip, /wp-config.php.bak ve benzerleri. Bu istekler tesadüf değildir. Dünyanın dört bir yanından çalışan otomatik botlar, yanlışlıkla web dizininde bırakılmış yapılandırma ve yedek dosyalarını arar. Bulduklarında elde ettikleri şey çoğu zaman bir sunucuya sızmaktan çok daha değerlidir: veritabanı şifreleri, API anahtarları ve e-posta hesap bilgileri. Bu yazıda .env dosyası sızıntısının ne olduğunu, botların hangi dosyaları aradığını, bir sızıntının sonuçlarını ve kalıcı korunma yöntemlerini anlatıyoruz.

.env dosyası nedir, neden bu kadar değerlidir?

Modern web uygulamaları, ortama göre değişen ayarları kodun içine yazmak yerine ayrı bir dosyada veya ortam değişkenlerinde tutar. Laravel, Symfony, Node.js, Next.js ve pek çok çatıda bu dosyanın adı genellikle .env olur. Bu yaklaşım doğrudur; aynı kod geliştirme, test ve canlı ortamda farklı ayarlarla çalışabilir ve şifreler kod deposuna girmez.

Sorun, bu dosyanın içeriğidir. Tipik bir .env dosyasında şunlar bulunur:

• Veritabanı sunucu adresi, kullanıcı adı ve şifresi.
• Uygulama şifreleme anahtarı (oturum ve çerez imzalamada kullanılır).
• E-posta gönderimi için SMTP sunucu bilgileri ve şifresi.
• Ödeme sağlayıcısı, SMS servisi, harita, yapay zekâ ve benzeri üçüncü taraf servislerin API anahtarları.
• Bulut depolama ve bulut sağlayıcısı erişim anahtarları.
• Bazen yönetici e-postası, hata izleme servisi bağlantıları ve iç sistem adresleri.

Yani .env dosyası, uygulamanın bütün kapılarının anahtarlarının bulunduğu bir anahtarlıktır. Bu dosya web üzerinden okunabiliyorsa, saldırganın sunucuya sızmasına gerek kalmaz; anahtarları alıp doğrudan veritabanına, e-posta hesabına veya bulut hesabına bağlanabilir.

.env dosyası nasıl sızar?

.env dosyasının sızması genellikle bir yazılım açığından değil, bir yapılandırma hatasından kaynaklanır. En sık karşılaşılan senaryolar şunlardır:

• Yanlış web kök dizini: Laravel gibi çatılarda web sunucusunun yalnızca public klasörünü göstermesi gerekir. Kök dizin bir üst klasöre ayarlanırsa .env dosyası doğrudan tarayıcıdan indirilebilir hale gelir. Paylaşımlı hostinglerde projenin tamamının public_html içine kopyalanması bu hatanın en yaygın biçimidir.
• Nokta ile başlayan dosyaların sunulması: Web sunucusu varsayılan olarak bu dosyaları engellemiyorsa ve özel bir kural tanımlanmamışsa, .env, .git veya .htpasswd gibi dosyalar okunabilir.
• Ön yüz derlemesine sır karışması: Tarayıcıda çalışan JavaScript koduna yalnızca herkese açık olması sakıncasız değerler girmelidir. Bazı çatılarda belirli bir önekle başlayan ortam değişkenleri derlemeye otomatik olarak dahil edilir; gizli bir anahtar bu önekle tanımlanırsa sitenin JavaScript dosyalarında herkesin görebileceği biçimde yayınlanır.
• Hata sayfaları: Geliştirme modunda bırakılmış bir uygulama, hata anında ortam değişkenlerini ve yapılandırmayı ayrıntılı hata sayfasında gösterebilir.
• Kod çalıştırma açıkları: Sunucuda kod çalıştırmaya imkân veren bir açık varsa, saldırganın ilk okuduğu şey ortam değişkenleridir. Bu konuyu React2Shell ve PHP2Shell yazılarımızda ayrıntılı ele aldık.

.git klasörü ve yedek dosyaları neden tehlikelidir?

.env tek risk değildir. Botların aradığı ikinci büyük grup, sürüm kontrol klasörleri ve yedek dosyalarıdır.

Açıkta kalan .git klasörü

Siteyi sunucuya git ile çeken ekipler, .git klasörünü web dizini içinde bırakabilir. Bu klasör erişilebilir durumdaysa, saldırgan otomatik araçlarla deponun tamamını ve geçmişini indirebilir. Bu, uygulamanın kaynak kodunun tamamı demektir; geçmiş commit'lerde yanlışlıkla eklenip sonra silinmiş şifreler, anahtarlar ve yapılandırma dosyaları da buna dahildir. Kaynak kodun eline geçmesi, saldırgana uygulamadaki diğer zayıflıkları sessizce inceleme fırsatı da verir.

Yedek ve döküm dosyaları

Bir güncelleme öncesinde alınıp web dizininde unutulan site.zip, backup.tar.gz, db.sql, dump.sql gibi dosyalar ya da düzenleme sırasında oluşan config.php.bak, config.php.old, index.php~ gibi kopyalar en sık bulunan sızıntılardandır. PHP dosyası normalde sunucuda çalıştırılır ve içeriği görünmez; ancak .bak veya .old uzantılı bir kopyası düz metin olarak indirilir ve içindeki veritabanı şifresi açığa çıkar. Bir SQL dökümü ise doğrudan müşteri verisinin tamamı anlamına gelebilir.

Botlar hangi dosyaları tarar?

Tarama botları sitenin büyüklüğüne veya sektörüne bakmaz. IP aralıklarını ve alan adı listelerini sırayla dolaşır, her sunucuya aynı adres listesini dener. Yeni bir alan adı için SSL sertifikası alındığında, sertifika şeffaflık kayıtlarına düşen alan adı kısa süre içinde bu taramaların listesine girer. Kendi sunucu loglarımızda da bu istekleri her gün görüyoruz. Tipik olarak denenen adresler şöyle gruplanabilir:

Grup	Örnek adresler	Aranan bilgi
Ortam dosyaları	/.env, /.env.local, /.env.production, /.env.backup, /api/.env, /laravel/.env	Veritabanı, e-posta ve API sırları
Sürüm kontrolü	/.git/config, /.git/HEAD, /.svn/entries	Kaynak kod ve geçmiş
CMS yapılandırması	/wp-config.php.bak, /wp-config.php~, /configuration.php.old, /config.php.save	Veritabanı şifresi
Yedek arşivleri	/backup.zip, /site.tar.gz, /www.zip, alan adıyla aynı adı taşıyan .zip dosyaları	Tüm site dosyaları
Veritabanı dökümleri	/db.sql, /dump.sql, /database.sql, /backup.sql	Müşteri ve kullanıcı verisi
Geliştirme ve bilgi sayfaları	/phpinfo.php, /info.php, /server-status, /debug, geliştirme araçlarına ait uç noktalar	Ortam değişkenleri, sürüm ve yol bilgisi
Bulut ve araç yapılandırmaları	/.aws/credentials, /.docker/config.json, /config.json, /sftp-config.json, /.vscode/sftp.json	Erişim anahtarları ve sunucu şifreleri

Bu tablo örnek niteliğindedir; gerçek listeler yüzlerce adres içerir ve her yeni açıkla birlikte güncellenir. Örneğin RSC geliştirme araçlarına yönelik isteklerde, sunucu sürecinin ortam değişkenlerini barındıran /proc/self/environ dosyasının okunmaya çalışıldığı görülür. Bu da aynı hedefe, yani ortam değişkenlerine farklı bir yoldan ulaşma çabasıdır.

.env dosyası sızarsa ne olur?

Sızıntının sonucu, dosyada hangi sırların bulunduğuna ve bu sırların nerede geçerli olduğuna bağlıdır:

Sızan bilgi	Olası sonuç
Veritabanı şifresi	Veritabanı dışarıya açıksa doğrudan bağlantı; müşteri verisinin kopyalanması, silinmesi veya fidye amaçlı şifrelenmesi.
SMTP şifresi	Kurumsal e-posta hesabınız üzerinden spam ve oltalama e-postası gönderimi; alan adınızın e-posta itibarının zarar görmesi.
Ödeme ve SMS servisi anahtarları	Hesabınız üzerinden işlem yapılması, SMS kredisinin tüketilmesi, müşteri bilgilerine erişim.
Bulut erişim anahtarları	Hesabınızda kaynak açılması, depolanan dosyalara erişim ve beklenmedik yüksek faturalar.
Uygulama şifreleme anahtarı	Oturum çerezlerinin taklit edilmesi; bazı çatılarda bu anahtar kod çalıştırmaya giden zincirin parçası olabilir.
Yapay zekâ ve diğer ücretli API anahtarları	Anahtarın başkaları tarafından kullanılması ve kullanım bedelinin size yansıması.

Kişisel veri içeren bir veritabanına yetkisiz erişim, 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamında bir veri ihlali anlamına gelebilir ve bildirim yükümlülüklerini gündeme getirebilir. Teknik önlemlerin hukuki boyutunu KVKK uyumlu web sitesi nasıl olur yazımızda ele aldık.

Web sunucusunda bu dosyalar nasıl engellenir?

Savunmanın ilk katmanı, bu dosyaların web üzerinden hiçbir koşulda sunulmamasıdır. Uygulanması gereken kurallar şunlardır:

1. Nokta ile başlayan dosya ve klasörleri engelleyin: Nginx'te nokta ile başlayan tüm yollar için bir location bloğu tanımlanıp erişim reddedilir; Let's Encrypt doğrulaması için kullanılan .well-known klasörü bu kuralın dışında tutulur. Apache'de aynı amaçla dosya eşleştirme kuralıyla erişim reddedilir. Birçok güncel Apache kurulumunda .ht ile başlayan dosyalar varsayılan olarak engellenir, ancak .env ve .git için ayrıca kural gerekir.
2. Yedek ve döküm uzantılarını engelleyin: .bak, .old, .orig, .save, .swp, ~ ile biten dosyalar ile .sql, .zip, .tar, .gz, .7z uzantılı dosyalara web dizininde erişim reddedilmelidir. Sitenin gerçekten bu uzantılarda indirme sunması gerekiyorsa, bu dosyalar ayrı ve kontrollü bir klasörde tutulmalıdır.
3. Web kök dizinini doğru ayarlayın: Web sunucusu yalnızca herkese açık olması gereken klasörü (Laravel'de public, birçok projede dist veya public_html) göstermelidir. Uygulama kodu, .env ve yapılandırma dosyaları bu klasörün bir üst seviyesinde durmalıdır.
4. Dizin listelemeyi kapatın: Klasör içeriğinin otomatik listelenmesi, yedek dosyalarının bulunmasını kolaylaştırır.
5. Kuralı test edin: Kural yazıldıktan sonra tarayıcıdan /.env ve /.git/config adreslerini deneyin; yanıtın 403 veya 404 olduğunu ve içerik dönmediğini doğrulayın.

Sırları web kök dizininin dışında nasıl tutarım?

Engelleme kuralları önemlidir, ancak bir yapılandırma değişikliğiyle bozulabilir. Asıl kalıcı çözüm, sırların web tarafından erişilebilecek bir konumda hiç bulunmamasıdır:

• Doğru klasör yapısı: Proje kökü web dizini değil, public klasörü web dizinidir. Paylaşımlı hostingde de bu yapı kurulabilir; proje public_html'in dışına alınıp yalnızca public içeriği public_html'e yönlendirilir.
• Ortam değişkenleri: Konteyner ve bulut ortamlarında sırlar dosya yerine platformun ortam değişkeni veya sır yönetimi özelliğiyle verilebilir.
• Sır yönetim araçları: Büyüyen ekiplerde sırların merkezi bir sır yönetim sisteminde tutulması, kimin hangi sırra eriştiğinin kaydını sağlar.
• Kod deposu disiplini: .env dosyası .gitignore listesinde olmalı, depoda yalnızca değerleri boş bir örnek dosya (.env.example) bulunmalıdır. Depoya düşmüş bir sırrı sonraki commit'te silmek yeterli değildir; sır geçmişte kalır ve yenilenmesi gerekir.
• Dosya izinleri: .env dosyası yalnızca uygulamanın çalıştığı kullanıcı tarafından okunabilir olmalıdır.
• Ön yüz ayrımı: Tarayıcıya giden derlemeye yalnızca herkese açık değerlerin girdiği, gizli anahtarların sunucu tarafında kaldığı düzenli olarak kontrol edilmelidir.

Sızıntı fark edilirse anahtarlar nasıl yenilenir?

Bir dosyanın açıkta kaldığını fark ettiğinizde, erişilip erişilmediğini kesin olarak bilemeyebilirsiniz. Botların taraması sürekli olduğu için, dosya bir süre açıkta kaldıysa okunmuş olduğunu varsaymak gerekir. İzlenecek sıra şöyledir:

1. Dosyayı hemen web erişiminden kaldırın ve engelleme kuralını ekleyin.
2. Erişim loglarında ilgili adrese başarılı (200 yanıt kodlu) istek yapılıp yapılmadığını ve hangi IP'lerden yapıldığını kontrol edin.
3. Dosyadaki her sırrı tek tek yenileyin: veritabanı şifresi, SMTP şifresi, API anahtarları, bulut erişim anahtarları ve uygulama şifreleme anahtarı. Yalnızca yeni anahtar oluşturmak yetmez; eski anahtarın ilgili serviste iptal edildiğinden emin olun.
4. Veritabanı kullanıcısının yalnızca uygulama sunucusundan bağlanabildiğini, veritabanı portunun internete açık olmadığını doğrulayın.
5. Üçüncü taraf servislerin panellerinde olağan dışı kullanım, gönderim veya işlem olup olmadığına bakın.
6. Kişisel veriye erişim ihtimali varsa yasal yükümlülükleri değerlendirin ve süreci belgeleyin.

Bot taramaları nasıl izlenir?

Bot taramalarını tamamen durdurmak mümkün değildir; amaç, taramaların sonuçsuz kalmasını ve olağan dışı bir durumun hızla fark edilmesini sağlamaktır.

• Log analizi: Erişim loglarında hassas dosya adlarına yapılan ve 200 yanıtıyla sonuçlanan istekler için uyarı tanımlayın. 404 dönen denemeler olağandır; 200 dönen tek bir istek alarm sebebidir.
• Otomatik engelleme: Kısa sürede çok sayıda hassas adres deneyen IP'leri geçici olarak engelleyen araçlar (Fail2ban gibi) veya WAF kuralları sunucu yükünü de azaltır.
• Harici tarama: Kendi sitenize dışarıdan, botların denediği adres listesiyle periyodik kontrol yapmak, bir yapılandırma değişikliğinden sonra açığa çıkan dosyaları erken yakalar.
• Sır tarama: Kod deposuna sır eklenmesini commit aşamasında yakalayan araçlar, sorunun hiç oluşmamasını sağlar.
• Servis uyarıları: Bulut ve API sağlayıcılarının kullanım ve fatura uyarılarını etkinleştirin; olağan dışı kullanım çoğu zaman bir anahtarın sızdığının ilk işaretidir.

Sık yapılan hatalar

• Projenin tamamını public_html içine kopyalayıp .env dosyasını web dizininde bırakmak.
• Güncelleme öncesi aldığı yedeği web dizininde unutmak.
• Sızıntıyı fark edip dosyayı silmek, ancak sırları yenilememek.
• Depoya düşmüş bir sırrı commit geçmişinden silmeden ve yenilemeden bırakmak.
• Canlı sunucuda geliştirme modunu ve ayrıntılı hata sayfalarını açık bırakmak.
• Tüm ortamlarda aynı veritabanı şifresini ve API anahtarını kullanmak.

Sonuç

.env dosyası sızıntısı ve yedek dosyalarının açıkta kalması, karmaşık bir saldırı gerektirmeyen ama sonuçları ağır olabilen bir güvenlik sorunudur. Doğru klasör yapısı, nokta ile başlayan ve yedek dosyalarına yönelik engelleme kuralları, sırların depo dışında yönetilmesi ve düzenli log izlemesi bu riski büyük ölçüde ortadan kaldırır. Güvenli bir sunucu ve klasör yapısıyla kurulan kurumsal siteler için web tasarım, sır yönetimi ve dağıtım süreci baştan kurgulanan uygulamalar için özel yazılım geliştirme, ödeme anahtarları ve müşteri verisi barındıran mağazalar için ise e-ticaret yazılımı sayfalarımızı inceleyebilirsiniz. Mevcut sitenizin bu açıdan kontrol edilmesini isterseniz bizimle iletişime geçin.