Soru:
Bir güvenlik duvarının arkasındaysak, yine de güvenlik açıklarını yamalamamız / düzeltmemiz gerekir mi?
Rakesh N
2017-11-20 14:39:51 UTC
view on stackexchange narkive permalink

Yakın zamanda kuruluşumda güvenlik odaklı bir topluluğa katıldım. Ürünlerimizin birçoğu genel bulutta intranette (şirket içi) dağıtılmamaktadır. Dolayısıyla, dahili portallara yalnızca kuruluşun ağı içinden erişilebilir.

Son zamanlarda, üçüncü taraf bir Apache kitaplığının güvenlik açığı (görünüşe göre, bir uzaktan kod yürütme) yayınlandı. Güvenlik liderimiz bizden kitaplığı en son sabit sürüme hemen yükseltmemizi istemişti.

" Portala yalnızca bir güvenlik duvarının arkasındaki intranette erişildiğinden, kitaplığı yine de yükseltmemiz gerekiyor mu? " diye sordum. Lider, zaman yetersizliğinden dolayı ayrıntılı bir açıklama yapamadı ve yükseltmenin ne olursa olsun yapılması gerektiğini doğruladı.

Öyleyse, "bir güvenlik duvarının arkasında olduğumuz için varsayım?) bu tür güvenlik açıkları bizi etkilemez ".

Her şeyden önce, tüm dahili kullanıcılarınız güvenilir değildir.Herkesin her şeyi görmesini veya değiştirebilmesini istemezsiniz.Tam olarak ayrımı isteyen yeterli uyum çerçevesi vardır.İkincisi, derinlemesine Savunma ilkesi var, bir saldırgan bunu güvenlik duvarının etrafında dolaşabilir ve yanal hareketleri sınırlandırılmalıdır.Günümüzde BYOD, WLAN, yerinde ziyaretler ve internete yönelik hizmetlerle çevre artık son savunma hattı değil (ilk).Ancak sadece ilk nokta aciliyeti açıklayabilir.
ABD hükümetinin en yüksek güvenlik gereksinimlerine ve çalışanları için en zorlu geçmiş kontrollerine sahip organlarından biri olan NSA, şimdi birkaç kez kendilerinden biri tarafından tehlikeye atıldı.Çalışanlarınıza güvenmek iyidir, sistemlerinize yama yapmak daha da iyidir.
Güvenlik duvarlarına neden "güvenlik duvarı" dendiğini biliyor musunuz?Güvenlik duvarları * yangının yayılmasına karşı dayanıklı * duvarlardır.Hiç "bir güvenlik duvarının arkasındayız, bu yüzden duman alarmlarına, fıskiye sistemine veya acil durum çıkışlarına ihtiyacımız yok" der misiniz?Güvenlik duvarları yangının yayılmasına * direnir *;onları * engellemezler * ve bir * savunma stratejisinin * parçası olmaları * amaçlanmıştır.
"Bir kapının arkasındaysak, yine de ön kapımızı kilitlememiz gerekiyor mu?"
Yani dışarıdan doğrudan bir saldırıyı önlediniz.Ya intranet bilgisayarınızdan birinin güvenliği ihlal edilirse ve sonra o bilgisayar saldırıyı başlatırsa?BT Güvenliğinin İlk Kuralı: Kimseye Güvenme
"Kale duvarlarımızı savunmaya çalıştık, ancak saldırı salonların içinden geldi" - İçerideki gaz sızıntısını düzeltmezseniz bir güvenlik duvarı hızla anlamsız hale gelir
"Son zamanlarda, bir üçüncü taraf Apache kitaplığının güvenlik açığı (görünüşe göre, bir uzaktan kod yürütme) yayınlandı."Buradaki herhangi bir kavramsal tartışmanın ardından, bir Apache sunucusuna yama uygulamak inanılmaz derecede basit ve günümüzde kullanımı kolaydır, isteğe bağlı olarak görülebilecek bir şey bile * düşünülmemelidir *.Bir yamayla bir sistemi kırma konusunda paranoyak iseniz, bu daha çok kötü sistem uygulamasına işaret eder, çünkü Apache'yi bir paket yükleyici aracılığıyla yamalamak acı verici derecede basittir.
Sekiz yanıtlar:
iainpb
2017-11-20 14:45:00 UTC
view on stackexchange narkive permalink

İfadeniz iki hatalı varsayımda bulunuyor:

  1. Güvenlik duvarlarınız tamamen doğru şekilde yapılandırılmış ve bir saldırganın güvenliğini tehlikeye atmasına olanak tanıyan hiçbir güvenlik açığına sahip değil ve bu mükemmel durum devam edecektir.

  2. Kuruluşunuzdaki herkes güvenilirdir ve hiçbir risk taşımaz.

Her zaman derinlemesine bir savunma yaklaşımı ile hareket etmeli ve elinizden geldiğince her katmanı güvence altına almalısınız. Bir saldırgan bir çevreye girerse veya kötü niyetli bir aktörünüz varsa, bu Apache güvenlik açığından yama yapılmazsa yararlanılabilir.

İyi bilinen veri ihlallerinin ayrıntılarına bakarsanız, genellikle ilk düşen şeyin ağdaki bazı üçüncü taraf aygıtlar olduğunu ve daha sonra daha fazla saldırı düzenlemek için bir sahil başı olarak kullanıldığını göreceksiniz.Bu, organizasyondaki herkese güvenme meselesi bile değildi, organizasyonun sahip olmadığı veya işletmediği ekipmanın yine de organizasyon şemasında görünmeden organizasyona "girmesine" izin verildiğini takdir edememekti.Bu yüzden bunun "3)" olarak mı yoksa "2)" üzerinde daha fazla detaylandırma mı olduğunu bilmiyorum.
Ve 3) bir saldırganın güvenlik duvarınızı atlamasının bir yolu yoktur.(Ahududu Pi'yi dahili bir ağ bağlantı noktasına takmak gibi)
Yapmamaları gereken bağlantılara tıklayan kullanıcılar.E-posta eklerini açan kullanıcılar yapmamaları gerekir.
Madde 2 gerçekten parçalanmalı."Güvenilir mi" ve "risk sunmuyor" başlı başına iki büyük kategoridir.İkincisi muhtemelen daha önemlidir ve kutularında kötü amaçlı yazılım bulaşması gibi şeyler içerir.
2) HERKES'e ek olarak ... ekleyeceğim 3) İçindeki HER ŞEY güvenli ve değiştirilmemiş.Verileri ağların içine ve dışına aktaran tüm IoT şeyleriyle, etkilenmesi için dışarıdan erişilebilen veya dışarıdan erişilebilen yalnızca bir öğenin içeride olması gerekir.
gowenfawr
2017-11-20 19:52:32 UTC
view on stackexchange narkive permalink

Bu çok eski bir sorudur ve her zaman aynı cevaba sahiptir.

Chewy Center

Saldırganlarınızın bunu yapamayacağına güvenemezsiniz. ağınıza erişin. Tek yapmanız gereken, bir kimlik avı e-postasına tek bir çalışan tıklamaktır ve saldırganın ağınızda bir eli vardır. Her şeyi yamalanmadan bırakırsanız, bir tarla günü geçirecekler.

resim burada nasıl alakalı?
Resim, kendisini dışarıdan korumak için bir şeyler inşa eden birini temsil ediyor, ancak onu her tehditten korumak için tasarlanmamış veya beklenmemiş.Bu durumda, biri kendini doğa koşullarından korumak için bir yapı inşa etti, ancak vahşi yaşamdan değil.Ayrıca gülümseyen kutup ayıları var.Kutup ayılarını gülümsemeyi kim sevmez?
Ya da daha doğrusu, birileri, yaban hayatının söz konusu yapıyı lezzetli bulduğunu ve doğrudan içinden yiyebileceğini / yiyeceğini fark etmeden, kendilerini vahşi yaşamdan korumak için bir yapı inşa etti.Yapının içinde daha fazla savunma olmadan, hemen ıslatılırsınız.
Bunun en basit ve en güçlü yanıt olduğunu düşünüyorum: "Tek gereken, bir phishing e-postasına tıklayan bir çalışanın."
ymbirtt
2017-11-20 20:26:03 UTC
view on stackexchange narkive permalink

Tehdit raporları, rutin olarak, kendi meslektaşlarınızdan, yabancılardan olduğundan çok daha fazla risk altında olduğunuzu tespit eder. Örneğin, bu 2015 raporundan aşağıdaki rakamlara sahibiz:

İhlallerin% 74'ü genişletilmiş kuruluştan kaynaklanıyor - çalışanlar arasında (% 40), üçüncü partiler (% 22) veya eski çalışanlar (% 12) -% 26'sı kuruluş dışından geliyor

...

İç güvenlik ihlallerinin üçte ikisi (% 67) kaynaklanıyor kasıtsız hatadan - üçte biri (% 33) kötü niyetten kaynaklanıyor

Dolayısıyla,% 74'ün% 33'ü bize tüm ihlallerin yaklaşık dörtte birini kendi meslektaşlarınızdan birinin karar vermesinden kaynaklanıyor sizi sevmiyorlar.

Bu belirli güvenlik açığının kötü niyetli ve teknik olarak yetenekli bir içeriden tehdit tarafından kullanılması gerekir. Bir yandan, buradaki "teknik olarak yetenekli" niteleyici, saldırı olasılığınızı önemli ölçüde azaltır. Öte yandan, "bu güvenlik açığı bizi yalnızca içerideki kişilere karşı savunmasız bırakıyor", yama yapmamak için tamamen yetersiz bir neden.

Teknik olarak yetenekli, ne olursa olsun, yalnızca gerçek istismarları kapsar.Finans adamımı çok sinirlendirebilirim ve bilgilerimi bazı Rus suç örgütlerine sızdırmalarını sağlayabilirim.Bu, bunların "gerçek" ihlaller olduğu anlamına gelmez, sadece teknik beceri gerekli değildir.Bu aynı zamanda, sağlamlaştırmanın yalnızca yama uygulamaktan ve güçlü parolalar kullanmaktan daha fazlası olması gerektiği anlamına gelir.
-1
Evet, yukarıdaki yorumumda kapsamın dışına çıktım.
tim
2017-11-20 19:13:13 UTC
view on stackexchange narkive permalink

Evet, dahili sistemlere yama uygulamanız gerekiyor.

Aşağıdakilerin doğru olduğunu varsayalım (muhtemelen doğru değildir):

  • dahili sisteminiz 100 Dış dünyadan% 100 anlaşılmaz (veya bir ihlal durumunda her dahili sistemin ele geçirilmesinde sorun yok).
  • Kuruluşunuzdaki herkese (veya daha doğrusu intranete erişimi olan herhangi birine% 100 güveniyorsunuz) , ziyaretçiler, geçici çalışanlar vb. dahil olabilir).

İntranete erişim gerektirmeyen, özellikle de XSS ve CSRF'den yansıyan web tabanlı güvenlik açıkları hâlâ mevcuttur.

Web uygulamalarında güncelleme yapmama yaklaşımını web sunucularında kullandığınız gibi kullanırsanız, bazı uygulamaların savunmasız olacağını varsaymak doğru olur. Artık, hangi yazılımı kullandığınızı bilen veya tahmin eden bir saldırgan, kuruluşunuzdaki herhangi biri bağlantıları tıklarken veya web sitelerini ziyaret ederken dikkatli olmazsa XSS veya CSRF aracılığıyla kod yürütme sağlayabilir.

rackandboneman
2017-11-22 04:53:21 UTC
view on stackexchange narkive permalink

Mecazi olarak açıklamak gerekirse:

Yönlü paket filtresinin / NAT maskeli ağ geçidinin genel anlamıyla bir güvenlik duvarı, dünyanın geri kalanının "insan" zehrinizi zorla beslemesini önleyecektir.

Aynı zamanda, birileri hala zehirleme ihtimaline karşı, delirirlerse ve şiddete başvururlarsa, dünyanın geri kalanına çok fazla zarar vermelerini engeller.

Onları çok katı bir diyet uygulamazsanız , halkınızın, ister açık bir şekilde onları zehirlemek amacıyla ister sadece hedeflenmemiş sadizm nedeniyle, birisinin zehirlediği yiyeceklere ulaşıp onları yemekten, teröre neden olmaktan alıkoymaz ...

Bir daha Gelişmiş güvenlik duvarı (Derin paket denetimi, kara liste / beyaz liste vb.) yiyecekleri denetleyecek, ancak yine de güvenilmez olacaktır. Kumaş yumuşatıcının gatorade olduğunu veya kokan peynirin herkesi gazdan arındırma girişimi olduğunu veya tuzun yeşil ışıkla aydınlatılması bir şişe doymuş salamurayı tüketmenin güvenli olacağı anlamına geldiğini düşündüğünde de sorun yaratabilir.

unknownprotocol
2017-11-22 06:32:27 UTC
view on stackexchange narkive permalink

Yalnızca İntranet'e yönelik güvenli olmayan hizmetler ve uygulamalar genellikle ihlallerin son hedefidir . Ne yazık ki, sistem / ağ yöneticilerine gereğinden fazla güvenmeyen (ve saf diyebilirim ki) onların güvenliğini sağlamayı ihmal etmekten çok daha sık.

Ya normalde güvenilen bir intranet kullanıcının makinesi bir virüs, truva atı veya botnet kötü amaçlı yazılımıyla sözleşme yapıyor veya sizde intranetinizi içeriden tarayan ve bu bilgiyi güvenilmeyen bir tarafa gönderen ne var? Artık güvenilmeyen taraf sadece intranetinizde bir vektöre sahip olmakla kalmıyor, aynı zamanda düzeni ve güvenli olmayan hizmetlerine nasıl erişeceğini de biliyor.

Öngörülemeyen pek çok güvenlik açığını ortadan kaldırmak için kişinin birden fazla güvenlik katmanına sahip olması gerekir, yalnızca bir tane değil.

mootmoot
2017-11-20 14:56:36 UTC
view on stackexchange narkive permalink

Yazılım güvenlik açıkları, tam olarak test edilmedikçe, belirli bir ölçümle giderilmesi zor olan bir sorundur. Bu nedenle, güvenlik duvarı kullanan azaltma yönteminden çok emin olmadıkça hiçbir tedarikçi size bu tür bir soruyu yanıtlayamaz.

Aslında, yamanın mevcut uygulamanızı ve sürecinizi bozup bozmayacağını, geri alınıp alınamayacağını sormalısınız. .

dan
2017-11-29 19:35:10 UTC
view on stackexchange narkive permalink

Bir güvenlik duvarını güncel tutmak ve güncel yazılımları korumak için 2 bağımsız savunma hattı vardır

Kısacası, sorunuzun yanıtı evet veya hayır olamaz, ikisi de yanlış.

Ve işte bunun nedenleriyle ilgili bazı açıklamalar:

  • "Mükemmel" bir güvenlik duvarı (bu model mevcut değil) ve hatta tamamen izole bir intranet (yani İnternet bağlantısı), sistemlerinizi bu yüksek düzeyde korunan kirlenmiş bilgisayar veya saldırı bilgisayarı içindeki bağlantıya karşı korumaz. (Bu gerçek hayattan bir geri bildirim: ~ yıl içinde / içinden böyle bir saldırı). Ayrıca bkz. Stuxnet (2010, Kaspersky Lab tarafından analiz edildi.).

    Kısacası, "mükemmel" bir güvenlik duvarı bile sizi içeriden gelen büyük risklere karşı koruyamaz.

  • Kötü olaylar yelpazesinin diğer ucunda, bir işletim sisteminin veya bir yazılımın yükseltilmesi, güvenliği iyileştirmenin garantisi değildir. Yazılım yükseltmelerinin çoğu, kod satırlarının sayısındaki artışlardır ve olasılık kanunu, bize, hataların sayısının orantılı olarak arttığını söyler. Bir işletim sistemi yükseltmesi, Apache içindeki 80 / tcp (http) bağlantı noktasında önceki sürümde bulunmayan bir güvenlik açığı açabilir ve birçok güvenlik duvarı yapılandırmasında olduğu gibi, bu protokole yasal olarak izin verilebilir. ağınıza girmek için. O zaman işletim sistemi yükseltmeniz tüm ağınızda ciddi bir güvenlik açığına neden olabilir. MacOS High Sierra'ya (2017, Lemi Orhan Ergin tarafından analiz edilmiştir) yükseltme yaparak uzaktan kök erişim güvenlik açığına da bakın.

    Kısacası, "her zaman güncelleme" gibi "mükemmel" bir uygulama bile sizi, güvenlik duvarınızın açık bir bağlantı noktasının önünde bulunan düzenleyicilerden kaynaklanan büyük hata riskine karşı koruyamaz.

Bu 2 yaklaşımın hiçbirinin yeterli olmadığını gösteren birçok başka senaryo var: "mükemmel" güvenlik duvarı, "mükemmel" yükseltme uygulaması.

Peki ne yapmalıyım?

Kişisel tavsiyem, güvenlik duvarlarını ve yazılımları, hiçbirinin ortaya çıkmadığını minimum düzeyde kontrol ettikten sonra bağımsız olarak güncel tutmayı diğerinin savunmaya hazır olmadığı bir güvenlik açığı.



Bu Soru-Cevap, otomatik olarak İngilizce dilinden çevrilmiştir.Orijinal içerik, dağıtıldığı cc by-sa 3.0 lisansı için teşekkür ettiğimiz stackexchange'ta mevcuttur.
Loading...