Saldırıldım mı yoksa sadece aptal mıyım?


11

Debian Squeeze kullanarak birkaç OpenVZ konteyneri kullanarak bir sunucu çalıştırıyorum. Kaplar çoğunlukla Squeeze, bazıları Lenny ve bazıları zaten Wheezy'ye güncellendi. Ana bilgisayar iptables ve DHCP'nin ötesinde bunu yapmaz. Dosya sunucuları, proxy'ler, posta sunucuları, kerberos, LDAP, ... kapsayıcılara konur. Sistem yıllarca istikrarlı bir şekilde çalıştı ve bir yıl boyunca bazı güvenlik duvarı kuralları dışında önemli bir değişiklik yapmadı.

2 gün önce aniden sistem çöktü. Tekrar gündeme getirirken çok fazla sorun yaşadım. İlk başta ssh ile giriş yapmama izin vermedi. root girişi 'Siz yoksunuz' tarafından reddedildi. Çekip gitmek!' Yerel giriş iyiydi. Bir süre sonra ssh tekrar çalıştı. Tesadüf olarak, bash geçmişinden satırı tekrar kullanmadım, ancak üç kez kontrol edilen satırla aynı olan, daha önce çalışmayan ancak çökmeden önce çalışan yeni bir komut yazdım.

Sonra sistem çalıştı, ancak çoğu protokolde ağ trafiği SYN ACK'nın ardından engellendi. DNS, Telnet ve SSH iyiydi, ancak geri kalanı bir karışıklıktı. Birkaç saat sonra karanlıkta balık tuttuktan ve güvenlik duvarını birkaç kez tekrar yükledikten sonra aniden her şey yolunda gitti. Günlüklerde şüpheli bir şey bulamadım - ama adli tıp uzmanı değilim.

Bugün dosya sunucusunun nscd'si, kap kotası nedeniyle LDAP ile bağlantı kurmak için yuvalardan çıktı. Daha önce hiç olmamış bir şey. Ayrıca smbd tarafından iddia edilen çok fazla soket gördüm (> 30).

/ var / log / messages sistem günlüğü ile aynı görünüyordu . /var/log/kern.log kilitlenme nedenleriyle ilgili şu ek bilgilere sahipti:

/var/log/kern.log:2950:Sep 19 10:46:57 asgard kernel: [6529441.320086] INFO: task sendmail:32181 blocked for more than 120 seconds.
/var/log/kern.log:2982:Sep 19 10:48:57 asgard kernel: [6529561.324525] INFO: task kdmflush:1932 blocked for more than 120 seconds.
/var/log/kern.log:3005:Sep 19 10:48:57 asgard kernel: [6529561.324694] INFO: task xfssyncd:10162 blocked for more than 120 seconds.
/var/log/kern.log:3027:Sep 19 10:48:57 asgard kernel: [6529561.324934] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:3060:Sep 19 10:49:51 asgard kernel: [6529561.325129] INFO: task imapd:31749 blocked for more than 120 seconds.
/var/log/kern.log:3084:Sep 19 10:49:51 asgard kernel: [6529561.325248] INFO: task cleanup:32194 blocked for more than 120 seconds.
/var/log/kern.log:3106:Sep 19 10:50:57 asgard kernel: [6529681.324028] INFO: task flush-253:3:3216 blocked for more than 120 seconds.
/var/log/kern.log:3142:Sep 19 10:50:57 asgard kernel: [6529681.324224] INFO: task kjournald:6859 blocked for more than 120 seconds.
/var/log/kern.log:3166:Sep 19 10:50:57 asgard kernel: [6529681.324366] INFO: task syslogd:11720 blocked for more than 120 seconds.
/var/log/kern.log:3198:Sep 19 10:50:57 asgard kernel: [6529681.324574] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:7152:Sep 19 19:29:41 asgard kernel: [ 1440.617090] INFO: task sendmail:11892 blocked for more than 120 seconds.

Son 'sendmail' çökmesi makineyi yeniden başlattıktan sonra oldu. O zamandan beri böyle bir olay olmadı. 'imapd' ve 'postgres' kesinlikle farklı kaplarda çalışır.

Hiç sigara silahı görmüyorum, ama muhtemelen sadece körüm. Sistemi bilinen / varsayılan iyi yedeklemelerden kurmak, çok iyi nedenler olmadan denemek için beni çok zorlayacaktı.

Bundan sonra ne kontrol etmek için herhangi bir tavsiye için teşekkür ederiz.

Yardımın için teşekkürler.

Güncelleme : Bazı çökme ön imlecini aramak için daha fazla çaba koyarak syslog aşağıdakileri buldum:

Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (10490->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (17442->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (11650->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (10202->8232)
Sep 19 10:11:29 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:13:27 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:20:33 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)

Bunun eleştirel olmadığını biliyorum, ama nadir bir olay gibi görünüyor. Paket kesilmesi yalnızca ikinci kilitlenme gününde oluşur. Kullanılabilir tüm günlük dosyalarında başka hiçbir yerde yok.

Yanıtlar:


2

Bu, büyük olasılıkla neworktan veya tehlikeye atılan konteynırlardan birinin içinden kaynaklanan DoS'a benziyor.

Vmstat'a bakarım, her 5 saniyede bir sürekli çalıştırırım: vmstat 5 ve kaynakların nerede harcandığını not edin. Ayrıca ekranı kullanabilir ve vmstat 60'ı (her dakika) ayrı bir pencerede çalıştırabilirsiniz - böylece daha uzun bir süre boyunca ani artışlar görebilirsiniz.

Bu durumda yüksek / ani Sistem CPU (sy), yüksek bağlam anahtar oranı (cs) ve yüksek IO (hem ağı hem de diski gösterir) DoS'yi gösterecektir:

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0   9584   6820 132432  23256    1    1   136    12    1    1 83  1 15  0  0
 0  0   9584   6696 132432  23256    0    0     0     0   20   32  0  0 99  0  1

Aynı zamanda ana bilgisayardaki ağ trafiğini izlemek, ntop öneririz, yani:

$ nload -t 10000 -u H eth0

0

Bir Disk G / Ç hatası gibi görünüyor. Fsck komutunu çalıştırın ve hataları kontrol edin.


Bunun için çalışmama süresini planlamaya çalışacağım. Ancak, hiçbir yerde G / Ç disk hatasıyla ilgili günlük yoktur. Yoksa gördün mü?
Lars Hanke

0

Belki herhangi bir dosya sistemi hatası yoktur, ancak eminim ki günlüğünüzde bu uyarıları görüyorsunuz, çünkü D durumunda (G / Ç'yi beklerken) birçok işleminiz var ve çekirdek sizi uzun bekleyiş hakkında bilgilendiriyor.


Sanırım durum böyle. Ama neden? Normal şartlar altında D durumunda süreç yoktur. Aslında ağ düşerse, bunu açıklayabilir. Ama neden sadece bazı hizmetler için düşecek? Bu durum neden yeniden başlatıldı? Ve neden tekrar ortaya çıktı?
Lars Hanke

0

Hata, işlemlerinizin disklere erişmek için çok uzun (120 sn) beklediğini gösterir; bu, disklerin işlemlere yanıt vermek için çok meşgul olduğu oldukça kalabalık sunucularda olur.

Vmstat altındaki "Bekleyen" i işaretleyerek emin olabilirsiniz.

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.