Root-Server Kernel Panic (Debian 8)

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

    Code
    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

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

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

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

    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

  • 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

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

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

    Ich würde das auch zu erst Versuchen.



    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

    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?

  • Hay,

    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

    1) Ob andere Kunden es gemerkt haben oder es gemeldet haben, wissen weder Du noch ich. Der TE hat das Problem ja auch schon seit Monaten und ist erst jetzt im Forum präsent. Vielleicht ist er nur der erste, der sich bemerkbar macht?

    2) Auch wenn mehrere Kunden auf dem Hostsystem sind, gibt es dennoch Dir dediziert zugewiesene Ressourcen, so dass es möglich ist, dass nur bei Dir etwas durchbrennt.

    3) Netcup ist zwar schon viel selbst aufgefallen und ich vertraue deren Monitoring - aber gerade der fleißige Forenleser findet einiges, was erst hier im Forum hochgepoppt ist - z.B. wo Server auf andere Nodes verschoben werden mussten oä.


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Was hat das denn mit dem Thema zu tun ?! :cry:

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


    Ist es immer die gleiche Kernelpanik?

    "Security is like an onion - the more you dig in the more you want to cry"

  • Was hat das denn mit dem Thema zu tun ?! :cry:

    Vor allem weil ich immer über das CCP ins SCP gehe. ?


    Noch was zum Thema: in dem Dump geht es um den apic timer. Dazu ist mir noch die Kernel-Option „nolapic-timer“ eingefallen, mit der man den Timer abschalten kann um Instabilitäten zu vermeiden.

  • Hallo zusammen!

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


    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.


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


    1. hab ich

    2. hab ich

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

    4. das überlege ich mal


    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 :)


    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

  • 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

    "Security is like an onion - the more you dig in the more you want to cry"

  • */5 * * * * top -b1 -n1 >> top_from_cron


    ^^ ist korrekt. Danke für den Hinweis. Leider kann man das Posting nicht editieren :(

    "Security is like an onion - the more you dig in the more you want to cry"

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


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

    Auswahl_012.png



    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.


    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.


    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.

  • 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:


    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.

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

    Schön, dass du eine Lösung gefunden hast. Ich will dich nicht davon abhalten, dein System zu aktualisieren, was sicher eine tolle Idee ist. Aber um nur zu testen, ob ein neuer Kernel hilft, kannst du auch einfach einen aus den Backports installieren:

    Code
    echo "deb http://http.debian.net/debian jessie-backports main" >> /etc/apt/sources.list
    apt-get update
    apt-cache search linux-image #den gewünschten Kernel aussuchen
    apt-get install -t jessie-backports linux-image-4.7.0-0.bpo.1-amd64 linux-headers-4.7.0-0.bpo.1-amd64 #bzw. gewünschte auswählen, kA was es da mittlerweile gibt
    reboot
  • 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.