Kök Uyumluluktan Sonra Yeniden Yükle?

Bu soruyu bir sunucu uyuşmazlığı üzerinde okuduktan sonra , insanların neden algılama / temizleme araçları kullanarak veya yalnızca sistemi tehlikeye atmak için kullanılan deliği düzelterek, güvenli bir sistemi kurtarabileceklerine inanmaya devam ettiklerini düşünmeye başladım.

Tüm kök kiti teknolojileri ve bir bilgisayar korsanının yapabileceği diğer şeyler göz önüne alındığında, çoğu uzman işletim sistemini yeniden yüklemenizi önerir .

Neden daha fazla insanın neden sadece ayrılmadığını ve sistemi yörüngeden atmadıklarını daha iyi bir fikir edinmeyi umuyorum .

İşte ele almak istediğim birkaç nokta var.

• Bir formatın / yeniden kurulumun sistemi temizlemeyeceği koşullar var mı?
• Sence hangi tür koşullar altında bir sistemin temizlenebileceğini ve ne zaman tam bir yeniden yükleme yapmalısınız?
• Tam bir yeniden yüklemeye karşı hangi sebep var?
• Yeniden yüklememeyi seçerseniz, temizlediğinizden ve daha fazla zarar gelmesini önlediğinizden emin olmak için hangi yöntemi kullanırsınız?

Güvenlik kararı, sonuçta, hangi ürünün piyasaya sürüleceğine ilişkin bir karar olduğu gibi, riskle ilgili bir ticari karardır. Bu bağlamda çerçevelendiğinde, seviyelememe ve yeniden kurma kararı mantıklı geliyor. Bunu kesinlikle teknik bir perspektiften düşündüğünüzde, düşünmez.

Genelde bu iş kararına giren şey:

• Arıza süremiz ölçülebilir bir miktar bize ne kadara mal olacak?
• Müşterilerimize neden olduğumuzu biraz açıklamak zorunda kalmamızın maliyeti ne kadardır?
• Yeniden yüklemek için insanları başka hangi yerlerden uzaklaştırmam gerekiyor? Fiyatı nedir?
• Sistemi hatasız bir hale getirmeyi bilen doğru insanlara sahip miyiz? Olmazsa, hataları giderirken bana maliyeti ne olacak?

Bu nedenle, bunun gibi masrafları artırdığınızda, "potansiyel olarak tehlikede olan" bir sistemle devam etmenin sistemi yeniden kurmaktan daha iyi olduğu düşünülebilir.

Bir yazıya dayanarak çok eskiden önce hala blogda rahatsız olabileceğimi yazdım .

Bu soru sürekli olarak web sunucularına giren bilgisayar korsanlarının kurbanları tarafından sorulmaya devam ediyor. Cevaplar çok nadiren değişiyor, ancak insanlar soruyu sormaya devam ediyorlar. Neden olduğundan emin değilim. Belki de insanlar yardım ararken gördükleri yanıtlardan hoşlanmazlar ya da tavsiye verecekleri güvendikleri birini bulamazlar. Belki de insanlar bu sorunun cevabını okurlar ve çevrimiçi olarak bulabilecekleri cevapların neden özel ve farklı olduklarının% 5'ine çok fazla odaklanırlar ve sorularının% 95'ini özlüyorlar. Online okudukları gibi.

Bu beni ilk önemli bilgi topluluğuna getiriyor. Gerçekten özel bir kar tanesi olduğun için minnettarım. Web sitenizin, sizin ve işinizin bir yansıması olduğundan veya en azından bir işveren adına yaptığınız sıkı çalışmanızın bir yansıması olduğu için takdir ediyorum. Ancak dışarıdan bakan birisi için, soruna bakacak bir bilgisayar güvenlik görevlisinin, size yardım etmek ya da saldırganın kendisine yardım etmek isteyip istemediği sorusuna bağlı olarak, sorununuzun sahip oldukları diğer davalarla en az% 95 oranında aynı olması muhtemeldir. hiç baktı.

Saldırıyı kişisel olarak almayın ve burada izleyen ya da diğer insanlardan kişisel olarak aldığınız önerileri almayın. Sadece bir web sitesi hack kurbanı olduktan sonra bunu okuyorsanız, gerçekten üzgünüm ve burada gerçekten yararlı bir şeyler bulacağınızı umuyorum, ancak bu, egonuzun ihtiyaç duyduğunuz şekilde girmesine izin verme zamanı değil yap.

Sunucularınızın saldırıya uğradığını öğrendiniz. Şimdi ne olacak?

Panik yapma. Kesinlikle acele etmeyin ve kesinlikle hiçbir şey olmamış gibi davranmaya çalışmayın ve hiç hareket etmeyin.

İlk önce, felaketin çoktan gerçekleştiğini anlayın. Bu inkar zamanı değil; ne olduğunu kabul etme, bu konuda gerçekçi olma ve etkinin sonuçlarını yönetmek için adımlar atmanın zamanı geldi.

Bu adımlardan bazıları zarar görecek ve (web siteniz benim bilgilerimin bir kopyasını almadığı sürece) Bu adımların tümünü veya bir kısmını görmezden gelmeniz umrumda değil, ancak bunu yapmanız sonunda sonuçların daha iyi olmasını sağlayacaktır. İlaç çok kötü olabilir ama bazen tedavinin gerçekten çalışmasını istiyorsanız, bunu göz ardı etmek zorundasınız.

Sorunun zaten olduğundan daha kötüye gitmesini durdurun:

1. Yapmanız gereken ilk şey, etkilenen sistemlerin İnternet bağlantısını kesmektir. Diğer sorunlarınız ne olursa olsun, sistemi web'e bağlı bırakmak yalnızca saldırının devam etmesine izin verir. Ben kelimenin tam anlamıyla bu demek istiyorum; Birinin sunucuyu fiziksel olarak ziyaret etmesini ve eğer gerekliyse ağ kablolarını çıkarmasını sağlayın, ancak başka bir şey yapmadan önce kurbanı bilgisayarlarından çıkarın.
2. Tüm sistemler için tüm şifrelerinizi, güvenlik altındaki sistemlerle aynı ağdaki tüm bilgisayarlarda değiştirin. Hayır gerçekten. Bütün hesaplar. Tüm bilgisayarlar. Evet, haklısınız, bu aşırı olabilir; Öte yandan, olmayabilir. Her iki şekilde de bilmiyorsun, değil mi?
3. Diğer sistemlerini kontrol et. İnternete bakan diğer hizmetlere ve finansal veya ticari olarak hassas verileri tutanlara özellikle dikkat edin.
4. Sistem herhangi birinin kişisel verilerini elinde bulunduruyorsa, bir kerede potansiyel olarak etkilenebilecek kişilere tam ve net bir açıklama yapın. Bunun zor olduğunu biliyorum. Bunun acıtacağını biliyorum. Birçok işletmenin bu tür bir sorunu halının altına süpürmek istediğini biliyorum ama korkarım bununla ilgilenmek zorunda kalacaksınız.

Hala bu son adımı atmakta tereddüt ediyor musunuz? Anlıyorum Ancak şuna şöyle bakın:

Bazı yerlerde, yetkilileri ve / veya bu tür gizlilik ihlallerinin mağdurlarını bilgilendirmek için yasal bir zorunluluğunuz olabilir. Bununla birlikte, müşterilerinize rahatsız olmaları, onlara bir sorundan bahsetmek için olabilir, onlara söylemiyorsanız çok daha fazla rahatsız olurlar ve birileri kredi kartı bilgilerini kullanarak 8.000 $ değerinde mal tahsil ettikten sonra kendileri bulurlar. Sitenizden çaldım.

Daha önce ne dediğimi hatırlıyor musun? Kötü bir şey zaten oldu . Şimdi tek soru, onunla ne kadar iyi başa çıktığın.

Sorunu tam olarak anlayın:

1. Etkilenen sistemleri, bu aşama tamamen bitinceye kadar tekrar çevrimiçi yapmayın, aksi halde bu makaleyi yazmaya karar vermem için benim için bahşiş noktası olan kişi olmak istemezseniz. Gönderi ile bağlantı kurmuyorum, böylece insanlar ucuz bir şekilde gülerdi; Bu ilk adımı takip etmemenizin sonuçları konusunda sizi uyarmak için bağlantı kuruyorum.
2. Saldırıların güvenliğinizi tehlikeye sokmada nasıl başarılı olduğunu anlamak için 'saldırı' sistemlerini inceleyin. Saldırıların "nereden geldiğini" bulmak için her türlü çabayı göstererek, gelecekte sisteminizi güvenli kılmak için hangi sorunlara sahip olduğunuzu ve çözmeniz gerektiğini anlayın.
3. “Saldırı” sistemlerini tekrar inceleyin, bu sefer saldırıların nereye gittiğini anlamak için, saldırıda hangi sistemlerin tehlikeye girdiğini anlayın. Tehdit altındaki sistemlerin sisteminize daha fazla saldırması için bir sıçrama tahtası olabileceğini öneren işaretçileri takip ettiğinizden emin olun.
4. Herhangi bir saldırıda kullanılan tüm "ağ geçitlerinin" tam olarak anlaşıldığından emin olun, böylece onları düzgün bir şekilde kapatmaya başlayabilirsiniz. (örneğin, sistemleriniz bir SQL enjeksiyon saldırısıyla tehlikeye girdiyse, o zaman yalnızca girdikleri belirli hatalı kod satırını kapatmanız gerekmez, aynı türde bir hata olup olmadığını görmek için tüm kodunuzu denetlemek istersiniz başka bir yerde yapıldı).
5. Birden fazla kusur nedeniyle saldırıların başarılı olabileceğini anlayın. Genellikle, saldırılar bir sistemde büyük bir hata bulmakla değil, bir sistemi tehlikeye atmak için birkaç sorunu (bazen küçük ve kendileri tarafından önemsiz) bir araya getirerek başarırlar. Örneğin, bir veritabanı sunucusuna komut göndermek için SQL Injection saldırılarını kullanmak, saldırdığınız web sitesini / uygulamayı keşfetmek, yönetici bir kullanıcı bağlamında çalışıyor ve bu hesabın haklarını diğer bölümleri tehlikeye atmak için bir basamak taşı olarak kullanıyor bir sistem. Ya da bilgisayar korsanlarının "hoşuna gittiği bir başka gün, ofisteki insanların yaptığı yanlış hatalardan yararlanarak" diyerek istemek gibi.

Kurtarma için bir plan yapın ve web sitenizi tekrar çevrimiçi hale getirin ve buna bağlı kalın:

Hiç kimse olması gerekenden daha uzun süre çevrimdışı olmak istemiyor. Bu bir verilen. Bu web sitesi gelir getirici bir mekanizma ise, hızlı bir şekilde tekrar çevrimiçi hale getirme baskısı yoğunlaşacaktır. Söz konusu olan tek şey, şirketinizin ünü olsa bile, bu, işleri hızla geri koymak için büyük bir baskı oluşturacaktır.

Ancak, çevrimiçi olarak çok hızlı bir şekilde geri dönme eğilimine girmeyin. Bunun yerine, soruna neden olanı anlamak ve çevrimiçi duruma dönmeden önce çözmek için mümkün olan en hızlı şekilde hareket etmek veya bir kez daha bir saldırıya kesinlikle mağdur olacaksınız ve şunu hatırlayın, "bir kez saldırıya uğramak talihsizlik olarak sınıflandırılabilir; sonradan tekrar saldırıya uğramak dikkatsizliğe benziyor "(Oscar Wilde'a özür dileriz).

1. Bu bölüme başlamadan önce ilk etapta başarılı girişime yol açan tüm sorunları anladığınızı farz ediyorum. Davayı abartmak istemem ama önce bunu yapmadıysanız gerçekten yapmanız gerekir. Üzgünüm.
2. Asla şantaj / koruma parası ödemeyin. Bu kolay bir işaretin işaretidir ve bu ifadenin sizi daha önce tanımlamak için kullanılmasını istemezsiniz.
3. Tam bir yeniden kurulum yapmadan aynı sunucuları tekrar çevrimiçi duruma getirmek için ayartmayın. Eski bir donanıma yeni bir kutu inşa etmek ya da "sunucuyu yörüngeden çekip temiz bir kurulum yapmak" eski sisteme geri koymaktan önce temiz olduğundan emin olmak için eski sistemin her bir köşesini denetlemekten daha hızlı olmalıdır. tekrar çevrimiçi. Buna katılmıyorsanız, bir sistemin tamamen temizlendiğinden emin olmanın gerçekte ne anlama geldiğini bilmiyorsunuzdur veya web sitenizin dağıtım prosedürleri kutsal bir karışıklıktır. Büyük olasılıkla sitenizi yalnızca canlı siteyi oluşturmak için kullanabileceğiniz yedeklemeler ve test dağıtımlarına sahipsiniz ve eğer saldırıya uğramadıysanız en büyük sorununuz bu değil.
4. Hack sırasında sistemde "canlı" olan verileri yeniden kullanırken çok dikkatli olun. "Asla yapma" demeyeceğim, çünkü beni görmezden geleceksin, ama açıkçası bütünlüğünü garanti edemeyeceğini bildiğin zaman veriyi korumanın sonuçlarını göz önünde bulundurman gerektiğini düşünüyorum. İdeal olarak, bunu izinsiz giriş öncesinde yapılan bir yedekten geri yüklemelisiniz. Bunu yapamazsanız veya yapamazsanız, bu verilere çok dikkat etmelisiniz, çünkü lekeli. Özellikle bu veriler doğrudan size değil, müşterilere veya site ziyaretçilerine aitse, özellikle sonuçların farkında olmalısınız.
5. Sistem (ler) i dikkatlice izleyin. Bunu gelecekte devam etmekte olan bir süreç olarak çözmelisiniz (aşağıda daha fazlası), ancak sitenizin tekrar çevrimiçi hale gelmesini izleyen dönemde uyanık olmak için fazladan acı çekeceksiniz. Saldırganlar neredeyse kesinlikle geri dönecekler ve onları tekrar girmeye çalışırken anlarsanız, daha önce kullandıkları tüm delikleri ve kendileri için yaptıklarını gerçekten kapatıp açamayacağınızı ve hızlı bir şekilde toplayıp toplayamayacağınızı kesinlikle görebileceksiniz. Yerel yasa uygulayıcıya aktarabileceğiniz bilgiler.

Gelecekte riskini azaltmak.

Anlamanız gereken ilk şey, güvenliğin, Internet'e yönelik bir sistemi tasarlamanın, uygulamanın ve sürdürmenin tüm yaşam döngüsü boyunca uygulamanız gereken bir süreç olduğudur, daha sonra ucuz bir kod gibi birkaç kat daha sonra kodunuza tokatlayabileceğiniz bir şey değil. boya. Düzgün bir şekilde güvenli olması için, bir hizmet ve bir uygulamanın, projenin ana hedeflerinden biri olarak başından itibaren tasarlanması gerekir. Bunun çok sıkıcı olduğunu ve daha önce hepsini duyduğunuzu ve beta web2.0 (beta) hizmetinizi web’de beta durumuna getirmenin "sadece baskı uygulayan kişiyi anlamadığımı" fark ettim, ancak gerçek şu ki: tekrarlanmak, çünkü ilk söylendiği zaman doğruydu ve henüz bir yalan olmadı.

Riski ortadan kaldıramazsınız. Bunu yapmaya bile çalışmamalısın. Ancak yapmanız gereken, hangi güvenlik risklerinin sizin için önemli olduğunu anlamak ve hem riskin etkilerini hem de riskin ortaya çıkma olasılığını nasıl yöneteceğinizi ve azaltacağınızı anlamaktır .

Bir saldırının başarılı olma olasılığını azaltmak için hangi adımları atabilirsiniz?

Örneğin:

1. İnsanların sitenize girmesine izin veren kusur, satıcı kodunda bilinen bir hata mıydı? Öyleyse, Internet'e bakan sunucularınızdaki uygulamaları düzeltme biçiminize yaklaşımınızı yeniden düşünmeniz gerekir mi?
2. İnsanların sitenize girmesine izin veren kusur, satıcı kodunda bilinmeyen bir hata mıydı? Kesinlikle, böyle bir şey sizi ısırdığı zaman tedarikçileri değiştirmeyi kesinlikle savunmuyorum çünkü hepsinin kendi sorunları var ve bu yaklaşımı uygularsanız en fazla bir yıl içinde platformlar tükenecek. Bununla birlikte, bir sistem sizi sürekli olarak durdurursa, o zaman ya daha sağlam bir şeye geçmelisiniz ya da en azından, sisteminizi savunmasız bileşenlerin pamuk yünü içinde ve düşman gözlerden mümkün olduğunca uzakta kalması için yeniden yapılandırmalısınız.
3. Hata, sizin tarafınızdan (veya sizin için çalışan bir müteahhit) geliştirdiğiniz kodda bir hata mıydı? Öyleyse, canlı sitenize dağıtım kodunu nasıl onayladığınız konusundaki yaklaşımınızı yeniden düşünmeniz gerekir mi? Hata, gelişmiş bir test sistemiyle veya kodlama "standart" ınızdaki değişikliklerle yakalanmış olabilir mi (örneğin, teknoloji her derde deva olmasa da, iyi belgelenmiş kodlama tekniklerini kullanarak başarılı bir SQL enjeksiyon saldırısı olasılığını azaltabilirsiniz. ).
4. Kusur, sunucu veya uygulama yazılımının nasıl kullanıldığına dair bir sorun mu oldu? Öyleyse, mümkün olduğunda sunucuları oluşturmak ve dağıtmak için otomatik prosedürler kullanıyor musunuz? Bunlar, tüm sunucularınızdaki tutarlı bir "temel" durumunun korunmasında, her birinde yapılması gereken özel çalışma miktarını en aza indirgemekte ve dolayısıyla bir hata yapma fırsatını en aza indirgemekte harika bir yardımcıdır. Aynı şey kod dağıtımı için de geçerlidir - web uygulamanızın en son sürümünü dağıtmak için "özel" bir şey yapmanız gerekiyorsa, daha sonra otomatikleştirmeyi deneyin ve her zaman tutarlı bir şekilde yapıldığından emin olun.
5. İzinsiz giriş daha önce sisteminizin daha iyi izlenmesiyle yakalanabilir mi? Elbette, personeliniz için 24 saat izleme veya "çağrı" sistemi uygun maliyetli olmayabilir, ancak web üzerinden hizmetlerinizi sizin için izleyebilen ve bir sorun durumunda sizi uyaran şirketler var. Bunu göze alamayacağınıza ya da ihtiyacınız olmadığına karar verebilirsiniz ve bu sadece iyi ... sadece dikkate alın.
6. Uygun olduğu durumlarda tripwire ve nessus gibi aletler kullanın - ancak söylediğim gibi sadece kör kullanmayın. Ortamınıza uygun birkaç iyi güvenlik aracını nasıl kullanacağınızı, bu araçları güncel tutup düzenli olarak kullanacağınızı öğrenmek için zaman ayırın.
7. Web sitenizin güvenliğini düzenli olarak 'denetlemek' için güvenlik uzmanlarını işe almayı düşünün. Yine, bunu karşılayamayacağınıza veya gerek duymayacağınıza karar verebilirsiniz ve bu iyi ... sadece dikkate alın.

Başarılı bir saldırının sonuçlarını azaltmak için hangi adımları atabilirsiniz?

Ev suyunuzun alt katının “riskinin” yüksek olduğuna, ancak taşınmayı garanti edecek kadar yüksek olmadığına karar verirseniz, en azından yeri doldurulamaz aile yadigarı üst katlara taşınmalısınız. Sağ?

1. Doğrudan Internet’e maruz kalan hizmetleri azaltabilir misiniz? Dahili hizmetleriniz ve İnternet'e dönük hizmetleriniz arasında bir çeşit boşluk tutabilir misiniz? Bu, harici sistemleriniz tehlikeye atılsa bile, iç sistemlerinize saldırmak için bunu sıçrama tahtası olarak kullanma şansının sınırlı olmasını sağlar.
2. Saklamanız gerekmeyen bilgileri saklıyor musunuz? Bu tür bilgileri başka bir yerde arşivlendiğinde "çevrimiçi" olarak mı saklıyorsunuz? Bu kısımda iki nokta var; Açık olanı, insanların sahip olmadığınız bilgileri sizden alamayacaklarıdır ve ikinci nokta, ne kadar az depolarsanız, daha az bakım yapmanız ve kodlamanız gereken şeylerdir ve bu yüzden böceklerin içine kayma olasılığı daha azdır. kodunuz veya sistem tasarımınız.
3. Web uygulamanız için "en az erişim" ilkelerini kullanıyor musunuz? Kullanıcıların yalnızca bir veritabanından okuması gerekiyorsa, web uygulamasının yalnızca okuma erişimine sahip olduğu hesabın, okuma erişimine izin vermediğinden ve kesinlikle sistem düzeyinde erişim sağlamadığından emin olun.
4. Bir konuda çok deneyimli değilseniz ve işletmeniz için merkezi değilse, dış kaynak kullanımını düşünün. Başka bir deyişle, masaüstü uygulama kodunu yazmaktan bahseden küçük bir web sitesi işletiyorsanız ve siteden küçük masaüstü uygulamaları satmaya karar verirseniz, kredi kartı sipariş sisteminizi Paypal gibi birine "dış kaynak" olarak düşünün.
5. Mümkünse, Olağanüstü Durum Kurtarma planınızın bir parçası olan güvenli sistemlerden kurtarma alıştırması yapın. Bu tartışmalı, karşılaşabileceğiniz başka bir "felaket senaryosudur", sadece kendi sorunlarıyla ve her zamanki gibi 'sunucu odasının yangına yakalanmasından' farklı olan sorunlardan biri, dev sunucu tarafından tüyler yiyen bir şey istila etti. (XTZ başına düzenleyin)

... Ve sonunda

Muhtemelen, başkalarının önemli olduğunu düşündüğü şeylerin hiçbirini dışarıda bırakmadım, ancak yukarıdaki adımlar, en azından bilgisayar korsanlarına kurban verecek kadar şanssızsanız, bir şeyleri çözmeye başlamanıza yardımcı olacaktır.

Her şeyden önce: Panik yapmayın. Harekete geçmeden önce düşün. Bir karar verdikten sonra iyice harekete geçin ve adım listeme ekleyeceğiniz bir şey varsa aşağıdaki yorumunuzu bırakın.

Daima yörüngeden çek. Emin olmanın tek yolu bu.

_{(kaynak: flickr.com )}

Çoğu sistem içsel, örtük bir güveni olan bütüncül varlıklardır. Uzlaşılmış bir sisteme güvenmek, başlangıçta sisteminizi ihlal eden kişiye güvendiğinizin açık bir ifadesidir. Başka bir deyişle:

Güvenemezsin. Temizlik ile zahmet etmeyin. Makineyi hemen ayırın ve yalıtın. Devam etmeden önce ihlalin doğasını anlayın, yoksa yine aynı şeyi davet edersiniz. Mümkünse, ihlalin tarihini ve saatini almayı deneyin, böylece bir referans çerçevesine sahip olursunuz. Buna ihtiyacınız var çünkü yedeklemeden geri yüklerseniz, yedeklemenin kendisinin üzerinde bir uzlaşma kopyası bulunmadığından emin olmanız gerekir. Geri yüklemeden önce silin - kısayolları almayın.

Pratik olarak konuşursak, çoğu insan bunu yapmaz çünkü çok uzun süreceğini ya da rahatsız edici olacağını düşünüyorlar. Sayısız müşteriye sorunların devam etme olasılığını tavsiye ettim, ancak bir yeniden yükleme genellikle bu nedenlerden biri için bir karar vericinin baskısı altında.

Bu, giriş yöntemini ve hasarın tamamını bildiğimden emin olduğum sistemlerde (katı makine dışı, tipik olarak bir IDS, belki SELinux veya izinsiz girişin kapsamını sınırlayan benzer bir şey), Kendini çok suçlu hissetmeden tekrar temizlemeden temizlik yaptım.

Büyük olasılıkla, yeniden yapılanma konusunda kendilerini güvende hissetmeleri için yeterince test edilmiş bir felaket kurtarma yordamına sahip değiller veya ne kadar sürecekleri veya etkinin ne kadar olacağı veya yedeklerin güvenilmez olduğu veya risk analistleri belirsiz olduğu belli değil. uzlaşılmış bir sistemin kapsamını anlamıyorum. Birçok neden düşünebilirim.

Temel rutin ve politikalarda çoğunlukla yanlış bir şey olduğunu ve açıkça itiraf etmek isteyeceğiniz bir şey olmadığını söyleyebilirim - ve bunun yerine savunma duruşu alırsınız. En azından, hangi açıdan bakarsanız bakın, tehlikeye düşmüş bir sistemi silmemeyi göremiyorum veya savunamıyorum.

Daha önce sistemi yok etmedim, böylece girdikleri vektörün bir analizini yapabilir ve daha sonra kullanımın analizini yapabilirim ve içeride nereye girdiklerini görmek için.

Köklendirildikten sonra - canlı bir bal küpünüz vardır ve bu sadece kesmekten çok daha fazlasını sunabilir. - özellikle polis için.

• Bu, sıcak beklemede temiz bir sistem elde edebilmek ve köklü kutuyu izole etmek için hızlı bir şekilde geliştirilmiş ağ güvenliği sunabildiğimi söyledi.