Beiträge von engine

Ich hatte gar nicht versucht eine Firewall zu erklären oder zu sagen, dass dein Setup schlecht ist Ich wollte nur sagen, dass eine öffentliche NIC halt öffentlich bleibt, solange sie nicht am Hypervisor auf der VM deaktiviert wird.

Zitat von Exception

Natürlich kann das wieder aktiviert werden. Aber sicherlich nicht durch ein Bug im System bzw. es müssten dann schon mehrere kritische Bugs sein die gleichzeitig auftreten. In solch einem Fall würde ich grundsätzlich das verwendete Betriebsystem in Frage stellen. Und sollte Schadsoftware auf dem Server sein, dann hast du grundsätzlich verloren. Dann ist es ohnehin egal, ob der Server direkt oder über eine Firewall seine Verbindung ins Internet nimmt.

Ansonsten hast du natürlich Recht. Viel schöner und "richtiger" wäre es, wenn man die Server auch nur mit dem VLAN NIC betreiben könnte. Dann kann der Kunde (und auch Netcup) die öffentliche IPv4 Adresse sparen. Mir ging es aber nur um den Sicherheitsaspekt, dass man die Server trotz der abgeschalteten NIC mit der öffentlichen IP sicher und ohne jegliche Bedenken betreiben kann.

Ich sage nur Firewalls. Wir setzen in der Bude lauter Fortigates ein. Ich hab aufgehört die RCEs zu zählen, die es gab in den letzten Monaten, die eine feindliche Übernahme ermöglicht hätten. Jetzt kann man natürlich Fefe spielen und jeden von uns Idiot nennen, weil man sowas einsetzt (was wäre denn die Alternative anyway, jeder Vendor hat Bugs), aber ich kann dir auch sagen, dass man im KRITIS Bereich oft sogar 2 Firewalls hintereinander einsetzt von unterschiedlichen Herstellern, um genau das zu mitigieren. Aber ich traue mich selbst als ITler nie etwas aus unwahrscheinlich zu bezeichnen, weil heute einfach viel zu viel von allem abhängig ist (Libraries etc)

Zitat von Exception

Warum nicht? Ich mache das exakt so. Das Interface mit der öffentlchen IP ist bei mir abgeschaltet, während die andere NIC mit dem VLAN aktiv ist. Gab noch nie Probleme damit.

Und wenn man wirklich Angst davor hat, dass ein Bug das Interface wieder aktiv schaltet, dann könnte man immer noch den DHCP Client vollständig deaktivieren oder einfach das Interface statisch mit einer RFC1918 Adresse austatten. Abgesehen davon ändert sich ja auch am Routing nichts. Selbst wenn die NIC wieder aktiv wird und bei der NIC die öffentliche IP Adresse eingerichtet ist, dann wird ja trotzdem alles über die VLAN NIC geroutet (falls das Default Gateway korrekt gesetzt ist). Und wenn man ganz paranoid ist, dann kann man notfalls das Interface mit iptables zusätzlich blacklisten.

Da müssten schon ganz schön viele Bugs auf einmal auftreten, damit da was blödes passiert. Natürlich wäre es am schönsten, wenn man die öffentliche NIC abschalten bwz. löschen kann. Einen Vorteil sehe ich allerdings nur darin, dass man sich die öffentliche IP sparen könnte.

Wie gesagt, alles was du deaktivierst, kann auch wieder aktiviert / umgeschrieben werden. Diverse Cloud-Anbieter geben eben deshalb die Möglichkeit VMs ohne Public IP zu erstellen um dann eben mittels VLANs und eigener Firewall sich abzusichern oder bieten ein NAT Gateway an. Wenn du da z.B. dann Tailscale nutzt, ist per se von aussen nach innen nichts direkt erreichbar.

Zitat von Paul

Man muss aber auch sagen, dass das Kerngeschäft mit dem Basis OS immer unwichtiger wird. Die Distribution an sich spielt immer weniger eine Rolle in Zeiten von Containerlösungen wie Docker oder Kubernetes. Am Ende will man einfach nur einen Kernel und ein paar GNU Tools. Der Rest kommt sowieso aus einer externen Quelle. Auch hier im Enterprise Umfeld wird immer mehr mit Containern gearbeitet. Da stellt sich durchaus die Frage warum man eigentlich für die Lizenzen so viel bezahlen soll. Am Ende kochen alle Distributionen nur mit Wasser. Und das Wasser von RHEL ist zudem auch noch ziemlich alt und muffig, was sich gerade in der Welt der Automatisierung und Virtualisierung negativ bemerkbar macht. Als Kubernetes Node eignet sich z.B. ein Fedora um einiges besser als ein veraltetes RHEL, weil schlicht der Kernel neuer ist oder auch die Python Version.

Meiner Meinung nach lohnt sich RHEL eigentlich nur, wenn man irgendwelche Legacy Software hat, die nur für bestimmte Distributionen zertifiziert ist und man es daher einsetzen muss. Und wenn man dann doch recht viel aus den RHEL Quellen nutzen will, kommt man meist um EPEL nicht drum herum, weil z.B. die Auswahl an Python oder PHP Pakete sehr begrenzt ist und einiges nur in EPEL zu finden ist. Und dort ist die Qualität bei weitem nicht so wie aus den Standard RHEL Quellen.

Das einzig wirklich gute an RHEL sind eigentlich die Security Advisories. Wenn man dafür bezahlen will, kann ich das gut verstehen. Aber dann spielt meist auch Geld keine wirkliche Rolle mehr.

Aber RedHat hat das ja auch erkannt und bewirbt ja auch seine anderen Services (z.B. Openshift) deutlich mehr als das "langweilige" RHEL.

Daher ist es mir immer noch ein Rätsel, warum RedHat den Schritt mit CentOS gemacht hat. Sie wissen eigentlich selbst am besten, dass das Kerngeschäft mit dem OS nicht mehr so skalieren kann wie in der Vergangenheit und es eigentlich klüger wäre, viele Entwickler und User anzulocken um dann später die wirklich interessanten Services verkaufen zu können.

Sehe ich auch so. Aber es gibt auch (unerklärliche) Ausnahmen: Wir nutzen in unserem Unternehmen eine ERP Software und deren Hersteller supported nur Red Hat, obwohl die Applikation mittels Docker läuft…

Das Thema mit dem langsamen Support besteht nun seit locker einem Jahr, wenn nicht sogar schon länger. Auch die Moderatoren hier lesen zwar mit, scheinen das aber nie intern bei Meetings anzusprechen. Oder sie tun’s und den CEOs ist’s egal. Nun ist‘s zwar extrem, aber man sieht ja wo die Prioritäten liegen: Quantität > Qualität.

Ich bin ebenfalls sehr enttäuscht (mein Ticket auch seit einer Woche unbearbeitet, wo‘s um Netzwerkperformance / ggf. Routingprobleme geht)) und sehe mich nach Alternativen um. Zwar schade, aber wenn gerechtfertigtes Meckern kein Gehör findet, dann muss man eben mit der Geldbörse protestieren.

Zitat von johnassel

Interesting. So it seems that some server's traffic is routed different even if the are at the same location. Maybe different datacenters here?

Theres only one DC, that's for sure.

Würde mich auch interessieren, fast nicht möglich^^

Zitat von H6G

Netcup war bereits vorher auf der Discounter-Schiene. Vorher gab es auch nur das Notwendigste an Support.

Es scheitert gerade daran, dieses Level zu halten.

Die Produkte sind aber noch zu gut, um die Schiene als Temu / AliExpress zu bezeichnen.

Eben, damals erhielt man wenigstens am selben Tag meist noch eine Antwort…

Preis/Leistung stimmt bei Netcup noch immer, auch die Verfügbarkeit - aber der Support bereitet mir langsam Sorgen, was mich schok seit geraumer Zeit zu anderen Anbietern schielen lässt. Ich weiß nicht, ob man unter Anexia mit Netcup einfach die komplette Discounter-Schiene fahren will. Zwar mit guten Produkten, aber wenig Support.

I‘ve opened a ticket with Netcup, however i don‘t expect an answer soon.

Looks like the issue persists only over IPv6, not over IPv4. Is that the case for you too?

Auch von mir ein Frohes Neues!

It look‘s like there are some problems in Vienna. My backup to a Storagebox is in Germany from another provider (the red one) and the speed is abou 20 mbit/s, usually it was 1-2 Gbit/s

Ich nehm’ mir gar nichts mehr vor, wie‘s kommt, so kommt‘s - und die anderen Ziele verfolge ich unabhängig ob Silvester ist oder nicht.

Euch allen dennoch einen guten Rutsch.

Busy bedeutet nichts anderes, als das die Gegenstelle derzeit ausgelastet ist - das ist kein Problem auf deinem Server. Einfach später nochmal probieren.

Zitat von sla

richtig, aber eine Geschwindigkeit wird dir nicht zugesichert. Ich bin genau so Kunde wie du auch und lache da mittlerweile nur noch drüber wie sich netcup den eigenen Ruf immer mehr zerstört. Produktives sollte man hier nicht laufen lassen, brauchst du Restore-Funktionen schaust du schlimmstenfalls in die Röhre, so wie hier.

Bis jetzt sind Uploads im KB-Bereich nicht mal einen Eintrag auf der Stautsseite würdig.

Ich bin jetzt bei weitem kein Fanboy, aber ich nutze netcup jetzt seit bald drei Jahren produktiv und hatte - bis auf das eine Steal-Problem - nichts großartig zu bemängeln, auch (fast) keine Ausfälle, schon gar keine langen. Was genau ist jetzt nicht produktivwürdig? Die Arm-Server? Das Netzwerk?

Der Support hat stark nachgelassen, das stimmt - aber ich denke, das weiß man bei netcup auch - nur wird netcup alleine nichts daran ändern können, wenn die Anexia-Tochter das Geld diktiert. Aber da kann ich mich auch irren.

Der Upload ist auch bei den x86 Servern langsam, scheint also ein Problem mit dem S3-Storage zu sein. Auch witzig: Der Upload funktioniert schneller mit einem externen Provider, netcup-intern kriecht er wie nichts dahin...

Es gibt keine Möglichkeit ohne Virtualisierungsflag das zum Laufen zu bekommen.

Zitat von frank_m

Das ist meines Erachtens nicht optimal, weil Wireguard mit UDP arbeitet. UDP Port 443 ist in den meisten Firewalls nicht offen, sondern nur TCP.

Wenn man Wireguard nativ machen will, dann eher auf Port 500 UDP. Der ist in vielen Firewalls offen für IPSec. Alternativ OpenVPN auf TCP Port 443, das klappt sehr häufig.

Stimmt, OpenVPN - die Idee mit 500 UDP ist gut!

Viele Webhosting-Unternehmen setzen Cloudlinux ein, eben wegen der angeblich guten Sicherheit (Art Cages). Support gibt‘s auch, ist übrigens von den Machern von KernelCare, die auch Almalinux ins Leben gerufen haben.

Witzig, dass die AI nicht mal weiß auf was die Distribution basiert.