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: 2013-12-25 16:20
(zmodyfikowany: 2016-02-15 09:57)
Przez: uzytkownikubunt
Wyświetleń: 10565
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.
Tworzymy ns
sudo ip netns add afirefox
Tworzymy parę veth0<->veth1
sudo ip link add veth0 type veth peer name veth1
Wrzucamy veth1 do ns:
sudo ip link set veth1 netns afirefox
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
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
Włączamy loopback w ns:
sudo ip netns exec afirefox ip link set dev lo up
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
(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
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:
Z konta na hoście (poza stworzonym ns) np. ping www.google.com -c 1
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
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
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
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.
Restartujemy Tora, by działał na podstawie nowej konfiguracji:
sudo /etc/init.d/tor restart
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
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:
