Tek panelden yüzlerce müşteri: MSP platformu düştüğünde ilk 24 saatte ne yapılır?

Bak usta, RMM paneli dediğin şey sahada bir anahtarlık gibidir. Yüzlerce müşterinin, binlerce cihazın kapısı o halkada asılıdır. Halka sağlamken kimse dönüp bakmaz. Bu hafta N-able'ın N-central ortamını kapatması hepimize o halkaya bakmayı hatırlattı.

Olguyu bir daha koyalım: bir araştırmacı 8 Kasım gecesi N-central'da 30'dan fazla açığı PoC'leriyle GitHub'a döktü. Üretici ertesi gün hosted ortamları Amerika, Avrupa ve Asya-Pasifik'te kapattı, şirket içi kurulum yapanlara da sunucularını geçici olarak kapatmalarını önerdi. Şirket aktif istismar görmediğini, hotfix hazırladığını söylüyor. Açıklamanın üreticiye haber verilmeden yapılması ayrı bir tartışma; ben bugün garajdaki işe bakacağım.

Panel kararınca ne durur?

Sahada iş böyle dönmez, "RMM gitti, bir iki gün idare ederiz" denmez. RMM gidince şunlar birlikte gider: otomatik patch dağıtımı, gece çalışan bakım script'leri, disk ve servis alarmları, uzaktan oturum. Yani sadece bir araç değil, operasyonun ritmi durur. Üstelik bunun Patch Tuesday haftasına denk gelmesi işi zorlaştırıyor.

Bir de öbür yüzü var. RMM'in kendisi saldırganın en sevdiği anahtardır; ele geçirilen bir panel, yönetilen her cihaza meşru yoldan komut göndermek demek. Elastic'in raporu da saldırganların RMM yazılımlarıyla iş gördüğünü kayda geçiriyor. Bu yüzden üreticinin "kapatın" demesi abartı değil, ihtiyat.

İlk 24 saatin iş listesi

Usta-çırak usulü sıralayayım:

• Önce envanter. Hangi müşteri, hangi cihaz bu panelden yönetiliyordu? Listeyi panelin içinden değil, dışarıdaki CMDB'den ya da faturalama kayıtlarından çıkarın. Panel kapalıyken o listeye ulaşamıyorsanız ilk dersinizi aldınız.
• Kapatma kararını change kaydına bağlayın. Şirket içi sunucuyu kapatmak da bir değişikliktir. Kim karar verdi, saat kaçta, hangi müşteriye haber verildi; hepsi kayıtta olsun. Kapatamıyorsanız en azından yönetim arayüzünün internete açıklığını kaldırın.
• İzi kaybetmeyin. Sunucuyu kapatmadan önce logları ve disk görüntüsünü saklayın. İleride "biz etkilendik mi?" sorusunun cevabı oradadır.
• Kritik cihazlar için ikinci yol. Gece aksayacak yedekleme, kritik bir sunucunun yaması, bir firewall'un izlenmesi… Bunlar için geçici, belgelenmiş ve yetkisi sınırlı bir alternatif belirleyin. Panik içinde herkesin kendi uzak masaüstü aracını kurması, bir açığı kapatırken on yenisini açmaktır.
• Müşteriye düz konuşun. Ne durdu, ne çalışıyor, bir sonraki bilgi ne zaman gelecek. Barracuda'nın anketi MSP arayan kurumların büyük kısmının sağlayıcının kurtarma becerisine güvenmediğini söylüyor; güven böyle günlerde kazanılır ya da kaybedilir.

Hotfix gelince acele etme

Hotfix çıktığında ilk refleks "hemen bas" olur. Bas, ama sırayla: üretici notunu oku, test ortamında dene, sonra üretime al. Paneli açmadan önce yönetici hesaplarını tek tek gözden geçir; tanımadığın, yeni oluşmuş bir hesap varsa açılış bekleyebilir. Yönetici hesaplarında MFA ve ayrı yönetici kimliği zaten olmalıydı; olmadıysa bu yeniden açılışın şartı olsun.

Kalıcı hardening tarafında da üç şey var: yönetim arayüzü internete değil yönetim ağına bakmalı, panelden çalıştırılabilecek script'ler onaylı bir kütüphaneyle sınırlanmalı, panel dışı bir acil durum erişim planı yazılı olmalı. Bunlar yeni öğütler değil; ama bu hafta neden yazıldıklarını herkes gördü.

Son söz

Tek panelden yüzlerce müşteriyi yönetmek verimliliktir, tek panelden yüzlerce müşteriyi kaybetmek de aynı mimarinin öbür yüzü. Bak usta, kriz günü yazılan plan plan değildir, not kâğıdıdır. Bu hafta RMM'in yokluğunda neyin duracağını bir sayfaya yazın, o sayfayı panelin dışında saklayın. Bir sonraki karanlıkta el yordamıyla değil, listeyle çalışırsınız.