Microsoft Defender for Linux na SEGach

czyli dlaczego praca w Korpo powoduje siwiznę

Mamy w Korpo nowego Klienta. Klient wykupił (hosting) serwery na SAPy, SRAPy i inne bazy danych.Klient zarządził, że serwery muszą być takie-a-takie, na RedHacie, chronione firewallem i antywirusem Microsoft Defender for Linux.

Oczywiście te serwery potrzebują wysyłać pocztę. Tutaj wchodzi mój zespół. Nasze bramki pocztowe (SEG) są zbudowane na Ubuntu, mamy własnego antywirusa (ClamAV) - dedykowanego do skanowania poczty. Są to osobne serwery i z reguły mówimy, żeby żaden inny zespół nam się na nie nie wpierdalał.

A Secure Email Gateway (SEG) is a cybersecurity solution that acts as a filter for both inbound and outbound email traffic, protecting organizations from threats like phishing, malware, and spam. It uses signature analysis, machine learning, and content inspection to analyze, scan, and block malicious messages.

I tu powstaje konflikt. Klient na początku narzucił Microsoft Defender for Linux, moje Korpo powtarza to jak mantrę, w ogóle nie rozumiejąc, że nasze serwery to nie są SAPy.

Techniczne wytłumaczenie dlaczego Microsoft Defender for Linux nie jest kompatybilny z SEG:

Otworzenie pliku do odczytu trigeruje jego przeskanowanie przez Microsoft Defender for Linux. Jeżeli w środku jest wirus - plik jest usuwany.

Amavis dzieli emaila na części (spłycając: na załączniki), zapisując je w osobnych plikach na dysku. ClamAV ma zadanie te pliki przeskanować. Jeżeli MDfL usunie taki plik przed ClamAV to, co jest chyba oczywiste, ClamAV nie znajdzie tam wirusa. Email (z wirusem) zostanie przepuszczony jako "czysty".

Co zrobić, jak żyć?

instalacja mdatp:

hostnamectl
curl -o /etc/apt/sources.list.d/microsoft.list https://packages.microsoft.com/config/ubuntu/22.04/prod.list
curl -sSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/microsoft.gpg > /dev/null

apt update
apt install mdatp

systemctl status mdatp

Sprawdzenie, że Lemat nie pierdoli głupot polegałoby na ściągnięciu EICARA

mdatp config real-time-protection --value enabled
curl -o /tmp/eicar_com.zip https://secure.eicar.org/eicar_com.zip
curl -o /tmp/eicarcom2.zip https://secure.eicar.org/eicarcom2.zip

mdatp threat list

Jeżeli Defender działa to plik powinien zniknąć jak tylko coś spróbuje go odczytać.

WYłączenie skanowania real-time:

mdatp config passive-mode --value enabled
mdatp config real-time-protection --value disabled

Sprawdzenie ustawień:

mdatp health --field healthy
mdatp health --field definitions_status
mdatp health --field real_time_protection_enabled

Dodanie wyjątków, na wszelki wypadek, gdyby jakaś korporacyjna owca włączyła Defendera:

mdatp exclusion folder add --path /var/lib/clamav 
mdatp exclusion folder add --path /var/log/clamav 
mdatp exclusion folder add --path /run/clamav 
mdatp exclusion folder add --path /var/spool
mdatp exclusion folder add --path /var/mail
mdatp exclusion folder add --path /var/lib/amavis
mdatp exclusion folder add --path /tmp

mdatp exclusion process add --name clamscan 
mdatp exclusion process add --name clamd 
mdatp exclusion process add --name freshclam 

Jeżeli Wasz ClamAV ma włączone skanowanie real-time to też należy to wyłączyć aby nie powodować konfliktów:

nano /etc/clamav/clamd.conf 
Add these lines: 

ExcludePath /opt/microsoft 
ExcludePath /var/opt/microsoft 
ExcludePath /var/log/microsoft 
ExcludePath /etc/opt/microsoft 

Make sure any OnAccessIncludePath is disabled or missing
#OnAccessIncludePath / 
#OnAccessIncludePath /home 
#OnAccessIncludePath /srv 

Restart: 
systemctl restart clamav-daemon 

Dlaczego Lemat walczy z korporacyjną głupotą?

Bo jak pracuję z emailami, które zawierają spam i wirusy (bo taka jest moja praca) to jak mi coś "zniknie" plik, nad którym właśnie pracuję - to się wkurzę.

Przykład: jeżeli jest fala wirusów/spamu to oglądam sobie nagłówki aby wyszukać cechy wspólne i zrobić regułkę blokującą.