Zaporowe reguły wychodzące

Zaporowe reguły wychodzące kontrolują ruch inicjowany przez sam serwer bazodanowy.

Kierunek ruchu, o który tu chodzi

Reguły wychodzące dotyczą połączeń inicjowanych przez samą maszynę, a nie przez komputery próbujące się do niej dostać. W przypadku serwera bazodanowego to rozróżnienie ma konkretne znaczenie: ruch przychodzący to sesje klientów łączących się z silnikiem, domyślnie na porcie 1433 dla instancji domyślnej i na porcie dynamicznym przydzielanym instancji nazwanej, przy czym jej odnalezienie wymaga jeszcze usługi przeglądarki nasłuchującej na porcie 1434 protokołu UDP. Ruch wychodzący to wszystko, co serwer sam wysyła w świat — powiadomienia pocztowe agenta, replikacja do drugiej instancji, zapis kopii zapasowej na zasób sieciowy, sprawdzanie aktualizacji, odpytywanie serwera czasu.

Po co blokować to, co wychodzi

Zapora domyślnie przepuszcza ruch wychodzący, bo blokowanie go utrudnia pracę. Na serwerze z danymi księgowymi lub osobowymi rachunek wygląda jednak inaczej: jeżeli maszyna zostanie przejęta, to właśnie połączeniem wychodzącym napastnik wyprowadza dane i pobiera kolejne narzędzia. Ograniczenie wyjścia do listy znanych celów — kontrolera domeny, serwera plików z kopiami, wewnętrznego serwera pocztowego i serwera czasu — zamyka najprostszą drogę. Przy okazji ujawnia oprogramowanie, które nie powinno pracować na tej maszynie, bo natychmiast pojawiają się odrzucone próby połączeń w dzienniku zapory.

Objawy zbyt ciasno ustawionych reguł

Pierwszy sygnał to przestające przychodzić powiadomienia o nieudanych zadaniach — agent nie dosięga serwera pocztowego, a zadania cicho kończą się błędem. Drugi to kopia zapasowa zapisywana na zasobie sieciowym, która zaczyna zwracać błąd dostępu do ścieżki, mylony z problemem uprawnień konta usługi. Trzeci to rozjazd zegara na serwerze po zablokowaniu portu 123, prowadzący do odrzucania biletów uwierzytelnienia w domenie i do niemożności zalogowania się użytkowników. Czwarty, trudniejszy do namierzenia, to serwer połączony z aplikacją przez łącznik do usługi zewnętrznej — zapytanie rozproszone albo integracja z bramką płatności przestaje działać, a komunikat mówi wyłącznie o przekroczeniu limitu czasu, bez wskazania, że pakiet został po prostu odrzucony.

Konfiguracja serwerów z bazami systemów sprzedażowych

Ustawienie zapory na maszynie z bazą to zawsze kompromis między szczelnością a działaniem programu, który z tej bazy korzysta. Wdrażamy i serwisujemy środowiska Subiekt, WAPRO oraz Comarch pracujące na SQL Server, więc znamy komplet połączeń, jakich te systemy faktycznie potrzebują — od portu instancji, przez usługę przeglądarki, po dostęp do zasobu z kopiami. Porządkujemy reguły, diagnozujemy sytuacje, w których stanowiska tracą łączność z bazą, i przywracamy działanie po nieudanej zmianie ustawień. Pracujemy przez całą dobę, siedem dni w tygodniu.