Kurumsal oltalama (phishing) saldırılarına karşı e-posta güvenlik duvarı: SPF, DKIM, DMARC kayıtları, sahte fatura ve siber dolandırıcılık koruma rehberi.
Hızlı Özet (TL;DR)
Başarılı olan kurumsal siber saldırıların, veri sızıntılarının ve fidye yazılımı (ransomware) vakalarının %90’ından fazlası karmaşık sistem açıklarından değil; personelin gelen kutusuna düşen sahte bir e-postadaki zararlı bağlantıya tıklaması veya virüslü eki açmasıyla başlar. Oltalama (Phishing / Spear-Phishing) saldırıları; gümrük konşimentosu, kargo takip belgesi, sahte banka dekontu veya tedarikçi IBAN değişiklik bildirimi kılığına girerek şirketleri milyonlarca liralık zarara uğratır. Bu tehdidi durdurmanın tek yolu DNS tabanlı kimlik doğrulama protokollerini (SPF, DKIM, DMARC) ve yapay zeka destekli bir E-Posta Güvenlik Duvarı (Secure Email Gateway - SEG) mimarisini devreye almaktır.
İmalat ve Dış Ticaret Firmalarını Hedef Alan Spear-Phishing ve BEC Saldırıları
Klasik spam e-postalar rastgele milyonlarca kişiye gönderilirken, modern siber suç örgütleri belirli bir şirketi ve o şirketin satın alma, muhasebe veya dış ticaret personelini hedef alan Hedefli Oltalama (Spear-Phishing) ve Kurumsal E-Posta Dolandırıcılığı (BEC - Business Email Compromise) yöntemlerini kullanmaktadır.
Sanayi bölgelerinde en sık karşılaştığımız saldırı senaryosu “Ortadaki Adam ve Sahte IBAN Değişikliği” vakasıdır. Saldırganlar önce zayıf parolalı bir ihracat veya satın alma personelinin e-posta hesabına sızar ve aylarca hiçbir şey yapmadan sadece yazışmaları izler. Şirketin yurt dışındaki bir hammadde tedarikçisine 150.000 Euro ödeme yapacağı gün geldiğinde saldırgan devreye girer. Tedarikçinin alan adına çok benzeyen sahte bir alan adı (Look-alike Domain / Typosquatting — örneğin @tedarikci-gmbh.com yerine @tedar1kci-gmbh.com) satın alır veya DNS koruması olmayan şirketlerde doğrudan tedarikçinin gerçek e-posta adresini taklit ederek (Email Spoofing) muhasebeye şu mesajı atar: “Mevcut banka hesabımız denetim nedeniyle geçici olarak kapalıdır, ödemeyi ekteki güncel Proforma Fatura’da yer alan yeni SWIFT/IBAN hesabımıza göndermenizi rica ederiz.”
Eğer kurumda gelişmiş bir e-posta güvenlik duvarı ve DMARC doğrulaması yoksa, muhasebe personeli bu e-postanın gerçek tedarikçiden geldiğini sanarak parayı doğrudan siber korsanların hesabına havale eder.
Şirket E-Postalarını Koruyan 3 Temel Protokol: SPF, DKIM ve DMARC
Bir e-posta güvenlik mimarisinde hem kendi alan adınızın (domain) başkaları tarafından taklit edilmesini önlemek hem de size gelen sahte e-postaları kapıda yakalamak için DNS düzeyinde mutlaka bulunması gereken 3 kriptografik standart vardır:
| Protokol | Tam Adı | Çalışma Prensibi ve Ne İşe Yarar? | Eksikliğinde veya Hatalı Kurulumda Oluşan Risk |
|---|---|---|---|
| SPF | Sender Policy Framework | Alan adınız adına dünyada hangi IP adreslerinin ve sunucuların mail gönderebileceğini DNS TXT kaydıyla ilan eder | Saldırganlar kendi sunucularından sizin şirketinizin adını kullanarak müşterilerinize sahte mail atabilir |
| DKIM | DomainKeys Identified Mail | Gönderilen her e-postanın başlığını (Header) ve gövdesini 2048-bit RSA kriptografik dijital imzayla mühürler | E-posta yolda ele geçirilirse içindeki IBAN numarası veya ek dosya değiştirilebilir |
| DMARC | Domain-based Message Authentication, Reporting & Conformance | SPF veya DKIM doğrulamasından geçemeyen sahte maillere alıcı sunucunun ne yapacağını (none, quarantine, reject) emreder | SPF ve DKIM olsa bile, p=reject kuralı yoksa sahte mailler sadece “şüpheli” sayılıp gelen kutusuna düşmeye devam eder |
DMARC Politikalarında p=none Tuzağı ve p=reject Zorunluluğu
Sahada gerçekleştirdiğimiz sızma testi (Pentest) ve e-posta güvenlik denetimlerinde, birçok firmanın DMARC kaydı oluşturduğunu ancak politikayı v=DMARC1; p=none; olarak bıraktığını görüyoruz. p=none parametresi yalnızca izleme modudur; sahte e-postayı kesinlikle engellemez. Kurumsal e-posta sunucusu, CRM ve toplu mail servislerinin SPF/DKIM hizalaması (Alignment) tamamlandıktan sonra DMARC kaydı kademeli olarak p=quarantine (Karantinaya Al) ve nihayetinde p=reject (Anında Reddet ve Sil) seviyesine çekilmelidir.
E-Posta Güvenlik Duvarı (Secure Email Gateway - SEG) Yetenekleri
SPF, DKIM ve DMARC protokolleri gönderici kimliğini doğrular; ancak saldırgan ele geçirdiği gerçek bir Gmail, Outlook veya tedarikçi hesabından zararlı dosya gönderdiğinde DNS kayıtları tek başına yeterli olmaz. Bu noktada posta sunucunuzun (Exchange, Microsoft 365, Google Workspace veya Zimbra) önüne konumlandırılan E-Posta Güvenlik Duvarı (SEG) devreye girer:
1. Bulut Sandbox (Kum Havuzu) ile Sıfırıncı Gün (Zero-Day) Ek Analizi
Saldırganlar geleneksel antivirüsleri atlatmak için e-posta ekine .pdf.exe, .iso, .lnk, şifreli .zip veya içine zararlı makro (VBA) gizlenmiş Excel/Word (Siparis_Listesi.xlsm) dosyaları ekler. E-posta güvenlik duvarı şüpheli eki kullanıcıya teslim etmeden önce izole bir sanal makinede (Sandbox) açar. Dosya açıldığında arka planda PowerShell çalıştırmaya veya dış dünyadaki bir komuta kontrol (C2) sunucusuna bağlanmaya çalışırsa, e-posta anında imha edilir.
2. Dinamik Link Taraması ve Yeniden Yazma (Time-of-Click URL Rewriting)
Kurnaz saldırganlar e-postayı gönderdiği anda içindeki web linkini tamamen zararsız bir sayfaya yönlendirir. E-posta güvenlik filtrelerinden geçip kullanıcının kutusuna düştükten 30 dakika sonra ise linkin hedefini sahte bir Microsoft 365 şifre çalma ekranına çevirir. Time-of-Click teknolojisi, e-postadaki tüm linkleri özel bir vekil sunucu (Proxy) adresiyle değiştirir ve personel linke tıkladığı saniyede hedef sayfayı canlı olarak tarar.
3. CEO Sahteciliği (Impersonation Protection) ve Görsel Benzerlik Analizi
Şirketin genel müdürü veya yönetim kurulu başkanının adını (Ad Soyad <ceo.sirket@gmail.com>) kullanarak muhasebe departmanına “Toplantıdayım, telefonum çekmiyor, ekteki faturayı acil ödeyip dekontu bana atın” şeklinde gönderilen sosyal mühendislik mailleri, gönderici görünen adı (Display Name) ile gerçek zarf adresi (Envelope From) arasındaki uyuşmazlığı denetleyen yapay zeka kurallarıyla bloke edilir.
4. İçeriden Dışarıya Veri Sızıntısı Kontrolü (Outbound DLP)
E-posta güvenlik duvarı yalnızca dışarıdan gelen tehditleri değil, içeriden dışarıya çıkan e-postaları da denetler. Bir çalışan şirketin müşteri veritabanını, fiyat listesini veya gizli CAD projelerini kişisel e-posta adresine veya rakip firmaya göndermeye çalıştığında, DLP (Veri Sızıntısı Önleme) kuralları devreye girerek e-postayı çıkış kuyruğunda durdurur ve yönetici onayına düşürür.
Sosyal Mühendislik Tatbikatları ve Ağ Katmanı Entegrasyonu
Teknolojik önlemlerin yanında “İnsan Güvenlik Duvarı”nı (Human Firewall) güçlendirmek için yılda en az iki kez çalışanlara habersiz Oltalama Simülasyonu (Phishing Testi) uygulanmalıdır. Simülasyonda sahte linke tıklayan veya şifresini giren personel cezalandırılmaz; anında interaktif bir farkındalık eğitimine yönlendirilir. Ayrıca bir çalışan tüm uyarıları aşarak zararlı bir linke tıklasa bile, kurumsal ağın çıkışında yer alan güvenlik duvarı (Firewall) çözümleri üzerindeki DNS/Web filtreleme ve IPS motoru, kullanıcının o zararlı IP adresine erişmesini ağ katmanında keserek ikinci bir savunma hattı oluşturur.
Sıkça Sorulan Sorular
Microsoft 365 veya Google Workspace kullanıyoruz, yine de ek E-Posta Güvenlik Duvarı ve DMARC gerekir mi?
Evet. Microsoft 365 ve Google Workspace standart paketlerinde temel spam ve bilinen virüs koruması bulunur; ancak DMARC (p=reject) ve özel DKIM imzalaması siz DNS panelinizde manuel olarak yapılandırmadığınız sürece aktif değildir. Ayrıca gelişmiş BEC (Sahte IBAN/Fatura), QR kodlu oltalama (Quishing) ve sıfırıncı gün (Zero-Day) Sandbox analizleri için gelişmiş e-posta güvenlik politikalarının devreye alınması şarttır.
Tedarikçimizden gelen gerçek e-postanın içindeki IBAN’ın değiştirilip değiştirilmediğini nasıl anlarız?
Bunun için teknik ve idari iki kural birlikte uygulanmalıdır. Teknik olarak; e-posta güvenlik duvarında daha önce hiç yazışılmamış yeni alan adlarından veya benzer harfli (Look-alike) domainlerden gelen tüm maillere kırmızı “DİKKAT: İlk Kez İletişim Kurulan Harici Gönderici” bandı (Banner) eklenir. İdari olarak ise; e-posta ile gelen hiçbir IBAN/SWIFT değişiklik talebi, tedarikçinin önceden kayıtlı sabit telefon numarası sesli olarak aranıp teyit edilmeden muhasebe sistemine işlenmemelidir.
Şirketimizin gönderdiği e-postalar müşterilerimizin Spam (Gereksiz) kutusuna düşüyor, sebebi nedir?
Gönderdiğiniz kurumsal maillerin alıcıların Spam kutusuna düşmesinin veya Gmail/Yahoo/kurumsal sunucular tarafından reddedilmesinin en yaygın sebebi; alan adınızın SPF, DKIM ve DMARC kayıtlarının eksik/hatalı olması veya mail sunucunuzun IP adresinin Reverse DNS (PTR) kaydının bulunmamasıdır. Google ve Microsoft’un güncel gönderici politikaları gereği, bu üç kriptografik doğrulamayı eksiksiz sağlamayan alan adlarının teslim edilebilirlik (Deliverability) puanı düşürülmekte ve postaları otomatik olarak karantinaya alınmaktadır.