Sono attaccato o semplicemente stupido?


11

Gestisco un server usando Debian Squeeze con diversi contenitori OpenVZ. I contenitori eseguono principalmente Squeeze, alcuni Lenny e alcuni già aggiornati a Wheezy. L'host non fa molto oltre iptables e DHCP. File server, proxy, server di posta, Kerberos, LDAP, ... sono tutti messi in contenitori. Il sistema è rimasto stabile per molti anni e non ha subito cambiamenti importanti, ad eccezione di alcune regole del firewall per oltre un anno.

2 giorni fa all'improvviso il sistema si è bloccato. Ho avuto molti problemi a riaverlo. All'inizio non mi avrebbe permesso di accedere tramite ssh. il login root è stato negato da 'Non esisti. Va via!' L'accesso locale andava bene. Qualche tempo dopo ssh ha funzionato di nuovo. Per coincidenza, non ho riutilizzato la riga della cronologia di bash, ma ho digitato un nuovo comando, che è stato triplicato in modo identico alla riga, che non ha funzionato prima ma ha funzionato prima dell'incidente.

Quindi il sistema ha funzionato, ma il traffico di rete sulla maggior parte dei protocolli è stato bloccato a seguito di SYN ACK. DNS, Telnet e SSH andavano bene, ma il resto era un disastro. Dopo un paio d'ore a pescare al buio e ricaricare il firewall più volte all'improvviso, tutto è andato di nuovo bene. Non ho trovato nulla di sospetto nei registri, ma non sono un esperto forense.

Oggi l'nscd del file server è uscito dai socket per contattare LDAP a causa della quota del contenitore. Qualcosa che non è mai successo prima. Ho anche visto un sacco (> 30) di socket rivendicati da smbd.

/ var / log / messages sembrava abbastanza simile a syslog . /var/log/kern.log aveva queste informazioni aggiuntive per motivi di crash:

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

Il crash finale di "sendmail" è stato dopo il riavvio della macchina. Da allora non si sono più verificati tali eventi. 'imapd' e 'postgres' funzionano sicuramente in contenitori diversi.

Bene, non vedo nessuna pistola fumante, ma probabilmente sono solo cieco. Configurare il sistema da backup noti / presunti sarebbe un duro colpo per provarlo senza ottime ragioni.

Gradirei qualche consiglio su cosa controllare dopo.

Grazie per l'aiuto.

Aggiornamento : Mettendo più impegno nella ricerca di alcuni pre-cursori dell'incidente ho trovato quanto segue in syslog:

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)

So che questo è considerato non critico, ma sembra essere un evento raro. Il troncamento dei pacchetti esiste solo il giorno del secondo arresto anomalo. Nessun altro posto in tutti i file di registro disponibili.

Risposte:


2

Sembra DoS, molto probabilmente proveniente da Nework o dall'interno di uno dei container compromessi.

Esaminerei vmstat, lo eseguirò continuamente ogni 5 secondi: vmstat 5 e prenderei nota di dove vengono spese le risorse. Puoi anche usare lo schermo ed eseguire vmstat 60 (ogni minuto) in una finestra separata, in questo modo puoi notare picchi quando si verificano per un periodo di tempo più lungo.

In questa situazione, CPU di sistema (sy) elevata / spiking, velocità di commutazione del contesto elevata (cs) e IO elevato (mostra sia la rete che il disco) indicheranno DoS:

$ 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

Allo stesso tempo, monitorare il traffico di rete sull'host, consiglio ntop, ovvero:

$ nload -t 10000 -u H eth0

0

Sembra un errore di I / O del disco. Esegui fsck e verifica la presenza di errori.


Proverò a programmare i tempi di fermo per quello. Tuttavia, non esistono registri relativi agli errori del disco I / O da nessuna parte. O ne hai visto qualcuno?
Lars Hanke,

0

Forse non hai errori del file system, ma sono sicuro che visualizzi gli avvisi nel tuo registro, perché hai molti processi in stato D (in attesa di I / O) e il kernel ti sta informando della lunga attesa.


Immagino che sia stato così. Ma perché? In condizioni normali non ci sono processi in stato D. Se in realtà la rete non funzionasse, potrebbe spiegarlo. Ma perché dovrebbe andare giù solo per alcuni servizi? Perché quella condizione è sopravvissuta al riavvio? E perché è tornato?
Lars Hanke,

0

L'errore indica che i tuoi processi stanno aspettando troppo tempo (120 sec) per accedere ai dischi; questo accade su server molto affollati in cui i dischi sono troppo occupati per rispondere ai processi.

Puoi assicurarti selezionando "In attesa" in vmstat.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.