Bu, Sunucu Güvenliği ile İlgili Kanonik bir Soru - İhlal Olaylarına Cevap Verme (Hacking)
Ayrıca Bakınız:

• LAMP Sunucusunu Güvende Tutmanın İpuçları
• Kök Uyumluluktan Sonra Yeniden Yükle?

Kanonik Sürüm
Sunucularımdan birinin veya daha fazlasının bir bilgisayar korsanı, virüs veya başka bir mekanizma nedeniyle tehlikeye girdiğinden şüpheleniyorum:

• İlk adımlarım neler? Siteye vardığımda sunucunun bağlantısını kesmeli, "kanıtları" korumalı mıyım, başka ilk düşünceler var mı?
• Yeniden çevrimiçi olma hizmetlerine nasıl geçeceğim?
• Aynı şeyin tekrar yaşanmasını nasıl önlerim?
• Bu olaydan öğrenmek için en iyi uygulamalar veya metodolojiler var mı?
• Bir Olay Müdahale Planını bir araya getirmek istesem, nereden başlardım? Bu, Felaket Kurtarma veya İş Sürekliliği Planlamamın bir parçası mı olmalı?

Orijinal versiyon

2011.01.02 - Pazar günü saat 9.30’da işe gideceğim, çünkü sunucumuz bir şekilde tehlikeye girmiş ve sağlayıcımıza DOS saldırısı ile sonuçlanmıştır . İnternete erişim yapan sunucular kapatıldı, bu da 5-600'den fazla müşterimiz sitelerinin kapalı olduğu anlamına geliyor. Şimdi bu bir FTP kesmesi ya da bir yerlerde koddaki bazı zayıflıklar olabilir. Oraya gidene kadar emin değilim.

Bunu hızlıca nasıl takip edebilirim? Sunucuyu en kısa sürede yedekleyemezsem, çok fazla dava açıyoruz. Herhangi bir yardım takdir edilmektedir. Open SUSE 11.0 kullanıyoruz.

---

2011.01.03 - Yardımlarınız için herkese teşekkürler. Neyse ki ben en yakın, bu sunucudan sorumlu tek kişi değildim. Farklı bir durumda olan diğerleri için geçerli olmasa da, bu sorunu çözmeyi başardık. Ne yaptığımızı detaylandıracağım.

Sunucuyu ağdan çıkardık. Endonezya'daki başka bir sunucuya Hizmet Reddi saldırısı gerçekleştirdi (gerçekleştirmeye çalışıyordu) ve suçlu taraf da oradaydı.

Öncelikle, sunucuda nereden geldiğini belirlemeye çalıştık, sunucuda 500'den fazla sitemiz olduğunu düşünüyoruz, bir süredir ay ışığı almayı bekliyorduk. Bununla birlikte, SSH erişimi hala devam ederken, saldırılar başladığı sırada düzenlenen veya oluşturulan tüm dosyaları bulma komutunu çalıştırdık. Neyse ki, rahatsız edici dosya kış tatilleri boyunca oluşturuldu, bu da o sırada sunucuda başka bir dosya oluşturulmadığı anlamına geliyordu.

Daha sonra bir ZenCart web sitesinde yüklenen resimler klasörünün içindeki rahatsız edici dosyayı tespit edebildik .

Kısa bir sigara molasından sonra, dosyaların konumu nedeniyle, güvenli olmayan bir şekilde bir dosya yükleme tesisi tarafından yüklenmiş olması gerektiği sonucuna vardık. Bazı Google aramalarından sonra, bir plak şirketi için bir resim için ZenCart yönetici panelinde dosyaların yüklenmesine izin veren bir güvenlik açığı olduğunu tespit ettik. (Hiç kullanmadığı bölüm), bu formu gönderen sadece herhangi bir dosya yükledi, dosyanın uzantısını kontrol etmedi ve hatta kullanıcının giriş yapıp yapmadığını kontrol etmedi.

Bu, saldırı için bir PHP dosyası da dahil olmak üzere herhangi bir dosyanın yüklenebileceği anlamına geliyordu. Etkilenen sitede ZenCart ile güvenlik açığını sağladık ve sorunlu dosyaları kaldırdık.

İş yapıldı ve ben 2 için evdeydim

---

Ahlaki - Daima ZenCart veya bu konuda başka bir CMS sistemi için güvenlik yamaları uygulayın. Güvenlik güncelleştirmeleri yayınlandığında olduğu gibi, tüm dünya bu güvenlik açığından haberdar edilir. - Daima yedekleme yapın ve yedeklerinizi yedekleyin. - Bu gibi zamanlarda orada olacak birini işe almak veya düzenlemek. Kimsenin Sunucu Hatası'ndaki panik yayına güvenmesini önlemek için.

Buraya gönderdiklerinizden özel tavsiyeler vermek zor, ancak yıllar önce yazdığım bir blog yazısına dayanarak yazdığım bir yazıya dayanarak bazı genel tavsiyelerim var.

Panik Yapma

İlk önce, sisteminizi izinsiz giriş öncesi alınan bir yedekten geri yüklemek dışında hiçbir "hızlı düzeltme" yoktur ve bunun en az iki sorunu vardır.

1. Saldırının ne zaman gerçekleştiğini tespit etmek zor.
2. Son zamanlarda kırılmalarına izin veren "deliği" kapatmanıza ya da gerçekleşmiş olabilecek herhangi bir "veri hırsızlığının" sonuçlarını çözmenize yardımcı olmaz.

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% 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. Eğer sadece bir web sitesi hack kurbanı olduktan sonra bunu okuyorsanız o zaman gerçekten üzgünüm ve burada gerçekten yararlı bir şeyler bulacağınızı umuyorum, ama 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: 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, bu size kalmış. Fakat onları doğru bir şekilde takip etmek sonunda işleri daha iyi hale getirecektir. İ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, derhal veri korumasından sorumlu kişiyi (siz değilseniz) ve URGE'yi tam bir açıklama ile bilgilendirin. Bunun zor olduğunu biliyorum. Bunun acıtacağını biliyorum. Birçok işletmenin bu tür bir sorunu halının altına çekmek istediğini biliyorum ancak işin bununla ilgilenmesi gerekecek - ve bununla ilgili tüm gizlilik yasalarına dikkat ederek bunu yapması gerekiyor.

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. Bu yazıyla bağlantı kurmayacağım, böylece insanlar ucuz bir kahkaha bulabiliyorlar, ama asıl trajedi, insanların hatalarından bir şeyler öğrenemediği zamanlar.
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ı bulmak 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.

Neden sadece tespit ettiğin kötüye kullanımı veya rootkit'i "tamir etmiyor" ve sistemi tekrar çevrimiçi hale getirmiyorsun?

Bu gibi durumlarda sorun, artık o sistemi kontrol edememenizdir. Artık senin bilgisayarın değil.

Sistemi kontrol altına aldığınızdan emin olmanın tek yolu sistemi yeniden kurmaktır. Sisteme girmek için kullanılan istismarın tespitinde ve düzeltilmesinde çok fazla değer varken, davetsiz misafirlerin kontrolünü ele geçirdikten sonra sisteme başka ne yapıldığından emin olamazsınız. "kendilerini" yeni bilgisayarlarını diğer bilgisayar korsanlarından korumak ve kendi rootkit'lerini kurmak için kullandıkları sömürülerin yamalarına sokmak için bir botnet sistemi kullanıyorlardı).

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 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 anlayabilirseniz, daha önce kullandıkları tüm delikleri ve kendileri için yaptıklarını gerçekten kapattıysanız ve faydalı bir şekilde toplanıp toplanmadığını 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’deki beta durumuna getirmenin "sadece baskı uygulayan kişiyi anlamadığımı" fark ettim. 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 girmelerine 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, bunun gibi bir şey sizi ısırdığında değişen tedarikçileri 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? Tabii ki, personeliniz için 24 saat izleme veya "çağrı" sistemi düşük maliyetli olabilir, ancak sizin için web yönlendirme hizmetlerinizi 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 seli 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; bariz olanı, insanların sahip olmadığınız bilgileri sizden alamayacağıdır ve ikinci nokta, ne kadar az depolarsanız, daha az bakım yapmanız ve kodlamanız gereken şeylerdir ve bu nedenle 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 birisine "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 sistemlerdeki kurtarma çalışmalarını yapın. Bu tartışmalı, karşılaşabileceğiniz başka bir "felaket senaryosudur", sadece kendi sorunlarıyla ve her zamanki "sunucu odasının ateş altında tutulduğu" / "dan farklı olan sorunlardan biri, dev sunucu tarafından tüyler yiyen bir şey istila etti.

... 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.

Başının biraz üzerinde sanki sesler; bu iyi. Patronunuzu arayın ve acil bir güvenlik yanıtı bütçesi için pazarlık etmeye başlayın. 10.000 dolar başlamak için iyi bir yer olabilir. Ardından, güvenlik olayı tepkisi konusunda uzmanlaşmış şirketleri aramaya başlamak için birisini (PFY, iş arkadaşı, yönetici) edinmeniz gerekir. Pek çoğu 24 saat içinde yanıt verebilir ve şehrinizde bir ofisi varsa bazen daha da hızlı yanıt verebilir.

Ayrıca müşterileri tetiklemek için birine ihtiyacınız var; Şüphesiz, zaten biri. Neler olup bittiğini, durumu ele almak ve ne olduğunu sormak için neler yapıldığını açıklamak için birinin telefonda olması gerekiyor.

O zaman, ihtiyacın olan ...

1. Sakin ol. Olayın tepkisinden sorumluysanız, şimdi yaptığınız şeyin en yüksek profesyonellik ve liderliği göstermesi gerekiyor. Yaptığınız her şeyi belgeleyin ve yöneticinizin ve yönetici ekibinizin yaptığınız önemli eylemlerden haberdar olmasını sağlayın; buna, bir yanıt ekibi ile çalışmak, sunucuları devre dışı bırakmak, verileri yedeklemek ve bir şeyleri yeniden çevrimiçi yapmak da dahildir. Kanlı ayrıntılara ihtiyaçları yok, ama her 30 dakikada bir senden haber almalılar.

2. Gerçekçi ol. Sen bir güvenlik profesyoneli değilsin ve bilmediğin şeyler var. Bu iyi. Sunuculara giriş yaparken ve verilere bakarken sınırlarınızı anlamanız gerekir. Nazikçe bas. Soruşturmanız sırasında, hayati bilgilere dayanmadığınızdan veya daha sonra ihtiyaç duyabileceğiniz bir şeyi değiştirmediğinizden emin olun. Eğer kendinizi rahatsız hissediyorsanız veya tahmin ediyorsanız, durmak ve üstlenmeniz gereken deneyimli bir profesyonel edinmek için iyi bir yer.

3. Temiz bir USB çubuğu alın ve sabit diskleri yedekleyin. Burada kanıt toplayacaksın. İlgili olabileceğini düşündüğünüz her şeyin yedeğini alın; İnternet servis sağlayıcınızla iletişim, ağ dökümü, vb.

4. En önemlisi kaybı durdurmaktır. Tehdit altındaki hizmetlere, verilere ve makinelere erişimi tanımlayın ve kesin. Tercihen, ağ kablolarını çekmelisiniz; eğer yapamazsan, o zaman gücü çek.

5. Daha sonra, saldırganı sökmeniz ve delikleri / delikleri kapatmanız gerekir. Tahminen, saldırganın etkileşimli erişimi artık yok; çünkü siz ağı aldınız. Şimdi tanımlamanız, belgelemeniz (yedeklemeler, ekran görüntüleri ve kendi kişisel gözlem notlarınızla veya tercihen sürücüleri etkilenen sunuculardan çıkararak ve tam bir disk görüntüsü kopyası yaparak bile) ve ardından geride bıraktığı tüm kodları ve işlemleri kaldırmanız gerekir. . Yedeklemeniz yoksa bu sonraki bölüm emilecektir; Saldırganı sistemden elle çözmeyi deneyebilirsiniz, ancak geride bıraktığı her şeyi aldığınızdan asla emin olmayacaksınız. Rootkit'ler kısır ve hepsi tespit edilemez. En iyi yanıt, girdiği güvenlik açığını belirlemek, etkilenen disklerin görüntü kopyalarını almak ve ardından etkilenen sistemleri silmek ve bilinen iyi bir yedekten yeniden yüklemek olacaktır. Don' Yedeklemenize kör bir şekilde güvenme; doğrula! Yeni ana bilgisayar ağa tekrar girmeden önce güvenlik açığını onarın veya kapatın ve sonra çevrimiçi duruma getirin.

6. Tüm verilerinizi bir rapor halinde düzenleyin. Bu noktada güvenlik açığı kapandı ve nefes almak için biraz zamanınız var. Bu adımı atlamak için cazip olmayın; sürecin geri kalanından daha da önemlidir. Raporda neyin yanlış gittiğini, ekibinizin nasıl yanıt verdiğini ve bu olayın tekrarlanmasını önlemek için attığınız adımları tanımlamanız gerekir. Mümkün olduğu kadar ayrıntılı olun; bu sadece sizin için değil, yönetiminiz için ve potansiyel bir davada bir savunma olarak.

Bu, ne yapılması gerektiğine dair gök yüksekliğinde bir inceleme; işlerin çoğu sadece dokümantasyon ve yedekleme işlemleriyle ilgilidir. Panik yapma, bunu yapabilirsin. Ben kuvvetle profesyonel güvenlik yardım almak öneriyoruz. Olanları idare edebilseniz bile, yardımları paha biçilmez olacak ve süreci daha kolay ve hızlı hale getirmek için ekipmanla birlikte geliyorlar. Patronunuz pahasına paçalıyorsa, bir davaya kıyasla çok küçük olduğunu ona hatırlatın.

Durumunuz için benim konsolosluklarım var. İyi şanslar.

CERT , iyi bir UNIX veya NT Sistem Anlaşmasından Kurtulma Adımları belgesine sahiptir . Bu belgenin belirli teknik ayrıntıları biraz güncel değil, ancak genel tavsiyelerin birçoğu hala doğrudan geçerli.

Temel adımların kısa bir özeti budur.

• Güvenlik politikanıza veya yönetiminize danışın.
• Kontrolü elinize alın (bilgisayarı çevrimdışı duruma getirin)
• Saldırıyı analiz et, günlükleri al, yanlış olanı bul
• Onarım işleri
  • İşletim sisteminizin temiz bir versiyonunu yükleyin !!! Sistemin tehlikeye atılması durumunda, ona güvenemezsin, dönem.
• Sistemleri güncelle ki bu bir daha olamaz
• İşlemleri devam ettir
• Gelecekte ve doküman için politikanızı güncelleyin

Sizi özellikle E.1 bölümüne yönlendirmek istiyorum.

E.1. Bir makine tehlikeye girerse, çekirdek, ikili dosyalar, veri dosyaları, çalışan işlemler ve bellek dahil bu sistemdeki herhangi bir şeyin değiştirilebileceğini unutmayın. Genel olarak, bir makinenin arka kapalı ve davetsiz misafir modifikasyonlarından arındırılmış olduğuna güvenmenin tek yolu işlemi yeniden kurmaktır.

Tripwire gibi bir sisteme sahip değilseniz, sistemi temizlediğinizden% 100 emin olmanız mümkün değildir.

1. Sorunu tanımla . Günlükleri oku.
2. İçerir . Sunucunun bağlantısını kestiniz, bu yüzden yapıldı.
3. Ortadan kaldırmak . Büyük olasılıkla etkilenen sistemi yeniden yükleyin. Ancak, hack olanın sabit diskini silmeyin, yeni bir tane kullanın. Daha güvenlidir ve eskisi gibi desteklenmemiş çirkin saldırıları kurtarmak ve ne olduğunu bulmak için adli tıp yapmak zorunda kalabilirsiniz.
4. Kurtar . Gerekenleri yükleyin ve müşterilerinizi çevrimiçi hale getirmek için yedekleri kurtarın.
5. Takip . Sorunun ne olduğunu anlayın ve tekrar olmasını engelleyin.

Robert'ın "acı hap" yanıtı açık ama tamamen genel (sorunuz gibi). Bir sunucunuz varsa ve bir sunucunuz ve 600 istemciniz varsa tam zamanlı bir sysadmin'e ihtiyaç duyuyorsunuz gibi geliyor ama bu size yardımcı olmuyor.

Bu durumda biraz elde tutma sağlayan bir barındırma şirketi işletiyorum, bu yüzden birçok ödün verilmiş makineyle uğraşıyorum, fakat aynı zamanda kendimiz için de en iyi uygulamalarla ilgileniyorum. Bir uzlaşmanın doğasından tam olarak emin olmadıkça, her zaman ödün vermeyen müşterilerimize yeniden oluşturmalarını söyleriz. Uzun vadede başka hiçbir sorumlu yol yoktur.

Ancak, neredeyse kesinlikle sadece DoS saldırıları veya IRC fedaileri için bir fırlatma rampası veya müşterilerinizin siteleri ve verileriyle tamamen alakasız bir şeyler yapmak isteyen bir senaryo çocuğunun kurbanısınız. Bu nedenle, yeniden inşa ederken geçici bir önlem olarak, kutunuza ağır bir dış güvenlik duvarı getirmeyi düşünebilirsiniz. Sitelerinizin çalışması için kesinlikle gerekli olmayan tüm giden UDP ve TCP bağlantılarını engelleyebiliyorsanız, ödünç alanınızı kolayca sizden ödünç alanlardan yararsız hale getirebilir ve sağlayıcınızın ağındaki etkiyi sıfıra azaltabilirsiniz.

Bu işlem daha önce yapmadıysanız ve hiç bir güvenlik duvarı düşünmediyseniz, birkaç saat sürebilir, ancak saldırganın müşterilerinize verilere erişmesine izin verme riski altında müşteri hizmetlerinizi geri yüklemenize yardımcı olabilir . Bir makinede yüzlerce müşteriniz olduğunu söylediğinizden beri, küçük işletmeler için küçük broşür web sitelerini barındırdığınızı ve kredi kartı numaralarıyla dolu 600 e-ticaret sistemini barındıracağınızı tahmin ediyorum. Bu durumda, bu sizin için kabul edilebilir bir risk olabilir ve sisteminizi, herhangi bir şeyi geri getirmeden önce güvenlik hatalarını tespit etmek için 600 siteyi denetlemekten daha hızlı bir şekilde çevrimiçi hale getirin. Ancak hangi verilerin olduğunu ve bu kararı ne kadar rahat vereceğinizi bileceksiniz.

Bu kesinlikle en iyi uygulama değil, ancak işvereninizde şu ana kadar olan şey değilse, parmağınızı sallayın ve bir SWAT ekibinden onbinlerce sterlin istediğinizi hissetmelerini isteyin, bu sizin suçunuzdur (haksız! ) pratik seçenek gibi gelmiyor.

ISS'nizin buradaki yardımı oldukça önemli olacak - bazı ISS'ler ağ bağlantısı kesilirken sunucuyu yönetmenize izin verecek bir konsol sunucusu ve ağ önyükleme ortamı (fiş, ancak en azından ne tür bir tesis arayacağınızı biliyorsunuz) sağlar. Bu tamamen bir seçenekse, isteyin ve kullanın.

Ancak uzun vadede, Robert'ın görevine ve her bir sitenin ve kurulumun denetlenmesine dayanarak bir sistem yeniden inşası planlamalısınız. Ekibinize bir sysadmin ekleyemiyorsanız , ISS'nize sysadminning yardımını ödediğiniz ve bu tür bir şey için 24 saat yanıt verdiğiniz yönetilen bir barındırma anlaşması arayın . İyi şanslar :)

Yeniden yüklemeniz gerekiyor. Gerçekten ihtiyacın olanı sakla. Ancak tüm çalıştırılabilir dosyalarınıza virüs bulaştığını ve kurcalanabileceğini unutmayın. Aşağıdakileri python'da yazdım: http://frw.se/monty.py , belirli bir dizindeki tüm dosyalarınızın MD5 özetlerini oluşturur ve bir sonraki çalıştırışınızda, bir şey değişip değişmediğini kontrol eder ve sonra ne çıktı dosyalar değişti ve dosyalar da değişti.

Garip dosyaların düzenli olarak değiştirilip değiştirilmediğini görmek sizin için yararlı olabilir.

Ancak şu anda yapmanız gereken tek şey, bilgisayarınızı internetten çıkarmak.

NOT: Bu bir öneri değildir. Özel Olay Tepkisi protokolüm muhtemelen Grant unwin'in davasına değiştirilmemiş şekilde uygulanmaz.

Akademik tesislerimizde sadece hesaplama yapan yaklaşık 300 araştırmacımız var. Web sitelerine sahip 600 müşteriniz var, böylece protokolünüz muhtemelen farklı olacak.

Bir Sunucu Anlaşmaya Girdiğinde Protokolümüze İlk Adımlar :

1. Saldırganın kök kazanabildiğini tanımlayın (yükseltilmiş ayrıcalıklar)
2. Etkilenen sunucuyu / sunucuları çıkarın. Ağ mı yoksa güç mü? Lütfen ayrı bir tartışma bakın .
3. Diğer tüm sistemleri kontrol et
4. Etkilenen sunucuları canlı bir cd'den önyükleyin
5. (isteğe bağlı) Tüm sistem sürücülerinin görüntülerinidd

6. Ölüm sonrası adli tıp yapmaya başla. Kayıtlara bak, saldırı zamanını bul, o zaman değiştirilmiş dosyaları bul. Nasıl cevap vermeye çalışın ? soru.

   • Paralel olarak, kurtarma işleminizi planlayın ve yürütün.
   • Hizmeti sürdürmeden önce tüm kök ve kullanıcı şifrelerini sıfırla

"Tüm arka kapılar ve rootkit'ler temizlenmiş olsa bile", o sisteme güvenmeyin - sıfırdan tekrar yükleyin.

Sınırlı deneyimlerime göre, Linux’taki sistem ödünleri Windows’ta olduğundan daha “kapsamlı” olma eğilimindedir. Kök kitleri, kötü amaçlı yazılımları gizlemek için sistem ikili dosyalarının kişiselleştirilmiş kodla değiştirilmesini içerir ve çekirdeğin sıcak eklenmesi engeli biraz daha düşüktür. Ayrıca, pek çok kötü amaçlı yazılım yazarı için ev işletim sistemidir. Genel rehberlik her zaman etkilenen sunucuyu sıfırdan yeniden oluşturmaktır ve bir nedenden dolayı genel rehberliktir.

O köpeği formatla.

Fakat eğer yeniden inşa edemezseniz (ya da güçler-o-be-be, ihtiyaç duyduğu yorucu ısrarınıza karşı yeniden inşa etmenize izin vermez), ne arıyorsunuz?

İzinsiz girişin keşfedilmesinden ve bir sistem geri yüklemesinin yapılmasından bu yana bir süre geçmiş gibi göründüğü için, hizmete geri dönmek için girdikleri yerin izlerinin damgayla durdurulması çok muhtemeldir. Talihsiz.

Olağandışı ağ trafiğini bulmak muhtemelen en kolay olanıdır, çünkü kutuda herhangi bir şey çalıştırmayı içermez ve sunucu kurulurken ve ne yapıyorsa yapılabilir. Elbette, ağ donanımınızın bağlantı noktası yayılmasına izin verdiğini varsayalım. Bulduğunuz şey tanısal olabilir veya olmayabilir, fakat en azından bilgidir. Olağandışı trafik almak, sistemin hala tehlikeye atıldığına ve düzleşmeye ihtiyaç duyduğuna dair güçlü bir kanıt olacaktır. TPTB'yi bir reformatın gerçekten, gerçekten de kesinti zamanına değdiğine ikna etmek yeterince iyi olabilir.

Bunu başaramazsanız, sistem bölümlerinizin bir dd kopyasını alın ve başka bir kutuya yerleştirin. İçeriği, bir sunucuyla tehlikeye atılan ile aynı yama düzeyinde karşılaştırmaya başlayın. Neyin farklı göründüğünü (bu tekrar md5sums) tanımlamanıza yardımcı olmalı ve tehlike altındaki sunucudaki göz ardı edilen alanları gösterebilir. Bu, dizinler ve ikili dosyalar arasında eleme yapmanın bir LOT'u ve emek yoğun olacak. Hatta bir reformat / yeniden yapılanmadan daha yoğun emek olabilir ve TPTB'yi gerçekten ihtiyaç duyduğu reformu yapmak konusunda vuracak başka bir şey olabilir.

@Robert Moir, @Aleksandr Levchuk, @blueben ve @Matthew Bloch'un yanıtlarında çok fazla durduğunu söyleyebilirim.

Bununla birlikte, farklı posterlerin cevapları farklıdır - bazıları daha üst düzeydedir ve hangi prosedürlerin (genel olarak) uygulanması gerektiği hakkında konuşur.

Bunu birkaç ayrı bölüme ayırmayı tercih ederim 1) Triyaj, AKA Müşterilerle ve yasal çıkarımlarla nasıl başa çıkılır ve oradan nereye gidileceğini belirleyin (Robert ve @blueben tarafından çok iyi listelenir) 2 Etkilerin azaltılması 3 ) Olay tepkisi 4) Ölüm sonrası adli tıp 5) İyileştirme öğeleri ve mimari değişiklikler

(Buraya, SANS GSC sertifikalı yanıt bildirimini buraya yerleştirin) Geçmiş deneyimlere dayanarak şunu söyleyebilirim:

Müşteri yanıtlarını, bildirimleri, yasal ve gelecekteki planları nasıl ele aldığınıza bakılmaksızın, eldeki ana konuya odaklanmayı tercih ederim. OP'nin asıl sorusu aslında sadece doğrudan # 2 ve # 3 ile ilgilidir, temel olarak, saldırının nasıl durdurulacağı, müşterilerin yanıtlarında iyi bir şekilde ele alınan asıl hallerinde ASAP'ı tekrar çevrimiçi hale getirmeleridir.

Yanıtların geri kalanı mükemmeldir ve birçok iyi tanımlanmış en iyi uygulamayı ve gelecekte bunun olmasını engellemenin yanı sıra buna daha iyi yanıt vermenin yollarını da kapsar.

Gerçekten de OP'nin bütçesine ve hangi sektörde olduklarına, arzu ettikleri çözümün ne olduğuna vb. Bağlıdır.

Belki de yerinde SA tahsis etmeleri gerekiyor. Belki bir güvenlik görevlisine ihtiyaçları vardır. Belki de Firehost veya Rackspace Managed, Softlayer, ServePath vb. Gibi tamamen yönetilen bir çözüme ihtiyaçları vardır.

Bu gerçekten işleri için neyin işe yaradığına bağlı. Belki de temel yetkinlikleri sunucu yönetiminde değildir ve bunu geliştirmeye çalışmaları mantıklı değildir. Veya, belki de zaten oldukça teknik bir organizasyondurlar ve doğru işe alım kararlarını alabilir ve tam zamanlı olarak özel bir ekip oluşturabilirler.

Çalışmaya başladıktan ve sunucuya baktıktan sonra sorunu çözmeyi başardık. Neyse ki, rahatsız edici dosyalar ofis kapalıyken bir Pazar günü sisteme yüklendi ve günlükler ve önbellek dosyaları dışında hiçbir dosya oluşturulmamalıdır. Basit bir kabuk komutu ile o gün hangi dosyaların oluşturulduğunu bulmak için onları bulduk.

Tüm rahatsız edici dosyalar, eski zencart sitelerimizin bazılarında / images / klasörü içinde gözüküyor. Herhangi bir aptalın, görsel olmayan kısımların yönetici bölümündeki resim yükleme bölümüne yüklenmesine izin veren (kıvrılma kullanarak) bir güvenlik açığı olduğu görülüyor. Suçlu .php dosyalarını sildik ve resim olmayan dosya yüklemelerini engellemek için yükleme komut dosyalarını düzeltdik.

Geçmişe bakıldığında, oldukça basitti ve bu soruyu iPhone'umda işe giderken gündeme getirdim. Tüm yardımlarınız için teşekkürler.

Gelecekte bu gönderiyi ziyaret eden herhangi birinin referansı için. Ben ediyorum değil elektrik fişine çekerek öneriyoruz.

Kapsamlı teknik cevaplara katkıda bulunacak çok az şeyim var ancak lütfen bunlardan bazılarına dikkat edin:

Teknik olmayan eylemler:

• Olayı dahili olarak bildirin.
  Zaten bir CYA tekniği olarak görünebilecek bir olay müdahale planınız yoksa, ancak BT departmanı, tehlikeli bir sunucunun ticari etkisini belirlemek için tek ve çoğu zaman en iyi yer bile değil .
  İş gereklilikleri teknik kaygılarınızı aşabilir. "Sana söylemiştim" deme ve işle ilgili endişelerin önceliğinin, bu tehlikeye girmiş sunucuyu ilk etapta kullanmasının nedeni olduğunu söyleme. (" İşlem sonrası rapor için bunu bırakın. ")

• Bir güvenlik olayını örtbas etmek bir seçenek değildir.

• Yerel makamlara rapor vermek.
  ServerFault yasal tavsiye için uygun bir yer DEĞİLDİR, ancak bu bir olay müdahale planına dahil edilmesi gereken bir şeydir.
  Bazı bölgelerde ve / veya düzenlenmiş endüstrilerde güvenlik olaylarını yerel yasa uygulamalarına, düzenleyici kurumlara bildirmek veya etkilenen müşterileri / kullanıcıları bilgilendirmek zorunludur.
  Ne olursa olsun, ne raporlama kararı ne de gerçek rapor yalnızca BT departmanında yapılmaz. Yönetimden ve yasal ve kurumsal iletişim (pazarlama) departmanlarının katılımını bekleyin.
  Muhtemelen çok fazla beklememelisiniz, internet sınırların çok az anlam ifade ettiği büyük bir yerdir, ancak birçok polis departmanında bulunan siber suç departmanları dijital suçları çözmekte ve suçluları adalete teslim edebilmektedir.

Sanırım her şey şurada kaynıyor:

İşine değer veriyorsan, daha iyi bir planın olsaydı ve düzenli olarak gözden geçir.

Planlamayı başaramamak başarısız olmayı planlıyor ve sistem güvenliğinden başka hiçbir yerde daha doğru değil. Ne zaman <sansürlenmiş> fan vurur, daha iyi başa hazır olurdu.

Burada geçerli olan başka bir şey (biraz klişeleşmiş) var: Önleme tedaviden daha iyidir .

Mevcut sistemlerinizi denetlemek üzere uzmanların görevlendirilmesi için bir takım önerilerde bulunulmuştur. Bunun yanlış zamanda soruyu sorduğunu düşünüyorum. Bu soru sistemin ne zaman yerleştirildiği sorulmalı ve cevaplar belgelendirilmelidir. Ayrıca, "İnsanların girmesini nasıl önleyebiliriz?" “Neden insanlar hiç giremez?” Olmalı. Ağınızdaki bir grup deliğin denetlenmesi, yalnızca yeni delikler bulunup kullanılıncaya kadar çalışacaktır. Öte yandan, temelden özenle düzenlenmiş bir dansta belirli sistemlere belirli şekillerde yanıt vermek için tasarlanan ağlar, hiç bir denetimden yararlanmayacak ve fonlar boşa gidecek.

İnternete bir sistem koymadan önce kendinize sorun - bunun% 100 internet karşısında olması gerekiyor mu? Eğer değilse, yapma. İnternetin ne göreceğine karar verebileceğiniz bir güvenlik duvarının arkasına yerleştirmeyi düşünün. Daha da iyisi, eğer söz konusu güvenlik duvarı iletimleri durdurmanıza izin veriyorsa (ters proxy veya bir tür geçiş filtresi aracılığıyla), yalnızca meşru eylemlerin gerçekleşmesine izin vermek için kullanmaya bakın.

Bu yapıldı - internette, yüklerini dengeleyici bir proxy'ye sahip bir yerde bir internet bankacılığı kurulumu yapıldı (ya da yapıldı); Güvenlik uzmanı Marcus Ranum, yalnızca bilinen geçerli URL'lerin geçmesine izin vermek ve diğer her şeyi bir 404 sunucusuna göndermek için ters proxy kullanarak onları tersine yaklaşmaya ikna etti . Zamanın testini şaşırtıcı derecede iyi bir şekilde sürdürdü.

Varsayılan izne dayanan bir sistem veya ağ, öngörmediğiniz bir saldırı gerçekleştiğinde başarısız olmaya mahkumdur. Varsayılan olarak reddetmek, ne girip girmeyeceği konusunda çok daha fazla kontrol sahibi olmanızı sağlar, çünkü olması gerekmedikçe içerideki herhangi bir şeyin dışardan görünmesine izin vermeyeceksiniz .

Bu, tüm bunların şikayetçi olmak için bir sebep olmadığını söyledi. Bir ihlalden sonraki ilk birkaç saat için hala bir planınız olmalı. Hiçbir sistem mükemmel değildir ve insanlar hata yapar.

Hoş bir çevrimiçi, son zamanlarda bir saldırganın bir sistemi nasıl tehlikeye sokabileceğini bulmamda bana yardımcı oldu. Bazı krakerler, değişiklik zamanını dosyalar üzerinde zorlayarak izlerini gizlemeye çalışırlar. Değiştirme zamanı değiştirilerek değişiklik zamanı güncellenir (ctime). Stat ile ctime görebilirsiniz.

Bu bir liner, ctime'ye göre sıralanmış tüm dosyaları listeler:

find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt

Dolayısıyla, uzlaşma zamanını kabaca biliyorsanız, hangi dosyaların değiştirildiğini veya oluşturulduğunu görebilirsiniz.