Tag: sieć

Opublikowane w

Jak zrobić router GSM na Linuksie?

Niedawno miałem awarię netu. Stwierdziłem, że warto przy tej okazji poćwiczyć awaryjne udostępnianie sieci na Linuksie. Oczywiście zrobienie routera z komputera z Linuksem to kwestia paru poleceń, ale stwierdziłem, przećwiczyć udostępnianie sieci po WiFi.

Istnieje pakiet hostapd, który ułatwia zamianę komputera z Linuksem w access point. Instalacja pakietu hostapd:

apt-get install hostapd

Jakość pakietu nie zachwyca, ale jest niezły tutorial do hostapd. Skrypt init nie zadziała – należy go uzupełnić o ścieżkę do pliku – zmienna DAEMON_CONF. Podobnie sam pakiet nie dostarcza – jak to zwykle ma miejsce w przypadku pakietów Debiana – pliku konfiguracyjnego umieszczonego w katalogu /etc. Przykładowy plik konfiguracyjny dla hostapd znajdziemy jednak w /usr/share/doc/hostapd/examples.

Żeby nie przedłużać, poniżej cały plik konfiguracyjny, którego ostatecznie użyłem:

interface=wlan0country_code=PLssid=NAZWA_SIECIhw_mode=gchannel=6wpa=2wpa_passphrase=TAJNE_HASLOwpa_key_mgmt=WPA-PSKwpa_pairwise=TKIPrsn_pairwise=CCMPauth_algs=1macaddr_acl=0

Jak widać, są lekkie różnice w stosunku do tutoriala. Brakujące ustawienie zmiennej w skrypcie startowym znalazłem później, więc ostatecznie uruchamiałem hostapd z ręki, bez demonizacji (w ramach debugu, zresztą).

Oczywiście sama konfiguracja hostapd nie wystarczy. Trzeba mieć jeszcze skonfigurowane „przyjście” netu. W moim przypadku internet był dostarczony z modemu GSM (tutaj opis konfiguracji Aero2 na modemie Huawei E3131). Użycie modemu LTE pozwoli oczywiście zrobić szybszy router GSM na Linuksie. Przyda się również serwer DHCP i konfiguracja DNS. Obie rzeczy może załatwić dość dokładnie opisany kiedyś dnsmasq. Ale dla przydzielania adresów IP systemom łączącym się z naszym routerem GSM wystarczą dla ww. konfiguracji dwie linie w /etc/dnsmasq.conf:

interface=wlan0dhcp-range=192.168.1.100,192.168.1.200,255.255.255.0,1h

Należy też dodać adres IP na interfejsie wlan0, włączyć forward pakietów dla IPv4 oraz uruchomić NAT. Wersja „ręczna” ww. czynności (dla mojej konfiguracji, interfejsy mogą się zmieniać) to:

ip a a 192.168.10.1/24 dev wlan0
ip link set wlan0 up
service dnsmasq restart
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Po tym wszystkim, inne komputery powinny móc się połączyć z naszym linuksowym routerem GSM, dostać adres IP oraz posiadać dostęp do internetu za jego pośrednictwem. W przypadku problemów warto sprawdzić kolejno: otrzymanie adresu IP, ping do routera (192.168.10.1), ping do świata po IP, ping do świata pod domenie (w zasadzie: resolvowanie DNS).

Na rynku jest sporo sprzętów, które pozwolą zbudować mocny routera GSM na Linuksie. Choćby przykładowo Banana Pi, Orange Pi czy nieśmiertelne Raspberry Pi. Oczywiście jeśli miałby być to sam router, to nie bardzo widzę sens ekonomiczny, bo zestaw modem+płytka+karta wifi+zasilacz pewnie będzie kosztował więcej, niż tani router LTE (no chyba, że ktoś akurat – jak ja – ma ww. graty pod ręką 😉 ), ale w przeciwieństwie do taniego routera GSM można tu uruchomić dodatkowe funkcjonalności typu NAS, VPN czy serwer WWW. Ten ostatni to może niekoniecznie na łączu GSM…

Mam nadzieję, że opis się przyda. Gdybym o czymś zapomniał, albo coś nie działało, proszę o uwagi.

PS. Oczywiście mam świadomość, że udostępnienie internetu z GSM potrafi w trzech kliknięciach zrobić chyba każdy smartfon z Androidem. W przypadkach awaryjnych jest to pewnie najszybsza droga. I tak, użyłem Aero2 i pakietu testowego bez captcha. Niskie opóźnienia pozytywnie zaskakują.

UPDATE: Istnieje coś takiego jak projekt RaspAP, o którym warto wspomnieć. Narzędzie umożliwia konfigurację access pointa WiFi w ładny (GUI) sposób. Wsparcie dla wielu języków, wygodny dostęp do wielu opcji.

Opublikowane w

Automatyczne pobieranie kontaktu abuse dla domeny lub adresu IP

Zawsze miałem problem z szukaniem właściwego kontaktu abuse. No może problem to za dużo powiedziane, ale szukanie ręcznie, w hurtowych ilościach to nie jest nic ciekawego. Poza tym, jeśli chcemy zgłaszać automatycznie, to szukanie ręcznie odpada. A w danych whois były cuda, więc parsowanie tego byłoby wyzwaniem… Stosunkowo niedawno RIPE zrobiło jako taki porządek i pojawiły się pola abuse-c. Jednak już wcześniej znalazłem abusix i ich projekt Abuse Contact DB. Pozwala na wygodne odpytywanie o kontakty abuse przy pomocy DNS, więc szybko, prosto i wygodnie.

Trochę, żeby ułatwić życie kolegom, a trochę, żeby automatycznie zgłaszać nadużycia (np. próby włamań po SSH) ze swoich hostów, popełniłem funkcję w Perlu[1], która zwraca pierwszy email z listy, na podstawie ww. bazy. W międzyczasie zająłem się czym innym, znalazłem serwis, który rozwiązał temat automatycznego raportowania prób włamania. Temat więc trochę umarł. Przynajmniej do wczoraj/przedwczoraj, kiedy znalazłem ten wpis i dowiedziałem się, że najprawdopodobniej nikt nie powiadomił firm hostujących. Plus zwykła ciekawość: a gdzie te skompromitowane hosty leżą? Z potrzeby chwili i własnej ciekawości skleciłem skrypt, który bierze domenę (czyli adres strony), sprawdza jego IP (dokładniej: rekord A) i ustala stosowny adres email do kontaktu z abuse.

Wynik działania dla domen .pl jest tu, a wynik działania dla całej listy tu. Skrypt jest zdecydowanie do poprawienia i rozwoju. W tej chwili nie zwraca nic przy braku kompletu danych, czyli brak obsługi błędów, jest wolny, bo działa sekwencyjnie, nie jest to czysty Perl, nie obsługuje IP (ani IPv6 czyli rekordów AAAA), grupowania domen/IP po kontakcie abuse (żeby nie słać wielu maili na ten sam adres) i wysyłki maili, ale leci na GitHuba. W ramach motywatora. 😉 Może kiedyś przyda się komuś, kto znajdzie jakiś malware…

TIL: istnieje oficjalne narzędzie w Pythonie, obsługujące bazę danych abuse; działa zarówno dla IPv4 jak i IPv6 (ale nie obsługuje domen). Generalnie robi to, co moja pierwotna funkcja w Perlu, tylko trochę lepiej. Mam wrażenie, że jak wtedy patrzyłem na tę stronę, to go nie było…

PS Z różnych źródeł wiem, że większe polskie hostingi są już powiadomione, nie ma potrzeby wysyłania maili. 😉 Warto natomiast zobaczyć, czy nie ma na liście strony własnej/znajomych. Problem leży tak naprawdę po stronie użytkownika hostingu i  jego niezaktualizowanej aplikacji, więc tylko on może go tak naprawdę rozwiązać.

[1] Teraz widzę, że funkcja nie jest w czystym Perlu, tylko wywołuje zewnętrzny program host, poprawię wkrótce.

Opublikowane w

Panoptykon narzeka na ministerstwa i blokowanie Tora

Fundacja Panoptykon po raz kolejny narzeka na blokowanie przez ministerstwa IP, na którym mają uruchomiony węzeł Tor (relay-node). Sytuacja skłoniła mnie do wpisu, bo mam wrażenie, że zachodzi grube niezrozumienie tematu. Z obu stron…

Logo projektu Tor

Źródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg

 

Czy warto blokować ruch z sieci Tor?

To zależy. Ruch z sieci Tor pozwala na łatwe uzyskanie stosunkowo wysokiej anonimowości w sieci. Z jednej strony jest to wykorzystywane do anonimowej komunikacji przez zwykłych ludzi, z drugiej jest wykorzystywane do nadużyć i wandalizmu. Ze znanych serwisów wymienionych w FAQ – Wikipedia blokuje edycję artykułów z sieci Tor, podobnie Slashdot. Oczywiście takich serwisów jest o wiele więcej. Po prostu stosunek sygnał/szum jest w przypadku sieci Tor wyjątkowo niski.

Są też inne, poważniejsze powody do blokowania. O ile sieć Tor ma raczej słabą przepustowość i nie nadaje się do ataków wolumetrycznych, to zdecydowanie ułatwia łatwe, anonimowe ataki na aplikację, SQLi itp. Czyli raj dla script kiddies. I dokładnie taki jest oficjalny powód podany przez rzecznika ABW cytowany na Niebezpieczniku.

Jak blokować ruch z sieci Tor?

Autorzy projektu Tor podkreślają, że wezły sieci Tor mają indywidualne polityki, ale.. Patrząc z punktu widzenia administratora serwisu docelowego i ekonomii działania: sieć Tor to jakieś ułamki promila ruchu, w dodatku często ruchu niepożądanego. Jeśli ktoś zdecyduje się już blokować ruch z sieci Tor, to raczej nie będzie bawił się w polityki poszczególnych węzłów, tylko zablokuje wszystkie. Czy to na poszczególnych maszynach, czy to na centralnym firewallu, czy wręcz null-route’ując na routerach ruch kierowany do węzłów Tor (co uniemożliwi komunikację TCP). Ostatnia metoda jest i prosta w implementacji, i prosta w utrzymaniu (centralne miejsce do zarządzania), i wydajna.

Z których węzłów ruch blokować?

Tu jest pies pogrzebany. Fundacja Panoptykon nie prowadzi exit node, czyli nie przekazuje ruchu z sieci Tor do „normalnego internetu”. Niestety, oficjalne narzędzia udostępniane przez projekt Tor IMO nie są zbyt przyjazne administratorom (szczególnie tym, którzy są mniej świadomi zasad działania Tora lub którzy nie mają czasu). Blokowanie wszystkich węzłów Tora widziałem spotkałem, zarówno jako użytkownik końcowy (tak, relay node w domu, ruch z normalnego IP i komunikat o niewpuszczaniu z sieci Tor w serwisie), jak i administrator. Przede wszystkim brakuje oficjalnej listy węzłów wyjściowych łatwej do przetwarzania, czyli zawierającej same IP. Przypominam, że pisałem we wpisie o blokowaniu węzłów Tor, że udostępniam taką listę. Tylko exit nodes, tylko adresy IP.

Podsumowując, obie strony są winne:

Dziwią mnie żale ze strony Panoptykonu, gdy sytuacja jest typowa i opisana w FAQ Tora:

You might also find that your Tor relay’s IP is blocked from accessing some Internet sites/services. This might happen regardless of your exit policy, because some groups don’t seem to know or care that Tor has exit policies. (If you have a spare IP not used for other activities, you might consider running your Tor relay on it.)

Jak widać, projekt Tor zaleca prowadzenie węzłów na oddzielnych IP, nieużywanych do innych usług. Tak, wiem, sekcja dotyczy węzłów wyjściowych, ale idę o zakład, że pomysłodawca/admin w Panoptykonie nie czytał. Poza tym, zdrowy rozsądek zaleca analizę możliwych konsekwencji przed uruchomieniem usługi i stosowanie oddzielnych IP w tym przypadku.

Dziwi mnie też implementacja blokowania Tora na rządowych serwerach, wskazująca na niezrozumienie tematu. Oczywiście nie mam złudzeń co do korzystania przez nich np. z mojej listy (sam bym tego na ich miejscu nie zrobił), ale samodzielna implementacja to nie rocket science… Plus, niezrozumienie tematu może prowadzić do fałszywego poczucia bezpieczeństwa – tak naprawdę nie sposób zablokować 100% ruchu z sieci Tor, przynajmniej nie w oparciu o adresy IP.