Każdy komputer Mac jest dostarczany z dwiema rzeczami, które ludzie nazywają „zaporą ogniową”. Jednym z nich jest Zapora aplikacji w Ustawieniach systemu, przełącznik połączeń przychodzących dla poszczególnych aplikacji. Drugim, cichszym jest pf, filtr pakietów BSD, który macOS odziedziczył po linii FreeBSD/OpenBSD i którego Apple sam używa pod maską do udostępniania Internetu, VPN i NAT. Zaawansowani użytkownicy i administratorzy mogą rozmawiać z nim bezpośrednio za pomocą pfctl, a wiele przewodników pokazuje fragment pf.conf i nie ma problemu. Przewodniki te rzadko wyjaśniają, kiedy pf przestaje być przydatne do tego, czego tak naprawdę pragnie większość ludzi: oglądania i kontrolowania tego, co wysyłają ich własne aplikacje. To laboratorium, a nie wykład — włączymy pf, napiszemy regułę, odczytamy stan, jaki utrzymuje, a następnie przyjrzymy się dokładnie, dlaczego ten stan ma niewłaściwy kształt dla zapory aplikacji.
Czym właściwie jest pf
pf to filtr pakietów na poziomie jądra: sprawdza pakiety przechodzące przez interfejsy sieciowe i, reguła po regule, decyduje, czy je przepuścić, czy zablokować. Nie ma pojęcia „aplikacje” — działa wyłącznie na nagłówkach pakietów: adresie źródłowym i docelowym, porcie, protokole, interfejsie, kierunku. Nie jest to ograniczenie, które ktoś zapomniał naprawić; to jest projekt. pf został zbudowany w celu filtrowania ruchu w warstwie sieciowej, w tej samej warstwie, w której działają routery i bramy, i jest w tym bardzo dobry.
Rozmawiasz z nim za pomocą pfctl, narzędzia sterującego. Jego strona podręcznika wyraźnie opisuje podział pomiędzy dwiema czynnościami, które wykonuje: ładuje zestawy reguł z pliku konfiguracyjnego i raportuje stan, w jakim znajduje się jądro. Dwie flagi mają największe znaczenie przy włączaniu i wyłączaniu filtra, jak mówi strona podręcznika: -e („Włącz filtr pakietów.”) i -d („Wyłącz filtr pakietów.”). Nic innego w pf nie jest włączone ani wyłączone — cały zestaw reguł działa razem.
Włączam go i odczytuję jego stan
Krótkie laboratorium na komputerze Mac, na którym swobodnie korzystasz z sudo. Najpierw sprawdź, czy filtr jest już włączony i zobacz jego liczniki:
sudo pfctl -s info
# example output, trimmed — the real thing includes per-rule and per-source-tracking stats with -v
Status: Enabled for 0 days 02:14:07 Debug: err
State Table Total Rate
current entries 42
searches 88213 9.7/s
inserts 611 0.1/s
removals 569 0.1/sNastępnie wypisz reguły aktualnie obowiązujące w jądrze. pfctl -s rules robi dokładnie to; strona podręcznika zauważa, że za pomocą -v wypisuje także liczniki, pakiety i bajty oceny dla poszczególnych reguł:
sudo pfctl -s rules
# example output, trimmed
scrub-anchor "com.apple/*" all fragment reassemble
anchor "com.apple/*" all
block drop in log quick from <blocklist> to anyTa linia com.apple/* nie jest ozdobą. Apple ładuje własne reguły do nazwanych kotwic — termin pf określający samodzielny podzestaw reguł, który można wymieniać i wymieniać bez ponownego ładowania wszystkiego innego. Flaga pfctl -a wskazuje konkretną kotwicę i, zgodnie ze stroną podręcznika, użycie jej z symbolem wieloznacznym umożliwia rekurencyjne drukowanie zagnieżdżonych kotwic, w ten sposób widzisz, co sam Apple załadował wraz ze wszystkim, co dodasz:
sudo pfctl -a '*' -s rules
# example output, trimmed to the anchors that exist on a stock MacPisanie i ładowanie reguły testowej
Minimalny plik zakotwiczenia, który blokuje wychodzący jeden adres IP, zapisany jako /etc/pf.anchors/test-block:
block drop out quick on en0 proto tcp to 203.0.113.10 port 443Aby załadować pojedynczy plik zakotwiczenia, pfctl -f odczytuje reguły z pliku, zgodnie ze stroną podręcznika, która opisuje plik jako zawierający makra, tabele, opcje i reguły filtrowania:
sudo pfctl -f /etc/pf.anchors/test-block
sudo pfctl -s rules
block drop out quick on en0 proto tcp from any to 203.0.113.10 port = 443Dlaczego pf nie może być zaporą sieciową Twojej aplikacji
Żadne z poniższych nie jest błędem. Tak właśnie się dzieje, gdy skierujesz filtr pakietów warstwy sieciowej na zadanie wymagające wiedzy, który proces wysłał pakiet.
Nie ma pojęcia, która aplikacja wysłała pakiet
Reguły pf pasują do adresu IP, portu, protokołu, interfejsu i kierunku. Nie ma pola na „nazwę procesu”, „identyfikator pakietu” ani „sygnaturę kodu”, ponieważ pf znajduje się w warstwie, w której istnieją pakiety, ale procesy nie. Dwie zupełnie różne aplikacje otwierające połączenia TCP z tym samym adresem IP i portem są nie do odróżnienia od pf. Jeśli chcesz pozwolić Slackowi na dotarcie do hosta, blokując jednocześnie dostęp innych aplikacji do tego samego hosta, sam pf nie może wyrazić tej reguły.
Reguła dotycząca nazwy hosta to reguła dotycząca dowolnego adresu IP, który nazwa hosta miała w czasie ładowania
Pliki pf.conf często odwołują się do nazwy hosta dla czytelności — block from evil.example.com. To, co faktycznie zostanie załadowane, to nie ta nazwa; jest to adres, na który został rozwiązany. Strona podręcznika OpenBSD pf.conf mówi wyraźnie: „Rozpoznawanie nazw hostów i interfejs do translacji adresów są wykonywane w czasie ładowania zestawu reguł”. Nie ma wyszukiwania DNS w czasie wykonywania w miarę przepływu ruchu — podstawienie następuje raz, gdy uruchomisz pfctl -f, a reguła będzie pasować do tego jednego adresu, dopóki nie zostanie ponownie załadowana. To jest w porządku dla serwera ze statycznym adresem IP. Rozpada się w momencie, gdy kryje się za nim nazwa CDN, moduł równoważenia obciążenia w chmurze lub jakakolwiek usługa, która zmienia się lub równoważy obciążenie na wielu adresach – co opisuje większość Internetu w 2026 r. Reguła mająca na celu blokowanie „tej usługi” po cichu zawęża się do „dowolnego z adresów IP tej usługi, który odpowiedział, gdy ładowałem regułę”, a ruch do każdego innego adresu o tej samej nazwie hosta przepływa bezpośrednio.
Żadnych podpowiedzi, żadnych rozmów — po prostu statyczny zestaw reguł
pf nie ma modelu interakcji. Nie może wstrzymać połączenia i zapytać: „Poczta chce po raz pierwszy osiągnąć 51.x.x.x na porcie 993 — pozwolić?” Albo pasuje do reguły, którą już napisałeś, albo przechodzi do reguły domyślnej. Każdą decyzję należy przewidzieć i zapisać z wyprzedzeniem, pod względem adresu IP i portu, zanim nastąpi ruch. Nie ma odpowiednika monitu o pierwsze połączenie, ponieważ monitowanie wymaga wiedzy, która aplikacja pyta, a pf nie ma takich informacji.
Twoja odręczna konfiguracja nie przetrwa aktualizacji
Apple traktuje /etc/pf.conf i ładowane przez niego kotwice jako konfigurację zarządzaną przez system powiązaną z wewnętrznymi elementami systemu macOS — od tego zależą udostępnianie Internetu, VPN i własne kotwice Application Firewall. Aktualizacje systemu macOS umożliwiają bezpłatne przepisanie lub zastąpienie tego pliku. Jeśli ręcznie go edytowałeś, dodając własne reguły, nie ma gwarancji, że przetrwają następną aktualizację; przekonasz się na własnej skórze, po tym jak Twoja reguła po cichu przestała obowiązywać. Plik konfiguracyjny, który ktoś ręcznie pielęgnuje, a system operacyjny okresowo nadpisuje, to złe miejsce na przechowywanie jedynej rzeczy, na której naprawdę ci zależy – „czy mój Mac znowu rozmawiał z tym adresem”.
Bez przeglądarki logów, bez historii, bez mapy
pf może logować dopasowane pakiety do pseudointerfejsu pflog0, jeśli reguła zawiera słowo kluczowe log — widoczne powyżej w regule listy bloków z wcześniejszego wyjścia -s rules. Ale ten dziennik jest strumieniem przechwytywania pakietów, który można odczytać za pomocą tcpdump -i pflog0, a nie historią, którą można przeszukiwać. Nie ma wbudowanej przeglądarki, nie ma listy poszczególnych aplikacji zawierającej informacje, co i kiedy zostało zablokowane, żadnego kraju ani organizacji powiązanej z adresem, niczego, co można by pokazać komuś, kto mógłby odpowiedzieć na pytanie: „Co ten Mac próbował osiągnąć w zeszłym tygodniu”. Dostajesz surowe pakiety, a resztę możesz zbudować sam.
Warstwa, którą Apple faktycznie zbudował do tego zadania
Odpowiedź Apple na pytanie „Chcę filtrować ruch mojego Maca według aplikacji” nie jest pf — jest to platforma Network Extension, a konkretnie dostawcy filtrów treści. Dokumentacja Apple dla programistów opisuje ten model bezpośrednio: „Filtr treści sieciowej na urządzeniu sprawdza zawartość sieci użytkownika przechodzącą przez stos sieciowy i określa, czy powinien ją blokować, czy pozwolić na przekazanie jej do miejsca docelowego”, a dostawca danych filtrujących — NEFilterDataProvider — „otrzymuje zawartość sieciową użytkownika i sprawdza tę zawartość, aby określić, czy ją zablokować, czy zezwolić”. Przepływy są reprezentowane jako obiekty NEFilterFlow (z NEFilterBrowserFlow i NEFilterSocketFlow jako konkretne przypadki), co stanowi brakujący element, którego nigdy nie miał: obiekt przepływu, który aplikacja filtrująca może sprawdzić i powiązać z procesem, który go otworzył, przed podjęciem decyzji o pasowaniu lub blokowaniu.
Z tego też powodu wbudowana zapora aplikacji (przełącznik w Ustawieniach systemu) to coś innego niż pf, a nie jej interfejs. W przewodniku Apple opisano to wyłącznie w kategoriach przychodzących: „może chronić komputer Mac przed niechcianymi kontaktami inicjowanymi przez inne komputery” i działa, umożliwiając „wybór aplikacji i usług oraz określenie, czy mogą mieć dostęp przez zaporę sieciową”. Tak, dla każdej aplikacji, ale tylko dla połączeń przychodzących i tylko za pośrednictwem specjalnego mechanizmu, który Apple zbudował dla tego jednego zadania. Odpowiada na inne pytanie niż „co wysyła moja aplikacja”.
| Zbliżać się | Widzi adres IP/port | Wie, która aplikacja | Obsługuje zmienione nazwy/rotację adresów IP | Może podpowiedzieć użytkownikowi | Kierunek |
|---|---|---|---|---|---|
| pf (@@KOD0@@) | Tak | NIE | Nie — rozwiązano raz w czasie ładowania | NIE | Albo, według zasady |
| Zapora aplikacji (Ustawienia systemowe) | Nie (przełącznik na poziomie aplikacji) | Tak | Nie dotyczy | NIE | Tylko przychodzące |
| Filtr treści rozszerzenia sieciowego | Tak | Tak, poprzez obiekt przepływu | Tak — oceniane według przepływu na żywo | Tak, przez zbudowaną na nim aplikację | Wychodzące i przychodzące |
Nic z tego nie czyni pf bezużytecznym. Jeśli używasz komputera Mac jako lekkiego routera i chcesz odrzucić znany, nieprawidłowy zakres na poziomie jądra, niezależnie od tego, który proces pyta, lub chcesz zrozumieć, co pod maską robią własne funkcje udostępniania Internetu i VPN firmy Apple, pf jest właściwym i jedynym narzędziem do tego zadania, a pfctl -s rules / -s info to właściwy sposób, aby na to spojrzeć. Nigdy nie zamierzała odpowiedzieć na pytanie, które zadaje sobie większość ludzi: która z moich aplikacji rozmawia z kim w tej chwili i czy mogę zostać zapytana, zanim dotrze do mnie nowa.
Jaką rolę odgrywają FireAI i HisnLabs
pf and the built-in Application Firewall are both worth using — FireAI does not replace either; it fills the specific gap neither one can, by tying outbound decisions to the app’s code signature and asking before an unknown one gets a first connection.
FireAI to własny produkt HisnLabs: zapora sieciowa z AI działająca bezpośrednio na Macu. Pokazuje prostym językiem każde połączenie nawiązywane przez twoje aplikacje i pozwala ci decydować, co opuszcza twojego Maca — jej AI działa lokalnie, więc twój ruch nigdy nie jest wysyłany do nas ani do nikogo innego. Zespół badań nad bezpieczeństwem HisnLabs dba o to, by te decyzje pozostały trafne: kataloguje, które domeny to zwykła telemetria, a które prawdziwa usługa, śledzi kraj i sieć stojące za połączeniem oraz trenuje lokalny model (funkcję Autopilot) na rzeczywistych wzorcach ruchu — a nic z tego nie opuszcza twojego Maca.
Możesz przeczytać o decyzjach technicznych, które za tym stoją, albo wypróbować FireAI przez 17 dni na FireAI od HisnLabs.