Beiträge von customer

  • Messen von IO Performance bzw. IOPS Performance der SSD

    VPS 500 G8

    Code
    fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test1 --filename=test1 --bs=4k --iodepth=64 --size=8G --readwrite=randrw --rwmixread=75

  • rDNS funktioniert nicht mit IPv6?

    Hallo,


    die Frage steht eigentlich schon im Thread-Titel: funktioniert rDNS nicht mit IPv6?


    Ich habe im CCP für meine IPv6 Adresse genauso einen Hostnamen angegeben wie für meine IPv4 Adresse, aber die DNS-Server liefern mir nur einen PTR Eintrag für die IPv4-Adresse.

  • Kein Login per SSH

    Zitat von Steini

    Ist das so? "klarerweise"??

    Ja, bei sicherheitsbewussten Admins schon. Das ist best practice seit vielen Jahren wie du selbst zitierst hast.


    Root user ist der erste Account den ich sperre, u.a. aus den von dir zitierten Gründen.

    Alles was mit root-Rechten ausgeführt wird auf meinen Systemen auch fein säuberlich mitgeloggt und das nicht nur aus Sicherheitsgründen.


    Das mit dem 3000+ bits RSA oder Ed25519 Schlüssel sollte auch selbstverständlich sein, denn damit hat man eine Sicherheit von 256+ bits. Auch schon seit Jahren Empfehlung.

    Natürlich kann man auch ein entsprechend langes und komplexes Passwort verwenden, aber da man sich das wahrscheinlich nicht merken kann und auch nicht händisch eintippen will, kann man auch gleich pubkeys verwenden.


    Zitat

    Ich sehe sudo also zusätzliche Software und damit zusätzlichen Angriffsvektor der (mir) keinen Sicherheitsgewinn bringt.

    Ich sehe es gegenteilig.
    Der root user ist der zusätzliche Angriffsvektor. Über den login. Ebenso über su...

    sudo verwendet auch nur pam und wenn da eine Lücke ist, dann ist sowieso schon alles egal.

    sudo ermöglicht auch noch zusätzliche Einschränkungen, die sonst nicht möglich sind bzw. mit root einfach umgangen werden könnten. Wie du richtig schreibst, ist das z. B. bei mehreren Admins äußerst nützlich.


    sudo zieht auch noch eine zusätzliche Sicherheitsschicht ein: Selbst wenn jemand Zugriff auf meinen Server mit meinem Admin-User hätte, dann bringt ihm das nichts, denn er müsste immer noch das Benutzerpasswort erraten ... und dank pam_faillock sind Brute-Force-Attacken hier ebenso unmöglich.
    Das wird natürlich auch geloggt.

    Zitat

    So denken viele User/Freizeitadmins "Hey, ich habe den Port geändert, nutze (irgendwelche) Keys und habe den Rootzugang deaktiviert, ich bin ultimativ safe".

    Aber von irgendwelchen Keys war auch nie die Rede.

    Den Port zu ändern ist nur security through obscurity, also kein echter Sicherheitsgewinn. Ich verwende den Standardport, nur ist dieser halt nur für mich offen.

    Was aber auf jeden Fall hilft, ist den Rootzugang zu deaktivieren. :P

  • SYN-Attacke abwehren (Linux)

    Seit knapp 4 Jahren (Linux 4.4) sollte der synproxy überflüssig sein, weil der Kernel in dem Bereich verbessert wurde und mit Millionen von SYN-Paketen pro Kern umgehen kann.

    Selbst Debian oldstable/9/stretch hat da schon einen viel aktuelleren Kernel, deswegen verstehe ich nicht warum das hier empfohlen wird?

  • NTP-Pool Monitoring bei IPv4 meines Server schlecht

    Tracepath:



    Sieht für mich nach schrägem Routing bei Zayo.com aus.

  • NTP-Pool Monitoring bei IPv4 meines Server schlecht

    Dragon Sorry aber da muss ich bei beiden Aussagen widersprechen.


    Ein "Ping" pro Hop aber dafür hunderte solcher Aufrufe mit Zeitstempel enthält mehr Informationen als ein Aufruf mit hunderten "Pings". (Es sind eigentlich keine Pings sondern UDP Pakete mit begrenzter TTL.)


    Zitat

    Die Verbindung sieht tendenziell aber in Ordnung aus, am letzten antwortenden Hop scheint nie ein Paket verloren gegangen zu sein. Was dazwischen passiert ist dann egal.

    Leider nicht.

    Wir wissen ja, dass es an keinen der jeweils beteiligten Server liegt, also MUSS der Fehler auf einem Hop dazwischen passieren.

    Es liegt hier klarerweise auch kein temporärer oder gar permanenter Paketverlust vor wo ab einem Hop alles verworfen wird,n ein scheinbar ganz sporadischer und vereinzelter.

  • NTP-Pool Monitoring bei IPv4 meines Server schlecht

    Mit Ziel-IP 139.178.64.4 über Zayo gibt es ebenfalls Probleme:


  • NTP-Pool Monitoring bei IPv4 meines Server schlecht

    Code
    5. 62.115.14.116       63.8%  2606   942 (ffm-b4-link.telia.net.)
6. 62.115.114.90        1.8%  2606  2560 (ffm-bb2-link.telia.net.)
   62.115.114.88                         (ffm-bb3-link.telia.net.)
7. 62.115.123.13        1.3%  2606  2571 (prs-bb3-link.telia.net.)
   62.115.122.138                        (prs-bb4-link.telia.net.)
   62.115.114.98                         (prs-bb4-link.telia.net.)
8. 62.115.114.228       5.3%  2606  2468 (ldn-bb4-link.telia.net.)
   62.115.134.93                         (ldn-bb3-link.telia.net.)
9. 62.115.113.20       24.8%  2606  1961 (nyk-bb4-link.telia.net.)

    Angabe Packet-Loss %, # gesendete Pakete, # Antworten.

  • IPv6-Adressen generieren

    Zitat von BrotherJ

    Ich habe es zumindest im CCP mit den Pefixen ::2 und ::3 hinbekommen. Schade, dass das so wenig dokumentiert ist bei Netcup.

    Meinst du das SCP? Das CCP ist eher für Leistungen und Vertragliches...


    Im SCP siehst du ziemlich schön die deiner VM zugeteilsten IPv4 und v6 Addressen bzw. Netze.



    Wie du deine Netzwerkschnittstellen konfigurierst, hängt von deiner Distribution und Konfiguration ab. Selbst wenn netcup alle Möglichkeiten dokumentieren würde - was Unsinn ist - dann müsstest du als Administrator immer noch wissen, was zu deinem System passt.

  • Netcup DHCP Server antwortet nicht auf Discovery Requests von ipconfig.

    Weiters sehe ich ipconfig schon seit vielen Jahren als deprecated an. Da wundert es mich auch nicht, wenn das eine defekte DHCP Client Implementierung hat.


    Zu den Unterschieden aus deinen Mitschnitten:

    ipconfig setzt scheinbar keine UDP checksum.

    ipconfig setzt auch nicht DHCP Option 61 oder Option 57 (maximum dhcp message size) fordert aber 5 zusätzliche Parameter gegenüber udhcpc an.

  • Netcup DHCP Server antwortet nicht auf Discovery Requests von ipconfig.

    Mal eine blöde Frage, wieso überhaupt DHCP? Sowohl IPv4 als auch IPv6 Addressen/Netze sind doch statisch den VMs zugewiesen, also sollte auch die Konfiguration entsprechender Adressen statisch sein.


    Ich habe noch nie DHCP in diesem Anwendungsfall verwendet und es wäre mir auch neu, dass Netcup oder andere Server Hoster DHCP Server betreiben. Wozu auch?



    Und wenn Debian/Ubuntu das von sich aus macht, dann ist das entweder ein Konfigurationsfehler des Administrators oder ein grober Bug.

  • DNSSEC und DANE per default!

    Sorry, das habe ich tatsächlich überlesen. Natürlich sind public keys nicht vertraulich.

    Was man jedoch braucht ist Integrität und Authentizität.


    Ach ja, Anwender, die sich wie Schimpansen verhalten würde ich erst gar nicht auf meine Server lassen. ;)

    Fehlt nur noch ein Admin, der sich genauso verhält und jeden unsicher übertragenen PubKey blind akzeptiert.

  • DNSSEC und DANE per default!

    Ja ich meine, wenn man Keys initial nicht über einen sicheren Kanal austauscht, dann hat man auch keine Authentifizierung.

    In den meisten Fällen wird es gut gehen, aber wenn dann mal was schiefläuft heißt es nur SSKM: selber schuld, kein Mitleid.


    Ist ein bisschen so, wie wenn man auf einen Link in einer Mail klickt und dann vermeintlich auf einer Webseite seiner Bank landet und sich dort dann direkt einloggt...

  • DNSSEC und DANE per default!

    Zitat von killerbees19

    Nicht zwangsläufig. Ein Angreifer könnte sich auch als MITM einklinken und sich als der Zielserver ausgeben, indem er alle Pakete zur Ziel-IP abfängt und beantwortet. Wenn er die Kontrolle über den Netzwerkverkehr hat, braucht er dir gar keinen falschen RR unterzujubeln. Letzteres alleine würde eventuell gar nichts bringen, weil das Opfer vielleicht einen eigenen Resolver am Client betreibt und diesen speziell geschützt hat. (DNSSEC, DNSCrypt, DoT, …)

    Das Unterjubeln eines falschen RR würde ja eine neue Lücke öffnen, die es vorher gar nicht gab, weil der Client dann theoretisch den SSH-Server des Angreifers (mit anderem Server-Key) blind akzeptieren könnte/würde. Aber wie danach erwähnt ergibt der RR eh nur dann Sinn, wenn der Kanal auch sicher ist - also DNSSEC.


    MITM auf IP Ebene hilft dem Angreifer bei SSH relativ wenig, eben weil die Keys zuvor durch einen sicheren Kanal ausgetauscht wurden.

  • DNSSEC und DANE per default!

    Zitat von gunnarh

    So schräg ist das nicht.


    1. lässt man nicht den Benutzern "Zugangsdaten zukommen", sondern man berechtigt die PubKeys der User sich dort anmelden zu dürfen. Somit ist da kein "sicherer Kanal" im Sinne von Vertraulichkeit nötig.


    Und die PubKeys der User bekommst du über unsichere Kanäle zugesandt, die du dann blind akzeptierst? Ich denke nicht.

    Bei SSH MUSS ein sicherer Kanal initial für den Austausch der Schlüssel verwendet werden. Sowohl von Client- als auch Server-Keys.

    Da führt kein Weg daran vorbei.


    Zitat

    2. hat das Hinterlegen von Server-Keys im DNS vor allem dann große Vorteile, wenn man sehr viele Server betreibt und / oder diese häufig (z.B. automatisiert) neu initialisiert - z.B. weil es sich um VMs, Container etc handelt.

    Wenn man viele VMs, Container, etc. wartet, dann wird man das vernünftigerweise automatisiert und über sichere Kanäle machen.

    Entsprechend kann man mit selbigen Automatisierungstools über selbige sichere Kanäle auch Keys austauschen. Musst du sowieso, wenn du dich mit PubKey einloggen willst. Entsprechend kannst du so auch die Server-Key-Fingerprints rausschreiben.


    Aber ja, wenn man stattdessen immer die DNS-RR Einträge alle aktualisiert, das richtig konfiguriert ist (DNSSEC ist hierfür eine Voraussetzung und eine hohe TTL wäre wahrscheinlich schlecht) und der Client/Resolver das auch unterstützt, dann muss man bei den Clients theoretisch nichts mehr machen.

  • DNSSEC und DANE per default!

    Ok, kurz im RFC gestöbert: dieser RR ist so gedacht, dass er über DNSSEC verifiziert wird. Ansonsten hätte man genau die Lücke geöffnet, die ich angeführt habe.

    Es wird übrigens beschrieben, dass der Client bei Übereinstimmung dann *automatisch* neue Server Keys annehmen kann.


    Schräg.

    Wenn ich schon regelmäßig neue User habe, die sich alle immer wieder zum ersten Mal auf den Server verbinden, dann kann ich ihnen den Server-Key-Fingerprint über den gleichen sicheren Kanal zukommen lassen wie die Serverdaten selbst...