Security thru Obscurity is no Security.
*Gähn*. Logspam ist Logspam.
Beiträge von NaN
-
-
deSEC.io ist ein (kostenloser) DNS-Betreiber
DeSEC ist auch ein installierbarer Open-Source Software-Stack. Ist natürlich nicht nötig, das selbst zu betreiben, weil der deSEC.io Service ganz fantastisch funktioniert. Man kann die DNS-01 Challenge übrigens per CNAME an eine Domain dort delegieren.
Ich empfehle auch, Wildcard-Zertifikate ausstellen zu lassen. Das ist besonders dann sinnvoll, wenn man privat genutzte Subdomains mit Zertifikaten ausstatten möchte, ohne dass die Hosts ständig auf Sicherheitslücken abgeklopft werden. Die CA Transparenz Logs von Letsencrypt werden nämlich von unzähligen Möchtegernangreifern als Quelle von Domainnamen genutzt. Mit Wildcard-Zertifikaten schiebt man dem einen Riegel vor, weil die letztendlich genutzten Subdomains nicht im Zertifikat stehen.
-
Du kannst einen CNAME Record anlegen oder einen A Record, nicht beides. Mit einem CNAME Record machst du die Domain zu einem Alias einer anderen Domain und dann gelten deren DNS-Records und nur die.
Edit: Ich habe mir die Anleitung angeschaut, was die da haben wollen. Der CNAME Record soll für die "www" Subdomain gesetzt werden und der A Record für die Apex Domain (weil dort ein CNAME bekanntlich nicht möglich ist). Ein A statt CNAME Record für die Subdomain müsste auch funktionieren.
-
du könntest auch alles auf einen einzige Subdomain die auf den Rootserver verweist reduzieren
Die Aufteilung auf verschiedene Namen ist trotzdem sinnvoll, weil man dann einzelne Dienste auf andere Server verlagern kann, ohne überall die Namen zu ändern.
-
Du legst die DNS-Records so an, wie du das beschrieben hast. Die Clients verbinden sich auf "ihrem" Port mit der IP-Adresse, die sie über die Abfrage des DNS-Namens bekommen. Wenn das der Standardport für den Client ist, brauchst du den nicht anzugeben. Sonst wird der im Client angegeben. Einige Protokolle haben die Möglichkeit, über SRV-Records auch einen Port im DNS anzugeben, wohin sich der Client verbinden soll.
In den meisten Protokollen ist es egal, über welchen Namen die Verbindung aufgebaut wird, weil der Name im Protokoll gar nicht auftaucht. In HTTP und HTTPS ist das anders, weil über den Namen "name based virtual hosting" gemacht wird und der Client dem Server dazu den Namen beim Verbindungsaufbau mitteilt. Gameserver und -clients machen das i.d.R. nicht.
-
Wäre es dann grundsätzlich möglich, die "Firmendomain.eu" mit dem Webhosting zu nutzen?
Entstehen weitere Kosten?
Im Webhosting 1000 ist eine externe Domain inklusive. Das geht also ohne zusätzliche Kosten. Weitere externe Domains können für einen einmaligen Betrag aufgeschaltet werden (5€).
Oder müssen einfach nur die von Netcup geforderten DNS-Einträge beim anderen Anbieter eingetragen werden?
Das ist zum Aufschalten der externen Domain nötig, aber alleine nicht ausreichend. Mit dem Aufschalten (1x inklusive, s.o.) wird dem Webserver die Domain bekanntgemacht, so dass der Server weiß, welcher Account dafür zuständig ist und wo die Daten dafür sind.
Wäre alternativ ein CNAME von "Firmendomain.eu" auf "nachname-vorname.de" sinnvoll/möglich?
Das ist möglich, aber nicht sinnvoll, weil dann die Emailfunktion nicht beim anderen Hoster bleiben kann. Mit CNAME wird der Name zu einem Alias des anderen Namen, inkl. der für Mail zuständigen MX-Records.
-
Es gab das Thema und es gibt es noch immer. Zum Beweis habe ich es verlinkt.
-
Es gab hier kürzlich ein Thema zum Einstieg in die Serveradministration. Fairerweise muss man sagen, dass es keine universellen Konventionen gibt, wie der erste Login stattfindet, besonders wenn nicht der Installer der Distribution durchgearbeitet sondern ein Image aufgespielt wird. Wenn man die verschiedenen Möglichkeiten nicht kennt, steht man halt vor dem Berg und sieht den Weg nicht. Aber dafür gibt es Foren und Dokumentation, je nachdem was man bevorzugt. Der Support hat anderes zu tun. Nicht entmutigen lassen. Niemand kommt als Profi auf die Welt.
-
Remote Logins als root sind in vielen Linux Distributionen abgeschaltet. Dafür hat der SSH-Server eine dedizierte Option in /etc/ssh/sshd_config mit einer Voreinstellung, die root die Anmeldung mit Passwort verbietet: PermitRootLogin: prohibit-password. So kann sich root nur mit public key Authentifizierung einloggen. Mit der Einstellung no ist für root gar kein remote Login möglich. Dann führt der Weg zu root über einen normalen User und sudo und/oder su.
Anstatt diese Konfiguration zu ändern, sollte man sich mit public key Authentifizierung vertraut machen und am besten den Login per Passwort für normale User ebenfalls abschalten: PasswordAuthentication: no. Wenn man sich durch einen Fehler remote ausgesperrt hat, kommt man immer noch über die lokale Konsole im SCP oder im äußersten Fall mit dem Rettungssystem an das installierte System.
Man sollte wirklich nicht erwarten, dass der Kundensupport Anfängerkurse in Serveradministration gibt. Diese elementaren Dinge sind an unzähligen Stellen ausführlich dokumentiert und werden auch in Foren immer wieder gefragt und beantwortet.
-
Ich habe die Weiterleitung von Emails an Adressen meiner Domain ohne vorhandenen Benutzer aktiviert.
Das wird meistens "Catch-all" genannt. (Wenn du zu dem Thema suchst, findest du mit dem Begriff mehr).
Gibt es dafür vielleicht eine Art Blacklist wo ich eintragen kann, dass z.B. Emails an willichnichthaben@meinedomain.de geblockt werden?
Du kannst im Webmail-Interface oder mit einem Client, der "Sieve" unterstützt, einen Filter auf dem Mailserver konfigurieren, der Emails an bestimmte Adressen löscht (oder markiert, oder in einen Ordner verschiebt, etc.). Alternativ kannst du eine Email-Adresse mit einem winzigen Speicherkontingent einrichten und alle Adressen, für die du keine Emails mehr empfangen möchtest, dort als Alias hinzufügen.
-
Die Zähler der Firewall können hilfreich sein:
Mit iptables -I INPUT -p udp --dport 51820 -j LOG legst du eine Firewallregel am Anfang der INPUT Chain an und mit iptables -v -L INPUT lässt du dir die Regeln der INPUT Chain inkl. Zählerständen anzeigen. So kannst du sehen, ob entsprechende UDP Pakete deinen Server erreichen. Im Systemlog kannst du so außerdem noch Details der Pakete sehen. Die Regel sollte man nach dem Testen wieder entfernen, damit das Log nicht überläuft und weil das Loggen Performance kostet.
-
Es macht tatsächlich keinen Unterschied, weil es auf ein Detail ankommt. Ich habe es gerade ausprobiert: Der Pfad wird nur dann angehängt, wenn ein Pfadpräfix in der Direktive angegeben wird.
Redirect 301 "https://netcup.com/" leitet von example.com/pfad zu netcup.com/ um.
Redirect 301 / "https://netcup.com/" leitet von example.com/pfad zu netcup.com/pfad um. (Und aufpassen: Der Pfad ohne den matchenden Anfang wird angehängt, also im Beispiel ohne den ersten /. Wenn das Ziel keinen Schrägstrich am Ende hat, gibt es Durcheinander.)
-
Aber das bringt mir doch nichts, wenn der Pfad unter .com nicht existiert?
In der Regel will man das, aber in dem Fall nicht. Das Modul, aus dem diese Direktive kommt, heißt "mod_alias". Gedacht ist das schon dem Namen nach dafür, dass bestimmte URIs Aliase für andere URIs sind, und das betrifft meist ganze URI-Mengen, z.B. wenn man eine Website umbaut oder auf eine andere Domain umzieht. Wenn man Domains nur als Werbung für eine andere Website einsetzt, ist das was anderes.
-
Aber genauso falsch*. Die Doku sagt, der Pfad wird angehängt (was man i.d.R. ja auch will):
https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect
Mit RedirectMatch geht es aber:
CodeRedirectMatch ".*" "https://meinedomain.com/"*) doch nicht falsch, siehe unten.
-
In dem Fall geht der einfache Redirect mit Redirect 301 "https://www.meinedomain.com/"
Die Zieldomain wird nicht aus dem selben Dokumentenstamm bedient, also gibt es keine Schleife. Alle aus dem Dokumentenstamm bedienten Domains sollen umgeleitet werden, also muss auch der verwendete Hostname nicht abgefragt werden.
-
Ich war durchaus beeindruckt, dass mir chatgpt kürzlich recht gut unterschiedliche Weiterleitungsarten aufgedröselt hat
Dann können wir das ja hier sein lassen. Es ist mir ein Rätsel, warum niemand sieht, dass diese "AIs" Plagiatmaschinen sind. Glaubst du wirklich, die "AI" hat sich diese Erklärungen selbst ausgedacht? Meine Bereitschaft, öffentlich zu helfen, sinkt rapide.
Also wenn ich jetzt einfach nur alle unter .de aufgerufenen Pfade auf die "Startseite" der .com umleiten möchte, nutze ich Redirect 301 "https://netcup.com"?
Im Prinzip ja, aber will man das? Außerdem musst du aufpassen, dass du Redirect-Schleifen vermeidest. Falls mehrere Domains aus dem selben Dokumentenstamm bedient werden, musst du das irgendwie abfangen. Wenn im Beispiel "netcup.com" auch diese .htaccess verwendet, dann geht es sonst endlos im Kreis herum.
-
https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#rewriteengine
https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#rewriterule
https://httpd.apache.org/docs/2.4/rewrite/remapping.html#canonicalhost
Das Beispiel im "Canonical Host" Abschnitt stammt wohl aus der Zeit vor LetsEncrypt und enthält das feste Schema http:
Apache ConfigurationRewriteCond "%{HTTP_HOST}" "!^www\.example\.com" [NC] RewriteCond "%{HTTP_HOST}" "!^$" RewriteRule "^/?(.*)" "http://www.example.com/$1" [L,R,NE]Das sollte man noch durch %{REQUEST_SCHEME} oder fest durch https ersetzen.
Die RewriteConds testen, ob nicht schon der "richtige" Hostname verwendet wurde und ob der Hostname nicht leer ist. "/?" in der RewriteRule ist für den Fall, dass dieser Regelsatz in der Serverkonfiguration verwendet wird. In der .htaccess kann der zu matchende Pfad nicht mit einem "/" anfangen. R=301 statt R macht aus dem temporären Redirect einen permanenten Redirect, sagt also dem Client, dass er in Zukunft gleich die neue Adresse verwenden soll.
Hier mal eine kurzer Vergleich zwischen Redirect (Client) und Rewrite (Server)
Redirect und RedirectMatch können nicht auf den Hostnamen prüfen, sind also für diesen Zweck nicht das Mittel der Wahl. Auch RewriteRule kann externe Redirects veranlassen (das 'R' in den Flags der RewriteRule).
-
Einen Versuch ist es wert, denn für die Anforderung des AuthInfo2 Codes finde ich keinen Preis unter 10€ pro Domain (überwiegend deutlich mehr). Deswegen würde ich auch die Kosten für die Wiederherstellung durch Netcup erfragen.
-
Abgesehen davon war der beschriebene Vorgang nicht mehr möglich.
Lies dir bitte die Informationen zur RGP bei der Denic durch.
ZitatDazu veranlasst der Provider die Generierung der AuthInfo bei DENIC (analog zu: Der bestehende Provider kann keine AuthInfo bereitstellen). Der letzte Domaininhaber erhält von DENIC die erzeugte AuthInfo per Einschreiben an seine in den Domaindaten hinterlegte Adresse. Gleichzeitig hinterlegt DENIC die generierte AuthInfo verschlüsselt in der Domaindatenbank. Der Domaininhaber teilt die AuthInfo dem Provider seiner Wahl mit, woraufhin die erneute Registrierung erfolgen kann.
Dass ein Einschreiben verschickt wird, sollte erklären, warum das nicht der billigste Weg ist. Auch für den bisherigen Provider ist eine Neuregistrierung kein normaler Domainumzug: das kostet.
-
Habe ich das falsch verstanden? Die Telekom will ein Impressum für den MTA, nicht für die Domain der Email-Adresse, oder?
