Beiträge von m_ueberall

    Mal eine Frage zu Zugangsschutz mit Port-Knocking, iptables und fail2ban: Macht ihr das, weil ihr keinen key-only Login nutzen könnt oder wollt?

    Ich mache das zusätzlich, weil es unter anderem die Logs klein hält (ohne die Chance, mit SSH oder anderen Diensten zu kommunizieren, gibt es auch keine wie­der­hol­ten protokollierten Login-Versuche Dritter). Und es ist einfach eine zusätzliche Sicherheitsvorkehrung, die nicht schadet und den regulären Betrieb nicht (nennenswert) ver­kom­pli­ziert.

    Und wenn ich Ruhe im Log haben will, dann gibt's ssh nur auf IPv6, und zwar auf einer nur dafür verwendeten Adresse.

    Das ist auch eine Möglichkeit, allerdings nicht immer eine Option.

    IvPe: Did you receive your credentials by e-mail? If so it should have been mentioned that the provided password is to be used in conjunction with the root account while the number shown above should be your customer number (which is only used elsewhere).

    stimmt, dafür die Wahrscheinlichkeit dass man sich damit selbst rauskickt im Sinne von komplett aussperrt dafür umso höher;8o

    Die korrekte Sequenz kann man schon ein paarmal senden. Bedarf dafür besteht aber in der Praxis eh' nur, wenn man keine VPN-Verbindung aufbauen kann (es ist also bereits ein Fallback-Szenario). Und wenn es einmal zu einer Sperrung kommen sollte – noch nie erlebt in den letzten Monaten! – bietet sich der Umweg über einen anderen Rechner an ("neues Spiel, neues Glück") … :D – Einer der vielen Vorteile des Server-Hoardings. :whistling:

    wie Du sagst - "theoretisch unbekannte Anklopfsequenz" - soll heissen, dass ausgeschlossen werden muss, dass durch Zufall die "Anklopfsequenz" von einem Portscan ausgelöst werden kann ... und hier hab ich meine Zweifel;:/

    Also, wenn die Portscans nicht die Reihenfolge der kontaktierten Ports und die Zugriffsart ständig permutieren (und das machen die allerwenigsten), ist bereits hier die Möglichkeit einer Exponierung des Dienstports in der Regel(!) ausgeschlossen. (Zur Erinnerung: Die Klopfsequenz kann – und sollte! – durchaus 5..10 Ports in zu­fäl­liger Reihen­folge und jeweils wahlweise UDP/TCP als Protokoll definieren[*]. Und nach jedem Klopfen müssten quasi alle potentiellen "SSH-Ports" unter Ver­wen­dung eben­dieses Protokolls getestet werden. Da sich aber auch "wildes Herumgeklopfe" entsprechend erkennen und blockieren lässt – d.h. danach sind für xxx Stun­den kei­ner­lei Tests mehr möglich – dürften entsprechende Einbrüche effektiv kaum möglich sein.)

    Mit obiger Vorarbeit kann man bei fehlerhaften key phrases übrigens auf Mehrfachversuche bei der Authentifizierung per SSH verzichten, d.h. man würde die ent­spre­chen­de IP-Adresse (bzw. nach einer gewissen Anzahl von Vorfällen ganze IP-Bereiche) direkt blockieren. Da in der Praxis auch die Klopfsequenzen wie alle anderen Schlüs­sel in adä­qua­ten zeitlichen Abständen geändert werden, haben Angreifer in Verbindung mit knockd sehr, sehr schlechte Karten. Sehr, sehr schlechte.


    [*] EDIT: Die Wahrscheinlichkeit, dass durch x-maliges schnelles(!) Anklopfen von ca. 65000 Ports via TCP und UDP die Sequenz als korrekt erkannt wird, ist sehr gering, selbst wenn falsche "knocks" dazwischen nicht registriert werden. Man müsste hier allerdings konkret (a) nochmal in den knockd-Quellcode schauen, wie das Verhalten genau vorgegeben ist und (b) prüfen, ob bspw. masscan das anlagemäßig von der Geschwindigkeit stemmen könnte. Ich halte das für ausgeschlossen für län­ge­re Klopf­se­quen­zen. Zudem wäre ein solches Verhalten ausgehend von ein- und derselben IP-Adresse wirklich recht eindeutig von "normaler Nutzung von Ports" zu unterscheiden.

    Are you referring to the SCP virtual server console ("VNC console")? This could be locale-related. Have you tried to type in your password instead of the username first (so it gets displayed; you might want to delete it instead of hitting enter, though)? If it looks "odd", the former is the case, if not, you must have made a mistake when setting the password.

    Einen Java-Decompiler, der dir C-Code generiert? Glaube da kannst du lange suchen :P

    Einen Decompiler braucht es ja nicht:

    hat jemand ein gutes Tool mit dem man aus einer Java Klasse (Quellcode in Form eines .java-Files) einen C Quellcode bekommt?

    Da gibt es schon ein paar, die man nacheinander durchprobieren könnte (Google spuckt u. a. ein älteres GitHub-Projekt aus); je nach Umfang und Nutzung der OOP kann die Ausgabe natürlich "wild" aussehen… Im Zweifelsfall würde ich einen Transpiler wählen, der auch in eine objektorientierte Zielsprache übersetzt (C++, C#?).

    Ich soll für einen Dienstleister von uns einen CNAME EIntrag setzen. sub.abc.com auf sub.xyz.de soweit kein Problem.

    Allerdings verlangen die ein SSL Zertifikat. Ich bin jetzt der Meinung das der Host sub.xyz.de das Zertifikat zur Verfügung stellen muß!?

    Liege ich da richtig?

    Ja, das ist korrekt. Der CNAME-Eintrag wird Client-seitig ausgewertet und es erfolgt direkt eine Kontaktierung des für sub.xyz.de zuständigen Hosts – aber unter dem "ursprünglichen" Namen sub.abc.com(!) Wenn das so nicht praktikabel ist (weil das Zertifikat nicht aus der Hand gegeben werden darf), hilft nur ein HTTP(S)-Redirect oder die Installation eines Reverse Proxies.

    Ohne den Diskussionsstrang von @mfnalex kapern zu wollen – der dortige Beitrag von @Andi22 hat mich daran erinnert, einmal einen genaueren Blick auf DNSControl werfen zu wollen. Auf den ersten Blick sind einige zusätzliche DNS-Eintragstypen wie SMIMEA, OPENPGPKEY "nachzurüsten", aber damit ist letztlich eine ein­heit­li­che, einfache Verwaltung von Domänen sowohl bei Netcup als auch bei einem gewissen Berliner Dienstleister (e.V.) möglich.

    Hat hier schon jemand Erfahrungen mit DNSControl gesammelt?

    Laut https://dnsviz.net/ gibt es keine DNSSEC-RRSIG-Einträge (ist das gewünscht?) und laut dem obigen Screenshot ist der Gültigkeitszustand der Einträge nicht "yes", sondern "unknown" – Wenn sich der Status nach mehreren Stunden immer noch nicht geändert hat, ist "irgendwo der Wurm 'drin" und der Support sollte sich das einmal ansehen, denn bereits die oben gezeigten Einträge – sofern vollständig – sollten von der Syntax (wie erwähnt: wegen des Domänensuffixes initial nicht von der intendierten Semantik) her allesamt valide sein.

    Setzen des "DNSSEC-Status-Häkchens" sollte nicht schaden (dies hat, sofern das Häkchen nicht vor weniger als 24 Stunden gelöscht wurde, eine "sofortige" Re-Signierung der Domäneneinträge zur Folge).