Beiträge von foto-andreas

Hi,

stimmt, es gibt nach Installation keine Benutzer Ubuntu, der wird später durch eine Ansible-Installation erstellt. Macht es aber nicht besser, denn dann hat die sudoers-Datei nach Installation da absolut gar nichts zu suchen.

Ja, wir werden ab jetzt einige Dinge anders machen. Mein Anliegen hier war, euch zu warnen und einfach mal nachzusehen, was in dieser Hinsicht auf euren Servern los ist.

Eine Info an den Netcup-Service ist raus, um das für die Zukunft abzustellen.

Andreas

Es wurde explizit Cloud-Init nicht als Image-Variante ausgewählt und frühere Images hatten das definitiv ja auch nicht.

Hallo,

ich habe auf einem von mir betreuten Server ein unerlaubtes sudo zu root geloggt. Die Nachforschung hat ergeben, dass offenbar seit einiger Zeit ein Standard-Ubuntu 24.04 Netcup-Image (definitiv NICHT in der cloudimg-Version sondern in der BIOS-Version) eine unerwünschte Datei in /etc/sudoers.d ablegt: Ich habe das soeben auf einem Testsystem noch einmal überprüft.

> cd /etc/sudoers.d/
> ll
total 16
drwxr-x---   2 root root 4096 Feb 13 17:24 ./
drwxr-xr-x 106 root root 4096 Feb 14 09:28 ../
-r--r-----   1 root root  139 Feb 13 17:24 90-cloud-init-users
-r--r-----   1 root root 1068 Jan 29  2024 README
> cat 90-cloud-init-users
# Created by cloud-init v. 25.2-0ubuntu1~24.04.1 on Fri, 13 Feb 2026 16:24:40 +0000


# User rules for ubuntu
ubuntu ALL=(ALL) NOPASSWD:ALL

Hier wird standardmäßig dem Benutzer ubuntu allgemeiner Root-Zugriff gestattet. Das ist unserer Erachtens ein maßloses unerwartetes Sicherheitsloch.

Es sind diverse Server von uns betroffen, die in den letzten Wochen neu aufgesetzt wurden. Es KÖNNTE sein, dass das Problem seit etwa dem 301.2026 besteht.

Schaut auf euren Servern nach, ob das bei euch auch der Fall ist und trefft Gegenmaßnahmen!

LG Andreas

Hi,

habe gestern Abend vom Support eine Info bekommen, dass sie vermutlich den Fehler gefunden und korrigiert haben. Von einem der Server gehts mit 1500 nun. Ich warte noch auf Bestätigung, dass die Korrektur für alle sechs gilt.

KB19 Wenn ich ein System neu vom Image aufsetze und keine Firewalls einstelle, ist auch keine aktiv. Das kann ich noch so oft kontrollieren. Und wenn es nach einer Änderung der MTU funktioniert, umgehe ich dadurch definitiv nicht eine Firewall, falls sie installiert wäre.

Andreas

Neu aufsetzen war nix, MTU auf 1450 setzen hat offenbar Verbesserung gebracht. Ist aber doof, dass die Standardinstallation versagt.

Also MTU auf 1450 setzen für das Interface, gemütlich rebooten und es geht jetzt erstmal. Ich verstehe nur nicht, warum die Defaults sich hier von Root-Server zu Root-Server unterscheiden.

Erstmal vielen Dank. Ich teste dann mal weiter!

* Firewalls sind aus

* max ICMP 1450 sowohl ins Internet als auch ins vLAN

Aber:

time while ping -s $size -c1 -M do 172.16.1.1 >&/dev/null; do    ((size+=4)); done
real    0m10,002s
user    0m0,000s
sys     0m0,003s


time while ping -s $size -c1 -M do google.com >&/dev/null; do    ((size+=4)); done
real    0m1,061s
user    0m0,000s
sys     0m0,003s

Neu aufsetzen probiere ich dann auch gleich mal...

Gleiches Problem bei uns. Ping geht, alles andere (NFS, telnet, ssh) nicht. Alle 6 am letzten Donnerstag bestellten Server sind betroffen. MTUs stehen auf 1500. Server wie die alten auch mit Ansible aufgesetzt.

ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
altname enp0s3
altname ens3
inet 152.53.135.215/22 brd 152.53.135.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
altname enp0s4
altname ens4
inet 172.16.3.34/16 brd 172.16.255.255 scope global eth1
valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever


ip -4 r
default via 152.53.132.1 dev eth0 proto static
152.53.132.0/22 dev eth0 proto kernel scope link src 152.53.135.215
172.16.0.0/16 dev eth1 proto kernel scope link src 172.16.3.34
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown


ip -4 n
152.53.132.3 dev eth0 lladdr bc:0f:fe:30:a8:43 STALE
152.53.135.48 dev eth0 lladdr 96:45:a5:a9:0d:28 STALE
152.53.132.1 dev eth0 lladdr 00:00:5e:00:01:96 REACHABLE
172.16.1.1 dev eth1 lladdr a6:60:3e:09:63:e3 DELAY

Keine Reaktion vom Service.

Andreas

ich hab dazu such schon mit dem Support rumgekaspert. Mit wenig Erfolg. Aktueller Chrome, auch mit privaten Fenster.

In der Auflistung oben kann man noch ergänzen, dass Server mit Snapshots nicht live umgezogen werden können auf ein anderes Hostsystem

Andreas

Lieber früher als später bitte, bitte, bitte

Andreas

Jepp, auf eine Antwort zu meinemTicket von Freitag warte ich auch noch...

Keine Antwort vom Support, scheint aber wieder zu gehen.

Andreas

Hallo,

Vorsicht aktuell bei Neuinstallation über das SCP. Ich habe auf mehreren VServern nach Neuinstallation von Ubuntu 22.04 weiterhin das alte System drauf. Entweder ist das Image falsch verlinkt oder es wird nicht installiert. Bei einigen Servern bekomme ich Fehlermeldungen, dass der Server nicht zu starten geht, läuft aber weiter. Serviceticket ist losgeschickt.

Andreas

Hier unser Ansible-Playbook für Ubuntu 20.04

---


# DNS-Server anpassen, bei NetCup schon mal sinnvoll


- name: DNS-Serverliste anpassen


hosts: ......


tasks:


# alte Zeile:
# DNS=46.38.225.230 46.38.252.230 2a03:4000:0:1::e1e6 2a03:4000:8000::fce6
- name: add 1st level servers Cloudflare
lineinfile:
path: /etc/systemd/resolved.conf
regex: ^(# *)?DNS=
line: 'DNS=1.0.0.1 1.1.1.1 2606:4700:4700::1111 2606:4700:4700::1001'


- name: add fallback servers Google
lineinfile:
path: /etc/systemd/resolved.conf
regex: ^(# *)?FallbackDNS=
line: 'FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844'


- name: restart resolve daemon
service:
name: systemd-resolved
state: restarted

Wir hatten seit Monaten immer wieder solche Probleme mit den NetCup-Mailservern. Seitdem wir auf Google+Cloudflare eingestellt haben, ist Ruhe.

Hi,

imzwischen fleißig den Spam-Learn benutzt, aber es werden nur ein paar Mails zusätzlich zum normalen Spamfilter erwischt.

doof.

Andreas

Zwischenstand: Bisher arbeitet der separate angelernte Spam-Assassin ich merklich besser als der von NetCup. Ich teste aber weiter damit.

Andreas

Bei mir ist das seit Jahren eine Katastrophe. Hab dein Posting als Anlass genommen, mal zu suchen und bin auf isbg (github) gestoßen. Das läuft auf einer getrennten Kiste und räumt per selbst zu konfigurierendem spamassassin ein Remote-Imap-Postfach auf.

ich habs gestern Abend mal installiert suf einem kleinen vserver und schau mal, ob man dadurch Verbesserungen bekommt.

Andreas