Beiträge von GTAzoccer

  • Das längste Thema

    Zitat von ckd

    Versuch doch mal folgendes: hardenize.com und lass mal die Checks fuer deine Domain durchlaufen. Damit kriegst du eigentlich die groebsten Fehler sofort angezeigt (sofern vorhanden). Google ist gerade bei DMARC ein toller Sparringspartner. :)

    image.png

    Ich glaube wir reden ein bisschen an einander vorbei. Mein Dashboard zeigt mir für von meinem MTA stammenden Mails auch alles grün und funktional an. Und MTAs, die unrechtmäßig meine Domains verwenden, werden abgewiesen. So wie es sein soll. Ich habe kein Problem mit DKIM/DMARC/SPF.

    Der Screenshot beinhaltet die rohen Mails, mit den eingehend Reports. Die grundsätzliche Menge an Reports ist von mir erwartet. Das habe ich in meiner DMARC-Policy auch so angefordert. Ich belustige mich lediglich darüber, dass Google (nicht immer, aber häufig), den exakt selben Report (gleiche Report-ID!) mehrmals verschickt. Teilweise bis zu acht mal! Also acht E-Mails mit Duplikaten von ein und dem selben Report. ^^

    Dein vorgeschlagenes Web-Tool zeigt bei meiner Domain aber auch alles grün an für DKIM und SPF. :)

  • Das längste Thema

    Zitat von ckd

    Sieht doch gut aus? Jetzt musst du die DMARC Reports nur noch (automatisiert) auswerten und die Ursache ermitteln. :)

    Wenn du so viele DMARC Reports bekommst, bouncen bei Google sehr viele Mails, die zu deiner Domain gehoeren, quasi die Kernfunktionalitaet von DMARC. Das kann viele Ursachen haben, beispielweise versucht eines deiner eigenen Systeme Mails zu versenden und es fehlen die TXT Records fuer SPF und bei Google bouncen alle Mails. Da du DMARC Reports aktiviert hast, wirst du natuerlich von Google darueber in Kenntnis gesetzt.

    Beispie fuer einen SPF Record:

    TXT "v=spf1 +mx +ip4:<ipv4 address> +ip6:<ipv6 address> -all"

    Ähm. Da bounced aber nichts. :) Das sind Dopplungen von Reports, die aussagen, dass die jeweilige Zustellung erfolgreich war und alle DMARC und SPF Prüfungen "pass"ed sind.

    Mein MTA hat zu den Mails auch jeweils nur einen (erfolgreichen) Zustellversuch unternommen.

    Oder verstehe ich dich gerade falsch?

  • Das längste Thema

    Interessant bei dem Thema finde ich gerade, dass der PoC in meiner lokalen Debian 12 Test-VM gar nicht funktioniert.

    Das Python-Skript läuft fehlerfrei durch, aber das su Binary ist danach nicht "vergiftet" und weiterhin das Original, welches nach dem root Passwort zur Authentifikation fragt. Ich sehe aber danach, dass das Modul "algif_aead" tatsächlich geladen wurde.
    Nach der modprobe Konfiguration von m_ueberallquittiert das PoC-Skript aber bereits mit einem fatalen Fehler. Das Modul ist danach auch nicht mehr geladen.

    Da das Modul auf keinen meiner Produktivsystem vorher geladen/genutzt war, sehe ich aber auch keinen Schaden, es pro-aktiv - fürs bessere Gewissen - überall tot zu stellen.

    Eine passwortlose Rootshell vor Deaktivierung zu erhalten und erst danach nicht mehr, hätte ich mich aber eigentlich schon interessiert. Im Sinne von: "Hab ich was falsch gemacht?"

  • Debian: unattended-upgrades

    Zitat von Win98SE4ever

    Die Datei habe ich gar nicht und bin mir sicher nichts aus dem Ordner gelöscht zu haben. :/

    Dann leg sie an. Oder sonst irgend ein Name, mit dem für dich später ersichtlich bleibt, dass sie von dir ist. Wichtig ist, dass irgendeine Datei in diesem Verzeichnis die zwei erwähnten Konfigurations-Direktiven setzt.

    Ich meine, ich habe mit den Namen meiner Datei damals aus dem Ubuntuusers Wiki gemopst.

  • Debian: unattended-upgrades

    /etc/apt/apt.conf.d/20auto-upgrades

    Wäre noch interessant. Da sollte noch so was drin stehen, damit von unattended-upgrades überhaupt was gemacht wird.

    Code
    APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

  • Das längste Thema

    Zitat von m_ueberall

    Ich hoffe doch sehr, dass die Box von außen über die öffentliche IP-Adresse nicht auf derartige Anforderungen wie "reconnect" reagiert … =O

    Nein, tut sie nicht.

    Als Paranoider war es so ziemlich eine meiner ersten Amtshandlungen, nach Erwerb meiner Fritzbox, diese von einem meiner Netcup VPS auf ihrem externen Interface alle möglichen Ports abzutasten.

    Allerdings weiß ich nicht, ob das mit der (meiner Meinung nach sowieso fahrlässigen) Option die Konfigurationsoberfläche auf dem WAN-Interfafe bereitzustellen, dann anders aussieht. Die Option hatte ich nie aktiviert und habe es auch nicht vor.

  • Das längste Thema

    Zitat von gunnarh

    Ich sehe da kein Indiz für eine angeschlossene Disk.

    Diese Speed-Messungen macht dieser raid6-Treiber doch vermutlich bei jedem Neustart?

    Zitat von KB19

    Wie kommst Du darauf? Das sehe ich hier nicht.

    Für mich sieht das eher wie ein update-grub mit aktivem os-prober aus. Aber ich habe am Handy gerade keinen Zugriff auf eine Test-VM, um die Logs zu vergleichen. Afaik entstehen da jedoch ziemlich ähnliche Einträge.

    Oder war das direkt beim Systemstart?

    update-grub ist der Hint, der mir gefehlt hat. Ich danke euch beiden!

    Grund meines Grübelns war, dass das mitten im Betrieb geloggt wurde. Sieht man auch noch an der Kernel Laufzeit von

    295480 Sekunden / 3,5 Tagen. Es also kein Teil einer Bootsequenz mehr war.

    Irgendwo bin ich dann bei "device-mapper: uevent" gedanklich falsch zu udev-event abgebogen. Was beim Einstöpseln eines neuen Block-Device getriggert werden würde.

    Dass die Probe-Sequenz von Grub das auslöst war mir nicht klar. ../apt/history.log bestätigt aber, dass ich zu dem Zeitpunkt alte Kernel entfernt habe.

  • Das längste Thema

    Manchmal stößt man, bei der Suche nach etwas komplett Anderem, auf Sachen die einen stutzen und komplett vergessen lassen, was man ursprünglich wollte.

    Auf der Suche nach aussagekräftigeren, protokollierten Meldungen als ein Service den Start mit einem schlichten "failed" verweigerte, bin ich in einer syslog hier rüber gestolpert:

    Hatte Netcup mir da aus versehen kurz eine andere (nicht meine) vdisk angeschlossen?

    lsblk zeigt mir heute jedenfalls keine unbekannten Disks mehr.

  • Kulanz-Erfahrungen bei netcup

    Zitat von tab

    Na dann, ran an die Arbeit :) . Allerdings habe ich noch ein Statement eines NC-Mitarbeiters im Gedächtnis, dass genau die hohe Zahl der Domains hier den Unterschied mache. Dass also das derzeitige Setup nur wegen der sehr hohen Zahlen nicht zuverlässig funktioniere. Ob das tatsächlich so ist, das weiss ich nicht, wer das geschrieben hat leider auch nicht mehr. Ich glaube es dann einfach erst einmal.

    Ich meine mich an dieses Statement in verbaler Form zu erinnern. Von Lars aus einer aufgezeichneten Q&A Session welche vermutlich bei einem Community-Event stattfand.

  • Server administrieren - wo fange ich an?

    Zitat von Bud
    Code: smartphone.conf
    [Interface]
PrivateKey = prvkey=
Address = 10.0.1.1/24, fd10:10:10::1/64
DNS = 91.99.154.175, 2a01:4f8:c010:8c35::175

[Peer]
PublicKey = pubkey=
Endpoint = 12.34.56.78:51820
AllowedIPs = 0.0.0.0/0, ::0/0
PersistentKeepalive = 25

    Ja gut, dann habe ich das aber so wie von euch beschrieben. Hatte nur die conf für den Peer nicht geposted.

    Du hast hier aber beiden Peers die selbe IP-Adresse gegeben.