 |
| Oluşan hata alarmı |
Hata "syspolicy_purge_history" isimli SQL Server'ın SQL Server Agent Job tarihçesini silen Job'tan geliyordu. Bu standart, SQL Server kurulumuyla gelen bir Job'tır. Kısa süreli çalışmayışı kritik bir sorun yaratmaz, ama uzun süre çalışmazsa canınızı sıkabilecek sonuçlar doğurabilir. Sorunu inceleyince hatanın alındığı adımın Job'ın Powershell komutu içeren 3. adımı olduğunu gördüm. Önceden karşılaşmadığım bir hata idi, biraz derinine inmek istedim ve indikçe durum daha da ilginç bir hal alıyordu. Derken tamamen şansa işletim sistemi diski olan C: diskinin kök dizinindeki bazı "klasörlerin" uzantılarının *.exe olduğu çekti dikkatimi ve haliyle dehşete kapıldım!
 |
| Temsili ekran görüntüsü |
Böyle bir manzarayı görmeyeli en az 10-15 sene olmuştur... Çok şaşırdım. Canlı bir veritabanı sunucusunun işletim sistemi diski (C:) bu!
Hemen ilgili yöneticilere ve mühendis arkadaşlara haber verdim ve hep beraber durumu incelemeye başladık. Bir süre sonra kötü niyetli bir korsanın iç ağa dışarıdan giriş yaptığı, bunu da Domain Admin grubuna üye olan bir hesabın bilgilerini ele geçirerek yaptığı anlaşıldı. Hesap Domain Admin yetkisine sahip olduğu için kötü niyetli kişi ağda istediği gibi gezinmiş, antivirüs uygulamasını kapatmış ve kim bilir daha neler yapmış... Yaptığı birçok şey çeşitli mekanizmalarla kayıt altına alınmış; fakat hesap zaten varolan ve varolması beklenen bir hesap olduğu için hareketleri göze batmamış. Hesabın bilgilerini elde eden kötü niyetli kişinin ağda hemen veritabanı sunucularına yöneldiği anlaşılıyor. Birkaç kere veritabanına bağlanmayı denemiş, fakat izlediğimiz Best Practice'ler sayesinde veritabanlarına bağlanamamış. Eğer veritabanı sunucumuzda, birçok ortamda gördüğüm gibi Domain Admin'ler ve Local Administrator'lar için yetki tanımlı olsaydı bu ortamda ne durumda olurduk düşünmek bile istemiyorum.
Şu anda neyse ki her şey kontrol altında.
Peki bu atak vakitlice fark edilmeseydi ve müdahale edilmeseydi neler olabilirdi? Aklıma gelen birkaç olasılık şöyle:
- Sisteme giren kötü niyetli kişi tüm veritabanlarını ve uygulama kodlarını ele geçirebilirdi,
- Varolan sunuculardaki dosyalar son zamanlarda popüler olan bir saldırı yöntemiyle şifrelenebilir ve fidye istenebilirdi,
- Eğer veritabanına bağlanabilseydi ve yeterince dersine çalışmış olsaydı finansal verilerle oynayabilir ve kazanç elde etmeye çalışabilirdi,
- Sadece yıkıcı bir etkiye neden olmak için verileri sonra fark edeceğimiz şekilde kirletebilirdi, ki yedeklerden geri dönebilmek için çok geç olurdu veya yedekleri de silebilirdi.
Bu hikayeden veritabanı yönetimi ve güvenliği açısından çıkarılması gereken dersler:
- Sadece gereken kişilere, gerektiği kadar yetki verme prensibinden asla şaşmayın. Mümkünse yetkileri geçici olarak verin ve sadece gerektiği sürelerde verin. Eğer geliştirme ve canlı öncesi/kalite testi ortamlarınız varsa canlı veritabanı sunucularınızda kimseye yetki vermeyin,
- Gerekli yetkilendirmeleri yaptıktan sonra eğer varsa "sa" hesabını ya Disabled duruma getirin, ya da adını değiştirin, çünkü tüm korsanlar bu hesabın varlığından haberdardır,
- SQL Server'ı Default Instance olarak kurduğunuzda Database Engine servisi 1433 portunu kullanır ve tüm korsanlar bunu bilir, bu nedenle farklı bir port numarası kullanın,
- Veritabanınıza yapılan hatalı giriş denemelerini takip edin, ortamınızın çalışma doğası dışında belli bir eşik değer geçildiğinde alarm üretilmesini sağlayın,
- Bu senaryoda olduğu gibi normal şartlarda oluşmayan hataların başka sorunların göstergesi olabileceğini unutmayın,
- * Yedeklerinizi mümkünse şifreli (encrypted) saklayın, ki yedek dosyaları kötü niyetli kişilerce ele geçirilse dahi içeriğe ulaşamasınlar,
- * Mümkünse Transparent Data Encryption (TDE) özelliğinden faydalanın, ki doğrudan veritabanı dosyalarınız ele geçirilse bile veriler ele geçirilemesin,
- SQL Server ve işletim sistemi güvenlik güncellemelerini uygulamayı ihmal etmeyin.
* Şifreleme için kullandığınız sertifikaları veritabanı yedek dosyalarının olduğu yerden çok farklı bir konumda saklayın, ki korsan bu anahtara ulaşamasın ki şifreleme önleminiz işe yarasın.
Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com
Hiç yorum yok:
Yorum Gönder