PHP'deki iki kritik güvenlik açığı için yama yayımlanmadan gelen uyarı, web yöneticilerini alışılmadık bir seçenekle karşı karşıya bırakıyor. AB kurumlarını koruyan CERT-EU, açıkları hızla yamalayamayan kurumların sitelerini geçici olarak çevrimdışı almayı düşünmesini söyledi. Asıl risk, yamanın kendisinden çok onun yayımlanmasından sonra açılan kısa pencerede yatıyor.

Ne oldu?

CERT-EU, PHP'nin iki kritik açığına karşı uyarı yayımladı. PHP projesi düzeltmeleri 21 Ekim Çarşamba günü 14:00 UTC'de, yani Türkiye saatiyle 17:00'de yayımlayacak. Yama çıkana kadar hızlıca güncelleme yapamayacak kurumlar için tavsiye net: siteyi kapatmayı değerlendirin. Açıkların teknik ayrıntıları bu yazının yazıldığı anda kamuya açık değil; bu yüzden etki alanı hakkında kesin bir şey söylemek yerine yöntemi ve riski konuşmak daha doğru.

Neden yama saati asıl risk penceresi?

Açık kaynak projelerde yama, aynı zamanda bir ipucudur. Düzeltme kodu herkesin görebileceği bir depoya girdiği anda, ne değiştiğini okumak isteyen herkes açığın nerede olduğunu öğrenir. Buna yama farkı analizi deniyor ve deneyimli bir saldırgan için bu iş saatlerle, bazen daha kısa sürede ölçülüyor. Savunan taraf ise yamayı test etmek, sunucuya dağıtmak ve gerekirse eklentilerle uyumunu doğrulamak zorunda.

Bu asimetri yeni değil. Log4Shell'den birçok kurumsal VPN ve dosya transfer ürününe kadar son yılların büyük olaylarında aynı örüntü tekrarlandı: yama çıktı, tarama trafiği hızla arttı, yamalamayanlar ilk dalgada vuruldu. CERT-EU'nun "kapatın" tavsiyesi bu tecrübenin sonucu. Açık kritikse ve saldırı uzaktan, kimlik doğrulamasız yapılabiliyorsa, internete açık bir sunucu otomatik tarayıcıların ilk hedefi olur.

PHP'nin ölçeği riski büyütüyor. Web sitelerinin büyük bir bölümü sunucu tarafında PHP çalıştırıyor; WordPress, Joomla, Drupal, Laravel ve çok sayıda e-ticaret altyapısı buna dayanıyor. Tek bir çekirdek açığı, tek tek eklenti açıklarından farklı olarak tüm bu ekosistemi aynı anda etkiler. Saldırgan hedefini seçmek zorunda kalmaz; geniş bir IP aralığını tarayıp yanıt veren sürümlere bakması yeter.

En kırılgan grup, desteği biten PHP sürümlerini çalıştıranlar. Proje yalnızca belirli sürümlere güvenlik yaması verir ve hangi dalların destekte olduğunu resmi sayfasında yayımlar. Eski bir sürümde yama hiç gelmeyebilir. Paylaşımlı hosting'de sürümü yükseltmek çoğu zaman hosting firmasının ya da kontrol panelindeki bir seçeneğin elinde; site sahibi "yamayı ben uygularım" diyemiyor.

Türkiye'deki küçük işletme siteleri için ne anlama geliyor?

Türkiye'de küçük işletme web siteleri büyük oranda paylaşımlı hosting üzerinde, çoğunlukla WordPress ve benzeri bir PHP tabanlı sistemle çalışıyor. Birçoğunu kuran ajans ya da freelancer artık ilgilenmiyor, site sahibi de panelde hangi PHP sürümünün seçili olduğunu bilmiyor. Bu tablo, yama gününde iki sorun yaratıyor: kimse sorumluluk almıyor ve eski sürümde takılı kalmış siteler fark edilmiyor.

Aşağıdaki tablo, siteyi kapatma tavsiyesinin kime ne kadar uyduğunu özetliyor. Bu bir editöryal değerlendirme; kesin kural değil.

DurumKapatma gerçekçi mi?Önerilen adım
Tanıtım amaçlı, trafik ve gelir düşük siteEvet, kısa süre içinYama çıkana kadar bakım sayfası, ardından güncelleme
E-ticaret, ödeme veya üyelik içeren siteKısmenÖnce hosting'den yama takvimini sorun; yamalanamıyorsa sipariş akışını durdurun
Kurumsal sistem, kritik hizmetHayır, tek başına çözüm değilWeb uygulama güvenlik duvarı kuralları, erişim kısıtlama, 7/24 izleme
Desteği bitmiş PHP sürümü kullanan siteYama gelmeyebilirSürüm yükseltmeyi acil plana alın; olmazsa siteyi statik hale getirin

Kapatmanın gerçekçi olmadığı durumlar çok. Bir hastane randevu sistemi ya da bir kargo takip sayfası saatlerce kapanamaz. Bu kurumlar için daha makul yol, yama çıktığı anda hazır bir dağıtım hattı kurmak, o ana kadar yönetim panellerini ve gereksiz uç noktaları IP kısıtlamasıyla kapatmak, günlükleri yakından izlemek. Kapatma tavsiyesi, bu önlemleri alamayacak ya da yamayı hızlı uygulayamayacak kurumlar için son çare.

Bir başka nokta da yamayı uygulamanın yeterli olmaması. Sunucuya yama gelse bile, yama öncesi dönemde sızılmışsa arka kapı kalabilir. Yama sonrası dosya bütünlüğünü, yeni oluşan yönetici hesaplarını ve beklenmedik zamanlanmış görevleri kontrol etmek gerekiyor.

Sırada ne var?

İlk izlenecek şey yamanın kapsamı: hangi PHP dalları düzeltiliyor, hangileri destek dışı kalıyor. İkincisi, hosting sağlayıcılarının tepki hızı. Büyük sağlayıcılar sunucu paketlerini birkaç saat içinde güncelleyebilir; küçük sağlayıcılar günler alabilir. Üçüncüsü, yama farkından türetilmiş sömürü kodunun kamuya düşüp düşmediği. Böyle bir kod yayımlanırsa tarama trafiği genellikle birkaç saat içinde belirgin biçimde artar.

Site sahipleri için bugün yapılabilecekler basit: hosting panelinden PHP sürümünü öğrenmek, sağlayıcıya yama planını sormak, yedeği güncel tutmak ve yama gelir gelmez uygulamak.

CERT-EU'nun tavsiyesi abartılı bir panik değil, ama herkese uymuyor. Kapatma, yamayı hızlı uygulayamayan ve çevrimdışı kalmanın maliyetini kaldırabilen siteler için mantıklı; asıl ders ise yama süreci olmayan sitelerin bu tür günlerde ister istemez kumar oynadığı.