Bir (UNIX) üretim sunucusunu zarif bir şekilde ele geçirme ipuçları


10

Aylarca süren ihmal, e-posta alevleri ve yönetim savaşlarından sonra mevcut sistem yöneticimiz işten çıkarıldı ve "sunucu kimlik bilgilerini" bana verdi. Bu kimlik bilgileri bir kök paroladan ve başka bir şeyden oluşur: prosedür yok, belge yok, ipucu yok, hiçbir şey.

Sorum şu: boobytraps'ı geride bıraktığı varsayılarak, sunucuları olabildiğince az kesinti ile nasıl ele geçirebilirim?

Detaylar burada:

  • bodrumdaki bir sunucu çiftliğinde bulunan bir üretim sunucusu; ubuntu server 9.x muhtemelen, grsec yamaları ile (son kez yöneticiye sorduğum söylentiler)
  • tüm dahili belgeleri, dosya deposunu, wiki'leri vb. içeren bir dahili sunucu. Yine, ubuntu sunucusu, birkaç yaşında.

Her iki sunucunun yamalı ve güncel olduğunu varsayalım, bu yüzden iyi bir neden (yani üst yönetime açıklanabilir) olmadığı sürece yolumu kesmek istemem.

Üretim sunucusunun barındırdığı birkaç web sitesi (standart apache-php-mysql), bir LDAP sunucusu, bir ZIMBRA e-posta paketi / sunucusu ve çalışan birkaç vmware iş istasyonu söyleyebildiğim kadarıyla. Orada neler olduğu hakkında hiçbir fikrim yok. Muhtemelen biri LDAP ustasıdır, ancak bu vahşi bir tahmindir.

Dahili sunucuda dahili bir wiki / cms, üretim sunucusundaki kimlik bilgilerini çoğaltan bir LDAP slave, birkaç vmware iş istasyonu ve çalışan yedekler bulunur.

Sadece sunucu grubunun yöneticisine gidebilir, sunucuya gidebilir, onlara ' sudoo sunucuyu kapatmayı söyleyebilirim' diyebilirim , tek kullanıcı modunda giriş yapabilir ve onunla birlikte yoluma devam edebilirim. Dahili sunucu için aynı. Yine de bu, kesinti, üst yönetim üzgün, eski sysadmin'in bana ateş açması anlamına geliyor. işimi yapamazsın 've diğer sıkıntıları, ve en önemlisi, potansiyel olarak birkaç hafta ödenmemiş zaman kaybetmek zorunda kalacağım.

Spektrumun diğer ucunda, neler olduğunu anlamak için sunucuda kök ve inç olarak giriş yapabilirim. Sürprizleri tetikleyen tüm risklerle geride kaldı.

Ortada bir çözüm arıyorum: ne olduğunu ve nasıl olduğunu anlarken ve en önemlisi geride kalan bubi tuzaklarını tetiklemekten kaçınarak her şeyi olduğu gibi çalışmaya devam etmeye çalışın .

Önerileriniz neler?

Şimdiye kadar dahili sunucu ile 'pratik yapmayı', ağ bağlantısını kesmeyi, canlı bir cd ile yeniden başlatmayı, kök dosya sistemini bir USB sürücüsüne boşaltmayı ve eski sysadmin yolunu anlamak için bağlantısı kesilmiş, yalıtılmış bir sanal makineye yüklemeyi düşündüm. düşünme (a-la 'düşmanınızı tanıyın'). Üretim sunucusuyla aynı başarıyı çekebilir, ancak tam bir döküm birisini fark eder. Belki sadece root olarak giriş yapabilir, crontab'ı kontrol edebilir, başlatılan komutlar için .profile'ı kontrol edebilir, lastlog'u dökebilir ve akla gelen her şeyi yapabilirim.

İşte bu yüzden buradayım. Ne kadar küçük olursa olsun, herhangi bir ipucu çok takdir edilecektir.

Zaman da bir sorundur: birkaç saat veya birkaç hafta içinde tetikleyiciler olabilir. Kötü Hollywood filmlerinden biri gibi, değil mi?


5
Sisadmin neden kovuldu? Bu kazançsız bir durum gibi görünüyor. Ne yapacağınızdan ve sunucularda tam olarak ne olduğundan emin değilseniz, bu iyi bitmeyecektir.
cstamas

@cstamas sysadmin tetiklendi çünkü yaptığımız her istek için (yani posta listesine kullanıcı ekleyin veya e-posta takma adı vb. oluşturun) geçen süre t = 1 gün ile t = 2 ay ( dahil). Ve bunu asla kabul etmedi. Ayrıca burada ayrıntılara girmeyeceğim bir sürü başka kötü davranış.
lorenzog

@lorenzog şimdi mantıklı. Kolay bir iş olmayacak gibi görünüyor. Şimdiden harika cevaplar var. İyi şanslar!
cstamas

1
@serverhorror: Hayır, ben bu şirkete katılmadan önce onu işe aldılar ve şimdi yeterince iyi olmadığı ortaya çıktı. Onu daha önce tanıdığımdan 'onunla uğraşmak' görevim vardı. Varsayımlarınıza dikkat edin.
lorenzog

1
@lorenzog: Bu seninle ilgili değil. Mesele şu ki, belgelenmemiş altyapının durumunun bile gerçekleşebileceği (aslında kim olursa olsun) yöneticiler hatasıdır - dediğim gibi: sadece suç yok gözlemi (öznel bir gözlem verdi)
Martin M.

Yanıtlar:


12

Diğerlerinin söylediği gibi bu gevşek bir durum gibi görünüyor.

(Sonundan başlayarak)

  • Tamamen yeni dağıtım

Tabii ki sunucuları indirip yükleyicinin sihir yapmasına izin veremezsiniz.

Genel İşlem

  • Yedekleme sunucusu için bütçe alın (veriler için depolama alanındaki yedekleme)
  • verilerin anlık görüntülerini oluşturun ve herhangi bir şey yapmadan önce onları buraya yerleştirin
  • Yönetim tarafından imzalansın!
  • Gereksinimlerin bir listesini toplayın (VMWare örneklerini kullanan gerekli wiki, ...)
    • Yönetim ve
    • Kullanıcılardan
  • Yönetim tarafından imzalansın!
  • Liste dışı hizmetleri bir hafta boyunca kapatın ( bir seferde bir hizmet - yalnızca harici hizmetleri kapatmak, ancak aynı ana bilgisayardaki bir uygulamadan kullanılabileceğinden şüpheleniyorsanız iptables arkadaşınız olabilir)
    • Tepki yok? -> son yedekleme, sunucudan kaldır
    • Reaksiyon? -> Hizmetin kullanıcılarıyla konuşun
    • Yeni gereksinimleri ve yönetim tarafından imzalanan Geet toplayın !
  • listelenmemiş tüm hizmetler bir ay boyunca ve tepki yok? -> rm -rf $service(harsch kulağa geliyor ama demek istediğim hizmetin devreden çıkarılması)
  • yedek sunucu için bütçe al
  • her seferinde bir hizmeti yedek parçaya geçirme
  • yönetim tarafından imzalanmış olsun!
  • taşınan sunucuyu kapat (gücü kapat)
  • daha fazla insanın sana çığlık attığını öğren -> yay, artık artıkları buldun
  • yeni gereksinimler topla
  • yeniden başlat ve hizmetleri taşı
  • Bir ay boyunca peşinizden gelen kimse kalmayıncaya kadar son 4 adımı tekrarlayın
  • sunucuyu yeniden konuşlandırın (ve yönetim tarafından kapatılmasını sağlayın!)
  • tüm işlemi durulayın ve tekrarlayın.
    • yeniden konuşlandırılan sunucu yeni yedeğinizdir

Ne kazandın?

  • Tüm hizmetlerin envanteri (sizin ve yönetiminiz için)
  • Belgeler (sonuçta yönetim için bir şeyler yazmanız gerekiyor, neden düzgün yapmıyorsunuz ve sizin ve yönetiminiz için bir şeyler yapmıyorsunuz)

Orada yaptım, hiç eğlenceli değil :(

Neden yönetim tarafından imzalanmasını istiyorsun ?

  • Sorunları görünür yap
  • Kovulmayacağından emin ol
  • Riskleri açıklama fırsatı
    • Yapmanızı istemiyorlarsa sorun değil, ama sonuçta yatırımın buna değip değmeyeceğine karar vermek için yeterli girdi elde ettikten sonra karar vermeleri.

Oh, ve başlamadan önce onlara genel planı sunun, en kötü ve en iyi durumda ne olacağına dair bazı tahminlerle.

Bu olacak sen belgelere yoksa bakılmaksızın reorganizasyon çok zaman mal oldu. Arka kapıları düşünmeye gerek yok, IMHO, belgeleriniz yoksa, şirket için değer sağlayacak bir aklı devlete ulaşmanın tek yoludur.


Bu çok iyi bir bakış açısı. Teşekkür ederim. Önerilerinizi kesinlikle takip edeceğim: İşlerin yönetimden çıkarılması ve sunucuların yavaş bir şekilde yeniden konuşlandırılması. Acıtacak, ama kulağa en uygun eylem tarzı gibi gelecektir.
lorenzog

: Uygun belgeler derken bu önermek serverfault.com/questions/25404/... (ayrıca genel konuya bakın) çok iyi (en azından benim için) çalışıyor
Martin M.

4

Önceki yöneticinin kötü bir şey bıraktığına inanmak için nedeniniz var mı, yoksa sadece çok film izliyor musunuz?

Çetrefilli olmak istemiyorum, ne tür bir tehdit olduğunu ve ne kadar olası olduğunu anlamaya çalışıyorum. Şansın gerçekten ciddi bir şekilde yıkıcı bir sorunun gerçekten var olabileceğinin çok yüksek olduğunu düşünüyorsanız, başarılı bir ağ saldırısı gibi davranmanızı öneririm .

Her durumda, patronlarınız bununla uğraşırken kesinti süresinin bozulmasını istemezler - sistemde bir arıza varsa (gerçek bir hata veya rogue admin) ve tutumları gerçekçi ise, burada gerçekten bir sorun yaşama olasılığınızı değerlendirmeniz.

Başka ne yaparsanız yapın aşağıdakileri göz önünde bulundurun:

Şimdi sistem görüntüsü alın . Başka bir şey yapmadan önce. Aslında, ikinizi alın ve bir kenara koyun ve sisteminizde bir şey olup olmadığını öğrenene kadar ona dokunmayın, bu, sistemi ele geçirdiğinizde nasıl olduğunuzu gösteren kayıttır.

"2." görüntü kümesini bazı sanal makinelere geri yükleyin ve olanları araştırmak için bunları kullanın. Belirli bir tarihten sonra tetiklenen şeylerden endişe ediyorsanız, tarihi sanal makinede bir yıl ileri ayarlayın.


En iyi şartlara katılmadığımız için gizlenen bir şey olabileceğinden şüphelenmek için nedenlerim var. Önceki sysadmin iyi bir arkadaştı, kolej sırasında oda arkadaşıydık ve yazılım geliştirme ve proje yönetimi yolunda ilerlerken sysadmin olmak için kullandığı püf noktalarının çoğunu "ona öğrettim". İlgili kişisel duygular olduğu için (beni kovulmayı başarmıştı) makul bir davranış bekleyemem. Oğlunun bir dereceye kadar babasına olan iyiliğini kanıtlamak istediği bir baba / oğul ilişkisi olarak ele alın.
lorenzog

4

Her şeyden önce, buna fazladan zaman ayıracaksanız, aslında bunun için ödeme almanızı tavsiye ederim . Öyle görünüyor ki, ödenmemiş fazla mesaiyi bir gerçek olarak kabul ettiniz, kelimelerinizden yola çıkarak - bu şekilde olmamalı, bence, ve özellikle bir başkasının hatası yüzünden (bu yönetim, eski sysadmin veya muhtemelen her ikisinin bir kombinasyonu).

Sunucuları indirin ve root girişinde çalışan komutları kontrol etmek için tek kullanıcı moduna (init = / bin / sh veya grub'ta 1) önyükleme yapın. Kesinti süresi burada gereklidir, yönetime, verilerini saklayacaklarından emin olmak istedikleri bir süre dışında bir seçenek olmadığını açıklayın.

Daha sonra yasal görünseler bile tüm cronjobs'a bakın. Ayrıca, yedeklemeler anlamına gelse bile tam yedeklemeleri mümkün olan en kısa sürede gerçekleştirin. İsterseniz tam yedeklemelerinizi çalışan VM'lere dönüştürebilirsiniz.

O zaman ellerinizi yeni sunuculara veya yetenekli sanal makinelere götürebilirseniz, hizmetleri tek tek yeni, temiz ortamlara geçiririm. Algılanan kesinti süresini en aza indirmek için bunu birkaç aşamada yapabilirsiniz. Temel sistemlere olan güveninizi geri kazandırırken, hizmetler hakkında çok fazla derinlemesine bilgi edineceksiniz.

Bu arada chkrootkit olarak araçları kullanarak rootkit'leri kontrol edebilirsiniz . Eski yöneticinin kullanabileceği güvenlik açıklarını aramak için sunucularda nessus'u çalıştırın .

Düzenleme: Sanırım ben de senin sorunun "incelikle" bir parçası ele vermedi. İlk adım (giriş tuzaklarını kontrol etmek için tek kullanıcı moduna girme) muhtemelen atlanabilir - size kök şifresini veren eski sysadmin ve bunu yapmak için giriş ayarı yapmak, rm -rf /tüm dosyaların silinmesinin hemen hemen aynı olacaktır, bu nedenle muhtemelen bunu yapmanın bir anlamı yok. Yedekleme kısmına göre: rsyncilk yedeklemenin çoğunu çevrimiçi yapabilmeniz ve çalışmama süresini en aza indirebilmeniz için temel bir çözüm kullanmayı deneyin .


0

Bu sunucularda hangi uygulamaların çalıştığını öğrenmek için zaman harcayacağım. Ne olduğunu öğrendikten sonra herhangi bir zamanda yeni bir sunucu yükleyebilirsiniz. Bazı arka kapılar olabileceğini düşünüyorsanız, sadece tek modda önyükleme yapmak veya sunucular ile harici ağ arasında bazı güvenlik duvarlarına sahip olmak iyi bir fikir olacaktır.


0

Güvenlik konusunda paranoyak oluyorsunuz. Paranoyak olmaya gerek yoktur. (çünkü bubi tuzaklarından bahsediyorsun). Yüklü yazılım listesini gözden geçirin. Hizmetin ne olduğunu görün (netstat, ps, vb.), Cron işlerine bakın. Hesabı silmeden önceki sys yönetici kullanıcı hesabını devre dışı bırakın (kabuğu nologin'e yönlendirerek kolayca yapabilirsiniz). Günlük dosyalarına bakın. Bu adımlarla ve sunucuların kullanımını tahmin edebileceğiniz şirket ihtiyaçları hakkındaki bilginizden düşünüyorum, bence bunları büyük bir aptallık olmadan koruyabilmelisiniz.


1
İlk etapta güvenlikle ilgili olmadığına katılıyorum (aksi takdirde eski yöneticiyi işe almamalıydılar). Ancak bu, kişinin ne kadar değer katabileceği ile ilgilidir. Geri kalanlar hakkında tamamen aynı fikirde değilim. Bazı şeyleri yönetmek için envanter olmadan aklı başında bir yolu yoktur. Kullanıcı bir süre sonra gelip size vuracaktır çünkü daha önce hiç duymadığınız bir şey çalışmayı durdurdu. Sonuçta, her kullanıcı görünür hizmetinin arkasında oldukça fazla altyapı var. Ve bu hizmetlerle ilgili belgeler bile yok ...
Martin M.
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.