Beiträge von tab

Sind fast gleich, die G12 können auf schnelleren Prozessoren laufen als die G11, müssen aber nicht. Aber der Preis ist ja auch identisch. Ich habe einen VPS 1000 G11 in Manassas, der ist etwas schneller als mein VPS 1000 G12 in Nürnberg. Sie laufen wohl derzeit auf gleichen Prozessoren. Jammern auf hohem Niveau, sie sind beide um 50% schneller als mein etwas älterer VPS 1000 G11, den ich mit dem G12 ersetzt habe. Der lief auf älterer Hardware. Alle drei haben 4 vCores, 8 GB RAM und 512 GB Speicher.

Also solange du z.B. nur nginx verwendest ohne Apache bei den Einstellungen für Apache und nginx (Proxymodus deaktiviert) greift die .htaccess nicht, auch mod_ rewrite funktioniert dann nicht.

Ansonsten funktioniert das bei mir seit vielen Jahren einwandfrei in allen netcup Webhostings.

Zitat von cyberhilfswerk

Nach meinem Verständnis sollte netcup mit dem DNSKEY den DS Record selbst generieren können, und ich muss bei desec gar nichts mehr setzen (außer der AAAA Resource Records etc). Liege ich da falsch?


EDIT: DNSKEY Record einmal gelöscht und neu eingetragen, nun geht es plötzlich. Beeindruckend -.-

Da liegst du nicht falsch. Es ist aber leider so, dass die Delegation gelegentlich hängt und der DS Record nicht gesetzt wird. Hatte ich auch vor einigen Wochen, mit meiner Serverdomain, zu der ca ein Dutzend Server gehört. Nach einem Umzug von meinem alten in meinen neuen Account bei netcup. Vor dem Umzug war alles gut, inklusive DS Record. Ich hatte zum Umzug die Netcup Nameserver wieder eingestellt und danach dann wieder deSEC. Danach wurde dann kein DS Record mehr gefunden.

Deine "Lösung" habe ich damals auch probiert und es hat nicht geklappt. Kürzlich habe ich es dann nochmal versucht, habe auch ein oder zwei Stunden gewartet mit dem neu eintragen nach dem Löschen. Und da hat es dann zum Glück geklappt. Jetzt schlafe ich vorübergehend wieder etwas besser. Vor dem Umzug der Domain hatte ich nie Probleme, jetzt hoffentlich auch für längereZeit nicht.

Zitat von KB19

Diese Phishing-Kampagne ist neu: Dringend: netcup Account-Bestätigung notwendig

Code

netcup.com Logo
security verification required urgent action account restricted authentication 
needed netcup hosting account security check verification code 8856 79MN secure 
portal sicherheitsüberprüfung hosting account zugang beschränkt verifizierung 
erforderlich identitätsverifikation obligatorisch sofortige aktion benötigt 
sicherheitsprotokoll

*Sehr geehrter Kunde,*

Im Rahmen unserer regelmäßigen Sicherheitskontrollen haben wir festgestellt, 
dass Ihr netcup Account eine zusätzliche Überprüfung benötigt.

*Der Zugang zu Ihrem netcup Account wurde vorübergehend eingeschränkt.*
Status:
Account vorübergehend eingeschränkt
Erforderliche Aktion:
Account-Daten verifizieren
Frist:
48 Stunden

Klicken Sie auf die Schaltfläche unten, um die Überprüfung durchzuführen und den 
vollen Zugriff wiederherzustellen:

ACCOUNT VERIFIZIEREN <https://heli-service-triet.ch/NETCUP/index.html>
*Wichtig:* netcup.com fragt niemals nach Passwörtern per E-Mail. Geben Sie Ihre 
Daten nur auf der offiziellen netcup Website ein.

Mit freundlichen Grüßen,
*netcup.com Sicherheitsteam*

© 2024 netcup GmbH. Alle Rechte vorbehalten.

Impressum <https://www.netcup.com/impressum/> Datenschutz <https:// 
www.netcup.com/datenschutz/> AGB <https://www.netcup.com/agb/> Kontakt <https:// 
www.netcup.com/kontakt/> Sicherheit <https://www.netcup.com/sicherheit/>
verifizierungscode: 885679MN | sicherheitsstufe: hoch | priorität: dringend 
netcup hosting account verifizierung erforderlich | zugangsebene: administrativ 
dienststatus: vorübergehend gesperrt | verifizierungsfrist: 48 stunden netcup 
account sicherheitsprüfung | automatische sicherheitssystembenachrichtigung 
alternative verifizierungsverknüpfung: https://heli-service-triet.ch/NETCUP/ 
index.html netcup sicherheitsportal: https://netcup.com/sicherheit/verifizierung 
notfallportal: https://support.netcup.com/dringend/verifizierung ignorieren sie 
diese nachricht nicht. bei nichtverifizierung wird der account gesperrt. die 
sicherheit ihres netcup accounts hat priorität. dies ist keine marketing-e-mail. 
sofortige verifizierung erforderlich, um dauerhafte sperrung zu vermeiden. diese 
nachricht wurde automatisch generiert. antworten sie nicht auf diese e-mail. 
kontaktieren sie den netcup-support nur über offizielle kanäle bei 
verifizierungsproblemen. netcup sicherheitsabteilung | hosting sicherheitsteam | 
account schutzabteilung automatisierte sicherheitsbenachrichtigung | priorität: 
hoch | klassifizierung: vertraulich verifizierungs-ID: NETCUP-SEC-2024-9934 | 
transaktion: TRX-8813-NO23 sichere e-mail-benachrichtigung | verschlüsselte 
nachricht | sicherheitsalarmstufe 3 netcup hosting account schutz | 
automatisches sicherheitssystem | verifizierung erforderlich leiten sie diese e- 
mail nicht weiter | vertrauliche informationen | sicherheitsprotokoll 4B netcup 
GmbH | Daimlerstraße 25 | 76185 Karlsruhe telefon: +49 (0)721 7540755-0 | e- 
mail: support@netcup.com | notfallkontakt: 24/7 verfügbar referenz: #NETCUP- 
SEC-2024-9934 | fallnummer: #CAS-8813-NO23

Alles anzeigen

Das Zeug kommt aktuell von mail-gateway-shared09.cyon.net (194.126.200.60)

/cc Moderatoren

Na dann warte ich mal, bis das auch in Deutschland aufschlägt. Bisher habe ich es noch nicht gesehen.

Dem kann ich mich nur anschliessen, das Paket wog tatsächlich etwa 1,3 kg . Vielen lieben Dank dafür! Jetzt muss ich nur noch herausfinden wie das funktioniert . Aber sollte ja heutzutage kein Problem sein. Zur Not frage ich einfach eine KI. Die wird mir diese Gulaschkanone dann schon erklären I .

Meine Spammails kommen derzeit ausschliesslich von wirren Adressen aus Subdomains von firebaseapp.com, verschickt von Google Mailservern.

Zitat von ASS

Es gibt keine wirklich guten Spamfilter.

Bayesfilter sind mit das kleinse Übel, aber die müssen eben angelernt werden.

An der Spammenge kannst du auch keine Qualität festmachen. Es gibt Zeiten mit viel Spam und mit wenig Spam...

Und derzeit ist mal wieder eine Zeit mit eher viel Spam.

Offensichtlich nur dadurch, dass du netcup davon überzeugst, den Hostnamen und den PTR zu ändern. GMX akzeptiert Defaultnamen nicht, weil Spammer oft Server benutzen und die Defaulteinstellungen belassen. Damit bist du bei GMX eben raus. Das gehört zu deren Mail-Policies. Und wenn Web.de immer noch praktisch 1:1 identisch läuft, dann wohl auch dort. Die beiden sind praktisch Geschwister. Haben ja auch den selben Papa.

Zitat von tab

Ja, mehrere meiner Server zeigen laut Munin gedroppte Pakete an, nicht erst seit gestern. So ca ab dem 3.12. relativ wenige, ab dem 8.12. dann verstärkt.

Das Problem scheint mittlerweile behoben zu sein. Jedenfalls kommen derzeit keine weiteren gedroppten Pakete mehr hinzu, bei den meisten Servern schon seit Tagen, beim letzten (VPS 1000 G12 Pro) seit gestern.

Hatte eigentlich für diese Woche geplant,mit einem piko oder Cyber Quack die Firewall mal in Ruhe selbst auszutesten. Oder mit dem VPS 500 G11s.Aber mit denen geht es noch nicht. Und die anderen will ich nicht alle 5 Minuten unerreichbar machen. Die Firewall steht genau auf all den Servern zur Verfügung, mit denen ich lieber nicht testen will. Wenigstens scheint das zurücksetzen auf Default wohl zuverlässig zu funktionieren, immerhin ein Trost.

Edit: Mit dem VPS 1000 G11 in Manassas scheint es zu funktionieren. Von dem muss ich eh alles auf den VPS 1000 G12 übertragen, das werde ich jetzt mal ein wenig forcieren müssen. Danach kann ich ihn zum Testen nutzen.

Zitat von Niklas434

Die Antwort finde ich angesichts der Probleme frech:
MA und mein Name habe ich aus Datenschutzgründen herausgelassen. Bei einem funktionierenden "Produkt"/AddOn hätte ich mit der Antwort ja leben können aber nicht so

Tja, "42" kennen wir jetzt. Fehlt nur noch die Frage dazu.

Zitat von KB19

Hat hier noch jemand deutlich spürbaren Packet Loss im Nürnberger RZ? Seit gestern betrifft das mehrere vServer aus verschiedenen Generationen, egal ob IPv4 oder IPv6, selbst das Cloud vLAN ist betroffen. Es betrifft sowohl den externen als auch RZ-internen Traffic, aber nicht zwischen allen vServern.

Meine Smokeping-Installationen zeigen erneut nicht viel an, weil es genau diese Verbindungen wohl nicht betrifft oder es dabei nicht lange genug läuft…

Ja, mehrere meiner Server zeigen laut Munin gedroppte Pakete an, nicht erst seit gestern. So ca ab dem 3.12. relativ wenige, ab dem 8.12. dann verstärkt.

Auch Redis nicht, kann mich aber auch täuschen. Man könnte Redis aber nutzen, wenn man einen externen Redis-Server hat, so sind zumindest die PHP-Versionen kompiliert, wenn es immer noch so ist. Aber gut, wer hat schon einen Redis-Server und was bringts, wenn man relativ große Latenzen beim Zugriff übers Netzwerk hat.

Er weiß eben, dass er alle Mails erhält, die er erhält. Das muss reichen. Microsoft Freemailer genauso.

Was ist eigentlich mit den Authcodes los? Die werden mir teilweise von anderen Registraren als ungültig abgelehnt. Dauert das ne Weile, bis die DNS-Server von netcup oder wer auch immer zur Kenntnis nimmt, dass für die Domain ein Authcode erstellt wurde? Oder ist er tatsächlich ungültig? Oder sind die anderen zu blöd einen gültigen Auth-Code zu verwenden? Ich schliesse nichts mehr aus . Den Umzug habe ich versucht in der Hoffnung, dass dabei vom neuen Registrar wenigstens der DS Record wieder in die de Zone eingetragen wird. Der Plan war, die Domain dann dort zu lassen, bis das neue netcup DNS live ist. Aber Pustekuchen, Umzug fehlgeschlagen.

Also habe ich beschlossen, jetzt doch ein Ticket aufzumachen für die Reparatur meiner Domain, zu der immerhin ca 10 Server gehören. Also DS-Record eintragen zu lassen von netcup. Hatte schon angefangen zu schreiben und wollte dafür nochmal bei der Domain was schauen. Keine Ahnung warum, jedenfalls habe ich dabei auch nochmal in den DNS-Editor geschaut und mit Entsetzen festgestellt, dass bei dem missglückten Umzugsversuch wohl noch etwas bei der Domain passiert ist. Die NS waren auf netcup umgestellt und es waren genau gar keine Einträge vorhanden, da die NS bis vor dem Umzugsversuch auf deSEC eingestellt waren. Also habe ich die deSEC Nameserver wieder eingetragen und festgestellt, dass natürlich auch keine DNSSEC Einträge mehr vorhanden waren. Und da dachte ich mir, lass das erst mal ein paar Stunden so, vielleicht hilft es ja. DNSSEC hast du ja eh nicht mehr gehabt, jedenfalls keins das funltioniert hätte. Das habe ich denn auch gemacht und erst danach die DNSSEC-Einträge neu gesetzt.

Und yes!! Nach einer weiteren guten Stunde hat dig mir das ad Flag angezeigt, DNSSEC funktioniert endlich wieder. DNSVIZ zeigt noch die obligatorische Warnung, aber alles wieder secure. Puh. Fast wie Weihnachten. Das fast fertig geschriebene Ticket habe ich gerade gelöscht

Zitat von mmaxx

Vielleicht solltest du auf ein Managed Hosting umsteigen?

??? Und ich dachte immer, die Webhostingpakete bei netcup seien Managed Hosting. Aber gut, vielleicht hat er ja auch einen vServer .

Zitat von webhosting_kunde

Funktioniert diese Vorgehensweise noch? Wenn ja, wie?

Ich muss jetzt die externe Domain verifizieren, in dem ich einen speziellen DNS Eintrag eintragen muss. Da die "externe" Domain, aber nur eine Subdomain ist, kann ich hier keine DNS Einträge machen, solange die "externe" Domain nicht verifiziert ist.

Die DNS-Einträge für externe Domains muss man auch weiterhin extern machen, da wo eben die Nameserver der Domain sind. Für die Subdomain gibt es da vermutlich keine eigene Zone, also muss man eben die Subdomain im Feld Host mit angeben in der Zone der Hauptdomain. Netcup verifiziert nur, dass der geforderte Eintrag gemacht wurde, du also Kontrolle über das DNS der Domain hast. Wenn du die Subdomain als externe Domain verifiziert bekommst, dann wird sie im Plesk/WCP behandelt wie eine "normale" Domain und somit kannst du dann auch Postfächer und Adressen dafür einrichten.

DHCP ist ja wohl verfügbar, wenn die Firewall auf Default steht. Ist aber auch klar, da durch dieangegebene Regel der Default auf INCOMING DROP ANY umschaltet, werden die ICMP-Messages nicht mehr durchgelassen.

Das Problem hatte ich bei Strota schon mit Keyhelp, was ICMP für IPv6 nicht komplett freischaltet in iptables. Dadurch hatte ich dann erst einmal keine IPv6 und musste diese dann statisch hinzufügen. Die IPs statisch zu konfigurieren ist letztlich eh sinnvoller bei einem Server, auch wenn Strota tatsächlich mal die IPv6 mit Ankündigung geändert hat. Die IPs müssen in so einem Fall sowieso auch im DNS der aufgeschalteten Domains geändert werden.

Auch ich bin alt genug, um zumindest die deutsche Bedeutung von "SS" zu kennen und den Namen des Befehls nicht unbedingt als glücklich anzusehen. Und ich habe auch oft genug netstat nachinstalliert. Fakt ist aber, schon seit einiger Zeit ist netstat zumindest in den Minimalversionen von Debian nicht mehr installiert, ss aber wohl.

Zitat von -Manu-

Code

sudo apt install net-tools  

Bei "Minimal"-Versionen (egal welche Distribution) fehlen bewusst viele Anteile an Standardkomponenten.

Das ist keine Standardkomponente mehr. Gibt es natürlich noch und man kann es auch installieren. Aber es ist mttlerweile deprecated seit einigen Jahren. Kannst auch mal schauen ob eventuell ss installiert ist. Das kann das alles auch anzeigen. Das ist der ofizielle "Ersatz" für netstat, zumindest seit Debian Bullseye, eher sogar seit ca 2011.