Usunięcie blokady portu 25 w Neostradzie.

Świat się nie zawalił. Narzekań specjalnych nie było, trochę psioczenia niektórych adminów (oj, nie wszyscy się przygotowali, nie wszyscy). Operacja się udała, więc pora na informację, jak zacną skądinąd blokadę wyłączyć.

Rano ten wpis wyglądał inaczej (i ta wersja niedługo wróci), ale z tego co wiem, polityka informowania na infolinii TP jest taka, że się nie da, więc na razie trzymajmy się tej wersji, bo z pewnych względów jest ona słuszna. Myślę, że oryginalna wersja powróci w okolicy Mikołajków.

Na wstępie uwaga: tak naprawdę wcale nie musisz tej blokady (i nie powinieneś – zobacz poprzednie wpisy, w których opisane są przyczyny jej wprowadzenia) wyłączać. O wiele lepszym rozwiązaniem jest zmiana konfiguracji czytnika poczty. No ale załóżmy, że skonfigurowałeś to komuś, komu za ChRL nie wytłumaczysz, jak zmienić konfigurację, a sam nie masz dostępu do tego systemu (pozdrawiam rodaków za granicą). Albo masz beznadziejny soft pisany na zamówienie, który wysyła maile na porcie 25 (bez uwierzytelniania, ciekawe, który admin serwera pocztowego przyjmuje taki syf z puli Neostrady). Co wtedy?

Póki co, postaraj się przekonfigurować czytnik poczty. Jeśli nie, zajrzyj za kilka dni…

Na wstępie uwaga: tak naprawdę wcale nie musisz tej blokady (i nie powinieneś – zobacz poprzednie wpisy, w których opisane są przyczyny jej wprowadzenia) wyłączać. O wiele lepszym rozwiązaniem jest zmiana konfiguracji czytnika poczty. No ale załóżmy, że skonfigurowałeś to komuś, komu za ChRL nie wytłumaczysz, jak zmienić konfigurację, a sam nie masz dostępu do tego systemu (pozdrawiam rodaków za granicą). Co wtedy?

Wtedy wystarczy zmiana loginu do usługi Neostrada. Na stronie TPSA zawarty jest dokładny opis możliwych ustawień poziomów ochrony przy pomocy loginu. Jak widać, możliwe w tej chwili są trzy warianty:

  1. „goły” login, czyli zablokowane porty „wirusowe” oraz 25,
  2. dodanie prefiksu „PODSTAWOWY-” do loginu – blokowane porty „wirusowe”, odblokowany port 25,
  3. dodanie prefiksu „BEZ_OCHRONY-” do loginu – odblokowane porty „wirusowe”, oraz port 25.

Aby odblokować wysyłkę poczty, wystarczy dodać prefix „PODSTAWOWY-„. Wpuszczanie wirusów nie ma sensu, szczególnie, jeśli użytkownikiem komputera jest ktoś, kto – mając do dyspozycji obrazkowe insturkcje – nie umie zmienić portu, na którym wysyłana jest poczta.

Jak widać, trzeba mieć zdalny dostęp do routera (albo założyć, że osoba, która nie umie zmienić portu poradzi sobie routerem, w co wątpię), albo zdalny dostęp do konfiguracji modemu (pod Windows to chyba tylko jakiś zdalny pulpit wchodzi w grę, ale wtedy lepiej zmienić port).

Kolejna niefajna sprawa, to fakt, że jeśli pomylimy się przy zmianie loginu (uwaga na wielkość liter, ma znaczenie!), to trwale odetniemy się od routera. Dlatego zmiana portu wysyłania poczty wydaje się znacznie lepszą, prostszą, bezpieczniejszą i korzystniejszą dla wszytkich opcją.

Wolność słowa w Chinach – możesz pomóc.

Jak można się było spodziewać, chińskie władze wzięły się za tor, czyli usługę anonimizującą pozwalającą na ominięcie państwowego firewalla, a tym samym na obejście cenzury i na dostęp między innymi do nieprawomyślnych – bo nie zatwierdzonych przez władze – informacji. W chwili obecnej blokowanych jest ok. 80% węzłów tora. Każdy może, w prosty i nie wymagający wielkich środków sposób, pomóc w walce z chińską cenzurą – poniżej przepis.

Na wstępie zaznaczę, że węzły tora dzielą się na kilka typów, z czego dwa nie grożą niczym nieciekawym osobom, które je prowadzą. Sprawdziłem to empirycznie prowadząc węzeł pośredniczący przez 4 miesiące przy konfiguracji opisanej w mini konfiguracji tora. Aby pomóc Chińczykom wymagana jest inna konfiguracja, ale także ona nie pozwala na nawiązywanie połączeń bezpośrednich, więc nie ma najmniejszych obaw, że ktoś coś zrobi nawiązując połączenie z naszego adresu IP i będziemy ciągani po sądach. Przy okazji – węzeł działa na słabym łączu 1024/256 kbit i słabym sprzęcie (PII 266 MHz, 64 MB RAM). Nie zauważyłem spowolnienia działania sieci czy odczuwalnego zwiększenia zużycia zasobów.

Aby pomóc Chińczykom musimy utworzyć tak zwany bridge-node, czyli węzeł mostkowy (brr, brzydkie tłumaczenie). Działa on tak, że przyjmuje połączenia przychodzące, a następnie przekazuje je do kolejnych węzłów (tylko i wyłącznie do kolejnych węzłów, nigdy bezpośrednio do celu). Jest o tyle pożyteczny, że nie jest widoczny na liście serwerów tora, a dane o nim są udostępniane zainteresowanym dopiero po wysłaniu maila na specjalny adres (dla zainteresowanych dokładny opis procedury uzyskiwania informacji o bridge-nodes.

Do rzeczy. Cała konfiguracja dla bridge-node składa się z 4 linii:

SocksPort 0ORPort 443               # port na którym nasłuchujemyBridgeRelay 1            # włączenie trybu bridge-nodeExitpolicy reject *:*    # blokada bezpośrednich połączeń wychodzących

Ja polecam – szczególnie posiadaczom słabszych łącz – na dodanie ograniczenia prędkości przesyłanych danych:

RelayBandwidthRate 20 KBytesRelayBandwidthBurst 30 KBytes

Trzeba też pamiętać o tym, by port na którym nasłuchujemy był dostępny z zewnątrz (publiczne IP lub przekierowanie na routerze). Zaleca się używanie popularnych portów (80, 443, itp.) – trudniej będzie je wychwycić i zablokować. Polecam też przeczytanie mojego poprzedniego wpisu na temat tora. Dotyczy co prawda innej konfiguracji, ale jest opisana część opcji.

Źródła: artykuł na heise-online, blog projektu tor, opis bridge-nodes na stronie projektu.

UPDATE: Tor posiada wersje dla większości systemów operacyjnych: OS X, Windows oraz Linuksa. tu możesz pobrać tora, a tu, dla wymagających tu więcej opcji. Jeśli chodzi o Linuksa, to zapewne znajduje się w repozytorium pakietów, z którego korzystasz.

UPDATE2: Nieco przydługi, ale ciekawy opis konfiguracji przekaźnika tora (dead link). Chyba głównie dla Windows przydatne – jakieś klikania opisane. 😉

WiFi Intela w Linuksie z WPA i WPA2

Koniec końców, mimo opisanych dawniej problemów udało mi się mieć nowy kernel, stabilne połączenie WiFi, i szyfrowanie WPA2 AES. Klucze do sukcesu były trzy, a winy ze strony fglrx – żadnej. Pierwszy, to odpowiednie opcje w kernelu. To udało się stosunkowo prosto, chociaż zmiany sposobu budowania modułów z wersji na wersję nie ułatwiały sprawy. Drugi, to odpowiednia konfiguracja wpasupplicanta. Trzeci, to wyłączenie ukrywania nazwy sieci w AP.

Ostatecznie konfiguracja WiFi w kernelu 2.6.30.1 wygląda dla 10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) następująco:

## Wireless LAN#CONFIG_WLAN_PRE80211=yCONFIG_WLAN_80211=yCONFIG_IWLWIFI=m# CONFIG_IWLWIFI_LEDS is not set# CONFIG_IWLWIFI_RFKILL is not set# CONFIG_IWLWIFI_SPECTRUM_MEASUREMENT is not set# CONFIG_IWLWIFI_DEBUG is not set# CONFIG_IWLAGN is not setCONFIG_IWL3945=mCONFIG_IWL3945_SPECTRUM_MEASUREMENT=y

Natomiast konfiguracja wpasupplicant wygląda tak:

ctrl_interface=/var/run/wpa_supplicantctrl_interface_group=0eapol_version=1ap_scan=1fast_reauth=0network={  ssid="tussidsieci"  scan_ssid=1  key_mgmt=WPA-PSK  proto=WPA2  pairwise=CCMP  group=CCMP  psk="tutajtajnyklucz"}

Żeby w ogóle działało z ukrytym SSID, konieczne jest dodanie opcji scan_ssid=1 . W przypadku normalnego SSID w niczym nie wadzi i jest opisana w czeluściach /usr/share/doc/wpasupplicant, szkoda że nie w man…

I jeszcze sieć ze zwykłym WPA i bez ukrytego SSID:

network={  ssid="tussidsieci"  key_mgmt=WPA-PSK  proto=WPA  pairwise=TKIP  group=TKIP  psk="tutajtajnyklucz"}

Działa także dla karty Intel 2200 na dystrybucyjnym jądrze z Debiana Lenny. No i gorąco polecam wicd. Bardzo przyjemny, w pełni klikany manager WiFi pod Linuksa. Niestety, w Lennym nieobecny, ale łatwo się backportuje.