Joomla güvenlik önlemi

[bolluk]

Mrb Arkadaşlar;
Anlatacaklarımı ustalarım da onaylarsa,oldukça önemli bir güvenlik önlemini sizlere sunmak istiyorum.
Ftp'deki configuration.php dosyasının chmod ayarını 600 yaptım.Bu dosyayı mevcut yerinden alıp diğer klasörlerden her hangi birinin içine koydum. Eski mevcut yerine aynı isimle başka bir configuration.php dosyası oluşturdum.Onun da chmod ayarını 600 yaptım.Ama içine sadece asıl configuration.php'ye yönlendirme kodu koydum. Tabi buna ulaşan belirtilen adresten kolayca configuration.php'i bulabilir. Bu yönlendirme kodunu okuyamamaları için "online free-php-encoder.php"
ile şifreledim. Bence artık bir iki denemede de bulabilirler conf.php'yi, saatlerce aramaları da gerekebilir.Bilmem bu anlattıklarım işinize yarar mı. Saygılar hepinize.

[Arfmin]

Güzel ve etkili bir yöntem. Ancak encoder işleminin doğrudan configuration.php dosyasına uygulanmasının daha etkili olacağı düşüncesindeyim. Umarım Joomla 1.6 geliştiricileri bu yönde bir çalışma yapıyorlardır.

[bolluk]

Güzel ve etkili bir yöntem. Ancak encoder işleminin doğrudan configuration.php dosyasına uygulanmasının daha etkili olacağı düşüncesindeyim. Umarım Joomla 1.6 geliştiricileri bu yönde bir çalışma yapıyorlardır.

Mrb.Arfmin;
Dediğinizi uyguladım. Ama bazı sorunlar oluştu. Onun için bu yöntemi tercih ettim.

[Arfmin]

Yönteminiz ustaca ancak sakladığınız configuration.php'nin bulunma olasalığı tartışılır.

configuration.php dosyasında local ve web ortamında yaptığım encoder uygulama testinde bir sorun gözlemlemedim. Sizde nasıl bir sorun oluştu?

[pisdoktor]

1.5 Sürümlerinde configuration.php dosyasına ulaşmalarının ne gibi bir zararı olacak onu anlamadım? bu dosyaya erişen kötü niyetli birisi siteyi bozacaksa index.php ye dadanır...

[bolluk]

1.5 Sürümlerinde configuration.php dosyasına ulaşmalarının ne gibi bir zararı olacak onu anlamadım? bu dosyaya erişen kötü niyetli birisi siteyi bozacaksa index.php ye dadanır...

Mrb ustam;
Her hangi bir iddiada değilim tabi. Sadece önlemlerden biri olur diye düşünüyorum.En azından şifrelerin korunur. Ona bakarsan sen her hangi bir iki dosyayı silse joomla çalışamaz hale gelir. Amacımız bu dosyaların bulunduğu alana kimseyi sokmamak ve joomlayı beton gibi sağlam yapmak. index.php ve diğerleri ile ilgili daha sağlam önerilerini duymak isteriz. Saygılar.

[bolluk]

Yönteminiz ustaca ancak sakladığınız configuration.php'nin bulunma olasalığı tartışılır.

configuration.php dosyasında local ve web ortamında yaptığım encoder uygulama testinde bir sorun gözlemlemedim. Sizde nasıl bir sorun oluştu?

Mrb. Arfmin;
Nasıl bir hata oluştuğunu şimdi tam hatırlamıyorum ama vazgeçmek zorunda kaldım. Yoksa süper bir şeydi.
Ayrıca seo ayarlarını yapınca benim yaptığım adres sistemi de çalışmadı. Adres kodları kendiliğinden silindi normal configuration.php haline geldi.
Saygılar

[Arfmin]

Mrb. Arfmin;
Nasıl bir hata oluştuğunu şimdi tam hatırlamıyorum ama vazgeçmek zorunda kaldım. Yoksa süper bir şeydi.
Ayrıca seo ayarlarını yapınca benim yaptığım adres sistemi de çalışmadı. Adres kodları kendiliğinden silindi normal configuration.php haline geldi.
Saygılar

Teşekkür ederim.

[chifo9]

bahsi geçen encoderların işe yaramadığını belirtmek isterim çünkü decoderleri mevcut. ftp me atılan xxx.php isimli dosyayı şahıs bahsettiğiniz yöntem ile şifrelemiş ama bakiim neymiş bunlar dediğimde kodlar ayna gibi çıktı. üstelik decoder online :D bence hiç uğraşmayın kaç gündür bu güvenlik yöntemleri yüzünden paranoyak oldum. hatta akar abimizde bir yöntem önermişti onunda işe yaramadığını söyleyebilirim. ama ilgilendiği için yinede çok teşekkür ederim. yöntem aşağıdaki koddan ibaret mutlaka forumda görmüşsünüzdür. ama işe yaramıyor. neden derseniz bu işlemi yaptıktan sonra joomla admin panelinde genel ayarlarda bir değişiklik yaparsanız configuration.php dosyasının içeriği eski halini geri alıyor. ve ayrıca kara listede belirtilen açığı bulunan eklentilere gözattım hiçbiri sitelerimde mevcut değil. aşırı saçma sapan eklentilerde kurulu değil. ama mutlaka biyerde açık var. config dosyasının okunması için gerekli mutlaka bir açık olması gerek. ben joomla da hala bir açık olduğunu düşünüyorum. youtube a girip videoları izledim bu sql injection olaylarını. ve makale id leri ile adamlar acaip işler yapıyorlar. onları gördükten sonra açık olmayacağını düşünmemek elde değil. hala arayış içindeyim.

<?php
require( dirname( __FILE__ ) . '/../../design2-files/joomla.conf' );
?>

[chifo9]

1.5 Sürümlerinde configuration.php dosyasına ulaşmalarının ne gibi bir zararı olacak onu anlamadım? bu dosyaya erişen kötü niyetli birisi siteyi bozacaksa index.php ye dadanır...

başına geldiğinde anlarsın. index.php yi değiştirmeye ihtiyaç duymuyorlar hatta senin sitene zarar vermiyolar. kötü niyetleri için ftp ni barındırıcı olarak kullanıyorlar devlete ait web sitelerine zarar veriyorlar. polis ilk seni arıyor :D başıma geldi ordan biliyorum :D

[Arfmin]

bahsi geçen encoderların işe yaramadığını belirtmek isterim çünkü decoderleri mevcut. ftp me atılan xxx.php isimli dosyayı şahıs bahsettiğiniz yöntem ile şifrelemiş ama bakiim neymiş bunlar dediğimde kodlar ayna gibi çıktı. üstelik decoder online :D bence hiç uğraşmayın kaç gündür bu güvenlik yöntemleri yüzünden paranoyak oldum. hatta akar abimizde bir yöntem önermişti onunda işe yaramadığını söyleyebilirim. ama ilgilendiği için yinede çok teşekkür ederim. yöntem aşağıdaki koddan ibaret mutlaka forumda görmüşsünüzdür. ama işe yaramıyor. neden derseniz bu işlemi yaptıktan sonra joomla admin panelinde genel ayarlarda bir değişiklik yaparsanız configuration.php dosyasının içeriği eski halini geri alıyor. ve ayrıca kara listede belirtilen açığı bulunan eklentilere gözattım hiçbiri sitelerimde mevcut değil. aşırı saçma sapan eklentilerde kurulu değil. ama mutlaka biyerde açık var. config dosyasının okunması için gerekli mutlaka bir açık olması gerek. ben joomla da hala bir açık olduğunu düşünüyorum. youtube a girip videoları izledim bu sql injection olaylarını. ve makale id leri ile adamlar acaip işler yapıyorlar. onları gördükten sonra açık olmayacağını düşünmemek elde değil. hala arayış içindeyim.

<?php
require( dirname( __FILE__ ) . '/../../design2-files/joomla.conf' );
?>


Uzun zamandır benimde dikkatimi çekmeye başladı. Değişik bir yöntem kullanılmaya başlanmış. Önlem alabilmek için açığa çıkarıp deşifre etmek gerekir.

[chifo9]

evet kesinlikle bir açık olduğundan şüpheleniyorum. joomla güvenliği ile ilgili bütün makaleleri okuyorum. yabancı sitelere girip araştırıyorum. bakalım bişey çıkarabilecekmiyiz. 1.5.19 sürümünde açık var demiştim ve o yorumlarımdan sonra 1.5.20 güvenlik sürümü çıkmıştı. sanırım yeni sürüm geliyor! ama yoruyor artık insanı her seferinde arayışa girmek çok sıkıyor...

[Arfmin]

Ben 1.5.20'de açık olduğunu sanmıyorum. Filist eklentisi ile yaptırdığım bir kaç incelemede şifrelerin doğrudan kullanıldığına kanaat getirdim. Geriye keylogger şüphesi kalıyor. Bazı sitelerde keylogger ile filezella içinde depolanan şifrelerin çalınabildiği belirtiliyor.

[bolluk]

chifo9'nun dediği gibi benim de configuration.php dosyası aynen geri geldi. Hatta bazı sitelerimde geri gelmemişti. Ama şimdi anlıyorum ki Yönetim panelinde değişiklik yaptıklarım herhalde geri geldi. Yapmadıklarım ise geri gelmemişti. Mücadele şart arkadaşlar.Paylaşımlar biraz daha anlaşılır ve dikkatli yapılırsa, arkadaşlar oyunu yarım bırakmazsa, sanırım daha etkili olacaktır.

[Akar]

Arkadaşlar, dediğiniz gibi son zamanda Joomla! üzerine saldırılar çoğaldı. Bu saldırıların çoğunda, eskisi değil doğrudan veritabanına giriş yapıldığını, dosya değiştirilmediğini görüyoruz. Düzenlemelerin veritabanında çeşitli tablolarda olduğunu görüyoruz. En azından benim 1.5.20'den bu yana artan saldırılarda müşteri sitelerinde gözlemlediğim durum bu. Yalnız sitelerin tamamının 1.5.20 olduğunu söyleyemem. Önceden bsürüm açığı olduğunu düşündüğüm bu durumun, aynı şekilde saldırı alan eski sürümler sebebiyle yanlış tesbit olduğu kanaatine vardım.

Dosya şifrelemenin herhangi bir faydası olduğunu bugüne kadar düşünmedim...halen de aynı kanıdayım. Ancak Joomla! tarafından da kayda alınan ve yukarıda verilen dosya içeriğini başka yerden çekme yönteminin, asıl dosya public_html ile aynı seviyede olduğu sürece bir kısım erişim yöntemlerine karşı çare olduğu konusunda hemfikirim.

Her ne kadar doğrudan veritabanına erişim olsa ve dosya düzenlemesi yapılmasa da veritabanı erişim bilgilerinin dosya okumadan alınması çok nadir gerçekleşebilecek bir durum. Keylogger şüphesine katılabilirim ama bunun son dönemde karşılaştığım çokça saldırılarda kullanılan yöntem olduğu sanmıyorum. Ayrıca keylogger ile gereken bilgiyi ayıklamak öok kolay olmadığından bunun genel saldırılarda kullnıldığını görmüyoruz. Daha çok hedeflenmiş saldırılarda, düşmalıklarda falan kullanılıyor.

Dolayısıyla son olarak önerim, configuration.php dosyasını şifrelemek yerine bu dosyaya erişim için bir çok yöntemi engellenebilecek şekilde, yayın dizini dışında barındırmak ve ftp katmanını doğru kullanmak.

Benim önerim:

Joomla özelliklerinden ftp katmanını kullanıyorsanız:

Sadece Joomla için kullanmak üzere bir ftp kullanıcısı oluşturup, bunun erişim dizinini public_html ya da sizde httpdocs ise httpdocs olarak belirleyin.
Joomla için ftp katmanını etkinleştiriyorsanız kullanıcı adı ve parola bilgilerini girmeyin. Lazım oldukça sistem sorar bu durumda, o zaman girersiniz. Dosyada kayıtlı olmaz böylece.


Aşağıdaki dosyayı configuration.php olarak kaydedip normal yerine koyun. Bu sizin sahte dosyanızdır:<?php
require( dirname( __FILE__ ) . '/../birdizinadi/birdosyaismi.conf' );
?>Ardından asıl configuration.php dosyanızın adını birdosyaismi.conf olarak değiştirin. Bu dosyayı public_html ya da yayın dizininiz httpdocs olsun; bu dizin içne değil dışına yeni bir klasör oluştuarak onun içine koyun. Yukarıdaki örneğe göre public_html veya httpdocs ile aynı seviyede birdizinadi isimli klasör oluşturun. Aynı örnek için adını birdosyaismi.conf yaptığınız yapılandırma dosyasını bu yeni dizin içine gönderin.

Burada birdizinadi ve birdosyaismi.conf örnek olarak verilmiştir. Bu isimleri istediğiniz gibi düzenleyip site dizinindeki sahte configuration.php dosyası içindeki ilgili yerleri buna göre düzenleyin.

Dosyanın chmod değerini 444 yapmanız yeterli olur.

Bu şekilde kullanımda Joomla! Genel Yapılandırma menüsü içindeki işlemleri oradan değil, diğer dizine taşıdığınız dosyadan yapmanız gerekir. Çünkü Genel Yapılandırma içinde işlem yapar ve kaydederseniz, sistem de yazma izni veriyorsa sahte dosya içeriği sistem tarafından normal bir configuration.php dosyası şeklinde tekrar oluşturulur. Yaptıklarınızın anlamı kalmaz, tüm bilgiler dosya içine yeniden yazılmış olur. (bolluk'un başına gelen)

Bu öneri sadece son dönemde gördüğüm, configuration.php dosyasının içeriğinin okunmasıyla yapılan saldırılara karşıdır ve saldırılarda başka bildiğimiz ya da bilmediğimiz yöntemlerle başka şeyler yapılabilir.

[bolluk]

Ayrıntılı açıklamalarınız için teşekkürler Akar Bey.
İyi ki varsınız.

[CLassMaN]

arkadaşlar configuration.php şifreleyebilirseniz yani decodesi olmayacak şekilde olucak. yaparsanız bir sorun çıkmaz. onun haricinde configuration.php yoluda değiştirseniz. adam sonuçta sunucu tarafında shell ile istediği gibi dolaştığı için asıl ayar dosyasınıda bulucaktır. eklentilerde bi açık yoksa cmsturk teki arkadaşlar sürekli yeni sürümleri koyuyorlar alıp güncellemeniz. sizin sitenizde açık olmasa da diğer sitelerde olmadığı anlamına gelmez. onun için kafam rahat olsun diyorsan sağlam bir sunucuya geçmen. onun haricinde hacklenirsin.

[Akar]

arkadaşlar configuration.php şifreleyebilirseniz yani decodesi olmayacak şekilde olucak. yaparsanız bir sorun çıkmaz. onun haricinde configuration.php yoluda değiştirseniz. adam sonuçta sunucu tarafında shell ile istediği gibi dolaştığı için asıl ayar dosyasınıda bulucaktır. eklentilerde bi açık yoksa cmsturk teki arkadaşlar sürekli yeni sürümleri koyuyorlar alıp güncellemeniz. sizin sitenizde açık olmasa da diğer sitelerde olmadığı anlamına gelmez. onun için kafam rahat olsun diyorsan sağlam bir sunucuya geçmen. onun haricinde hacklenirsin.İşte olay bu zaten. Sunucuda shell ile istendiğigi gibi dolaşılabiliyorsa, ne yapsanız faydası olmazç. Adam sizin şifrelenmiş dosyanız yerine kendisi yenisini oluşturur kolayca :) Bu kadar güvensiz bir sunucuda birşeyler yapmanızın anlamı yok. Yöntemler hesabın içine girilip gezilme durumlaı için değil, dışarıdan doğrudan erişimler içindir. Yoksa adinin biri hesabınıza girdiyse oradan boş çıkmaz.