Uygulamanız e-posta gönderebilmek için bir kullanıcı adı ve şifre kullanıyor. Bu bilgiler bir kod deposunda, bir yapılandırma dosyasında veya eski bir yedekte duruyor olabilir — ve ele geçirildiğinde alan adınız adına spam gönderilir.
Bu yazı, gönderim kimlik bilgilerinin korunmasını ele alıyor.
Sızıntının Sonuçları
Bir gönderim şifresi ele geçirildiğinde olabilecekler:
- Sizin adınıza spam gönderilir. Kimlik doğrulaması geçerlidir.
- Kimlik avı iletileri meşru görünür.
- IP ve alan adı itibarı çöker.
- Gönderim kotanız tükenir.
- Hesabınız askıya alınır.
İkinci madde en tehlikeli olanıdır: sizin altyapınızdan gönderilen bir kimlik avı iletisi, tüm kimlik doğrulama kontrollerinden geçer — SPF, DKIM ve DMARC hepsi başarılı görünür.
Bu, alıcı için ayırt edilmesi neredeyse imkânsız bir saldırıdır. Müşterileriniz sizin adınıza kandırılır ve sorumluluk size döner.
Sızıntı Nereden Olur?
Kimlik bilgilerinin en sık sızdığı yerler:
- Kod deposuna yanlışlıkla eklenmiş yapılandırma.
- Web kökünde erişilebilir yapılandırma dosyası.
- Eski yedeklerin indirilebilir olması.
- Geliştirici bilgisayarının ele geçirilmesi.
- Ekran görüntüsü veya destek talebi paylaşımı.
Birinci madde en yaygın kaynaktır: bir kez kod deposuna eklenen şifre, sonradan silinse bile geçmiş kayıtlarda kalır ve depoya erişimi olan herkes tarafından bulunabilir.
Bu yüzden yanlışlıkla eklenmiş bir şifreyi silmek yeterli değildir — o şifre artık yanmıştır ve mutlaka değiştirilmelidir.
Beşinci madde ise düşünülmeyen bir kanaldır. Sorun bildirirken paylaşılan bir ekran görüntüsü veya günlük dosyası, kimlik bilgilerini içerebilir.
Nerede Saklanmalı?
Kimlik bilgilerinin doğru saklanma yerleri:
| Yöntem | Durumu |
|---|---|
| Kod içinde sabit | Asla |
| Web kökündeki dosya | Riskli |
| Web kökü dışında dosya | Kabul edilebilir |
| Ortam değişkeni | İyi |
| Sır yönetim sistemi | En iyi |
İkinci satır sanılandan daha risklidir: web kökündeki bir yapılandırma dosyası, sunucu yapılandırması bozulduğunda düz metin olarak sunulabilir.
Bu, gerçekten yaşanan bir senaryodur. Bir güncelleme sonrası PHP işleyicisi devre dışı kalırsa, dosyalar kaynak kod olarak görüntülenir ve içindeki her şey açığa çıkar.
Ayrı Kimlik Kullanmak
Tek bir kimlik bilgisini her yerde kullanmak riski katlar:
- Her uygulama için ayrı kimlik oluşturun.
- Test ortamı için ayrı kimlik kullanın.
- Yetki kapsamını daraltın.
- Gönderim limitini uygulamaya göre ayarlayın.
Birinci madde hasarı sınırlar: bir kimlik sızdığında yalnızca onu iptal etmek yeterli olur, diğer sistemler çalışmaya devam eder.
Ortak kimlik kullanılıyorsa, sızıntı durumunda tüm sistemleri aynı anda güncellemeniz gerekir — ve bu, kriz anında yapılması zor bir iştir.
Dördüncü madde ise erken uyarı sağlar. Günde yüz e-posta gönderen bir uygulamanın kimliğine düşük bir limit koymak, kötüye kullanımı sınırlar ve fark edilmesini kolaylaştırır.
Şifre Yerine Anahtar
Modern gönderim servisleri şifre yerine API anahtarı sunar:
- Anahtar iptal edilebilir. Hesap şifresi değişmeden.
- Yetkisi sınırlanabilir. Yalnızca gönderim.
- Kullanımı izlenebilir. Hangi anahtar ne kadar gönderdi.
- Süreli olabilir.
Üçüncü madde tespit açısından değerlidir: anahtar bazlı kullanım raporu, hangi sistemin beklenmedik hacimde gönderim yaptığını doğrudan gösterir.
Bu görünürlük, tek bir ortak şifre kullanıldığında elde edilemez. Kötüye kullanım fark edilmeden uzun süre devam edebilir.
Kötüye Kullanımı Fark Etmek
Kimlik bilgisi ele geçirildiğinde görülecek belirtiler:
| Belirti | Anlamı |
|---|---|
| Beklenmedik gönderim hacmi | Kimlik kullanılıyor |
| Tanımadığınız alıcı adresleri | Dış liste kullanılıyor |
| Geri dönüş oranında sıçrama | Kalitesiz liste |
| Farklı IP'lerden bağlantı | Kimlik başka yerde |
| Gece saatlerinde aktivite | Normal dışı desen |
Dördüncü satır en kesin göstergedir: gönderim kimliğinizin sunucunuz dışındaki bir IP adresinden kullanılması, sızıntının kanıtıdır.
Bu yüzden gönderim servisinizin IP kısıtlama özelliği varsa mutlaka kullanılmalıdır — kimlik sızsa bile başka bir yerden kullanılamaz.
Sızıntı Anında Müdahale
Şüphelendiğiniz anda yapılacaklar:
- Kimliği hemen iptal edin. Araştırmayı sonra yapın.
- Yeni kimlik oluşturun.
- Uygulamaları güncelleyin.
- Gönderim kayıtlarını inceleyin. Ne gönderilmiş?
- İtibar durumunu kontrol edin.
Birinci maddedeki sıra önemlidir: önce iptal edip sonra araştırmak, saldırının devam etmesini önler — araştırma sırasında geçen her dakikada yeni iletiler gidiyor olabilir.
Dördüncü madde ise hasarın boyutunu belirler. Kaç ileti gitmiş, kimlere gitmiş ve içeriği neydi — bu bilgiler hem müdahale hem bildirim için gereklidir.
Gönderim altyapınızın kayıt ve kısıtlama özelliklerini incelemek, bu tür bir olayı hem önlemeye hem hızlı çözmeye yardımcı olur. SMTP servisi tarafındaki erişim kayıtları, olay sonrası incelemenin temel kaynağıdır.
Düzenli Bakım
Sızıntı olmasa bile yapılması gerekenler:
- Kullanılmayan kimlikleri iptal edin.
- Ayrılan personelin erişimini kaldırın.
- Kimlikleri düzenli yenileyin.
- Kod deposunu sır taraması yapın.
- Yedeklerin erişilebilirliğini kontrol edin.
Dördüncü madde otomatikleştirilebilir: kod deposunda şifre benzeri dizeleri arayan araçlar, yanlışlıkla eklenmiş kimlikleri ortaya çıkarır.
Birinci madde ise sıkça atlanır. Yıllar önce bir proje için oluşturulmuş ve artık kullanılmayan bir kimlik, hâlâ geçerliyse açık bir kapıdır.
Sonuç
Gönderim kimliğinin sızmasının en tehlikeli sonucu, sizin altyapınızdan gönderilen bir kimlik avı iletisinin tüm doğrulama kontrollerinden geçmesidir — alıcı için ayırt edilmesi neredeyse imkânsızdır. Kimlikleri kod içinde veya web kökündeki dosyalarda tutmayın; sunucu yapılandırması bozulduğunda bu dosyalar düz metin olarak sunulabilir. Her uygulama için ayrı kimlik kullanın ve IP kısıtlaması varsa mutlaka açın. Sızıntı şüphesinde ise sıra nettir: önce iptal edin, sonra araştırın.
Sıkça Sorulan Sorular (SSS)
Gönderim şifresi sızarsa ne kadar ciddi?
Çok ciddi. Sizin altyapınızdan gönderilen iletiler SPF, DKIM ve DMARC kontrollerinden geçer — yani kimlik avı iletileri tamamen meşru görünür. Müşterileriniz sizin adınıza kandırılır ve itibarınız çöker.
Kimlik bilgilerini nerede saklamalıyım?
Kod içinde ve web kökünde asla. Web kökündeki bir yapılandırma dosyası, sunucu yapılandırması bozulduğunda düz metin olarak sunulabilir — bu gerçekten yaşanan bir senaryodur. Ortam değişkeni veya sır yönetim sistemi tercih edin.
Kod deposuna eklediğim şifreyi sildim, yeterli mi?
Yeterli değil. Bir kez eklenen şifre, sonradan silinse bile geçmiş kayıtlarda kalır ve depoya erişimi olan herkes bulabilir. O şifre yanmıştır — mutlaka değiştirin.
Kimliğimin kullanıldığını nasıl anlarım?
En kesin gösterge, gönderim kimliğinizin sunucunuz dışındaki bir IP adresinden kullanılmasıdır. Ayrıca beklenmedik gönderim hacmi, tanımadığınız alıcılar ve gece saatlerindeki aktivite uyarı işaretleridir. IP kısıtlama özelliği varsa mutlaka açın.
