Beiträge von TEN

BTW auch ein swapoff -a bringt das Serverchen unter Debian 11.1 (i386) nicht um:

top - 12:38:28 up 2:12, 1 user, load average: 0.08, 0.03, 0.00

Tasks: 67 total, 1 running, 66 sleeping, 0 stopped, 0 zombie

%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

MiB Mem : 113.5 total, 39.8 free, 31.6 used, 42.2 buff/cache

MiB Swap: 0.0 total, 0.0 free, 0.0 used. 76.0 avail Mem

Also über einen längeren Zeitraum auszutesten, ob besser mit oder ohne Swap (auf virtualisierter "Platte").

Freilich findet sich in /var/log/syslog bzw. /var/log/messages die "WARNING!":

** You are using 32-bit PTI on a 64-bit PCID-capable CPU. **

** Your performance will increase dramatically if you **

** switch to a 64-bit kernel!

...aber der macht sich dann ja auch im Speicher (ggf. zu) breit.

Zitat von Interessent

Funktioniert auch anscheinend nur mit 1 Port, ich brauche aber "alle"...

Scheint nix zu geben. Und angeblich funktionierende Lösungen wurden bisher leider nicht beschrieben

Zitat

The FLOSS is not set. There is no code but what we make for ourselves.

...frei nach John Connor

Typo

Zitat von Holzflasche

VPS 10 G7 habe mir den vor gut 4 Jahren zur einer Sonderaktion geholt.

Ebenso, v.a. quasi im letzten Moment noch ein Fuß(zeh) in IPv4.

Zitat von sebres

Die images von netcup sind alle x64 (OS und kernel), versuch mal ...i386...

Und wenn es geht, noch eine swap Partition (128 oder 256MB) während der Installation anlegen (schadet nie).

...außer der Overhead ebenfalls virtualisierter Platte fällt störender aus, wenn das Maschinchen gar nicht swappen müsste:

top - 16:00:57 up 8 min, 1 user, load average: 0.00, 0.07, 0.06

Tasks: 68 total, 1 running, 67 sleeping, 0 stopped, 0 zombie

%Cpu(s): 0.0 us, 0.3 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.3 si, 0.3 st

MiB Mem : 113.4 total, 13.6 free, 30.7 used, 69.1 buff/cache

MiB Swap: 244.0 total, 244.0 free, 0.0 used. 72.8 avail Mem

Da die dist-upgrades auch ein längerer (Um+)Weg gewesen wären, ebenfalls direkt mit debian-11.1.0-i386-netinst.iso

versucht: Evtl. hätte sich das sogar nervenschonender wie ein netcup-Image unattended (net)installieren lassen?

Zitat von mfnalex

Ein System mit nur ~128 MB hat schon was

Du könntest mal probieren ob es mit der ISO + SWAP klappt, aber ich bezweifele es.

Nur nicht davon abschrecken lassen, dass nach Debian 9 die "minimalen RAM-Anforderungen" verdoppelt wurden:

Hieß es in https://www.debian.org/releases/jessie/i386/ch03s04.html.en zu 128 MB noch "The actual minimum memory requirements are a lot less than the numbers listed in this table. Depending on the architecture, it is possible to install Debian with as little as 20MB (for s390) to 60MB (for amd64). The same goes for the disk space requirements, especially if you pick and choose which applications to install"

...sagt https://www.debian.org/releases/bulls…ch03s04.en.html nun 256 MB verlangend zwar etwas unklar "The minimum values assumes [sic] that swap will be enabled and a non-liveCD image is used. The “No desktop” value assumes that the non-graphical installer is used. The actual minimum memory requirements are a lot less than the numbers listed in this table. With swap enabled, it is possible to
install Debian with as little as 285MB [sic]."

Über das Textmenü des CD-Images geht es aber jedenfalls mit ein paar Stolpersteinchen:

Natürlich warnt der Installer, unter 237 MB RAM nicht zu erwarten, dass alles funktionieren werde,

und mindestens dieses Modulpaket muss man manuell auswählen, damit er die (virtuelle) Netzwerkkarte erkennt:

pasted-from-clipboard.png

Bei der Partitionierung 10.481 GB als primäre ext2-Partition auswählen, damit am Ende der "Platte" noch 256.9 MB für Swap bleiben (falls wirklich ratsam - ggf. nach Installation swapoff zum Vergleichstest).

Neben root verlangt der Installer noch einen User anzulegen, der auch gebraucht wird, s.u.

Vorselektiertes GNOME (als GUI) wählt man wohl besser ab und den "SSH server" hinzu (da die Darstellung im Fortgang der Installation etwas unschön gerät: es gilt die Spalte ganz links außerhalb der eckigen Klammern), um nicht nur per VNC aufs System zu kommen (oder gäbe es auch sonst einen Default statt OpenSSH?):

pasted-from-clipboard.png

Vor Reboot ins neue System nur die "HDD" in der Bootreihenfolge nach vorne schieben, entgegen der Aufforderung nicht das CD-Image aushängen, da es beim ersten Start nochmal verlangt wird.

Will man sich nicht nur als User einloggen und über su arbeiten, muss in /etc/ssh/sshd_config halt noch PermitRootLogin yes und sshd neu gestartet werden.

Überraschend (da https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862013 ja seit 3 Jahren gefixed sein sollte) wird /run laut /etc/mtab zu klein angelegt:

tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=11616k,nr_inodes=2904,mode=700,uid=1000,gid=1000 0 0

Dadurch wird dann der (Re-)Start selbst schlanker Dienste wie lighttpd oder certbot verweigert mit Meldungen wie:

"Failed to reload daemon: Refusing to reload, not enough space available on /run/systemd. Currently, 10.0M are free, but a safety buffer of 16.0M is enforced."

Bis jemand eine dauerhafte Lösung vorschlägt, lässt sich dieses Problem z.B. umgehen mit:

mount -t tmpfs /run -o remount,size=32M,nr_inodes=2904,mode=700,uid=1000,gid=1000

Freilich wäre wünschenswert, sich durch geeignete i386-Images schlanker, noch im Support befindlicher Releases direkt in der netcup-Vorauswahl alle o.g. Klimmzüge ersparen zu können.

Zitat von aRaphael

Naja, eigentlich könnte ich das schon. Über die Konsole, denn der Server läuft ja.

Grml.

Hab ich auch gerade wieder mal.

Das Einspielen des Snapshots hat funktioniert und der Server ist (nach Anpassung der ip) auch per ssh und http erreichbar, aber das SCP hat das offenbar (mal wieder) nicht mitbekommen.

Kann den Server leider nicht herunterfahren...

Nur das spätere Wiederhochfahren wird dann nix.

Alles anzeigen

Leider bekommen auch weder VCP noch SCP mit, wenn sich ein vServer direkt beim Hochfahren des Images z.B. mit Kernel Panic verabschiedet (bei den kleineren aus Speicherplatzmangel nicht selten):

pasted-from-clipboard.png

Wegen des "laufenden Vorgangs" wird dann erst nach stundenlangem Warten auf den Timeout hartes Abschalten / Power Cycle erlaubt, obwohl der Nutzer während auch ACPI nicht mehr reagiert doch wohl seinen guten Grund hat, zum drastischeren Button zu greifen.

Zitat von mropen

auf jeden Fall zunächst mal solche Anfragen automatisch in der Firewall abfackeln. Das geht schneller, effizienter und sicherer als erst darauf zu warten, dass die Anfrage von SSH behandelt wird, dann abgelehnt und geloggt wird und dann Fail2Ban das Log auswertet und die Firewall scharf schaltet.

Die Firewall lässt sich mit iptables, ipset und dem recent Modul schön einrichten: https://www.falk-online.eu/2018/02/04/abs…es-ssh-zugangs/ (siehe Abschnitt "Rate Limiting"). Idealerweise nimmt man heutzutage nftables statt iptables, aber dafür sind die Anleitungen noch etwas spärlich. Fail2Ban deckt dann noch weitere Fälle ab, die die Firewall selbst nicht erkennen kann.

Bin jahrelang ziemlich wartungsfrei mit https://forum.doozan.com/read.php?2,20609,20799#msg-20799 ganz gut gefahren:

Vielleicht ist ja jemand schon so weit in nftables, das auch darauf inkl. der recent-Logik schnell umsetzen zu können?

Zitat von xeon

das BSI scannt einfach nach Servern wo rpcbind oder portmap läuft und schicken dann die Meldungen an den Netzbetreiber.
Wenn wirklich ein Angriff stattgefunden hätte, sähe die E-Mail etwas anders aus. Dann wird glaube ich auch eine Antwort von Netcup verlangt

Zitat von heavygale

Hier ist nicht von einer Abusemeldung sondern von einer Informationsmeldung die Rede

Zitat von [netcup] Felix

betonen, dass die E-Mails zunächst rein informativen Charakter haben. Da die E-Mails von einer Bundesbehörde kommen, möchten wir diese Weiterleiten.

Wir haben den Parser jetzt weiter optimiert, so dass in der Zukunft auch ein Teil des Logs mitgeschickt wird, in dem Informationen zu den IP-Adressen stehen, die der CERT-Bund geprüft hat... Wir teilen nicht alle Bedenken des CERT-Bunds. Es gibt z.B. durchaus sinnvolle Einsatzzwecke von offenen DNS-Resolvern o.ä...

Falls das CERT-Bund seine Wünsche nach "einem anderen (weniger reflection-anfälligen) Internet" selbst an abuse-Adressen der Hoster richten sollte, wäre das schon grenzwertig.

netcup jedenfalls schreibt Kunden mit der "Information" aus alarmierender abuse-Adresse an, evtl. wären ein weniger dramatischer Absender und verständlicher als vom BSI beigefügter Lösungsvorschlag beruhigender.

Will man z.B. Portmap für einzelne IP-Adressen zugänglich lassen, wäre folgendes ein Ansatz, auf eigene Gefahr, bei hinreichenden Kenntnissen:

# https://www.bsi.bund.de/DE/Themen/Cyber-Sicherheit/Aktivitaeten/CERT-Bund/CERT-Reports/HOWTOs/Offene-Portmapper-Dienste/Offene-Portmapper-Dienste_node.html
# https://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-rpc
# https://support.cyberwebhosting.de/index.php?/Knowledgebase/Article/View/62/0
# https://superuser.com/questions/401198/how-to-negate-a-range-in-iptables
iptables -A INPUT -p tcp ! -s 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p tcp -s 127.0.0.1  --dport 111 -j ACCEPT
iptables -A INPUT -p tcp -s 37.221.x.y  --dport 111 -j ACCEPT
iptables -A INPUT -p udp ! -s 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p udp -s 127.0.0.1  --dport 111 -j ACCEPT
iptables -A INPUT -p udp -s 37.221.x.y  --dport 111 -j ACCEPT

Statt 192.168.0.0/24 zur Freigabe empfehlenswerte Netblocks und/oder IPs kann sicher netcup nennen.

Dynamisch greylisten könnte man bei Bedarf z.B. in Anlehnung an https://forum.netcup.de/administration…ffen/#post84657

Zitat von Ympker

per iptables die ssh logins per Minute reduzieren

In Ergänzung zu MaxAuthTries 2 in /etc/ssh/sshd_config (wirkt nach Restart des Dienstes)

ein dynamischerer Vorschlag (nach Lektüre u.g. Dokumentation und auf eigene Gefahr):

# cf. http://forum.doozan.com/read.php?2,20609,20799#msg-20799 et seq.
iptables -N SSHbrute
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m recent --update --seconds 7200 --reap --name SSHbrute --rsource -j DROP
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSHknown --rsource
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 30 --hitcount 2 --name SSHknown --rsource -j SSHbrute
iptables -A SSHbrute -m recent --set --name SSHbrute --rsource -j LOG --log-prefix "SSHbrute "

Wer bzw. wieviel erkannt und ggf. greylisted wird, lässt sich z.B. verfolgen per:

cat /proc/net/xt_recent/SSHknown

cat /proc/net/xt_recent/SSHbrute

watch -d -n 2 iptables -nvL -x

Verdächtige IP-Adressen werden damit für 2 Stunden kaltgestellt - gleichzeitig sperrt man sich auch bei Bedienfehlern selbst nicht länger aus.

Für veränderte Angriffsmuster lassen sich wie unter obiger URL m.w.N. diskutiert verschärfte Filter nachlegen.