MacOS pf Güvenlik Duvarı: Neler Yapabilir ve Neden Uygulamanızın Güvenlik Duvarı Olamıyor?

Her Mac, insanların "güvenlik duvarı" dediği iki şeyle birlikte gelir. Bunlardan biri, gelen bağlantılar için uygulama başına bir geçiş olan Sistem Ayarlarındaki Uygulama Güvenlik Duvarıdır. Diğeri, daha sessiz olanı, macOS'un FreeBSD/OpenBSD soyundan devraldığı ve Apple'ın kendisinin internet paylaşımı, VPN ve NAT için kullandığı BSD paket filtresi pf'dir. Uzman kullanıcılar ve yöneticiler pfctl ile doğrudan konuşabilir ve birçok kılavuz bir pf.conf pasajı gösterir ve bunu bir gün sonra bitirir. Bu kılavuzların nadiren açıkladığı şey, pf'nin çoğu insanın aslında istediği şey için yararlı olmayı bıraktığı noktadır: kendi uygulamalarının ne gönderdiğini izlemek ve kontrol etmek. Bu bir laboratuvardır, bir ders değil; pf'yi açacağız, bir kural yazacağız, tuttuğu durumu okuyacağız ve ardından bu durumun bir uygulama güvenlik duvarı için neden yanlış şekil olduğuna tam olarak bakacağız.

Aslında pf nedir

pf, çekirdek düzeyinde bir paket filtresidir: paketleri ağ arayüzlerinden geçerken inceler ve kural kural, bunların iletilmesine mi yoksa engellenmesine mi karar verir. "Uygulamalar" kavramı yoktur; yalnızca paket başlıklarında çalışır: kaynak ve hedef adresi, bağlantı noktası, protokol, arayüz, yön. Bu birisinin düzeltmeyi unuttuğu bir sınırlama değil; tasarım budur. pf, ağ katmanındaki trafiği filtrelemek için oluşturuldu, yönlendiriciler ve ağ geçitleri aynı katmanda çalışıyor ve bu işte çok iyi.

Onunla, kontrol yardımcı programı pfctl ile konuşursunuz. Man sayfası, yaptığı iki şey arasındaki ayrım konusunda açıktır: bir yapılandırma dosyasından kural kümelerini yükler ve çekirdeğin tuttuğu durum hakkında rapor verir. Man sayfasının kendi ifadeleriyle, filtreyi etkinleştirmek ve devre dışı bırakmak için iki bayrak çok önemlidir: -e (“Paket filtresini etkinleştirin.”) ve -d (“Paket filtresini devre dışı bırakın.”). Pf ile ilgili başka hiçbir şey açık veya kapalı değildir; tüm kural seti birlikte hareket eder.

Açma ve durumunu okuma

Sudo'yu rahatlıkla kullanabileceğiniz, Mac'te hızlı bir laboratuvar. Öncelikle filtrenin zaten etkin olup olmadığını kontrol edin ve sayaçlarına bakın:

$ 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/s

Daha sonra çekirdeğin şu anda sahip olduğu kuralları listeleyin. pfctl -s rules tam olarak bunu yapar; kılavuz sayfası -v ile kural başına değerlendirme sayımlarını, paketlerini ve baytlarını da yazdırdığını belirtiyor:

$ 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 any

Bu com.apple/* satırı dekorasyon değildir. Apple, kendi kurallarını adlandırılmış bağlantılara yükler - pf'nin, diğer her şeyi yeniden yüklemeden değiştirilebilen, bağımsız bir alt kural kümesi için kullandığı terim. pfctl'in -a bayrağı belirli bir bağlantıyı hedefler ve man sayfası başına, bunu bir joker karakterle kullanmak, iç içe bağlantıların yinelemeli yazdırılmasını sağlar; bu, Apple'ın eklediğiniz herhangi bir şeyin yanında ne yüklediğini bu şekilde görürsünüz:

$ sudo pfctl -a '*' -s rules
# example output, trimmed to the anchors that exist on a stock Mac

Test kuralı yazma ve yükleme

/etc/pf.anchors/test-block olarak kaydedilen, bir IP adresinin dışarı çıkmasını engelleyen minimum bağlantı dosyası:

block drop out quick on en0 proto tcp to 203.0.113.10 port 443

Tek bir bağlantı dosyası yüklemek için, pfctl -f, dosyayı makrolar, tablolar, seçenekler ve filtreleme kuralları içerdiğini açıklayan kılavuz sayfası başına bir dosyadan kuralları okur:

$ 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 = 443

Neden pf uygulamanızın güvenlik duvarı olamaz?

Aşağıdakilerin hiçbiri bir hata değildir. Hangi işlemin paketi gönderdiğini bilmeyi gerektiren bir işe ağ katmanı paket filtresini yönlendirdiğinizde olan şey budur.

Paketi hangi uygulamanın gönderdiği hakkında hiçbir fikri yok

pf kuralları IP, bağlantı noktası, protokol, arayüz ve yöne göre eşleşir. "İşlem adı", "paket tanımlayıcısı" veya "kod imzası" için alan yoktur, çünkü pf, paketlerin bulunduğu ancak süreçlerin bulunmadığı katmanda bulunur. Aynı IP ve bağlantı noktasına TCP bağlantılarını açan tamamen farklı iki uygulama, pf ile ayırt edilemez. Diğer tüm uygulamaların aynı ana bilgisayara ulaşmasını engellerken Slack'in bir ana bilgisayara erişmesine izin vermek istiyorsanız, pf tek başına bu kuralı ifade edemez.

Ana makine adına ilişkin kural, yükleme sırasında ana bilgisayar adının sahip olduğu IP'ye ilişkin bir kuraldır

pf.conf dosyaları genellikle okunabilirlik için bir ana bilgisayar adına başvurur — block from evil.example.com. Aslında yüklenen şey bu isim değil; Hangi adrese karar verildiyse odur. OpenBSD pf.conf kılavuz sayfası bunu açıkça söylüyor: "Ana bilgisayar adı çözümlemesi ve adres çevirisine yönelik arayüz, kural kümesi yükleme süresinde yapılır." Trafik akışı sırasında çalışma zamanı DNS araması yoktur; değişiklik, pfctl -f komutunu çalıştırdığınızda bir kez gerçekleşir ve kural, siz onu yeniden yükleyene kadar o adresle eşleşmeye devam eder. Statik IP'ye sahip bir sunucu için bu iyidir. Arkasındaki ad bir CDN, bir bulut yük dengeleyici veya birçok adres arasında dönen veya yük dengeleme yapan herhangi bir hizmet olduğu anda dağılır; bu, 2026'da internetin çoğunu tanımlar. "Bu hizmeti" engellemeyi amaçlayan bir kural, sessizce "kuralı yüklediğimde o hizmetin IP'lerinden hangisi yanıt verdiyse" şeklinde daralır ve aynı ana bilgisayar adının çözdüğü diğer tüm adreslere giden trafik doğrudan gider.

İstem yok, konuşma yok; yalnızca statik bir kural seti

pf'nin etkileşim modeli yoktur. Bağlantıyı duraklatıp "Mail ilk kez 993 numaralı bağlantı noktasında 51.x.x.x'e ulaşmak istiyor; buna izin verilsin mi?" diye soramaz. Ya önceden yazdığınız bir kuralla eşleşir ya da varsayılana düşer. Her kararın, trafik gerçekleşmeden önce IP ve bağlantı noktası açısından önceden tahmin edilmesi ve yazılması gerekir. İlk bağlantı isteminin eşdeğeri yoktur, çünkü istemde bulunmak hangi uygulamanın sorduğunu bilmeyi gerektirir ve pf başlangıçta bu bilgiye sahip değildir.

El yazısıyla yazılan yapılandırmanız güncellemeden etkilenmez

Apple, /etc/pf.conf'yi ve yüklediği bağlantıları, macOS'un dahili bileşenlerine bağlı sistem tarafından yönetilen yapılandırma olarak ele alır - internet paylaşımı, VPN, Uygulama Güvenlik Duvarı'nın kendi bağlantıları buna bağlıdır. macOS güncellemelerinde bu dosyayı yeniden yazmak veya değiştirmek ücretsizdir. Kendi kurallarınızı eklemek için elle düzenlediyseniz bunların bir sonraki güncellemede hayatta kalacağının garantisi yoktur; Kuralınızın sessizce uygulanmayı bıraktığını zor yoldan anlarsınız. Bir kişinin elle tuttuğu ve işletim sisteminin periyodik olarak üzerine yazdığı bir yapılandırma dosyası, gerçekten önemsediğiniz tek şeyi - "Mac'im yine o adresle konuştu mu?" - saklamak için kötü bir yerdir.

Günlük görüntüleyici yok, geçmiş yok, harita yok

pf, bir kural log anahtar sözcüğünü içeriyorsa, eşleşen paketleri pflog0 adlı sahte bir arayüze kaydedebilir; yukarıda önceki -s rules çıktısındaki engelleme listesi kuralında görülebilir. Ancak bu günlük, aranabilir bir geçmiş değil, tcpdump -i pflog0 ile okunabilen bir paket yakalama akışıdır. Yerleşik bir görüntüleyici yok, neyin ve ne zaman engellendiğini gösteren uygulama başına bir liste yok, bir adrese iliştirilmiş bir ülke veya kuruluş yok, "bu Mac geçen hafta neye ulaşmaya çalıştı?" diye yanıtlayacak birine göstereceğiniz hiçbir şey yok. Ham paketler alırsınız ve gerisini kendiniz oluşturursunuz.

Apple'ın aslında bu iş için oluşturduğu katman

Apple'ın "Mac'imin uygulama başına trafiğini filtrelemek istiyorum" sorusuna verdiği yanıt pf değil, Ağ Uzantısı çerçevesi, özellikle de içerik filtre sağlayıcılarıdır. Apple'ın geliştirici belgeleri modeli doğrudan açıklamaktadır: "Cihaz üzerindeki bir ağ içeriği filtresi, ağ yığınından geçerken kullanıcı ağ içeriğini inceler ve bu içeriği engellemesi mi yoksa nihai hedefine aktarılmasına izin vermesi mi gerektiğini belirler" ve bir filtre veri sağlayıcısı - NEFilterDataProvider - ​​"kullanıcı ağ içeriğini alır ve bu içeriği engelleyip engellemeyeceğini veya izin verip vermeyeceğini belirlemek için inceler." Akışlar, NEFilterFlow nesneleri olarak temsil edilir (NEFilterBrowserFlow ve NEFilterSocketFlow somut örnekler olarak), bu da pf'nin hiçbir zaman sahip olmadığı eksik parçadır: bir filtreleme uygulamasının geçişe veya engellemeye karar vermeden önce inceleyip onu açan işleme geri bağlayabileceği bir akış nesnesi.

Yerleşik Uygulama Güvenlik Duvarının (Sistem Ayarlarındaki geçiş) pf'den farklı bir hayvan olmasının, onun için bir ön uç olmamasının nedeni de budur. Apple'ın kendi kılavuzu bunu yalnızca gelen terimlerle açıklıyor: "Mac'inizi diğer bilgisayarlar tarafından başlatılan istenmeyen temaslardan koruyabilir" ve "uygulamaları ve hizmetleri seçmenize ve bunların güvenlik duvarı üzerinden erişip erişemeyeceklerini belirlemenize" izin vererek çalışır. Uygulama başına evet, ancak yalnızca gelen bağlantılar için ve yalnızca Apple'ın o iş için geliştirdiği özel mekanizma aracılığıyla. "Uygulamam ne gönderiyor?" sorusundan farklı bir soruyu yanıtlıyor.

Bunların hiçbiri pf'yi işe yaramaz hale getirmez. Bir Mac'i hafif bir yönlendirici olarak çalıştırıyorsanız, hangi işlemin istediğine bakılmaksızın çekirdek düzeyinde bilinen kötü bir aralığı reddetmeniz gerekiyorsa veya Apple'ın kendi internet paylaşımı ve VPN özelliklerinin aslında ne yaptığını anlamak istiyorsanız, pf bu iş için doğru ve tek araçtır ve pfctl -s rules / -s info buna bakmanın doğru yoludur. Hiçbir zaman yapamayacağı şey, çoğu insanın aslında sahip olduğu soruyu yanıtlamaktı: Şu anda hangi uygulamam kiminle konuşuyor ve yeni bir uygulama gelmeden bana sorulabilir mi?

FireAI ve HisnLabs burada nereye oturuyor

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, HisnLabs’in kendi ürünüdür: doğrudan Mac’inizde çalışan, yapay zekâ destekli bir güvenlik duvarı. Uygulamalarınızın kurduğu her bağlantıyı sade bir dille gösterir ve Mac’inizden neyin çıkacağına sizin karar vermenizi sağlar — yapay zekâsı yerel olarak çalışır, yani trafiğiniz asla bize ya da başka birine gönderilmez. HisnLabs güvenlik araştırma ekibi bu kararların isabetli kalmasını sağlayan ekiptir: hangi alan adlarının sıradan telemetri, hangilerinin gerçek bir hizmet olduğunu kataloglar, bir bağlantının ardındaki ülkeyi ve ağı izler ve cihaz üzerindeki modeli (Autopilot özelliği) gerçek trafik örüntüleriyle eğitir — üstelik bunların hiçbiri Mac’inizden dışarı çıkmadan.

Arkasındaki teknik kararları okuyabilir ya da FireAI’yi 17 gün boyunca deneyebilirsiniz: HisnLabs’ten FireAI.