Czy jest jakaś różnica w bezpieczeństwie między zaporą opartą na rootach (AFWall +) a zaporą inną niż root (NetGuard)?

18

Jakie są techniczne różnice między firewallami opartymi na rootach (jak AFWall +) i firewallami innymi niż root (jak NetGuard)?

Czy ma to wpływ na bezpieczeństwo skutecznie zapewniane przez takie oprogramowanie?

Sprawdziłem już trochę w kodzie źródłowym NetGuard, aby sam sobie wyobrazić, ale myślę, że to może być dobre pytanie i chciałbym uzyskać analizę innych osób na ten temat.

Chciałbym ograniczyć takie pytanie do podstawowej funkcji technicznej zapewnianej przez takie oprogramowanie (takiej jak zapora ogniowa: bezstanowa lub stanowa, czy istnieją jakieś stałe wyjątki, odporność kodu na niezaufane pakiety itp.), A nie na funkcje dodatkowe lub mogą zawierać funkcje anty (funkcje reklamowe, śledzące, kosmetyczne itp.), chyba że mają one konkretny wpływ na główny cel oprogramowania.

Innymi słowy: proszę nie rants;)!

W przypadku ograniczeń warto wspomnieć, czy są one specyficzne dla implementacji (konsekwencja pewnego wyboru dokonanego przez zespół programistów) lub konsekwencja zastosowanej technologii (w oparciu o bardzo różne systemy, możliwe, że trzeba sobie poradzić z ograniczeniami, których ten drugi nie ma).

WhiteWinterWolf
źródło

Odpowiedzi:

14

Jako autor NetGuard mam doświadczenie z pierwszej ręki w tej dziedzinie.

Wadą zapory opartej na lokalnej sieci VPN jest to, że nie wszystkie typy ruchu mogą być obsługiwane, ponieważ jądro Linuxa (Android) nie pozwala na przekazywanie wszystkich typów ruchu przez połączenie oparte na gniazdach. Przykładem jest protokół IPsec, który jest wykorzystywany przez niektórych producentów do połączeń IP. Częściowym (nie dla IPsec) rozwiązaniem tego problemu byłoby użycie zdalnego serwera VPN do przekazywania ruchu, ale jest to prywatnie niedopuszczalne dla wielu osób i wymagałoby dodatkowej złożoności, a także prawdopodobnie dodatkowego zużycia baterii. W praktyce obsługa ruchu TCP i UDP wydaje się wystarczająca dla 99,9% użytkowników NetGuard. Od systemu Android 5 można wykluczyć routing aplikacji do sieci VPN (aplikacja wdrażająca VPN decyduje, czy jest to obowiązkowe czy opcjonalne), które można wykorzystać do rozwiązania problemów wynikających z niemożności przekazania całego ruchu. Inną opcją jest wykluczenie adresu (zakresów), którego NetGuard używa do „naprawy” połączeń IP u niektórych producentów.

Kolejną wadą jest to, że ruch związany z przekazywaniem zwiększy zużycie baterii na urządzeniach mobilnych, ponieważ wiąże się to z pewnym przetwarzaniem, ponieważ pakiety muszą być sprawdzane i przekazywane. Korzystanie z iptables, które jest zintegrowane z jądrem Linuksa, jest bardziej wydajne, a zatem bardziej przyjazne dla baterii.

Zasadniczo okazało się, że Android kieruje cały ruch do VPN, nawet ruch aplikacji i komponentów systemowych, ale producent może zdecydować o wykluczeniu niektórych rodzajów ruchu, zmniejszając bezpieczeństwo, które można osiągnąć za pomocą zapory sieciowej opartej na VPN.

NetGuard nie analizuje samych danych, z wyjątkiem żądań DNS w celu zapewnienia blokowania reklam, ale gdyby to zrobił, mogłoby to budzić obawy dotyczące prywatności. Niemniej jednak technicznie widać, że jest to zaleta zapory sieciowej opartej na sieci VPN (jeśli nadal chcesz ją tak nazwać), ponieważ pozwoliłaby na pełną kontrolę strumieni danych poza stanem możliwym w przypadku iptables. Byłoby to prawdopodobnie kosztem użytkowania baterii, ze względu na związane z tym przetwarzanie. Pamiętaj, że do sprawdzenia strumieni SSL wymagany byłby lokalny atak MiT.

Jeszcze inną wadą jest to, że Android nie pozwala na łączenie sieci VPN, więc użycie lokalnej sieci VPN do wdrożenia zapory sieciowej uniemożliwi korzystanie z prawdziwej usługi VPN, chyba że zapora sieciowa sama zapewnia taką usługę lub alternatywnie mechanizm przekazywania lub proxy do innej sieci VPN podanie.

Wreszcie zapora sieciowa oparta na sieci VPN zależy od aplikacji udostępniającej zaporę VPN. Wydaje się to trywialne, ale nie jest, ponieważ niektóre wersje / warianty Androida niektórych producentów zbyt agresywnie zabijają procesy w warunkach niskiej pamięci (IMHO jest błędem, jeśli Android zabija aplikacje świadczące usługę VPN).

Wreszcie, rootowanie urządzeń z Androidem staje się coraz trudniejsze, dlatego zapora sieciowa VPN jest jedynym wyborem dla wielu osób. Nie oczekuję, że Google w najbliższym czasie doda zaporę systemową, ponieważ może to znacząco wpłynąć na ich przychody z reklam. iOS ma zaporę systemową.

Daj mi znać, jeśli będą jakieś pytania, a ja postaram się na nie odpowiedzieć.

M66B
źródło
1
Dziękuję za odpowiedź. „pozwoli to na pełną kontrolę strumieni danych poza stanem możliwym w przypadku iptables” , iptables jest modułowy, a AFAIK nic nie stoi na przeszkodzie, aby zapewniał takie techniki głębokiej inspekcji pakietów (DPI). Jest nawet kilka projektów wdrażających to ( ndpi-netfilter , https://github.com/thomasbhatia/OpenDPI , l7-filter ), ale przypuszczam, że faktyczne zapotrzebowanie na takie rzeczy jest zbyt niskie w porównaniu do wymaganej pracy, więc wszystkie wydają się porzucony teraz.
WhiteWinterWolf
Tak, można to zrobić również przy użyciu modułu jądra Linux, ale jest to o wiele prostsze na poziomie aplikacji. Moduły jądra Linux muszą być kompatybilne z wersją jądra, co nie byłoby realną opcją na Androidzie przy tak wielu wersjach jądra na wolności. Wymagałoby to również uprawnień roota i wiedzy o tym, jak wstawić moduł jądra, czego nie można oczekiwać od przeciętnego użytkownika, chociaż może to być w jakiś sposób zautomatyzowane.
M66B,
10

Według mojej wiedzy jest to podejście:

Zapory ogniowe wykorzystują IPFilter / iptables do kontrolowania przepływu. Odnosi się to automatycznie do wszystkich aplikacji, niezależnie od tego, czy połączenie sieciowe jest w ogóle dostępne, czy nie, czy routing działa całkowicie, czy nie, albo czy znajdujesz się w „zamkniętym środowisku” (Intranet) bez dostępu do „zewnętrznego świata” „(Internet). Aplikacje, które zablokowałeś, są zablokowane. Na dość niskim poziomie.

Zapory użytkownika innego niż root nie mają dostępu do tego niskiego poziomu, dlatego muszą korzystać z obejść. W większości przypadków odbywa się to za pomocą urządzeń VPN systemu Android . W zależności od implementacji działa to całkowicie na urządzeniu (tj. Ponownie niezależnie od tego, jakie połączenie sieciowe może być dostępne) lub za pośrednictwem „usług zewnętrznych” (łączących cię z VPN dostawcy aplikacji). W tym drugim przypadku wszystko się psuje, gdy tylko ta usługa przestanie być dostępna - fakt, który możesz zauważyć lub nie. W obu przypadkach nie jestem pewien, czy tak naprawdę wszystkie aplikacje honorują VPN, czy też istnieją jakieś sposoby. 1 Kolejnym nieprzyjemnym faktem związanym z VPNami, o których czytałem, jest irytujące stałe powiadomienie, które mówi: „Twoja sieć może być monitorowana”- ale AFAIK, który powinien pojawić się tylko wtedy, gdy aplikacja wymaga zainstalowanego własnego certyfikatu. 2)

Werdykt: Osobiście bardziej ufam rozwiązaniu opartemu na rootowaniu. Ale tam gdzie nie jest możliwe, rozwiązania inne niż root powinny być prawie tak samo dobre. W takim przypadku moja rekomendacja dotyczyłaby rozwiązań typu open source, takich jak NetGuard (jego twórca również stworzył Xprivacy i cieszy się dużym zaufaniem). Mówiąc o tym: Aby uzyskać więcej informacji, zapoznaj się z wprowadzeniem NetGuard na XDA , który wyjaśnia tło z kilkoma szczegółami.


1 Nie znam szczegółów technicznych związanych z implementacją VPN Androida, ale cytując WhiteWinterWolf (patrz komentarz poniżej), to system podstawowy Androida musi to wymusić, nie ma powodu, aby sądzić, że nie jest to zrobione poprawnie.

2 Ponownie powołując WhiteWinterWolf: API VPN wykorzystywane przez NetGuard pozwala wszystkie dane mają być przechwytywane przez nieuprzywilejowany aplikacji, to co Android skutecznie uznać za „monitorowanie”, to nie ma związku z żadnym certyfikacie i to ostrzeżenie jest nieunikniona i spodziewane konsekwencją za pomocą tego interfejsu API.

Izzy
źródło
2
Dziękuję za odpowiedź. „Nie jestem pewien, czy tak naprawdę wszystkie aplikacje honorują VPN” : wymuszenie tego zależy od systemu bazowego Android, nie ma powodu, aby sądzić, że nie jest to zrobione poprawnie. „irytujące stałe powiadomienie” : interfejs API VPN używany przez NetGuard umożliwia przechwytywanie wszystkich danych przez nieuprzywilejowaną aplikację, to Android skutecznie uznaje za „monitorowanie”, nie ma związku z żadnym certyfikatem, a tego ostrzeżenia jest nieuniknione i oczekiwane konsekwencja korzystania z tego interfejsu API.
WhiteWinterWolf
Dzięki za szczegóły! Zintegrowałem je z moją odpowiedzią (przyznane kredyty), aby ułatwić ich wykrycie. Jeśli chodzi o „powiadomienie monitorujące”: gdziekolwiek to stwierdziłem, było to w kontekście instalowanego certyfikatu użytkownika. Ale dzięki za wyjaśnienia!
Izzy
1
Tak, to smutne, że Android ponownie używa tego samego powiadomienia do kilku niepowiązanych celów. W obecnym kontekście to powiadomienie należy połączyć z następującą instrukcją z poprzednio połączonej dokumentacji interfejsu API VPN : „Powiadomienie zarządzane przez system jest wyświetlane przez cały czas trwania połączenia VPN”. .
WhiteWinterWolf
1
Należy pamiętać o tym, czy istnieją sposoby na obejście VPN, podczas wyszukiwania czegoś innego znalazłem tę notatkę dotyczącą ulepszeń w Androidzie 4.4 : VPN na użytkownika . Na urządzeniach z wieloma użytkownikami VPN są teraz stosowane na użytkownika. Może to pozwolić użytkownikowi do kierowania całego ruchu sieciowego przez VPN bez wpływu na innych użytkowników urządzenia ”.
WhiteWinterWolf
2
  1. Oprócz ogólnego konsensusu, że rzeczywiste zabezpieczenia są niedostępne dla zrootowanych urządzeń i oczywiście zależy od użytkownika, AFWall + oferuje podejście filtrowania ruchu na poziomie jądra, podczas gdy NetGuard używa szyfrowania. Myślę, że możliwość działania jako administrator Androida bez konieczności pozostawania na pierwszym planie jest ważna ...
  2. AFWall + opcjonalnie używa skryptu uruchamiania na poziomie systemu, zapobiegając wyciekom danych w czasie uruchamiania (i, jak sądzę, również zamykania)
  3. Jeśli jest używany, ma również wbudowaną wtyczkę Tasker, która oferuje możliwość automatycznego przełączania profili po wykryciu zmiany łączności (naprawdę podoba mi się ten)
  4. Oparte na systemie Linux iptables w przeciwieństwie do metody VPN używanej przez Netguard
  5. Nie widzę żadnych opcji ochrony hasłem ustawień aplikacji w Netguard, ale nigdy też nie korzystałem z tej funkcji w AFWall +, więc ...

Myślę, że ważną funkcją, o której należy pamiętać o Netguard, byłaby możliwość filtrowania określonych adresów dla poszczególnych aplikacji. To jest płatna opcja.

Nie mogę powiedzieć, że VPN oparty na certyfikatach i iptables. Prawdopodobnie zależy to od wersji jądra i Androida dla iptables i NetGuard, algorytmów używanych do szyfrowania danych, niezależnie od tego, czy są one rejestrowane i gdzie są przechowywane. Moja odpowiedź może nie być tak techniczna, jak to, czego szukałeś, i tak długo, jak użytkownik AFWall + (wersja darowizny), jestem zdecydowanie stronniczy w tym względzie. Wiem jednak, że twórca NetGuard również aktywnie utrzymuje XPrivacy, bardzo dobrze znany / zaufany i solidny menedżer prywatności Androida. AFWall + wcale nie został porzucony, ale zdecydowanie nie otrzymał aktualizacji tak niedawno, jak NetGuard. Oba stosują różne metody utrzymywania kontroli ruchu, ale ostatecznie myślę, że to zależy głównie od użytkownika, jak bezpieczne jest dowolne urządzenie.

cbar.tx
źródło
Dziękuję za odpowiedź, szczególnie kula była bardzo pouczająca. Jak wiadomo NetGuard nie stosuje żadnego szyfrowania, po prostu korzysta z VPN API Androida, ponieważ ten interfejs API pozwala przekierować całą komunikację sieci danych do nieuprzywilejowanego procesu użytkownika. Początkowym celem tego interfejsu API jest umożliwienie takiemu procesowi obsługi połączenia VPN (w rzeczywistości szyfrowania itp.) Ze zdalnym hostem, ale NetGuard zamiast tego używa tej pozycji tylko lokalnie, aby móc analizować i filtrować ruch. O ile wiem, NetGuard nie ma rzeczywistej opcji VPN (w przeciwieństwie do AFWall +).
WhiteWinterWolf
Jedną z moich ciekawości nie zmusiło mnie do wyśledzenia ostatecznej odpowiedzi na pytanie, czy aplikacje są w ogóle tunelowane przez przesyłane shenanigany i jak skuteczne byłoby analizowanie i filtrowanie danych tunelowanych przez ten mechanizm VPN.
cbar.tx
Tunelowanie VPN jest przezroczyste dla innych aplikacji, uważają, że mają bezpośredni dostęp do Internetu, podczas gdy Android faktycznie przekierowuje komunikację do interfejsu VPN. O ile mi wiadomo, NetGuard nie analizuje samych danych, tylko informacje protokołu warstwy 3 (adresy IP i flagi) oraz nieudokumentowaną sztuczkę Androida, aby połączyć pakiet z aplikacją źródłową, to wystarczy, aby zdecydować, czy pakiet powinien być dozwolone czy nie.
WhiteWinterWolf
Nie istnieje żadna nieudokumentowana sztuczka dla Androida służąca do łączenia pakietów z aplikacjami, ale udokumentowana funkcja jądra Linuksa.
M66B
@ M66B: Dzięki za precyzję, w tym przypadku polegałem na artykule XDA, do którego link znajduje się w odpowiedzi Izzy: Odkryliśmy, że w celu odróżnienia ruchu od różnych aplikacji konieczne było skorzystanie z nieudokumentowanego dostępu do plików w jądrze System plików „proc”, aby przetłumaczyć procesy na identyfikatory UID aplikacji. Dostęp ten może być łatwo zablokowany w przyszłych wersjach Androida przez SELinux, a nawet może być zablokowany na urządzeniach bardziej zorientowanych na bezpieczeństwo ” .
WhiteWinterWolf