Beiträge von mainziman

    Hille  joas

    etwas Geschichte

    es gab Zeiten, da war https die Ausnahme, f. Banking, ...; alles andere war nur http

    und es war kein Problem in den HTML z.B. das da <img src="http://47.77.13.77/badimage.jpeg">

    oder das da <script src="http://47.123.87.21/badscript.js" type="text/javascript"> zu infiltrieren

    seit aber das ganze HTTPS ist, nicht; bis dieser Quark kam: weil damit geht das wieder wunderbar auch mit HTTPS;

    aus Sicherheitsgründen: blockier ich generell HTTP-Requests mit einer IP(v6)-Adresse im Host-Field;

    und damit auch den Quark; da wird nicht unterschieden;

    hat halt wieder mal jemand nicht zu Ende gedacht bei dem Quark; ;)

    da kann ich beruhigen, da es auf den 1ten Blick eher fürn Hugo is,

    wird es sich kaum verbreiten ...

    Front and center is the ability to indicate that a service supports HTTPS directly from the result of a DNS query. Currently, web clients have to first perform a DNS lookup for a service’s internet address and access it “in the clear” with HTTP in the hopes of being redirected to that service’s HTTPS endpoint.

    da kenn ich schon mindestens 1 Gegenbeispiel¹, des es gleich so richtig verkorkt;

    und dass das mit der Verbreitung von DNSSEC fällt/steht sei nur nebenbei erwähnt;

    (den Quark von DNS-over-HTTPS od. DNS-over-TLS vergesst dabei mal ...)

    ¹ ftp.mozilla.org dass man hier das FTP-Prokoll deaktiviert versteh ich ja,

    mal abgesehen davon, dass der Host ftp. genau das assoziiert;

    aber dass man dann HTTP erlaubt ist dann mehr als fragwürdig;

    http://ftp.mozilla.org/ <-- das dürfte gar nicht gehen, geht aber

    https://ftp.mozilla.org/

    Oder man speichert sich beides in einen Passwortmanager ab, der geräteunabhängig die 2FAs hält. Z.B. 1Password.

    wenn Du mit 'beides' hier auch das jeweilige Passwort meinst,

    ist das eine ganz schlechte idee, weil damit das ganze sich wieder reduziert und bloß zu einem Faktor wird,

    welcher bei unerwünschter Kenntnis von Dritten sogar zum Super-Gau eskaliert;

    ein Tipp: man speichere sich die QR-code images an einer geeigneten Stelle ab, dann kann mich sich jederzeit

    in jeden beliebigen H/TOTP das wieder einrichten; egal ob auf einem anderen Phone/Tablet od. nur einer anderen Authenticator-App

    genau darauf wollte ich hinaus; wenn diese IP welche Du da bekommst aus dem selben Range ist,

    aus dem auch die anderen IPs kommen, ist es sinnlos;

    ist das aber ein eigener Bereich, wo es unwahrscheinlich ist, dass da gleich das ganze Subnetz blockiert wird, nur dann macht es überhaupt erst einen Sinn;

    und jetzt etwas weiter gedacht: es wurde ja schon mal der Wunsch angedacht, dass netcup ausgehend Port 25 sperrt, und man dies nur explizit per Anforderung für sich freischalten lassen kann;

    was ist wenn dieser Anbieter das ähnlich handhabt, und genau dafur diese IPs anbietet?

    ..., wäre das sicher ne Überlegung wert bzw als sinnvoll zu erachten.

    hängt von den Rahmenbedingungen ab, bei denen ich es mir kaum vorstellen kann;

    d.h. ist die IP einfach nur eine zusätzliche IP, wie jede andere, ist es sinnlos;

    nicht alles was einen Marktwert hat hat auch einen Sinn;

    Um einen anderen Anbieter. Wir sind mit dem Verein ja aktuell bei Strota, wollen da aber weg. Nun wurde mir ein anderer Anbieter empfohlen (Stichwort E-Mail-Reputation), bei welchem man zu seinem Webhosting eine eigene IP buchen kann.

    und sicher dass diese eigene IP mit Mail und nicht mit Web zu tun hat - Stichwort SSL ohne SNI?

    wobei eines muss man hier auch klar sagen, wieso da manche lieber eine

    GMX, Gmail, ... Adresse hätten mit der sie kommunizieren;

    ganz einfach: die erlauben deren Zwangs-Newsletter-SPAM;

    und 'ne unbekannte Domain könnte da was gedreht haben ...

    weil mit Abstand größten SPAM-Schleuden heißen GMail und Outlook.com

    und GMX ist da auch nicht viel besser;

    Sollten es nicht auch eher die neighbor advertisements, die die Tabelle füllen?

    ich denke nicht,. weil davon gibts kaum Pakete, sind fast ausschließlich "neighbor solicitation"

    Gute Frage: was ist da passiert, dass eben seit rund 2 Tagen der /var/log/messages mit Meldungen geflutet wird ...

    ohne dass ich irgendwas verändert habe;

    Ich hab exakt diese neighbor solicitations auch im Dump. Sie kommen von Juniper Hardware, also vielleicht von Switches.

    Aber bei mir führen sie nicht zum Overflow der Neighbour Table. Vor allem auf meinem Piko hab ich da nur ne Handvoll Einträge, obwohl die solicitations tonnenweise vorbeikommen. Ich bin da auf Standard Einstellungen von Ubuntu und Debian unterwegs. Hast du da was verändert?

    interessant, ich fahr eigentlich auch mit den Standard Einstellungen von CentOS, habe da nie was verändert;

    da auf meinem 3ten vServer das Problem nicht exisitert; habe ich dort mal den tcpdump f. einige Minuten laufen lassen;

    4891 Einträge in 6¼ Minuten => rd 13 Einträge pro Sekunde

    beim Piko mit diesem Problem 21875 Einträge in 4¼ Minuten => rd. 85 Einträge pro Sekunde

    beim RS mit diesem Problem waren es gewaltige 596781 Einträge in 96¾ Minuten => rd. 103 Einträge pro Sekunde

    Moderatoren kommt das euerseits od. hat da wer einen Pfusch konfiguriert?

    Häng dich mal mit tcpdump ans Interface und filter alle ICMPv6 Pakete, eventuell auch nach ARP filtern. Lässt sich da auf den ersten Blick ein Muster erkennen? Würde mich nicht wundern, wenn jemand mal wieder ganze IPv6-Subnetze scannt. Dahinter könnte eine ähnliche Motivation wie z.B. bei MAC-Flooding stehen.

    Ja man erkennt ein Muster, hab das für einen Zeitraum von rund 90 Minuten auf dem RS gespeichert: tcpdump -n -i eth0 icmp6 > /tmp/icmpv6.txt

    der File is mehr als 80 MByte groß

    und es handelt sich tatsächlich um 2 Übentäter im LAN Moderatoren

    Code
    # wc /tmp/icmpv6.txt
      596781  7758048 83774506 icmpv6.txt
    # cat /tmp/icmpv6.txt |grep -v fe80::22d8:b00:91ee:ff4 |wc
     359416 4672303 50549438
    # cat /tmp/icmpv6.txt |grep -v fe80::22d8:b00:91fa:424c |wc
     239171 3109118 33448150
    # cat /tmp/icmpv6.txt |grep -v fe80::22d8:b00:91fa:424c |grep -v fe80::22d8:b00:91ee:ff4 |wc
       1806   23373  223082

    die Einträge sehen hier so aus:

    12:28:14.309619 IP6 fe80::22d8:b00:91fa:424c > ff02::1:ff64:8c3d: ICMP6, neighbor solicitation, who has 2a03:4000:31:3d5:74d8:c9ff:fe64:8c3d, length 32

    bzw.

    12:28:14.856725 IP6 fe80::22d8:b00:91ee:ff4 > ff02::1:ff00:383e: ICMP6, neighbor solicitation, who has 2a03:4000:31:2be::383e, length 32

    nach dem ff02::1:ff is es was zufälliges und auch bei who has sind es verschiedene;

    mein RS hat ein /64 welches Teil von 2a03:4000:31::/48 ist;

    beim VPS Piko hab das für ein paar Minuten gemacht

    und auch hier 2 Übeltäter im LAN Moderatoren

    Code
    # wc /tmp/icmpv6.txt
      21875  284356 3191789 icmpv6.txt
    # cat /tmp/icmpv6.txt |grep -v fe80::22d8:b00:9fee:ff4 |wc
      12085  157086 1765828
    # cat /tmp/icmpv6.txt |grep -v fe80::22d8:b00:9ffa:424c |wc
       9868  128265 1437533
    # cat /tmp/icmpv6.txt |grep -v fe80::22d8:b00:9ffa:424c |grep -v fe80::22d8:b00:9fee:ff4 |wc
         78     995   11572

    und auch hier die Einträge analog

    exemplarisch

    14:23:56.868177 IP6 fe80::22d8:b00:9fee:ff4 > ff02::1:ff96:e72c: ICMP6, neighbor solicitation, who has 2a03:4000:40:77:4455:eaff:fe96:e72c, length 32

    und auch hier mein VPS piko hat ein /64 welches Teil von 2a03:4000:40::/48 ist;

    Man beachte: die fe80 Adressen der Übeltäter unterscheiden sich nur durch 3(!) bits

    fe80::22d8:b00:91ee:ff4 vs. fe80::22d8:b00:9fee:ff4

    bzw.

    fe80::22d8:b00:91fa:424c vs. fe80::22d8:b00:9ffa:424c

    andreas. Jepp das war wie Penicillin;

    interessantes Detail: ich hatte zuvor ähnliches gefunden Link, da stand nur was von den Werten f. IPv4

    und nachdem ich diese gesetzt habe, hat sich nichts geändert;

    mit den Werten f. IPv6 hat es den Durchbruch gegeben;

    ergo ist da seit 1-2 Tagen gröber was mit IPv6 im Busch;

    nur mal so gefragt, kann das eine Fehl-Konfiguration eines "Nachbarn" sein?

    od. sonst eine Fehlkonfig. sein; beim 3ten mit den Standardwerten gibts keine Probleme derart;

    Detail am Rande: der VPS piko baut alle paar Minuten eine Verbindung zum RS per SSH auf,

    und hatte seit knapp 2 Tagen 1-2 mal pro Stunde ein Timeout

    Code
    ssh: connect to host rs-host port 22: Connection timed out

    (seit dem Erhöhen der Werte keine mehr)

    Wer 'ne Ahnung was da auf einmal die Logs [/var/log/messages] mit derartigem anfüllt

    (seit rund 1-2 Tagen)

    das auf zwei meiner 3 vServer (einer ein VPS piko und einer ein RS, beim 3ten ist nichts derartiges zu beobachten)

    diese beiden hatte ich vor rund 1½ neu gestartet ...

    Enten sind immer gut 🦆

    besonders wenn sie am Sonntag aus dem Backofen kommen :D

    tja ...
    Code: /var/log/maillog
    Apr 21 02:55:56 mailhost postfix/smtpd[32302]: NOQUEUE: reject: MAIL from mail.systekam.ru[31.13.133.158]: 554 5.7.1 <interpolinverstigationpolice@outlook.com>: Sender address rejected: Domain (outlook.com) blocked; from=<interpolinverstigationpolice@outlook.com> proto=ESMTP helo=<mail.systekam.ru>

    wenn die Leutz die sowas machen deren Hirnmasse f. die gute Sache einsetzen würde hätten wir keine Probleme ...