vermin.eu.org

Jestem sobie po urlopie. Relax, luz (bo sprawy pokończyłem w większości przed wyjazdem - więc nic nowego się jeszcze specjalnego nie uzbierało). Dodatkowo odświeżona stacja robocza - koledzy z helpdeska przeinstalowali system. Ok - może luz nie w pełni, bo wieczorkiem chciałem dostać się na stację przejrzeć trochę logi. VPN zestawiony, remote desktop się włącza… i pupa. Stacja pinga, fw na pewno nie blokuje - bo GPO narzuciło odpowiedni profil domenowy a tu nic.

Na szczęście sprawa jest banalna:
1. Uruchamiamy regedit,
2. Podłączamy się zdalnie do komputera.
3. Wchodzimy do klucza HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server
4. I zmieniamy wartość fDenyTSConnection na 0.
5. W ten sposób zdalnie włączyliśmy zdalny pulpit.

Podczas troubleshootingu (jak to by było po polsku? ;-)) łączności z siecią trzeba było wykonać test blackhole routers - czyli routerków, które nie puszczają pakietów o okreslonej wielkości przez sieć. Ponieważ polecenia ping i komunikaty z systemów Windows i Linux mocno się różnią, gwoli przypomnienia dorzucę (opierając się na IPku WP.pl):

To polecenie nakazuje nie fragmentować pakietów i ustawia ich realnąwielkość na 1500 - czylitypową dla pakietów ethernet. Jeśli w linuksie nie dostaniemy żadnej informacji, a w Windows Pakiet musi być podzielony na fragmenty, ale ustawiono opcję DF, to oznacza, że niestety, po drodze coś nie bangla.

Jak sobie z tym poradzić? Dla systemów rodem z Redmond polecam odpowiedni artykuł z KB, zaś dla linuksa wystarczy polecenie: ifconfig i odpowiednie MTU

SBS lubi być sam. Sam możnowładnie pełnić rolę pana i władcy. Nie lubi, kiedy cokolwiek mu przeszkadza. Ba, wyjątkowo źle reaguje jak coś mu przeszkadza, zazwyczaj to wyłączając. Niestety nie odłącza zewnętrznego urządzenia (może Centro/MBE dzięki NAP będzie to potrafić?), a wyłącza swoje funkcjanolności, w skrajnej sytuacji wyłączając sam siebie. Jak się okazuje, można zabronić mu wyłączania serwera DHCP w momencie gdy wróg pojawi się w naszej sieci (albo testowo włączymy routerek, odpalimy serwerek linuksowy nie rekonfigurując portów VMa czy cokolwiek innego). Okazuje się, że można przestrzec się przed tak trywialnym problemem w wyniku którego nagle przestaje działać nam sieć. Wystarczy uruchomić edytor rejestru, przejść od klucza HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dhcpserver\Parameters a następnie dodać w nim wartość typu DWORD o nazwie DisableRogueDetection i wartości 1. Restart serwera (hahaha) i voila - działa.
Oczywistym minusem tego rozwiązania jest fakt, że jak wyłączymy wyłączanie serwisu DHCP w sieci, to otwieramy się na swoisty wektor ataku, polegający na tym, że wstawia się wrogi serwer dhcp do sieci, on ustawie siebie jako proxy i przechwytuje ruch do sieci. Niemniej oczywiście mamy wdrożonego IPSec’a i nie musimy obawiać się takich prozaicznych ataków. Prawda?

Komputeryzacja kiedyś, to rozsiane w różnych miejscach monitor i (dosyć specyficzna) klawiatura. Gdzieniegdzie drukarka, “ukryty” mainframe czy też koncentrator terminali. Stoją u mnie takie pudełka rozsiane po terenie. Stoją i się kurzą, bo już od dawna nikt na terminalach nie pracuje. I tu właśnie powstaje pytanie - dobrze-li to?
Problemu nie było kiedyś - nie było komputerów osobistych, więc terminal był jedyną opcją pracy z systemem komputerowym. Następnie pojawiły się komputery osobiste, których moc wciąż rośnie a cena maleje i na nie przerzucono część obliczeń. Po co więc roztrząsać temat terminali?

Na pewno przydają się one tam, gdzie aplikacja z różnych względów powinna być zainstalowana na jakimś jednym serwerze. Powodem może być chociażby zabezpieczenie sprzętowe czy też konkretna aplikacja, która z jakiegoś powodu nie ma interfejsu zbudowanego w oparciu o lekki model trójwarstwowy typu Oracle Forms czy SAP GUI. No dobra - to dość specyficzne rozwiązania, więc czy jest sens wogóle zajmować się tą tematyką? Można by pomyśleć, że taki specyficzny bezdyskowy terminal z Windows Embedded będzie tańszy niż komputer typu “składak-PC” z renomowanej stajni “Wójek Juzeg - Komputery i Myjnia samochodowa” czy inny tani DELL. Niestety tak nie jest - otóż taka prosta maszynka jest tańsza niż bezdyskowy terminal. No więc dlaczego to się wciąż produkuje?

Dla mnie jedyną przemawiającą za tym rozwiązaniem cechą jest uproszczenie administracji. Rozrzucamy takie małe komputerki po firmie. Małe to i ciche, wydajność niewielka, bo w końcu a tylko włączyć środowisko graficzne, zestawić połączenie z siecią i już. Administracja to betka - pojawiają się nowe, wpływające na tą rzadką ilość obsługiwanych komponentów na WXPE poprawki - tworzymy nowy obraz systemu, rozsyłamy po stacjach i już. Aktualizacja oprogramowania w firmie zrobiona. Inny soft? Wystarczy przecież zaktualizować to co jest na serwerach i nasze klienty terminalowe/citrixowe już mają najświeższe wersje dostępne pod przyciekiem myszy. Cud administracyjny - użytkownicy nie mogą popsuć komputera. Jak coś im nie działa… to podsyła się serwisanta z zapasowym pudełkiem, minuta roboty i już pracujemy ponownie.

Tyle, że pojawiły się kolejne koszty, których nie widać wprost.
Po pierwsze - musimy wydać więcej na serwer. Więcej ramu, więcej procesora. Dyski w końcu i tak mamy na macierzach, więc koszt dodania kolejnych napędów jest znikomy (w porównaniu do ceny macierzy ).
Secundo - licencje dostępowe. Każdy dostęp do serwera Windows zżera nam kolejne licencje - jedną z dostępowych do serwera terminali… i jeśli nie łączymy się z systemu, który ma CAL wbudowany (XP/Vista Business lub Enterprise) to na dodatek alokuje się na to połączenie licencja na używanie systemu Windows Server. Nie mówię nawet o citrixach, które wszak też nie są darmowe.
Tertio - spróbujcie pracować w ten sposób z jakąś zasobożerną aplikacją…

Reasumując - dla terminali na Windows jestem na nie. Dla terminali linuxowych - noo, tu już jest ciut inna śpiewka, bo koszty są dużo niższe. Gdybym miał firmę w całości przestawioną na linuxy to może by to miało sens, ale nie wcześniej. Chyba, że jest tu gdzieś drugie dno, które pominąłem?

Dziennik Internautów zamieścił artykuł, że istotnym wzrostem bezpieczeństwa zapobiegającym phishingowi byłoby stworzenie specjalnych domen .safe oraz .bank.

Pytanie, czy nazwa domeny coś znaczy? Czy nadal domeny .com to tylko rzeczy komercyjne, czy .org to tylko organizacje, czemu nie powstały domeny XXX? Pytanie jest czysto retoryczne. Teoretycznie domenę .us powinny posiadać jedynie podmioty fizycznie znajdujące się na rynku amerykańskim (chyba nawet dość fizycznie) a tak naprawdę nie ma z tym większego problemu. Jeśli wprowadzimy koncesjonowanie tych domen (np. tylko dla zarejestrowanych podmiotów) to wprowadzimy dużo większe problemy - brak konkurencji.

Po pierwsze trzeba by określić międzynarodowe standardy czym taka instytucja jest i jakimi dokumentami powinna się charakteryzować. Nawet jeśli to zrobimy… to ja i tak nie wierzyłbym papierom pochodzącym chociażby z Nigerii…
Po drugie - zdobycie pożądanych dokumentów rodzi problemy natury finansowej - one zazwyczaj nie mało kosztują. Jeśli tego nie zrobimy a użytkownicy zostaną wyedukowani to przecież nikt nie będzie korzystał z usług sklepów który się nie zautoryzuje w safe, co zdecydowanie podniesie koszty obsługi (monopolizacja rynku).
Po trzecie załóżmy, że jakieś podmioty w jakimś kraju nazywają się podobnie - to kto powinien mieć domenę safe? Jeśli powiemy, że to zależy od kraju, to po co wprowadzać domeny TLD .safe a nie safe.<ISO_County_Code>?
I te trzy punkty chyba nie wyczerpują do końca tematu…

Po czwarte (dla mnie najciekawsze) - otwieramy nowy wektor ataku, który może spowodować paraliż internetu. Już teraz nie aż tak rzadkie są problemy z serwerami DNS, które wydają się najsłabszym elementem internetowej układanki. Jeśli wprowadzilibyśmy prawie automatyczne ufanie nazwie domeny, to ataki na różnego rodzaju lokalne resolvery, serwery odpowiedzialne za obsługę domen, DNS poisoning etc. wzrosną niepomiernie. A przecież wystarczy zrobić dobrego DDOSa na najpopularniejsze NSy, żeby połowa ludzi miała poważne problemy z dostępem do internetu (NSy głównych operatorów telekomunikacyjnych, TLD, główne bazy krajowe).

To wcale nie wydaje się takie niewykonalne - na razie po prostu jest to nieopłacalne (bo można taniej osiągnąć odpowiedni poziom phishingu), ale jak uczy nas ekonomia, jeśli zasoby stają się ograniczone, to wzrasta akceptowalny poziom kosztów, które dla osiągnięcia rezultatu gotowi jesteśmy ponieść. A że przypadkowymi ofiarami może być całkiem spore grono użytkowników Internetu? Cóż - collateral damage…

WSS podał odnośnik do artykułu na Performance Blog i opatrzył go tytułem “Pliki PST w sieci to zły pomysł“. Cóż - ja mam przeciwne zdanie, które postaram się tu (bo gdzie?) przedstawić.

Po pierwsze warto sobie zdać sprawę kiedy i dlaczego używa się sieciowych plików PST. Sam plik PST przechowuje dane (głównie pocztowe) użytkownika. Jest to plik skomplikowany w swej strukturze plik, który bardzo lubi nabierać wielkości. Wyobraźmy sobie teraz małą sieć w firmie. Zazwyczaj użytkownicy korzystają ze swojego komputera, niemniej czasem zdarza im się przesiąść na cudzy komputer i potrzebują tam swoich danych. Na szczęście wprowadziliśmy małą domenę NT (dowolna platforma) i mamy roaming profiles, więc dane użytkownika wędrują zanim… oprócz danych Microsoft Outlook, który jest umieszczony w %USERPROFILE%\Ustawienia lokalne\Dane aplikacji\Microsoft\Outlook. Ponieważ są to ustawienia lokalne to plik ten niestety się nie przerzuca na serwer, więc podłączając się do nowej stacji nie mamy do niego dostępu.

Wykonujemy drugi krok, przerzucamy plik do lokalizacji, która się synchronizuje… I to jest największy błąd, bo ładowanie/zamykanie profilu trwa wieki ze względu na konieczność synchronizacji danych. Żeby się tego pozbyć wrzucamy pliki do udziału sieciowego, konfigurujemy na nim uprawnienia, przekonfigurowujemy outlooka odnośnie umiejscowienia jego pliku magazynowego i voila. Działa. Działa szybko i sprawnie - poczta dostępna z każdego komputera, w jednej lokacji. Dzięki temu łatwo je zbackupować… ale nie tylko! Możemy się do tych plików podłączyć i przeprowadzić ich defragmentację, archiwizację czy też inną operację administracyjną o jakiej sobie pomyślimy.

Ok, dlaczego wobec tego takie halo? Otóż faktycznie, jeśli te pliki są duże, jeśli nasza sieć jest rozbudowana tak, że mogą pojawić się poważne przekłamania podczas transmisji i przede wszystkim - jeśli takich użytkowników jest dużo to faktycznie - tylko serwer Exchange. Ale pojmowanie małej sieci w wersji amerykańskiej (nawet nie 200 stacji z przykładu ale chociażby 50) a polskiej (10 stacji) to jednak jest różnica. Jeśli kogoś stać na tyle licencji (i administratora do tego) to wydatek na Exchange nie powinien być dla niego aż takim obciążeniem (że o SBS nie wspomnę)…
Niemniej jesteśmy na rynku polskim - i tu w małej sieci pliki PST na zdalnym udziale oraz administrator, który wie jak nimi zarządzać to wszystko co firmie jest potrzebne. Szczególnie jak jest do tego AD i firmowa książka adresowa to Exchange jest wręcz zbytkiem (chociaż to naprawdę kawał fajnego produktu jest). A że jest to niewspierane przez MS? Cóż - przecież tego Exchange trzeba ludziom sprzedać

Wyobraź sobie urządzenie, która ma ileś tam czujników - np. kaloryfer z termoregulacją. Masz odczyt temperatury (wartość1) i pokrętło (wartość2). Chcielibyśmy (jeśli kaloryfer to umożliwia) pobierać i monitorować urządzeniem zewnętrznym wartość tej temperatury (wartość1), a także ustawienie pokrętła (wartość2). Jak to zrobić (w dziedzinie komputerów)?

Monitorowanie sprzętu jest ważne - na przykład dlatego, że pozwala wykryć sytuacje prowadzące do nieodpowiednich zachowań. Zaczynając od tak banalnych rzeczy jak wysycenie pewnych parametrów (np. mierzenie poziomu zajętości dysku, badanie obciążenia procesora, stronicowanie pamięci i inne wąskie gardła), do zagadnień bezpieczeństwa (tu dla odmiany monitorowania bramki internetowej, co pozwoli nam stwierdzić, czy ktoś przypadkiem nie wykorzystuje naszego łącza pomimo (braku) zabezpieczeń w czasie teoretycznego braku aktywności). Monitorować można na wiele różnych sposobów, niemniej warto zainteresować się jednym z nich, dostępnym zarówno w systemach Windows i Linux - a przede wszystkim w dużej ilości urządzeń zewnętrznych (w szczególności sieciowych).

Do monitorowania wykorzystuje się protokół SNMP. Ten prosty protokół jest szeroko rozpowszechniony i doczekał się już swojej trzeciej wersji. Niemniej ponieważ w użyciu są przede wszystkim wersje 1 i 2, skupimy się na nich - żeby to zaczęło działać.

Do podstawowego działania każde monitorowane urządzenie powinno mieć program (agenta), który będzie pobierał stan jakiegoś wewnętrznego rejestru (np. przepływność interfejsu sieciowego) a następnie, odpytany przez zarządcę, podawał mu te dane. Agent może być także ciut proaktywny i w wypadku zadziałania zdefiniowanego warunku wysyłać do zarządcy odpowiednią informację (zwaną trap/pułapką). Do poprawnego działania w środowisku sieciowym potrzebne będą porty TCP 161 (odpytywanie) i 162 (pułapki). Przyda się jeszcze tzw. community name, czyli nazwa o którą będziemy odpytywać nasze urządzenie.

Na boku: Widać tu wyraźnie, że skoro jedynym zabezpieczeniem jest znajomość community name musimy przedsięwziąć inne środki bezpieczeństwa… lub wdrożyć wersję 3 protokołu SNMP.

OK - tyle teorii wystarczy. Jak to wszystko zrobić nie dopłacając? O tym w następnym artykule.

Cóż - aktualizacja systemu, szczególnie, do jakby nie było jeszcze wersji testowej, powoduje pewne problemy. W tym wypadku niestety posiadanie karty działającej ze sterownikiem sundance 1.1 z jajka 2.6.18 w wypadku zainstalowania snmpd, który z automatu odpytuje to urządzenie co 30 sekund powoduje zrzut czegoś w formacie

i to dla każdej z aktywnych kart składających się na to urządzenie.

Podejrzewam, ponieważ nie towarzyszą temu żadne komunikaty o wyłączaniu komunikacji, oopsy kernela, czy inne dziwne teksty (%s: Something Wicked happened! %4.4x.), że są to informacje typu debug, które zostały wkompilowane w kernel. Niestety serwer jest zdalny i nie za bardzo mogę wyłączyć tą sieciówkę, przez którą idzie m.in. cała komunikacja ze światem zewnętrznym… a pewnie wystarczy zmiana parametrów przy ładowaniu tego modułu Cóż, będzie go trzeba w wolnej chwili przeładować albo czekać, że wraz z wersją 2.6.19 pojawi się w Debianie sterownik w wersji 1.2 (i wtedy przeładujemy system…)

[l8r that day] Po przejrzeniu kodu i stron…

Swoją drogą ciekawe jest, że RH podaje, że ten moduł nie przyjmuje żadnych parametrów, a w źródle można znaleźć takie coś:

co zresztą pokazuje modinfo. Dalsze śledztwo pokazało też, że za całe zamieszanie odpowiedzialna jest procedura netdev_ioctl, która ot tak sobie wypluwa te wszystkie informacje, przy debug=0. Raczej przyjdzie ręcznie wywalić ten kod z modułu…

Istnieje w sieci komputer o nazwie netbios “23″. Niby nic takiego, ale… próba połączenia się z nim jednego z komputerów poprzez otoczenie sieciowe generuje w logach IPSa dziwne zdarzenie: “martian destination 0.0.0.23 from 192.168.10.141″. Co ciekawe znajduje się także właściwy adres IP i komputer rozpoczynający połączenie w końcu się połączy… ale zastanawia mnie, czy nadanie jako nazwy komputera adresu IP w postaci DWORD a na tym właśnie adresie otworzenie udziału nie spowodowałoby de facto przekierowania zapytania pierwotnego na tą drugą (DWORD) maszynę?

Mojemu kochanemu operatorowi przypomniało się w końcu, że wprowadzając HSDPA, (czyli w skrócie - rozszerzenie pozwalające zamiast z maksymalną prędkością EDGE wynoszącą 384 kbit/s łączyć się z zawrotną prędkością 1,8 Mbit/s) ma pewną, niemałą, grupę klientów, którzy zakupili modemy option. Możliwość aktualizacji firmware tych modemów na stronach producenta pojawiła się już dawno, niemniej, ponieważ większość urządzeń sprzedawanych w PL sprzedawana jest przez sieci komórkowe, wprowadzają one swoje zmiany/ograniczenia do firmware w ten sposób czyniąc generyczną aktualizację oprogramowania niemożliwą.
Konkurencji, tj. PTC oraz Orange już dawno udostępniły zmienioną przez siebie nową wersję oprogramowania umożliwiającą łączenie się z zawrotnymi prędkościami - nawet wtedy, kiedy usługi teoretycznie nie było… Niestety PlusGSM zapomniał o swoich klientach i nawet listując na stronie iPlus modemy i wypisując które z nich będą mogły obsługiwać HSDPA, słowem nie wspomniał, że sprzedawane wcześniej przez niego urządzenia też mają taką opcję. OK - może nie wiedzieli?
Nie ważne - ważne, że spod adresu http://www.iplus.pl/download/iplus_flasher_hsdpa_for_option.exe można ściągnąć plik EXE który dokona aktulizacji firmware w naszym modemie o ile, (w wypadku PCMCIA), będziemy korzystać z zasilacza a nie z baterii oraz wyciągniemy kartę SIM (chociaż tego drugiego nie zrobiłem i U MNIE działało). No a teraz… prędkość połączenie 1,8 już się wesoło świeci w trayu