.LNX-WORLD

Quelle: Wikimedia

Chrony gleicht die Systemzeit Schritt für Schritt an, nicht auf einen Schlag!
Die Systemzeit aktuell zu halten ist gerade bei Servern sehr wichtig! Die Gründe dafür habe ich ja bereits in meinem Artikel über den NTP Server beschrieben:

Viele Webserver (oder Rootserver) sind auf eine genau laufende Uhrzeit angewiesen, um aussagefähige Logfiles (Beispielsweise Zugriffsstatistika der Webseiten oder Systemlogfiles für die Fehleranalyse) schreiben zu können. Leider laufen die Systemuhren (Hardwareclock) nicht sehr genau und haben bereits nach einigen Wochen relativ grosse Abweichungen zu verzeichnen. Vergisst man gelegentlich die Uhr/Zeit zu stellen, kann man sich da schon einige Unschönheiten einfangen.

Leider hat der NTP Daemon einen unschönen Nachteil – bei Zeitdifferenzen aktualisiert er die Uhrzeit auf einen Schlag! Das mag meist keine Auswirkungen haben, jedoch wird es dann haarig, wenn man auf ein von der Zeit her sauberes Logfile angewiesen ist. Oder Cronjobs nun durch den “Zeitsprung” evtl. übersprungen werden, eben weil die Zeit auf einen Schlag korrigiert wurde, sei es auch nur ein 1min Sprung. Hier kann chrony Abhilfe schaffen. Chrony arbeitet lokal auf dem aktuell zu haltendem Server / System und passt bei Zeitdifferenzen zu den eingetragenen NTP Zeitserver Quellen die Zeit Stück für Stück sanft an. Logfiles sind so zumindest im chronologischem Ablauf wieder nachvollziehbar, Zeitgesteuerte Aufgaben, also Cronjobs, werden keinesfalls übergangen.

Für meinen Webserver habe ich mich jedenfalls für Chrony entschieden und meinen lokalen NTP Server deaktiviert – eben weil ich keinesfalls meine Backupjobs übersprungen wissen möchte. Chrony ist in den Repositorys von Debian und Ubuntu enthalten und lässt sich auf diesen Systemen entsprechend einfach auch installieren:

aptitude install chrony

Die Konfiguration von Chrony liegt unter /etc/chrony/chrony.cfg – hier brauch man, sofern man die Liste der Referenzzeitserver nicht anpassen möchte, nichts mehr dran machen, da passt eigentlich alles schon gut zusammen. Fehlt also nur noch:

/etc/init.d/chrony start

Fertig, die Zeitsynchronisation eures Debian Linux (oder welches Derivat ihr habt) sollte nun problemlos und dauerhaft laufen!

Weitere Links zum Thema:

• Chrony Home
• LNX-WORLD: Zeitsynchronisation unter Debian Linux mit NTP
• LNX-WORLD: VMware Tools unter Debian Etch installieren
• LNX-WORLD: VMware Tools Zeitsynchronisation ohne GUI
• Hilfe, bei mir tickt es nicht richtig
• Adminlife – Chrony

VMware: In einer virtuellen Maschine lässt sich mit der VMware Toolbox die Zeitsynchronisation ganz einfach mit einem kurzen Haken setzen. Leider gilt diese einfache Konfiguration der Zeitsynchronisation in der VMware nur für Windows Gastsysteme, oder Linux Systeme welche das X11 System nutzen. Fast alle meiner virtuellen Maschinen, welche ich unter VMware betreibe sind allerdings Linuxsysteme ohne X11 System.

Dennoch lässt sich hier die Zeitsynchronisation für die virtuelle Maschine aktivieren, sofern man weiß wie die aktuelle Einstellung ist. Continue reading ‘VMware: Zeitsynchronisation in VM´s per Kommandozeile’ »

SSH absichern – ich sagte es schon in Teil 1 dieser Reihe – dies ist etwas, dass jeder der Linux Server betreibt (egal ob in einem Firmennetzwerk, direkt über das Web erreichbar, oder beides) mit als erstes in den Angriff nehmen sollte.

In diesem Teil 2 der Reihe “SSH absichern” gehe ich auf einen Punkt ein, welcher oftmals schlicht unterschätzt wird: Den SSH Port ändern! Wenn man im Mittelalter nicht wollte, dass jemand einen Schatz fand, bzw. einen geheimen Ort, dann wurde dieser versteckt. Genauso funktioniert das gute alte Kinderspiel des Versteckens.

Was damals funktionierte, tut auch heute noch seine Wirkung! Denn beim den simplen Portscans auf offene SSH Zugänge wird meist nur nach dem default Port von SSH gesucht, dem Port 22. Was nun wenn der Server bei Anfragen auf den SSH Port 22 ganz simpel nicht antwortet? Meist fliegt man aus der Liste der Server die per Script und Brute Force angegriffen werden sollen, zumindest ist dies mein Ergebniss aus den Erfahrungen der Vergangenheit. Continue reading ‘SSH absichern – Teil 2 – SSH Port ändern’ »