Przejdź to tekstu

Uruchamianie Firefoksa w osobnej przestrzeni nazw zasobów sieciowych (osobna kopia stosu sieciowego) i przekierowanie całego ruchu poprzez sieć Tor

Kategoria: Artykuły, etykiety: namespace, przestrzeń nazw sieciowych, stos sieciowy, anonimowość, tor, nftables

Dodany przez: uzytkownikubunt, 2013-12-25 16:20 (zmodyfikowany: 2016-02-15 09:57)

Wyświetleń: 6423

Poradnik przetestowany na Ubuntu 12.04.3 (z jądrem 3.8), Kubuntu 14.04 oraz czystej instalacji Debian 7.3 z płyty netinstall ze środowiskiem xfce z jedyną zmianą: dodaniem oficjalnego repozytorium deweloperów Tora. Pierwotnie w poradniuku użyty był iptables, od 18 marca jest uaktualniony o sekcję dotyczącą nftable. Sekcja dotycząca nftables została przetestowana tylko na Kubuntu 14.04, który zbudowany jest w oparciu o rdzenne wnętrzności z Ubuntu 14.04 i środowisko KDE.

Oświadczam, że w konfiguracji mogą kryć się błędy, gdyż nie jestem zbyt doświadczony w konfiguracji sieci.

W artykule założyłem, że do komputera nie jest podłączona żadna sieć o adresach z puli 192.168.0.2/24 jak również 10.192.0.0/16. Jeśli jednak takowe są podłączone, należy wymyślić inne które nie są podłączone.

W dalszej części będę często wyrażenie "przestrzeń nazw zasobów sieciowych" zastępował skrótem ns (z ang. namespace). Problemy i uwagi proszę zgłaszać tutaj Dodatkowa uwaga: programy uruchomione wewnątrz ns nie mają dostępu do komunikacji międzyprocesowej za pomocą DBusa. W zależności od celu użycia ns jest to wada lub zaleta.

Cel:

  • Firefox nie może sprawdzić Twojego adresu IP i MAC za pomocą wywołań systemowych
  • Wszystkie pakiety TCP i DNS z /do Firefoksa przechodzą przez wirtualny interfejs sieciowy powiązany z instancją Tora

Czego nie osiągniemy? Pełnej izolacji procesów w ns od reszty systemu hosta. To oznacza, że atakujący mający kontrolę nad procesem w ns będzie miał taki sam dostęp do plików m.in. również logów w których może znajdować się Twój adres IP. Aby odciąć atakującego od reszty systemu całkowicie, należałoby zastosować dodatkowe rozwiązania np. systemy Mandatory Access Control/ACL. Pełne omówienie tematu przekracza zakres tego poradnika.

Co mamy osiągnąć? Wielu deweloperów aplikacji mogło nie brać pod uwagę, że ich użytkownicy będą chcieli wysyłać komunikację przez sieć Tor, albo w pewnym momencie, po wielu godzinach pracy, po prostu się zapomnieli. Konsekwencją tego może być pobranie od systemu operacyjnego Twojego adresu IP i wysłanie go do Internetu. Jeśli wymusi się na netfilterze, by wysyłał dane od każdego programu przez sieć Tor to i tak istnieje możliwość, że wysłany zostanie Twój adres IP. Tor spełni zadanie: anonimowo wyśle Twój adres IP do Internetu, jednak prawdopodobnie nie tego oczekujesz. Ten poradnik ma za zadanie pokazać, jak skonfigurować system, by programy nie widziały realnego adresu IP Twojej karty sieciowej i przez to go nie wysłały, a także w jaki sposób z tak wydzielonej przestrzeni wymusić wysyłanie danych do sieci Tor. Często tego typu rozwiązania nazywa się z ang. tor middlebox. Dzięki temu unikniemy wycieków naszego numeru identyfikującego w Internecie (IP), a także numeru MAC (identyfikującego w sieci lokalnej). Wycieki zapytań do serwerów DNS to również częsty problem osób dbających o prywatność. Zapobieganie wyciekom pakietów bezpośrednio do sieci jest bardzo ważne, a w Gnu/Linuksie bardzo proste. [Preventing Tor DNS Leaks].

Z czego będziemy korzystać? pakiet iproute - Narzędzia do kontroli sieci i ruchu w niej

Wywołania CLONE_NEWNET (dostępnego od czasów Linuksa w wersji 2.6.24 i uzupełnione od czasów Linux 2.6.29) za pomocą poleceń rozpoczynających się: sudo ip netns . Pozwala tworzyć nowe przestrzenie nazw sieciowych, uruchamiać w nich programy. Ns posiadają własne, odizolowane od reszty systemu urządzenia sieciowe (karty sieciowe), adresy IP, tablicę routingu, katalog /proc/net, numery portów itd.

  1. Tworzymy ns

    sudo ip netns add afirefox

  2. Tworzymy parę veth0<->veth1

    sudo ip link add veth0 type veth peer name veth1

  3. Wrzucamy veth1 do ns:

    sudo ip link set veth1 netns afirefox

  4. Konfigurujemy veth0:

sudo ip addr flush dev veth0

sudo ip addr add 192.168.0.2/24 dev veth0

sudo ip link set dev veth0 up

  1. Konfigurujemy veth1 w ns:

    sudo ip netns exec afirefox ip addr flush dev veth1

    sudo ip netns exec afirefox ip addr add 192.168.0.1/24 dev veth1

    sudo ip netns exec afirefox ip link set dev veth1 up

  2. Włączamy loopback w ns:

    sudo ip netns exec afirefox ip link set dev lo up

  3. Ustawiamy routing w ns. Następnie będzie go można go sprawdzić komendą od drugiej linijki:

    sudo ip netns exec afirefox ip route add default via 192.168.0.2

    sudo ip netns exec afirefox ip route show

    default via 192.168.0.2 dev veth0

    192.168.0.0/24 dev veth0 proto kernel scope link src 192.168.0.1

  4. (Krok opcjonalny, dla dodaniach swojego rodzaju checkpointu). Teraz za pomocą iptables na hoście przesyłamy przez maskaradę:

    su -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

    sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

    sudo iptables -A FORWARD -i eth0 -o veth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

    sudo iptables -A FORWARD -i veth0 -o eth0 -j ACCEPT

  5. Ustawiamy adresy DNS. W zależności od tego w jaki sposób masz skonfigurowane w systemie ustawianie adresów DNS, w niektórych przypadkach program w ns nie będzie mógł tego ustawienia przeczytać, co za tym idzie będzie pozbawiony możliwości DNS. Jednym ze sposobów jest wyedytowanie /etc/resolv.conf

    nameserver 87.118.100.175

    nameserver 77.109.138.45

Należy pamiętać, że niektóre usługi jak np. resolvconf potrafią automatycznie po każdym restarcie zmienić wpisy w /etc/resolv.conf, co może zablokować możliwość korzystania z Internetu wewnątrz ns.

Po tym wszystkim (łącznie z punktem 8) powinniśmy móc połączyć się z Internetem z wewnątrz ns (uruchamiamy przez su, bo normalnie ruchomilibyśmy Firefoksa spod konta roota).

sudo ip netns exec afirefox su -c 'firefox' nazwauzytkownika

Jeśli nie działa uruchamiany ping jakiejś popularnej strony:

  1. Z konta na hoście (poza stworzonym ns) np. ping www.google.com -c 1

  2. W ns pingujemy, ale adres IP zwrócony przez polecenie ping w pkt 1 np. sudo ip netns exec afirefox su -c 'ping 173.194.112.80 -c 1' nazwauzytkownika

  3. Jeśli w punkcie powyższym polecenie działa, a nie działa z ns pingowanie domeny to mamy problem z DNS.

Problemy i uwagi proszę zgłaszać tutaj

  1. Teraz konfigurujemy, by wszystko szło przez tora z wewnątrz ns. Trzeba będzie usunąć regułki z iptables z hosta, którymi w punkcie 8 ustanowiliśmy maskaradę (NAT). Czyścimy tablicę prerouting i postrouting

    sudo iptables -t nat -F

  2. Musimy skorzystać z pewnej funkcji klienta sieci Tor zwanej Transparent Proxy. Backupujemy stary plik konfiguracji /etc/tor/torrc

mv /etc/tor/torrc /etc/tor/torrc.kopia

W pliku /etc/tor/torrc ustawiamy:

 SocksPort 0 # Wyłączamy zwykłe proxy socks
 TransListenAddress 192.168.0.2:9040
 TransPort 9040
 DNSListenAddress 192.168.0.2:9053
 DNSPort 9053
 AutomapHostsOnResolve 1
 VirtualAddrNetwork 10.192.0.0/16 # tutaj musimy uważać, by ta podsieć nie pokrywała się z  jakąkolwiek 
 podłączoną do naszego komputera o tej samej numeracji. Tor będzie mapował adresy domen .onion na te 
 adresy ip i jeśli prześlemy ruch przez tora z adresem docelowym o tym ip to połączy nas ze stroną .onion.
  1. Restartujemy Tora, by działał na podstawie nowej konfiguracji:

    sudo /etc/init.d/tor restart

  2. Wyłączamy ip forwarding i ustawiamy w iptables przesyłanie całego ruchu po tcp i dns (53 port UDP) do klienta Tor, przy okazji ustanawiając prosty firewall:

    su -c 'echo 0 > /proc/sys/net/ipv4/ip_forward'

    sudo /sbin/iptables -t nat -A PREROUTING -i veth0 -p udp --dport 53 -j DNAT --to-destination 192.168.0.2:9053

    sudo /sbin/iptables -t nat -A PREROUTING -i veth0 -p tcp -j DNAT --to-destination 192.168.0.2:9040

    sudo iptables -F INPUT

    sudo iptables -I INPUT 1 -i lo -j ACCEPT

    sudo iptables -I INPUT 2 -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

    sudo /sbin/iptables -I INPUT 3 -i veth0 -p udp --dport 9053 -j ACCEPT

    sudo /sbin/iptables -I INPUT 4 -i veth0 -p tcp --dport 9040 -j ACCEPT

    sudo /sbin/iptables -I INPUT 5 -i veth0 -j REJECT

    sudo iptables -P INPUT DROP

    sudo /sbin/iptables -F FORWARD

    sudo /sbin/iptables -P FORWARD DROP

  3. W końcu uruchamiamy Firefoksa z wewnątrz oddzielnej przestrzeni nazw sieciowych, z której wyjście kierowane jest przez Tora:

sudo ip netns exec afirefox su -c 'firefox' nazwauzytkownika

Część druga, czyli skorzystajmy z nftables zamiast iptables.

Nftables to alternatywa dla iptables, która do głównej gałęzi jądra została dodana w czasie rozwoju jądra 3.13. Oprócz jądra 3.13 lub nowszego z wkompilowaną obsługą nftables, należy zaopatrzyć się w komponenty w userspace. Ta część poradnika była testowana tylko na Kubuntu 14.04 (standardowe jądro generic) z ppa:xuzhen666/nftables. Warto mieć też na uwadze, że nftables nie jest jeszcze szeroko używanym rozwiązaniem, więc nie jest jeszcze tak zaufany jak iptables. Ta część poradnika jest alternatywną drogą do wykonania tego, co w pkt który zaczynał się od słów "Wyłączamy ip forwarding " za pomocą nftables. Plik z regułami niech nazywa się w tym poradniku tor.rules i należy wstawić do niego następującą treść:

#! nft -f
   table filter {
    chain input         { 
    type filter hook input priority 5; 
    # Akceptujemy połączenia już wykonane
    ct state {established, related} counter accept

    # Akceptujemy wszystkie pakiety na loopback interface
    iifname lo accept

    # Odrzucamy błędne pakiety
     ct state invalid counter drop

    # Akceptujemy pakiety icmp
    ip protocol icmp accept

    # Otwieramy port tcp 9040 port dla połączeń przychodzących na interfejs veth0
    iifname veth0 tcp dport 9040 counter accept

    # Otwieramy port udp port 9053 (DNS) dla pakietów DNS
    iifname veth0 udp dport 9053 counter accept


    # Wszystko inne odrzucamy
    counter reject;
  }
        #Odrzucamy pakiety forwardowane
        chain forward           { type filter hook forward priority 5; counter reject;}
}
#Wyłączamy komunikację przez IPv6
table ip6 filter {
        chain input             { type filter hook input priority 0; reject; }
        chain forward           { type filter hook forward priority 0; reject; }
}


table nat {
chain prerouting        {
type nat hook prerouting priority -150;
#Wykonujemy docelowy NAT dla pakietów udp które przyszły na port 53 i wszystkich tcp na wejściu do interfejsu veth0
iifname veth0 udp dport 53 counter dnat 192.168.0.2:9053;
iifname veth0 tcp dport 0-65535 counter dnat 192.168.0.2:9040;
}

chain post              {
 type nat hook postrouting priority -150; 
  #Wykonujemy źródłowy NAT na pakietach
  ip saddr 192.168.0.2  meta oif veth0 counter snat 192.168.0.1;
        }
}

Załadowanie tego pliku z regułami należy najpierw uprzedzić czyszczeniem poprzednich. Można to wykonać takim zbiorem komand, które można zapisać w pliku polaczns.sh

#! /bin/sh
#Ładujemy odpowiednie moduły odpowiedzialne za NAT
modprobe nft_nat
modprobe nft_chain_nat_ipv4
modprobe nft_chain_nat_ipv6
# Wyłączamy forwardowanie
su -c 'echo 0 > /proc/sys/net/ipv4/ip_forward'
#Czyścimy tablicę filter
nft flush table filter
#Usuwamy łańcuch input
nft delete chain filter input
#Usuwamy łańcuch forward
nft delete chain filter forward
#Usuwamy tablicę filter
nft delete table filter
#I podobnie dla innych:
nft flush table ip6 filter
nft delete chain ip6 filter input
nft delete chain ip6 filter forward
nft delete table ip6 filter
nft flush table nat
nft delete chain nat prerouting
nft delete chain nat post
nft delete table nat
#Ładujemy reguły:
nft -f tor.rules

Następnie można nadać prawo wykonywalności plikowi polaczns.sh za pomocą komendy: chmod +x polaczns.sh I go uruchomić: /polaczns.sh Oczywiście, uruchomić należy go z konta roota, a także pliki mieć w tym samym folderze i w nim być, z tego powodu, że nie użyto bezwzględnych ścieżek do plików

Problemy i uwagi do artykułu proszę zgłaszać tutaj

Mirrory (serwery lustrzane, backup) artykułu:

Nie uaktualniona: http://dug.net.pl/tekst/262/uruchamianie_firefoksa_w_osobnej_przestrzeni_nazw_zasobow_sieciowych_%28osobna_kopia_stosu_sieciowego%29_i_przekierowanie_calego_ruchu_poprzez_siec_tor

Nowsza: http://dug.net.pl/tekst/262/uruchamianie_firefoksa_w_osobnej_przestrzeni_nazw_zasobow_sieciowych_%28osobna_kopia_stosu_sieciowego%29_i_przekierowanie_calego_ruchu_poprzez_siec_tor

OSnews Wykop Blip Flaker Kciuk Śledzik Facebook Identi.ca Twitter del.icio.us Google Bookmarks