Beiträge von darignac

Das Installieren der Backports funktionierte, allerdings ging dann Docker usw. nicht mehr und ich konnte das auch nicht auf die schnelle Fixen.

Ich habe dann in Ruhe das Upgrade auf Debian 9 gemacht, seither läuft das System ohne Kernel Panics.

So, mittlerweile habe ich den crashdump aktiv und konfiguriert, das spart mir auch das manuelle Neustarten des Servers.

Folgende Ursache lässt sich im Dump herauslesen:

57332.329154] BUG: unable to handle kernel NULL pointer dereference at 0000000000000078
[57332.329492] IP: [<ffffffff810a6b68>] check_preempt_wakeup+0xb8/0x1d0
[57332.329719] PGD 0 
[57332.329805] Oops: 0000 [#1] SMP 
[57332.329936] Modules linked in: cfg80211 rfkill veth xt_nat ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat_ipv4 bridge stp llc aufs(C) xt_multiport ip6t_REJECT xt_hl ip6t_rt nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT xt_LOG xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables crc32_pclmul joydev evdev aesni_intel aes_x86_64 ttm drm_kms_helper drm lrw gf128mul glue_helper ablk_helper ppdev parport_pc serio_raw pcspkr cryptd parport processor virtio_balloon thermal_sys button autofs4 hid_generic usbhid hid ext4 crc16 mbcache jbd2 sr_mod cdrom sg ata_generic sd_mod crc_t10dif crct10dif_generic
[57332.332293]  virtio_net virtio_scsi crct10dif_pclmul crct10dif_common crc32c_intel ata_piix uhci_hcd ehci_hcd floppy libata psmouse usbcore usb_common i2c_piix4 virtio_pci i2c_core virtio_ring virtio scsi_mod
[57332.332293] CPU: 0 PID: 24642 Comm: runc:[2:INIT] Tainted: G         C    3.16.0-6-amd64 #1 Debian 3.16.57-2
[57332.332293] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[57332.332293] task: ffff8800675169f0 ti: ffff88013e560000 task.ti: ffff88013e560000
[57332.332293] RIP: 0010:[<ffffffff810a6b68>]  [<ffffffff810a6b68>] check_preempt_wakeup+0xb8/0x1d0
[57332.332293] RSP: 0018:ffff88013e563e50  EFLAGS: 00010002
[57332.332293] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000008
[57332.332293] RDX: 0000000000000000 RSI: ffff880052c96970 RDI: ffff8801bfc14038
[57332.332293] RBP: ffff8800baf9d1c0 R08: ffffffff816114c0 R09: 0000000000000009
[57332.332293] R10: 00000000fa83b2da R11: 0000000000000000 R12: ffff8801bfc13fc0
[57332.332293] R13: ffff8800675169f0 R14: ffff880052c97000 R15: 0000000000000000
[57332.332293] FS:  00007f0b980b4740(0000) GS:ffff8801bfc00000(0000) knlGS:0000000000000000
[57332.332293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[57332.332293] CR2: 0000000000000078 CR3: 000000015a6be000 CR4: 0000000000360770
[57332.332293] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[57332.332293] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[57332.332293] Stack:
[57332.332293]  ffffffff810a0c18 ffff8801bfc13fc0 0000000000013fc0 ffff8801bfc13fc0
[57332.332293]  ffff8801bfc13fc0 ffff880052c97004 0000000000013fc0 ffffffff8109b068
[57332.332293]  ffff880052c96970 ffffffff8109dcea 0000000000000286 00007fffffffeffd
[57332.332293] Call Trace:
[57332.332293]  [<ffffffff810a0c18>] ? sched_clock_cpu+0x88/0xa0
[57332.332293]  [<ffffffff8109b068>] ? check_preempt_curr+0x88/0xa0
[57332.332293]  [<ffffffff8109dcea>] ? wake_up_new_task+0xea/0x1b0
[57332.332293]  [<ffffffff8106b54c>] ? do_fork+0x11c/0x400
[57332.332293]  [<ffffffff8105b4fb>] ? __do_page_fault+0x1ab/0x470
[57332.332293]  [<ffffffff8153b139>] ? stub_clone+0x69/0x90
[57332.332293]  [<ffffffff8153ad9c>] ? system_call_fast_compare_end+0x1c/0x21
[57332.332293] Code: 00 00 00 83 e8 01 48 8b 5b 70 39 d0 75 f5 89 d0 39 d0 7d 17 0f 1f 80 00 00 00 00 83 ea 01 48 8b 6d 70 39 c2 75 f5 0f 1f 44 00 00 <48> 8b 7b 78 48 3b 7d 78 75 6e 48 85 ff 74 69 e8 b4 cb ff ff 48 
[57332.332293] RIP  [<ffffffff810a6b68>] check_preempt_wakeup+0xb8/0x1d0
[57332.332293]  RSP <ffff88013e563e50>
[57332.332293] CR2: 0000000000000078
[57332.332293] Shutting down cpus with NMI

Nach ein bisschen Suchen fand ich heraus, dass das ab Kernel 3.11 und bei einigen speziellen 4.x Versionen auftreten kann (Quelle 1, Quelle 2). Mein Kernel ist 3.16.0-6-amd64, liegt also nah, dass ich mal auf Debian 9 aktualisiere.

Ich hab jetzt mal Port Knocking für SSH aktiviert, das funktioniert, bringt aber für das ursprüngliche Problem nix. Danke trotzdem für den Hinweis.

Zitat von Track1991

Ich würde das auch zu erst Versuchen.

Dann müssten aber auch andere Kunden von diesen Problem betroffen sein und sich bei Netcup gemeldet haben.

Außerdem monitort Netcup alle seine Hostsysteme und so was hätte schon Auffallen müssen

Möglich ist auch das der Server eine DDOS Attacke bekommt was ich allerdings nicht glaube das es dran liegt und das ganze kann man im SCP unter Netzwerk erkennen.

Kann man in den Statisten im SCP hohe Netzwerk oder CPU Lasten feststellen?

Alles anzeigen

Netzwerk nein, sobald der Crash passiert hat die CPU exorbitante Auslastung:

Auswahl_012.png

Zitat von CmdrXay

Hay,

ich vermute da eher einen Hardwarefehler. Bei nur 2 offenen Ports (und einer ist offensichtlich ssh) ist die Angriffsfläche doch ziemlich klein. Ich würde den Netcup-Support bitten, mal nach dem Ausfall zu sehen - genauen Zeitpunkt mitliefern.

CU, Peter

Der Netcup-Support macht da leider nix, da es ein Root-Server ist und ich alleine für den verantwortlich bin.

Zitat von killerbees19

Welche Kernelversion? Distributionskernel oder selbst gebaut? Irgendwelche zusätzlichen Kernelmodule? Was läuft auf dem Server grob?

Du könntest einmal versuchen ein "Kernel Crash Dump" automatisch speichern zu lassen, um der Ursache näher zu kommen.

Kernel Crash Dump belese ich mich und richte ich gleich ein.

Zitat von vmk

Das würde ich auch vermuten. Hardware sollte ja stabil laufen und im Monitoring von netcup drin sein.

Wenn du kein Monitoring hast, mach einen cronjob mit:

*/5 * * * * top -b1 -n >> top_from_cron

Auch das richte ich ein.

Danke soweit für eure Ratschläge, ich werde weiter dran arbeiten.

Hallo zusammen!

Ich danke euch für eure Beiträge, hier meine Antworten:

Zitat von voja

Spiel alle Updates eingespielt? Hast Du den Server auch mal über das CCP komplett ausgeschaltet? Hast Du sshguard oder fail2ban laufen?

Server ist up-to-date. Ich hab ihn schon ein paar mal runtergefahren und wieder gestartet über die Zeit, das ändert nix.

Ich hab fail2ban laufen mit einem Jail auf SSH mit 5 maximalen Versuchen.

Zitat von killerbees19

Welche Kernelversion? Distributionskernel oder selbst gebaut? Irgendwelche zusätzlichen Kernelmodule? Was läuft auf dem Server grob?

Du könntest einmal versuchen ein "Kernel Crash Dump" automatisch speichern zu lassen, um der Ursache näher zu kommen.

Der Kernel ist aktuell 3.16.0-6-amd64. Das ist der Distri-Kernel und ich hab über die normalen Systemupdates schon paar Kernelaktualisierungen gemacht (da bestand das Problem auch schon). Zusätzliche Module habe ich nicht.

Auf dem Server läuft nur Docker, nginx und eine Webseite (die nicht via Docker betrieben wird).

Zitat von Track1991

Im CCP kann man den Server nicht Ausschalten sondern im SCP.

Das ist normal im Internet laufen Bot Server die versuchen andere Server per den Standard SSH Port anzugreifen.

Tipps:

1. Fail2ban Einsetzen das nach 3-5 Versuchen die IP für 24-48 Stunden in der Firewall automatisch gesperrt wird

Risiko: Der Port ist immer noch im Internet und wenn man selber 5 mal falsch Passwort oder Key verwendet ist man gesperrt und muss wieder SCP im Bildschirmmodus entsperren

2. Port 22 auf ein anderen Port vierstellig Ändern Beispiel Port 2001, die Bots versuchen immer auf Port 22 und 2222 zugreifen, weil diese Bekannt sind.

Risiko: Der Port ist immer noch im Internet und kann mit einen Port Scanner wieder gefunden werden

3. Port in der Firewall schließen nur bei Bedarf per Portknocking öffnen lassen, ist von Firewall unterschiedlich

Risiko: Der Portknocking Port kann auch per Port Scanner gefunden werden, wird aber von 99% der Bots nicht eingesetzt

4. Zugriff auf den Server nur per VPN und SSH nur im VPN Netz freigeben (Setzte ich ein)

Nachteil: Man muss erstmals eine VPN Verbindung zum Server Einrichten und Aufbauen um auf SSH zukommen

Vorteil: Port ist nicht mehr im Internet erreichbar und somit bleiben die Bots draußen.

PS: Ich nutze als Firewall Shorewall und kann mir den Log auf dem Server per tail -f ansehen und sehe dort in 2-5 Minuten Takt Zugriffe per:

SSH, RDP, FTP, und Admintools z.B. Webmin 1001

Alles anzeigen

1. hab ich

2. hab ich

3. das schaue ich mir mal an, klingt auf jeden Fall sinnvoll

4. das überlege ich mal

Zitat von CmdrXay

Hay,

ich vermute da eher einen Hardwarefehler. Bei nur 2 offenen Ports (und einer ist offensichtlich ssh) ist die Angriffsfläche doch ziemlich klein. Ich würde den Netcup-Support bitten, mal nach dem Ausfall zu sehen - genauen Zeitpunkt mitliefern.

CU, Peter

Stimmt, die kann man ja auch mal fragen

Zitat von vmk

Poste den stack trace bitte komplett. Alles andere ist Kaffeesatzleserei.

Ist es immer die gleiche Kernelpanik?

Den Stacktrace sehe ich nur im VNC, sobald der Server neu gestartet ist finde ich den in den Logs nirgends wieder.

Ich muss gestehen, dass ich die VNC-Screenshots nicht gesammelt habe, aber ich bin der Meinung das ist immer dasselbe. Werde beim nächsten Mal einen machen.

VG

Alex

Hallo zusammen,

ich betreibe einen Root-Server RS 1000 mit Debian 8. Aller x Tage fährt sich der Server mit einer Kernel-Panik fest. Ich kann ihn dann nur via Server Control Panel und "Garantierter Neustart" wiederbeleben. Das passiert unregelmäßig, manchmal läuft der Server 2 Monate sauber durch, manchmal nicht mal eine Woche.

Mir ist unklar, warum das passiert. Alle Services auf meinem Server sind so gebaut, dass der Ausfall nicht stört, aber die Downtime nervt, vor allem wenn ich es nicht schaffe mich zeitnah ins Server Control Panel einzuloggen und neuzustarten.

Die VNC Konsole zeigt folgendes:

serverfail.png

Die Logs sagen alle dasselbe (ich hab die IPs und Servername anonymisiert), das ist aus dem kern.log, syslog und messages zeigen genau dasselbe.

Aug 24 19:46:37 <SERVERNAME> kernel: [252718.933584] [UFW BLOCK] IN=eth0 OUT= MAC=<SOME-MAC-ADDR> SRC=<SRCIP> DST=<SERVERIP> LEN=442 TOS=0x00 PREC=0x00 TTL=59 ID=59108 DF PROTO=UDP SPT=6034 DPT=5060 LEN=422 
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

Das sieht jedes Mal genauso aus. Ich habe, wie zu sehen, UFW laufen und blocke alles außer 2 Ports. Im auth.log sehe ich auch, dass permanent versucht wird, sich mit dem Nutzer root einzuloggen (den gibt es aber nicht). Das ufw Log selber sagt nichts weiter.

Hat jemand eine Idee, woran das liegt und was ich da machen kann?

Besten Dank schon mal!

Viele Grüße

Alex