Beiträge von KB19

  • Probleme mit Nextcloud

    Naja, es ist aber auch nicht sonderlich intelligent, wenn man absolute Pfade in Konfigurationsdateien abspeichert. PHP würde den Pfad selbst bilden können, wenn es notwendig wird. Da ist Owncloud/Nextcloud schon ein bißchen selbst schuld daran! ;)



    MfG Christian

  • Das längste Thema

    Vielleicht hilft Dir meine Konfiguration weiter, pick Dir einfach mal was raus:


    Code
    smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDB3-SHA, KRB5-DES, CBC3-SHA
smtp_tls_exclude_ciphers  = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDB3-SHA, KRB5-DES, CBC3-SHA
smtpd_use_tls=yes
smtpd_tls_auth_only = yes
smtp_tls_security_level = may
smtpd_tls_security_level = may


    Du könntest auch einmal as Loglevel erhöhen: (höher als 1)


    Code
    smtpd_tls_loglevel = 1
smtp_tls_loglevel = 1


    Und teste es einmal damit: Mailserver überprüfen (STARTTLS und TLS Check) · SSL-Tools

  • Sehr hohe CPU auslastung.

    thomas: Der TE hat doch schon neu installiert?


    Wobei ich mich trotzdem Frage, ob das das Leck war. Der Prozess lief offenbar als root. Der Angreifer müsste somit entweder das Root-PW von innen erraten haben oder einen Root-Exploit ausgenutzt haben. Vielleicht war auch die aktuelle Kernellücke mitschuld?



    MfG Christian

  • Das längste Thema

    traceroute -6 ... ergibt den gleichen Fehler?


    traceroute(6) ist normalerweise in mehreren Paketen enthalten, in unterschiedlichen Implementierungen. Probiere einmal ein anderes aus. Ich erinnere mich dunkel, dass da irgendwas "optimiert" wurde bei Debian und/oder Ubuntu.

  • I/O error: hostbyte=DID_TIME_OUT

    Tja, war kein Einzelfall:


    Code
    Oct 21 06:55:35 vmx kernel: [1421616.804055] sd 0:0:0:0: [sda] abort
Oct 21 06:57:07 vmx kernel: [1421708.887433] sd 0:0:0:0: [sda] Unhandled error code
Oct 21 06:57:07 vmx kernel: [1421708.887445] sd 0:0:0:0: [sda]  
Oct 21 06:57:07 vmx kernel: [1421708.887452] sd 0:0:0:0: [sda] CDB: 
Oct 21 06:57:07 vmx kernel: [1421708.887467] end_request: I/O error, dev sda, sector 83677168
Oct 21 06:57:07 vmx kernel: [1421708.888248] sd 0:0:0:0: [sda] abort
Oct 21 06:57:07 vmx kernel: [1421708.888536] EXT4-fs (sda3): discard request in group:140 block:12542 count:2039 failed with -5
Oct 21 06:57:07 vmx kernel: [1421708.902367] sd 0:0:0:0: [sda] abort



    In beiden Fällen zeigt auch das Monitoring interessante Werte an:


    diskstats_latency-pinpoint=1476990000,1477378800.png


    Ich habe jetzt einmal das Online-Discard für alle Partitionen deaktiviert und werde es weiter beobachten.



    MfG Christian

  • IPv6: UFW blockt pings

    Probier mal static statt auto. Wenn das auch nicht klappt, bin ich überfragt. Dann könntest Du es zum Test noch manuell je IP mit dem "ip neigh" Befehl versuchen, wie im vorherigen Link erklärt.


    IP-Forwarding hast Du für IPv6 ja schon aktiviert, oder?

    Code
    sysctl sys.net.ipv6.conf.all.forwarding=1


    Eventuell möchtest Du die (IPv6) Firewall zum Test einmal deaktivieren?



    MfG Christian

  • IPv6: UFW blockt pings

    Nein, weil Du das dem netcup Router beibringen müsstest. Und der wird nicht auf Dich hören, solange Du keine NDP-Antworten zurückschickst! :) Bei zusätzlich gebuchten /64-Subnetzen besteht dieses Problem übrigens nicht, die sind nämlich geroutet und landen sowieso immer in Deiner VM.


    ndppd habe ich kürzlich für Debian 8 kompiliert, das gibt es sonst nämlich erst ab Debian 9 in den Repos. Bei Interesse bitte PN, dann schicke ich eine ausführlichere Anleitung zum Einbinden.


    Bei OpenVPN könntest Du alternativ auch ein Script nutzen, das entsprechende ndp_proxy-Regeln erstellt. In Deinem Link findest Du mehr Informationen: Routing public ipv6 traffic through openvpn tunnel - Unix & Linux Stack Exchange (Short answer ODER Dynamic NDP proxy with OpenVPN hooks)



    MfG Christian

  • IPv6: UFW blockt pings

    Ich vermute einmal, dass Du ndp_proxy oder ndppd einrichten musst. Das standardmäßig enthaltene Subnetz ist nicht geroutet, Dein Server muss also auf die Suchanfragen vom Router reagieren.


    Verifizieren kannst Du meine Vermutung mit nachfolgendem Befehl:

    Code
    tcpdump -n -l -i eth0 -v icmp6


    Dann ruf am Client mit der IPv6-Adresse einmal ping6 o.ä. auf. Sollten nur lauter Neighbor Solicitations für die Client-IP auftauchen, aber keine Neighbor Advertisements, liege ich richtig.



    MfG Christian

  • IPv6: UFW blockt pings

    Code
    # z.B. IPv6 bei irgendwas erzwingen:
wget -O /dev/null -6 https://fnx.li/


    Das Ziel sollte natürlich IPv6 unterstützen, sonst wird das logischerweise nichts! :D


    Ich kann mir aber nicht vorstellen, dass das klappt. ICMPv6 ist für jegliche IP-Kommunikation erforderlich, es wird ja kaum nur am Ping scheitern.



    MfG Christian

  • [Warnung/Erinnerung] Benutzt SSH Keys!

    Wenn man die Keyfiles mit einem Passwort schützt, ist es eigentlich fast egal, ob diese in der Cloud abgelegt werden. Meine liegen am NAS, über mein VPN kann ich mir jederzeit fehlende auf z.B. Handy oder Notebook herunterladen. (Und eine Passphrase sollten Keyfiles immer haben, außer für automatisierte Aufgaben über Scripte!)


    Ich finde Keyfiles extrem praktisch. So muss ich mir nur die Passphrase merken. Am Smartphone bzw. Tablet verwende ich VX Connectbot, dort werden sie einwandfrei unterstützt. Und auf fremden Rechnern würde ich niemals eine SSH-Verbindung zu meinen Servern herstellen! Das ist meiner Ansicht nach eine der schlimmsten Aktionen, die man machen kann. Würde bei mir aber sowieso nicht gehen, weil SSH nur über das VPN erreichbar ist.



    MfG Christian

  • Netzwerk für Container LXD / OpenVZ mit eigener IP auf Netcup Root Server KVM

    Zitat von voja

    hat es eigentlich jemand mal hinbekommen die IPv6 Adressen aus dem /64 direkt an die Container zu verteilen?


    Könnte es an NDP scheitern? Häng Dich mal mit "tcpdump -n -l -v -i eth0 icmp6" dran und beobachte, ob auf die Neighbor Solicitations überhaupt ein Neighbor Advertisement von Deiner VM folgt.


    Ich weiß nicht, wie das bei LXD oder OpenVZ gehandhabt wird, aber vielleicht braucht man da auch etwas wie ndppd oder wenigstens ndp_proxy. Das standardmäßig enthaltene /64 ist nämlich nicht geroutet!



    MfG Christian

  • Das längste Thema

    Zitat von killerbees19

    Ich glaube, spätestens jetzt muss ich mich endlich mit Lets Encrypt und der DNS-Challenge beschäftigen. Lange genug vor mir her geschoben.


    Die letzte Testphase meines Setups läuft zwar noch, aber es sieht bisher sehr gut aus. Wurde auch Zeit, in ungefähr zwei Wochen laufen meine ersten St***SSL-Zertifikate aus… 8|


    Dank getssl und der API meines Domainregistrars läuft es ohne jegliche Änderung auf den Zielservern von einer zentralen VM aus. Mal abgesehen von OCSP-Stapling, dafür muss ich einmalig Änderungen im jeweiligen vHost vornehmen. Danach aber nie wieder, weil ich das auf eine neue Struktur umstelle, wo es ebenfalls von getssl mit aktualisiert wird.


    Einen kleinen Haken hat das Setup noch: Wenn der Zielserver nicht erreichbar ist, wird das Zertifikat wahrscheinlich erfolgreich angefordert, kann dort aber nicht installiert werden. Einen erneuten Versuch gibt es nicht. In diesem Fall bleibt mir nur die Benachrichtigung vom Cron-Daemon per E-Mail, woraufhin ich händisch eingreifen muss. Mal sehen, ob ich dafür noch eine simple Lösung finde… Wenn ich den Sourcecode richtig interpretiert habe, versucht er es beim nächsten Cron-Durchlauf (oder eben manuell) einfach nochmals zum hinüber Kopieren. Das Problem ist somit keines, da der Autor dran gedacht hat. Auch gut… :)