Posts by customer

    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.


    Quote

    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.

    Quote

    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

    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?

    Tracepath:



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

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


    Quote

    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.

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


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

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

    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.

    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.

    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.

    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.

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

    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.

    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.


    Quote

    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.

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

    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:

    Code
    1. ip a[ddress]
    2. ip l[ink]
    3. 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.

    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.