vermin.eu.org

Specjalista IT na tru^Hopie

Entries Comments



Month: December, 2006

Czy będąc za routerem instalować firewall?

27 December, 2006 (00:53) | bezpieczeństwo | By: vermin

Takie właśnie pytanie przyniosło tu kogoś przez Google. Ponieważ temat jest jednym z tych religijnych (chociaż chyba coraz mniej), to jednak są zarówno pewne plusy jak i minusy takich rozwiązań, na temat których w własną opinię postaram się przedstawić w kontekście kilku zmiennych. Jest to ponadto decyzja biznesowa, odbijające się na domowym/firmowym budżecie - koszt licencji sensownego firewall na stację kliencką Windows to wydatek minimum 100 pln.

Oczywiście należy rozumieć fakt, iż bycie “za routerem” nie zawsze musi oznaczać bycia “niewidocznym” w sieci Internet, co dokonuje się zazwyczaj przez zastosowania jakiegoś rodzaju translacji portów (maskarada/SNAT) i (opcjonalnie) “ściany ogniowej”. Jest to oczywiste na poziomie ISP lub też sieci firmowych, niemniej nawet w usługach abonenckich, np. w jednej z opcji internetDSL dostajemy większą pulę adresową niż standardowe /30 (można dostać 5 możliwych do przypisania urządzeniom końcowym adresów IP) przez co komputery za routerem mogą używać adresów publicznych.
W tej sytuacji pomimo, że firewall i router nie są pojęciami tożsamymi, my jednak zajmijmy się sytuacją, kiedy gateway de facto jest dla nas urządzeniem:

  • dokonującym translacji adresów (zamieniającym ruch wychodzący/przychodzący na jeden przyznany adres publiczny na szereg adresów prywatnych z pul 192.168.x.y(/16) 172.16.x.y(/12) 10.x.y.z(/8))
  • posiadającym firewall nieprzenoszący ruchu przychodzącego z sieci zewnętrznej do sieci wewnętrznej o ile nie jest on powiązany z sesja nawiązaną z wewnątrz sieci (czyli odrzucającym wszystko przychodzące z zewnątrz o co się wyraźnie nie pytaliśmy)

Skoro ustaliliśmy już model wyjściowy, czas odpowiedzieć sobie na pytanie postawione w tytule notatki - czy instalować tego firewalla czy też nie?

Środowisko domowe a firma
Sieć domowa zazwyczaj składa się z jednego lub więcej komputerów. Użytkownicy tych komputerów często działają na kontach posiadających zbyt szerokie uprawnienia (administrator/root) i są sobie samymi sterem i okrętem. Komputery nie udostępniają żadnych usług i nie ma potrzeby dostępu do nich z zewnątrz poza ściśle wylistowanymi i zazwyczaj określonymi wstępnie na routerze przypadkami (GG, eMule, BitTorrent, soulseek, etc.) - niemniej instalowane jest na nich wiele niesprawdzonego oprogramowania, któremu warto odcinać możliwość kontaktu ze światem. Nie każdy komputerowy ET powinien móc dzwonić do domu - szczególnie, jeśli podczas komunikacji prześle także nasze poufne dane. W takiej sytuacji dodatkowa opcja zabezpieczeń - w szczególności właśnie filtrowania połączeń wychodzących, czego nie zapewnia wbudowany w Windows firewall, jest szczególnie ważna.
W firmie zazwyczaj mamy sytuację bardziej złożoną - zarówno ze względu na większą kontrolę punktu styku sieci wewnętrznej i zewnętrznej, która wykraczać powinna poza kontrolę stanu połączenia, ale bardziej wkraczać w filtrowanie na poziomie aplikacji i specyfikę protokołów komunikacyjnych. Ponadto zazwyczaj użytkownicy nie mają uprawnień administratora, zaś ich stacje robocze powinny być otwarte na dostęp administracyjny właśnie - aby pewne operacje mogły zostać przeprowadzone (zdalny pulpit, przejęcie pulpitu, kontrola aplikacji, kontrola maszyny i usług, etc.) W tej sytuacji i tak otwieramy maszynę na dostęp z zewnątrz - chociażby z “zaufanej” podsieci adminstratorskiej (tak jakby nie istniała możliwość oszukania switchy (arp poisoning), fałszowania adresów IP i innych takich), więc stawianie zapory ogniowej na każdej stacji może nie być aż tak konieczne, jak zapewnienie bezpieczeństwa serwerom albo stacjom roboczym pełniącym ich rolę oraz odpowiedniemu filtrowaniu w punkcie styku.

Sieć mała a rozległa
Czy skala sieci ma znaczenie? Moim zdaniem ma, i to odwrotnie proporcjonalne. Im większa sieć, tym mniejsza potrzeba używania firewalli na stacjach klienckich, im sieć mniejsza, tym potrzeba większa. Twierdzenie to wydaje się być dosyć niedorzeczne, przecież enterprise, ta skala, ta konieczność kontroli… Właśnie dlatego wydaje mi się, że tam można, ale nie za bardzo trzeba. W sieci o dużej skali stacje robocze powinno się dać łatwo spacyfikować a wszelkie zagrożenia wykryć ponieważ:

  • W sieci powinny działać systemy analizujące/blokujące ruch na podstawie typowego zachowania - większość klientów wewnętrznych nie potrzebuje łączyć się na portach innych niż 25, 80, 110, 443. Ba, w większości przypadków także taki ruch nie zawsze jest pożądany kiedy cel jest poza adresacją wewnętrzną firmy… albo właśnie w niej, ale na maszynach, które nie pełnią danej roli. W zasadzie im firma większa, tym większa sieć, tym większa potrzeba stawiania takich maszyn w pewnych węzłach sieci.
  • Zazwyczaj, chociażby z konieczności zmniejszenia domeny broadcastowej, zmniejszenia skali zniszczeń po ataku robaka, wielości oddziałów, budowy VPNów, DMZów i innych skrótowych oznaczeń, tworzy się dodatkowe, wewnętrzne firewalle, separujące odpowiednie segmenty sieci i nie pozwalające na przenoszenie nieodpowiedniego ruchu na szerszą skalę.
  • Dostęp do sieci powinien być autoryzowany, chociażby 802.1x - to także zazwyczaj dzieje się przy budowie sieci większych, bo to dodatkowe maszyny czy też switche obsługujące ta technologię
  • Switche mogą mieć ustawione triggery odłączające maszynę przy zbyt dużej ilości generowanych pakietów.
  • Systemy antywirusowe w kluczowych miejscach sieci, wysyłają alarmy w wypadku zagrożeń pochodzących z wewnątrz.
  • Istnieje możliwość szybkiego wycięcia klienta sprawiającego problemy - już w miejscu jego podłączenia do sieci, (co także wymaga odpowiedniego sprzętu).
  • Stacje robocze nie pełnią funkcji repozytoriów danych, (ba, czasem to nawet tylko terminale klienckie łączące się z systemem macierzystym), więc ich partykularne bezpieczeństwo jest mniej cenne niż bezpieczeństwo sieci jako całości.

Co prawda ostatni punkt nie jest w pełni prawdą - ponieważ każdy system jest tak trwały, jak jego najsłabsze ogniwo - niemniej, jesli nałożymy pewne obostrzenia sieci korporacyjnej (integralność sprzętu) możemy to uproszczenie zastosować.

Te wszystkie rzeczy trudniej jest realizować w mniejszych sieciach, w mniejszych firmach, gdzie każdy dodatkowy czy tez przestarzały komputer jest i tak zagospodarowywany chociażby na maszynę do pisania - a nie na system bezpieczeństwa. W końcu to sprzęt który miałby chodzić 24/7, zużywać energię - i co ważne dla domowego użytkownika, czyli sieci o mikro skali - generować hałas.
Ponadto składowanie danych odbywa się właśnie na tych węzłach sieci, które generują ruch, wymiana danych odbywa się w stylu komputer-do-komputera(1), więc tam szczególnie potrzebna jest ścisła kontrola i możliwie wczesne raportowanie wszelkich możliwych nadużyć - takich jak nagła chęć komunikacji zegara systemowego ze światem. Więc im mniej rzeczy z powyższej listy zastosowane jest w Twojej sieci, tym bardziej powinieneś pomyśleć o stosowaniu zapory ogniowej.

Wielość interfejsów oraz maszyny przenośne
Nowoczesna maszyna zaczyna zawierać coraz więcej interfejsów - sieci przewodowe, bezprzewodowe (takie jak WiFi/WiMAX czy bluetooth i jego PANy) czy też komórkowe. Wszystkie z nich pozwalają dostęp do naszej maszyny i zgromadzonych na niej danych - niektóre jest łatwiej kontrolować (sieć kablowa) inne trudniej. Jeśli nie potrafimy panować nad medium, którym przesyłane są dane - a kto potrafi zapanować nad powietrzem i przenoszonymi przez nie falami EM - to powinniśmy pilnować mocno punktu końcowego.
Tu w szczególności ma zastosowanie konieczność posiadania zapory ogniowej za routerem. Przecież nagle nasza sieć wewnętrzna staje się otwarta - i wzmiankowany na wstępie router i jego firewall nie zapobiegają już atakom na nasza maszynę. Te ataki przychodzą z wewnątrz sieci! Stąd brak posiadania firewall oznacza możliwość wykorzystania naszej maszyny do celów nie do końca pożądanych. Ponadto wykorzystując sieci, które nas ‘chronią’ przed dostępem z zewnątrz same nadając nam wewnętrzną, nie przechodząca do internetu adresację, takie jak np. blueconnect, iPlus czy dowolny hotspot, otwieramy do nas dostęp z własnej sieci danego operatora - przed którego złośliwymi użytkownikami ochroni nas jedynie nasz własny firewall.
Ponadto warto zauważyć, że nawet tak banalny system jak Windows 2000 pozwala przerzucać ruch w trybie bridge albo za pomocą dzielenia łącza - wtedy w szczególności warto ograniczyć albo taką opcję w ogóle, albo móc filtrować to, co przez komputer przechodzi. Nasz zysk z użyczania dostępu do sieci może się zamienić w poważne problemy, jeśli ktoś poprzez to udostępnione połączenie narobi ambarasu…

Podsumowanie, czyli co powinna potrafić zapora ogniowa
W artykule omawiając rózne sprawy pominąłem pastwienie się szczegółowo nad DMZ czy VPN, bo to także wykracza poza (i tak straszenie rozszerzone) ramy postawionego na wstępie pytania. A jaka jest odpowiedź? Wydaje mi się, że dosyć jasna. Tak - firewall. Albo na jednej stacji, albo rozproszony, ale firewall. Filtrowanie ruchu jest potrzebne, wskazane i pożądane - w końcu to jedna z barier chroniąca nas przed wyciekiem pieniędzy: albo cennych danych, albo dla ‘pana od komputerów’ na doprowadzenie systemu do porządku.

    Na zakończenie lista cech - co taki firewall powinien umieć?

  • Uruchamiać się przy starcie systemu, tak aby być gotowym już wtedy, gdy jest nadany adres i możliwa komunikacja z systemem z zewnątrz, przed uruchomieniem pozostałych usług opartych na sieci innej niż pętla wewnętrzna
  • Umożliwiać filtrowanie nie tylko ruchu przychodzącego, co odcina nas od hakjeruff w Sieci, ale także ruchu wychodzącego, co pozwala w jakimś sensie zabezpieczyć się przed własnymi błędami
  • Umożliwiać kontrolę jaka aplikacja może wysyłać dany rodzaj ruchu - po co np. zegar systemowy miałby łączyć się z portem innym niż ntp/daytime? Po co przeglądarce ruch na port 25?
  • Tworzenie reguł w nawiązaniu do konkretnych interfejsów/typów interfejsów.
  • Tworzenie reguł czasowych - np. otwórz ten port na tą sesję/na 30 minut
  • Zawierać dużą ilość predefiniowanych reguł pozwalających na automagiczną konfigurację znanych (i/lub podpisanych cyfrowo) aplikacji wraz z aktualizacją tej listy.
  • W miarę możliwości filtrować w warstwie aplikacji, tak aby odfiltrowywać ataki na przypadkowo uruchomionego na stacji roboczej IIS czy SQL Server (WMSDE/MSDE) czy linuxowe odpowiedniki.
  • Wyświetlać jasne komunikaty, że jakieś niepokojące zdarzenie ma miejsce - i to najlepiej w ilości niepozwalającej przejść obojętnie, albo miec opcję wysyłania takich ostrzeżeń do znajomego pana od komputerów/działu IT.
  • Monitorować tworzone ad-hoc interfejsy (BT, GPRS, WiFi) i w zależności od polityki albo je wyłączać albo chronić.
  • Monitorować ruch przechodzący przez maszynę, jeśli prowadzi routing.
  • Móc całkowicie, definitywnie odłączyć maszynę od sieci - tak, żeby była potrzebna fizyczna interwencja administratora.
  • Tworzyć zapisy swoich działań i móc raportować je do systemów zewnętrznych.

(1) W Windows Vista i w Longhorn serwer został/zostanie zaimplementowany wewnętrznie protokół p2p, który pewnie pozwoli na rozproszone i szybkie składowanie danych w dużych skupiskach i pozwoli(?) wykorzystać nadmiar pamięci masowej na stacjach roboczych :)

Druki bezadresowe, czyli jak wyrzucić pieniądze w błoto

23 December, 2006 (01:32) | reklama i okolice | By: vermin

Firmy uwielbiają wysyłać na święta życzenia - cel jest oczywisty: budowanie świadomości marki, kontakt z klientem - jeśli już tym klientem był, wysyłanie informacji o swoim istnieniu. Cel pierwszy i ostatni oferując produkt masowy osiąga się przez efekt skali - w tym celu można wykorzystać np. pocztę, która jak wiadomo po ostatnim strajku roznosi tony ulotek reklamowych.
No właśnie - co znalazłem w i na skrzynce na listy? Idealny sposób jak pomimo poniesionych niemałych nakładów finansowych osiągnąć efekt mizerny, jeśli jakikolwiek. Dotarła do mnie dość ładna, wydrukowana na dobrej jakości papierze, otwierana kartka pocztowa z życzeniami od sprzedawcy towarów AGD, którego klientem nigdy nie byłem. Wszystko wydaje się ok - gdzie to wyrzucanie pieniędzy w błoto? Cóż - byłoby ok, gdyby nie fakt, że zapakowana została w zwykłą, tanią, białą, nieprzezroczystą, niezaadresowaną, zaklejoną kopertę. Ja się zaciekawiłem kto zrobił coś tak głupiego - ale ilość kartek leżących na skrzynce, gdzie współmieszkańcy mojej klatki odkładają druki reklamowe pokazuje, że byłem w zdecydowanej mniejszości. Chociaż może się nie znam i tu mieszkają niestandardowi konsumenci?

Przerzucanie portów na iptables, z haczykiem

22 December, 2006 (04:56) | bezpieczeństwo, linux | By: vermin

Sprawa wydawałaby się bananalna. Pakiety wchodzą z internetu (interfejs zewnętrzny, zewnętrzny IP) do routera i mają trafić do jakiegoś komputera w sieci. Router robi jakąś maskaradę sieci wewnętrznej. Ponieważ chcemy przejąć w tejże sieci wewnętrznej pulpit, powiedzmy, że to będzie WXP Pro, czyli interesuje nas port 3389. Zakładamy, że port na który wchodzą pakiety, to port 33089
OK - czyli do tej pory mamy:

  • zewnętrzny IP routera (np. 193.213.32.4),
  • wewnętrzny IP/sieć routera (np. 172.16.34.1/16),
  • port routera: 33089
  • adres WXP (np. 172.16.34.56),
  • port WXP: 3389
  • swój adres: 83.24.240.244

Sprawa banalna, opisana wszędzie, wystarczy wykonać dwa polecenia:

  • /sbin/iptables -A PREROUTING -t nat -s 83.24.240.244 -d 193.213.32.4 –dport 33089 -j DNAT –to-destination 172.16.34.56:3389
  • /sbin/iptables -A FORWARD -d 172.16.34.56 -p tcp –dport 3389 -j ACCEPT

Pierwsza z reguł mówi, że kazdy pakiet wchodzący z sieci zewnętrznej, kierowany na IP 193.213.32.4, port 33089 powinien być przekierowywany na maszynę o IP 172.16.34.56 i port 3389. Jest to reguła sprawdzana zanim zostanie podjęta jakakolwiek decyzja o routingu. Pakiety wpadają sobie do firewalla, podejmowana jest decyzja o routingu, ponieważ sieć docelowa jest wśród tych, które firewall osbługuje, to wrzuca pakiet do łańcucha forward, stąd konieczność (reguła 2) umożliwienia takiego właśnie ruchu.

Banalna sprawa, nieprawdaż? Gdzie ten haczyk? Cóż, wszystko działa oprócz tego, że TU nie działa. Otóż komputer kliencki ma swojego firewalla, który to spryciarz dopuszcza tylko połączenia z sieci wewnętrznej, (co łatwo sprawdzić, bo odrzuca połączenia z zewnątrz, a telnet na port działa). Zastosowany tu DNAT niestety nie tłumaczy adresu źródłowego na adres lokalny i pozostawia 83.24.240.244, co klient od razu ubija - pojawia się konieczność szukania zagrody, znaczy obejścia.
W tym momencie szkoły są dwie: falenicka i otwocka. Albo nie mamy czasu, olewamy sprawę, komfigurujemy tunel i voila, jesteśmy w środku i mamy dostęp do maszyny, albo nie mamy czasu, niemniej pokombinujemy z iptables. Pierwsza rzecz, która się nasuwa, to przeróbka pakietu. Niestety tablica mangle nie do tego została stworzona, żeby przerabiać takie cuda, więc nie tam. Są polecenia conntracka zamiany adresów, ale one raczej nie mają tu zastosowania. Rozwiązanie sprawy leży znów w NATce. Tym razem jednak na wyjściu.

  • iptables -A POSTROUTING -t nat -s 83.24.240.244 -d 172.16.34.56 -p tcp –dport 3389 -j SNAT –to 172.16.34.1

Cóż to robi? Bada pakiet już wychodżacy z routera i jeśli spełnia on warunki źródła, celu, portu… to robi NAT (zwany popularnie maskaradą) zamianiejąc jak to w nacie bywa adresy źródła (-s), ukrywając je za adresem bramy. Nie ukrywam, że przez dłuższą chwilę nie przyszło mi do głowy, że to może być tak banalne (przecież to zwykły NAT, tylko na opak), niemniej szybka, nocna lektura dokumentacji pozwala na usprawnienie procesów myślowych.

Jedyne co mnie zastanawia, to fakt, że zawsze najlepsze (czytaj: działające w zadowalający sposób. ok, po prostu działające) rozwiązanie człowiek znajduje na końcu. Może dlatego, że dalej nie szuka?

Dwa firefoxy w jednym domu stały

22 December, 2006 (01:14) | web, windows | By: vermin

Ostatnio ukazały się nowe wersje przeglądarki Firefox (FF): 1.5.0.9 oraz 2.0.0.1 zawierające poprawki bezpieczeństwa. Co w tym dziwnego? Cóż - obecnie utrzymywane są dwie stabilne linie przeglądarekdla produktu FF. Zastanawiam się czy (i kiedy) linia 1.5.x wygaśnie, tj. sama zaproponuje przejście na linię 2.x (a może już 3.x)? Tak czy siak, popularność firefoxa w wielości odmian wymusza posiadanie dwóch jego wersji (tak jak niestety będąc adminem w sieci z Windows albo web developerem trzeba mieć dwie wersje IE). W wypadku FF taka koegzystencja jest na szczęście osiągan dużo łatwiej. Niestety samo zainstalowanie wersji 1.5 oraz 2 w dwóch odrębnych katalogach to za mało, żeby działały niezależnie - obie pragną odwoływać się do tego samego profilu, co rodzi pewne problemy chociażby z rozszerzeniami, tematami, czy innemi ustawieniami FF które nie muszą być zgodnie pomiędzy tymi dwiema liniami produktu. Jasne staje się, że wymusic musimy działanie FF na dwóch niezaleznych profilach. Niestety sam FF, w przeciwieństwie chociazby do OE, gdzie rozwiązanie profili było zaskakująco często i gęsto używane przez zwykłych użytkowników, nie podaje nam profili wprost w menu. Trzeba uruchomić program z parametrem “-p” (chociażby przez modyfikację skrótu) co pozwoli na uruchomienie okna z wyborem profili. Tworzymy nowy profil dla FF2, nazywając go dla niepoznaki “dwa”. Ponowna modyfikacja linii poleceń tj dodanie parametru “-p dwa” a dla FF1 “-p default” pozwoli już na uruchamianie dwóch przeglądarek nie brudzących sobie w profilach. Niestety niedopracowanie profili w FF, (albo optymalizacja wykorzystania pamięci przez użytkowanie jednej instancji tak samo nazywających się bibliotek) objawia się także tym, że dwie przeglądarki nie potrafią pracować niezależnie, tj. próba uruchomienia FF2 na swoim profilu lub innym gdy działa “1″ spali na panewce. Muszę poszukać, czy jest jakieś rozwiązanie tego problemu. Dopiero ustawienie parametru środowiska MOZ_NO_REMOTE=1 (np. Mój komputer -> Własciwości -> Zaawansowane -> Zmienne środowiskowe lub set MOZ_NO_REMOTE=1 w pliku batch) pozwala na osiągnięcie tego celu (źródło: Mozillazine Knowledge Base)

Swoją drogą - jak radzi sobie Opera?

Bluetooth i natrętne sterowniki generyczne MS

21 December, 2006 (01:53) | gadgets, windows | By: vermin

Miałem kiedyś pecha i włożyłem USB BT dongle (jak to na polski przełożyć?) przed instalacją oprogramowania Widcomm. Oczywiście różnica w wykorzystaniu sprzętu, a dokładniej ról jakie może przyjąć komputer wyposażony w ów gwizdek jest zależna głównie od oprogramowania - oczywiście na generycznym sofcie MS mnóstwo rzeczy nie działa. Niestety próba zainstalowania post factum sterowników widcomm’a nie przynosiła pożądanych rezultatów, (stworzenia z komputera zestawu słuchawkowego z nagrywaniem treści rozmowy), i pomimo drobnego wysiłku (a nuż restarcik, a nuż wyrzucenie standardowego urządzenia bluetooth działającego na sterach MS, a zmiana portu USB, a restart serwisów BT) nie przynosiła rezultatów. Podpisane sterowniki MS rządziły. Rozwiązanie okazało się banalne - wystarczyło w urządzeniu, które się pojawiło (generic bluetooth device) zmienić, po uprzedniej zmianie polityki podpisywania sterowników na ignore, sterowniki na CSR USB BT device. Komputer chwilę pomielił… i nagle znikły standardowe wynalazki MS a pojawiły się w końcu widcommowe cuda. Szkoda tylko, że znikło circa 15 minut bezcennego ostatnio wolnego czasu ;-)

Szybkie płatności internetowe, czyli BZ WBK ssie

18 December, 2006 (23:02) | Prywatne, tyrady, web | By: vermin

W zasadzie lubię ten bank. Mam w nim konto od lat, niezłą historię rachunku, szeroki portfel usług. Znam miłe panie w moim oddziale. Nie wspomnę, że jest to bank poznańsko - wrocławski, więc powinien być zajefajny per se. Niestety ma jedną
“wspaniałą” rzecz, które obsysa po całości. W szczególności jak się porówną ją do konkurencji. Jest to rzecz prawie niepotrzebna użytkownikowi konta. Prawie, bo chodzi o przelewy.
Otóż próba przelania pieniędzy pomiędzy rachunkami (przelew drugiej osobie, spłata karty kredytowej) trwa conajmniej parę godzin. W takim mBanku - kilka sekund. Oczywiście, jeśli chodzi o to, to człowiek jeszcze ten policzek zniesie - ale miara się przelała. Musiałem dokonać szybkiego zakupu (1) oraz doładować konto w panelu zarządzania - ot, pora przedużyć jakąś domenkę (2). Co się dzieje? Cóż - od jakiegoś czasu transakcje wychodzące wykonane przez Przelew24 wiszą, allpay (przez którego to szło) nie potwierdza transakcji, czyli nie wiem, czy uda się dostać zamówienie przed świętami. Mógłbym przelać przez coś innego, ale nie za bardzo mam gdzieś takie środki, bo kwota nie mała dla mnie. Co do (2), to tam poradziłem sobie przez inteligo akurat - które ma swoje wady, niemniej podobnie jak mBank szybko obsługuje płatności internetowe. Jest to moment, kiedy nie szkodzą mi zwielokrotnione płatności - najwyżej kupię sobie jeszcze jakąś domenkę.

Swoją drogą interfejs BZ WBK potrafi być wk.. jak wdrażają coś nowego. W szczególności, jeśli to ma im zaoszczędzić koszty - chociazby darmowe wyciągi papierowe zmienić chcą na tylko elektroniczne. Zamieniają domyślne akcje, żeby wyświetliła się opcja zmiany zamiast historii konta. Ja rozumiem raz, ja rozumiem kilka logowań lub dzień. Ale oni nie znają umiaru i dopiero ostre krzyki klientów wyprostowały sprawę. Swoją drogą ogólnie ich interfejs do inteligo się nie umywa. Ooooh, wie schade…

Tak czy siak, drogie BZ WBK, ssiesz. Poza funduszem Arka nie licz na moje pieniądze, a jeśli tylko znajdę coś lepszego, to i marne pare groszy które tam trzymam pewnie zabiorę. Cóż, jak mówił Marek Kondrat w reklamie innego banku za którym nie przepadam - Banki nie są od tego żeby je lubić. Banki są od tego żeby zarabiały (czy jakoś tak).

Kernel 2.6.17 i ipw2200 razem nie lubią działać

15 December, 2006 (12:08) | amilo, debian(ized), linux | By: vermin

W debianie testing/etch pojawiło się swego czasu jądro systemu w wersji 2.6.17.

Wielkieś mi uczyniła pustki w domu moim,
Moje drogie jądro, tym pojawieniem swoim!

Jądro to automagicznie wyłączyło mi sieć bezprzewodową, generując przy tym tonę komunikatów typu

ipw2200: disagrees about version of symbol ieee80211_wx_get_encodeext
ipw2200: Unknown symbol ieee80211_wx_get_encodeext
ipw2200: disagrees about version of symbol ieee80211_wx_set_encode
ipw2200: Unknown symbol ieee80211_wx_set_encode
ipw2200: disagrees about version of symbol ieee80211_wx_get_encode
ipw2200: Unknown symbol ieee80211_wx_get_encode
ipw2200: disagrees about version of symbol ieee80211_txb_free
(…)
ipw2200: disagrees about version of symbol alloc_ieee80211
ipw2200: Unknown symbol alloc_ieee80211

Ponieważ jednocześnie owe jądro wnosiło sterownik w wersji 1.1.1 należało także zmienić firmware z wersji 2.4 na 3.0. Niestety - pomimo tych zmian sterownik ipw2200 w jądrze nie działał poprawnie z ieee80211. Pozostawało jedynie ściągnąć nowszą wersję sterownika i samemu znów skompilować moduł ipw2200-source lub rekompilować jądro. Co ciekawe, to zachowanie nie występowało w poprzedniej wersji jądra - 2.6.16, gdzie wszystko działało poprawnie.

Na szczęście po ostatnim upgradzie systemu pojawiło się w końcu jądro 2.6.18 z ipw2200 w wersji 1.2.0 oraz ieee80211 w wersji… 1.1.13 (czyli downgrade!). I znów wszystko działa :)

Google Mini

13 December, 2006 (10:00) | bezpieczeństwo, gadgets, web | By: vermin

Dziś dowiedziałem się o istnieniu stworzenia zwanego jak w tytule. Jest to relatywnie ciekawe zwierzę, pozwalające na indeksowanie i przeszukiwanie infrastruktury wewnętrznej przedsiębiorstwa - tej, która niedostępna jest z zewnątrz sieci: serwerów plikowych czy też stron intranetowych. Rozwiązanie ciekawe, szczególnie, że niewielkie (1U) i łatwe w instalacji. Podejrzewam, że relatywnie niedrogie, biorąc pod uwagę, że najmniejsza wersja kosztuje circa 2000$ (i co roku circa 1000$ abo). Dużym plusem jest oczywiście fakt, że ma się fajną wyszukiwarkę i wierzy, że nie wypuszcza ona informacji na zewnątrz.

Co mi się w tym niepodoba? Cóż - brak rozbudowanego interfejsu bezpieczeństwa, brak integracji z jakimś protokołem autoryzacyjnym. Nie pierwszy raz wiadomo, że wynalazki google pozwalają na wyszukiwanie informacji, które nie zawsze powinny trafić do szerokiego spektrum odbiorców. W tym wypadku jest niestety podobnie - google appliance potrafi znaleźć wszystko i wszystko odbiorcy zaserwować. Bez oglądania się na poziom zabezpieczeń, dostępów. Wyszukiwarka jest dostępna każdemu i każdemu zaserwuje zgromadzone informacje :|
Co prawda z dostępnych informacji wynika, że wersje entreprise mają już przyjemną(?) integrację, ale Enter Price version…

Debian 4.0 - ciąg dalszy

12 December, 2006 (10:48) | debian(ized) | By: vermin

Wczoraj rozpoczęła się faza zamrożenia czwartej już edycji Debiana - Etch. W związku z tym można się spodziewać, że niedługo ta właśnie edycja osiągnie fazę stable. Aktualizacja większości popularnych pakietów (server) nie jest szczególnie trudna i prawie obywa się bez problemów, więc tym, którzy chcą wcześniej przesiąść się na tą distro w celu spokojnej aktualizacji już dziś mogą polecić sed -i s/sarge/etch/g /etc/apt/sources.list lub też zmienić stable (co nie wiedzieć czemu pokutuje jeszcze w konfiguracji źródeł apt) na etch właśnie.

Kolejnym krokiem jest wykonanie aktualizacji pakietów (aptitude update) oraz instalacja samego aptitude (aptitude install aptitude). Tą linię warto jednak rozszerzyć o któryś z pakietów linux-image-2.6 (np. linux-image-2.6.18-3-686), ponieważ jest bardzo prawdopodobne, że zostanie nam odinstalowane jajko 2.6.8-3 i zostaniemy zupełnie bez jądra…. Więc wykonanie aptitude install aptitude linux-image-2.6.18-3-686 powoduje, że wszystko jest już ok.

Następnie wykonujemy raz jeszcze aptitude update i w końcu możemy spokojnie wykonać upgrade distro do wersji 4.0 etch (aptitude dist-upgrade). Bez odświeżenia aptitude moglibyśmy to także zrobić, ale byłby problem z niepodpisanymi pakietami…