Różowy blog
Karty graficzne firmy ATI, czyli obecnie AMD, przynajmniej wersje mobilne, montowane w laptopach, posiadają wbudowaną w sterowni funkcję łatwej zmiany prędkości. Jest ona szczególnie przydatna w laptopach, gdzie niekoniecznie przez cały czas potrzebna jest wydajność, za to liczy się możliwość dłuższej pracy na baterii czy po prostu cichszej pracy.
Wczoraj poproszono mnie o zajęcie się problemem pt. "nie działa ć". Nie odmówiłem, mimo, że Windows i Vista (nie znam, ale przecież to taki intuicyjny system) bo coś takiego kiedyś już widziałem (chociaż IIRC o ś chodziło) i sprawa wydawała się prosta - wyłączyć skrót w jakimś programie, żeby nie blokował pl-znaków.
Jak pisałem wcześniej, nowe fglrx (wersja 8.522) powodują problem z iwl3945 intela. No to spieszę donieść, że w 8.532 trochę się poprawiło - działa stablilnie (kilkanaście godzin testu) na 2.6.24.x. Niestety, na 2.6.26.x nadal krzaki, chociaż niby w changelogu jest, że poprawili Compilation issues against Linux kernel 2.6.26.
Mimo, że nie zabalowaliśmy zbytnio pierwszego dnia, wstaliśmy punktualnie i zgodnie z planem, to nie dotarliśmy na pierwszy wykład dnia drugiego (dzień pierwszy tutaj). Plecak kumpla nagle okazał się za mały, mimo, że do Krakowa całkowicie wystarczał... No ale mieliśmy PS2 ze sobą, więc jesteśmy usprawiedliwieni... Koniec końców zmieściliśmy się jakoś (trochę miejsca znalazło się u mnie w plecaku) i ruszyliśmy na wykład. Ale stwierdziliśmy, że 20 minut spóźnienia to przesada i lepiej kawę wypić... Zmieniona została też agenda, ale trzymam się wersji ze strony - kolejność jest mniej istotna.
Tak się złożyło, że w miniony czwartek i piątek w Krakowie odbywała się pierwsza konferencja Polish Network Operators Group. Tak się szczęśliwie złożyło, że miałem okazję w niej uczestniczyć. Poniżej krótkie wrażenia z pierwszego dnia konferencji.
Pierwszy - i moim zdaniem zdecydowanie najlepszy tego dnia, choć dość kontrowersyjny wykład prowadził Randy Bush. Przedstawiane tezy jego "religii" były dość kontrowersyjne i odbiegały mocno od reszty wykładów. Postulował prosty szkielet sieci - żadnych QoS, żadnych MPLS w szkielecie. Core ma być wydajny i oparty o sprzęt, bez cudów software'owych. Sprzęt tanieje (podlega prawu Moora), dotyczy to także fizycznych linków. Producenci sprzętu to wróg - wciskają "wartości dodane" w stylu QoS czy MPLS za co im płacisz (i komplikujesz budowę/konfigurację sieci - podnosząc koszty utrzymania, a w sumie i tak nie wykorzystasz tego w pełni/poprawnie), zamiast inwestować w infrastrukturę (sprzęt). Sieć ma być prosta i zdolna do samonaprawy.
Tradycyjnie serwer WWW równa się apache (lub IIS), ale istnieją też inne rozwiązania. Apache przy domyślnej instalacji ma dwie zalety: działa i łatwo znaleźć pomoc/howto/dokumentację.
Ale istnieją także inne serwery WWW. Przykładem może być lighttpd lighttpd. Z lighttpd korzytają m.in. Wikipedia i YouTube..
Niestety, domyślnie paczka debianowa (Etch, ale pewnie inne wersje też) nie ma wsparcia dla PHP (wrzucimy index.php do /var/www i nie wyświetli strony). Szybka (quick'n'dirty) metoda na uruchomienie obsługi PHP poniżej.
Aby działało PHP5 należy w lighttpd.conf zamieścić linie:
"mod_access",
"mod_alias",
"mod_accesslog",
"mod_fastcgi",
oraz
fastcgi.server = ( ".php" => ((
"bin-path" => "/usr/bin/php5-cgi",
"socket" => "/tmp/php.socket"))
)
oraz zainstalować paczkę php5-cgi.
Nieco lepsze (poprawna obsługa plików, jeśli nie podano rozszerzenia) jest:
fastcgi.server = ( ".php" => (( "bin-path" => "/usr/bin/php4-cgi",
"socket" => "/tmp/php.socket" )),
".phtml" => (( "socket" => "/tmp/php.socket-0" ))
)
Oczywiście da się także korzystać z PHP4. Należy zmienić (zarówno w konfigu, jak i w doinstalowywanej paczce na php4-cgi).
Serwerek jest lekki - z 64 MB RAM, przy uruchomieniu prostej stronki i skrypciku PHP zajął 0.2 do 2% (po wywołaniu strony) dostępnej pamięci. Benchmark lighttpd.
Zaznaczam, że powyższa konfiguracja nie jest przewidziana/testowana do obsługi dużego ruchu i jest mało elegancka - chodziło o samo uruchomienie obsługi PHP. Na pewno bardziej eleganckim i "Debian way" sposobem uaktywnienia mod_cgi jest wykorzystanie /etc/lighttpd/conf-available i /etc/lighttpd/conf-enabled. Liczę na inne uwagi.
Ostatnimi czasy miałem dość 2.6.24.x, więc popełniłem upgrade do 2.6.25.x, a następnie do 2.6.26.x na laptopie. Wiązał się z tym upgrade sterownika karty graficznej fglrx z 8.476 do 8.522 (sterownik bezpośrednio ze strony producenta, paczka utworzona wewnętrznym builderem; numeracja taka, jaka widoczna w utworzonym debie) - starszy nie wspiera nowszych kerneli.
Wszystko pięknie i bez problemu tylko...przestało działać wifi. Konkretniej - działało poprawnie krótszą lub dłuższą chwilę (kilka - kilkadziesiąt minut) i przestawało działać (pomagało przeładowanie modułów i rekonfiguracja sieci, ale nie będę tego robił co kilka minut...).
Widzę gorączkę Google Chrome, ale zachęcam do ostrożności przy testowaniu - w tej chwili na komputerze użytkownika GC bez jego wiedzy może znaleźć się plik - wystarczy spreparowana strona WWW. Źródło i przykład.
Ledwo przeglądarka została wydana, a już pojawiły się pierwsze exploity (PoC w zasadzie). W wersji Google Chrome 0.2.149.27 na Windows XP z SP3 po kliknięciu na specjalnie przygotowany link dochodzi do zawieszenia procesu przeglądarki.
Szczegóły, możliwość testu oraz źródło wiadomości tutaj oraz tutaj.
Swego czasu głośno było o problemach Debiana - kilkanaście(?) miesięcy temu włamanie na serwery, ostatnio dziura w OpenSSL. Żeby nie było, że takie wpadki to przypadłość wyłącznie Debiana - dziś poinformowano o włamaniach na serwery Fedory i Red Hata.
Zwykle do przechowywania danych stosuje się bazy danych - MySQL, PostgreSQL czy - w przypadku, kiedy prędkość/zasoby są kluczowe - SQLite. Czasami jednak nie są potrzebne wszystkie możliwości oferowane przez bazę, a liczy się wyłącznie prędkość i prostota, plus możliwość dostępu do wspólnych danych przez kilka niezależnych procesów czy hostów. W takich przypadkach skorzystać można z memcached. Poniżej krótki opis tego narzędzia.
Firefox czy Opera to dobre przeglądarki. Ale prędzej czy później trafia się sprzęt, który wymaga IE. Tak po prostu. Inne przeglądarki nie działają i już. Wówczas (poza użyciem telnetu) do wyboru mamy następujące rozwiązania:
Zajmiemy się tym ostatnim rozwiązaniem, jako najprostszym.
Na typowym desktopie zwykle niezbędny jest flash, najlepiej ten od Adobe. W Debianie sprawę załatwia instalacja pakietu flashplugin-nonfree, który zajmuje się dostarczeniem flasha. Wszystko działało pięknie i bezbłędnie, aż do wczoraj. Przy okazji porządków w systemie ojca postanowiłem dokonać aktualizacji flasha i... pojawiły się problemy. Przy okazji przyjrzałem się bliżej narzędziom i znalazłem parę "śmiesznostek/żałostek".
Patrzę na to, co się dzieje po ogłoszeniu błędu ze słabymi kluczami i jestem przerażony. Próbkę mam znikomą, ale generalnie administratorzy nie przejmują się błędem zupełnie - albo robią upgrade samej paczki (w przypadku Debiana upgrade openssh jest o tyle dobry, że automatycznie wykrywa znane słabe klucze serwera), co nie rozwiązuje problemu, bo słabe klucze już są wygenerowane, albo czekają (nie wiem na co...). A tymczasem konsekwencje dotyczą nie tylko Debiana, ale i innych systemów z dostępem przez SSH, a liczba kluczy, które były generowane na dotkniętych błędem systemach Debiana to tylko 32767[1] dla każdej długości klucza (dla lepszego zobrazowania - trzyliterowe hasło składające się z samych liter daje podobne zabezpieczenie), a hasło na klucz niczego nie zmienia (bo wersja niezabezpieczona zawiera się w tych 32 tysiącach).
Problem nie dotyczy tylko Debiana, ale wszystkich systemów, na których użytkownicy Debiana mogli ustawić słaby klucz jako zaufany. No i tu pora na narzekanie - żaden administrator systemu (brak jakichkolwiek restrykcji w dostępie via SSH) na których dodałem swój słaby klucz nie zareagował - usunąłem klucze samodzielnie. Ilu użytkowników jeszcze dodało tam słabe klucze - nie wiem. Wiem, że aktualnie w Debianie pojawiło się narzędzie ssh-vulnkey, które po wywołaniu ssh-vulnkey -a sprawdza wszystkie standardowe lokalizacje (także authorized_keys użytkowników) w poszukiwaniu słabych kluczy - zachęcam do skorzystania z niego i przeportowania na inne systemy.
Tak czy inaczej wygląda na to, że ogólnie poziom bezpieczeństwa w IT drastycznie spadnie. Niebawem będzie w użyciu masa skompromitowanych systemów, słabych certyfikatów itd., a ten problem dotyczy nie tylko administratorów, ale wszystkich użytkowników komputerów.
[1] źródło
Okazuje się, że działania developera Debiana były słuszne - przeanalizował kod, odkrył wykorzystanie niezainicjalizowanych obszarów pamięci jako źródła losowych danych (nie są/nie muszą być losowe), chciał to naprawić. W tym celu skontaktował się z developerami OpenSSL, potwierdzili oni błąd i sposób naprawy. Rzecz w tym, że uzgadniał zmianę w jednej funkcji, a tymczasem poprawił podobny kod w dwóch funkcjach. I teraz powstaje dylemat: czy faktycznie popełnił błąd źle oceniając działanie drugiej funkcji, czy może jednak w OpenSSL, w wersji oryginalnej, nadal w jednym z miejsc polega się na niezainicjalizowanej pamięci jako źródle losowych danych (co jest lepszą metodą, niż to, co wprowadził, ale nadal dalekie jest od ideału)? Mam przeczucie, że czeka nas niebawem jeszcze jedna wymiana kluczy, tym razem na wszystkich systemach...
