E-mail o błędzie VPN na FortiGate: filtruj pola, nie logi

W zdaniu „wyślij mi e-mail, gdy logowanie VPN się nie powiedzie” kryją się dwie decyzje. Pierwsza to sposób dostarczania powiadomienia: jedna wiadomość na zdarzenie, okresowe podsumowanie albo alert z kolektora. Druga to zawartość komunikatu. Błąd w pierwszej zalewa skrzynkę, a błąd w drugiej usuwa pola, które czynią alert użytecznym. Żadna z decyzji nie wymaga tłumienia kategorii logu VPN, a to właśnie skrót, który po cichu niszczy ścieżkę audytu.

Trzy formy dostarczania i kiedy każda pasuje

Wybieraj według tego, kto reaguje i jak szybko może, a nie według tego, która opcja jest najłatwiejsza w konfiguracji. Pojedynczy FortiGate chroniący jedno biuro może uzasadniać e-mail na zdarzenie. Ta sama konfiguracja na bramie przyjmującej próby uzupełniania skradzionych danych logowania generuje tysiące wiadomości dziennie i trafia do filtrowania w folderze, którego nikt nie czyta.

Zacznij od rekordu zdarzenia, nie od wiersza tematu

Przeczytaj reprezentatywne zapisane zdarzenie w wersji, którą faktycznie uruchamiasz. Dokumentacja logów FortiOS 7.4.8 identyfikuje nieudane logowanie do SSL VPN jako zdarzenie 39426, a jego pola obejmują action, user, remip, reason, tunneltype i vd. Projektowanie filtra z przekazanego tematu e-maila zamiast z tego rekordu to sposób, w jaki ludzie kończą na dopasowywaniu nazwy pola, którą ich firmware zapisuje inaczej. Otwórz dwa lub trzy rzeczywiste błędy i potwierdź zgodność identyfikatorów, zanim napiszesz trigger. Pięć minut, które to zajmuje, jest krótsze niż tydzień alertów odpalających na niewłaściwym zdarzeniu.

Zszycie automatyzacji łączy trigger dziennika zdarzeń z akcją, a trigger jest miejscem, w którym powinien znajdować się wybór zdarzenia. Dodawaj tylko te dodatkowe warunki pól, których wymaga twoje wymaganie; trigger filtrujący po małym zestawie pól wciąż dostarcza nieprzetestowane zachowanie dla reszty.

Zbuduj zwartą treść z obsługiwanych podstawień

W wersjach dokumentujących podstawianie pól logu dla akcji e-mail treść może być krótka i nadal użyteczna. Poniższa forma jest ilustracyjna; przed przyjęciem sprawdź nazwy atrybutów i składnię podstawiania względem wersji firmware.

config system automation-trigger
    edit "ssl-vpn-login-fail"
        set event-type event-log
        set logid 39426
    next
end

config system automation-action
    edit "mail-vpn-fail"
        set action-type email
        set email-to "[email protected]"
        set email-subject "SSL-VPN login failed"
        set message "Account: %%log.user%% | Source: %%log.remip%% | Reason: %%log.reason%%"
    next
end

Szablon wyświetlający puste pole nie dowodzi, że zdarzeniu brakowało tych danych. Najpierw sprawdź nazwę pola i składnię podstawiania, potem przetestuj jednym kontrolowanym błędem i przeczytaj rzeczywistą wiadomość. Dodaj tożsamość urządzenia i czas wystąpienia, aby reagujący znalazł pełny rekord bez zgadywania, która jednostka wysłała e-mail.

Wycisz wolumen bez usuwania rekordu

Kontrola tempa, grupowanie i korelacja należą do warstwy dostarczania. Podnoszenie minimalnej wagi e-maili dla wszystkiego to tępe narzędzie, które ukrywa niepowiązane zdarzenia, a wyłączanie kategorii logu VPN jest gorsze: zdarzenia przestają być w ogóle zapisywane. Zachowaj zatwierdzony cel logowania i politykę retencji dokładnie takie, jakie były, i pozwól zamiast tego, by ścieżka powiadomień stała się cichsza. Udokumentuj, co wyciszyłeś, bo następna osoba znajdzie lukę w skrzynce i musi wiedzieć, że była zamierzona.

Gdy nowa ścieżka jest zweryfikowana, wycofaj każdą nakładającą się starą regułę e-mail przez przejrzaną zmianę. Zakończenie z dwiema ścieżkami, które obie odpalają, albo z żadną, bo starą wyłączono pierwszą, to częsty wynik sprzątania przed testem.

Czytaj błąd jako błąd

Nieudane zdarzenie uwierzytelniania nie jest udaną sesją VPN, a nazwa użytkownika w zdarzeniu nie jest zweryfikowanym przypisaniem do osoby. Skoreluj przyczynę z udanymi logowaniami, znaną aktywnością użytkownika i powtarzanymi próbami, zanim ogłosisz konto przejętym, i powiedz w alercie, które z nich sprawdziłeś.

Wysyłaj powiadomienie tylko do upoważnionych odbiorców. Nazwy kont, wewnętrzne identyfikatory urządzeń i adresy źródłowe są wrażliwe operacyjnie, a lista dystrybucyjna rosnąca dla wygody staje się ścieżką wycieku. Jedna użyteczna ścieżka plus nienaruszona ścieżka audytu to cały cel.