DANE i MTA-STS

Kilka lat temu pisałem o wchodzących na rynek kolejnych mechanizmach zabezpieczenia poczty - DANE i MTA-STS. Mechanizmy te są od pewnego czasu dostępne w Exchange Online, MTA-STS jest również możliwy do skonfigurowania na innych platformach pocztowych. Niestety, jeżeli chodzi o systemy Exchange on-premises, ciągle nie widać istotnych zmian (podobnie jak ciągły brak DKIM). Microsoft nastawił się przede wszystkim na mechanizmy ochronne Exchange Online. Ponieważ jednak wiele bramek pocztowych pozwala na skonfigurowanie dodatkowych mechanizmów ochrony, warto zweryfikować możliwość skonfigurowania niezbędnych elementów (przynajmniej DKIM).

Innym promowanym przez wielu dostawców poczty w ostatnim czasie rozwiązaniem jest BIMI, który nadal jest ignorowany przez Microsoft, możemy jednak skonfigurować go dla naszej domeny (podobnie jak dla pozostałych mechanizmów konfiguracja w dużej mierze sprowadza się do ustawienia odpowiednich rekordów DNS), tak żeby nie mieć problemów wysyłając pocztę np. do Gmaila. O konfiguracji BIMI będzie mowa w kolejnym wpisie.

Co ważne, konfigurację naszych zabezpieczeń możemy sprawdzić, używając mojego ulubionego serwisu mxtoolbox.com (rysunek poniżej). Interesującą alternatywą jest serwis National Cyber Security Centre, chociaż jeszcze nie wszystkie opcje są dostępne.

Jak zatem skonfigurować naszą domenę pocztową, tak żeby skutecznie wykorzystać DANE  (DNS‑based Authentication of Named Entities) w Exchange Online? Exchange Online implementuje DANE w taki sposób:

1. Ruch wychodzący (z Microsoft 365 do Internetu):
• Exchange Online Protecion (EOP) przy próbie dostarczenia wiadomości do zewnętrznych domen sprawdza, czy domena docelowa ma odpowiednie rekordy MX i TLSA, a strefa jest podpisana DNSSEC.
• Jeśli tak, EOP egzekwuje DANE: nawiązuje TLS, weryfikuje certyfikat serwera odbiorcy zgodnie z polityką TLSA i w razie niezgodności nie dostarcza wiadomości.
• Jeśli TLSA/DNSSEC nie są obecne, EOP stosuje standardowy opportunistic TLS (lub inne mechanizmy polityki, np. MTA‑STS, jeśli są dostępne).
2. Ruch przychodzący (z Internetu do Microsoft 365):
• Microsoft publikuje rekordy TLSA dla swoich hostów MX obsługujących Exchange Online, aby nadawcy wspierający DANE mogli kryptograficznie zweryfikować połączenie TLS do EOP.

Dzięki temu, jeśli nadawca obsługuje DANE, jego MTA będzie wymuszał TLS w drodze do Microsoft 365.

Po stronie Exchange Online nie ma przełącznika „włącz DANE” dla ruchu wychodzącego – obsługa jest automatycznie zapewniana przez platformę od marca 2022. Dla ruchu przychodzącego usługa osiągnęła status GA w roku 2024, podobnie jak dla domen konsumenckich (outlook.com i hotmail). W lutym 2026 roku Microsoft wprowadził również opcję konfiguracji konektorów wysyłających w Exchange Online, tak żeby administrator mógł zdecydować, czy dany konektor ma wymuszoną konfigurację DANE z użyciem DNSSEC, korzysta z opcji domyślnej (negocjacja sposobu zabezpieczenia z serwerem docelowym) czy też DANE jest wyłączony, bo system naszego partnera tego nie potrafi - .

Żeby uprościć konfigurację inbound DANE z użyciem DNSSEC, Microsoft ma w Q3 2026 wprowadzić kreator ułatwiający konfigurację (DNSEC enablement wizard), co właśnie ogłosił na blogu zespół produktowy.

Nie ma potrzeby publikowania samodzielnie rekordów TLSA dla hostów MX należących do Microsoftu - Microsoft je utrzymuje.

Majowe aktualizacje bezpieczeństwa do Exchange

Już niebawem kolejny patch tuesday, ale dla porządku wspomnę o opublikowanych w maju poprawkach bezpieczeństwa dla Exchange:

• Exchange Server 2013 CU23
• Exchange Server 2016 CU22 and CU23
• Exchange Server 2019 CU11 and CU12

Warto wspomnieć, że od tego pakietu Microsoft zmienia sposób instalacji poprawek - zamiast paczki msp, która musiała być instalowana w kontekście administratora, teraz dostarczana jest paczka w formacie exe, z automatyczną eskalacją uprawnień, co powinno pomóc nawet zapominalskim adminom.

Ponadto Microsoft dodatkowo po zainstalowaniu poprawek każe uruchomić ponownie setup.exe z opcją przygotowania wszystkich domen (jednorazowo). Więcej informacji na blogu zespołu produktowego.

Marcowe aktualizacje zabezpieczeń dla Exchange

Kolejny "patch Tuesday" i kolejna łatka na zabezpieczenia serwerów Exchange. W tym miesiącu aktualizacja adresuje dwa problemy opisane w artykułach CVE-2022-23277 (Remote Code Execution) oraz CVE-2022-24463 (Spoofing). Chociaż nie znaleziono jeszcze aktywnych exploitów, wykorzystujących te podatności, to Microsoft zaleca niezwłoczną instalację poprawki. W zależności od wersji należy pobrać odpowiednią paczkę:

• Exchange Server 2013 CU23
• Exchange Server 2016 CU21 and CU22
• Exchange Server 2019 CU10 and CU11

Poprawkę należy instalować ręcznie, w kontekście administratora, ale mam nadzieję, że do tego wszyscy się już przyzwyczaili. Więcej informacji na blogu zespołu produktowego.

Antimalware w Exchange raz jeszcze

Noworoczny problem z aktualizacją silnika Antimalware w serwerach Exchange wywołał sporo dyskusji, które pokazały mi, że nie wszyscy dobrze rozumieją tematy związane z powyższym zagadnieniem. Dodatkowe zamieszanie spowodowała wprowadzona w czerwcu 2021 integracja z AMSI systemu operacyjnego. Należy pamiętać o jednej podstawowej różnicy - starszy mechanizm poprzez agenta transportowego, skanuje pod kątem malware treść i załączniki przesyłanych maili w warstwie transportowej serwera. Integracja z AMSI pozwala poprzez moduł http proxy skanować zapisywane w skrzynce pocztowej wiadomości w trakcie zapisywania/odczytu z użyciem mechanizmów ochrony animalware działających w systemie operacyjnym i również korzystających z AMSI. Uzupełnienie szczególnie istotne dla firm, które nie mają zbyt dobrej ochrony na stacjach roboczych - dostęp do skrzynki zarówno z Outlooka jak i OWA jest dodatkowo weryfikowany.

Problemy z aktualizacjami Antimalware pojawiały się już wielokrotnie - pisałem o tym kilkukrotnie w kontekście Exchange 2013 jak i Exchange 2016. Ale powtórzę raz jeszcze kilka podstawowych kwestii.

Sam komponent od momentu dodania do systemu Exchange specjalnie się nie zmienił, jednak pomimo faktu, że jest dostępny już ponad 8 lat, to nadal część administratorów powtarza ten sam błąd. Po zainstalowaniu serwerów Exchange nie zwraca uwagi na komunikaty generowane przez usługę antimalware (systemowy log aplikacyjny serwera Windows, źródło zdarzeń - usługa FIPFS). Najczęstszym problemem, jaki spotykam, to brak aktualizacji - przeważnie spowodowany brakiem komunikacji z internetem. Warto pamiętać, że usługa Antimalware ma oddzielny moduł powershell do zarządzania i niezależną od systemu operacyjnego i Exchange definicję serwera proxy, który musimy włączyć oddzielnie:

Add-PsSnapin Microsoft.Forefront.Filtering.Management.Powershell

Set-ProxySettings -Enabled <$true | $false> -Server <Name or IP address of proxy server> -Port <TCP port of proxy server>

Więcej informacji można znaleźć w dokumentacji - Download antimalware engine and definition updates.

Jeżeli nie chcemy korzystać z aktualizacji poprzez proxy, możemy pobierać aktualizacje silnika i sygnatur antimalware skryptem update-engines.ps1, udostępnionym na stronach pomocy technicznej, a następnie wskazać usłudze inną niż domyślna ścieżkę aktualizacji. Mając pobrany skrypt oraz utworzony folder (przykładowa nazwa ScanEngineUpdates) na serwerze plikowym FileServer01, który ma służyć jako udział sieciowy do aktualizacji serwerów Exchange uruchamiamy skrypt:
Update-Engines.ps1 -EngineDirPath C:\ScanEngineUpdates\

A następnie na wszystkich serwerach Exchange korzystającym z ochrony antimalware, wywołujemy standardowy skrypt, dostarczony z systemem Exchange

& $env:ExchangeInstallPath\Scripts\Update-MalwareFilteringServer.ps1 -Identity mailbox01.pepug.org -EngineUpdatePath \\FileServer01\ScanEngineUpdates

W ten sposób również osiągniemy aktualizację silnika i sygnatur na naszych serwerach, nawet przy całkowitej blokadzie dostępu tych maszyn do internetu. Oczywiście, jeżeli chcemy, żeby przy kolejnej próbie aktualizacji serwer sięgnął do naszego udziału sieciowego, dobrze jest zmienić podstawową lokalizację aktualizacji komendą:
Set-MalwareFilteringServer mailbox01.pepug.org -PrimaryUpdatePath \\FileServer01\ScanEngineUpdates

Noworoczna niespodzianka dla serwerów Exchange

 Poprzedni rok dla grupy produktowej Exchange nie był dobry - słynna marcowa dziura i wiele serwerów zaatakowanych tą podatnością (pisałem o tym na blogu w marcu aż trzykrotnie - art. 1, art. 2, art. 3), później pojawiły się kolejne problemy bezpieczeństwa, choć nie tak spektakularne, konieczne do łatania prawie w każdym miesiącu. No i ciągle brak nawet słowa o kolejnej wersji systemu, mimo, że miał zostać wydany w 2021 roku.

Ten rok zaczął się od poważnego zgrzytu wkrótce po północy. Silnik animalware - pamiątka po produkcie Forcepoint Protection for Exchange, zaczął szwankować po przekręceniu się licznika na rok 2022. Na wielu serwerach Exchange 2016 i 2019 pojawił się w aplikacyjnym logu systemowym komunikat (Usługa FIPFS, EventID 1106) “The FIP-FS Scan Process failed initialization. Error: 0x80004005. Error Details: Unspecified error”, ewentualnie podobny w treści o numerze 5300, a w kolejkach transportowych zaczęły się gromadzić maile. 

Zespół produktowy zidentyfikował problem i opublikował na swoim blogu opis problemu oraz skrypt do jego rozwiązania - https://aka.ms/ResetScanEngineVersion, który tak naprawdę czyści folder z aktualną wersją silnika Antimalware. Można to zrobić również ręcznie, wykonując poniższe kroki:

1. Zatrzymaj usługę Microsoft Filtering Management service.  Zostaniesz poproszony również o zatrzymanie Microsoft Exchange Transport service, potwierdź "Yes".
2. Sprawdź w Task Managerze, czy updateservice.exe nie jest uruchomiony.
3. Skasuj folder:
    %ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\amd64\Microsoft.
4. Skasuj wszystkie pliki z folderu:
    %ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\metadata.

Teraz tylko ponowne uruchomienie usług, wymuszenie aktualizacji silnika poprzez uruchomienie skryptu z folderu standardowych skryptów Exchange Update-MalwareFilteringServer.ps1 <server FQDN> i powinno działać poprawnie. Kolejki transportowe Exchange zaczną przetwarzać się normalnie.

Ciekawe, ile firm  w poniedziałkowy poranek zauważy ze zgrozą, że ich kolejki transportowe stoją...

Domyślne zabezpieczanie Teams w Edukacji

Temat tworzenia zdalnych spotkań (a zwłaszcza lekcji) w sposób bezpieczny ciągle powraca. Pisałem o tym również na blogu jakiś czas temu. Kilka miesięcy temu Microsoft wprowadził w panelu administracyjnym Teams dla Edukacji rewolucyjną zmianę, która potrafi nieźle zaskoczyć osoby, które nie zaglądają w to miejsce zbyt często. Przy wejściu na stronę https://admin.teams.microsoft.com przywitać może nas okienko proponujące dodatkowe zabezpieczenie (ekran poniżej).

Jeżeli wybierzemy opcję "Zrobię to później" to nic nie zmienimy. Jeżeli jednak wybierzemy przycisk domyślny "Dalej", to przejdziemy do konfiguracji grypy polis zostawiających odpowiednie uprawnienia nauczycielom, a odbierające np. opcje organizacji spotkań i czatowania uczniom. W kolejnym kroku zostaniemy poproszeni o wskazanie grupy, zawierającej nauczycieli

Oczywiście grupa może nazywać się dowolnie - pokój nauczycielski, nauczyciele, pracownicy, itp, jednak musi zawierać wszystkie osoby, które powinny mieć odpowiednie uprawnienia w Teams do organizowania i kierowania spotkaniami. Jeżeli takiej grupy nie wybierzemy, to przechodząc dalej ograniczymy uprawnienia w Teams wszystkim.

Po kliknięciu "Zastosuj" polityki organizacji spotkań i wymiany wiadomości (oraz kilka innych) zostanie zastosowanych.

Warto przeczytać ze zrozumieniem również ekran podsumowania i pamiętać o tym, że zmiana polityk dla dużej organizacji może trwać nawet kilkanaście godzin, więc warto wszystko sprawdzić dwa razy, a najlepiej aplikować zmiany w piątek wieczorem, tak żeby mieć czas na zweryfikowanie zmian w weekend. Jeżeli jednak popełnimy błąd, to nic straconego - kreator możemy uruchomić ponownie z ekranu startowego panelu administracyjnego Teams.

Warto również przeczytać dokumentację, gdzie jest dokładnie opisane, jakie ustawienia kreator modyfikuje.

Listopadowe poprawki bezpieczeństwa dla Exchange i parę przemyśleń

Minęło raptem kilka tygodni od październikowych poprawek bezpieczeństwa dla serwerów Exchange, a tu znowu kolejny wysyp. Czyżby ktoś przeklął administratorów poczty on-premises? Niestety tak bywa. Obserwując poszczególne produkty Microsoft, widać w jakie obszary idzie cały wysiłek koncernu, a gdzie prace zostały mocno spowolnione. Dokładnie rok temu na konferencji Ignite Microsoft ogłaszał wydanie w tym roku kalendarzowym (2021) nowej wersji Exchange, Skype for Business i Sharepoint Server. Niestety, na szumnych zapowiedziach się skończyło. O ile w przypadku Sharepoint Servera, pojawiła się wersja Subscription Edition, z wydaną w lipcu wersją preview, to w przypadku zarówno Skype for Business jak i Exchange, brak informacji o nowych wersjach, nawet testowych. W zeszłym tygodniu odbyła się kolejna konferencja Ignite, na której była jedna (!) sesja o Exchange Online (ale bez ogłaszania żadnych nowości). Pojawiają się co prawda usprawnienia, takie jak aktualizacje modułu administracyjnego powershell, dla którego właśnie pojawiła się wersja preview, umożliwiająca łączenie z chmurą bez konieczności użycia uwierzytelnienia Basic dla WinRM, albo nowy serwis Emergency Mitigation, o którym pisałem w poprzednim poście. Jednak rozwój systemu nie jest już tak dynamiczny jak kiedyś, w końcu trudno coś rewolucyjnego wymyślić po tylu latach stabilizacji funkcjonalności.

Wracając jednak do tematu aktualizacji. Na blogu zespołu produktowego pojawiła się informacja o kolejnych poprawkach, które administratorzy powinni zainstalować jak najszybciej. Poprawka chroni przed opisaną w biuletynie bezpieczeństwa podatnością CVE-2021-42321. Poprawka jest dostępna jak zwykle dla dwóch ostatnich wersji CU serwerów Exchange 2016 i 2019 oraz dodatkowo dla wersji 2013:

• Exchange Server 2013 CU23
• Exchange Server 2016 CU21 lub CU22
• Exchange Server 2019 CU10 and CU11

Oczywiście warto sprawdzić przed instalacją środowisko najnowszą wersją skryptu Health Checker. Dla mniej sprawnych administratorów jest dostępny również kreator, pomagający zaktualizować wersję Exchange. Warto również skorzystać ze środowiska testowego, jeżeli je posiadamy.

Poprawki wrzesień-październik dla Exchange

Dużo ostatnio pracuję i mam lekkie opóźnienie z publikowaniem treści na blogu. Niestety, taki mamy klimat. Ale muszę wspomnieć o poprawkach do Exchange jakie Microsoft wydał we wrześniu i październiku.  28 września opublikowane zostały poprawki Cumulative Updates dla Exchange 2019 i dla Exchange 2016. Pisałem już wcześniej, że Microsoft, ze względu na koniec podstawowego wsparcia dla Exchange 2016 miał zakończyć publikowanie CU dla tej wersji systemu, jednak zgodnie ze starym powiedzieniem "Nigdy nie mów nigdy", musiał zmienić zdanie. Tegoroczny wysyp podatności w Exchange i próby ich opanowania skutkowały kilkoma decyzjami - w czerwcu została wprowadzona integracja z interface'm AMSI systemu operacyjnego, na tyle istotna, że niezbędny był pakiet CU21 (pisałem o tym na tym blogu), a we wrześniu Microsoft dodał do architektury Exchange dodatkową usługę, która ma za zadanie ułatwiać ochronę przed krytycznymi podatnościami - Microsoft Exchange Emergency Mitigation Service, o którym zespół produktowy pisał szczegółowo na swoim blogu. Po marcowym trzęsieniu ziemi z potężną dziurą w zabezpieczeniach Exchange, Microsoft udostępnił dodatkowe narzędzie EOMT (Exchange On-premises Mitigation Tool). Teraz zostało ono dodane jako dodatkowy serwis do usług Exchange, więc konieczny był kolejny pakiet przebudowujący całościowo binaria Exchange.

Warto również wspomnieć, że od wrześniowych pakietów poprawek Microsoft wprowadził opcjonalnie wysyłanie danych diagnostycznych z działania systemu, dlatego też zmieniła się zgoda, którą udzielamy w trakcie instalacji CU. Skutkuje to istotną zmianą w trakcie instalacji z linii komend - zamiast przełącznika /IAcceptExchangeServerLicenseTerms mamy do wyboru dwa alternatywne przełączniki:

/IAcceptExchangeServerLicenseTerms_DiagnosticDataON

/IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

Jak można się domyślać, używając pierwszego przełącznika zgadzamy się na warunki licencyjne i wysyłanie danych diagnostycznych do Microsoftu, drugi przełącznik nie zezwala na wysyłanie takich danych.

Więcej informacji znajdziecie na blogu zespołu produktowego. A tutaj znajdziecie pakiety aktualizacji:

• Exchange Server 2019 Cumulative Update 11 (KB5005334), VLSC Download, Download
• Exchange Server 2016 Cumulative Update 22 (KB5005333), Download, UM Lang Packs

Niecałe dwa tygodnie po wydaniu CU pojawiły się dodatkowo pakiety poprawek bezpieczeństwa, również dla wersji Exchange 2013. Poprawki te adresują podatności opisane w poniższych biuletynach bezpieczeństwa:

• CVE-2021-26427 (Remote Code Execution)
• CVE-2021-41350 (Spoofing)
• CVE-2021-41348 (Elevation of Privilege)
• CVE-2021-34453 (Denial of Service)

Należy pamiętać o tym, że poprawki są udostępnione tylko dla dwóch najnowszych wersji CU. Więc najpierw należy zaktualizować CU do wymaganej wersji. Więcej szczegółów można znaleźć na blogu zespołu produktowego. Stąd można pobrać odpowiednie wersje poprawek:

• Exchange Server 2013 CU23 (dla Exchange 2013 może być potrzebne rozszerzenie schematu /prepareschema.)
• Exchange Server 2016 CU21 oraz CU22
• Exchange Server 2019 CU10 oraz CU11

Zmiany w Azure AD Connect

Ponad rok w aplikacji Azure AD Connect nie widać było żadnych aktualizacji, ale ostatnie miesiące przyniosły istotne zmiany, na które warto zwrócić uwagę i zaaplikować jak najszybciej, zwłaszcza w konktekście znalezionych podatności oraz wygasającego wsparcia dla poszczególnych komponentów.

Wchodząc na stronę historii wersji Azure AD Connect, zobaczymy, że dostępne są dwie ścieżki:

• Azure AD Connect 2.0, do instalacji na serwerze w wersji Windows Server 2016 lub nowszej,
• Azure AD Connect 1.6, do instalacji na starszych wersjach systemu (które już wyszły ze wsparcia lub za chwilę wyjdą)

Co nowego przynosi wersja 2.0? Jest kilka istotnych zmian, w komponentach, które wykorzystuje nowa wersja (więcej informacji w dokumentacji produktu):

• lokalna baza danych w wersji SQL Server 2019 LocalDB. Instalowany w wersji 1.x SQL Server 2012 wychodzi ze wsparcia w lipcu 2022.
• biblioteka uwierzytelnienia MSAL zamiast ADAL, która będzie wycofana w czerwcu 2022,
• TLS 1.2 jako domyślny i jedyny protokół zabezpieczania transmisji (TLS 1.0 i 1.1 są od dluższego czasu oznaczane jako podatne na ataki) - przed aktualizacją musimy ustawić obsługę protokołu TLS w odpowiedniej wersji,
• Visual C++ Redist 14 jako komponent niezbędny dla SQL 2019

Jak możemy zrobić upgrade? Oczywiście jest możliwy upgrade in-place, jeżeli oczywiście mamy serwer w co najmniej wersji 2016, po zakończeniu aktualizacji musimy pamiętać jednak o odinstalowaniu komponentów SQL 2012. Niestety auto-upgrade nie zadziała, musimy pobrać najnowszą wersję produktu i uruchomić proces instalacji samemu.

Po zweryfikowaniu konfiguracji serwera i instalacji dodatkowych składników, kreator poprosi nas o wprowadzenie poświadczeń administratorskich i przejdzie do kroku finalnego (kolejny rysunek).

Możemy również wykorzystać ścieżkę eksportu i importu konfiguracji, kiedy na przykład musimy zmienić wersję systemu operacyjnego. Proces jest dobrze opisany w dokumentacji.

CLM - Ograniczanie możliwości Powershell w środowisku firmowym

Powershell jest moim ulubionym językiem skryptowym, bardzo popularny na platformie Windows i w chmurze, stopniowo zadomawia się również w środowiskach Linux, stał się również zamiennikiem powłoki systemu operacyjnego Windows. Taka popularność rodzi obawy przed możliwymi zagrożeniami, więc warto zastanowić się jak można poprawić bezpieczeństwo środowiska? Od wersji 3.0 wprowadzono w Powershell możliwość włączenia trybu Constrained Language Mode (CLM), co powoduje znaczące ograniczenie możliwości wywołania bardziej zaawansowanych mechanizmów języka (bardziej szczegółowy opis ograniczeń można znaleźć w artykule https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode).

Cmdlety wykonują się poprawnie, jednak przy wywołaniu skryptu możemy zobaczyć komunikat:

Cannot invoke method. Method invocation is supported only on core types in this language mode.

Czyli włączenie CLM, będzie skutkowało koniecznością zweryfikowania wszystkich skryptów, które są wykonywane w tak chronionym kontekście, a nawet zmodyfikowania pliku profilowego.

No dobrze, ale dobrze jest wiedzieć, jak włączyć CLM w naszym środowisku. W ramach pojedynczej sesji Powershell wystarczy wykonać komendę:

$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

Oczywiście, jeżeli uruchomimy drugą sesję Powershell to będzie ona działać w trybie standardowym. Możemy również ponownie zmienić tryb pracy na pełny komendą

$ExecutionContext.SessionState.LanguageMode = "FullLanguage"

Możemy również ustawić zmienną środowiskową __PSLockDownPolicy na wartość 4.  Jednak zalecanym rozwiązaniem w środowisku domenowym Active Directory jest użycie polis GPO, włączając odpowiednie polisy - AppLocker dla komputerów Windows 7 lub nowszych, ewentualnie Windows Defender Application Control dla Windows 10.

Przykładowo, dla applockera tworzymy polisę, w której definiujemy reguły dla skryptów (rysunek poniżej), nie możemy również zapomnieć o wymuszeniu stosowania polisy (kolejny rysunek).

Wymuszenie konfiguracji komputera przez GPO jest trudne do obejścia, nawet dla osoby mającej uprawnienia administracyjne. Warto w takim przypadku spojrzeć na szczegóły polisy opisującej konfigurację applockera dla skryptów. Przy włączonym wymuszeniu stosowania polisy na naszym komputerze, będzie działać tryb CLM we wszystkich lokalizacjach oprócz dopuszczonych przez polisę, gdzie będzie działać pełny tryb języka. Przy domyślnych regułach lokalni administratorzy mogą uruchamiać skrypty bez ograniczeń, a pozostali użytkownicy tylko z folderów Windows i Program Files, ale jeżeli domyślne reguły zostały zmienione, to dobrze jest to sprawdzić, chociażby podglądając ustawienia polisy w konsoli Group Policy Management, jak pokazuje rysunek poniżej.

Majowe poprawki bezpieczeństwa dla Exchange

Mam nadzieję, że wszyscy zainstalowali już majowe poprawki dla serwerów Exchange. W poprzednim artykule wspominałem o tym, że tylko część wykrytych na przełomie marca i kwietnia podatności została uwzględniona w kwietnowym zestawie poprawek, w maju opóźnienia zostały nadrobione. Poprawki można znaleźć na stronach Microsoftu:

• Exchange Server 2013 CU23
• Exchange Server 2016 CU19 and CU20
• Exchange Server 2019 CU8 and CU9

Więcej informacji na temat podatności oraz problemów występujących po zainstalowaniu poprawek można znaleźć na blogu zespołu produktowego Exchange.

Warto również pamiętać o używaniu (i systematycznej aktualizacji) skryptu Exchange Health Checker wskazującego nam nie tylko brak poprawek w naszym środowisku Exchange ale również inne potencjalnie ułomne opcje konfiguracyjne.

Kwietniowe poprawki bezpieczeństwa dla Exchange

Dzisiaj kolejny patch tuesday i pojawiły się poprawki dla Exchange. Po trzęsieniu ziemi, jakie miało miejsce na początku marca i ataku na wiele tysięcy organizacji Exchange, mam nadzieję, że administratorzy systemów pocztowych zaktualizowali swoje serwery i teraz będzie nieco spokojniej. Poprawki zabezpieczają systemy przed czterema podatnościami (jak na razie dosyć niejasno opisanymi w komunikatach bezpieczeństwa). Jak Microsoft twierdzi są to jak na razie zagrożenia teoretyczne (nie ma jeszcze w sieci exploitów wykorzystujących te podatności), ale lepiej nie czekać i łatać przed atakiem. Poniżej linki do paczek instalacyjnych (należy instalować w kontekście administratora):

• Exchange Server 2013 CU23
• Exchange Server 2016 CU19 and CU20
• Exchange Server 2019 CU8 and CU9

Warto pamiętać również o przydatnym skrypcie, udostępnionym na Githubie do weryfikacji zabezpieczeń serwerów Exchange - nie tylko zainstalowanych poprawek ale również konfiguracji interface'ów sieciowych, sterowników i innych parametrów konfiguracji serwerów - https://aka.ms/ExchangeHealthChecker. 

Jeszcze więcej poprawek do serwerów Exchange

Nie cichnie wrzawa po wykryciu w ostatnich dniach podatności w systemach Exchange Server. Pisałem już w poprzednim poście o poprawkach, które Microsoft wydał dokładnie tydzień temu, wiele organizacji Exchange zostało do dziś zaatakowanych - bez wątpienia był to największy atak na najczęściej używany na świecie komercyjny system pocztowy. Podstawowym problemem, jaki mieli administratorzy, którzy chcieli zabezpieczyć swoje serwery Exchange, był w wielu przypadkach brak aktualnych wersji poprawek Cumulative Updates (grupa produktowa Exchange wydaje poprawki bezpieczeństwa tylko dla dwóch ostatnich wersji CU), których z różnych względów firmy nie mogły lub nie chciały zainstalować.

Dlatego też, ze względu na fakt, jak krytyczne są wykryte podatności, Microsoft opublikował dodatkowo poprawki dla trzech poprzednich wersji CU, zarówno dla Exchange 2016 jak i Exchange 2019. Dodatkowe poprawki łatają tylko wykryte w marcu podatności, ale dzięki ich instalacji, firmy będą mogły lepiej przygotować się do instalacji najnowszych aktualizacji zbiorczych, nie będąc narażonymi na ataki. Więcej informacji na blogu grupy produktowej Exchange.

Warto również sprawdzić, czy na naszym serwerze Exchange nie ma podejrzanych plików, świadczących o dokonanym ataku. Microsoft udostępnił skrypt Test-ProxyLogon.ps1, który szuka takich danych.

W przypadku, gdy serwer jednak padł ofiarą ataku, Microsoft zaleca reinstalację systemu. W takiej sytuacji warto pamiętać o parametrze instalacyjnym /recoverserver dzięki któremu w trakcie instalacji konfiguracja zostanie pobrana z Active Directory, co na pewno znacząco ułatwia życie. Dokładniejszą instrukcję, jak odbudować serwer umieścił na swoim blogu Jaap Veselius.

Office 365 - problemy ze spamem

Wysyłając pocztę ze skrzynek na Office 365 czasem ze zdziwieniem orientujemy się, że trafia ona do spamu. Niestety, pomagając administratorowi opublikować niezbędne dla Exchange Online rekordy, Microsoft nadal podaje tylko 3 rekordy - MX, SPF i autodiscover. Już jakiś czas temu publikowałem kilka postów o dodatkowych metodach zabezpieczania poczty - DKIM oraz DMARC. Od tego czasu zdecydowana większość firm używa już tych mechanizmów. Warto poświęcić kilka minut, żeby skonfigurować je dla swojej organizacji Office 365. O ile konfiguracja DMARC to tylko dodanie rekordu do DNS (przynajmniej na początku), to konfiguracja DKIM wymaga jeszcze włączenia na poziomie Exchange Online. W artykule https://pepugmaster.blogspot.com/2016/03/walka-ze-spamem-spf-dkim-dmarc.html opisałem konfigurację w Office 365, jednak ostatnio zaważyłem, że dla własnych domen, obsługiwanych w Office 365 możliwość włączenia w webowym panelu administracyjnym, zarówno Exchange Admin Center, jak i https://protection.office.com/dkim została ukryta.

Funkcjonalność nie jest zablokowana, ale jak wiele zaawansowanych funkcji dostępna tylko w powershell. Wystarczy z poziomu modułu administracyjnego Exchange Online wykonać komendę:

new-DkimSigningConfig -Identity -KeySize 2048 -Enabled $true

Jeżeli w DNS dla naszej domeny nie dodaliśmy niezbędnych rekordów, funkcjonalność zostanie skonfigurowana, ale nie będzie włączona, o czym zostaniemy poinformowani odpowiednim komunikatem:

Jeżeli uzupełnimy/poprawimy rekordy, możemy włączyć zabezpieczenie domeny komendą:

set-DkimSigningConfig -Identity lab.pepug.org -Enabled $true.

I nasza poczta będzie bardziej wiarygodna.

Zmiany w zabezpieczeniach Exchange Server

Część firm wykorzystujących Exchange Online z niepokojem czeka na jesień, kiedy to 13 października, zgodnie z zapowiedziami zespołu produktowego Exchange, w celu zwiększenia bezpieczeństwa zostanie wyłączone uwierzytelnienie podstawowe dla wielu usług - EWS, POP, IMAP, a także ActiveSync i Remote Powershell (uszczegółowienie listy usług, dla których zostanie wyłączone uwierzytelnianie podstawowe opublikowano we wrześniu ubiegłego roku). Dla wielu administratorów to niezłe trzęsienie ziemi, bo przecież jesteśmy przyzwyczajeni, że usługi te towarzyszą nam od dekad. Zespół produktowy wskazuje jednak, jak możemy zapobiec problemom, używając aplikacji, które wykorzystują nowocześniejsze mechanizmy uwierzytelnienia - w szczególności bazujące na OAuth i Modern Authentication. Zresztą tendencja do wyłączania słabszych mechanizmów zabezpieczeń nie dotyczy tylko Exchange ale również np. Google i współpracujących z nim klientów (Thunderbird od wersji 38 może wykorzystywać OAuth2 do uwierzytelniania np. POP w serwisie Google). Teraz na liście nadchodzących aktualizacji w Office 365 znalazło się wprowadzenie mechanizmów Oauth dla protokołów POP i IMAP (chociaż np. w usłudze konsumenckiej Outlook.com IMAP korzysta z OAuth już od pewnego czasu). Zespół produktowy Exchange własnie opublikował kolejny artykuł na swoim blogu, opisujący wprowadzane zmiany oraz jak zabezpieczyć się przed ewentualnymi problemami.

Po pierwsze możemy sprawdzać w portalu administracyjnym Azure AD, czy w naszym tenancie zachodzi uwierzytelnianie starszymi metodami - informacje te możemy znaleźć w oknie Sign-In Events, dodatkowo wymuszając prezentację aplikacji używanych przez użytkowników, jak widać na poniższym rysunku (niektóre domyślne kolumny schowałem dla czytelności widoku).

Eksportując wyniki w formacie JSON, możemy w Excelu zweryfikować informacje o użytkownikach/systemach, którzy wykorzystują uwierzytelnianie Basic (już niebawem raporty w pormacie csv również będą zawierały niezbędne informacje). Pamiętajmy jednak o tym, że Modern Auth jest dostępne w Outlookach od wersji 2013, podobnie w klientach mobilnych od dłuższego czasu. Aktualizując aplikacje pocztowe oraz mechanizmy dostępu administracyjnego (np. modułów powershell, używanych do zarządzania usługami) unikniemy problemów po wyłączeniu słabych mechanizmów zabezpieczeń.

Kwietniowe poprawki bezpieczeństwa dla Exchange

Kilka dni temu przy okazji cyklicznego święta "patch Tuesday", pojawiły się poprawki bezpieczeństwa dla wszystkich wspieranych wersji Exchange, które rozwiązują problem opisany w poniższych artykułach:

• CVE-2019-0817: Microsoft Exchange Spoofing Vulnerability
• CVE-2019-0858: Microsoft Exchange Spoofing Vulnerability

Warto pamiętać, że poprawki zostały przygotowane tylko dla najnowszych i N-1 wersji systemów, więc warto instalować pakiety CU na bierząco. Poniżej lista dostępnych poprawek i odpowiednie artykuły w bazie wiedzy Microsoft:

Wersja Exchange	Build	Artykuł KB	Lokalizacja poprawki	CVE-2019-0817	CVE-2019-0858
Exchange 2019 CU1	15.2.330.7	KB4487563	Pobierz	Yes	Yes
Exchange 2019	15.2.221.16	KB4487563	Pobierz	Yes	Yes
Exchange 2016 CU12	15.1.1713.6	KB4487563	Pobierz	Yes	Yes
Exchange 2016 CU11	15.1.1591.16	KB4487563	Pobierz	Yes	Yes
Exchange 2013 CU22	15.0.1473.4	KB4487563	Pobierz	Yes	Yes
Exchange 2010 SP3 RU27	14.3.452.0	KB4491413	Pobierz	Yes	No

Jak widać w powyższej tabeli, poprawka dla wersji Exchange 2010, nie rozwiązuje problemu opisanego w CVE-2019-0858. Rozszerzone wsparcie dla tej wersji systemu kończy się już za 9 miesięcy (14 stycznia 2020) i od tego dnia żadne aktualizacje nie będą publikowane.

Acrobat Reader z dostępem do zabezpieczonych plików dostępny w Preview

W poprzednim poście wspominałem o ogłoszonym na Ignite zmienionym dostępie do dokumentów PDF zabezpieczonych przez AIP. Dzisiaj ukazała się wersja Preview Acrobat Readera DC z dodatkową wtyczką Microsoft Information Protection, dzięki której możemy czytać zapezpieczone AIP dokumenty. Wcześniej było to dostępne w aplikacji AIP viewer, oraz wybranych czytnikach zewnętrznych (np. Foxit Viewer), jednak w ramach umowy między firmami Microsoft i Adobe, w końcu ten popularny czytnik również dostał taką możliwość. Jak można się o tym przekonać?

Po pierwsze musimy zmienić format zabezpieczanych dokumentów PDF. zgodnie ze standardem ISO, dzięki czemu zabezpieczony dokument nadal będzie używał rozszerzenia pdf, zamiast ppdf. W tym celu logujemy się w konsoli administracyjnej AIP i wybieramy opcję Advanced w ustawieniach używanej przez nas polisy (jeżeli nie dodawaliśmy więcej polis, to robimy to w domyślnej polisie Global). W tym celu wybieramy wielokropek przy nazwie polisy (rysunek poniżej) i klikamy w opcję Advanced Settings:

Następnie dodajemy ustawienie jak na poniższym rysunku EnablePDFv2Protection z wartością TRUE. Lista ustawień zaawansowanych polis AIP dostępna jest w przewodniku administracyjnym - https://docs.microsoft.com/en-us/azure/information-protection/rms-client/client-admin-guide-customizations

Mając odpowiednie ustawienie konfiguracyjne możemy pobrać aplikację i plugin z udostępnionej paczki. Po instalacji otwarcie zabezpieczonego pliku pdf jest możliwe.

Więcej informacji w artykule https://docs.microsoft.com/en-us/azure/information-protection/rms-client/protected-pdf-readers

Microsoft Ignite 2018 - Information Protection

Klasyfikacja i zabezpieczanie danych w ramach usług Office 365, to jedna z częściej poruszanych kwestii w tym roku, chociażby w kontekście wprowadzenia GDPR. Usługi Information Protection systematycznie się rozwijają, dlatego też nie dziwi duża ilość zmian i nowości ogłoszona przy okazji konferencji Microsoft Ignite 2018:

• Zcentralizowane zarządzanie etykietami i  ustawieniami ochrony w Security & Compliance Center uzyskało status General Availability,
• Microsoft Information Protection SDK uzyskał status General Availability,
• Pojawiła się wersja Preview etykietowania w Word, PowerPoint, Excel  oraz Outlook dla Mac (w ramach Office Insider Program),
• Pojawiła się wersja Preview etykietowania w Word i PowerPoint dla iOS i Android,
• Ogłoszono udostępnienie w październikowej aktualizacji systemu Windows 10 ochrony urządzeń końcowych, na bazie etykiet w ramach Windows Information Protection. Oznacza to, że po wykryciu, że na komputerze w naszym środowisku jest dokument opatrzony etykietą, aplikowana jest odpowiednia polisa WIP,
• Ogłoszono udostępnienie w październiku wersji preview przeglądania zabezpieczonych i opatrzonych etykietami dokumentów w formacie PDF w Adobe Acrobat Reader dla Windows,
• Pojawiła się wersja Preview analityki dla Information Protection,
• Dodane zostały nowe funkcjonalności dla Office 365 Message Encryption.