MS Exchange 2022 Bug

infoguru — Mon, 03 Jan 2022 15:19:41 +0000

Da hat man sich bei Microsoft wohl gedacht, dass man schon lange keinen Millenium Bug mehr hatte… 😉
Aber Spaß beiseite, erst mal frohes neues Jahr an alle da draußen!

Falls Ihr zu den Menschen gehört die in Euren Firmen die Mail-Server administrieren, oder Ihr einfach neugierig seid, welcher interessante Fehlerteufel sich am 01.01.2022 beim Microsoft Exchange Server eingeschlichen hat, dürfte Euch unsere kleine Zusammenfassung interessieren!

Seit dem 01.01.2022 um 0:00 Uhr hat ein Großteil der on premise gehosteten Microsoft Exchange Server ein Problem mit dem Mailverkehr. Daran ist jedoch zur Abwechslung mal nicht der Transport Agent schuld, sondern der Schadsoftwarefilter.

Der Virenscanner FIP-FS Scan Engine meldet einen Fehler mit dem Text „Can’t Convert ‚2201010001‘ to long“.
Der „größte“ Long ist 2.147.483.647, Datumsangaben im Jahr 2022 haben jedoch einen Mindestwert von 2.201.010.001.

Dieser Fehler hat außerordentlich viele Systeme betroffen, da die FIP-FS Anti-Spam- und Anti-Malware-Scan-Engine seitens Microsoft seit dem Exchange Server 2013 standardmäßig aktiviert ist.

Malware Agent deaktivieren – Exchange Management Shell

Zum Glück lässt sich der Fehler schnell kurzfristig umgehen, allerdings leider nur in dem der Malware Agent deaktiviert wird. Zur Behebung des Problems könnt ihr mit den folgenden beiden Zeilen in der Exchange Management Shell den Malware Agent deaktivieren und anschließend den Transport Service neu starten, wonach Euer Microsoft Exchange Server auch im Jahr 2022 wieder ordnungsgemäß arbeiten sollte:

Powershell-Befehl Get-Transportagent "Malware Agent" | Disable-Transportagent Restart-Service MSExchangeTransport

Wenn das sauber funktioniert hat, so seht Ihr bei der nachfolgenden Überprüfung folgende Ausgabe:

In einigen Fällen kann es sein, dass der MSExchangeTransport beim Neustarten Schwierigkeiten hat, in diesem Fall könnt Ihr den Dienst auch über die GUI neu starten, oder den ganzen Server rebooten.

MSExchangeTransport über die GUI neu starten:

Für den Weg über die GUI ruft Ihr zunächst die Dienste auf

Hier sucht Ihr nun den Microsoft Exchange-Transport Dienst heraus und startet diesen neu:

Nun sollte Euer Microsoft Exchange Mailserver wieder funktionieren und gut für 2022 gewappnet sein 😉

Wenn Euch dieser Beitrag gefallen hat schreibt uns oder besucht uns auf einem unserer Social Media Kanäle und lasst einen Like oder Kommentar da!

Der Beitrag MS Exchange 2022 Bug erschien zuerst auf Informatik Guru.

Forkbomb

infoguru — Fri, 25 Jan 2019 18:15:02 +0000

Unter einer „Forkbomb“ versteht man ein Programm, welches sich rekursiv selbst kopiert bzw. sich selbst erneut aufruft.
In Unix bspw. funktioniert das unter anderem durch den Systemcall „fork“ in Endlosschleife.

Hierbei entstehen in sehr kurzer Zeit enorm viele Prozesse, da die Vermehrung exponentiell vonstattengeht.
Jede Kopie ruft immer weitere Kopien hervor.[2, 4, 8, 16 usw.]
Nach zehn Zyklen existieren 1024 Prozesse, nach zwanzig Zyklen sind es bereits 1.048.576.
Demnach ist arbeiten nach kürzester Zeit nicht mehr möglich.

In einer Windows-Batch funktioniert dies bspw wie folgt:
@echo off
:start
start „Forkbomb“ /high %0
goto start

Oder in der Kurzform:

%0|%0

Plattformunabhängig in Perl:

perl -e „fork while fork“

In Bash:

function forkbomb() { #Deklaration der Funktion „forkbomb“
forkbomb | forkbomb& #Rekursiver Aufruf der Funktion
}
f #Aufruf der Funktion

Stark verkürzt:

:(){ :|:& };:

Hierbei wird die Funktion ‚:‘ deklariert, die zwei Kopien von sich selbst aufruft ‚:|:‘ und diese im Hintergrund ausführt ‚&‘.
Diese wird nach dem Kommandoseparator ‚;‘ aufgerufen.

Gegenmaßnahme in den meisten Linux-Distributionen:

Man kann einer Obergrenze für die Anzahl ausgeführter Prozesse pro Benutzer festlegen in der:

/etc/security/limits.conf

Diese ist wie folgt aufgebaut:

# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#
#
#Where:
# can be:
# – a user name
# – a group name, with @group syntax
# – the wildcard *, for default entry
# – the wildcard %, can be also used with %group syntax,
# for maxlogin limit
# – NOTE: group and wildcard limits are not applied to root.
# To apply a limit to the root user, must be
# the literal username root.
#
# can have the two values:
# – „soft“ for enforcing the soft limits
# – „hard“ for enforcing hard limits
#
# can be one of the following:
# – core – limits the core file size (KB)
# – data – max data size (KB)
# – fsize – maximum filesize (KB)
# – memlock – max locked-in-memory address space (KB)
# – nofile – max number of open files
# – rss – max resident set size (KB)
# – stack – max stack size (KB)
# – cpu – max CPU time (MIN)
# – nproc – max number of processes
# – as – address space limit (KB)
# – maxlogins – max number of logins for this user
# – maxsyslogins – max number of logins on the system
# – priority – the priority to run user process with
# – locks – max number of file locks the user can hold
# – sigpending – max number of pending signals
# – msgqueue – max memory used by POSIX message queues (bytes)
# – nice – max nice priority allowed to raise to values: [-20, 19]
# – rtprio – max realtime priority
# – chroot – change root to directory (Debian-specific)
#
#
#

#* soft core 0
#root hard core 100000

Der Beitrag Forkbomb erschien zuerst auf Informatik Guru.

erklärbär Archive - Informatik Guru