Bilgisayar korsanlığı önleme, adli tıp, denetim ve karşı önlemler


11

Son zamanlarda (ama aynı zamanda tekrarlayan bir soru) hack ve güvenlik hakkında 3 ilginç konu gördük:

Güvenliği ihlal edilmiş bir sunucuyla nasıl başa çıkabilirim? .
Saldırıya uğramış bir sunucunun nasıl saldırıya uğradığını bulma
Dosya izinleri sorusu

Sonuncusu doğrudan ilgili değildir, ancak bir web sunucusu yönetimiyle uğraşmanın ne kadar kolay olduğunu vurgular.

Yapılabilecek birkaç şey olduğundan, kötü bir şey olmadan önce , bir saldırının arka etkilerini sınırlamak için iyi uygulamalar ve hüzünlü davada nasıl tepki verileceği konusunda önerilerinizi almak istiyorum.

Bu sadece sunucuyu ve kodu güvence altına almak değil, aynı zamanda denetim, günlük kaydı ve karşı önlemleri almakla da ilgilidir.

İyi uygulama listeniz var mı veya web sunucularınızı sürekli analiz eden yazılımlara mı yoksa uzmanlara mı güvenmeyi tercih ediyorsunuz?

Evetse, listenizi ve fikirlerinizi / görüşlerinizi paylaşabilir misiniz?

GÜNCELLEME

Birkaç iyi ve ilginç geri bildirim aldım.

Basit bir listeye sahip olmak istiyorum, böylece BT Güvenliği yöneticileri için değil, aynı zamanda web factotum master'ları için de kullanışlı olabilir .

Herkes iyi ve doğru cevaplar vermiş olsa bile, şu anda en basit, net ve özlü olan Robert'ı ve en eksiksiz ve kesin olan sysadmin1138'i tercih ediyorum .

Ama hiç kimse kullanıcı bakış açısını ve algısını düşünmez, ilk düşünülmesi gereken şey olduğunu düşünüyorum.

Saldırıya uğrayan sitemi ne zaman ziyaret edeceğini düşünecek olan kullanıcı, onlar hakkında makul verileriniz varsa çok daha fazlası Bu sadece verilerin nerede stoklanacağı değil, öfkeli kullanıcıların nasıl sakinleştirileceği meselesidir.

Veriler, medya, yetkililer ve rakipler ne olacak?


3
Security.stackexchange.com ile başlayın . Burada zaten bazı iyi cevaplar olmasına rağmen ....
AviD

İyi bir nokta! Bir tane olduğunu bilmiyordum, tam listenin her yığın web sitesinin altbilgisinde olduğunu düşündüm.
tmow

Bence beta siteleri tam teşekküllü sitelerde görünmüyor. Ve tam teşekküllü siteler de beta altbilgileri üzerinde
bulunmuyor

Yanıtlar:


11

Odaklanacak iki büyük alan var:

  1. İçeri girmek zor.
  2. Birisinin geçmiş noktaya girme olayını sakin ve verimli bir şekilde ele almak için politikalar ve prosedürler oluşturmak

İçeri girmek zor

Bu çok karmaşık bir konudur ve birçoğu, WTF'den sonra gerçekleştiğini anlamak için yeterli bilgiye sahip olduğunuzdan emin olmaya odaklanmaktadır. Soyut madde işareti basitliği işaret eder:

  • Günlükleri tutma (ayrıca bkz. Güvenlik Bilgileri Olay Yönetimi)
    • Başarılı ve başarısız olan her türlü yetkilendirme girişimi, tercihen kaynak bilgileri bozulmamış olarak yapılır.
    • Güvenlik duvarı erişim günlükleri (kullanılıyorsa, sunucu başına güvenlik duvarlarını içermesi gerekebilir).
    • Web sunucusu erişim günlükleri
    • Veritabanı sunucusu kimlik doğrulama günlükleri
    • Uygulamaya özel kullanım günlükleri
    • Mümkünse, SIEM şüpheli kalıplara uyarı verebilir.
  • Uygun erişim denetimlerini zorunlu kılın
    • Hakların her yerde doğru bir şekilde ayarlandığından emin olun ve mümkün olduğunda 'tembel haklardan' ("oh sadece herkese okuyun") kaçının.
    • Prosedürlerin gerçekten takip edildiğinden emin olmak için ACL'lerin periyodik denetimleri ve sorun giderme işlemleri tamamlandıktan sonra geçici sorun giderme adımları ("herkese okumasını sağlayın, çalışıp çalışmadığını görün") doğru şekilde kaldırıldı.
    • Tüm güvenlik duvarı geçiş kurallarının gerekçelendirilmesi ve periyodik olarak denetlenmesi gerekir.
    • Hem web sunucusu hem de dosya sistemi EKL'leri olan web sunucusu erişim denetimlerinin de denetlenmesi gerekir.
  • Değişim yönetimini zorunlu kılın
    • Güvenlik ortamında yapılacak herhangi bir değişikliğin birden fazla kişi tarafından merkezi olarak izlenmesi ve gözden geçirilmesi gerekir.
    • Yamalar bu sürece dahil edilmelidir.
    • Ortak bir işletim sistemi yapısına (şablon) sahip olmak, ortamı basitleştirecek ve değişiklikleri izlemeyi ve uygulamayı kolaylaştıracaktır.
  • Konuk hesaplarını devre dışı bırakın.
  • Tüm şifrelerin varsayılanlara ayarlanmadığından emin olun.
    • Hazır uygulamalar, kullanıcıları önceden tanımlı parolalarla ayarlayabilir. Onları değiştir.
    • BT cihazlarının birçoğu çok iyi bilinen kullanıcı / şifre çiftleriyle birlikte gönderilir. Yılda sadece bir kez giriş yapsanız bile bunları değiştirin.
  • En az ayrıcalık uygulayın. Kullanıcılara gerçekten ihtiyaç duydukları erişimi verin.
    • Yönetici kullanıcılar için iki hesaplı bir kurulum akıllıca olur. E-posta ve diğer ofis görevleri için kullanılan normal hesaplardan biri ve özel çalışmaların yükseltilmesi için ikinci hesap. VM'ler bunu yaşamayı kolaylaştırır.
    • Genel yönetici / kök hesaplarının düzenli kullanımını teşvik ETMEYİN, kimin ne zaman ne yaptığını izlemek zordur.

Birinin içeri girme olayını sakin ve verimli bir şekilde ele almak için politikalar ve prosedürler oluşturmak

Bir güvenlik olayı politikası tüm kuruluşlar için zorunludur. İnsanlar, bu gibi olaylarla karşılaştıklarında mantıksız olma eğiliminde olduklarından, "kafalarımız kesilmiş halde koşmak" yanıt aşamasını büyük ölçüde azaltır. Saldırılar büyük, korkutucu işler. Bir saldırıya maruz kaldığında utanç aksi halde düz başlı sistem yöneticilerinin yanlış tepki vermeye başlamasına neden olabilir.

Kuruluşun tüm düzeylerinin politikaların farkında olması gerekir. Olay ne kadar büyük olursa, üst yönetimin bir şekilde katılımı o kadar olasıdır ve bir şeyleri ele almak için belirlenmiş prosedürlere sahip olmak, "yardım" ı yüksek seviyeden atmaya büyük ölçüde yardımcı olacaktır. Ayrıca, olay yönetimine doğrudan katılan teknisyenler için, orta yönetimin kuruluşun geri kalanıyla arayüz oluşturma prosedürleri şeklinde bir kapsam sunar.

İdeal olarak, Afet Kurtarma politikası zaten belli hizmetlerinde DR politikası tekmeler önce kullanım dışı olabilir ne kadar tanımlamıştır. Olayların bu tür gibi bu olay tepkisini yardımcı olacaktır vardır afetler. Olay, kurtarma penceresinin karşılanmayacağı bir türdeyse (örnek: etkin yedek DR sitesi, değiştirilen verilerin gerçek zamanlı beslemesini alır ve davetsiz misafirler DR sitesine çoğaltılmadan önce bir grup veri siler Bu nedenle, soğuk kurtarma prosedürlerinin kullanılması gerekecektir), o zaman üst yönetimin risk değerlendirme görüşmelerine dahil edilmesi gerekecektir.

Herhangi bir olay müdahale planının bazı bileşenleri:

  • Güvenliği ihlal edilmiş sistemleri ve açıkta kalan verileri belirleyin.
  • Nihai kovuşturma için yasal delillerin saklanmasının gerekip gerekmediğine erken karar verin.
    • Eğer kanıtlar saklanacaksa , kesinlikle gerekli olmadıkça bu sistemle ilgili hiçbir şeye dokunmayın . Oturum açmayın. Günlük dosyaları arasında gezinmeyin. Yapmak. Değil. Dokunma.
    • Delil muhafaza edilecekse, güvenli olmayan sistemler bırakılmaması gerekir çevrimiçi ama kopuk sertifikalı bilgisayar adli tıp uzmanı kanıt taşıma kuralları ile uyumlu bir şekilde sisteme teşrih gibi bu zamana kadar.
      • Güvenliği ihlal edilmiş bir sistemin kapatılması verileri bozabilir.
      • Depolama sisteminiz buna izin veriyorsa (ayrık SAN cihazı), bağlantıyı kesmeden önce etkilenen LUN'ların anlık görüntüsünü alın ve salt okunur olarak işaretleyin.
    • Kanıt işleme kuralları karmaşıktır ve çok kolay vidalanır. Onlarla ilgili eğitim almadıkça yapmayın. Çoğu genel SysAdmins'in bu tür bir eğitimi YOKTUR.
    • Kanıtlar saklanıyorsa, hizmet kaybını bir donanım kaybı felaketi olarak kabul edin ve yeni donanımlarla kurtarma işlemlerine başlayın.
  • Ne tür afetler için önceden belirlenmiş kurallar, ne tür bildirimler gerektirir. Yasalar ve düzenlemeler bölgeye göre değişir.
    • 'Maruz kalma' ve 'kanıtlanmış uzlaşma' ile ilgili kurallar değişiklik gösterir.
    • Bildirim kuralları İletişim departmanının katılmasını gerektirecektir.
    • Gerekli bildirim yeterince büyükse, üst düzey yönetimin dahil edilmesi gerekecektir.
  • DR verilerini kullanarak, hizmeti tekrar çevrimiçi duruma getirmeden önce ne kadar "WTF oldu" zamanının harcanabileceğini belirleyin.
    • Hizmet kurtarma süreleri, tabi olanların ne olduğunu anlama işini gerektirebilir. Eğer öyleyse, hizmetler geri yüklendikten sonra diseksiyon için etkilenen cihazın bir sürücü görüntüsünü alın (bu bir delil kopyası değildir, tekniklerin mühendisleri tersine çevirmesi içindir).
    • Hizmet kurtarma görevlerinizi yalnızca karışıklığı temizlemekle kalmayıp, etkilenen sistemin tamamen yeniden oluşturulmasını içerecek şekilde planlayın.
    • Bazı durumlarda servis kurtarma süreleri, bir uzlaşma oluştuktan ve yasal kanıtların saklanmayacağını belirledikten hemen sonra disk görüntülerinin alınması gerektiği kadar sıkıdır. Hizmet yeniden kurulduktan sonra, ne olduğunu bulma işi başlayabilir.
  • Saldırganın nasıl içeri girdiğine ve bir kez içeri girdiklerine ilişkin bilgiler için günlük dosyalarını gözden geçirin.
  • İçeri nasıl girdiklerine ve girdikten sonra ne yaptıklarına ilişkin bilgi için değiştirilmiş dosyaları gözden geçirin.
  • Nereden geldikleri, nereye veri gönderdikleri ve ne kadarının gönderildiği hakkında bilgi için güvenlik duvarı günlüklerini gözden geçirin.

Bir uzlaşma öncesinde politikalar ve prosedürler uygulamak ve bir uzlaşma durumunda bunları uygulayacak insanlar tarafından iyi bilinmek, yapılması gereken bir şeydir. İnsanların düz düşünmeyeceği bir zamanda herkese bir yanıt çerçevesi sağlar. Üst yönetim, davalar ve cezai suçlamalar hakkında şimşek çakabilir, ancak aslında bir vakayı bir araya getirmek pahalı bir süreçtir ve önceden öfkeyi hafifletmeye yardımcı olabileceğini bilmek.

Ayrıca bu tür olayların genel Afet Müdahale planına dahil edilmesi gerektiğini de not ediyorum. Bir uzlaşma, 'kayıp donanım' yanıt politikasını tetikleyecek ve ayrıca 'veri kaybı' yanıtını tetikleyecektir. Hizmet kurtarma sürelerinizin bilinmesi, güvenlik yanıt ekibinin hizmet kurtarma işlemine gerek duyulmadan önce gerçek güvenliği ihlal edilmiş sistemden (yasal kanıt tutmuyorsa) ne kadar süre kalması gerektiğine ilişkin beklentinin belirlenmesine yardımcı olur.


Cevabınızı seçtim, çünkü en eksiksiz olanı ve çalıştığımız şirketler gibi, kullandıkları ve sürekli geliştirdikleri, ancak en kısa sürede bir çözüm bulmak zorunda olan normal web yöneticileri için nasıl basitleştirilebileceğini merak ediyorum, çok fazla para olmadan çok daha fazlası.
tmow

Sizin ve Robert'in cevabı arasında hala emin değilim.
tmow

Bu harika bir cevap, sadece +1 yerine +2 yapabilseydim
Rob Moir

7

Uygun yardım masası prosedürleri nasıl yardımcı olabilir?

Müşterilerin burada nasıl ele alındığını düşünmemiz gerekir (bu, bir yardım masasıyla iletişim kuran hem dahili hem de harici müşteriler için geçerlidir).

Her şeyden önce iletişim önemlidir ; kullanıcılar iş dünyasındaki aksaklıklardan öfkeli olacaklar ve bir izinsiz girişin parçası olarak meydana gelebilecek bilgi ihlallerinin kapsamı / sonuçları hakkında da endişe duyabilirler. Bu insanları bilgilendirmek, hem bilginin paylaşılmasının iyi olduğu hem de belki de daha az belirgin olan bir bakış açısıyla, duymaları gereken bir şeyin, durum.

Yardım masası ve BT yönetiminin bu noktada bir "şemsiye" gibi davranması, izinsiz girişin kapsamını belirlemek ve işi bu işi kesintiye uğratan sayısız sorgudan geri yüklemek için işi yapan insanları barındırması gerekir.

  1. Müşterilere gerçekçi güncellemeler sunmaya çalışın ve bir hizmeti tekrar çevrimiçi hale getirme aciliyetini belirlemek için onlarla birlikte çalışın. Müşteri ihtiyaçlarının farkında olmak önemlidir, ancak aynı zamanda size uygulanamayan bir program dikte etmelerine izin vermeyin.
  2. Yardım masası ekibinizin hangi bilgilerin yayınlanabileceğini ve yayınlanamayacağını bildiklerinden ve söylentileri ve spekülasyonları teşvik etmemeleri gerektiğinden emin olun (ve kesinlikle kuruluşunuzun yapabileceği veya karşılaşabileceği herhangi bir yasal işlemi öngörebilecek herhangi bir şeyi tartışmamalıdır).
  3. Yardım masasının müdahaleye ilişkin tüm çağrıları kaydetmesi olumlu bir şeydir - bu, hem izinsiz girişin kendisinin hem de onunla başa çıkmak için takip edilen süreçlerin neden olduğu aksaklığı ölçmeye yardımcı olabilir. Saldırı ve hafifletme için hem zaman hem de finansal maliyet koymak hem gelecekteki stratejilerin iyileştirilmesinde çok yardımcı olabilir hem de herhangi bir yasal işlemde faydalı olduğu açıktır. ITIL olayı ve sorun kaydının karşılaştırılması burada yardımcı olabilir - hem izinsiz girişin kendisi hem de hafifletme ayrı sorunlar olarak kaydedilebilir ve her arayan bir veya iki sorunun bir olayı olarak izlenebilir.

Dağıtım standartları nasıl yardımcı olabilir?

Ayarlanmış bir şablona (veya en azından bir kontrol listesine) dağıtmak, dağıtım şablonunuzdaki tüm özelleştirmeler / yükseltmeler üzerinde değişiklik kontrolü / yönetimi uygulamakla da yardımcı olur. Farklı işler yapan sunucuları (örneğin bir posta sunucusu şablonu, bir web sunucusu şablonu vb.) Hesaba katmak için birkaç şablonunuz olabilir.

Bir şablon hem işletim sistemi hem de uygulamalar için çalışmalı ve yalnızca güvenlik değil , kullandığınız tüm ayarları içermeli ve insan hatasını olabildiğince ortadan kaldırmak için el ile uygulanmadan (örneğin bir kontrol listesi) ideal olarak komut dosyasına yazılmalıdır (örn. Bir kontrol listesi).

Bu, çeşitli şekillerde yardımcı olur:

  • Bir izinsiz giriş gerçekleşmesi durumunda daha hızlı geri yüklemenizi / yeniden oluşturmanızı sağlar ( bu şablondan 'olduğu gibi' dağıtmamanız gerektiğini unutmayın, çünkü savunmasız olduğunu bilirsiniz , ancak bilinen son iyi yapılandırmanıza geri dönmenizi sağlar " Canlı dağıtımdan önce daha fazla sertleştirilmesi gerekiyor ... ve düzgün bir şekilde kilitlendiğinden emin olduktan sonra dağıtım şablonunuzu güncellemeyi de unutmayın)
  • Saldırıya uğramış bir sunucuyu karşılaştırmak için size bir "temel" verir
  • İlk etapta izinsiz girişlere neden olabilecek gereksiz hataları azaltır
  • Değişiklik ve yama yönetimine yardımcı olur, çünkü güvenlik için bir yama / yükseltme veya prosedürel değişikliğe ihtiyacınız olduğu anlaşıldığında (veya bu konuda başka nedenlerle), hangi sistemlerin değişikliğe ihtiyaç duyduğunu görmeyi kolaylaştırır, test yazmayı kolaylaştırır değişikliğin doğru uygulanıp uygulanmadığını görmek için).
  • Her şey mümkün olduğunca tutarlı ve mantıklıysa, olağandışı ve şüpheli olayların biraz daha öne çıkmasına yardımcı olur.

1
+1. Evet, doğru, ancak her şey olursa, şablonunuzun düşündüğünüz kadar güvenli olmadığı anlamına gelir, bu nedenle yeni bir web sitesi dağıtmak için kullanamazsınız. Müşterilere geçici bir sorun hakkında bilgi veren ve başka bir yerde (başka bir sunucu, başka bir IP ve eskiden yeniden yönlendirme) barındırmak için daha iyi bir bakım sayfasına ihtiyacınız var. Bence her zaman en kötü durumu dikkate almalıyız.
tmow

2
@tmow - haklısınız ancak şablon, bir sistemi "bilinen" yapılandırmanıza hızlı bir şekilde geri yüklemenizi sağlar; bu da sunucuyu yeniden dağıtmadan önce değiştirmeniz gerekir. Cevabı, bunu belirtmiş olmalıydı, çünkü kesinlikle oradasınız.
Rob Moir

1
Teşekkürler. Kullanıcı bakış açısını ve algısını unutmayın.
tmow

@tmow, kullanıcılar hakkında biraz ekledi ve destek masasını işlerin sonuna kadar yardımcı olmaya koydu.
Rob Moir

4

Sunucularımızın çoğunda, önleme işlemimizin çoğunda ana bilgisayar ve ağ güvenlik duvarlarına, virüsten korunma / casus yazılım yazılımlarına, ağ IDS'lerine ve ana bilgisayar IDS'lerine güveniyoruz. Bu, minimum privs, kaldırılan temel olmayan programlar, güncellemeler, vb. Gibi tüm genel yönergelerle birlikte, oradan Nagios, Cacti ve SIEM çözümü gibi ürünleri çeşitli taban astarları ve olayların ne zaman meydana geldiğine dair bildirimler için kullanıyoruz. Bizim HIDS (OSSEC) SIEM tipi günlük kaydı da yapıyor ki bu da güzel. Temel olarak mümkün olduğunca blok şeyler yapmaya çalışıyoruz, ancak daha sonra merkezi olarak oturum açıyoruz, böylece bir şey olursa onu analiz edebilir ve ilişkilendirebiliriz.


Her şey yolunda, bence daha fazla bir şeye ihtiyaç yok, ama yine, ne zaman olur, çünkü olur, tam olarak ne yaparsın, hızlı tepki vermek için ne gerekiyor? Çok daha stresli bir durumda, binlerce satırlık satırı analiz etmek, en azından kullanıcıları bilgilendirmek için hızlı bir geçici çözüm veya geçici bir çözüm sağlamayacaktır.
tmow

Bir şey meydana geldiğinde, o zaman yerinde prosedürlere ve eğitilmiş ve ne yapılacağını bilen bir olay müdahale ekibine ihtiyacınız vardır. Binlerce günlük satırı analiz etmenin göz korkutucu bir görev olduğunu biliyorum, ancak eğitim ve doğru araçlarla bunu biraz daraltabileceksiniz. Sonunda hala emecek, ancak tek çözüm olabilir. Ayrıca, yönetimi ve olay duyurularını nasıl kontrol edeceğinizi iyi anladığınızdan emin olmanız gerekir. Ayrıca, iyi yedekleme yordamları, sistem tamamen kurtarılamazsa ne kadar süre çalışmamanız gerektiğini en aza indirebilir.

Günde milyarlarca satırlık satır öğütmek için alışkınım ve bildiğim şey, halkanın ne olduğunu anlamadan önce, düzeltmek veya geçici bir çözüm bulmak için çok daha önemlidir, bu sadece statik bir sayfayla bile geçici bir sunucu olabilir kullanıcılara açıklıyor blah, blah, ..., blah ve özür diler. Bu ilk adımdır, o zaman hizmeti (veya bir kısmını) ne ve ne zaman yeniden kurabileceğinizi düşünürsünüz ve son olarak herhangi bir önlemi araştırır ve yerine koyarsınız.
tmow

4

Gerçekten istediğiniz 3 temel alana düşebilir:

  1. Standart Sistem Yapılandırması
  2. Sistem / Uygulama İzleme
  3. Olay Müdahalesi

Herhangi bir bilgi (güvence | güvenlik) personeliniz varsa, kesinlikle onlarla konuşmalısınız. Olay Müdahalesi genellikle söz konusu görevin tek amacı olsa da, geri kalanı etkilenen tüm taraflar için ortak bir geliştirme çabası olmalıdır.

Kendi kendine pezpleme riski altında, ilgili bir sorunun bu cevabı sizin için birçok yararlı kaynağı dizine eklemelidir: Bir LAMP Sunucusunun Güvenliğini Sağlama İpuçları.

İdeal olarak, en az desteklenen işletim sistemine sahip olmanız ve her birini bir temel görüntü kullanarak oluşturmanız gerekir. Sunucunun sağladığı hizmetleri sağlamak için tabandan yalnızca gerektiği kadar sapmalısınız. Sapmalar belgelenmelidir veya PCI / HIPAA / vb. İle karşılaşmanız gerekiyorsa gerekli olabilir. veya diğer uyumluluklar. Dağıtım ve yapılandırma yönetim sistemlerinin kullanılması bu konuda çok yardımcı olabilir. Özellikler işletim sisteminize, ayakkabıcıya / kukla / Altiris / DeployStudio / SCCM vb.

Kesinlikle bir tür düzenli günlük incelemesi yapmalısınız. Seçenek göz önüne alındığında, bir SIEM çok yararlı olabilir, ancak hem satın alma fiyatı hem de birikme maliyetlerinde pahalı olmanın dezavantajı vardır. Günlük analizi ile ilgili bazı yorumlar için IT Security SE sitesinden bu soruya göz atın: Günlük analizini nasıl ele alırsınız? Bu hala çok ağırsa, LogWatch gibi yaygın araçlar bile olup bitenler için iyi bir bağlam sağlayabilir. Ancak önemli olan, günlüklere bakmak için zaman ayırmaktır. Bu, normal davranışı neyin oluşturduğunu tanımanıza yardımcı olur, böylece anormalleri tanıyabilirsiniz.

Günlük incelemesine ek olarak, sunucunun durumunu izlemek de önemlidir. Planlı olsun ya da olmasın değişikliklerin ne zaman gerçekleştiğini bilmek çok önemlidir. Tripwire gibi yerel bir izleme aracı kullanmak yöneticiyi değişikliklere karşı uyarabilir. Ne yazık ki, SIEM'ler ve IDS'ler gibi, ayarlanması ve / veya satın alınması için pahalı olmanın dezavantajı vardır. Dahası, iyi ayar yapmadan, uyarı eşikleriniz o kadar yüksek olacak ki, iyi mesajlar gürültüde kaybolacak ve işe yaramayacaktır.


Hemen hemen her şeye katılıyorum, ancak bu çoğunlukla orta ve büyük şirketler için geçerlidir. Küçük ölçekli şirketler bu kadar pahalı bir yapıya ihtiyaç duymazlar veya istemezler.
tmow


2

Ben bir güvenlik uzmanı değilim, bu yüzden onlara erteliyorum; ancak En Az Ayrıcalık İlkesi ile başlamak neredeyse her zaman işlerini önemli ölçüde kolaylaştırır. Bunu iyileştirici bir salve gibi uygulamak, güvenliğin birçok yönü için iyi çalışır: dosya izinleri, çalışma zamanı kullanıcıları, güvenlik duvarı kuralları, vb. KISS hiçbir zaman acıtmaz.


2

Burada bahsedilen çözümlerin çoğu ana makine ve ağ düzeyinde uygulanabilir, ancak genellikle güvenli olmayan web uygulamalarını unutuyoruz. Web uygulamaları en sık görülen güvenlik açıklarıdır. Web uygulaması yoluyla bir saldırgan veritabanınıza veya ana makinenize erişebilir. Hiçbir güvenlik duvarı, IDS, güvenlik duvarı sizi bunlara karşı koruyamaz. OWASP, en kritik 10 güvenlik açığının bir listesini tutar ve bunlar için düzeltmeler sunar.

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide

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.