[ PROXMOX ] - Debian 11 schlechte Performance beim SSH Login

Ich habe festgestellt das wenn man einen LXC mit Debian 11 auf einem Proxmox laufen lässt, die Performance auf ssh ziemlich schlecht ist. Auch sudo dauert ziemlich lange (wenn man es verwendet)

Das liegt am Service systemd-logind wenn man diesen deaktiviert hat man wieder die gewohnte Performance.

Um zu verifizieren ob es an diesem Service liegt , grept einfach mal nach 'org.freedesktop.login1' in der Datei /var/log/auth.log
grep 'org.freedesktop.login1' /var/log/auth.log
wenn ihr dort Einträge findet, die wie folgt aussehen, liegt es vermutlich an diesem Dienst.
Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Problem wird dann mit diesen Befehl behoben (muss als root ausgeführt werden)
systemctl mask systemd-logind && pam-auth-update

spring4shell : vulnerability scanner

Nach log4j kommt spring4shell , langsam nervt das ;(

Ein Kollege hat hier einen vulnerability scanner geschrieben um verdächtige Klassen auf einem System zu finden. z.G. ist das Tool in GO geschrieben und kann für jede Plattform kompiliert werden. Nachdem ich das jetzt bereits ausgiebig im Einsatz habe, kann ich sagen, das macht das Leben leichter.
https://github.com/hillu/local-spring-vuln-scanner

gnome-flashback : disable desktop

Ich benutze hier ein i3wm in Verbindung mit gnome-flashback, hier wird jedesmal ein Desktop gestartet. Um das zu unterbinden kann man mit dem dconf Editor den Desktop auf false setzen
dconf write /org/gnome/gnome-flashback/desktop false

um nur die icons zu deaktiveren kann man diesen Befehl absetzen
gsettings set org.gnome.gnome-flashback.desktop show-icons false

und um das komplett zu machen , um nur einige Icons zu entfernen kann diese Kette verwendet werden
gsettings set org.gnome.gnome-flashback.desktop.icons show-home false
gsettings set org.gnome.gnome-flashback.desktop.icons show-trash false

POWERSHELL : scan nach log4j

aus gegebenen anlass hier ein kleines Powershell wie man nach jar files schauen kann. Das Array mit den Pfaden kann beliebig erweitert werden.

$SearchPath = @(${env:ProgramFiles} , ${env:ProgramFiles(x86)} , ${env:JAVA_HOME} , 'D:\Program Files' , 'D:\Program Files (86)' , 'D:\Tools')
$FilesFound = @()
$FileSearch = 'log4*.jar'
foreach ($Path in $SearchPath)
{
    $FilesFound += (Get-ChildItem -Path ${Path} -Filter ${FileSearch} -Recurse -ErrorAction SilentlyContinue)
}
if ($FilesFound) 
{
Write-Output ('{0} found on system , please check files' -f ${FileSearch})
Write-Output '------------------------------'
$FilesFound
}
else
{
Write-Output ('{0} not found on system' -f ${FileSearch})
}


Hier gibts das alles nochmal in Professionell ;-)
https://hochwald.net/post/powershell-based-log4j-vulnerabilities-scanner/


https://logging.apache.org/log4j/1.2/
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://www.randori.com/blog/cve-2021-44228/
https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2021/211211_log4Shell_WarnstufeRot.html

Hier gibts noch einen Scanner für das Problem :
https://github.com/hillu/local-log4j-vuln-scanner

Proxmox : LXC Unprivileged konvertieren zu Privileged

Ich setzte zuhause Proxmox ein und lasse alles auf LXC laufen, da es einiges an Overhead spart.
Normalerweise läuft ein LXC als "Unprivileged container" in machen Fällen kann es jedoch vorkommen das ein LXC als "Privileged container" laufen muss. Ein konvertieren des LXC ist nur über einen kleinen Umweg möglich.

Das einfachste Vorgehen :

1.) Stoppen des LXCs (in meinen Fall 102)
2.) einen Snapshot des LXC erstellen
2.) Diesen Snapshot dann als neue Maschine (hier 103) restoren und den Parameter für unprivileged auf 0 setzen
pct restore 103 /var/lib/vz/dump/vzdump-lxc-102-2021_11_18-22_49_58.tar.zst -ignore-unpack-errors 1 -unprivileged 0 --storage ZFS-DATA

3.) Starten des LXC

Dieses Vorgehen sollte aber nur verwendet werden wenn es GAR NICHT anders geht ;-)

Privileged containers: container uid 0 is mapped to the host's uid 0.
Unprivileged containers: container uid 0 is mapped to an unprivileged user on the host.

das bedeutet bei einem Privileged containers ist der user root im container auch der root user auf dem proxmox host

Proxmox : https://www.proxmox.com/de/
LXC : https://de.wikipedia.org/wiki/LXC
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)