Posts by DC2022

    Das kann man überhaupt nicht vergleichen. Das eine ist ein fertig konfiguriertes Image, das andere ein Installationsmedium, wo man durch die Konfiguration noch komplett durchmuss. Wie gesagt, nicht vergleichbar.

    Naja also ich habe es noch nicht fertig bekommen das man mit der normalen Installationsroutine eine Datei Namens /etc/network/interfaces.d/50-cloud-init.cfg bekommt. Das ist schon sehr spezifisch.

    Das Problem ist, dass es eine Kündigungsfrist von 31 Tagen gibt - wenn der Monat allerdings weniger als 31 Tage hat, verlegt das den nächstmöglichen Kündigungstermin um einen Monat.

    :D wtf, ist logisch und wohl auch richtig aber hab ich so nochnie gehört


    Meine Erfahrungen bezüglich Kulanz bei Netcup war bei den 2 Versuchen nicht vorhanden. Aber als Firmenkunde ist der Umgang eh immer "streng" und viele "normale" Regeln, z.B. die 1 Monatige Mindestlaufzeit nach der Originallaufzeit, gibts halt nicht.

    Hallo zusammen,


    mich würden mal Interessieren worin sich die Netcup Images von den "Offizielen Images", die es bei Netcup ja als CD/DVD zum "einlegen" gibt, unterscheiden.

    Mir persönlich geht es eigentlich nur um Debian 12, wäre sicher für alle Systeme Interressant zu wissen.


    netcup.de - Fertige Images für vServer
    Webhosting, Server, Domains, Managementdienste, einfach alles fuer einen erfolgreichen Internetauftritt
    www.netcup.de


    Ich habe vor ca. 2 Wochen ein Debian 12 Image installiert und wollte eine Failover IP Adresse als ausgehende IP Adresse konfigurieren. Siehe Hier


    Wie ich dann herausgefunden habe, sind beim Netcup Image die Interfaces anders Konfiguriert als bei einer Installation mit einer "DVD". Netcup verlagert die Netzwerkeinstellungen in die Datei /etc/network/interfaces.d/50-cloud-init.cfg. Ich habe dann den Verweis auf die Datei von Netcup in der Originalen /etc/network/interfaces gelöscht und meine Einstellungen dort eingetragen.


    Jetzt würde mich Interessieren ob es noch weitere Unterschiede gibt, und wenn ja welche und warum. Das mit der Netzwerkkonfiguration ist nachvollziehbar (einfaches ausrollen der eigenen Netzwerkonfiguration ohne überschreiben der Originaldateien), wäre aber nett wenn man etwas offensichtlicher darauf hinweißt, aber naja.

    Ich weiß zwar nicht was mit "me" gemeint ist (evtl. was Netcup internes?), aber wenn du deine FritzBox Adresse z.B. unter dyndns.meinedomain.de einrichten willst, sollte der cname Eintrag unter deiner Domain so aussehen:


    dyndns CNAME *MyFritzDynDNSAdresse*

    Hallo zusammen, ich habe es gelöst bekommen, aber danke für eure Hilfe =)


    Wenn man bei der Installation nicht von DVD Bootet sondern ein Image von netcup benutzt, ist die Konfiguration in folgender Datei gespeichert:

    /etc/network/interfaces.d/50-cloud-init.cfg


    Ich habe in der "normalen" /etc/network/interfaces Datei dann folgenden Eintrag ganz oben gelöscht:

    Code
    source /etc/network/interfaces.d/*


    Und den Inhalt von der 50-cloud-init.cfg in die "normale" Datei kopiert. Anschließend konnte ich mit folgendem, oben schon mehrmals erwähnten Befehl die Failover-IP Addresse als Ausgehend einrichten

    Code
    up ip route change default via 2.56.XXX.XXX src 45.90.XXX.XXX

    Vielen Dank für deine Hilfe. Hier nochmal die aktualisierte /etc/network/interfaces

    Server ist neu gestartet, funktioniert aber nicht =) Die Ausgabe von ip address:


    Ausgab von ip route:

    Code
    default via 2.56.XXX.XXX dev eth0 onlink
    2.56.XXX.XXX/22 dev eth0 proto kernel scope link src 2.56.XXX.XXX

    Also jetzt sieht meine /etc/network/interfaces wie folgt aus (die Kommentare zwischen den ## im letzten Befehl sind natürlich wieder Nachträglich hinzugefügt).

    Server ist neugestartet, ist erreichbar, aber benutzt immer noch seine alte Standard IP Adresse zum nach draußen telefonieren =(


    Hmm, welche Auswirkung sollte das Hinzufügen der IP-Adresse auf dem Server auf das DNS haben? Vielleicht habe ich das Problem nicht verstanden, aber ich würde sagen, du musst die iP-Adresse per A-Record ins DNS der Domain eintragen.

    Sorry aber ich habe keine Ahnung was du meinst :D Also ich weiß auch nicht was das jetzt mit dem DNS zu tun hat


    Irgendwie passt das alles nicht: Du mischt hier DHCP und statische Konfiguration, nennst die Interfaces anders, der Gateway stimmt zwischen den Befehlen nicht überein…

    Ich habe mich, wie schon gesagt nur an die Beschreibung von Netcup gehalten, den dort angegebenen Befehl angehängt und dann noch den oben erwähnten Befehl aus dem anderen Thread danach angehängt. Der Rest ist alles die "Standard Auslieferung" von Netcup.


    Okay danke, ich probiere es mal aus.

    Hallo zusammen,


    ich weiß es gibt zu dem Thema schon diverse Threads, aber ich raffe es einfach nicht.

    Ich würde gern die Failover IP als Haupt-IP-Adresse verwenden.

    Hinzugefügt habe ich die IP Adresse wie im Netcup-Wiki beschrieben:https://helpcenter.netcup.com/de/wiki/server/ip

    Der Server ist jetzt auch unter dieser IP Adresse erreichbar, das klappt soweit.


    Meine /etc/network/interfaces sieht wie folgt aus:

    anschließend habe ich dann, wie in diesem Thread beschrieben (https://forum.netcup.de/admini…hende-ipv4-konfigurieren/), folgende Zeile hinzugefügt (Die Kommentare zwischen den # sind natürlich nachträglich eingefügt worden):


    Code
    up ip route change default via 2.90.XX.XX #Standard_IP_Adresse# src 46.90.XXX.XXX #Failover_IP_Adresse#

    Das zeigt allerdings keine auswirkungen, wenn ich meine IP-Adresse z.B. dig +short ANY whoami.akamai.net @ns1-1.akamaitech.net abfrage, kommt die normale IP-Adresse. Den Server habe ich selbstverständlich neu gestartet.


    Betriebssystem ist Debian 12.

    Der Benutzer soll doch sudo verwenden, falls er höhere Berechtigungen benötigt. Allerdings sollte er nur für die Befehle berechtigt sein, die der Benutzer für seine Arbeit benötigt. Die Berechtigungen werden in der Soduers Datei definiert. Das ist das eigentliche Ziel von Sudo.


    Klar, wenn man den Benutzer in die sudo Gruppe hinzufügt, also die Default Gruppe, welche vollständige Root Rechte hat, dann ist klar, dass dann Sudo nicht nur überflüssig ist, sondern auch noch potentiell eine Gefahr darstellt. Denn nun kann der normale Benutzer Befehle mit Root ausführen ohne das Kennwort von Root zu wissen. Deshalb sollte man das eigentlich nicht machen. Die Benutzer in der Gruppe sudo kann man also quasi auch als Root darstellen.

    Ja das ist klar, aber bei dem Szenario von BarneyBurp ist der Root-User ja deaktiviert. Das heißt es müsste einen Non-Root User geben der keine Limitierungen bei Sudo hat, sonst kann man den Server ja nicht mehr richtig Administrieren :D


    • Per sudo ist es nicht notwendig irgendwie/irgendwo das singulär vorhandene Root PW einzutippern

    Ich empfinde das eher als Nachteil, da der Nutzer dann ja ohne zusätzliche "Barriere" sudo ausführen kann?


    Ich würde z.B. den Rootnutzer komplett deaktivieren.

    Dann hast du einen Non-Root Benutzer, der aber in der Sudo Gruppe drin ist und ohne zusätzliches Passwort per Sudo alles ausführen kann? Ist das nicht unsicherer?

    Ich persönlich würde dir das Thema SSH Public-Key-Authentifizierung ans Herz legen. Dazu den SSH Port ändern und per nftables den SSH Zugang an eine feste IP binden. Das wäre ein guter Schritt zum Thema Sicherheit

    Danke für die Tipps, aber ich möchte das Thema hier nicht ausschweifen lassen. Möglichkeiten den Server abzusichern gibt es ja genug und vieles wurde hier im Forum schon mehrmals durchgekaut.

    Mir gehts wirklich nur explizit um das Thema mit der Sudo Gruppe und dem zweiten Non-Root Benutzer.


    Kann man machen aber ist meiner Meinung definitiv falsch. Sudo verfolgt das Ziel, dass man nicht mehr so oft mit Root Rechten arbeitet bzw. das man die Root Rechte beschränkt. Zum Beispiel soll ein Webentwickler den Webserver Dienst Neustarten dürfen aber ansonsten nichts am System oder an den anderen Diensten was machen dürfen. Dann kann man die Berechtigung in der Sudoers Datei hinterlegen. Wenn nun der Webentwickler sudo aufruft, dann wird der Befehl mit Root Rechten durchgeführt. Sudo prüft dann halt, ob der Benutzer dafür berechtigt ist.


    Bei der Installation von Sudo wird immer eine Default Gruppe sudo erstellt. Diese sudo Gruppe hat standardgemäß alle Root Rechte. Das ist notwendig, da man sich beispielsweise bei Ubuntu sich sonst aussperren würde bzw. keine Möglichkeit hätte Root zu werden, da bei Ubuntu bei der Installation kein Root Passwort vergeben wird. Wenn man aber Sudo wirklich nutzen möchte, dann sollte man auch die Sudoers Datei entsprechend anpassen und nicht alle User in die sudo Gruppe hinzufügen, da ansonsten Sudo überflüssig wäre.

    Gut, das heißt so wie wirs machen, den zweiten Benutzer komplett ohne Sudo Rechte anzulegen und nur im Notfall dann per su+Root PW zum Root Nutzer zu wechseln, ist deiner Meinung nach korrekt =) Frag mich warum die das dann in Anleitungen mit Aufnahmen..

    Hallo zusammen,


    ich hätte mal eine Frage bezüglich der Serversicherheit.


    Wir haben auf unseren Servern ausschließlich Debian laufen. Standardmäßig wird der Root Login per SSH dann deaktiviert (+ufw+fail2ban). Man loggt sich per SSH mit dem Non-Root Benutzer ein, und wechselt per su in den root Modus. dazu muss man das Root-PW eingeben. Das m.E. nach den Vorteil, dass wenn jemand es schafft, sich Zugriff zu verschaffen, er noch an dieses Root-PW herankommen muss.


    In diversen Anleitungen im Internet ist aber zu sehen das der Non-Root benutzer in die Sudo Gruppe mit aufgenommen wird. Somit kann er mit Sudo auch mit Root Berechtigungen arbeiten. Dazu muss er sein eigenes, also das Non-Root PW eingeben.


    Machen wir hier etwas Grundsätzlich falsch, und das mit der Sudo Gruppe wäre richtig? Mir persönlich kommt es unsicherer vor, weil man ja das Root-PW niemals braucht. Also was ist hier "State of the Art"?

    Sorry aber das mit testweiße IP Adressen ändern und RDNS/DNS EInträge ändern ist keine gute Idee. Das dauert immer ewig bis es im Internet ankommt und macht deine Domain/IP Adressen nicht gerade beliebter bei den Mail Anbietern.

    Du musst deinen Mailserver bei diversen Providern (io*nos, telekom, microsoft und ich glaube google, sonst fällt mir grad keiner ein) anmelden.
    Der RDNS Eintrag, von der IP Adresse vom Server der die Mails verschickt, muss heißen wie ein Mailserver (z.B. mail.xxx.de).
    Außerdem ein Eintrag in der DNSWL machen.


    Hast du das alles erledigt?


    Und nochmal wegen der Benennung;

    Wenn deine Domain XY.com heißt, sollte der RDNS EIntrag mail.xy.com heißen und der server sollte ebenso heißen. Ich denke das dass bei dir nochnicht passt.

    Wahrscheinlich hast du den RDNS EIntrag angepasst aber der server heißt noch irgendwas mit yourserver.

    Und dann dein RDNS auf yourserver oder sonstwas umzubennen ist wie schon gesagt keine gute Idee für die Reputation, davon abgesehen das solche Domains im Normalfall eh nicht akzeptiert werden.

    Der DKIM PublicKey wird vom Mailserver generiert und muss im DNS hinterlegt werden.
    Ich glaube aber nicht das die Mail wegen dem fehlenden DKIM EIntrag im Spam landet.


    Du musst deinen Mailserver bei diversen Providern (io*nos, telekom, microsoft und ich glaube google, sonst fällt mir grad keiner ein) anmelden.
    Der RDNS Eintrag, von der IP Adresse vom Server der die Mails verschickt, muss heißen wie ein Mailserver (z.B. mail.xxx.de).
    Außerdem ein Eintrag in der DNSWL machen.

    Wenn die DNS Records vom Mailserver über Cloudflare laufen kann es garnicht funktionieren. Rausnehmen geht auch nicht, Cloudflare ist ja dein DNS/Nameserver Hoster. Wenn du sie rausnimmst existieren sie nicht mehr.


    Du musst, wie der Kollege oben schon erwähnt hat, bei Cloudflare auf nur DNS stellen. Also nebem dem Eintrag die Wolke rausmachen. Dann wird der Traffic nicht über das CDN von Cloudflare geroutet sondern direkt.

    Nachteil: Wenn Mailserver und Server auf dem gleichen Server liegen, ist der Vorteil von Cloudflare etwas gemindert da die IP ja über den MX Record öffenltich ist.

    Btw ob man Cloudflare überhaupt in DE verwenden darf, DSGVO und so, darüber könnte man diskutieren aber ist m.E. eigentlich nicht möglich.