Beiträge von customer

Wenn du schon mit domain name anstatt IP verbindest und wenn dir ein Angreifer eine andere IP Adresse unterjubeln kann, weil DNS schlecht konfiguriert ist, dann wird er dir wahrscheinlich auch einen gefälschten DNS-RR unterjubeln können.

Und selbst dann lehnt ein normaler SSH Client die Verbindung ab .. außer der SSH Client würde den gefälschten DNS-RR lesen und ihm vertrauen, dann würdest du in eine Falle tappen, die dieser Mechanismus erst möglich macht.

Wenn der Angreifer hingegen Zugriff auf deine Keys hat, dann hast du sowieso schon verloren. Da ist DNS dann auch schon irrelevant.

Wie gesagt, ich verstehe den Sinn nicht, aber vielleicht habe ich etwas übersehen?

Trust wird bei SSH über Server/Client Keys hergestellt.

Manche DNS-RR für Mail Server existieren ja auch nur, weil das Protokoll kaputt ist und z.B. vom Client ein Downgrade von TLS auf keine Verschlüsselung machen kann.

Ach ja, noch eine pedantische Anmerkung: ifconfig ist nun wirklich schon arg veraltet. Stattdessen sollte man:

ip a[ddress]
ip l[ink]
ip r[oute

etc. verwenden. Arch hat net-tools sogar schon vor 8 Jahren deprecated.

Und je nachdem wie man mit dem Internet verbunden ist, kann es durchaus sein, dass ein Interface am Rechner eine oder sogar mehrere global routbare IPv4/6 Adressen hat.
Das hat aber nichts mit Linux oder Windows zu tun.

Zitat von R60

Genau solche Seiten habe ich dann meistens auch genutzt. Was mir aber dort schon in 90% der Fälle fehlt, ist die Möglichkeit den Standort der IP zu ermitteln und vor allem meine Daten zu speichern. Da ganze ist mir im Zusammenhang mit vpn's sehr wichtig um zu sehen ob der Standort stimmt.

Das Arbeiten mit einer API ist darüber hinaus natürlich für Projekte auch schöner.

Für Linux Systeme brauchst du ja so externe Seiten überhaupt nicht, Dank ifconfig etc bekommst du auch deine externe IP + noch mehr Infos.

Dabei muss ich anmerken, dass nur, weil die IP stimmt, das noch lange nicht bedeutet, dass man sicher ist.

Gerade Browser können auf verschiedenste Arten leaken oder über die IP hinweg getrackt werden, weswegen man das eigentlich auch mit dem Browser überprüfen muss.

Siehe zB ipleak.net.

Für DNS gibt es zB www.dnsleaktest.com

Browser tracking: panopticlick.eff.org oder amiunique.org

Selbiges muss man auch für alle anderen Anwendungen prüfen, wenn man nicht identifiziert/verfolgt werden möchte.

Die Frage ist auch, warum du überhaupt überprüfen musst, ob der Standort stimmt. Wenn dein System richtig eingerichtet ist, dann hat es auch nur Internetzugriff, wenn die VPN-Verbindung steht und dann auch nur über den Tunnel.
Wenn der VPN-Provider dir dann Konfigurationen für Länder A, B, C gibt und du nach dem Verbinden verwundert feststellen msust, dass du stattdessen in den Ländern X, Y und Z gelandet bist, dann würde ich sofort den Provider wechseln.

Denn das ist entweder grobe Inkompetenz oder aber der Provider wurde kompromittiert.

Welchen Nutzen soll denn SSHFP haben?

All diese extra DNS-RR sind doch nur Hacks für ein kaputtes Protokoll.

Weil die Intel-CPUs der letzten 10 Jahre sicherheitstechnisch alle (na gut, fast, es gibt Ausnahmen wie Intel Atom) defekt sind, sollte man Intel Hyperthreading eigentlich eh immer deaktivieren, besonders in virtualisierten Umgebungen.

Das Zertifikat scheint ungültig zu sein.

Für einfache Ermittlung der externen IP nehme ich: ipecho.net/plain

Es gibt hunderte Alternativen.

Nächster zufälliger Tipp bezügl. PHP-Performance: Opcache.

Zuerst einmal sollte eine aktuelle PHP-Version laufen. 7.1 wird schon nicht mehr aktiv unterstützt und Sicherheitsupdates werden auch mit 1. Dez 2019 eingestellt.

Siehe: https://www.php.net/supported-versions.php

Da PHP eine Skriptsprache ist, muss der Quelltext bei jedem Aufruf neu interpretiert/optimiert/übersetzt werden. Genau da hilft der Opcache, indem er das Ergebnis zwischenspeichert und somit beim nächsten Aufruf all die zuvor genannten Schritte entfallen können.

Dazu kommt in die php.ini:

zend_extension=opcache

[opcache]
opcache.enable=1

; wenn ihr php Skripts auch über das CLI ausführt:
opcache.enable_cli=1

; abhängig von der Menge an PHP-Code sowie verfügbarem RAM (beides in MiB!):
opcache.memory_consumption=256
opcache.interned_strings_buffer=16

; wir wollen, dass bei Änderungen an den php Dateien der opcache automatisch invalidiert wird
opcache.validate_timestamps=1

; wie oft soll das überprüft werden? (Angabe ist KEINE Frequenz, sondern 1/Frequenz! Beispiel: 5 bedeutet nach einem Check müssen mindestens 5 Sekunden vergehen, bis wieder gecheckt wird)
opcache.revalidate_freq=5

; brauchen manche Frameworks, ansonsten kann man es deaktivieren
opcache.save_comments=1

Dann php-fpm oder Apache oder was auch immer ihr verwendet neu starten.

Anschließend kann man sich ein buntes PHP opcache status Skript installieren, wie zB opcache-gui, oder man macht einfach folgendes in eine php Datei:

<!DOCTYPE html>
<html lang="en">
  <head><meta charset="utf-8" /><title>opcache status</title></head>
  <body><pre><?php var_dump(opcache_get_status(true)); ?></pre></body>
</html>

Dort sieht man dann ob der opcache aktiviert ist (opcache_enabled), Speichernutzung (used_memory), Trefferrate (opcache_hit_rate), sowie eine Liste aller Dateien, die im opcache liegen.

Nächster Tipp: einfache Systemüberwachung mit glances.

Die meisten Distros bieten ein gleichnamiges Paket an. Also mit Paketmanager installieren und starten:

$ glances

So sieht es dann im Terminal aus:

screenshot-wide2.jpg

Sieht auf den ersten Blick wie ein htop gekreuzt mit Funktionen aus dstat aus, bietet jedoch auch eine API, Web-UI, sowie Exportmöglichkeiten.

Dokumentation: https://glances.readthedocs.io/en/latest/

Steini Das ergibt für mich keinen Sinn.

ls gibt nur den Inhalt des aktuellen Ordners aus, und dessen Ausgabe sollte nicht zum Scripten verwendet werden.

sed sollte unnötig sein, weil wir einfach .. anhängen können.

Sollte es nicht eher so aussehen?

find . -type d -name ".git" -print0 -prune | xargs -0 -P10 -I{} git -C "{}/.." pull

Mir reicht dazu mit bash das Paket

bash-completion

... dann einfach TAB spammen.

Es ergibt auch Sinn in seine ~./bashrc häufig verwendete Befehle samt Optionen als Aliase zu definieren, z.B.:

alias la='ls -lah --color=yes'

Aber dazu mehr in einem anderen Beitrag...

Hallo,

mit diesem Thema möchte ich eine kleine Sammlung von Technik-Tipps für Systemadministratoren starten.

Ich bitte darum Antworten - sofern sie keine Tipps sind - kurz und technisch zu halten.

Dann fange ich mal an...

Wie wir hoffentlich alle wissen leiden SSDs unter Leistungsverlust, wenn im Dateisystem Dateien verkleinert oder gelöscht werden. Das hat auch negative Auswirkungen auf die Lebensdauer der Flash-Zellen.
Abhilfe schafft der "neue" ATA-Befehl TRIM, welche das Betriebssystem an den SSD-Controller schickt, um der SSD mitzuteilen, welche Blöcke verworfen (discarded) und für das Neubeschreiben vorbereitet werden können.

Zuerst schauen wir, ob unsere SSDs TRIM unterstützen. Hier steht DISC für discard und Werte > 0 deuten auf Unterstützung hin:

$ lsblk --discard
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0        4K       1G         0
├─sda1        0        4K       1G         0
└─sda2        0        4K       1G         0
sr0           0        0B       0B         0

Moderne Linux-Distributionen bieten einen entsprechenden systemd service und systemd timer oder cron job:

# systemctl enable fstrim.timer

$ systemctl list-timers
NEXT                          LEFT          LAST                          PASSED     UNIT                         ACTIVATES
Mon 2019-09-02 00:00:00 CEST  1 day 2h left n/a                           n/a        fstrim.timer                 fstrim.service

Man kann den service auch manuell starten:

# systemctl start fstrim.service

Status/Ergebnis/Log ein paar Sekunden später:

# systemctl status fstrim.service
● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
   Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled)
   Active: inactive (dead) since Sat 2019-08-31 20:59:57 CEST; 28min ago
     Docs: man:fstrim(8)
 Main PID: 30948 (code=exited, status=0/SUCCESS)

Aug 28 23:47:09 xserv systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Aug 28 23:47:10 xserv fstrim[25419]: /: 31.5 GiB (33799159808 bytes) trimmed on /dev/sda2
Aug 28 23:47:10 xserv systemd[1]: fstrim.service: Succeeded.

Neben diesem periodischen TRIM (auch "batch discard") sei auch noch kontinuierliches TRIM (auch "online discard") erwähnt, was jedoch in den meisten Fällen nicht empfohlen wird.

Dies wird mit der Option "discard" in /etc/fstab oder direkt im Dateisystem aktiviert.

Hatte vorgestern Abend noch den Support angeschrieben und die haben dann die VM auf einen anderen Server verschoben.

Mir ist völlig bewusst, dass diese Leistung nicht immer/konsistent zur Verfügung steht, aber wenn selbst leichteste Last (ein paar Services die herumidlen, <0.5% auf nur einem Kern) ein loadavg von 0.3 bis über 0.5 verursachen, dann stimmt etwas nicht.

Genauso bei SMT. Wenn bei einer zwei VCore VM die Leistung mit zwei Prozessen/Threads schlechter ist als mit einem, dann stimmt etwas nicht.

Seit dem Verschieben ist die Performance jetzt vergleichbar mit dem was andere Kunden gepostet haben. Gut, warum nicht gleich so?

Zitat von Kraeutergarten

VPS mit 1Core von Hxxxner https://browser.geekbench.com/v4/cpu/14422435

Das sind +50% bis +60% gegenüber meinem "2 Kern" VPS 500 G8 so wie er jetzt läuft.

Regulärer VPS 500.

Wieder dasselbe Produkt zu buchen sehe ich nicht als eine sinnvolle Option. Da wechsle ich vorher lieber zu einem anderen Provider.

Habt ihr irgendwelche Ideen woran es liegen könnte?
Selbst wenn das Hostsystem ausgelastet ist, dann sollte doch bei 2 VCores das Multi-Core Ergebnis höher sein.

Zitat von Lukay

So wie ich das verstanden habe, ist das der "Abstrich", den man bei den VPS servern macht.

Keine Garantierte CPU und CPU Leistung. In der Produktbeschreibung steht ja auch nur "vCore".

Ich denke mal Netcup verwendet hier gerade die CPUs die zum Zeitpunkt des Kaufes am günstigsten sind?

1 vCore zum Preis von 2? Ich denke nicht, dass das normal ist.

Immer noch nicht besser:

https://browser.geekbench.com/v4/cpu/14420654

... 4,30 €/Monat

Unverändert mit LTS Kernel:

Linux xserv 4.19.67-1-lts #1 SMP Fri Aug 16 10:30:45 CEST 2019 x86_64 GNU/Linux

https://browser.geekbench.com/v4/cpu/14414875

Richtig, ist ein frisch installiertes Arch Linux.

Irgendwelche Ideen warum sich mein System so verhält, als hätte es nur eine CPU?

Es läuft kaum etwas auf der VM, htop zeigt meistens <1% Auslastung.

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 6
model name      : QEMU Virtual CPU version 2.5+
stepping        : 3
microcode       : 0x1
cpu MHz         : 2399.994
cache size      : 16384 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 ht syscall nx lm rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave hypervisor lahf_lm cpuid_fault invpcid_single ssbd ibrs ibpb invpcid md_clear
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips        : 4801.98
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 6
model name      : QEMU Virtual CPU version 2.5+
stepping        : 3
microcode       : 0x1
cpu MHz         : 2399.994
cache size      : 16384 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 ht syscall nx lm rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave hypervisor lahf_lm cpuid_fault invpcid_single ssbd ibrs ibpb invpcid md_clear
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips        : 4801.98
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3944         139        3201         154         603        3426
Swap:          4095           0        4095

Liegt es vielleicht an den Intel CPU Bugs? Aber selbst wenn ich im kernel mit mitigations=off boote ändert sich nichts.

Hallo,

habe seit kurzem einen VPS 500 G8 (mit 2 Kernen).

Ein kurzer Benchmark zeigt aber, dass die Multi-Core Leistung niedriger ist als die Single-Core Leistung... wie, wenn die VM nur einen CPU-Kern hätte.

https://browser.geekbench.com/v4/cpu/14413488

Also den Support angeschrieben.. der meinte ich sollte den Test im Rettungssystem wiederholen. Da war das Ergebnis besser. Nach dem Reboot war es auch im Echtsystem besser (das war aber am Vormittag)... und jetzt ist es wieder schlechter.

Wer es selbst testen möchte, der kann gerne folgenden Einzeiler verwenden:

wget "http://cdn.geekbench.com/Geekbench-4.3.3-Linux.tar.gz" && tar xzf Geekbench-4.3.3-Linux.tar.gz && cd Geekbench-4.3.3-Linux && ./geekbench4

und dann den ersten Link hier reinkopieren.

Vielleicht hängen zu viele Kunden auf dem Server? Vielleicht ist das ganze auch zeitabhängig? Oder aber es liegt an meiner Konfiguration... wobei ich nicht wüsste was da falsch sein könnte.