· kaynak dev.to (home feed)
MySQL'un genel sorgu log'u sessizce düz metin parolaları kaydediyor
Bir dev.to yazısı, general_log açık olduğunda MySQL ve MariaDB'nin genel sorgu log'unun CREATE USER ve ALTER USER komutlarındaki parolalar dahil her ifadeyi kelimesi kelimesine kaydettiği konusunda uyarıyor.

dev.to'da yayımlanan bir yazı, rutin bir MySQL ve MariaDB tanılama ayarındaki sessiz bir güvenlik sorununa dikkat çekiyor: genel sorgu log'unun açılması, sunucunun aldığı her ifadenin kelimesi kelimesine düz metin kaydını üretiyor ve CREATE USER ... IDENTIFIED BY 'password' gibi hesap yönetimi ifadeleri parola tamamen korunmuş halde bu kayda düşüyor.
Genel sorgu log'u varsayılan olarak kapalıdır. dev.to yazısına göre general_log = 1 ayarlanınca her bağlantı, her ifade ve her bağlantı kesme işlemi log_output tarafından seçilen hedefe kaydediliyor; bu hedef bir dosya, bir tablo veya ikisi olabilir ve dosya yolu general_log_file ile belirlenir. İfadeler alındıkları haliyle, hiç değiştirilmeden yazılır.
Diske ne düşüyor
Yazıya göre CREATE USER'ın yanı sıra ALTER USER ... IDENTIFIED BY, GRANT ... IDENTIFIED BY ve değişmez (literal) bir sır içeren herhangi bir uygulama sorgusu da gönderildiği gibi çıktıda yer alıyor. Oturum değerleri, tek kullanımlık token'lar veya kişisel veri taşıyan ifadeler de yakalanıyor.
Bu değişken, yapılandırma dosyasına dokunulmadan, SYSTEM_VARIABLES_ADMIN yetkisine sahip herhangi bir hesap tarafından runtime'da da açılabilir. Yazar bunun denetimler için önemli olduğunu savunuyor: önemli sorular log'u kimin açabildiği ve çıktının gerçekte nereye gittiği haline geliyor; yapılandırma dosyasını incelemek bu ikisine de cevap vermiyor çünkü dinamik bir ayar dosyayı geçersiz kılıyor.
Açık bırakmanın riskli olmasının nedeni
Yazı, log'un sınırlı bir inceleme dışında çalıştırılmasının üç sorununu sıralıyor:
- Kimse böyle sınıflandırmadığı halde bir kimlik bilgisi deposuna dönüşüyor. Loglanan bir ifadedeki parola, dosyayı okuyabilen herkese açığa çıkıyor ve bir veri dizinindeki izinler normalde içeriğin gizliliği için değil, sunucu süreci için ayarlanmıştır.
- Genişlik. Log, izleme, raporlama ve uygulama hesapları dahil her hesaptan gelen her sorguyu tutuyor; dolayısıyla dosyayı okuyan tek biri fiilen sunucunun tamamını görmüş oluyor.
- Saklama süresi. Döndürülen log'lar operatörün yapılandırdığı hedefe kopyalanıyor ve bir yedekleme biriminde duran bir kopya, onu üreten incelemeden daha uzun süre yaşıyor.
Komşu log'lar
Yazıya göre slow query log ve binary log, tanımlı koşullar altında ifadeleri kaydediyor ve ifadeye ve replikasyon formatına bağlı olarak değişmez değerleri de yakalayabiliyor. Genel log üçünün en genişi ve aceleyle birisi tarafından en çok açılması muhtemel olanı.
Bir inceleme kontrol listesi
Yazı şu önerileri sıralıyor:
- Dinamik bir değişken ayarlandığında yapılandırma dosyası bağlayıcı olmadığı için her sunucuda
general_log,log_outputvegeneral_log_file'ın runtime değerlerini kontrol edin. - Kullanımı sınırlandırın: log'u tanımlı bir süre için açın, çıktıyı kontrollü bir konuma yönlendirin, sonra devre dışı bırakıp döndürün ve ikisini de kimin yaptığını kaydedin.
- Fiilen bir ifşa yeteneği olan
SYSTEM_VARIABLES_ADMINyetkisini kısıtlayın. - Çıktıyı bir sır olarak koruyun; dosya izinleri, içindeki ifadelerin hassasiyetine uygun, genellikle veri dizini varsayılanından daha katı olmalı.
- Değişmez değer içeren ifadeler için yedekleri ve log iletimini inceleyin ve saklamadan önce temizlemeyi düşünün.
- Süregelen tanılama için performans şemasını ve iş yüküne göre ayarlanmış
long_query_timeile slow query log'u tercih edin; çünkü ikisi de varsayılan olarak daha az kaydeder.
Neden önemli
Genel sorgu log'u tam tasarlandığı gibi çalışan, belgelenmiş bir özellik ve yazı, gerçek maruziyetin log'un açık olup olmamasına, çıktıyı kimin okuyabildiğine ve iş yükünün hangi ifadeleri gönderdiğine bağlı olduğunu özenle belirtiyor. Onu pratik bir tuzak yapan da tam bu: baskı altında birisinin uzandığı anahtar, dinamik olduğu için yapılandırma dosyası denetimlerinden kaçıyor ve rutin yönetimi sessizce, kopyaları döndürme ve yedekler yoluyla yayılan kalıcı bir kimlik bilgisi deposuna dönüştürüyor. Log dosyasına sır muamelesi yapmak ve onu açma ayrıcalığını bir ifşa yeteneği olarak görmek, yazının veritabanı yöneticilerinden istediği operasyonel değişimdir.
- #mysql
- #mariadb
- #database-security
- #logging
- #sysadmin