Rootnode planet
Planeta to miejsce, w którym agregujemy wpisy z najciekawszych blogów znajdujących się na Rootnode. Jeśli myślisz, że twój blog powinien się tutaj znaleźć poinformuj nas o nim. Bardzo mile widziane blogi techniczne i specjalistyczne.

Dnia 15.03.2010

Niebezpieczni w służbie bezpieczeństwa?

W

łamywacze o bardzo nieokreślonych intencjach są często bardzo pożyteczni z punktu widzenia biznesu, niektórych światowych firm. Wykorzystywanie ich do testowania systemów stało się powszechnym zjawiskiem. Najzabawniejsze jest to, że staje się to praktycznie bez ich wiedzy. W systemie, który ma zostać sprawdzony oraz spenetrowany umieszcza się mechanizmy zabezpieczeń, które mają zostać poddane próbą, stwarza się określone warunki izolujące taki system w celu niwelacji zagrożenia na szerszą skalę, a zarazem zainstalowany monitoring takiego systemu dostarcza pełnych informacji, o poczynaniach intruza. W ten sposób obserwacja sposobów i skuteczności penetracji pozwala na wykrycie niedoskonałości, wprowadzanie poprawek, kolejnych zabezpieczeń, a nawet przeprojektowanie systemu. Jest to swego rodzaju forma zbliżona do otwierania systemów o zamkniętych kodach źródłowych w celu ich szybszego usprawnienia.

     Któż by potrafił lepiej przełamać zabezpieczenia naszej sieci komputerowej niż ktoś, kto na, co dzień zajmuje się ich łamaniem? Oczywiście można zatrudnić specjalistów od zabezpieczeń, ale ekonomicznym problemem w tym przypadku jest to, że trzeba im odpowiednio dużo zapłacić. Sprowadzenie testów systemów do kategorii ekstremalnie pospolitych włamań niesie z sobą inne zalety. Warunki panujące podczas takiego zajścia są stuprocentowo naturalne do tych, które codziennie występują w różnych niepożądanych częściach rozległych sieci komputerowych przyprawiając o zawrót głowy niczego niespodziewających się administratorów, co oddziela typowe warunki laboratoryjne od dżungli panującej na zewnątrz. Światowa prasa od czasu do czasu karmi nas informacjami na temat kolejnych prób włamań się do sieci komputerowych uchodzących za najbardziej zabezpieczone (Pendaton, NASA, MIT, Banki, Firmy z Fortune 100 itp.). Dzięki brakowi, w tym wszystkim elementów fantastycznych takie eskapady potrafią udowodnić, że na informatycznych eksploratorów nie ma mocnych, co dodaje przeprowadzanym próbą w pełni profesjonalny wymiar i najwyższy standard wykrywania podatności praktycznie za darmo. Większość firm wydaje miliony na walkę z wyrafinowanymi zagrożeniami informatycznymi, bacznie zwracając uwagę na elementarne zasady bezpieczeństwa. Inni nie ograniczają się tylko do korzystania z rozwiązań proponowanych przez specjalistyczne firmy i tworzą własne oddziały badawcze, w ten sposób mogąc bronić siebie i przy okazji oferować swoje usługi innym. Im więcej źródeł wystawianych jest na publiczny dostęp, tym więcej informacji można zebrać na temat używanych metod oraz wprowadzanych nowości w obchodzeniu zabezpieczeń.

     Inną stosowaną polityką, która nie wymusza czekania, aż ktoś zapuka do naszego bezpiecznego wielkiego brata jest po prostu ogłaszanie różnego rodzaju konkursów, które poprzez oferowanie atrakcyjnych wynagrodzeń lub nawet obietnic posad pracy mają masowo przyciągać wszystkich zainteresowanych tematyką bezpieczeństwa komputerowego. Dzięki takiemu współzawodnictwu każdy stara się jak najlepiej wykazać swoimi umiejętnościami w zastosowaniu metod weryfikacji stanu bezpieczeństwa danej platformy systemowej, czy znajomości strategii zabezpieczeń sieci komputerowych. Uczestnicy stają w konfrontacji z realnym, ale także specjalnie przygotowanym i zabezpieczonym obiektem, który ma zmusić ich do kreatywnego rozpracowywania systemu i jednocześnie obnażyć ich wypracowane przez lata chwyty, na które oczywiście po fakcie opracowywana jest odpowiednia szczepionka.

     Podczas, gdy jedni przyjmują za punkt honoru pokonywanie barier i zabezpieczeń strzegących informacji, zawartych w komputerowych bazach danych lub przesyłanych w żyłach sieci teleinformatycznych, inni głowią się nad projektowaniem nowszych i skuteczniejszych metod chroniących te dane. Choć bezpieczeństwo systemów informatycznych jest złożonym zagadnieniem, które obejmuje zarówno warstwę technologiczną, formalną i ludzką – to poprzez nieustanną walkę oba te gatunki w cybernetycznym środowisku uzupełniają się wzajemnie z dnia na dzień tworząc doskonalsze formy i kształty w bezpieczeństwie sektora IT. Coraz nowsze rozwiązania poddawane są coraz nowszym obejściom wzajemnie na siebie wpływając – pomagają stworzyć proaktywną i dynamicznie rozwojową naturę, w której bezpieczeństwo jest wynikiem doświadczeń i wyprzedzaniem negatywnych zdarzeń, które moją zaistnieć w przyszłości, a nie reakcją na już zaistniałe incydenty.

Felieton ten pochodzi z magazynu: Linux+ Nr 2 (118) Luty 2007.

Dnia 14.03.2010

Rootkity ACPI

R

ootkity od zawsze były zmorą administratorów sieci. Jednak wraz z rozwojem technologii ukrywania złośliwego kodu w systemie, rozwijały się także narzędzia, które go wykrywały. Przed ich twórcami stanęło teraz nowe zadanie: rootkity, które ukrywają się w BIOSie, znane pod nazwą rootkitów ACPI.

Artykuł ten został opublikowany w numerze 06/2008 (38) magazynu hakin9.

Artykuł w formacie PDF

Dnia 07.03.2010

Niezdrowe trendy w bezpieczeństwie – full disclosure

J

ak w każdym zjawisku zachodzącym na masową skalę, tak i w bezpieczeństwie technologii informatycznych z socjologicznego punktu widzenia można wyróżnić pojawiające się lub zanikające trendy, które w określonym czasie cieszą się większym bądź mniejszym zainteresowaniem. Te bardziej znaczące i rewolucyjne potrafią zmienić dotychczasowe paradygmaty (w tym znaczeniu – wzorcowe przykłady tworzone na podstawie historii rozwoju zabezpieczeń) w sektorze security.

     Anomalią towarzyszącą w tworzeniu pewnych kanonów postępowania w sferze bezpieczeństwa systemów czy ogólnie oprogramowania jest fakt, że zazwyczaj powstające trendy nigdy nie rozwijają się dokładnie w tym kierunku, w którym na początku przewidywali ich twórcy. Gruntownym tutaj przykładem z poziomu antropologii pokazującym esencję powyższych stwierdzeń jest tzw. trend sekularny (zachodzący pod wpływem rozwoju cywilizacji) hackingu, który jest nierozłączną częścią bezpieczeństwa IT, a nawet jego fundamentem. Ukazuje on z perspektywy historycznej główną wadę poglądu full disclosure (pełne ujawnienie błędów), którego głównym założeniem jest podanie do opinii publicznej wszystkich informacji dotyczących odkrytych błędów w zabezpieczeniach informatycznych, włączając w to wszelkie dane techniczne oraz narzędzia (exploity), które wykorzystują te błędy i pozwalają na ich dokładną analizę.

     Termin hacking w pierwotnym znaczeniu wcześnie tworzonego żargonu informatycznego był międzynarodowym określeniem czynności, które pokonują wszelkie zabezpieczenia w postaci kodów i haseł zastrzeżonych dla osób wtajemniczonych pozwalając włamać się do sieci komputerowych. Był to pierwszy trend wśród użytkowników wykorzystujących ogólnodostępne źródła informacji w Internecie. W tamtych czasach odpowiedniki dzisiejszych for – BBSy (biuletyny komputerowe) roiły się od praktycznych porad i wskazówek dosłownie ukazujących krok po kroku słabości ówczesnych systemów. W dodatku na rynku wydawniczym królowała pozycja Hacker’s Handbook Hugo Cornwalla stanowiąca główny poradnik początkujących włamywaczy. Wszystko to spowodowało obranie złej drogi przez panującą modę i metodę prezentacji informacji, wymykając się spod kontroli jej autorów – ktokolwiek ubogi umysłowo technologicznie, czy nie mający większego pojęcia o technice komputerowej – był w stanie opanować parę chwytów, zdobyć adresy, kody, hasła i dostać się do baz danych i systemów państwowych. Wówczas poświęcono wiele konferencji, aby ukształtować finalną etykę hackerów oraz stworzyć prawdziwe podziemie w Sieci dostępne tylko dla wąskiej grupy specjalistów. Głównym czynnikiem, który wpłynął na rewolucje było prawo, które w przeszłości bardzo powolnie podążało za problemami pojawiającymi się w wraz z rozpowszechnianiem się technik przestępstw komputerowych. To wraz z jego reinterpretacją oraz stworzeniem nowych przepisów nastąpiła także akceleracja rozwoju świadomości samozachowawczej osób dyktujących warunki bezpieczeństwa Internetu. Można było wtedy wyraźnie zaobserwować odłączenie się grup guru od przeciętnych skrypciaków (ang. script kiddie), co zakończyło erę bezlitosnych nadużyć informacji przeznaczonych dla osób z branży. I oto bez podłoża genetycznego nastąpiła zmiana przystosowawcza do panujących warunków wśród hackerów, którzy stali się wartościowymi osobami posługującymi się szeroką gamą języków programowania, potrafiących porozumiewać się z wieloma odmianami systemów obsługujących sieci i posiadających dość inwencji, by udoskonalać nowe i już istniejące mechanizmy zabezpieczeń, a co najważniejsze – o wykrytych lukach powiadamiali pierw producentów oprogramowania.

     Historia, która lubi się powtarzać – ukazuje, że wraz z ciągłym rozwojem technologii internetowych zwiększa się prawdopodobieństwo naruszenia bezpieczeństwa już istniejących zabezpieczeń. Każda nowa technika ataku, narzędzie, czy technologia sprzętowa daje nowe możliwości w starych warunkach, a jeszcze większa rola wiarygodnych źródeł informacji pogłębia to zjawisko. Ostatnio szczególnie jest to widoczne w bezpieczeństwie serwerów rządowych, które są masowo testowane przez niezależne serwisy zajmujące się tematyką bezpieczeństwa. W wielu przypadkach niski poziom bezpieczeństwa polega na ignorancji. Wśród administratorów tych systemów panuje przekonanie, wynikające z braku wiedzy i pewności, że do ich systemu nie można się włamać. Zatrudniani są przeciętni fachowcy, którzy nie są zbytnio zainteresowani obsługiwanym przez nich systemem. Znudzeni nie reagują na zgłoszenia osób z zewnątrz, a swoją pracę wykonują jedynie dla pieniędzy. O ile początkowa wina leży po stronie celów audytów informatycznych, tak wiele razy serwisy powiadamiające o tych zaniedbaniach, zbyt szybko ujawniają krytyczne informacje powodując automatycznie dodatkowe ataki na te serwery. Błędem jest tutaj zmiana kolejności etapów wtajemniczenia osób postronnych. W celu uzyskania wyraźnego rozgłosu podaje się pierw do informacji publicznej zaistniałe fakty, a dopiero potem powiadamia się o nich samych zainteresowanych czekając na ich oświadczenia. Pozostawia to lukę czasową pozwalającą na działanie osób o nie w pełni sprecyzowanych zamiarach, które dodatkowo wyposażone są w techniczne szczegóły ujawniane często także, przez samych testerów mających na względzie błędnie rozumowane dobro publiczne.

     Analogiczna sytuacja ma miejsce w przypadku wypuszczania przez programistów exploitów typu 0-day (zerowego dnia) oraz proof of concept (dowodów na poprawność). Kod takich exploitów publikowany jest w bardzo, krótkim czasie po oficjalnym lub nie, ogłoszeniu istnienia określonej podatności w systemie czy programie, lecz zanim producent / autor oprogramowania wypuści poprawkę naprawiającą ów błąd. Dopóki tego nie zrobi wszyscy użytkownicy korzystający z danej marki pozostają w realnym zagrożeniu. Kontrastem dla tej sytuacji może być fakt wypuszczenia przez niezależnego programistę poprawki. Problemem w tym przypadku jest także złe wykorzystanie informacji. Bardzo wiele razy podaje się od razu dane dotyczące możliwości szybkiej aktualizacji, bez jakiegokolwiek przewidywania możliwości technicznych. W ten sposób na serwerze udostępniającym stronę programisty wykonywany jest nieświadomy atak DDoS (ang. Distributed Denial of Service) przez rzucających się jednocześnie na łatę użytkowników. W dodatku istnieje także obawa, że nieoficjalna poprawka może wprowadzać niepożądane zmiany w systemie.

     Wymienione powyżej przypadki noszą znamiona metody pełnego ujawniania, która umożliwia poznanie pełnej specyfikacji wykrywanych luk. Odkrywa ona szczegóły dotyczące konfiguracji oraz jakości stosowanego oprogramowania, ale także trafia do zbyt szerokiego grona użytkowników, którzy nie zawsze pozyskane informacje wykorzystują w odpowiedni sposób. Mimo to, że zmusza ona dostawców oprogramowania by tworzyli kod o najwyższej jakości, w celu uniknięcia publicznej kompromitacji – często wykorzystywana jest do praktyk brudnego marketingu, aby pomóc zainteresowanym osobom w doborze konkurencyjnego produktu – nie zawsze bardziej bezpiecznego. Zwykli użytkownicy nie będący programistami mogącymi samemu dokonać poprawek zostają skazani na wysoki stopień niebezpieczeństwa oraz nieprzemyślane ryzyko. Wszystko to, aby konkretne osoby lub zgrupowania zyskały jednoznaczny rozgłos. Metoda full disclosure powinna być głównie stosowana w przypadku powiadamiania dostawców oprogramowania, aby w jasny i klarowny sposób przedstawić im sedno problemu, a nawet zasugerować sposób naprawy. W ten sposób cała wartość informacji kierowana jest do odpowiedniego odbiorcy. Na szczęście w ujęciu publicznym trend ten cieszy się coraz mniejszym zainteresowaniem na przestrzeni ewolucji ujawniania luk w zabezpieczeniach, w której katalizatorem jest ciągły postęp technologiczny i rosnąca świadomość wartości wielu informacji. Coraz częściej stosowanym wariantem tego procesu staje się responsible disclosure (odpowiedzialne ujawnianie), które dzięki wcześniejszemu powiadomieniu producentów pozwala im na wydanie poprawki i publiczne ogłoszenie jej dostępności; odczekaniu odpowiedniego okresu czasu, aż wszyscy odpowiedzialni użytkownicy wykonają aktualizację, a dopiero później publikacji informacji o błędzie. No i ze względu na dzisiejszy hacking wydaje się to bardziej etyczne.

Felieton ten pochodzi z magazynu: Hakin9 Nr 4 (24) Kwiecień 2007.

Dnia 06.03.2010

Podglądanie pulpitu

U

żywając mechanizmu haków w systemie Windows, możemy swobodnie przechwytywać poufne dane wprowadzane z klawiatury (hakin9 1/2008). Pora teraz podpatrzeć,
co użytkownik robi na swoim komputerze.

Artykuł ten został opublikowany w numerze 02/2008 (34) magazynu hakin9.

Artykuł w formacie PDF

Dnia 03.03.2010

Ataki kombinowane

A

taki kombinowane (ang. combined attacks) i mieszane zagrożenia – (ang. blended threats) to sieciowe formy ataku komputerowego, które polegają na zmaksymalizowaniu dotkliwości wyrządzonych spustoszeń i prędkości rozprzestrzenienia / zarażania poprzez łączenie metod charakterystycznych dla wirusów i robaków (ang. worm), jak również dzięki wykorzystaniu podatności w danych systemach komputerowych czy systemach urządzeń sieciowych. Bardzo często podczas tego rodzaju ataku używa się także ogólnie ujętej socjotechniki (szczególnie w fazie wstępnej, obejmującej działania phishingu lub pharmingu).

Podejście takie stosowane jest w przypadku bardziej skomplikowanych ataków, gdzie ważnym założeniem jest, aby atakujący przeniknął niezauważony przez wszystkie systemy bezpieczeństwa. Dzięki użyciu wielu technik ataków elektronicznych, zasięg zagrożeń mieszanych jest bardzo duży już z definicji. Charakterystycznymi cechami dla tej techniki są: wyrządzanie szkód na skalę masową; propagacja za pomocą wielu metod – na przykład wstępna dystrybucja odbywa się za pomocą hybrydy (wirus/robak) umieszczonej w wiadomości e-mail, która sama zaczyna się replikować infekując serwery WWW, by każdy odwiedzający stronę użytkownik został również zainfekowany – po czym proces się powtarza (w wielu przypadkach mechanizm taki posiada możliwość automatycznej aktualizacji – łącząc się ze stroną utrzymywaną w technice fast-flux, aby pobrać najnowsze wtyczki uaktualniające jego możliwości lub omijające nowo powstałe mechanizmy neutralizujące); atak na wiele punktów jednocześnie przy wykorzystaniu powstałych luk w oprogramowaniu, które mogą także być przyczyną wcześniejszego ataku np. malware (pasożytnicze żerowanie na innym szkodliwym oprogramowaniu). Zamiarem takiego ataku jest dokonanie rzeczywistej szkody (a nie tylko spowodowanie drobnych problemów z komputerem ofiary), np. poprzez wykonanie ataku DDoS (ang. Distributed Denial of Service) przeciwko wybranemu celowi lub masowa dystrybucja koni trojańskich do wysyłania wiadomości SPAM. Formy tego rodzaju ataku określane są jako najbardziej groźne i wyrafinowane w dziedzinie bezpieczeństwa komputerowego, w dodatku nie wymagają interwencji człowieka (otwierania załączników) dla dalszej własnej propagacji w Sieci. Raz zainicjowane – automatycznie szukają nowych celów, poddając je wielu próbom na sprawdzone luki w mechanizmach bezpieczeństwa. Aktualnie ataki te wykazują cechy wirusów, robaków, koni trojańskich, a także innego rodzaju malware. Najprostszym atakiem wykorzystującym technikę mieszanych zagrożeń jest wysłanie wirusa w załączniku poprzez pocztę e-mail, razem z koniem trojańskim osadzonym w pliku HTML, który ma na celu całkowite uszkodzenie komputera odbiorcy. Nimda, CodeRed oraz Bugbear są typowymi, przykładnymi pierwowzorami mieszanych zagrożeń (już w 2003 roku firma Symantec odnotowała 64% wzrost popularności tego rodzaju ataków). Efektami takiego ataku są nie tylko straty w oprogramowaniu czy nawet sprzęcie komputerowym, lecz także znaczny spadek wydajności wielu pracowników, którzy w wyniku kompromitacji całej sieci czy poszczególnych maszyn są zmuszeni do zawieszenia wielu czynności do czasu, gdy zostaną przywrócone normalne warunki pracy. Obecnie za jedyną formę walki z mieszanymi zagrożeniami specjaliści uważają skupienie się na zarządzaniu poprawkami bezpieczeństwa, używaniu i utrzymywaniu w dobrym stanie zapór ogniowych, a także posługiwanie się systemami IDS (ang. Intrusion Detection System), które posiadają zdefiniowane reguły wykrywające różnego rodzaju szkodliwe oprogramowanie. Wszelkiejmożliwej ochronie powinny podlegać wszystkie punkty infrastruktury informatycznej (ochrona wielu warstw), które mogą zostać potencjalnie zaatakowane, np. brama internetowa (ang. gateway), brama komunikacyjna: e-mail, IM (ang. messaging gateway) czy stacje i serwery końcowe (ang. endpoint clients / servers). Jeśli chodzi o utrzymanie dobrego stanu zapór ogniowych – mowa tutaj oczywiście o stałym nadzorze i aktualizacji oprogramowania wchodzącego w skład mechanizmów blokujących, a także ich implementacja zarówno na węzłach sieciowych, jak i komputerach typu desktop. Edukacja użytkowników i pracowników w zakresie postępowania z załącznikami i niechcianą pocztą, a także ogólne zasady zachowania się online również wnoszą bardzo dużo do zminimalizowania ryzyka infekcji. Szczególnie pomocne są krótkie noty dla pracowników związane z najnowszymi zagrożeniami oraz wytycznymi, jak postępować w ich obliczu w przypadku infekcji zwykłych PC czy urządzeń mobilnych, które aktualnie zbliżone są swoją funkcjonalnością do komputerów osobistych.

      Wraz z rozwojem opisywanego typu ataków możemy zauważyć, jak powoli zacierają się granice pomiędzy poszczególnymi systemami operacyjnymi. Ze względu na swoją budowę programistyczną oraz podejście producenta do kwestii – faworytem nadal pozostaje produkt giganta z Redmond (mimo, iż w 2006 roku laboratorium firmy Kaspersky znalazło kod dowodzący możliwości stworzenia wirusa zdolnego zainfekować zarówno system Windows, jak i Linux – Virus.Linux.Bi.a / Virus.Win32.Bi.a). By zmajstrować coś w Linuksie, trzeba nad tym popracować, by zmajstrować coś w Windowsie, wystarczy na nim pracować. Jednak ataki wymierzone w system Linux bazują głównie na jego słabościach pod względem konfiguracyjnym, a nie programistycznym (w tej koncepcji wykorzystywane są exploity). Na początek można przytoczyć przykład szkodliwego oprogramowania, które wykorzystując błąd pod postacią słabego hasła do kont FTP czy paneli logowania CMS – łamiąc je metodą siłową (ang. brute force) dodawało do każdego pliku index.html / .php, a także .htaccess, zaszyfrowany kod, który miał za zadanie otworzyć ramkę typu IFRAME w przeglądarce i przekierować użytkownika do specjalnie spreparowanej strony. Na witrynie tej dokonywana była analiza, czy zanotowano wcześniej połączenie z konkretnego adresu IP. Jeśli tak, zostawała wyświetlona strona z komunikatem błędu, jeśli nie – przekierowanie było kontynuowane wraz z powtórną weryfikacją adresu IP, po czym kolejny podstawiony skrypt podsyłał ofierze plik będący koniem trojańskim (Win32.Trojan-Spy.Zbot – więcej informacji można znaleźć na blogu Bothunters). Ciekawą kombinacją jest tutaj wykorzystanie uchybienia w protokole bezpieczeństwa pod postacią słabych haseł do kont FTP oraz błędu konfiguracji, która nie uwzględniała żadnego mechanizmu wymuszającego stosowanie tylko silnych haseł do uwierzytelniania kont. W efekcie czego otrzymaliśmy pośrednie infekcje, przenoszące się przy pomocy systemów Uniksopodobnych, które miały na celu rozprzestrzenienie się już w systemach Windows. Można przytoczyć podobny przykład, związany z techniką wstrzyknięcia kodu SQL (ang. SQL Injection), np. boty wyszukujące stron zawierających frazę is not a valid MySQL i – w zależności od funkcji, która zwraca ów komunikat (mysql _ num _rows(), mysql _ fetch _ array() itp.) – przeprowadzające serię odpowiednich ataków, mających na celu wykorzystanie kolejnych dzieł nieuważnego programisty. Może być to np. skrypt PHP / JavaScript do ściągania malware lub dodawanie treści SPAM do zawartości baz danych, która ukazywana byłaby na stronach WWW. W tym przypadku wykorzystane zostałyby błędy konfiguracyjne i programistyczne PHP. Konfiguracyjne – ponieważ komunikaty błędów powinny być logowane do odpowiednich plików, a nie wyświetlane na stronie. Programistyczne – ponieważ to właśnie niesprawdzony lub niezaktualizowany kod generuje takowe ostrzeżenia. Takie ataki kombinowane nie tylko stanowią tunele łączące różne luki różnych platform systemowych, ale także ukazują prawidłowość, że za błąd popełniony w jednym systemie często musi zapłacić drugi. Przy założeniu, że istnieją mniej i bardziej bezpieczne systemy operacyjne, a te w wyższym stopniu odporne służą do ochrony tych bardziej podatnych na ataki – luka znaleziona w systemie ochronnym staje się poważną konsekwencją dla systemów chronionych. Do tego faktu możemy dodać, iż systemy ochronne cieszą się również większym zaufaniem, co czyni je doskonałym medium propagującym ataki. Istnieją również ataki kombinowane, wymierzone tylko i wyłącznie w systemy uchodzące za bezpieczniejsze, wykonywane za pośrednictwem systemów, które posiadają większą zdolność do ich przejmowania. Aktualnie botnety (skoordynowane sieci komputerów) wykorzystywane są m.in. do testowania haseł różnych daemonów Uniksowych / Linuksowych (najpopularniejszym jest SSHd) oraz przeprowadzania ataków z użyciem exploitów. Technika ta daje atakującemu gwarancję, że nie zostanie on zbyt szybko zablokowany (jakby to miało miejsce w przypadku pojedynczego adresu IP) i wykryty. Popuszczając nieco wodzy fantazji, kwestią czasu może być powstanie botnetów służących do łamania kluczy kryptograficznych za pomocą systemów rozproszonych – obok tych rozsyłających SPAM. Skoro botnety wysyłające niechcianą pocztę wykorzystują w głównej mierze przepustowość łączy internetowych, czemu nie stworzyć botnetów wykorzystujących przeważającą część mocy procesorów zainfekowanych maszyn?

Felieton ten pochodzi z magazynu: Hakin9 Nr 10 (41) Październik 2008.

Dnia 21.02.2010

Rejestracja na Zimowy AgileTuning została właśnie otwarta

Dzięki funduszom od Agile Alliance i Scrum Alliance udało się nam sfinansofwać podróż kilku prelegentów spoza Polski. Prezentacje “rodzimych” ekspertów wyglądają nie mniej ciekawie. Szczegółowy program imprezy dostępny jest pod adresem http://zimowy.agiletuning.pl/program

Rejestracji można dokonać na stronie http://zimowy.agiletuning.pl/rejestracja Lepiej nie czekać do ostatniego momentu ponieważ ilość miejsc jest ograniczona.

Opera – analiza działania mechanizmu ochrony przed oszustwami

O

d kilku lat wszyscy jesteśmy świadkami nowej ery w historii globalnej sieci Internet. Otóż narzędzie, które początkowo miało służyć rozwojowi myśli technicznej, w momencie wkroczenia weń wielkiego biznesu spowodowało pociągniecie za nim osób chcących w łatwy i szybki sposób wzbogacić się cudzym kosztem – mowa tu o internetowych przestępcach.

Artykuł ten został opublikowany w numerze 10/2007 (30) magazynu hakin9.

Artykuł w formacie PDF

Dnia 20.02.2010

Rodzaje i klasyfikacja włamań oraz ataków internetowych

N

iniejsza publikacja opisuje teoretyczne aspekty bezpieczeństwa komputerowego (włamania, ataki oraz techniki; odpowiednio posortowane oraz przydzielone do odpowiednich im sekcji); w żadnym wypadku publikacja ta nie jest tutorialem, czy przewodnikiem i nie powinna być w taki sposób postrzegana. Autorzy skupili się na możliwie jak najwierniejszym przedstawieniu poszczególnych i konkretnych technik ataków oraz ich klasyfikacji (swoista hierarchia). Niektóre z prezentowanych tu technik w warunkach “normalnych” i “przyjaznych” służą jako przydatne narzędzia dla administratorów czy też chociażby funkcje implementowane w celu zwiększenia funkcjonalności dla potencjalnych użytkowników, jednak w rękach włamywaczy mogą one stanowić (i stanowią) potencjalną broń – publikacja ta również w swoim zamierzeniu poświęca miejsce takim aspektom.

     Włamanie jest typem ataku, który obejmuje kradzież prywatnych lub poufnych informacji, dowolną zmianę lub usunięcie danych i zmianę ustawień konfiguracyjnych. Podczas ataku tego typu może również zostać zablokowane konfigurowanie zabezpieczeń lub ich wyłączenie, czy zamiana plików konfiguracyjnych, w celu ułatwienia następnych włamań…

     Wraz z rozwojem komunikacji sieciowej rozwijają się także ataki ukazujące słabości nowo powstałych rozwiązań. Możliwe jest, że podział ataków utrzyma się taki sam, lecz ich rodzaj oraz klasyfikacja zmienia się poprzez mieszanie poszczególnych ich anatomii. Coraz nowsze ataki łączą w sobie wiele rodzajów lub są udoskonaleniem swoich poprzedników. Niektóre z ataków już nie pozwalają na przyporządkowanie siebie do istniejących grup, co zmusza do tworzenia nowych klasyfikacji, które wraz z upływem czasu będą się stawać coraz większe. Niżej wymienione rodzaje ataków są tylko nielicznymi przykładami z jakimi możemy się spotkać użytkując komputery, a co za tym idzie Internet. Poza nimi istnieje jeszcze wiele innych ataków, które posiadają własne rozwiązania w stosunku do stosowanych technik sieciowych oraz ich zabezpieczeń.

Celem takich ataków są poszczególne komputery bądź serwer główny (ew. węzły nadzorujące). Konsekwencjami są zwykle przerwy w pracy sieci lokalnej, uszkodzenie poszczególnych (bądź wszystkich) końcówek serwera, a co za tym idzie – całej sieci, co powoduje wielogodzinne przerwy w pracy. Skutki mogą być niewinne i skończyć się na zawieszeniu poszczególnych komputerów czy nawet całej sieci, ale może to także prowadzić do fizycznego uszkodzenia sprzętu (albo co gorsza wyciek lub utraty ważnych i często poufnych danych).

Ataki możemy podzielić ze względu na:

  • Źródło:

    a) Zewnętrzne (zdalne) – ataki przeprowadzane są z systemów znajdujących się poza atakowaną siecią, na przykład atak na sieć firmy NFsec.Inc odbywa się z sieci firmy Agresory.Inc.

    b) Wewnętrzne (lokalne) – ataki przeprowadzane są z systemów znajdujących się w atakowanej sieci, na przykład atak na główny serwer firmy NFsec.Inc odbywa się z serwera działu zaopatrzenia tej samej firmy przez sfrustrowanego pracownika. Atakiem wewnętrznym można również uznać atak użytkownika serwera w celu zdobycia

    c) Pośrednie – ataki przeprowadzane są za pomocą systemów i urządzeń pośredniczących w celu ukrycia oryginalnego źródła ataku. Najczęściej do tego celu wykorzystywane są systemu typu open proxy i open relay lub inne systemy umożliwiające dalsze przekazywanie łączności sieciowej bez odpowiedniego filtrowania. Ataki pośrednie są również pierwszym etapem wykorzystania luk w zabezpieczeniach zaufanych środowisk, takich jak popularne witryny instytucji finansowych oraz społeczności internetowych. Po złamaniu zabezpieczeń zaufanego serwisu WWW, przestępcy mogą wykorzystać go jako źródło rozpowszechniania destrukcyjnych programów używanych następnie do włamywania się do wybranych komputerów.

    d) Bezpośrednie – ataki przeprowadzane bezpośrednio na atakowanych systemach (zdalnie lub lokalnie) bez wykorzystania żadnych systemów i urządzeń pośredniczących. Bazują one na bezpośrednim wykorzystywaniu wykrytych luk, których specyfikacja uniemożliwia wykorzystania pośredników do przekazania strumienia ataku. Ataki bezpośrednie bardzo często przeprowadzane są z wcześniej przejętych systemów. W ten sposób atakujący posiada możliwość przeprowadzenia bezpośredniego ataku, a poprzez pełną kontrolę nad przejętym systemem “atrapą” zatarcia śladów oryginalnego źródła ataku.

  • Zamiar:

    a) Zamierzony – atakujący zdaje sobie sprawę z tego, co robi i jakie konsekwencje mogą z tego wyniknąć. Na przykład atak w celu uzyskania konkretnie wytyczonych informacji czy unieruchomienia serwera (DoS).

    b) Niezamierzony – atakujący przypadkowo i nieświadomie dokonuje ataku, na przykład jeden z użytkowników serwera przez błąd programu obchodzi system autoryzacji uzyskując prawa administratora lub wpisując w formularzu losowy ciąg znaków wykonuje atak XSS.

  • Skutek:

    a) Udany – rozpoczęty atak przez atakującego kończy się osiągnięciem zamierzonego celu, na przykład poprzez przeskanowanie sieci wykrywa lukę w zabezpieczeniu, którą wykorzystuje do ataku, który okazuje się trafny i kończy się powodzeniem, zaciera za sobą ślady i opuszcza atakowany cel. Udany skutek ataku możemy podzielić na:

    - Aktywny – w wyniku ataku system komputerowy traci integralność, na przykład atak włamywacza, który usuwa pewną ilość ważnych danych oraz powoduje zmianę działania programów. Atakiem aktywnym może być także modyfikowanie strumienia danych lub tworzenie danych fałszywych.

    - Pasywny – atak ten polega na wejściu do systemu bez dokonywania w nim żadnych zmian, na przykład atak włamywacza, który kopiuje pewną ilość ważnych danych nie powodując zmian w działaniu programów. Atakiem pasywnym może być także podsłuchiwanie lub monitorowanie przesyłanych danych. W tym przypadku celem osoby atakującej jest odkrycie zawartości komunikatu. Typowym atakiem pasywnym może być analiza przesyłu danych (ang. traffic analysis). Ataki pasywne są bardzo trudne do wykrycia, ponieważ nie wiążą się z modyfikacjami jakichkolwiek danych.

    b) Nieudany – rozpoczęty atak przez atakującego kończy się nie osiągnięciem zamierzonego celu, na przykład poprzez przeskanowanie sieci wykrywa lukę w zabezpieczeniu, którą wykorzystuje do ataku, który okazuje się nietrafny i kończy się niepowodzeniem, brak możliwości zatarcia śladów powoduje ryzyko wykrycia ataku jak i samego atakującego.

  • Przepływ informacji:

    a) Przerwanie (ang. interruption) – jest atakiem na dyspozycyjność polegający na częściowym zniszczeniu systemu lub spowodowaniu jego niedostępności (niezdolności do normalnego użytkowania). Przykładem tutaj może być fizyczne zniszczenie fragmentu komputera lub sieci, np. uszkodzenie dysku, przecięcie linii łączności między komputerem a drugim obiektem, lub uniemożliwienie działania systemu zarządzania plikami.

      [##] ----------x---------> [##]
      [##]           |           [##]
       |             |            |
      Użytkownik   Agresor       Serwer
    

    b) Przechwycenie (ang. interception) – jest atakiem opierającym się na poufności i występuje wtedy, gdy ktoś niepowołany uzyskuje dostęp do zasobów naszego systemu komputerowego. Przykładem tutaj może być podsłuch pakietów w celu przechwycenia danych w sieci i nielegalne kopiowanie plików lub programów.

      [##] ----------|---------> [##]
      [##]           |           [##]
       |            \ /           |
      Użytkownik   Agresor       Serwer
    

    c) Modyfikacja (ang. modification) – jest atakiem opierającym się na nienaruszalności polegający na zdobyciu dostępu do zasobów przez niepowołaną osobę, która wprowadza do nich jakieś zmiany w celu uzyskania wyższych praw lub utrzymaniu dostępu do danego systemu. Przykładem tutaj może być zmiana wartości w pliku z danymi, wprowadzenie zmiany w programie w celu wywołania innego sposobu jego działania lub modyfikacja komunikatów przesyłanych w sieci.

      [##] ---------\ /--------> [##]
      [##]           |           [##]
       |             |            |
      Użytkownik   Agresor       Serwer
    

    d) Podrobienie (ang. fabrication) – podrobienie jest atakiem opierającym się na autentyczności, podczas przesyłania danych z jednego do drugiego komputera trzeci komputer blokuję uniemożliwiając mu dalszy przesył, a sam wprowadza do systemu drugiego komputera fałszywe obiekty. Przykładem tutaj może być
    wprowadzenie nieautentycznych komunikatów do sieci lub dodanie danych do pliku.

      [##] -------x-> /--------> [##]
      [##]           |           [##]
       |             |            |
      Użytkownik   Agresor       Serwer
    

  • Dostęp do informacji:

    a) Odczytanie (ang. read) – odczytanie informacji, do której nie jest się uprawnionym.

    b) Przekopiowanie (ang. copy) – przekopiowanie zastrzeżonych informacji w celu ich swobodnego wykorzystania.

    c) Modyfikacja (ang. modify) – modyfikacja zawartości i charakterystyki informacji w celu dalszej kompromitacji.

    d) Usunięcie (ang. delete) – destrukcyjne działanie mające na celu bezpowrotne usunięcie wybranej informacji.

   Warto także wspomnieć, iż bardzo często używanym kryterium miejsca przeprowadzania ataków jest także podawanie Warstwy OSI, na której atak / włamanie przebiega, ew. postronnie dotyczy. I tak przykładowo zgodnie z warstwami OSI, ataki na niższych warstwach (np. warstwa druga łącza danych L2 bądź też warstwa trzecia sieciowa L3) dotyczyć będą głównie routingu (ustalanie tras pakietów) czy też samego już “pakowania” danych w odpowiednie ramki. A więc ataki tutaj przynależne to m. in. ataki w sieciach DHCP oparte o sam przesył danych, ataki na MAC, ARP, wysyłanie niepoprawnych pakietów do routera w celu jego zablokowania, podszycia się, itp. Możliwości jest rzeczywiście bardzo wiele nawet w pierwszej warstwie L1 – fizycznej, która może już rozróżniać ataki na sieci przewodowe i bezprzewodowe. Z kolei ataki na warstwach wyższych dotyczyć już będą głównie błędów w samych aplikacjach, ich złych konfiguracjach, błędnego działania mechanizmów zabezpieczających typu firewall, NIDS, HIPS, wstrzykiwanie danych, itp.

Więcej informacji: Bezpieczeństwo teleinformatyczne, Ataki opisane w dziale “Ataki Internetowe”

Dnia 19.02.2010

Jebut

Tytuł tego wpisu to jednocześnie onomatopeja oddająca odłgos mojej szczęki opadającej na podłogę, podczas gdy reszta ciała zapoznawała się z wyrokiem Trubunału Sprawiedliwości Wspólnot Europejskich w sprawie Komisja Wspólnot Europejskich przeciwko Rzeczypospolitej Polskiej.

Poszło o GMO.

Daruję sobie istotę problemu, bo każdy kto ma mózg potrafi sobie wyguglać czym jest GMO, porównać dostępne na ten temat dane i wyciągnąć wnioski. Clou tej notki jest co innego: uzasadnienie stanowiska naszego rządu. Rząd nasz otóż postanowił nie wprowadzać w życie postanowień dyrektywy 2001/18/WE, gdyż albowiem ponieważ nie bardzo wiadomo dlaczego. Z jednej bowiem strony minister rolnictwa twierdzi, iż Biorąc pod uwagę obecny stan wiedzy naukowej i opinii ekspertów, można stwierdzić, że żywność modyfikowana genetycznie nie stanowi zagrożenia dla zdrowia ludzi, z drugiej Polska nie kwapi się z dopuszczeniem do obrotu morderczego GMO. W końcu, gdy Komisja traci cierpliwość i pozywa Najjaśniejszą przed surowe oblicze Trybunału, nasz przedstawiciel – Mikołaj Dowgielewicz – musi się podpierać argumentacją zapewne przez siebie nie napisaną. I teraz najlepsze, ta argumentacja. Zaczerpnięta z uzasadnienia wyroku, który każdy jeden Polak i każda jedna Polka może sobie przeczytać (sprawa o numerze C-165/08).

Co do istoty sprawy Rzeczpospolita Polska podnosi, że wbrew temu, co utrzymuje Komisja, orzecznictwo potwierdza, że skarga na podstawie art. 30 WE przestaje być możliwa tylko wtedy, gdy przeprowadzona harmonizacja wspólnotowa obejmuje środki niezbędne do osiągnięcia szczególnego celu, do którego ochrony zmierza to postanowienie traktatu WE. Tymczasem względów etycznych nie obejmują właśnie dyrektywy 2001/18 i 2002/53, które mają na celu wyłącznie ochronę środowiska i zdrowia ludzi. Motyw 57 i art. 29 ust. 1 dyrektywy 2001/18 zastrzegają poza tym wyraźnie dla państw członkowskich kompetencję regulacji aspektów etycznych związanych z GMO.

W niniejszym przypadku przyjęcie spornych przepisów krajowych kierowane było zasadami etyki chrześcijańskiej i humanistycznej, które są wyznawane przez większość polskiego społeczeństwa.

W tym zakresie Rzeczpospolita Polska powołuje się kolejno na chrześcijańską koncepcję życia, która sprzeciwia się temu, aby organizmy żywe stworzone przez Boga były przedmiotem manipulacji i zmieniane były w materiały będące przedmiotem praw własności przemysłowej, na chrześcijańską i humanistyczną koncepcję postępu i rozwoju, która nakazuje szacunek dla planu stworzenia, jak również na poszukiwanie harmonii między człowiekiem i przyrodą, i w końcu na chrześcijańskie i humanistyczne zasady ładu społecznego, gdyż zredukowanie organizmów żywych do rangi produktów o celach czysto komercyjnych może szczególnie podważać fundamenty funkcjonowania społeczeństwa.

To jest, proszę wycieczki, argumentacja kraju, który w swojej konstytucji posiada artykuł dwudziesty piąty. To jest, proszę wycieczki, przykład tego, jak ze słynnego NOMA w polskich realiach zostaje OMA. To jest również przykład kompletnej, graniczącej z histerią bezradności, którą – przy braku sensownych argumentów – każe przed międzynarodową instytucją wyciągać argumenty bezsensowne, co potem owocuje kolejnymi żartami o kraju nad Wisłą (czemu po fakcie wszyscy się u nas niezmiernie dziwią). Tekst o „zredukowaniu organizmów żywych do rangi produktów o celach czysto komercyjnych” powinien wejść do antologii najlepszych dowcipów świata, szczególnie jak sobie człowiek uświadomi, że na bazarkach i giełdach rolnych organizmami żywymi handluje się od tysiącleci i w celach komercyjnych jak najbardziej. Przy okazji zwracam uwagę szanownej wycieczki na sprytne splecenie chrześcijańskiej i humanistycznej koncepcji postępu. W ten prosty sposób jednymi, którzy nie brzydzą się GMO zostali kanibale, pedofile i mordercy.

Wynik tego całego cyrku na kółkach? Sprawę z godnościom osobistom przerżęnlim, mamy zapłacić koszta własne i dwie trzecie kosztów poniesionych przez Komisję Europejską. Pan zapłaci, i pani zapłaci. Ale moralnie to jesteśmy górą, tak nam dopomóż.

PS Temat tego wpisu został bezczelnie wykradziny Danielowi Passentowi, z jego felietonu pt. „Z życia buraków” („Polityka” 8/2010). W ramach jego poszerzania (tematu, nie Passenta) proponuję lekturę tekstu „Sąd ostateczny” Joanny Podgórskiej i Agnieszki Mazurczyk. Też ciśnienie skacze.

Dnia 18.02.2010

Format BMP okiem hackera

P

liki graficzne są dziś szeroko rozpowszechnionym nośnikiem informacji, spotyka się je praktycznie na każdym komputerze. Dobry programista powinien wiedzieć jak wyglądają nagłówki poszczególnych formatów plików graficznych, i jak są przechowywany jest sam obraz. A jak to zwykle bywa, diabeł tkwi w szczegółach.

Artykuł ten został opublikowany w numerze 03/2008 (35) magazynu hakin9.

Artykuł w formacie PDF

Dnia 17.02.2010

Proste monitorowanie serwera WWW za pomocą PHP

P

HP może zostać wykorzystanie nie tylko do pisania dynamicznych aplikacji internetowych, ale również prostych skryptów, takich jak np. skrypt służący do monitorowania wybranej strony WWW, którego zadaniem jest powiadamianie poprzez e-mail w przypadku, gdy serwer WWW nie odpowiada lub szukana fraza na stronie nie została znaleziona.

Jego przydatność określają dwa przypadki. Pierwszym jest wiadomość, o tym, że serwer WWW, na którym jest ulokowana nasza strona jest niedostępny. Drugim jest proste sprawdzenie czy nasza strona w wyniku ataku nie została podmieniona (ang. website defacement). Poniższy skrypt wystarczy zapisać np. w pliku o nazwie monitor.php:

<?php
function check($host, $find) {
    $fp = fsockopen($host, 80, $errno, $errstr, 10);
    if (!$fp) {
        echo "$errstr ($errno)\n";
    } else {
       $header = "GET / HTTP/1.1\r\n";
       $header .= "Host: $host\r\n";
       $header .= "Connection: close\r\n\r\n";
       fputs($fp, $header);
       while (!feof($fp)) {
           $str .= fgets($fp, 1024);
       }
       fclose($fp);
       return (strpos($str, $find) !== false);
    }
}

function alert($host) {
    mail('login@e-mail.com', 'Monitoring WWW', $host.' nie odpowiada.');
}

$host = 'www.nfsec.pl';
$find = 'Grid Focus';
if (!check($host, $find)) alert($host);
?>

Funkcja check() przyjmuje dwa parametry. Pierwszym jest adres serwera WWW, którego dostępność chcemy sprawdzać (w przykładzie jest to nfsec.pl) oraz drugim jest wybrana fraza, której szukamy na monitorowanej stronie WWW. Jeśli serwer nie odpowie, lub wybrana fraza nie zostanie znaleziona – wówczas może świadczyć to o tym, że z serwer WWW jest przeładowany, czy wyłączony lub, co gorsza ktoś podmienił treść naszej strony w wyniku ataku. W takim przypadku zostanie wywołana funkcja alert(), która prześle odpowiednią wiadomość na wybrany adres e-mail.

Należy pamiętać, aby skrypt taki był uruchamiany z zewnętrznego (innego niż, ten na którym stoi nasza strona WWW) serwera monitorującego. Cykliczne (co godzinne) wywoływanie skryptu możemy osiągnąć dzięki wpisowi umieszczonemu w crontabie:

0 * * * * /usr/bin/php -q /htdocs/www/monitor.php

Plik monitor.php powinien posiadać prawa dostępu 644 (chmod 644 monitor.php).

Więcej informacji: Cats Who Code

Dnia 14.02.2010

„Heligoland” albo stopa zwrotu z inwestycji

Zapewne nawet najbardziej zaciekli[1] czytelnicy blogusia nie zdają sobie sprawy jaką to miętę czuję do dokonań grupy Massive Attack. Przy czym czuję się też w obowiązku zaznaczyć, że uczucie to nie przekłada się wcale na umiłowanie do gatunku jako takiego. Trip hop nie kręci mnie jakoś szczególnie, tylko od Massive Attack zalatuje wspomnianą miętą.

Ze zespołem tym stało się tak, że najpierw wydał trzy znakomite płyty – „Blue Lines”, „Protection”„Mezzanine” – a potem wziął i się zepsół. Czwarty krążek, „100th Window”, był właściwie solowym dokonaniem 3D. Umówmy się, że to nie była dobra płyta, wcale. Jakby w uznaniu tego smutnego faktu del Naja zrobił sobie siedmioletnią przerwę i gdy PT Publiczność przekonana już była, że projekt poszedł do piachu, Massive Attack powróciło. I to, w mordę, naprawdę był Zmasowany Atak.

„Heligoland”, piąty krążek. Pełna rehabilitacja po „100th Window”, nie wiem czy nie najlepsze dokonanie w dziejach grupy. Mam jakoś tak dziwnie, że dobre płyty rozpoznaję po tym, że mi się nie podobają. Znaczy, wróć – nie podobają mi się przy pierwszym przesłuchaniu. Przesłuchanie drugie, które następuje z reguły następnego dnia po tym pierwszym, przynosi już wzrost zainteresowania i ostrożne stwierdzenie, że może nie jest tak źle, jak się na początku wydawało. Przesłuchanie trzecie kończy się łagodną odmianą ekscytacji, że właśnie udało mi się trafić na dobrą płytę. Czwarte jest tylko potwierdzeniem tej diagnozy i rozpoczyna kilkutygodniowy maraton z jednym krążkiem na uszach, aż do zajechania materiału. Szybki galop po internetowych recenzjach potwierdza tą diagnozę: nie dajcie się zwieść pierwszemu wrażeniu.

Okładka albumu Heligoland

Zaczyna się znakomicie: „Prain for Rain” to typowo massivatackowy numer, odpowiednio mroczny, na wysokości 2:50 łapiący drugi, lepszy oddech. Dodatkowo zawiera chyba najlepszy wokal na całym krążku (Tunde Adepimbe). „Babel” z Martiną Topley-Bird już taki dobry nie jest, aczkolwiek poniżej pewnego poziomu nie schodzi. „Splitting the Atom”, znany z epki, jest minimalistyczny, leniwy, hipnotyzujący.

„Girl I Love You” to kolejny jasny moment na płycie, trochę jakby wyjęty z sesji „Blue Lines” – gdyby nie Horace Andy na wokalu byłby jeszcze lepszy. Następujący zaraz po nim „Psyche” to bardzo przyjemna przyśpiewka – dosłownie. Takie małe niby nic, ale wkręca. „Flat Of the Blade” to chyba najsłabsza chwila, nie będę się rozpisywał, tym bardziej, że zaraz po nim melduje się „Paradise Circus”. Murowany kandydat do ścisłej czołówki dokonań grupy, wsłuchajcie się w wokal Hope Sandoval i zwróćcie uwagę jak całość się pięknie rozwija – z prostej melodii do małego, muzycznego Wszechświata (poniższy teledysk to wersja NSFW, lepsza moim zdaniem od tego, co widać w telewizorach).

„Rush Minute” to del Naja na wokalu, czyli to, co tygrysy lubią najbardziej (ktoś pamięta „Eurochild”?) i znów dwie czy trzy nuty w tle. „Saturday Come Slow” to Damon Albarn z Blur (idealnie pasuje do tej linii melodycznej, właściwie mógłby się pod tym podpisać). Zamykający „Atlas Air” to wisienka na torcie – dosłownie. Mój ulubiony utwór, zaczyna się znakomicie a potem jest już tylko lepiej. 3D wiedział chyba dobrze, że musi to mieć tylko dla siebie. Ech, żeby każda płyta kończyła się tak dobrze…

Jak zapewne zauważyliście rzadko się tu rozpisuję o muzyce, ale czasem pojawiają się takie krążki, że po prostu nie można przejść obok nich obojętnie. „Heligoland” to póki co płyta roku i nie sądzę, żeby cokolwiek mogło jej zagrozić przez kolejne dziesięć miesięcy. #wyraz[2], żebym tylko nie musiał czekać na kolejne wydawnictwo MA przez następne siedem lat.

Na koniec wyjaśnienie ekonomicznego wątku w tytule: za niecałe czterdzieści złotych polskich dostajecie tyle radochy, że starczy na długo. Mocny towar, jak mówią na dzielni. I tylko trochę żal, że za oceanem mogą mieć wersję MP3 za niecałe 10 dolarów. Szybkie przeliczenie siły nabywczej polskiej pensji w stosunku do równie polskich cen mam za całą diagnozę sytuacji na nadwiślańskim rynku muzycznym. Ale, ale – nie mój cyrk, nie moje małpy, señores presidentes.


Przypisy:

  1. MSPANC []
  2. nowomowa blipowa, proszę o wybaczenie []

Dnia 13.02.2010

DLL Injection

W

spółczesne systemy operacyjne pozwalają uruchomić wiele procesów, z których część posiada wyższy priorytet niż inne oraz może korzystać z większej ilości zasobów komputera. Czy jesteśmy jednak pewni, że nie da się przejąć kontroli nad tymi procesami i wykorzystać ich w sposób niezamierzony?

Artykuł ten został opublikowany w numerze 10/2008 (41) magazynu hakin9.

Artykuł w formacie PDF

Dnia 12.02.2010

Bezpieczne usuwanie pliku

N

ormalnie, gdy usuwamy plik (zobacz polecenie rm), dane nie są faktycznie niszczone. Niszczony jest wyłącznie indeks wskazujący, gdzie jest przechowywany plik, a miejsce jest udostępniane do ponownego wykorzystania. Istnieją narzędzia odzyskiwania skasowanych danych usiłujące odtworzyć indeks i potrafiące odzyskać plik, jeśli jego miejsca zapisu nie były ponownie użyte. Na zajętych systemach z prawie pełnymi napędami, miejsce może zostać ponownie wykorzystane w ciągu kilku sekund. Nie ma jednak sposobu, by się co do tego upewnić. Jeżeli posiadamy istotne dane i chcemy być pewni, że odtworzenie ich nie będzie możliwe w prosty sposób, wystarczy nadpisać plik nieistotnymi danymi.

Warto wspomnieć, że nawet po takim nadpisaniu, możliwe jest zabranie dysku do laboratorium i użycie różnego czułego (i kosztownego) sprzętu do oglądnięcia śladów “echa” pierwotnych danych pod danymi, które je nadpisały. Jeżeli dane zostały nadpisane tylko jednokrotnie, to nie jest to nawet takie trudne. W Linuksie istnieje proste narzędzie o nazwie shred (ang. niszczarka, cięcie na pask), które posługuje się wieloma kolejnymi nadpisywaniami, z wzorcami danych dobranymi tak, aby zmaksymalizować szkody wyrządzane starym danym. Mimo, że działa to także na dyskietkach, to wzorce zaprojektowane są dla uzyskania najlepszego efektu na dyskach twardych. Na przykład jeśli chcemy bezpiecznie i efektywnie usunąć plik o nazwie “poufne_dane.txt” wystarczy wydać polecenie:

shred -v -f -u -z -n 100 poufne_dane.txt

Spowoduje to: zmianę praw dostępu do pliku tak, by umożliwić jego nadpisanie; nadpisanie jego zawartości nastąpi 100 razy, gdzie przy każdym 25 powtórzeniu zostają użyte przynajmniej jednokrotnie wzorce do nadpisywania; ostatnim nadpisaniem będzie nadpisanie przy pomocy zer by ukryć proces niszczenia pliku; po nadpisaniu plik zostanie usunięty wraz z dowiązaniem o podanej nazwie. Shred umożliwia również usuwanie danych z całych partycji czy dysków:

shred -v -f -u -z -n 100 /dev/sda1
shred -v -f -u -z -n 100 /dev/sdb

Jak możemy przeczytać w dokumentacji – narzędzie shred może nie działać dokładnie tak jak założono w przypadku pracy na systemach plików opartych o rejestrację lub księgowanie np. ext3, ext4, JFS, ReiserFS, Reiser4, XFS. Na przykładzie systemu plików ext3 można stwierdzić, że chodzi o sytuację pracy w trybie najbezpieczniejszym, gdzie księgowane są zarówno metadane jak i zwykłe dane (tryb journal). W trybie standardowej pracy systemu plików ext3 (ordered), gdzie księgowane są tylko metadane narzędzie to powinno posiadać pełną efektywność.

Drugim narzędziem jest bezpieczna implementacja rmsrm (ang. secure replacement for rm(1)). W odróżnieniu od standardowego narzędzia rm nadpisuje ono dane w docelowych plikach przed ich odłączeniem. Zapobiega to możliwości odzyskania danych za pomocą dostępnych poleceń do odzyskiwania danych w systemie poprzez bezpośrednie badanie bloków na urządzeniu (dysku). Może również udaremnić fizyczne odzyskanie danych, jednak nie należy mieć pewności, że całkowicie ochroni przed tego typu odzyskiwaniem.

Srm wykorzystuje algorytmy opisane w publikacji Peter’a Gutmann’a pt. “Secure Deletion of Data from Magnetic and Solid-State Memory” oraz narzędziu The Hacker’s Choice – Secure Delete (sekwencji nadpisania, okrojenia, zmiany nazwy i odłączenia). Program ten dostępny jest w repozytorium SourceForge. Jego instalacja przebiega następująco:

tar -xvf srm.tar.bz2
./configure --prefix=/usr
make
make install
srm srm.tar.bz2

W dystrybucji Debian / Ubuntu istnieje możliwość instalacji pakietu o nazwie secure-delete również autorstwa THC, w którym zawarte są narzędzia do bezpiecznego usuwania plików (srm), wolnej przestrzeni (sfill), pamięci RAM (smem) oraz pliku wymiany (sswap).

Więcej informacji: man shred, Secure Erase in UNIX, srm

Dnia 06.02.2010

Zimowy AgileTuning - nadal czekamy na tematy!

Do Zimowego Tuningu zostało jeszcze prawie 6 tygodni. Nadal można nadsyłać propozycje tematów prezentacji. Te, które już do nas dotarły pozwalają mi obiecać, że niezapomniane widoki zza okna nie będą główną atrakcją popołudnia (dzisiaj oficjalnie ogłosiliśmy, że impreza odbędzie się w Centrum Konferencyjnym UJ w krakowskich Przegorzałach). Tym niemniej, zawsze może być ciekawiej i dlatego gorąco zachęcam do przesłania swoich propozycji do programu.

Dnia 04.02.2010

Dnia 28.01.2010

JDS

Nie znoszę takich notek, ale jednocześnie odczuwam głęboką potrzebę napisania kilku słów, gdy odchodzi ktoś dla mnie ważny. Dziś, tak się składa, zmarł Jerome David Salinger.

Gdybym miał wskazać jedną książkę, która jest dla mnie pozycją magiczną, to przychodzi mi do głowy tylko „Buszujący w zbożu”. Pamiętam, tak jakby to było wczoraj, pochłonąłem ją wiele lat temu w pociągu osobowym z Wrocławia. Zacząłem czytać gdy skład ruszał z peronu, skończyłem gdy dojeżdżałem na miejsce. Pomiędzy tymi dwoma momentami czas właściwie przestał istnieć. Coś nieprawdopodobnego. Nigdy już nie doświadczyłem czegoś takiego. Nawet Vonnegut mi czegoś takiego nie zafundował.

What really knocks me out is a book, when you’re all done reading it, you wished the author that wrote it was a terrific friend of yours and you could call him up on the phone whenever you felt like it.

Dzięki.

Salinger

Dnia 26.01.2010

Błędy w serwisach Onet.pl i WP.pl, Allegro.pl i mBank.com.pl

W

Polsce podejście do błędów typu JavaScript Injection, XSS, Session Fixation, RCSR, itp. jest mniej poważne, niż być powinno. Podczas swoich testów natknąłem się na błędy w wielu serwisach internetowych. Niektóre są większe, inne mniejsze. W pierwszej części tego artykułu chciałbym się skupić na lukach wykrytych w dwóch największych polskich portalach.

Artykuł ten został opublikowany w numerze 04/2007 (24) magazynu hakin9.

Artykuł w formacie PDF

Dnia 25.01.2010

Czytanie dokumentów SXW bez OpenOffice

Z

godnie z informacjami z Wikipedii o formacie .sxw:

SXW to rozszerzenie plików zawierających dokumenty tekstowe pakietu OpenOffice.org w wersji 1.x. Plik .sxw jest skompresowanym plikiem w formacie ZIP, wewnątrz którego znajdują się pliki XML opisujące strukturę dokumentu oraz ewentualne obiekty osadzone w jego wnętrzu, takie jak rysunki, wykresy i in. Na bazie formatu .sxw powstał używany w OpenOffice.org 2.x oraz innych procesorach tekstu format ODT, opisany w specyfikacji OpenDocument.


Dlatego, jeśli pragniemy odczytać zawartość pliku *.sxw np. w terminalu tekstowym systemu, w którym w dodatku nie ma zainstalowanego pakietu OpenOffice wystarczy umieścić wybrany plik w osobnym katalogu, rozpakować go:

unzip dokument.sxw

oraz zainteresować się plikiem o stałej nazwie content.xml. Niestety, jak na plik XML przystało jest on wypełniony dużą ilością tagów, których można się pozbyć za pomocą języka Perl:

cat content.xml | perl -p -e  "s/ [^>]*>/ /g;s/\n/ /g;s/ +/ /;"

Zabieg ten może spowodować utratę formatowania użytego w oryginalnym dokumencie sxw, ale pozwala zapoznać się z jego zawartością w trybie tekstowym jeśli zachodzi pilna taka potrzeba.

Więcej informacji: Nuff sed, OpenOffice Forum

Dnia 18.01.2010

Boski podcast

Dopiero co pisałem o moich ulubionych podcastach, a już mam pierwszą aktualizację tej listy. Zakochałem się beznadziejną miłością w produkcji niby z jednej strony amatorskiej, ale z drugiej robiącej wrażenie wyprodukowanej przez HBO czy innego Foksa. Chodzi o „Mr. Deity”.

Zaraz wyjaśni się tytuł wpisu: podcast jest o Bogu. Tym chrześcijańskim. Wic polega na tym, że ten Bóg to raczej „Bogu” ze znanego skeczu Neonówki. Mr. Deity ma zatem ajfona, lekko olewackie podejście do swoich dzieł, wspólnika Jesse (albo „Hesusa”, z hiszpańskiego), żonę Lucy (zdrobnienie od „Lucyfer”) i asystenta Larry’ego. Z poczty głosowej (modlitwy) odsłuchuje tylko pierwsze kilka nagrań, pozostałe miliony kasuje. Gdy idzie do knajpy prosi Jesse’go żeby rozmnożył pojedynczą porcję na trzy pozostałe talerze, dzięki czemu można będzie oszczędzić na rachunku. I tak dalej, i tak dalej. Czujecie już klimat? Jeśli nie, to może na zachętę pierwszy odcinek?

Co dziwne, podcast doceniany jest również przez amerykańskich chrześcijan. Twórcy dostali wiele maili, w których na przykład pastor pozdrawia i zwierza się, że wykorzystuje niektóre odcinki podczas zajęć w szkółce niedzielnej. OK, być może to nie powinno być aż takie dziwne, bo humor prezentowany w „Mr. Deity” to nie jest brutalne walenie młotem w głowę a raczej delikatne stukanie gumowym młoteczkiem w kolano. Nie każdy się zorientuje. Jak tak się zastanowić, to chyba „najmocniejszy” odcinek to „Mr. Deity and the Magic”. O, ten właśnie:

Problemy z tym podcastem są dwa. Po primo, jest po angielsku. Po secundo jest mocno „zlokalizowany” i żeby go docenić przydaje się jednak znajomość tła. W odcinku, który oglądaliście przed chwilą (bo oglądaliście go, PRAWDA?!) dobrze jest znać duet Penn&Teller, w innym z kolei („Mr. Deity and the skeptic”) warto skojarzyć, że Bóg rozmawia z PZ Meyersem i ten banan na końcu odcinka nie jest przypadkowy.

„Mr. Deity” to także „Words”, czyli taki trochę jakby sub-podcast, który opowiada o kulisach powstawania głównego show (i z którym są problemy w iTunes, ostrzegam). Od czasu do czasu trafia się też wariacja podstawowego tematu – czyli „mini wywiady o maxi sprawach”, gdzie Larry przeprowadza wywiad z Bogiem a całość wzorowana jest na słynnym pojedynku Frost vs. Nixon (i znowu dobrze jest wiedzieć takie rzeczy, bo nikt nie objaśnia kontekstu).

Fajne, c’nie? I’m sold, jak mówią rodacy autorów. Na tyle sold, że pewnie uaktywnię swoją kartę kredytową. W końcu jak ktoś tak ładnie prosi, to trudno odmówić (musicie to obejrzeć, koniecznie; sam przycinałem, temi rencami).

Dnia 14.01.2010

afsctool i kompresja na poziomie HFS+ w OS X

Mrrrrraaaauuuu, uwielbiam takie tytuły. 99% społeczeństwa nie wie czy przypadkiem nie oparłem się niechcący o klawiaturę.

Ad rem. OS X 10.6, ksywa Snow Leopard wprowadził, wśród innych nowości, kompresję na poziomie systemu plików, doganiając tym samym po piętnastu latach Windows NT 3.51. Brawo. Zanim jednak pochylimy się nad szczegółami, warto zapoznać się zasadą działania tego wynalazku.

Kompresja. Wiemy czym jest. Ale na poziomie systemu plików? Po co, skoro mamy ZIP-a, RAR-a i inne programy, które służą do rozpakowywania warezu? Po to, żeby móc zaoszczędzić miejsce na dysku zajmowane przez pliki, które do kompresji się nadają, a które są często w użyciu. Ja na przykład mam spory katalog z pedeefami. Gdybym go spakował, to owszem – odzyskałbym sporo megabajtów – ale jednocześnie stanąłbym wobec konieczności rozpakowywania całego archiwum tylko po to, żeby otworzyć jeden plik. Trochę bezsęsu.

Tym bardziej, że zastosowanie kompresji na poziomie systemu plików nie tylko oszczędza miejsce na dysku, ale i skraca czas odczytu pliku. Dzieje się tak dlatego, że skompresowane dane nie są przechowywane w sektorach, ale w tzw. resource forks a te najmniejsze nawet wprost w atrybutach pliku. Struktura tych elementów różni się od typowego układu sektor-za-sektorem i przypomina raczej bazę danych, więc i głowica Waszego twardego dysku nie musi wykonywać dłuższych wycieczek, co jest przecież elementem najbardziej wpływającym na wydajność odczytu.

OK, pora się dowiedzieć jak aktywować taką kompresję na Maku. Otóż, uwaga: NIE DA SIĘ. To znaczy, wróć, da się, ale nie z poziomu klikalnego interfejsu, jaki na przykład znamy z Windows.

Okno interfejsu Windows

Ja wiem, być może przyprawi to Wojciecha Orlińskiego o palpitacje wszystkiego, ale w celu aktywowania kompresji HFS+ trzeba się na Maku zapuścić w mętne otchłanie terminala, jak nie przymierzając jakiś linuksowiec. Zapuśćmy się zatem.

$ afsctool -v ~/Documents/pedeefy/jakiś_pedeef.pdf
File is not HFS+ compressed.
File content type: com.adobe.pdf
File data fork size (reported size by Mac OS X Finder): 12625780 bytes / 12.6 MB (megabytes) / 12 MiB (mebibytes)
Number of extended attributes: 4
Total size of extended attribute data: 244 bytes
Approximate overhead of extended attributes: 1072 bytes
Approximate total file size (data fork + resource fork + EA + EA overhead + file overhead): 12629532 bytes / 12.6 MB (megabytes) / 12 MiB (mebibytes)

Teraz uwaga: niespodzianka. Narzędzia, którym się posłużyłem nie znajdziecie w /bin. Apple postanowiło bowiem dobić Wojciecha Orlińskiego i wymyśliło, że kompresja the Mac way odbywać się będzie z wykorzystaniem komendy ditto, która to potrafi kompresować, owszem, ale podczas kopiowania. Tak jest, żeby skompresować plik trzeba go najpierw skopiować. #fuckyeah. Tak na marginesie: ditto pozwala również na wyrzucenie niechcianej architektury z Universal Binary, o czym niewiele osób wie. man ditto, jakby co.

Przywołany wyżej program o zupełnie niemakowej nazwie afsctool jest o tyle lepszy, że nie musi danych kopiować, żeby je skompresować, wyświetla sporo informacji o pliku i ma jeszcze całą masę innych, fajnych przełączników, których mnogość jest nie do ogarnięcia dla Wojciecha Orlińskiego. Autorowi, ukrywającemu się pod pseudonimem brkirch należą się wielkie brawa, uściski i co tam jeszcze.

Wróćmy do meritum. Jak widać wyżej, jakiś_pedeef.pdf liczy sobie 12 MB. Skompresujmy jegomościa.

$ afsctool -c ~/Documents/pedeefy/jakiś_pedeef.pdf
File is HFS+ compressed.
File content type: com.adobe.pdf
File size (uncompressed data fork; reported size by Mac OS 10.6+ Finder): 12625780 bytes / 12.6 MB (megabytes) / 12 MiB (mebibytes)
File size (compressed data fork - decmpfs xattr; reported size by Mac OS 10.0-10.5 Finder): 6999754 bytes / 7 MB (megabytes) / 6.7 MiB (mebibytes)
File size (compressed data fork): 6999770 bytes / 7 MB (megabytes) / 6.7 MiB (mebibytes)
Compression savings: 44.6%
Number of extended attributes: 4
Total size of extended attribute data: 244 bytes
Approximate overhead of extended attributes: 1608 bytes
Approximate total file size (compressed data fork + EA + EA overhead + file overhead): 7002180 bytes / 7 MB (megabytes) / 6.7 MiB (mebibytes)

No i proszę. 44,6%, ponad 5 megabajtów! Tyle skorzystaliśmy na całkowicie przezroczystej dla systemu kompresji, która nie wymaga żadnych dalszych zabiegów. Po prostu jest i działa. W dodatku plik ten od tej chwili będzie się szybciej ładował. Może nie będą to jakieś poważne różnice, ale zawsze.

$ purge
$ time cat ~/Documents/pedeefy/jakiś_pedeef.pdf 1>/dev/null

real 0m1.183s
user 0m0.001s
sys 0m0.024s

To przed kompresją. A po?

$ purge
$ time cat ~/Documents/pedeefy/jakiś_pedeef.pdf 1>/dev/null

real 0m0.828s
user 0m0.001s
sys 0m0.179s

Komenda purge czyści cache dyskowy w pamięci i nie ma jej domyślnie w systemie. Należy do pakietu The Computer Hardware Understanding Developer Tools, który Jobs daje za darmo o ile ma się konto w Apple Developer Connection.

Jak widać skrócił się czas ładowania kosztem wzrostu obciążenia procesora. To kompromis na, który trzeba się zgodzić – i na taki kompromis poszło Apple, kompresując większość aplikacji systemowych w OS X 10.6. To właśnie na aplikacjach notuje się największe zyski wydajnościowe, to one doczytują sporo danych z resource forków. Ludzie raportowali, że Snow Leopard zrobił się żwawszy i w dużej mierze ta „żwawość” wzięła się właśnie z kompresji w HFS+.

Dla ciekawskich: Apple wykorzystuje bibliotekę zlib, a Microsoft w swoim NTFS używa LZ77. Nie wiem jak wypada porównanie obu algorytmów, aż tak ciekawski nie byłem.

Na koniec szczypta dziegciu: kompresja w wykonaniu Apple nie przeżywa niestety modyfikacji pliku. Czyli jednak do NTFS-a trochę w tym względzie brakuje.

PS Wojciecha Orlińskiego przepraszam za naśladownictwo w stylu. Jednocześnie serdecznie pozdrawiam, machając przy tym swoim przyrządem do machania.

Dnia 13.01.2010

Nadchodzące konferencje

W Poznaniu odbędą się dwie konferencje o tematyce około-javowej (wybaczcie potworka językowego): 4Developers; 26 marca 2010, GeeCON; 12-14 maja 2010.


Dnia 11.01.2010

Hakowanie aplikacji Rootkity i Ptrace

P

rzede wszystkim muszę zastrzec, że ten tekst jest specyficzny dla Linuksa i potrzebna jest pewna wiedza o programowaniu w ANSI C oraz trochę o asemblerze. Było już dawniej parę różnych technik wstrzykiwania procesu z udziałem, kilka publicznych, jak i prywatnych exploitów, furtek i innych aplikacji. Przyjrzymy się bliżej funkcji i nauczymy się, jak pisać własne furtki.

Artykuł ten został opublikowany w numerze 01/2007 (21) magazynu hakin9.

Artykuł w formacie PDF

Dnia 10.01.2010

Brak nasłuchu podczas sesji X

W

iększość osób ignoruje bezpieczeństwo systemu X w nadziei, że w ich przypadku nie spowoduje to zagrożenia całego systemu. W systemach wykorzystujących środowiska graficzne X, do których należy większość używanych komputerów, podsystem graficzny ma dostęp do wszystkich danych wprowadzanych przez użytkowników przy użyciu klawiatury oraz wyświetlanych na ekranie.

Co więcej, (póki, co) serwer ma ustawiony bit set-UID wskazujący na użytkownika root. Wrogi proces może połączyć się z buforem systemu X i przechwycić hasło użytkownika podczas wprowadzania go za pomocą klawiatury. Jeśli nie posiada się odpowiednich zabezpieczeń, bardzo trudno się przed tym problemem uchronić. Dobrym rozwiązaniem jest zwyczajne, całkowite wyłączenie nasłuchiwania przez serwer X na porcie 6000. W tym celu podczas wywołania programu serwera należy dodać odpowiedni argument. Prostym sposobem jest dodanie do
pliku $HOME/.xserverrc poniższego wiersza:

X -nolisten tcp :0

W Slackware możemy także edytować bezpośrednio plik /usr/bin/startx i w zmiennej defaultserverargs dodać w/w frazę:

defaultserverargs="-nolisten tcp"

Dla graficznego menedżera Gnome jest to plik /etc/X11/gdm/gdm.conf:

[server-Standard]
command=/usr/X11R6/bin/X -nolisten tcp

Natomiast KDE /etc/X11/xdm/Xservers:

:0 local /usr/bin/X11/X -nolisten tcp

W celu sprawdzenia czy takie ustawienie rzeczywiście spowoduje zablokowanie możliwości utworzenia połączenia z portem 6000, należy użyć polecenia: netstat -tan | grep 6000. Innym z możliwych rozwiązań jest blokada za pomocą firewalla portów z zakresu 6000 – 6063. W przypadku niektórych systemów, dysponujących najwyższymi zabezpieczeniami właściwe mogłoby być rozważenie zupełnej rezygnacji z używania systemu X lub wręcz całkowite usunięcie go z systemu serwera. Tym niemniej niektórzy ludzie nie potrafią sobie dobrze radzić bez środowiska graficznego… To samo tyczy się serwera czcionek – XFS (X Font Server) – jeśli korzystamy z jego usług na lokalnej maszynie – możemy z pewnością wyłączyć jego nasłuch poprzez dodanie wyrażenia: no-listen = tcp do jego pliku konfiguracyjnego zazwyczaj znajdującego się w: /usr/lib/X11/fs/config.

Więcej informacji: man X, man startx

Dnia 05.01.2010

Zarządzanie tożsamością

Z

arządzanie tożsamością jest bardzo szerokim pojęciem, które posiada wiele definicji. Definicje te można sprowadzić do stwierdzenia, które mówi, że jest to zestaw technologii i procedur umożliwiający efektywne zarządzanie cyklem życia tożsamości użytkownika.

Artykuł ten został opublikowany w numerze 09/2008 (38) magazynu hakin9.

Artykuł w formacie PDF

Dnia 04.01.2010

Odwzorowanie nazw – /etc/hosts.conf

P

lik /etc/host.conf zawiera podstawowe opcje resolvera nazw. W większości wypadków wystarczy domyślna konfiguracja zawarta w tym pliku. Jednak w celu usprawnienia jego działania oraz bezpieczeństwa należy ustawić kolejność odpytywania w odpowiedniej kolejności serwera DNS oraz włączenie mechanizmu zabezpieczającego przed podszywaniem się:

order hosts,bind
multi on
nospoof on
spoofalert on
spoof warn

Pierwsza pozycja wskazuje kolejność używania metod szukania adresów hostów, w podanym przykładzie najpierw będzie przeszukiwany plik /etc/hosts, a w drugiej kolejności odpytywane serwery DNS. Drugi wiersz zezwala na zwracanie więcej niż jednego adresu IP z pliku /etc/hosts (o ile przypisano większą liczbę adresów do nazwy). Mechanizm broniący przed spoofingiem definiują ostatnie trzy wiersze. Polega on na dodatkowym odpytaniu hosta próbującego się połączyć z naszą maszyną w celu potwierdzenia jego tożsamości. Jeśli zajdzie taki incydent zostanie on odnotowany w logach systemowych, a podszywający się host zostanie poddany prewencji podszywania.

Więcej informacji: The hosts file, Podręczny serwer DNS

Dnia 02.01.2010

Nowa generacja wirusów: nikt nie jest bezpieczny?

N

owa generacja wirusów: nikt nie jest bezpieczny? Wywiad z Mikko Hypponenem.

Artykuł ten został opublikowany w numerze 3/2006 (17) magazynu hakin9.

Artykuł w formacie PDF

Dnia 01.01.2010

Program [s]uper [u]ser tylko dla wybranych

P

rogram su jest programem umożliwiającym zwykłemu użytkownikowi uzyskanie uprawnień administratora dzięki wpisaniu jego hasła. W celu ograniczenia tej możliwości z zachowaniem poprawnej pracy programu do pewnej, wybranej ilości czy grupy użytkowników powinniśmy stworzyć plik konfiguracyjny /etc/suauth, w którym umieścimy odpowiednie reguły dotyczące uprawnień korzystania z programu SU. Jeśli chcemy umożliwić korzystanie z programu tylko jednemu użytkownikowi np. o loginie agresor to wpis ten powinien wyglądać następująco:

ALL:ALL EXCEPT agresor:DENY

Jeśli pragniemy dodać kolejnych użytkowników do tego przywileju dodajemy ich kolejne identyfikatory po przecinku (agresor, wingzero). Możemy także zezwolić na użytkowanie SU specyficznej grupie np. wheel, w tym przypadku wpis ten przyjmuje następującą postać:

ALL:ALL EXCEPT GROUP wheel:DENY

Teraz tylko użytkownicy systemowo dopisani do grupy wheel będą posiadali możliwość poprawnego używania programu su. Drugi sposób ograniczeń został opisany w artykule “Zasady logowania do systemu.”

Więcej informacji: man su

Dnia 31.12.2009

Współczesne rozwiązania wielosilnikowe

Z

agadnienia związane z bezpieczeństwem systemów komputerowych w przedsiębiorstwach nabrały ogromnego znaczenia w ciągu ostatnich lat. Powodem zaistniałej sytuacji stał się wzrost ilości różnych typów złośliwego oprogramowania oraz metod rozpowszechniania go w sieci Internet.

Artykuł ten został opublikowany w numerze 05/2008 (37) magazynu hakin9.

Artykuł w formacie PDF

Dnia 30.12.2009

Zły czas pracy na konsoli

K

olejnym sposobem ograniczenia logowania się na lokalną konsolę serwera (jeśli w pliku /etc/login.defs opcja: PORTTIME_CHECKS_ENAB posiada ustawioną wartość “yes”) jest program porttime. Plik konfiguracyjny tego programu (/etc/porttime) zawiera listę terminali (tty), loginy użytkowników oraz czas pozwalający im na zalogowanie się na danym terminalu.

Reguły w tym pliku tworzone są poprzez trzy wcześniej wymienione pola oddzielone od siebie dwukropkiem “:“. Jeśli w którymś z pierwszych dwóch pól umieścimy gwiazdkę “*” będzie tyczyła się ona wszystkich trafień, czyli wszystkich użytkowników lub terminali. Trzecie pole składa się ze skrótu nazwy dnia oraz przedziału czasu wyrażanego w godzinach. Oprócz skrótów nazw siedmiu dni możemy także posłużyć się wpisem “Wk” – oznaczającym Weekend oraz “Al” – oznaczającym każdy dzień. Na przykład wpis:

*:agresor:Wk0900-2200

Oznacza, że użytkownik agresor może logować się z lokalnych terminali (np. od tty1 do tty6) w Weekendy od godziny 9:00 rano (AM) do godziny 10:00 wieczorem (PM). W przypadku kiedy chcemy, aby tylko użytkownik agresor, który posiada uprawnienia do stania się administratorem i sam administrator mogli logować się na konsoli serwera w każdym dniu i o każdej porze, a inni użytkownicy nie mają posiadać takiej możliwości to do pliku /etc/porttime dodajemy następujące wpisy:

*:root,agresor:Al0000-2400
*:*:

Powyższy wpis pozwala na dostęp tylko użytkownikowi root oraz agresor na każdą konsolę serwera w każdym czasie. Każdy inny użytkownik pasujący do drugiego wpisu (* – czyli wszyscy) nie posiada dostępu do wszystkich konsol serwera o każdej porze dnia i nocy. Stosując powyższą restrykcje musimy zapewnić dobrą synchronizację czasu na serwerze.

Więcej informacji: man porttime

Dnia 29.12.2009

Okiem wielkiego brata – inwigilacja pracowników w firmie

I

nwigilacja to dyskretne obserwowanie osób albo miejsc przez system monitoringu cyfrowego, system kontroli wejścia i wyjścia, a także przez prywatnych detektywów, policję. Pojęcie to rozszerza jeszcze informatyka o zdalną kontrolę systemów informatycznych.

Artykuł ten został opublikowany w numerze 5/2007 (25) magazynu hakin9.

Artykuł w formacie PDF

Dnia 28.12.2009

Wesołych Świąt!

Przyszłorocznych.

Więc tak: to miał być prezent pod choinkę, ale nie zdążyłem. Jak zwykle. Umówmy się zatem, że oto wprowadzam nową, świecką tradycję: prezent noworoczny. Okazja, jak każda inna, tyle że naród w tych dniach chodzi bardziej napruty, więc i skala zadowolenia z byle czego jakby większa.

Klik. I nie dziękujcie.

Dnia 27.12.2009

Ograniczona konsola dla administratora

Z

azwyczaj nie ma potrzeby wchodzenia bezpośrednio z konsoli na konto root. Na naszej maszynie pracujemy korzystając z konta zwykłego użytkownika, i przełączamy się na konto administratora dopiero wtedy, gdy zaistnieje taka potrzeba – wtedy zazwyczaj korzystamy z polecenia “su” lub “sudo“.

Jeśli pragniemy ograniczyć dostęp do konta superużytkownika, powinniśmy opatrzyć komentarzami wszystkie wpisy w pliku /etc/securetty, co spowoduje całkowitą blokadę logowania się administratora z lokalnej konsoli. Jednak, gdy chcemy posiadać chociaż jedną “działającą” konsolę, która da nam możliwość bezpośredniego dostania się na konto root to pozostawiamy wybrany przez nas wpis bez komentarza np. tty2. Zalecane jest, aby wpisów tych nie było więcej niż dwa. W dodatku dobrze jest jeśli nie jest to pierwsza konsola, którą podczas odchodzenia od serwera powinniśmy zostawiać jako aktywną na monitorze. W przypadku ingerencji w konto administratora przez nieświadomego intruza przy włączonym mechanizmie raportowania nieudanych logowań, będziemy posiadali świadomość próby potencjalnie nieudanego włamania.

Więcej informacji: man securetty

Dnia 23.12.2009

Bezpieczne aplikacja internetowe

D

la wielu mniej zaawansowanych twórców aplikacji webowych projekt kończy się wraz z wyklikaniem w swoim tworze podstawowych przypadków użycia. W efekcie sieć pełna jest witryn dziurawych jak ser szwajcarski. Znaczne zwiększenie bezpieczeństwa aplikacji webowych jest proste. Trzeba tylko wiedzieć, jak to zrobić.

Artykuł ten został opublikowany w numerze 11/2008 (42) magazynu hakin9.

Artykuł w formacie PDF

Dnia 21.12.2009

Blokada [CTRL]+[ALT]+[DEL]

N

asze serwery znajdują się w bardzo dobrze strzeżonych miejscach, z brakiem możliwości dostania się do nich, co najmniej bez posiadania kluczyka do przysłowiowej “szafy”. – Niestety nie wszystkie maszyny mają to szczęście. Dlatego z wielu powodów nie powinniśmy udostępniać każdemu użytkownikowi i “przechodniowi” znajdującemu się przy klawiaturze naszego serwera możliwości przeładowania systemu za pomocą “trzech króli”, czyli kombinacji klawiszy Ctrl+Alt+Delete.

W Slackware funkcję tą możemy zablokować poprzez umieszczenia w pliku /etc/inittab znaku komentarza (#) przed wierszem posiadającym następującą składnię:

ca::ctrlaltdel:/bin/shutdown -t3 -r now

lub w Debianie:

ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

Następnie w celu wprowadzenia zmian należy przeładować init poleceniem: init q. Teraz przeładowanie lub zatrzymanie systemu będzie możliwe poprzez wydanie poleceń: shutdown, halt lub reboot. Powinniśmy zadbać o to, aby dostęp do tych komend posiadały tylko odpowiedzialne osoby. W celu dopuszczenia wyselekcjonowanych użytkowników do używania kombinacji trzech klawiszy należy po wyżej wymienionym wierszu dodać parametr: -a. Tak więc składnia przyjmie postać podobnej do tej z Debiana:

ca::ctrlaltdel:/bin/shutdown -a -t3 -r now

Następnie należy stworzyć plik shutdown.allow, który powinien znaleźć się w katalogu /etc (touch /etc/shutdown.allow). W pliku tym umieszczamy nazwy użytkowników, którzy są upoważnieni do fizycznego restartu serwera (wpisy powinny być tworzone według schematu: użytkownik na jedną linię, czyli jeden pod drugim, a maksymalna liczba użytkowników, którzy mogą się w nim znaleźć wynosi 32). Teraz program shutdown przed wykonaniem czynności restartujących najpierw sprawdzi istnienie pliku shutdown.allow – jeśli on istnieje to nastąpi porównanie w nim zawartych wpisów z zalogowanym użytkownikiem na wirtualnej konsoli (poprzez odczytanie informacji z pliku /var/run/utmp). Jeśli zostanie odnaleziony użytkownik, który rezyduje w pliku autoryzacyjnym programu shutdown restart systemu zostanie wykonany. W przeciwnym wypadku zostanie wyświetlony komunikat: shutdown: no authorized users logged in. Wadą tego ograniczenia jest, iż w przypadku kiedy na lokalnej konsoli serwera jest zalogowanych dwóch użytkowników z czego tylko jeden jest wpisany do pliku shutdown.allow, to drugi może wykorzystać fakt jego obecności na konsoli i zrestartować serwer poprzez użycie danej kombinacji klawiszy.

Więcej informacji: man shutdown

Dnia 20.12.2009

Oracle z punktu widzenia intruza

Z

awodowo nie zajmuję się administracją serwerów Oracle. Moja praca wiąże się raczej z analizowaniem bezpieczeństwa systemów IT (testy penetracyjne, przeglądy konfiguracji). Z tego względu prezentowany materiał przyjmuje raczej punkt widzenia atakującego system niż administratora. Artykuł jest podsumowaniem ponad dwuletnich doświadczeń w testowaniu bezpieczeństwa systemów Oracle. Większość informacji pochodzi ze źródeł powszechnie dostępnych w Internecie.

Artykuł ten został opublikowany w numerze 1/2003 (1) magazynu hakin9.

Artykuł w formacie PDF

Dnia 19.12.2009

Quota – limity przestrzeni dyskowej

Q

uota jest pakietem, który definiuje limity wykorzystania przestrzeni na dysku. Podstawową ideą quoty jest to, że użytkownicy naszego systemu zmuszeni są do ograniczenia swoich zasobów i, co za tym idzie odebranie im ich zdolności do zabierania nieskończonej ilości pamięci dyskowej. Według naszego uznania możemy nałożyć ograniczenia na poszczególnych użytkowników czy wybrane grupy systemowe. Ograniczenia możemy nakładać na dwa sposoby: ilość i-węzłów (czyli plików) jaką może zapisać użytkownik oraz ilość bloków (w kilobajtach) jaką może zapisać użytkownik. Narzucenie takich limitów daje nam komfort przed obawą, że jeden z użytkowników wykorzysta całe dostępne miejsce na partycji, gdzie znajdują się także konta innych użytkowników, co czasami może nawet doprowadzić do błędów podczas ich logowania.

Obsługa quoty została zintegrowana już z jądrem Linuksa od wersji 1.3.8x, także z jej posiadaniem nie powinno być problemu. Jednak, aby mieć możliwość skorzystania z tego pakietu, musimy się upewnić, że jądro naszego systemu potrafi ją obsłużyć – musi lub musiało być skompilowane z zaznaczoną opcją Quota support (CONFIG_QUOTA [y]) – poprzez kompilacje jądra poleceniem “make menuconfig” lub “make xconfig” powinniśmy znaleźć i zaznaczyć menu: [x] Quota support. Teraz wystarczy skompilować oraz zainstalować oprogramowanie pozwalające zarządzać quotą. Jeśli oprogramowanie obsługujące pakiet quoty jest już zainstalowane na naszym systemie (większość dystrybucji Linuksa oferuje możliwość instalacji tego pakietu podczas instalacji samego systemu – w Slackware jest to pakiet quota w sekcji “A” – w systemie Debian – quota oraz dodatkowo quotatool) nie musimy nic więcej robić (fakt ten możemy sprawdzić np. poprzez wydanie komendy quotacheck).

Po spełnieniu wszystkich warunków pozwalających nam na skorzystanie z mechanizmu quoty przyszedł czas na zmodyfikowanie skryptu inicjalizującego nasz system, aby sprawdzał quotę oraz włączał ją podczas startu systemu (w dystrybucji Slackware skrypt /etc/rc.d/rc.M jest standardowo przystosowany do tej funkcji). Oto przykładowy wycinek skryptu, który sam przeszukuje plik /etc/fstab w celu sprawdzenia czy zostały dodane flagi sugerujące uaktywnienie mechanizmu quoty na danej partycji. Jeśli tak – to nastąpi aktywacja limitów dyskowych nałożonych na daną partycję:

if grep -q quota /etc/fstab ; then
  for quotafs in $(awk '/quota/ {print $2}' /etc/fstab) ; do
    /bin/rm -f $quotafs/{a,}quota.{group,user}.new
  done
  if [ -x /sbin/quotacheck ]; then
    echo "Checking filesystem quotas:  /sbin/quotacheck -avugm"
    /sbin/quotacheck -avugm
  fi
  if [ -x /sbin/quotaon ]; then
    echo "Activating filesystem quotas:  /sbin/quotaon -avug"
    /sbin/quotaon -avug
  fi
fi

Główną zasadą jaką musimy przestrzegać podczas włączania quoty – jest to, aby mechanizm ten był uaktywniany dopiero jak systemy plików odczytane z pliku /etc/fstab zostały zamontowane – w innym przypadku mechanizm quoty nie będzie działał. Dlatego skrypt ten powinien znajdować się na końcu pliku inicjalizującego system, lub po sekcji kiedy systemy plików są montowane.

Aktywowanie quoty zaczynamy od edycji pliku /etc/fstab. W zależności od tego czy chcemy nałożyć limit na poszczególnych użytkowników czy na grupę do opcji montowania danej partycji, na której mają być aktywne limity dopisujemy opcję: usrquota (dla poszczególnych użytkowników) lub grpquota (dla poszczególnych grup). Więc, aby możliwe było nałożenie ograniczenia przestrzeni dyskowej na katalogi domowe użytkowników, katalog /home musi znajdować się na oddzielnej partycji. Oto przykładowy wpis aktywujący limity dla poszczególnych użytkowników systemu:

/dev/hda7     /home    ext4     defaults,rw,nosuid,nodev,usrquota     1    1

Oczywiście możemy dodać równocześnie opcję usrquota oraz grpquota. Teraz wystarczy stworzyć plik z danymi o quocie. W zależności od flag jakie dodaliśmy do montowania danej partycji tworzymy plik aquota.user – w przypadku umieszczenia flagi usrquota lub aquota.group – w przypadku umieszczenia flagi grpquota. Jeśli dodaliśmy obydwie flagi tworzymy dwa wymienione pliki. Pliki te powinny należeć do administratora systemu (root) – tylko on powinien posiadać możliwość ich zapisu i odczytu oraz powinny one znajdować się w podstawowym katalogu na partycji, którą chcemy objąć quotą. Czyli w przypadku partycji /home będą to polecenia:

touch /home/quota.user
touch /home/quota.group
chmod 600 /home/quota.*
touch /home/aquota.user
touch /home/aquota.group
chmod 600 /home/aquota.*

Pierwsze trzy polecenia odnoszą się do systemu plików quoty w wersji pierwszej, a kolejne trzy do systemu plików quoty w wersji drugiej – którego aktualnie używają jądra Linuksa od wersji 2.4.x. W zależności jakiej wersji systemu quoty używamy należy wykonać odpowiednie komendy – aby zachować kompatybilność oraz zapobiec zbędnym komunikatom programu quotacheck można stworzyć wszystkie cztery pliki, później sprawdzając, które pliki są wykorzystywane.

Po tak wykonanych zabiegach wykonujemy restart systemu w celu wprowadzenia zmian jakich dokonaliśmy. Jeśli podczas startu systemu w sekcji odpowiedzialnej za zamontowanie “normalnej” quoty spotkamy się z komunikatem:

quotacheck: Your kernel probably supports journaled quota but you are
not using it. Consider switching to journaled quota to avoid running
quotacheck after an unclean shutdown.

Możemy pokusić się o aktywację mechanizmu quoty z obsługą księgowania. Zaletą quoty z księgowaniem jest fakt, iż nie wymaga ona uruchamiania programu quotacheck po awaryjnym zamknięciu systemu (działa ona dla systemu plików ext3 oraz ext4). W tym celu wystarczy nasz wcześniejszy wpis dla partycji /home zmodyfikować na:

/dev/hda7     /home    ext4     defaults,rw,nosuid,nodev,usrjquota=aquota.user,jqfmt=vfsv0     1    1

Teraz jesteśmy gotowi, aby przypisać limity użytkownikom. W celu ograniczenia wielkości przestrzeni dyskowej dla np. jednego użytkownika o loginie agresor wydajemy polecenie: “edquota -u agresor“. W tym momencie w oknie edytora widzimy informacje o całkowitej liczbie aktualnie używanych przez użytkownika bloków (w kilobajtach / KB ) oraz aktualnej liczby plików jaką użytkownik posiada na dysku (inodes):

/dev/hda7: blocks in use: 5027, limits (soft = 0, hard = 0)
inodes in use: 27, limits (soft = 0, hard = 0)

Limity wielkości bloków (KB) oraz ilości plików nadajemy poprzez modyfikacje ich początkowych wartości. Istnieją dwa rodzaje ograniczeń: pierwszy to soft – jest to limit, który określa maksymalną objętość dysku jaką może wykorzystać użytkownik – limit ten może być przekroczony jeśli aktywna jest opcja grace period – czyli opcja, która określa czas przez który użytkownik może nadal zapisywać dane w stanie przekroczenia limitu. Drugim rodzajem jest hard (działa jedynie przy ustawieniu grace period) – określa absolutny limit na dysku, którego dany użytkownik nie może przekroczyć. Na przykład chcemy nałożyć limity dyskowe, które będą pozwalały użytkownikowi zapisać dane o objętości 5 MB (5120 KB) oraz umożliwiały posiadanie 500 plików:

/dev/hda7: blocks in use: 5027, limits (soft = 5120, hard = 0)
inodes in use: 27, limits (soft = 500, hard = 0)

Standardowo grace period nie jest aktywne (czyli ustawione na 0), dlatego limitu (soft), który ustaliliśmy nie da się przekroczyć. Aby ukazać działanie opcji grace period stwórzmy limit pozwalający użytkownikowi zapisać dane o objętości 5 MB, posiadać 500 plików, lecz tylko przez 5 dni będzie on mógł posiadać oraz zapisywać dane o objętości 7 MB (7168 KB) oraz posiadać 1000 plików:

/dev/hda7: blocks in use: 5027, limits (soft = 5120, hard = 7168)
inodes in use: 27, limits (soft = 500, hard = 1000)

Następnie wydajemy polecenie: “edquota -t” w celu określenia długości czasu, w którym będzie możliwy zapis danych przez użytkownika po przekroczeniu soft limitu:

Time units may be: days, hours, minutes, or seconds
Grace period before enforcing soft limits for users:
/dev/hda7: block grace period: 5 days, file grace period: 5 days

Takie ustawienie po przekroczeniu użytkownika 5 MB spowoduje, automatyczne uaktywnienie się hard limitu pozwalającego mu zapisać tylko i wyłącznie 7 MB oraz ograniczy jego przekroczenie limitu do 5 dni. Po 5 dniach użytkownik nie będzie w stanie zapisywać żadnych dodatkowych danych dopóki nie wróci do stanu określonego przez soft limit czyli mniejszego lub równego 5 MB. Podobnie ustawiamy quotę dla całej grupy z tą różnicą, że limity będą się tyczyły nie jednego użytkownika lecz wszystkich, którzy należą do danej grupy. W tym celu wydajemy polecenie: “edquota -g grupa, a jeśli chcemy zobaczyć wykaz wszystkich ustawień quoty wydajemy polecenie: “repquota -a“.
Bonus:Jeśli chcemy, aby użytkownik np. firedoll posiadał takie same ustawienia quoty jak użytkownik agresor to wystarczy, że wydamy polecenie: “edquota -p agresor firedoll“. Dodatkowo możemy spowodować, by quota była uaktualniana np. co dzień, a nie co restart systemu poprzez dodanie następującego skryptu do ścieżki crontaba znajdującej się w /etc/cron.daily/:

#!/bin/sh
/sbin/quotaoff -a
/sbin/quotacheck -avugmb
/sbin/quotaon -avug
I-węzły- (ang. i-node) to struktura danych używana w linuksowych systemach plików do opisu pliku. W skład i-węzła wchodzi:

- typ pliku: zwykły, katalog lub plik urządzeń,
- identyfikator UID właściciela,
- wykaz bloków dyskowych i ich fragmentów tworzących plik.

I-węzeł możemy traktować jako swoisty identyfikator pliku na dysku, którym system posługuje się w celu odnalezienia żądanego pliku. Każdy plik na danej partycji ma przyporządkowany tylko jeden i-węzeł. Natomiast blok dyskowy to przechowująca informacje część przestrzeni na partycji. Rozmiar bloku definiowany jest przez użytkownika podczas podziału dysku na partycje. Może jednak zostać zmieniony przy użyciu programów modyfikujących dany system plików; w przeciwieństwie do i-węzłów, wiele bloków może należeć do jednego pliku.

Więcej informacji: Quota mini-HOWTO – /usr/doc/Linux-mini-HOWTOs/Quota

Dnia 17.12.2009

Entropia – pomiar i zastosowanie

E

ntropia, rozumiana jako wielkość losowości pewnych danych, może służyć wprawnemu badaczowi jako narzędzie pomocne w wyszukiwaniu ukrytych danych oraz interpretacji budowy nieznanych plików. Niniejszy artykuł ma na celu przedstawić Czytelnikowi zagadnienia związane z entropią.

Artykuł ten został opublikowany w numerze 3/2008 (35) magazynu hakin9.

Artykuł w formacie PDF

Dnia 15.12.2009

Publiczne serwery DNS Google

T

rzeciego grudnia 2009 roku firma Google oddała własne serwery DNS do publicznego użytku. Jest to projekt bardzo zbliżony do OpenDNS. Ma on zapewnić jego użytkownikom szybkość odpowiedzi resolwerów DNS, ich bezpieczeństwo oraz niezawodność w działaniu. Szybkość i niezawodność osiągnięto dzięki zapewnieniu odpowiedniej obsługi klastrów złożonych z serwerów DNS; równoważeniu obciążenia (ang. load-balancing) zapytań do resolwerów DNS jak i zastosowaniu mechanizmu aktywnego prefetchingu.

Szybkość odpowiedzi:

Pod pojęciem odpowiedniej obsługi klastrów Google DNS, tak na prawdę kryje się odpowiednia konfiguracja maszyn składających się na klaster: serwery buforujące zapytania DNS (ang. caching dns) muszą wykonywać znacznie droższe w eksploatacji operacje niż serwery autorytatywne, gdyż wiele odpowiedzi DNS nie może być podawanych z pamięci; zamiast tego wymagają komunikacji z innymi serwerami nazw, a ten sposób pracy wymaga wiele ruchu sieciowego. Jeśli resolwery nie są odpowiednio przygotowane do pracy sieciowej – ich obciążenie ma negatywny wpływ na wydajność oraz szybkość obsługi klientów. Wiele pakietów jest traconych, wiele musi być retransmitowanych, zapytania są kolejkowane itd. Wszystkie te czynniki prowadzą do opóźnień obsługi. Ponadto publiczne / otwarte serwery DNS są bardziej narażone na ataki typu dns spoofing, cache poisoning oraz DDoS. Dlatego ważnym czynnikiem dla serwerów DNS jest umieszczenie ich w wysoko wydajnej infrastrukturze sieciowej. Umożliwia to obsługę ataków DDoS, dla których jednym ze skutecznych rozwiązań jest rozproszenie ich na wiele maszyn. Jednocześnie istotnym zabiegiem jest nie zmniejszanie prawdopodobieństwa trafienia pamięci podręcznej wraz z dodawaniem kolejnych serwerów DNS – wymaga to wdrożenia skutecznej polityki równoważenia obciążenia, którą Google rozwiązało następująco:

- skalowanie infrastruktury resolwerów poprzez dodawanie kolejnych maszyn może rzeczywiście odbić się rykoszetem i zmniejszyć prawdopodobieństwo trafień pamięci podręcznej serwerów DNS, jeśli nie zostanie zastosowana odpowiednia polityka równoważenia obciążenia. W typowych środowiskach produkcyjnych wiele maszyn umieszczonych jest za mechanizmem rozkładania obciążenia, który po równo rozdziela ruch do każdej maszyny używając prostego algorytmu karuzelowego (ang. round robin). Rezultatem takiego działania jest to, że każda maszyna ma swoją, własną niezależnie zbuforowaną pamięć, która jest niedostępna dla reszty serwerów DNS. Jeśli każde przychodzące zapytanie jest rozprowadzane do losowo wybranej maszyny – w zależności od rodzaju ruchu sieciowego – efektywna liczba nietrafień pamięci podręcznej może zostać proporcjonalnie zwiększona. Dla przykładu: domeny z długim TTL (ang. Time To Live – czasem ważności rekordów w domenie wyrażonym w sekundach), o które często występują zapytania posiadają zwiększone prawdopodobieństwo nietrafień pamięci podręcznej poprzez liczbę maszyn w klastrze. Analogicznie – dla domen z bardzo krótkim TTL, o które zapytania występują bardzo rzadko lub wyniki pochodzą z niezbuforowanych odpowiedzi (0 TTL lub błędów) – prawdopodobieństwo nietrafień pamięci podręcznej nie jest na prawdę uzależnione od ilości maszyn DNS w klastrze.

By zwiększyć procent trafień dla bardzo popularnych domen ważne jest by poddać równoważeniu obciążenia serwery, których pamięć podręczna jest nie pofragmentowana (oddzielona od innych). Istnieją dwa sposoby, aby tego dokonać:

  • ‘wszym jest wykorzystanie globalnej pamięci podręcznej, która jest współdzielona przez wszystkie maszyny.
  • ‘gim jest podział ogólnej pamięci podręcznej na domeny – tak by zapytania dla wybranej domeny zawsze trafiały do tej samej maszyny.

W przypadku publicznych serwerów Google DNS wykorzystywane są obydwa podejścia. Jedna pula maszyn współdzieli pewną małą część globalnej pamięci podręcznej dla najbardziej popularnych domen. Jeśli odpowiedź na zapytanie nie może zostać dostarczona z współdzielonej pamięci podręcznej tych maszyn – zapytanie jest wysyłane do innego zespołu maszyn, które dzielą pamięć podręczną mniej popularnych domen. Wszystkie zapytania dla tej samej domeny są wysyłane do tej samej maszyny, gdzie została już / lub nie zbuforowana.

Prefetching, czyli wcześniejsze wczytanie z dysku plików potrzebnych do działania programu pozwala skrócić czas uruchomienia programu, jak również czas uruchomienia całego systemu. W systemach operacyjnych taki mechanizm jest obecny od dawna. W przypadku serwerów DNS prefetching polega na na ciągłym, asynchronicznym odświeżaniu rekordów w pamięci podręcznej. Dzięki takiemu rozwiązaniu nie powinno być sytuacji, w której klient odpytuje o rekord domeny, który już wygasł i nie ma go w pamięci podręcznej. Wówczas konieczne jest odświeżenie rekordu przez odpytywane serwery DNS, a to wprowadza dodatkowe opóźnienia. Google nastawiło się również na geolokalizację tj. w zależności z jakiego kraju korzystamy z jego serwerów DNS będziemy kierowani do geograficznie najbliższego data center utrzymującego Google DNS. Ma to wpłynąć głównie na zlikwidowanie opóźnień przy kierowaniu ruchu przez niepotrzebne węzły sieciowe. W tym przypadku należy mieć na uwadze fakt, iż mimo zastosowaniu tylu technik optymalizacji publiczne serwery Google nadal mogą być wolniejsze od serwerów, które dostarcza nam nasz ISP (ang. Internet Service Provider – Dostawca Internetu) – właśnie ze względu na odległość geograficzną, która głównie wiąże się z ilością routerów do pokonania. Z badań przeprowadzonych przez serwis Heise Online wynika, że pakiety (zapytania) polskich użytkowników wędrujące do serwerów DNS Google’a muszą pokonać trasę zawierającą około 12 węzłów i składającą się z około 8 podsieci należących do czterech różnych operatorów – przyjmując za punkt początkowy sieć Telekomunikacji Polskiej.

Trafienie pamięci podręcznej- Trafienie pamięci podręcznej występuje, jeśli buforowana zawartość wpisów DNS pasuje do zapytania zgłaszanego przez klienta, a brak trafienia pamięci podręcznej występuje, jeśli buforowana zawartość wpisów DNS nie pasuje do zapytania zgłaszanego przez klienta. Jeśli serwer DNS jest dostępny, a zapytanie trafiło w pamięć podręczną – odpowiedź na zapytanie klienta wysyłana jest od razu. Jeśli serwer DNS jest dostępny, lecz nie wystąpiło trafienie w jego pamięci podręcznej – musi wykonać on zapytanie do innych serwerów DNS, aby zwrócić odpowiedź na zapytanie klienta. Jeśli serwer DNS jest niedostępny lub nie może dostarczyć żądanej zawartości, serwer ten zwraca klientowi komunikat o błędzie z informacją o nieodnalezieniu zawartości.

Bezpieczeństwo:

Ze względu na otwarty i rozproszony projekt jakim jest usługa DNS oraz fakt, iż korzysta on z protokołu UDP (ang. User Datagram Protocol) powoduje, że jest podatny na różne formy ataków. Publiczne resolwery DNS pozwalające na rekursywne pytania, tym bardziej. W dodatku nie ograniczają one przychodzących pakietów do dopuszczalnego zakresu adresów IP np. sieci lokalnej. Dlatego Google postawiło nacisk głównie na ochronę przed dwoma rodzajami ataków:

  • Ataki podszywania się (ang. dns spoofing) prowadzące do zatruwania pamięci podręcznej DNS (wcześniej wspomniane dns cache poisoning) oraz inne rodzaje fałszowania odpowiedzi, których celem jest kierowanie użytkowników z legalnych witryn do stron zawierających szkodliwe i złośliwe oprogramowanie (ang. malware), w tym te odkryte przez Dana Kaminsky’ego, w których agresor przejmuje autorytatywną kontrolę nad całą strefą DNS.
  • Ataki Denial of Service (DoS) lub Distributed Denial of Service (DDoS), które wymierzone są prosto w serwery DNS jak również do przeprowadzania dalszych ataków na innych systemach. Ataki, które wykorzystują serwery DNS do przeprowadzenia ataków DDoS na innych systemach poprzez wywołanie bardzo dużej ilości odpowiedzi na zapytania są znane jako “wzmocnienia ataku” (ang. amplification attacks).

Jak również postawiło nacisk na kontrolę upływu ważności oraz odrzucanie podejrzanych odpowiedzi innych serwerów nazw, w tym:

  • nie parsowalne lub zniekształcone odpowiedzi,
  • odpowiedzi, których ID, źródłowe IP, źródłowy port lub nazwa zgłoszenia są niezgodne z parametrami oryginalnego żądania,
  • rekordy, które nie są powiązane z żądaniem,
  • rekordy odpowiedzi, dla których Google nie jest w stanie zrekonstruować łańcuch CNAME,
  • rekordy, dla których odpowiadający serwer nazw nie jest wiarogodny (określenie wiarygodności serwera odbywa się poprzez sprawdzenie jego pozycji w delegacji dla wybranej domeny, zapamiętanie jej w pamięci podręcznej serwerów Google, a następnie porównywanie jej z każdym serwerem nadsyłającym odpowiedź).

Jeśli chodzi o ochronę przed atakami “podszywania się” – zastosowano następujące mechanizmy zwiększające entropię, utrudniającą atakującemu odgadnięcie ID zapytania, numer portu UDP, adresu IP (z którego pochodzi odpowiedź) oraz nazwy zapytania:

  • Google DNS nie używa standardowego numeru portu odpowiedzi 53 (UDP), lecz dla każdego zapytania losuje inny numer portu (używając 15 bitów, które pozwalają na wykorzystanie około 32.000 losowych numerów portów),
  • w sytuacji, gdy do odpowiedzi na dane zapytanie zgłasza się większa liczba serwerów DNS z wybranej strefy, usługa Google określa losowo tylko jeden z nich,
  • wprowadzenie losowej zmiany wielkości liter w zapytaniach – technika znana jako “0×20″, ponieważ właśnie ten bit służy do określania wielkości liter w US-ASCII (przy czym podczas tłumaczenia nazw różnice te nie mają żadnego znaczenia),
  • dodawanie etykiet do zapytań kierowanych do głównych serwerów nazw np. zapytanie o entriih-f10r3.www.google.com powinno zwrócić identyczną odpowiedź, co zapytanie o www.google.com,
  • usuwanie zduplikowanych zapytań, w celu uniknięcia ataku urodzinowego, czyli Google DNS nigdy nie pozwoli na więcej niż jedno żądanie dla tej samej nazwy, typie oraz docelowym adresie IP.

W przypadku ochrony przed atakami DoS, Google DNS wprowadziło mechanizm ograniczający lub “dławiący” ilość i szybkość odpowiedzi. Ma on na celu ochronę zarówno innych serwerów DNS jak i samych klientów przed atakami DoS oraz DDoS (również w wersji z wzmocnieniem) poprzez wykorzystanie serwerów Google. Jeśli zapytania z określonego adresu IP konsekwentnie będą przekraczać maksymalną wartość QPS (ang. Queries Per Second – zapytań na sekundę) lub przydzieloną, średnią przepustowość (sporadyczna, większa liczba odpowiedzi będzie przepuszczana) usługa Google DNS będzie zwracała błędne odpowiedzi lub nawet żadnych.

Opisana usługa Google DNS jest osiągalna pod następującymi adresami IP:

DNS1: 8.8.8.8
DNS2: 8.8.4.4

Nawiązując do wcześniej wspomnianej usługi OpenDNS – Google nie umożliwia żadnych przekierowań, blokowania stron czy nakładania filtrów. Wszystkie strony są w pełni dostępne. Ponadto Gigant z Mountain View uspokaja swoich sceptyków, jeśli chodzi o ochronę prywatności – gwarantując zapisywanie jedynie danych niezbędnych do rozwiązywania problemów natury technicznej – żadne dane pozwalające na zidentyfikowanie użytkownika nie są gromadzone.

Więcej informacji: Google Public DNS, Domain Name System, Round Robin

Dnia 11.12.2009

Potrójne wydanie od Suna

Sun przygotował zbiorcze wydanie nowych wersji trzech ważnych produktów: Java EE 6 GlassFish v3 NetBeans 6.8


JAVA exPress #6

Nowy numer do ściągnięcia. Polecam artykuł Mateusza o Grails Object Relational Mapping.


Dnia 04.12.2009

JPA: persist() vs. merge()

W trakcie pisania kawałka kodu wykorzystującego JPA natrafiłem na następującą sytuację. Z innej warstwy aplikacji otrzymywałem nowy obiekt, którego jeden z atrybutów był obiektem zapisanym już wcześniej w bazie danych. Jednak był on w stanie detached i należałoby go włączyć do persistence context przed zapisaniem głównego obiektu. class A { // nowy obiekt, bez ustawionego id   [...]


Programy diagnostyczno-narzędziowe do sieci TCP/IP w Windows

W

łączamy komputer i po krótszej lub dłuższej chwili związanej z ładowaniem systemu operacyjnego wita nas pulpit ze znajomą ikonką przeglądarki internetowej. Uruchamiamy zatem przeglądarkę i wpisujemy adres strony WWW aby po chwili cieszyć się lekturą zawartości naszych ulubionych stron… A teraz pytanie: co działo się od momentu włączenia zasilania do chwili, kiedy w okienku przeglądarki zaczęły pojawiać się obrazki i napisy — i co ewentualnie mogło pójść źle? Przyjmijmy, że mamy zainstalowany system MS Windows 2000 Professional, a do Internetu przyłączeni jesteśmy za pośrednictwem sieci lokalnej zbudowanej w oparciu o standardowy ethernet i że korzystamy z usług serwera DNS znajdującego się gdzieś u naszego providera. Żeby było łatwiej w odpowiedzi możemy pominąć rozważania związane z ładowaniem systemu operacyjnego.

Artykuł ten został opublikowany w numerze 1/2003 (1) magazynu hakin9.

Artykuł w formacie PDF

Dnia 03.12.2009

Repozytorium Mavena z db4o

Obiektowej bazy danych db4o do niedawna nie można było znaleźć jako zależności w oficjalnym repozytorium Mavena. Żeby z niej skorzystać w swoich projektach, należało wcześniej zainstalować ją sobie lokalnie. Twórcy db4o ułatwili nam życie i udostępnili repozytorium z artefaktami bazy. Aby skorzystać z tego dobrodziejstwa należy dopisać poniższe linijki do pliku pom.xml: <repositories> <repository> [...]


Sysinternals – zestaw narzędzi dla administratorów

Z

witryny Technet firmy Microsoft pobrać można zestaw narzędzi dla administratorów stworzonych przez Marka Russinovicha (twórcy strony Sysinternals od 1996 roku, obecnie pracownika koncernu z Redmond), które dotychczas dostępne były jako pojedyncze pliki.

Od lat narzędzia rozwijane przez Marka doceniane są na świecie przez profesjonalistów IT oraz administratorów pracujących z systemami okienkowymi koncernu z Redmond. Niewielkie rozmiary oraz łatwość użycia to główne przyczyny tak dużej popularności narzędzi Sysinternals. W skład pakietu wchodzą narzędzia do monitorowania i analizowania: dysku, sieci, procesów, bezpieczeństwa systemu, które znacznie ułatwiają pracę administratorom jak i osobom zajmującym się helpdeskiem.

Więcej informacji: Sysinternals

Dnia 02.12.2009

Skuteczna obrona przed rootkitami

G

łośno o rootkitach zaczęło się mówić od czasu skandalu w roku 2005. Ujawniono wtedy, że firma Sony BMG Music Entertaiment do ochrony praw własności wykorzystała rootkita (aries.sys) umieszczonego w oprogramowaniu XCP Content Protection DRM. Tak naprawdę rootkity zaczęły się pojawiać w systemach komputerowych w połowie lat 90-tych XX wieku.

Artykuł ten został opublikowany w numerze 11/2007 (31) magazynu hakin9.

Artykuł w formacie PDF

Dnia 01.12.2009

Jak popsuć Linuksa (administrator vs użytkownik)

J

esteś początkującym użytkownikiem Linuksa? Jako administrator możesz zrobić, co chcesz, wliczając w to, że możesz przyśpieszyć wypadki przy pracy z systemem. Na przykład wydaj to polecenie jako root (lecz pierw zastanów się nad jego konsekwencją – i czy na pewno chcesz zawiesić swój system):

cp /dev/zero /dev/mem

Jako root, możesz również wykasować wszystkie dane w swoim systemie za pomocą niewinnie wyglądającego jedno-liniowca (nie wykonuj tej komendy, chyba że planujesz reinstalację systemu!):

rm -fr /

Ta prezentacja nie ma na celu ukazania jak łatwo rozbić Linuksa w bitowe kawałki, ale jak wielką i kompletną władzę posiada administrator tego systemu. Możemy zrobić niezłe zamieszanie w MS Windows tylko poprzez usunięcie paru plików z katalogu C:\WINDOWS lub C:\WINDOWS\SYSTEM. W aspekcie separacji kont administratora i użytkownika – Linux posiada wielkie rozróżnienie, dzięki czemu zwykli użytkownicy są w stanie operować wyłącznie na plikach do których mają przyznane prawa, i których są właścicielami – to samo tyczy się programów, które można uruchamiać tylko z określonych obszarów systemowych. Oddzielenie kont administracyjnych od użytkowych zwiększa złożoność systemu w pozytywnym tego słowa znaczeniu, a także czyni go naprawdę wielodostępnym. Jest to zupełnie inne podejście niż w starszych systemach MS Windows. Politykę nowszych systemów Windows, Microsoft aktualnie przenosi bardziej w kierunku uniksowego podejścia. Jak mówi stare mądre przysłowie: “Ci, którzy nie znają Uniksa są skazani na to by go ponownie odkryć.” Konkluzja: nie należy używać konta administratora do codziennej pracy z systemem, a jako pierwsze polecenie administracyjne – należy dodać do systemu standardowe konto użytkownika, wykorzystując je do zbierania doświadczenia w regularnej pracy z Linuksem. Konto administratora w stacji roboczej powinno być wykorzystywane tylko do przeprowadzania konfiguracji systemu, a w serwerze – do konfiguracji oraz czynności administracyjnych. Jako root nigdy nie należy uruchamiać programów, których przeznaczenia i działania się nie zna; przynajmniej nie na maszynie, której używa się do produktywnej pracy. Nawet przeglądanie Sieci jako administrator nie godzi się całkowicie z pojęciem bezpieczeństwa. Na początku oczywiście należy eksperymentować i bawić różnymi funkcjami (jako root i nie root), przeprowadzać konfigurację – by w przyszłości móc przewidzieć różne zachowanie systemu, a przede wszystkim wykonywać rzeczy, które się rozumie, a gdy już czujemy się na siłach przeinstalować system by przystąpić do normalnej pracy (podczas której oczywiście dalej uczymy się nowych funkcji lecz z bardziej wyrafinowanym podejściem). Linux jest systemem, który raz, a dobrze zainstalowany na dobrym sprzęcie potrafi legendarnie działać na nim przez miesiące, a nawet lata. Jako początkujący użytkownik, możesz być prawie pewnym, że dziwne zachowanie systemu jest rezultatem Twojego działania jako administrator lub wadliwego sprzętu ;-)

Więcej informacji: Linux Newbie Administrator Guide

Dnia 30.11.2009

Podsłuch elektromagnetyczny

W

mediach co rusz słyszymy, że ktoś kogoś podsłuchał. Cały ten szum podsłuchiwania dotyczy raczej specjalizowanych urządzeń podsłuchowych, mini-nadajników zwanych pluskwami – lecz to nie jedyny rodzaj podsłuchu obecny w otaczającym nas świecie. Nie należy zapominać, że podsłuchać można nie tylko człowieka, ale także komputer i to, co w nim najcenniejsze dla właściciela.

Artykuł ten został opublikowany w numerze 3/2008 (35) magazynu hakin9.

Artykuł w formacie PDF

Dnia 29.11.2009

Podział łącza przez ominięcie blokady TTL

W

iele mniejszych i “domowych” ISP blokuje dalszy podział łącza przez użytkowników poprzez ustawienie odpowiednio małej wartości TTL (ang. Time To Live), tak by dochodząc do naszego komputera wynosiła ona 1, co oznacza, że pakiety z naszego komputera / routera nie mogą zostać przekazane dalej.

Prawidłowość ta opiera się na prostej zasadzie działania sieci, w której każdy kolejny router IP na trasie zmniejsza TTL przekazywanego pakietu o jeden. Jeśli router / komputer otrzyma pakiet z TTL równym 1, odrzuci go i usunie z sieci. W celu sprawdzenia, czy blokada taka została zastosowana w naszym wypadku wystarczy użyć polecenia ping, które dostarczy nam informacji o wartości TTL:

ping www.slackware.com

Jeśli zwracanymi wartościami TTL będą 1′dynki – pakiety dochodzące do naszego routera / komputera nie mogą być dalej przesyłane. W celu ominięcia tej blokady należy zwiększyć wartość TTL przychodzących pakietów co najmniej o 1. W tym wypadku wystarczy dodać poniższe linijki do pliku /etc/rc.d/rc.firewall:

iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-inc 1
iptables -t mangle -A POSTROUTING -o eth0 -j TTL --ttl-inc 1

Możemy także podnieść TTL na wybranych portach TCP:

iptables -t mangle -A PREROUTING -p TCP --dport 33434:33542 -j TTL --ttl-inc 1

Lub ustawić stałą wartość TTL na 64:

iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 64

Gdzie eth0 jest interfejsem podłączonym do Internetu.

Więcej informacji: Netfilter extensions HOWTO

Dnia 28.11.2009

Poznaj swój komputer – oczami intruza

W

Sieci jeszcze bardziej niż w życiu realnym należy chronić wszelkie informacje dotyczące naszej osoby, firmy, działań, kierunków rozwoju… Dbać o te wszystkie dane muszą ludzie, którym je powierzamy. Dlatego zadziwiająca jest beztroska większości użytkowników Internetu w kwestiach bezpieczeństwa i ochrony wrażliwych danych.

Artykuł ten został opublikowany w numerze 12/2007 (32) magazynu hakin9.

Artykuł w formacie PDF

Dnia 27.11.2009

Resetowanie hasła administratora

N

ajprostszym sposobem jest ponowne uruchomienie systemu w trybie single. Jednak w wielu przypadkach i tak zostaniemy poproszeni o podanie hasła administratora (Slackware i Arch jak i pewnie inne dystrybucje). W tryb single możemy wprowadzić system poprzez dodanie do opcji bootowania parametr “single” w bootloaderze LILO:

Linux single

Jeśli używamy bootloadera GRUB, musimy na początku wybrać odpowiednie jądro podświetlając jego menu oraz nacisnąć klawisz “E”. Wybrać linię zaczynającą się od frazy “kernel” kolejny raz naciskając klawisz “E”. Należy dodać frazę “single” (bez cudzysłowu) na końcu wiersza – nacisnąć spację oraz wpisać: single. Naciśnięcie Enter spowoduje wyjście z trybu edycji. Powracając do ekranu GRUBa naciskamy “B”, aby wystartować system w trybie single. Kiedy system się uruchomi należy zalogować się jako root (o ile nie zostaniemy poproszeni o hasło) oraz użyć komendy passwd do zmiany hasła. Drugim sposobem jest użycie parametru

init=/bin/bash

do wystartowania systemu. Oczywiście przed tym parametrem należy podać nazwę wybranego jądra systemu np. Linux init=/bin/bash. W tego rodzaju rozruchu główna partycja zostanie zamontowanie w trybie tylko do odczytu, dlatego należy ją przemontować do trybu zapisu i odczytu, następnie użyć komendy zmiany hasła oraz zrestartować system:

mount -o remount,rw /
passwd
sync; mount -o remount,ro /
reboot

Należy pamiętać, iż w sytuacji, gdy podczas rozruchu systemu korzystamy z initrd (który posiada np. sterowniki obsługi systemu plików, bądź kontrolera dysków) podając parametr init=/bin/bash nie załadujemy sterowników i nie uruchomimy systemu (podziękowania dla Borysa Łąckiego za przypomnienie). Trzecim sposobem jest uruchomienie komputera za pomocą LiveCD (np. Slax lub Knoppix). Po odpaleniu systemu należy zamontować główną partycję w danym punkcie montowania, użyć środowiska chroot i zmienić hasło lub poddać edycji plik /etc/shadow w celu jego usunięcia:

mkdir /mnt/recovery
mount -o rw /dev/hda1 /mnt/recovery
chroot /mnt/recovery /bin/bash
passwd
exit
reboot

Więcej informacji: Reset a Lost Root Password, Knoppix, Slax

Dnia 26.11.2009

Przegląd wybranych metod niwelowania ograniczeń sieci lokalnych

I

stnieje wiele aplikacji, które do działania potrzebują publicznego adresu IP. Jest szereg sposobów, aby umożliwić użytkownikom wewnątrz sieci lokalnych korzystanie ze wszystkich zalet publicznego IP. Można powiedzieć, że istnieje pewnego rodzaju walka pomiędzy administratorami sieci komputerowych, a ich użytkownikami.

Artykuł ten został opublikowany w numerze 04/2007 (24) magazynu hakin9.

Artykuł w formacie PDF

Dnia 25.11.2009

Aktywacja Numlock

W

celu aktywowania klawiatury numerycznej podczas startu systemu Linux dla dowolnej ilości lokalnych konsol wystarczy do pliku lokalnego demona /etc/rc.d/rc.local dodać następujący skrypt inicjujący aktywację:

# Aktywacja numlocka
for i in 1 2 3 4 5 6; do
/usr/bin/setleds -D +num  /dev/tty${i} > /dev/null
done

Jeśli posiadamy więcej lub mniej niż 6 konsol to wstawiamy odpowiedni ciąg liczb po słowie kluczowym “in” (za zwiększanie / zmniejszanie liczby konsol lokalnych odpowiedzialny jest plik /etc/inittab, w którym znajdują się wpisy dotyczące ilości konsol w trybie wielo-użytkowym (multiuser) np. poprzez opatrzenie znakiem komentarza linii: c5:1235:respawn:/sbin/agetty 38400 tty5 linux – redukujemy ilość konsol do 4 analogiczne możemy zwiększyć ich ilość poprzez dodanie kolejnego wpisu, którego wartość jest zwiększona o 1 pod ostatnim wpisem np.: c6:12345:respawn:/sbin/agetty 38400 tty5 linux – przez, co zwiększamy ich ilość do 6).

Więcej informacji: www.userlocal.com

Dnia 23.11.2009

Atak na Bluetooth

B

luetooth jest technologią, która powstała by ułatwić nasze zdolności komunikowania się. Okazał się jednak także technologią nadającą się do kradzieży danych. W tym artykule przedstawimy Wam jak wykorzystać jego słabe punkty.

Artykuł ten został opublikowany w numerze 3/2007 (23) magazynu hakin9.

Artykuł w formacie PDF

Dnia 22.11.2009

Prawa Nowych Technologii

Odpowiedzialność karna za włamanie do systemu komputerowego:

W

yobraźmy sobie następujący scenariusz – Firma “Edytory” S.A. opracowuje kolejną wersję popularnego edytora tekstu. Intruz postanawia zdobyć program wraz z dokumentacją, a następnie wyprodukować pirackie kopie programu. Jako cel ataku wybiera prywatny komputer szefa firmy. Do włamania używa specjalnego programu łączącego się z komputerem ofiary i próbującego uzyskać dostęp do systemu poprzez podstawienie kolejnych haseł. Intruz ma wiele szczęścia i już po kilku godzinach poznaje hasło dostępu do komputera ofiary. Inwigiluje system nie znajdując jednak interesującego go programu. Kontynuując atak przesyła na adres e-mail biura firmy komputerowej list zawierający konia trojańskiego. Roztargniona sekretarka “daje się nabrać” i instaluje ukrytego w załączniku konia trojańskiego na firmowym serwerze. Intruz uzyskuje szeroki dostęp do systemu, zapoznaje się z dokumentacją programu, czyta firmową pocztę i stara się ustalić stopień zaawansowania prac nad programem. Kiedy jest już pewien, że dobiegły one końca, używa kolejnych funkcji konia trojańskiego i kopiuje program na dysk swojego komputera. Następnie wprowadza do systemu komputerowego firmy “Edytory” S.A. wirusa niszczącego dane zapisane na serwerze. System komputerowy firmy zostaje sparaliżowany na wiele godzin. Żądny popularności włamywacz zmienia firmową stronę WWW, zamieszczając na niej informacje o włamaniu.

     W oparciu o powyższą hipotetyczną historię chciałbym przedstawić odpowiedzialność sprawcy na gruncie przepisów kodeksu karnego, kodeksu cywilnego oraz prawa autorskiego. Włamanie do systemu komputerowego, penetracja systemu oraz kopiowanie i niszczenie zgromadzonych w nim danych stanowi naruszenie szeregu przepisów prawa.

Odpowiedzialność karna – Pierwsze włamanie:

     Pierwszym krokiem intruza jest złamanie hasła broniącego dostępu do prywatnego komputera szefa firmy. Mimo wnikliwej penetracji systemu atakujący nie znajduje jednak interesujących go danych. Należy zastanowić się, czy taka działalność może zostać uznana za tzw. przestępstwo hackingu, o którym mowa w art. 267 par. 1 k.k. Zgodnie z tym artykułem odpowiedzialność karną będzie ponosił sprawca, który przełamując elektroniczne, magnetyczne albo inne szczególne zabezpieczenia, uzyskał bez uprawnienia informację dla niego nie przeznaczoną. Warunkiem postawienia agresorowi zarzutu naruszenia art. 267 par. 1 k.k. jest po pierwsze – przełamanie “szczególnych zabezpieczeń” chroniących system komputerowy, a po drugie – uzyskanie informacji dla niego nie przeznaczonej. System musi posiadać zatem aktywne (a nie tylko zainstalowane) [1] zabezpieczenia, stanowiące realną przeszkodę dla włamywacza, których sforsowanie wymaga specjalistycznej wiedzy lub urządzeń. Jak trafnie wskazuje się w literaturze prawniczej, “przełamanie zabezpieczeń” ma miejsce zarówno wtedy, gdy sprawca niszczy, usuwa zabezpieczenia, jak również kiedy sprawca oddziałując bezpośrednio na zabezpieczenia chwilowo niweluje ich funkcję zabezpieczającą [2]. Niewątpliwie w omawianym przez nas przypadku doszło w drodze “odgadnięcia” hasła do przełamania zabezpieczeń systemu komputerowego. Na marginesie rozważań zauważmy, że nie będzie ponosił odpowiedzialności karnej na gruncie omawianego przepisu intruz, który uzyskuje dostęp do systemu w inny sposób, niż łamiąc zabezpieczenia. Nie będziemy mogli postawić zarzutu przestępstwa hackingu intruzowi, który wykorzystując błędy w oprogramowaniu omija zabezpieczenia lub używa haseł, które wcześniej zdobył stosując tzw. social engineering (do niektórych ataków tego typu znajdzie zastosowanie art. 267 § 2 k.k.). Drugim, po przełamaniu zabezpieczeń, koniecznym warunkiem karalności hackingu jest uzyskanie przez sprawcę nieprzeznaczonej dla niego informacji. W doktrynie przedmiotu reprezentowane są dwa stanowiska odnośnie informacji, których uzyskanie uzasadnia postawienie zarzutu popełnienia przestępstwa hackingu. Zadaniem A. Adamskiego, intruz łamiąc zabezpieczenia w postaci hasła dostępu, “zapoznaje się z nieprzeznaczoną dla niego informacją, jaką jest treść hasła” [3].
     Do postawienia zarzutu popełnienia przestępstwa z art. 267 § 1 k.k. nie jest zatem konieczne, aby intruz wykorzystał “złamane” hasło, penetrował system czy zapoznał się z innymi danymi. Karalne jest samo uzyskanie przez osobę nieuprawnioną w drodze przełamania zabezpieczenia “informacji” umożliwiającej “wtargnięcie” do systemu komputerowego. Proponowana jest również odmienna wykładnia przepisu, wyraznie rozróżniająca informację o zabezpieczeniu od samej “informacji” chronionej tym zabezpieczeniem [4]. Zgodnie z tą koncepcją intruz ponosi odpowiedzialność karną, jeżeli dokona przełamania zabezpieczeń i uzyska dostęp do informacji w szerszym zakresie, niż tylko informacja o zabezpieczeniu (np. napastnik zapozna się z dokumentacją programu, pocztą elektroniczną pracowników). W omawianym przez nas przypadku intruz “złamał” hasło dostępu i wtargnął do systemu, nie znalazł natomiast na twardym dysku ofiary informacji będącej zasadniczym celem ataku. Przyjmując pierwszą z przedstawionych koncepcji będzie można mu postawić zarzut popełnienia przestępstwa z art. 267 § 1 k.k. Przyjmując natomiast za trafną drugą z proponowanych wykładni, czyn intruza należy uznać za usiłowanie popełnienia przestępstwa z art. 267 § 1 k.k. Przestępstwo zagrożone jest karą grzywny, ograniczenia wolności lub pozbawieniu wolności do lat dwóch. Ściganie przestępstwa następuje na wniosek pokrzywdzonego.

Odpowiedzialność karna – Koń trojański:

     Kolejnym krokiem w realizacji planu intruza jest przesłanie ukrytego w załączniku do e-maila konia trojańskiego. Włamywacz instaluje konia trojańskiego na komputerze ofiary, za jego pomocą inwigiluje system oraz przechwytuje korespondencję przedsiębiorstwa. Na straży poufności przekazu informacji stoi art. 267 § 2 k.k. wprowadzający odpowiedzialność karną sprawcy, który “w celu uzyskania informacji, do której nie jest podsłuchowym, wizualnym lub innym urządzeniem specjalnym”. Moim zdaniem za “urządzenie specjalne”, o którym mowa w przepisie, należy uznać miedzy innymi komputer wyposażony w specjalistyczne oprogramowanie przeznaczone do przechwytywania informacji w sieciach komputerowych [5]. Do programów tego typu należą różnego rodzaju konie trojańskie oraz sniffery. Nie ma przy tym znaczenia, czy intruz posługuje się programem zainstalowanym na własnym komputerze, czy też instaluje taki program na komputerze ofiary. Zauważmy, że odpowiedzialności karnej podlega także sprawca, który sam nie zainstalował konia trojańskiego czy sniffera, ale posługuje się takim oprogramowaniem wcześniej zainstalowanym w systemie przez innego intruza. Należy podkreślić, że intruz ponosi odpowiedzialność karną niezależnie, czy zdążył zapoznać się z informacją, czy był w stanie ją zrozumieć, a nawet niezależnie, czy uzyskał jakąkolwiek informację (inaczej niż w omawianym powyżej art. 267 § T k.k.). Karalna jest sama instalacja lub posługiwanie się specjalistycznym programem w celu zdobycia takiej informacji. W analizowanym przez nas przypadku intruzowi będzie można postawić zarzut popełnienia przestępstwa z art. 267 § 2 k.k.

Odpowiedzialność karna – Kopiowanie programu:

     Po wtargnięciu do systemu intruz skopiował interesujący go program komputerowy. Program komputerowy stanowi utwór chroniony prawem autorskim. W omawianym przypadku zastosowanie znajdzie art. 117 ust. 1 pr. aut. w myśl którego każdy, kto “bez uprawnienia albo wbrew jego “warunkom w celu rozpowszechnienia utrwala lub zwielokrotnia cudzy utwór (…) podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat dwóch” [6]. Na gruncie tego przepisu karane jest zatem przygotowanie do przestępstwa tzw. piractwa komputerowego. Ochronę programów komputerowych zapewniają również przepisy kodeksu karnego. Zgodnie z art. 278 k.k. karze pozbawienia wolności od 3 miesięcy do 5 lat podlega sprawca, który “bez zgody osoby uprawnionej uzyskuje cudzy program komputerowy w celu osiągnięcia korzyści majątkowej”. Pojęcie “uzyskanie programu komputerowego” należy interpretować szeroko, ponieważ obejmuje ono zarówno utrwalenie oraz zwielokrotnienie programu na nośniku materialnym (np. CD), jak również ściągniecie plików przez Internet na twardy dysk komputera. Uzyskanie cudzego programu musi łączyć się z zamiarem uzyskania korzyści materialnych. Jak trafnie wskazuje się w literaturze, w większości przypadków sam program posiada znaczną wartość majątkową – sprawca nielegalnie uzyskując program może z niego korzystać bez ponoszenia kosztów nabycia program [7]. W omawianym przypadku intruz zamierzał uzyskać poprzez produkcję pirackich kopii programu znacznie szerszą korzyść majątkową. Zauważmy, że art. 278 k.k. przewiduje karę wyższą, niż omawiany powyżej art. 117 pr. aut., właściwszym zatem będzie postawienie sprawcy zarzutu popełnienia przestępstwa z art. 278 k.k.

Odpowiedzialność karna – Zniszczenie danych:

     Kolejnym krokiem intruza jest wprowadzenie do systemu wirusa niszczącego zgromadzone na serwerze dane oraz modyfikacja witryny internetowej firmy. Ochronę integralności zapisu informacji zapewnia art. 268 k.k., zgodnie z którym odpowiedzialności karnej podlega sprawca, który “niszczy, uszkadza, usuwa lub zmienia zapis istotnej informacji albo w inny sposób udaremnia lub znacznie utrudnia osobie uprawnionej zapoznanie się z nią”. Czynem karalnym staje się więc umyślne wprowadzenie do systemu wirusa uszkadzającego lub niszczącego dane, zmiana praw dostępu do plików, niszczenie lub zmiana logów systemowych, modyfikacja stron WWW itp. Na marginesie rozważań zauważmy, że przepis znajdzie zastosowanie również do ataków typu DoS, które można zakwalifikować jako działanie znacznie utrudniające zapoznania się z informacją przez uprawnionego. Na gruncie cytowanego przepisu ochronie podlega jedynie “istotna” informacja. Oceniając “istotność” informacji należy kierować się przede wszystkim kryteriami obiektywnymi, odnosząc wartość informacji do pewnego standardu obowiązującego w dziedzinie, której dana informacja dotyczy [8]. Nie bez znaczenia dla oceny “istotności” informacji pozostaje również nakład środków, jakie poniósł pokrzywdzony w celu jej uzyskania. Zauważmy, że odpowiedzialności karnej podlega tylko taka ingerencja w system, która “udaremnia lub znacznie utrudnia” zapoznanie się z informacją, a jak wiadomo nie każda ingerencja prowadzi do tego typu skutków. Jak często wskazuje się w literaturze [9], nie dojdzie do popełnienia przestępstwa, gdy ofiara ataku posiada dodatkową kopię danych i gdy ich odtworzenie nie stworzy przy tym szczególnych trudności. Przestępstwo naruszenia integralności informacji zapisanej na nośniku komputerowym zagrożone jest karą pozbawienia wolności do lat trzech. Jeżeli sprawca swoim czynem wyrządził znaczną szkodę majątkową, podlega karze pozbawienia wolności od trzech miesięcy do pięciu lat. Zgodnie z art. 115 § 5 k.k. “znaczną szkodą” będzie szkoda w wysokości przekraczającej dwustu krotną wysokość najniższego miesięcznego wynagrodzenia.

Odpowiedzialność cywilna – Włamanie:

     Rozpatrując odpowiedzialność sprawcy za włamanie i inwigilację systemu komputerowego należy wskazać na możliwość zastosowania przepisów kodeksu cywilnego o ochronie dóbr osobistych. W art. 23 k.c. ustawodawca jedynie przykładowo wymienia dobra pozostające pod ochroną prawa cywilnego, w tym m.in. zdrowie, wolność, tajemnice korespondencji, nietykalność mieszkania, twórczość naukową. Zarówno doktryna przedmiotu, jak i orzecznictwo, nieustannie “odkrywa” nowe, pozostające pod ochroną prawa dobra osobiste. Zgodnie ze stanowiskiem doktryny oraz orzecznictwem sfera życia prywatnego stanowi podlegające ochronie dobro osobiste człowieka. Zdaniem A. Kopffa [10] “dobrem osobistym w postaci życia prywatnego jest to wszystko, co ze względu na uzasadnione odosobnienie się jednostki od ogółu społeczeństwa służy jej rozwoju fizycznej i psychicznej osobowości oraz zachowania osiągniętej pozycji społecznej”. W moim przekonaniu włamanie oraz inwigilacja systemu komputerowego stanowi wkroczenie w sferę prywatności jednostki, w rezultacie następuje niedopuszczalne naruszenie spokoju psychicznego ofiary ataku. Nie ma przy tym znaczenia sam techniczny aspekt włamania i nie będzie koniecznym stwierdzenie przełamania zabezpieczeń systemu. Moim zdaniem sama bezprawna inwigilacja systemu komputerowego stanowi naruszenie dóbr osobistych jednostki. Zgodnie z art. 24 k.c. osoba, której dobro osobiste zostało zagrożone, może żądać zaniechania bezprawnych działań. A zatem podniesienie takiego roszczenia będzie możliwe już w fazie przygotowania ataku, np. skanowania portów. Gdyby doszło do bezprawnego naruszenia dobra, poszkodowany może żądać zaniechania takiego działania, usunięcia skutków naruszenia, w tym założeniu oświadczenia o odpowiedniej treści i w odpowiedniej formie (np. przeprosin w gazecie). Poszkodowany może wystąpić również o zasądzenie odpowiedniej sumy jako zadośćuczynienia pieniężnego za doznaną krzywdę lub zasądzenie takiej sumy na wskazany cel społeczny. Jeżeli w skutek naruszenia pokrzywdzony doznał szkody majątkowej, może dochodzić jej naprawienia na zasadach ogólnych (art. 415 k.c.).

Odpowiedzialność cywilna – Koń trojański, inwigilacja poczty elektronicznej:

Art. 49 Konstytucji Rzeczypospolitej Polskiej gwarantuje wolność i ochronę tajemnicy komunikowania się. Natomiast art. 23 k.c. wprost wymienia “tajemnice korespondencji” jako ochronione prawem dobro osobiste człowieka. W doktrynie prawniczej dyskutowany jest problem, czy przekaz w formie elektronicznej podlega ochronie w ramach tajemnicy korespondencji, czy raczej właściwsze jest stosowanie szerszego pojęcia tj. tajemnicy komunikacji. Bez wdawania się w nieco teoretyczne dyskusje, należy stwierdzić, że na gruncie przepisu art. 23 k.c. ochronie podlegają obie formy porozumiewania. Jak zostało to już zasygnalizowane, samo zagrożenie dobra osobistego stanowi podstawę do wystąpienia z roszczeniem o zaniechanie bezprawnych działań naruszających to dobro. Moim zdaniem, ofiara ataku będzie mogła podnieść roszczenie z art. 24 k.c. już w momencie przesłania na jej konto konia trojańskiego, wtedy bowiem następuje zagrożenie dobra osobistego. Przechwytywanie poczty elektronicznej oraz inwigilacja systemu stanowi już naruszenie dobra osobistego, a zatem poszkodowany w oparciu o art. 24 k.c. może wystąpić z roszczeniami w szerszym zakresie. Należy wskazać, że zgodnie z przepisem art. 43 k.c. przepisy o dobrach osobistych stosuje się odpowiednio do osób prawnych (osobą prawną jest np. spółka akcyjna). Jak stwierdził Sąd Najwyższy, “dobra osobiste osób prawnych – to wartości niemajątkowe, dzięki którym osoba prawna może funkcjonować zgodnie ze swoim zakresem działań” [11]. Niewątpliwie wolność oraz tajemnica komunikowania się stanowi podstawę prawidłowego funkcjonowania przedsiębiorstwa.

Odpowiedzialność cywilna – Odpowiedzialność za szkodę:

     Jeżeli intruz swoim działaniem doprowadzi do powstania szkody majątkowej, znajdą zastosowanie ogólne zasady kodeksu cywilnego dotyczące odpowiedzialności z tytułu czynów niedozwolonych. Podstawową zasadę odpowiedzialności z tego tytułu wprowadza przepis art. 415 k.c. stanowiący, że “Kto z winy swej wyrządził drugiemu szkodę, zobowiązany jest do jej naprawienia”. Dochodząc odszkodowania poszkodowany musi udowodnić występowanie następujących zdarzeń:

- Istnienie szkody, rozumianej jako powstała wbrew woli poszkodowanego różnica między obecnym jego stanem majątkowym a tym stanem, jaki zaistniałby, gdyby nie nastąpiło zdarzenie wywołujące szkodę. Szkoda obejmie zarówno straty, jakie poniósł poszkodowany, jak i utracone korzyści, których mógł się spodziewać, gdyby mu szkody nie wyrządzono. W omawianym przypadku odszkodowanie obejmuje zarówno wartość straconych danych, koszty związane z ponowną instalacją i konfiguracją oprogramowania, jak również wartość zleceń, które spółka mogłaby przyjąć i wykonać, gdyby jej system komputerowy działał poprawnie.
- Zawinione zachowanie sprawcy. Poszkodowany musi więc wykazać, że doszło do włamania, zniszczenia danych itp. oraz że intruz ponosi winę za te działania. Analiza pojęcia winy przekracza rozmiary niniejszego artykułu. Na marginesie naszych rozważań warto wskazać, że nie można przypisać winy osobie niepoczytalnej, w tym małoletniemu do lat 13. Jak wskazuje orzecznictwo Sądu Najwyższego, ocena poczytalności nieletnich w wieku 13 – 18 lat może również w konkretnym przypadku wyłączać przypisane im winy. Osoby takie nie będą zatem odpowiadać za szkodę wyrządzoną swoim działaniem. Za szkodę spowodowania włamaniami nieletnich włamywaczy będą najczęściej odpowiadać osoby zobowiązane do nadzoru nad nimi (np. rodzice, wychowawcy).
- Związek przy czy nowy pomiędzy czynem sprawcy a szkodą. W omawianym przypadku istnieje oczywisty związek między włamaniem i wprowadzeniem wirusa, a skanowaniem danych i paraliżem systemu komputerowego.

Odpowiedzialność cywilna – Kopiowanie programu:

     Jak zostało już zasygnalizowane, większość programów komputerowych podlega ochronie autorsko – prawnej. Intruz, kopiując program komputerowy, narusza majątkowe prawa autorskie twórcy programu, nie ma przy tym znaczenia, czy zdążył on rozpowszechnić program lub sam z niego korzystać. W omawianym przypadku uprawniony z praw autorskich będzie mógł żądać w oparciu o art. 79 ust. 1 pr. aut. zaniechania naruszeń, wydania uzyskanych korzyści lub zapłaty stosownego wynagrodzenia w potrójnej wysokości oraz naprawienia szkody na zasadach przedstawionych powyżej. Przez “stosowne wynagrodzenie” należy rozumieć wynagrodzenie, jakie otrzymałby twórca, gdyby sprawca zawarł z nim umowę o korzystanie z programu (nabył licencję) [12]. Ponadto, jeżeli sprawca narusza prawa autorskie w ramach prowadzonej działalności gospodarczej, uprawniony może domagać się, aby sprawca uiścił odpowiednią sumę na Fundusz Promocji Twórczości.

Odpowiedzialność cywilna – Zmiany na stronie:

     Ostatnim z destrukcyjnych kroków intruza była zmiana zawartości firmowej strony WWW. Zakładamy, że strona WWW ofiary charakteryzowała się twórczością i indywidualnością w stopniu uzasadniającym uznanie jej za utwór chroniony prawem autorskim. Jednym z osobistych praw autorskich twórcy jest prawo do nienaruszalności treści i formy oraz rzetelnego wykorzystania utworu (tzw. prawo integralności utworu). Niedopuszczalne jest dokonywanie bez zgody twórcy jakichkolwiek zmian w projekcie i kompozycji strony. Intruz będzie zatem odpowiadał za naruszenie osobistych praw autorskich. Na podstawie art. 78 ust. 1 pr. aut. twórca będzie mógł wystąpić z roszczeniem o usunięcie skutków naruszenia, w szczególności o złożenie stosownego oświadczenia (np. przeprosin) oraz żądać zadośćuczynienia pieniężnego lub przekazania odpowiedniej sumy na wskazany cel społeczny. Ponadto zmieniając zawartość strony WWW, intruz naraził na szwank renomę przedsiębiorstwa. Spółka może zatem wystąpić z rszczeniem w oparciu o przepisy o ochronie dóbr osobistych (tj. art. 23 i art. 24 z związku z art. 43 k.c.). Wydaje się, że szczególnie uzasadnione będą tu żądania zmierzające do odbudowy renomy spółki, np. zamieszczenie przeprosin w prasie.

     W chwili obecnej istnieją instrumenty prawne pozwalające na podciągnięcie do odpowiedzialności sprawców włamań komputerowych. W omawianym przypadku intruz naruszył przepisy kodeksu karnego, kodeksu cywilnego oraz ustawy o prawie autorskim i prawach pokrewnych. Odpowie za to w procesie karnym oraz w procesach cywilnych wytoczonym przez spółkę “Edytory” S.A. oraz jej prezesa. Należy ponadto wskazać, że zgodnie z art. 62 k.p.c. pokrzywdzony może w postępowaniu karnym dochodzić roszczeń majątkowych wynikających bezpośrednio z przestępstwa. Moim zdaniem konieczna jest jednak dalsza praca doktryny prawniczej oraz orzecznictwa w kierunku przyjęcia wykładni przepisów uzwzględniającej wyzwania postępu technicznego. Ponadto nieodzownym staje się podjęcie prac nad nowelizacją kodeksu karnego – zwłaszcza jego paragrafów dotyczących przestępstwa hackingu (art. 267 § 1 k.k.). Moim zdaniem, karalne powinno być samo wejście przez nieuprawnionego do systemu komputerowego w celu uzyskania zgromadzonych w nim informacji, niezależnie, czy łączy się to z “przełamaniem zabezpieczeń” oraz czy intruz w wyniku ataku uzyskał informację.

Wybrane przepisy KK i KC:

Art. 13 kodeksu karnego:

§ 1. Odpowiada za usiłowanie, kto w zamiarze popełnienia czynu zabronionego swoim zachowaniem bezpośrednio zmierza do jego dokonania, które jednak nie następuje.
§ 2. Usiłowanie zachodzi także wtedy, gdy sprawca nie uświadamia sobie, że dokonanie jest niemożliwe ze względu na brak przedmiotu nadającego się do popełnienia na nim czynu zabronionego lub ze względu na użycie środka nie nadającego się do popełnienia czynu zabronionego.

Art. 267 kodeksu karnego:

§ 1. Kto bez uprawnienia uzyskuje informację dla niego nie przeznaczoną, otwierając zamknięte pismo, podłączając się do przewodu służącego do przekazywania informacji lub przełamując elektroniczne, magnetyczne albo inne szczególne jej zabezpieczenie, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat 2.
§ 2. Tej samej karze podlega, kto w celu uzyskania informacji, do której nie jest uprawniony, zakłada lub podsłuchuje się urządzeniem podsłuchowym, wizualnym albo innym urządzeniem specjalnym.
§ 3. Tej samej karze podlega, kto informację uzyskaną w sposób określony w § 1 lub 2 ujawnia innej osobie.
§ 4. Ściganie przestępstwa określonego w § 1 – 3 następuje na wniosek pokrzywdzonego.

Art. 268 kodeksu karnego:

§ 1. Kto nie będąc tego uprawnionym, niszczy, uszkadza, usuwa lub zmienia zapis istotnej informacji albo w inny sposób udaremnia lub znacznie utrudnia osobie uprawnionej zapoznanie się z nią, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat 2.
§ 2. Jeżeli czyn określony w § 1 dotyczy zapisu na komputerowym nośniku informacji, sprawca podlega karze pozbawienia wolności do lat 3.
§ 3. Kto, dopuszczając się czynu określonego w § 1 lub 2, wyrządza znaczną szkodę majątkową, podlega karze pozbawienia wolności od 3 miesięcy do lat 5.
§ 4. Ściganie przestępstwa określono w § 1 – 3 następuje na wniosek pokrzywdzonego.

Art. 117.1. ustawy o prawie autorskim i prawach pokrewnych:

1. Kto bez uprawnienia albo wbrew jego warunkom w celu rozpowszechnienia utrwala lub zwielokrotnia cudzy utwór w wersji oryginalnej lub w postaci opracowania, artystyczne wykonanie, fonogram, wideogram lub nadanie, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat 2.
2. Jeżeli sprawca uczynił sobie z popełniania przestępstwa określonego w ust. 1 stałe zródło dochodu albo działalność przestępną, określoną w ust. 1, organizuje lub nią kieruje, podlega karze pozbawienia wolności do lat 3.

Art. 23 kodeksu cywilnego:

Dobra osobiste człowieka, jak w szczególności zdrowie, wolność, cześć, swoboda sumienia, nazwisko lub pseudonim, wizerunek, tajemnica korespondencji, nietykalność mieszkania, twórczość naukowa, artystyczna, wynalazcza i racjonalizatorska, pozostają pod ochroną prawa cywilnego niezależnie od ochrony przewidzianej w innych przepisach.

Art. 24 kodeksu cywilnego:

§ 1. Ten, czyje dobro osobiste zostaje zagrożone cudzym działaniem, może żądać zaniechania tego działania, chyba że nie jest ono bezprawne. W razie dokonanego naruszenia może on także żądać, ażeby, osoba, która dopuściła się naruszenia, dopełniła czynności potrzebnych do usunięcia jego skutków, w szczególności ażeby złożyła oświadczenie odpowiedniej treści i w odpowiedniej formie. Na zasadach przewidzianych w kodeksie może on również żądać zadośćuczynienia pieniężnego lub zapłaty odpowiedniej sumy pieniężnej na wskazany cel społeczny.
§ 2. Jeżeli wskutek naruszenia dobra osobistego została wyrządzona szkoda majątkowa, poszkodowany może żądać jej naprawienia na zasadach ogólnych.
§ 3. Przypisy powyższe nie uchybiają uprawnieniom przewidzianym w innych przepisach, w szczególności w prawie autorskim oraz w prawie wynalazczym.

Przypisy:

1. Zwraca na to uwagę P. Kardas, Prawnokarna ochrona informacji w polskim prawie karnym, Czasopismo prawa karnego i nauk penalnych 2000/1.
2. W. Wróbel w: G. Bogdan, K. Buchała, Z. Ćwiakalski, M. Dąbrowska-Kardas, P. Kardas, J. Majewski, M. Rodzynkiewicz, M. Szewczyk, W. Wróbel, A. Zoli, Kodeks karny, Część szczególna. Komentarz, t. 2 str. 1007.
3. A. Adamski, Prawo karne komputerowe, Warszawa 2000, str. 47: A. Adamski, Przestępstwa komputerowe w nowym kodeksie karnym str. 39 w: Nowa Kodyfikacja Karna Krótkie Komentarze, Warszawa 1998.
4. W. Wróbel, Kodeks karny… j.w., str. 1007, a także P. Kardas, Prawnokarna ochrona informacji… j.w., str. 69.
5. Przegląd taki reprezentuje A. Adamski. Komputer w paragrafach, Rzeczpospolita 30.10.1997; Przestępstwa komputerowe w nowym kodeksie… j.w., str. 56, Prawo karne komputerowe, str. 59. W doktrynie prezentowane jest również stanowisko odmienne W. Wróbel, Kodeks karny… j.w., str. 1010.
6. J. Barta, M. Czajkowska-Dąbrowska, Z. Ćwiakalski, R. Markiewicz, E. Trapie, Komentarz do ustawy o prawie autorskim i prawach pokrewnych, Warszawa 1995, str. 486 i następne.
7. A. Adamski, Przestępstwa komputerowe w nowym kodeksie… j.w., str. 118 podobnie E. Czarny-Drożdżejko, Ochrona informacji i programów komputerowych w nowym kodeksie karnym, str. 216 w: Prawo autorskie a postęp techniczny, Kraków 1999.
8. Zwraca na to uwagę także P. Kardas, Prawokarna ochrona informacji, str. 88.
9. A. Adamski, Przestępstwa komputerowe w nowym kodeksie… j.w., str. 57.
10. A. Kopff, Koncepcja prawa do intymności i do prywatności życia osobistego, Studia Cywilistyczne, T XX, Kraków 1972.
11. Wyrok SN z 14.11.1986, II CR 295/86, OSNC 1988/2-3/40.
12. J. Barta, M. Czajkowska-Dąbrowska, Z. Ćwiakalski, R. Markiewicz, E. Trapie, Komentarz do ustawy… j.w., str. 375 i następne.

Bonus:Odpowiedzialność karna intruza za zniszczenie lub modyfikację logów systemowych:

     W większości systemów operacyjnych istnieje mechanizm rejestrowania wszystkich zdarzeń zachodzących w systemie. Systemy linuksowe rejestrują działanie systemu w plikach rejestru znajdujących się w katalogu /var/log [1]. Ponadto często administrator instaluje dodatkowe oprogramowanie do monitorowania pracy systemu i rejestracji zdarzeń. [2] Administrator analizując odpowiednie dzienniki zdarzeń może stwierdzić kto i kiedy pracował w systemie oraz jakie wykonał operacje. Intruz dokonujący włamania zdaje sobie najczęściej sprawę z istnienia mechanizmu rejestrującego jego poczynania w systemie, a zatem w celu ukrycia swojej działalności stara się zniszczyć lub zmienić logi systemowe. Intruz używając edytora tekstu (np. pico, vi) może “ręcznie” zmodyfikować logi lub usprawnić sobie pracę wykorzystując gotowy program lub pisząc prosty skrypt w języku powłoki. Na strarzy integralności zapisu informacji stoi przepis art. 268 k.k. zgodnie, z którym odpowiedzialności karnej podlega sprawca który nie będąc do tego uprawniony “niszczy, uszkadza, usuwa lub zamienia zapis istotnej informacji albo w inny sposób udaremnia lub znacznie utrudnia osobie uprawnionej zapoznanie się z nią”. Natomiast przepis art. 268 § 2 k.k. stanowi, że gdy czyn dotyczy zapisu na komputerowym nośniku informacji sprawca podlega karze pozbawienia wolności od lat 3 (typ podstawowy przestępstwa zagrożony jest mniej surową karą grzywny, ograniczenia wolności lub pozbawienia wolności do lat 2).
Zauważmy, że w oparciu o omawiany przepis karalne jest zniszczenie, uszkodzenie czy zmiana nie jakiejkolwiek informacji, a wyłącznie “ISTOTNEJ” informacji. Powstaje zatem pytanie czy zapis logów systemowych stanowi “istotną” informację w rozumieniu niniejszego przepisu. Jak wskazuje się w literaturze prawniczej, ocena “istotności” informacji powinna opierać się o kryteria obiektywne. [3] Jednocześnie należy zgodzić się z opinią, że podstawą oceny istotności informacji powinien być “standard obowiązujący w danej dziedzinie do której odnosi się informacja”. [4] Ponadto w doktrynie przedmiotu reprezentowany jest podgląd zgodnie, z którym oceniając “istotność” informacji oprócz przesłanek obiektywnych należy uwzględnić znaczenia informacji dla jej dysponenta oraz cel jakiemu informacja służy [5]. Moim zdaniem skasowanie lub modyfikowanie logów systemowych przez intruza mieści się w pojęciu niszczenia, usuwania lub zmiany zapisu ISTOTNEJ informacji. Zmiana zapisu informacji, o której mowa w przepisie, prowadzić może zarówno do zupełnego pozbawienia sensu zapisu jak również do stanu, w którym informacja pozostaje czytelna, nabiera jednak zupełnie innego znaczenia niż przed dokonaniem zmiany w zapisie [6]. W przypadku ingerencji w logi systemowe najczęściej spotykamy się właśnie z drugą z wymienionych ewentualności. Intruz najczęściej nie niszczy całości zapisu, kasuje lub modyfikuje jedynie zapis dotyczący własnej działalności w systemie (np. próby zalogowania z danego hosta). Oczywiście tego typu “częściowa” zmiana logów systemowych również stanowić może czyn karalny. W praktyce administrator stara się przeciwdziałać modyfikacji logów systemowych poprzez odpowiednią konfigurację systemu (w Linuksie będzie to modyfikacja pliku /etc/syslogd.conf). Możliwa jest konfiguracja systemu, zmierzająca do “dublowania” zapisu logów systemowych. Kopia logów może być zapisywana w odpowiednim pliku na tym samym komputerze (/zapisana/bardzo/głęboko/w/systemie) wysyłana na inny host lub okresowo drukowana [7]. Przestępstwo z art. 268 § 2 k.k. jest przestępstwem skutkowym, odpowiedzialność karna sprawcy zależy od wystąpienia skutku w postaci udaremnienia lub znacznego utrudnienia osobie uprawnionej zapoznania się z informacją. Jak wskazuje W. Wróbel “Nie stanowi realizacji znamion czynu zabronionego określonego w tym przepisie zniszczenie jednej z wielu kopii zapisu informacji, chyba że zapoznanie się z tą informacją zawartą na pozostałych kopiach jest znacznie utrudnione” [8]. Nie dojdzie zatem do popełnienia przestępstwa z art. 268 § 2 k.k. w przypadku, gdy intruz zniszczy lub zmodyfikuje tylko jedną z kopii logów systemowych i zapoznanie się z “oryginalnym” zapisem logów nie będzie stanowić znacznego utrudnienia dla uprawnionego. Omawiane przestępstwo jest przestępstwem umyślnym. Zgodnie z art. 9 § 1 k.k. czyn zabroniony popełniony jest umyślnie, jeżeli sprawca ma zamiar jego popełnienia, to jest chce go popełnić albo przewiduje możliwość jego popełnienia i na to się godzi. Nie stanowi zatem przestępstwa nieumyślne zniszczenie logów systemowych w wyniku nieostrożnych, przypadkowych działań użytkownika systemu. Należy podkreślić, że niezależnie od odpowiedzialności karnej, zniszczenie lub modyfikacja logów systemowych łączy się z odpowiedzialnością cywilną sprawcy.

Przypisy:

1. Więcej zobacz: Krzysztof Rzecki, Leszek Siwik, “Bezpieczeństwo w systemach komputerowych – Referat z przedmiotu “Administrowanie Systemami Komputerowymi”, artykuł dostępny na stronach serwisu www.ipsec.pl
2. np. LogCaster, zobacz: T. Łopatkiewicz, Centralne monitorowanie logów systemowych – LogCaster, IT Security Magazine, 12/2000; Robert Wysocki, Audit Policy;
3. A. Adamski, Prawo karne komputerowe, Warszawa 2000, str. 65
4. P. Kardas, Prawnokarna ochrona informacji w polskim prawie karnym, Czasopismo prawa karnego i nauk penalnych 2000/1
5. O. Górniok, Kodeks karny, str. 325; podobnie: W. Wróbel w: G. Bogdan, K. Buchała, Z. Ćwiakalski, M. Dąbrowska-Kardas, P. Kardas, J. Majewski, M. Rodzynkiewicz, M. Szewczyk, W. Wróbel, A. Zoll, Kodeks karny, Część szczególna. Komentarz, t. 2 str. 1019
6. tak: J. Kardas, Prawnokarna ochrona… j.w., str. 90
7. Dominik Bałos, Dariusz Czapla, Jan Górkiewicz, Bezpieczeństwo systemów komputerowych na przykładzie systemu Linuks., Artykuł dostępny na stronach serwisu www.ipsec.pl; Gerhard Mourani, Securing and Optimizing Linux, RedHat Edition – A Hands on Guide
8. W. Wróbel w: G. Bogdan, K. Buchała, Z. Ćwiakalski, M. Dąbrowska-Kardas, P. Kardas, J. Majewski, M. Rodzynkiewicz, M. Szewczyk, W. Wróbel, A. Zoll, Kodeks karny, Część szczególna. Komentarz, t. 2; zobacz również: A. Adamski, Prawo karne komputerowe… j.w., str. 72

Odpowiedzialność karna sprawcy ataku typu DoS (Denial of Service attack).

     Przez atak typu DoS (denial of service attack) rozumie się różnego typu ataki na systemy komputerowe mające na celu utrudnienie lub uniemożliwienie funkcjonowania danej maszyny lub części sieci. Ataki tego typu polegają najczęściej na sztucznym generowaniu i przesyłaniu do komputera ofiary wielkiej ilości informacji. Komputer (ofiara) nie jest w stanie przeanalizować i odpowiedzieć na wszystkie napływające informacje co prowadzi do spowolnienia lub zablokowania jego działania (zawieszenia komputera). Do ataków tego typu należą między innymi: Chargen-Echo, Teardrop, DDoS, SYN Flood, Nuke, Land, Smurf, Ping oF Death [1]. Niezależnie od zastosowanej techniki ataku podstawowym jego celem jest “unieruchomienie” komputera, uniemożliwienie pracy oraz komunikacji z innymi maszynami. Działania tego typu stanowią zatem naruszenie jednego z podstawowych praw człowieka – wolności komunikowania się. Jak stanowi art. 49 Konstytucji RP “Zapewnia się wolność i tajemnice komunikowania się. Ich ograniczenie może nastąpić jedynie w przypadkach określonych w ustawie i w sposób w niej określony.” Powyższy przepis Konstytucji znajduje realizację zarówno w przepisach prawa karnego jak i cywilnego. W omawianym przypadku znajdzie zastosowanie art. 268 kodeksu karnego stanowiący, że:
§ 1. Kto nie będąc tego uprawnionym, niszczy, uszkadza, usuwa lub zmienia zapis istotnej informacji albo w inny sposób udaremnia lub znacznie utrudnia osobie uprawnionej zapoznanie się z nią, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat 2.
§ 2. Jeżeli czyn określony w § 1 dotyczy zapisu na komputerowym nośniku informacji, sprawca podlega karze pozbawienia wolności do lat 3.
§ 3. Kto, dopuszczając się czynu określonego w § 1 lub 2, wyrządza znaczną szkodę majątkową, podlega karze pozbawienia wolności od 3 miesięcy do lat 5.
§ 4. Ściganie przestępstwa określono w § 1 – 3 następuje na wniosek pokrzywdzonego.
Niewątpliwie skuteczny atak typu DoS będzie można zakwalifikować jako działanie udaremniające lub znacznie utrudniające zapoznanie się z informacją przez uprawnionego. Jak wskazuje się w literaturze nie dochodzi do popełnienia przestępstwa gdy uprawniony posiada kopię danych i gdy ich odtworzenie nie stworzy przy tym szczególnych trudności [2]. Zauważmy, że w przypadku informacji zamieszczonych na serwerze WWW (podobnie serwerze poczty) osobą uprawnioną do zapoznania się z informacją będzie każdy użytkownik (internauta), a nie tylko osoba która zamieściła informację lub która administruje serwerem. A zatem możliwość zapoznania się z danymi przez administratora systemu oraz ograniczony krąg osób uprawnionych (np. po odłączeniu serwera od internetu dane mogą przeglądać jedynie użytkownicy sieci LAN) nie wyłączy odpowiedzialności karnej sprawcy ataku. Pozostanie bowiem cała rzesz użytkowników (uprawnionych) którzy w wyniku ataku nie będą mogli zapoznać się z informacją zgromadzoną na serwerze. Na gruncie omawianego przepisu podlega ochronnie jedynie “istotna” informacja. Przestępstwem będzie zatem atak udaremniający lub utrudniający zapoznanie się z “istotną” informacją. Jak wskazuje się w literaturze chodzi w tym przypadku o ISTOTNĄ informację w znaczeniu obiektywnym [3]. Przy ocenie “istotności informacji” należy brać również pod uwagę interes dysponenta informacji oraz w pewnych przypadkach interes podmiotu którego dotyczy informacja [1]. Słusznym wydaje się postulat oceny “istotności” informacji odnosząc jej wartość do pewnego standardu obowiązującego w dziedzinie której dana informacja dotyczy [5]. Moim zdaniem oceniając “istotność” informacji należy kierować się również nakładem pracy i środków koniecznych do “uzyskania” danej informacji. Ustawodawca wprowadził surowszą odpowiedzialność za udaremnienie lub utrudnienie zapoznania się z informacją zgromadzoną na “komputerowym nośniku informacji”. A zatem zgodnie z art. 268 § 2 k.k. w przypadku ataków typu DoS sprawca będzie podlegał karze pozbawienia wolności do lat 3. Odpowiedzialność sprawcy będzie jeszcze surowsza jeżeli w wyniku ataku wyrządzona zostanie “znaczna szkoda majątkowa”. Zgodnie z art. 268 § 3 k.k. sprawca wyrządzający znaczną szkodę majątkową podlega karze pozbawienia wolności od 3 miesięcy do lat 5. Zgodnie z art. 115 § 7 k.k. w zw. z § 5 znaczną szkodę majątkową stanowi szkoda przekraczająca dwukrotną wartość najniższego miesięcznego wynagrodzenia. Przestępstwo z art. 268 § 2 k.k. jest przestępstwem umyślnym. Nie będzie zatem podlegał karze użytkownik który np. w wyniku awarii programu lub sprzętu przypadkowo dokonał ataku DoS na inny host. Ponadto atak typu DoS łączy się z odpowiedzialnością cywilną sprawcy.

W USA ataki DoS, zgodnie z ustawą “National Information Infrastructure Protection Act” z 1996 r., są przestępstwem federalnym zagrożonym karą od 5 do 10 lat więzienia oraz grzywną w wysokości 250 tys. USD. Z kolei w Wielkiej Brytani sprawców ataków Denial of Service pozwala pociągnąć do odpowiedzialności znowelizowana w 2002 roku ustawa “Computer Misuse Act”.

Przypisy:

1. Więcej na temat ataków typu DoS zobacz: A. Dudek, Nie tylko wirusy, Helion 1998; M. Dudek, Co każdy internauta wiedzieć powinien – wybrane zagadnienia osobistej polityki bezpieczeństwa. w: Internet Fenomen Społeczeństwa Informacyjnego, pod red. ks. prof. T. Zasępy; Krzysztof Rzecki, Leszek Siwik, Bezpieczeństwo w systemach komputerowych, Artykuł dostępny na stronach serwisu www.ipsec.pl;Wojtek Jakóbczyk, Ataki DoS – ICQ
2. W. Wróbel w: G. Bogdan, K. Buchała, Z. Ćwiakalski, M. Dąbrowska-Kardas, P. Kardas, J. Majewski, M. Rodzynkiewicz, M. Szewczyk, W. Wróbel, A. Zoll, Kodeks karny, Część szczególna. Komentarz t. 2 podobnie: A. Adamski, Prawo karne komputerowe, Warszawa 2000, str. 72, A. Adamski, Przestępstwa komputerowe w nowym kodeksie karnym. str. 57 w serii: Nowa Kodyfikacja Karna Krótkie Komentarze.
3. A. Adamski, Prawo karne komputerowe j.w., str. 65
4. np. gdy chodzi o dane osobowe, należy brać pod uwagę istotność tych danych dla podmiotu którego dotyczą.
5. Zwraca na to uwagę P. Kardas, Prawo karne ochrona informacji w polskim prawie karnym, Czasopismo prawa karnego i nauk penalnych 2000/1.

Więcej informacji: www.prawnik.net.pl

Dnia 15.11.2009

Ewolucja Kodów Powłoki

K

od powłoki jest fragmentem kodu maszynowego, który wykorzystuje się jako ładunek przy atakach bazujących na wykorzystaniu błędów softwarowych. Wykorzystywanie słabych punktów w rodzaju przepełnienia bufora przydzielonego na stosie lub stercie lub stringów formatujących wymagają kodu powłoki. Kod ten będzie wykonany jeśli proces wykorzystania luki się powiedzie.

Artykuł ten został opublikowany w numerze 1/2007 (21) magazynu hakin9.

Artykuł w formacie PDF

Dnia 14.11.2009

Funkcje kodujące adresy e-mail w CMS Wordpress

W

iadomości SPAM swoje główne źródło bazy adresów e-mail znajdują w spambotach. Spamboty są to specjalnie zaprogramowane roboty sieciowe – podobne do tych, które indeksują strony dla wyszukiwarek – tylko z tą różnicą, iż robią to pod kontem wyszukiwania ogólnodostępnych adresów e-mail umieszczanych na stronach WWW. Tak zebrane adresy e-mail lądują w bazach danych spamerów, stają się przedmiotem handlu wśród różnych niechcianych kampanii reklamowych czy innych negatywnych form aktywności sieciowej szkodników pod postacią wirusów czy robaków.

Najprostszą metodą walki ze spambotami jest użycie techniki zniekształcania (ang. munging) lub zaciemniania (ang. obfuscation) adresu e-mail. Technika zniekształcania polega na zapisaniu adresu e-mail w formie uniemożliwiającej odczytanie go za pomocą oprogramowania komputerowego. Mimo to pozostaje on w pełni zrozumiały dla ludzkiego rozumu, który potrafi zrekonstruować oryginalny zapis. I tak dla przykładu zwykły adres e-mail pod postacią “nikt@ważny.pl” zostaje zapisany pod postacią “nikt (małpa) ważny (kropka) pl”. Technika ta staje się coraz bardziej popularna wśród użytkowników prywatnych stron WWW, grup dyskusyjnych, for czy czatów – ceniących sobie “czystość” swoich skrzynek pocztowych. Aktualnie istnieje bardzo duże prawdopodobieństwo, że adres e-mail zapisany w czystej postaci zostanie włączony do kolekcji przez złowrogie oprogramowanie komputerowe w tak zwanym procesie zbioru adresów e-mail (ang. e-mail address harvesting). Prywatne adresy przesyłane w wiadomościach e-mail pomiędzy dwoma osobami są najmniej narażone na dołączenie do zbioru (chyba, że jedna z nich posiada drugą w książce adresowej, która została właśnie przejęta przez złośliwe oprogramowanie infekujące jej komputer).

W wielu przypadkach różne zapisy zniekształcania stosowane przez kreatywnych odbiorców wiadomości utrudniają komunikację, która mogłaby zostać nawiązana przez początkujących użytkowników Internetu, a metoda ta wymaga kreatywności! Z prostego względu. Jeśli np. zastosujemy najbardziej znany zapis w postaci “login at host dot com” to jedynie pomożemy spamerom w zbieraniu adresów e-mail. Alternatywną metodą do zniekształcania adresów e-mail jest metoda zaciemniania. Polega ona na zapisaniu adresu e-mail w technice pozwalającej oszukać oprogramowanie komputerowe, a jednocześnie przedstawić adres e-mail w czystej postaci. Najbardziej znaną, która istnieje od zalania dziejów jest odpalenie ulubionego edytora graficznego i zapisanie adresu e-mail w postaci pliku graficznego. Bardziej wyrafinowaną odmianą tej techniki jest ukrycie adresu w animacji flash, która by zmuszała spamera do poszukania prawidłowego pliku .swf, jego ściągnięcia, dekompilacji oraz wyszukaniu w źródle adresu. Niestety techniki te nie mają racji bytu w przypadku stron, w których istnieje duża liczba dynamicznie dodawanych adresów e-mail. Drugą techniką w zaciemnianiu adresów jest zamiana “czytelnych” znaków na “nieczytelne”. Dla przykładu: następujący kod po przeprasowaniu przez przeglądarkę wyświetli adres e-mail “nikt@ważny.pl”:

<script type="text/javascript">
 var name = 'nikt';
 var at = '@';
 var domain = 'ważny.pl';
 document.write(name + at + domain);
</script>

lub

<a href='mailto:m%65@%6D%79%73ite%2E%63om'>Mail</a>

Niestety kody te są bardzo wadliwe, ze względu na ich boleśnie prostą możliwość odkodowania – nawet przez nie za bardzo wyrafinowane spamboty. Rozwiązaniem może okazać się metoda, której autorem jest Tim Williams, a która została zmodyfikowana przez Andrew Moulden’a oraz przepisana na kod PHP przez Ross’a Killen’a. Jej działanie polega na:

  • Pobraniu adresu e-mail, który ma zostać chroniony przez spambotami.
  • Przekształceniu go na małe litery.
  • Stworzeniu metody szyfrowania, która posłuży do zaszyfrowania adresu.
  • Wpisaniu zaszyfrowanego adresu e-mail oraz szyfru w dokument (oba te kawałki kodu są w zasadzie bezużyteczne dla zbieracza adresów).
  • Następnie owinąć te fragmenty kodu w JavaScript by faktycznie ukazać przeglądającemu użytkownikowi strony klikalny adres e-mail powstały z zaszyfrowanego klucza oraz tekstu.

Najważniejszą rzeczą jest, aby nie używać tego samego klucza za każdym razem, gdy adres e-mail jest kodowany. Gdyby technika ta zyskała szersze zastosowanie autor spambota z pewnością wykorzystałby ten fakt, do napisania metody dekodującej adres. Wiele trudniej jest zrobić to, gdy klucz jest dynamiczny i zmienia się za każdym razem, gdy zostaje użyta funkcja szyfrująca. Poniżej przedstawiam dwie takie funkcje, które zostały przystosowane już do użycia w systemie blogowym Wordpress. Pierwsza z nich nazywa się munge:

function munge($atts, $content = null) {
    extract(shortcode_atts(array(
	'address' => 'user@user.com',
	), $atts));
    $address = strtolower($address);
    $coded = "";
    $unmixedkey ="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.@";
    $inprogresskey = $unmixedkey;
    $mixedkey="";
    $unshuffled = strlen($unmixedkey);
    for ($i = 0; $i <= strlen($unmixedkey); $i++)
    {
	$ranpos = rand(0,$unshuffled-1);
	$nextchar = $inprogresskey{$ranpos};
	$mixedkey .= $nextchar;
	$before = substr($inprogresskey,0,$ranpos);
	$after = substr($inprogresskey,$ranpos+1,$unshuffled-($ranpos+1));
	$inprogresskey = $before.''.$after;
	$unshuffled -= 1;
    }
    $cipher = $mixedkey;
    $shift = strlen($address);
    $txt = "<script type=\"text/javascript\">\n";
    for ($j=0; $j<strlen($address); $j++)
    {
	if (strpos($cipher,$address{$j}) == -1 )
	{
		$chr = $address{$j};
		$coded .= $address{$j};
	}
	else
	{
		$chr = (strpos($cipher,$address{$j}) + $shift) %strlen($cipher);
		$coded .= $cipher{$chr};
	}
    }
    $txt .= "		coded = \"" . $coded . "\"\n" .
	"		key = \"".$cipher."\"\n".
	"		shift=coded.length\n".
	"		link=\"\"\n".
	"		for (i=0; i<coded.length; i++) {\n" .
	"		    if (key.indexOf(coded.charAt(i))==-1) {\n" .
	"		      ltr = coded.charAt(i)\n" .
	"		      link += (ltr)\n" .
	"		    }\n" .
	"		    else {     \n".
	"		      ltr = (key.indexOf(coded.charAt(i))-shift+key.length) % key.length\n".
	"		      link += (key.charAt(ltr))\n".
	"		    }\n".
	"		  }\n".
	"		document.write(\"<a href='mailto:\"+link+\"'>\"+link+\"</a>\")\n" .
        "	<" . "/script>\n";
    return $txt;
}
add_shortcode('antispam', 'munge');

Tak przygotowany kod można wkleić do pliku functions.php znajdującego się w głównym katalogu wybranej skórki / tematu. Plik ten jest automatycznie ładowany podczas inicjalizacji systemu Wordpress dlatego każda funkcja znajdująca się w jego wnętrzu również jest automatycznie uaktywniana. Istnieje również możliwość zapisania całości np. jako plik antispam.php i umieszczeniu go w katalogu plugins systemu Wordpress. Wówczas tak stworzoną “wtyczkę” należy aktywować z panelu administratora. Od tej pory każdy adres e-mail ujęty w znacznik “antispam” w taki sposób:

[antispam address="nikt@wazny.pl"]

Wewnątrz źródła strony adres będzie miał postać:

<script type="text/javascript">
	coded = "mJ4DNy4.HZNDgsW1"
		key = "uE3A6fe7tzQ25W0soPUSaZDVhMOckvLNyGTrmxnXl9IgKCY@bqR4FiHw1jBJdp8."
		shift=coded.length
		link=""
		for (i=0; i<coded.length; i++) {
		    if (key.indexOf(coded.charAt(i))==-1) {
		      ltr = coded.charAt(i)
		      link += (ltr)
		    }
		    else {
		      ltr = (key.indexOf(coded.charAt(i))-shift+key.length) % key.length
		      link += (key.charAt(ltr))
		    }
		  }
		document.write("<a href='mailto:"+link+"'>"+link+"</a>")
</script>

Drugą funkcją jest funkcja o nazwie hide_email autorstwa Maurits’a van der Schee. Tak na prawdę jest to ta sama implementacja używająca tylko trochę innego algorytmu szyfrującego z zoptymalizowanym kodem JavaScript oraz zgodna ze standardem prasera XHTML 1.0:

function hide_email($atts, $content = null) {
    extract(shortcode_atts(array(
        'address' => 'user@user.com',
        ), $atts));
    $address = strtolower($address);
    $character_set = '+-.0123456789@ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz';
    $key = str_shuffle($character_set); $cipher_text = ''; $id = 'e'.rand(1,999999999);
    for ($i=0;$i<strlen($address);$i+=1) $cipher_text.= $key[strpos($character_set,$address[$i])];
    $script = 'var a="'.$key.'";var b=a.split("").sort().join("");var c="'.$cipher_text.'";var d="";';
    $script.= 'for(var e=0;e<c.length;e++)d+=b.charAt(a.indexOf(c.charAt(e)));';
    $script.= 'document.getElementById("'.$id.'").innerHTML="<a href=\\"mailto:"+d+"\\">"+d+"</a>"';
    $script = "eval(\"".str_replace(array("\\",'"'),array("\\\\",'\"'), $script)."\")";
    $script = '<script type="text/javascript">/*<![CDATA[*/'.$script.'/*]]>*/</script>';
    return '<span id="'.$id.'">[Adres e-mail chroniony JavaScript]</span>'.$script;
}
add_shortcode('hideemail', 'hide_email');

Od tej pory każdy adres e-mail ujęty w znacznik “hideemail” w taki sposób:

[hideemail address="nikt@wazny.pl"]

Wewnątrz źródła strony adres będzie miał postać:

<span id="e885754433">[Adres e-mail chroniony JavaScript]</span><script type="text/javascript">/*<![CDATA[*/eval("var a=\"IMUstxVKiC9j7gZ+O@Yl5REeJw2WDQXbFyfBAGh8r0u-1.zpm4_adH36cPLSokTqnvN\";var b=a.split(\"\").sort().join(\"\");var c=\"o.Sogo.SoU-6H\";var d=\"\";for(var e=0;e<c.length;e++)d+=b.charAt(a.indexOf(c.charAt(e)));document.getElementById(\"e885754433\").innerHTML=\"<a href=\\\"mailto:\"+d+\"\\\">\"+d+\"</a>\"")/*]]>*/</script>

Wadą tego typu rozwiązań jest możliwość odgadnięcia adresów e-mail przez bardziej wyrafinowane boty, które zdolne są do wykonywania kodu JavaScript. Istnieje również prawdopodobieństwo, że wraz z popularyzacją tego typu rozwiązań – metody te są łamane i dodawane do nowszych wersji robotów przeszukujących Sieć – tym bardziej, że rozłożenie pozycji klucza jak i zaszyfrowanego kodu zawsze jest stałym elementem. Nie mniej jednak jest to znacznie lepsza metoda niż czysty tekst.
Więcej informacji: Hide email address in source code

Dnia 07.11.2009

Sieci Zombie

S

ieci botnet są coraz bardziej rozpowszechnione. Z danych statystycznych wynika, że co 4 komputer domowy w sieci to Zombie. W jaki sposób się one rozprzestrzeniają, co potrafią i dlaczego nie można sobie z nimi poradzić – na te pytania Czytelnik uzyska odpowiedź po przeczytaniu tego artykułu.

Artykuł ten został opublikowany w numerze 7/2007 (27) magazynu hakin9.

Artykuł w formacie PDF

Dnia 06.11.2009

Nawet dość profesjonalny proftpd

P

rofesjonalny demon FTP posiada duże możliwości konfiguracji i składnię przypominającą plik konfiguracyjny serwera Apache. Obok demona Wu-FTP może pochwalić się szeregiem opcji niedostępnych w większości innych demonów ftp, w tym limitami dyskowymi, wirtualnymi serwerami i budową modularną pozwalającą na pisanie własnych modułów. Mimo, że jego dokładna konfiguracja może wymagać od nas większej uwagi (choć standardowa postać jego pliku konfiguracyjnego zapewnia już dość wysoki poziom bezpieczeństwa) serwer ten uważany jest za najbezpieczniejszy (korzystają lub korzystały z niego takie serwisy jak sourceforge.net oraz kernel.org).

Przesyłanie plików jest niezwykle istotne dla funkcjonowania systemu Linuksowego (o ile założenia danej komunikacji sieciowej nie wymagają korzystania z protokołu przesyłania plików – zaleca się wykluczenie możliwości korzystania z tej usługi). Decydując się na serwer FTP należy pamiętać, że w większości serwerów FTP wykorzystywana jest standardowa autoryzacja oparta na identyfikatorze użytkownika i haśle. Serwer nie może, więc z całą pewnością stwierdzić, że użytkownik jest tym, za kogo się podaje. Domyślnie hasła przesyłane są w postaci niezakodowanej. Pozwala to na założenie podsłuchu i przechwytywanie haseł, w dodatku także sesje FTP nie są szyfrowane, tym samym nie oferując prywatności. Gdy jednak funkcjonowanie serwera FTP jest koniecznością, istnieją różne jego metody ochrony. Postaram się omówić szerzej kilka sytuacji oraz sposobów zabezpieczenia demona proftpd (założenia dotyczące samego protokołu File Transfer Protocol określono w dokumentach RFC 0765, 0959, 2228, 2389). Sytuacje te głównie będą się tyczyć:

– zmiany komunikatu powitalnego – ponieważ zaleca się zmianę komunikatu wyświetlanego przez demon FTP bezpośrednio po nawiązaniu połączenia. Zależnie od stosowanego programu, ujawnić on może osobom niepowołanym: typ demona, wersję, platformę systemową jak i inne istotne dane.
- ograniczenia połączeń FTP – z którym wiąże się stosunkowo niebezpieczne zjawisko m.in. atak typu DoS. Standardowo, wiele programów określa tę wartość jako dość wysoką. Przy jej modyfikowaniu należy zachować roztropność. Przelicznikiem tej wartości może być poważne zastanowienie się ile połączeń dany serwer faktycznie jest w stanie obsłużyć.
- uprawnienia – bardzo ważną kwestią jest ścisłe określenie dla każdego użytkownika jego praw umieszczenia na serwerze i pobierania plików, jak również uprawnień dotyczących poszczególnych plików i katalogów.

Cały proces zaczynamy od pobrania najnowszych źródeł demona z serwera ftp.proftpd.org. Po ich pobraniu rozpakowujemy je poleceniami (w dystrybucji Slackware ProFTPD jest standardowym serwerem FTP w tej dystrybucji, który jest już skompilowany do formy gotowego do zainstalowania pakietu tak, więc tak samo można go pobrać z serwera ftp.slackware.com z sekcji N – etwork):

gunzip proftpd-1.2.9.tar.gz
tar -xvf proftpd-1.2.9.tar
rm proftpd-1.2.9.tar
cd proftpd-1.2.9

Następnie określamy szczegóły kompilacji programu za pomocą skryptu “configure” poprzez dodanie do niego odpowiednich opcji wywoławczych powodujących zmianę jego standardowych ustawień. ProFTPD instalowany jest standardowo w katalogu /usr/local/sbin/, jego składowe programy (ftpcount i ftpwho) w /usr/local/bin, plik konfiguracyjny w /usr/local/etc/ oraz strony manualne i pliki stanowe odpowiednio w /usr/local/man/, i /usr/local/var/proftpd/:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-shadow --with-modules=mod_readme:mod_ratio:mod_tls:mod_wrap
make
make install

Opisując poszczególne opcje: –prefix – określa ścieżkę gdzie zostanie zainstalowany program – w naszym przypadku /usr/sbin; –sysconfdir – położenie pliku konfiguracyjnego, czyli /etc/proftpd.conf; –localstatedir – w tym przypadku określamy położenie plików .log oraz .pid; –enable-shadow – wymuszamy używania mechanizmu szyfrowanych haseł; –with-modules – wymieniamy dodatkowe moduły, jakie mają być uwzględnione podczas instalacji programu. Wszystkie moduły znajdujące się w katalogu /modules po rozpakowaniu programu są standardowymi modułami, które zostaną wkompilowane w program chyba, że sami zdecydujemy o ich dezaktywacji (./configure –help). Dodatkowe moduły, które podlegają możliwości instalacji znajdują się w katalogu /contrib. Każdy z nich oferuje nam różne możliwości rozszerzenia samych możliwości programu ProFTPD. Np. moduł TLS umożliwia nam kryptografię transmisji plików na podstawie szyfrowania SSL i certyfikatów generowanych właśnie w tym standardzie, moduł wrap oferuje autoryzację na podstawie biblioteki TCP Wrapper. Więcej informacji na temat możliwości oraz opcji każdego z modułów znajdziemy w ich dokumentacji (jeśli skorzystaliśmy z pakietowej wersji proftpd listę wkompilowanych modułów możemy uzyskać poprzez wydanie komendy: proftpd -l). Skoro mamy już proces instalacji za sobą możemy przejść do samej konfiguracji serwera. Na samym początku skopiujemy dotychczasowy plik konfiguracyjny, a sami stworzymy nowy krok po kroku zawierając w nim użyteczne opcje, które będą wydawać się nam potrzebne:

cp /etc/proftpd.conf /etc/proftpd-standard.conf
echo "" > /etc/proftpd.conf

Poniżej zawarte opcje są ustosunkowane do wydajnością serwera. Chodzi głównie o ilość możliwych połączeń, obsługiwanych użytkowników oraz czasu bezczynności. Każdą z tych opcji należy dostosować do własnych potrzeb mając na uwadze możliwości własnej maszyny oraz łącza. W poniższym przykładzie nie zostało uwzględnione logowanie za pomocą konta anonymous, które umożliwia dostęp do serwera każdej osobie łączącej się zewnątrz. Jeśli pragniemy udostępnić taką usługę należy bezwzględnie przestudiować opcje pozwalające na ograniczony zapis czy odczyt plików na serwerze. Warto wspomnieć, że konta anonymous są 90% powodem udanych włamań na serwery FTP spowodowanych złą konfiguracją tego konta. Pozostałe 10% wynika z samych, wewnętrznych błędów oprogramowania. Powracając do tematu konfiguracji – zaczynamy oczywiście od edycji pliku oraz umieszczaniu w nim danych opcji:

ServerName "NARF Inc. FTP Server"

Określamy nazwę naszego serwera. W nazwie nigdy nie należy podawać nazwy oprogramowania oraz jego wersji.

ServerAdmin hostmaster@nfsec.org

Określamy adres kontaktowy z administratorem systemu – czyli nasz własny (należy usunąć spacje).

ServerType standalone

Określamy tryb uruchomienia serwera. Opcja standalone pozwala nam na niezależność demona ftp od innego np. inetd, w ten sposób jesteśmy w stanie kontrolować go jako osobny proces, a co za tym idzie – mamy możliwość nakładania na niego własnych ograniczeń względem połączeń.

Bind 217.25.72.175

Określamy adres, a tym samym interfejs, na którym ma nasłuchiwać serwer FTP. Opcja jest ta szczególnie przydatna, gdy np. serwer WWW, który jest aktualizowany przez pracowników łączących się wyłącznie z sieci lokalnej – wtedy nie mamy potrzeby udostępniania serwera FTP dla całego Internetu, lecz tylko dla danej sieci lokalnej wpisując w tej opcji adres wewnętrznego interfejsu, czyli podłączonego do sieci lokalnej. Jeśli posiadamy łącze stałe, lecz z dynamicznym adresem IP, należy nie uwzględniać tej opcji w pliku konfiguracyjnym – co spowoduje nasłuch na wszystkich możliwych interfejsach, a blokadę nie potrzebnych połączeń z kolejnych adresów możemy przeprowadzić za pomocą zapory sieciowej lub TCP Wrappers.

DeferWelcome on

Zezwalamy na komunikat powitalny dopiero po autoryzacji przez danego użytkownika.

DefaultServer on

Określamy by standardowa konfiguracja serwera była używana podczas przyjmowania wszystkich połączeń.

RequireValidShell on

Do poprawnej autoryzacji użytkownik musi posiadać przyznaną powłokę wylistowaną w pliku /etc/shells. Jeśli takowej nie posiada logowanie nie powiedzie się. Mechanizm ten pozwala nam na szybką blokadę dostępu do usługi FTP poprzez zmianę powłoki użytkownika.

ServerIdent on "NARF Inc. FTP Server Ready."

W tej opcji zmieniamy komunikat powitalny FTP. Zaleca się zmianę komunikatu wyświetlanego przez demon FTP bezpośrednio po nawiązaniu połączenia (w celu uniknięcia ataku typu banner grabbing). Zależnie od stosowanego programu, ujawnić on może osobom niepowołanym typ demona, wersję, platformę systemową i inne istotne dane. Standardowa konfiguracja pozwala w samej próbie połączenia uzyskać kilka podstawowych informacji: typ demona FTP i jego wersję. Potencjalnemu agresorowi nie pozostaje nic prostszego jak przejrzeć listę powszechnie znanych wad stosowanego programu (jeśli takie istnieją) i rozpocząć ich wykorzystywanie.

AccessGrantMsg "Welcome %u - your transfer is logged."

Definiujemy kod wiadomości 230 – oznajmiający użytkownikowi poprawne logowanie oraz ostrzegamy go, że jego poczynania w naszym systemie są monitorowane.

AccessDenyMsg "Login incorrect. Access denied for %u."

Definiujemy kod wiadomości 530 – oznajmiający użytkownikowi niepoprawne logowanie do serwera FTP.

Port 21

Nakazujemy nasłuch demona na porcie o numerze 21 według przyjętych międzynarodowych standardów. W przypadku, gdy pragniemy, aby nasz serwer w ogóle nie używał praw administratora (co jest dobrym pomysłem), wtedy należy podać port powyżej wartości 1025 – oraz dodać opcję RootRevoke on. W przypadku, gdy opcja ta zostanie zastosowana, a serwer będzie nasłuchiwał na porcie mniejszym niż 1025, czyli standardowo 21′rwszym – spowoduje to dezaktywację trybu aktywnego przesyłu danych pozostawiając tylko dostępny tryb pasywny (używany przez przeglądarki korzystające z adresów typu: ftp://). Decydując się na ten krok warto także dodać opcję: Passive Ports 49152 65534.

Umask 022

Ustalamy maske / standardowe prawa dostępu z jakimi będą tworzone nowe pliki oraz katalogi (więcej na temat praw dostępu możemy dowiedzieć się z artykułu “prawa dostępu do plików i katalogów”).

MaxInstances 15

Określamy maksymalną, dopuszczalną liczbę procesów, demona FTP, która może być uruchomiona na naszym systemie. Dzięki tej dyrektywie możemy ustrzec się przed atakami typu DoS, ograniczając zużycie serwera względem usługi FTP. Warto wspomnieć, że z limitem ilości połączeń FTP wiąże się dość ciekawe zagrożenie. Standardowo, może określać ono tę wartość jako stosunkowo wysoką. Dlatego przy jej modyfikowaniu, warto zachować zdrowy rozsądek. Przede wszystkim warto rozważyć ile strumieni połączeniowych nasz serwer faktycznie potrafi obsłużyć.

MaxLoginAttempts 2

Ilość nieudanych prób logowań, po których serwer zerwie z klientem łączność. Maksymalną wartością jaka może być w tym polu przyznana nie powinna przekraczać wartości 3, ze względu na możliwość próby ataku brute force.

MaxClients 10 "Server is full. Please wait."

Definiujemy maksymalną ilość klientów mogących naraz korzystać z serwera FTP. Wartość ta jest uzależniona od ilości posiadanych użytkowników w naszym systemie oraz ich gwarantowanym dostępie do konta przez FTP.

MaxClientsPerHost 2 "Two clients per one host only."

Określamy maksymalną ilość klientów mogących naraz korzystać z serwera FTP łącząc się z tego samego hosta docelowego. Jeśli udostępniamy serwer FTP wyłącznie komputerom pochodzącym z sieci lokalnej możemy prezentowaną wartość obniżyć do wartości jedynki będąc pewnym, że każdy komputer z sieci posiada jednego użytkownika przypadającego na nasz serwer FTP. W innym przypadku może się zdarzyć się z serwera, który jest autoryzowany do naszego serwera FTP konto posiada dwóch lub więcej użytkowników, którzy posiadają oficjalny dostęp do naszej maszyny. W tym przypadku należy odpowiednio zwiększyć powyższą wartość.

MaxClientsPerUser	2 "Download And Upload - And What?"

Jeśli posiadamy obawy, że zbyt duża ilość użytkowników z danego hosta może łączyć się z naszym serwerem to opcja ta pozwala na wprowadzenie limitu polegającego na określeniu maksymalnej, dopuszczalnej liczby połączeń przypadających na jednego użytkownika. Nadając jej wartość 1 – zmuszamy danych użytkowników do ściągania lub umieszczania plików z / na serwer. Jeśli posiadamy szybkie łącze oraz wydajny sprzęt serwerowy możemy umożliwić im wykonywanie tych czynności na raz poprzez nadanie tej wartości 2.

TimeoutIdle 120

Definiujemy przedział czasowy, w ciągu którego serwer przerwie połączenie jeśli w ciągu danej wartości czasowej nie zostanie odnotowana żadna aktywność ze strony użytkownika. Wartość ta określana jest w sekundach, czyli w naszym przypadku 2 minuty.

TimeoutLogin 60

Dyrektywa ta określa maksymalny w jakim użytkownik ma prawo do przeprowadzenia procesu logowania. Moim zdaniem jedna minuta to bardzo dużo czasu – szczególnie dla osób wstukujących 200 parę znaków na minutę, lecz nawet osoby dopiero uczące się pisania na klawiaturze powinny zmieścić się w tym przedziale.

TimeoutNoTransfer 180

Opcja określająca przedział czasowy, w którym użytkownik zobowiązany jest określić wszystkie zmienne (tryb i rodzaj przesyłu itp.) włącznie z lokalizacją pliku, który będzie pobierał / wysyłał z / na serwer. Standardowo opcja ta posiada wartość 300’stu sekund. Jednak należy się zastanowić czy wartość ta jest prawidłowa skoro nie prowadzimy żadnego serwera FTP z ogromem danych, które wymagają czasu by je przeszukać i znaleźć cel wizyty na serwerze FTP? Użytkownik logujący się na serwer FTP powinien posiadać sprecyzowany cel, do którego osiągnięcia powinny mu wystarczyć 3 minuty by przeszukać swoje dane.

TimeoutSession 86400 users !agresor,!firedoll

Ostatnim czasomierzem serwera jest określenie czasu całej sesji FTP. Zakładając, że na serwerze operuje się nie dość dużymi plikami – możemy ograniczyć czas trwania sesji do jednego dnia. Oczywiście zdarzają się wyjątki tak, więc z ograniczeń zwalniamy małą grupę użytkowników, którzy potrafią ściągać całymi dniami zapychając nasze łącze.

User ftp
Group ftp

Nakazujemy demonowi proftpd by po zakończeniu niezbędnych czynności wymagających praw administratora porzucił jego uprawnienia przyjmując prawa zwykłego użytkownika (ftp). Takie postępowanie daje nam gwarancje, że osoba która w jakiś sposób złamała zabezpieczenia serwera FTP nie przejmie całkowitej kontroli nam systemem jak to by miało mieć miejsce w przypadku, gdy serwer by działał z uprawnieniami administratora. Dlatego na tą okazję należy stworzyć użytkownika ftp, który będzie posiadał zablokowane konto (passwd -l ftp lub wstawiamy “*” w drugim polu pliku /etc/passwd odnoszącym się do tego konta) oraz brak możliwości logowanie się do systemu (jego powłoką powinno być pseudo urządzenie /dev/null lub /bin/false).

SystemLog /var/log/proftpd
TransferLog /var/log/xferlog
ExtendedLog /var/log/ftpsnif
ExtendedLog /dev/tty7
PidFile /var/run/proftpd.pid
ScoreboardFile /var/run/proftpd.scoreboard

Określamy położenie plików dziennika, w których zapisywane będą informacje dotyczące połączeń z naszym serwerem FTP, przesyłaniem plików (wysyłaniem oraz ściąganiem) pomiędzy klientem, a serwerem oraz poszczególne komendy, których użyli użytkownicy przebywając zalogowani przez usługę FTP. Przed ostatnia linijka wymienionych opcji dotyczy miejsca, gdzie zostanie zapisany plik posiadający numer procesu przyznanego ProFTPD w celu jego identyfikacji w systemie. Ostatni wpis ustawia położenie pliku gdzie nasz demon będzie przechowywał informacje na temat aktualnych sesji. Plik ten jest niezbędny dla poprawnego działania dyrektywy MaxClients jak i takich narzędzi jak ftpwho i ftpcount, które potrafią dostarczyć nam informacji w czasie rzeczywistym o osobach działających na serwerze FTP.

DefaultChdir ~
DefaultRoot ~

Powyższe dwie opcje określają pole na jakim uprawniony użytkownik jest w stanie działać w systemie przy pomocy usługi FTP. Pierwsza z nich określa katalog, do którego zostanie przeniesiony użytkownik zaraz po zalogowaniu się do systemu – tylda określa jego domowy katalog. Druga opcja powoduje uwięzienie go w tym katalogu tym samym izolując go od innych krytycznych zasobów systemu jak i innych użytkowników – tym samym powodując, że jego działania będą tylko i wyłącznie tyczyły się jego konta systemowego. Są to bardzo przydatne opcje powodujące brak możliwości poruszania się po systemie użytkownika jak to ma miejsce w przypadku zwykłego zalogowanie się do powłoki.

RootLogin off

Opcja ta nawet jeśli by nie została zawarta w pliku konfiguracyjnym pozostaje pod taką postacią standardowo. Więc czemu ją tu wstawiać? By mieć podwójną pewność? Też. Ale stanowi dobry pretekst by wytłumaczyć, że zezwalając na możliwość jakiejkolwiek akceptacji do sieciowego zezwolenia logowania administratora popełniamy wielki błąd. Opcja ta po wpisaniu poprawnego loginu i hasła użytkownika root – proftpd nie pozwoli na jego zalogowanie. Nawet w przypadku włączenia tej opcji w tryb On – nasz demon za pomocą programu syslog prześle odpowiednią adnotacje do logów systemowych.

DefaultTransferMode binary

Jest to raczej opcja udogadniająca niż mająca wpływ na bezpieczeństwo serwera. Określona ona po prostu standardowy tryb przesyłania plików poprzez serwer FTP (bin – binarny ; ascii – tekstowy).

DeleteAbortedStores on

Jest to bardzo przydatna konfiguracja związana z zadbaniem zajętości dysku. Podczas wrzucania większego pliku na serwer, czasami może się zdarzyć, iż pomyliliśmy pliki lub zmieniliśmy zdanie – w tym celu anulujemy tzw. upload (do serwera przesyłana jest komenda ABOR). Część pliku który przez ten czas został wrzucony pozostaje na serwerze zajmując miejsce. Po zakończeniu tej operacji należy odczekać na przerwanie połączenia; ponowne odczytanie i wyświetlenie aktualnej zawartości katalogu. Po uaktywnieniu tej opcji nasz serwer FTP automatycznie będzie kasować fragmenty plików z niedokończonych sesji – przez co po rozmyśleniu się możemy nie martwiąc się o nic zerwać zupełnie połączenie z serwerem.

HiddenStor on

Opcja powiązana z jej poprzedniczką. Mamy już zabezpieczenie przed niedokończonymi transferami, ale jak się zabezpieczyć przed możliwością używania pliku dopiero po jego całkowitym transferze? Właśnie poprzez wyżej wymienioną opcję. Zakładając przypadek, w którym strona internetowa korzysta z systemu nowości – najnowsze informacje dotyczące aktualnego dnia są właśnie umieszczane na serwerze – plik jest w 50% przegrany – i w tym samym czasie użytkownik odwiedza stronę w celu przeczytania dzisiejszych wydarzeń – ku jego zdziwieniu jeden z artykułów kończy się w 1/3 długości. By temu zapobiec należy uaktywnić bezpieczny upload. Powoduje on zapisywanie pliku podczas jego transferu w postaci: “.in.nazwa_pliku” – i dopiero w momencie jego całkowitego i ukończonego powodzeniem umieszczenia na serwerze – zmienia jego nazwę na oryginalną. W ten sposób nasz system newsów – który oczywiście posiada sprawdzanie przed wyświetleniem artykułu czy dany plik istnieje poinformuje, odwiedzającego użytkownika, iż artykuł jest jeszcze nie gotowy.

MaxRetrieveFileSize 25 Mb group users
MaxRetrieveFileSize *
MaxStoreFileSize 25 Mb group users
MaxStoreFileSize *

Stos opcji określających maksymalny rozmiar pobieranego (retrieve) / wysyłanego (store) pliku. W powyższym wypadku ograniczamy tylko grupę użytkowników (users), reszta grup i należących do nich użytkowników nie posiada żadnych ograniczeń (*). Ograniczenia możemy określać poprzez jednostki od Gigabajtów (Gb) po Mega (Mb); Kilo (Kb), a nawet poszczególne bajty (B). Dodam tylko, że przelicznikiem limitu może być 55% – 70% objętości konta, ponieważ dwa pliki po 50% każdy zmieszczą się na serwerze, jednak 2 x 55% – już nie – dlatego najlepiej przed tym doświadczeniem uchronić użytkowników którzy posiadają jeszcze jakieś złudzenia.

TransferRate RETR 25.0:204800 group !vipusers
TransferRate APPE,STOR 30.0:204800 group !vipusers

Wprowadzamy limity zużycia łącza. Pierwszy wpis tyczy się pobierania plików z serwera, a jego interpretacja jest następująca: wszyscy oprócz grupy użytkowników – vipusers (! – pełni rolę negacji – czyli wszyscy oprócz) – będą mogli pobierać małe pliki (do 200 Kb – 200b x 1024 = 204800) – z maksymalną prędkością aktualnie oferowaną przez cały serwer – jeśli plik będzie posiadał większą pojemność od 200 Kb serwer ograniczy transfer do 25 Kb/s. Drugi wpis posiada tą samą regułę, lecz odnosi się ona do umieszczania plików na serwerze, oraz limit w przypadku większych plików wynosi 30 Kb/s. Jeśli chcemy zastosować limity do tylko jednej grupy użytkowników – wystarczy usunąć znak “!” oraz wpisać nazwę danej grupy.

DisplayConnect /etc/issue.net

Jest to mały zabieg kosmetyczny związany z poinformowaniem użytkowników łączących się z naszym serwerem FTP. W pliku issue.net, w którym zapisana jest informacja dotycząca ogólnie serwera – możemy umieścić info o możliwości uwierzytelniania tylko przez powołane osoby, w ten sposób ostrzegając przypadkowych wizytantów o rezygnacji z połączenia. Plik issue.net może zawierać przykładową treść:

Welcome to The Network Server:
Unauthorized Access Prohibited
---

Do pliku issue.net możemy także odwołać inne demony oferujące wyświetlanie banerów ostrzegawczych np. OpenSSH – w ten sposób nie będziemy musieli tworzyć osobnych plików o identycznej zawartości.

ListOptions "+a"

Normalnie do komend FTP listujących zawartość katalogów możemy dodać parametry, które decydują jakie pliki mają być wyświetlone, a jakie nie. Poprzez dodanie do powyższej dyrektywy opcji “+a” powodujemy, że parametr listujący wszystkie pliki, nawet te ukryte będzie ignorowany, czyli po wydaniu komendy: ls -a – zawsze będzie ona traktowana jako zwykła komenda: ls – w ten sposób ukryte pliki systemowe nie będą widzialne dla użytkownika.

<Directory />
  AllowOverride off
  HideNoAccess on
<Limit CWD PWD LIST>
  IgnoreHidden on
</Limit>
</Directory>

Kończący naszą standardową konfigurację stos opcji. Pierwszy wpis tyczy się przeszukiwania plików .ftpaccess w katalogach użytkowników. Pliki te regulują dostęp do serwera FTP (tak samo jak pliki .htaccess w Apaczu tak tutaj .ftpaccess). W standardowej konfiguracji opcja ta jest zezwolona. Jednak radzę ją wyłączyć, ze względu na to, że użytkownicy nigdy nie powinni decydować o zezwalaniu na jakiekolwiek połączenia (nawet jeśli tyczą się one wyłącznie ich kont) – unikniemy w ten sposób możliwości odblokowania naszych restrykcji połączeń wprowadzonych na cały serwer. W przypadku wyjątku od reguły możemy zastosować wpis: AllowOverride on login_użytkownika – w ten sposób zezwalając pojedynczemu, a zarazem naprawdę zaufanemu użytkownikowi możliwość zezwalania oraz odmawiania połączenia z jego kontem FTP. Kolejna opcja – HideNoAccess – powoduje ukrywanie przed użytkownikami katalogów, do których nie posiadają dostępu (mają brak praw dostępu lub w ogóle nie są ich właścicielami). W ten sposób możemy dokładnie zinterpretować powiedzenie – czego oczy nie widzą tego dusza nie pragnie. Ostatnia opcja odnosząca się do limitu przy użyciu komend listingu oraz operacji na aktualnym katalogu jak i jego zmianie – powoduje ignorowanie wyświetlania plików ukrytych, czyli tych zaczynających się od “.” np. .bash_history. Jeśli dane konto zostało stworzone dla potrzeb strony www lub przechowywania plików programowych – nie ma potrzeby zajmowania ekranu użytkownika plikami konfiguracyjnymi jego konta, do którego nie posiada dostępu (lub jeśli posiada to może pliki te skonfigurować poprzez używanie nadanej mu powłoki).

Pozostaje nam teraz tylko blokada innych – systemowych kont, by nie zostały one wykorzystane do celów próby logowania przez serwer FTP. W tym celu wystarczy ich identyfikatory systemowe w formie loginów wprowadzić do pliku /etc/ftpusers. Dla przykładu mogą to być takie konta jak:

www
nobody
mail
pop
root
ftp
oidentd
ssh

  Na koniec wspomnę tylko dla tych zainteresowanych, którzy bardzo pragną posiadać konto anonymous (dostępne publicznie – choć jeszcze raz przypominam – jeżeli połączenia anonimowe muszą być dostępne, wymagana jest niezwykła dbałość o ustawienia uprawnień dostępu do plików i katalogów) – niech zainteresują się następującymi opcjami: Anonymous, AllowFilter, AnonRejectPasswords, DirFakeMode, DirFakeUser, DirFakeGroup i GroupOwner, a także dokładnie przeanalizują przykładowy plik konfiguracyjny dla tego konta dostarczony wraz ze źródłami lub dokumentacją (w zależności od tego czy posiadamy wersję pakietową) ProFTPD. Dobrym pomysłem by było także stworzenie osobnej partycji dyskowej na te cele lub nawet umieścić “anonimową” usługę FTP na jednym systemie, który nie zawiera żadnych poufnych danych i który będzie umieszczony na zewnątrz sieci firmowej. Bardzo dobrą alternatywą jest zastąpienie publicznego FTP dobrze skonfigurowanym serwerem Apache, który może symulować serwer FTP oraz udostępniać publicznie wybrane pliki oraz katalogi. Po zakończeniu jakiejkolwiek konfiguracji polecam uruchomienie serwera ProFTPD na pierwszym planie z odpowiednim poziomem debugowania pracy, co pozwoli na analizę pracy i ewentualne poprawienie błędów: proftpd -n -d 5

Bonus:  Poniżej postaram się przedstawić dwa sposoby na uzyskanie prostego poza systemowego (innego niż /etc/passwd) źródła autoryzacji dla serwera FTP. Pierwszą z nich będzie prosta konfiguracja, która pozwoli na odizolowanie użytkowników od naszego systemu oraz pozwoli na nadanie im zupełnie innego hasła niż posiadają przy używaniu powłoki – oto ona: Na początek przed sekcją <Directory /> musimy dodać opcję określającą, skąd ProFTPD ma odczytywać dane o audytucie użytkowników:

AuthUserFile /etc/ftp/ftpd.passwd
AuthGroupFile /etc/ftp/ftpd.group

Jak sami widzimy, określają one miejsce podstawowych plików autoryzacji zawierających informacje o grupach oraz użytkownikach. Następnie by nie tylko hasła naszych użytkowników były inne, ale także ich loginy użyjemy mechanizmu aliasów w celu zmiany ich loginów dla serwera FTP:

AuthAliasOnly on
UserAlias wingzero agresor

Jest to pojedynczy przykład, lecz aliasy należy stworzyć dla wszystkich użytkowników korzystających z serwera FTP (format: alias login). W przypadku, gdy ktoś podsłucha naszą transmisję – login i hasło – będzie on posiadał tylko dostęp poprzez FTP – dość duża izolacja względem systemu zostanie zachowana. Kolejnym krokiem jest stworzenie fizycznych potwierdzeń dokonanej konfiguracji. Do kontynuacji tej czynności będą nam potrzebne źródła ProFTPD rozpakowane do głównego katalogu root (jak tego dokonać opisano wyżej) – ponieważ będziemy wykorzystywali w tych pracach narzędzie dostarczone przez TJ Saunders’a o nazwie ftpasswd (program ten wymaga wsparcia języka Perl).
Zaczynamy od utworzenia podstawowych plików oraz katalogów (komendy wydajemy z macierzystego katalogu root):

mkdir /etc/ftp
chown root:ftp /etc/ftp
chmod 770 /etc/ftp
cp proftpd-(wersja)/contrib/ftpasswd /etc/ftp
cp /etc/group /etc/ftp/ftpd.group
cd /etc/ftp
chown ftp:ftp ftpd.group
chmod 660 ftpd.group

Po przygotowaniu gruntu pod działkę możemy zacząć dodawać użytkowników. By zachować kompatybilność z prawami systemowymi użytkownika, musimy sklonować jego preferencje z wpisu znajdującego się w pliku /etc/passwd. Posłuży nam do tego komenda: cat /etc/passwd|grep login – gdzie login – jest to odpowiedni użytkownik, który ma posiadać konto FTP. Należy pamiętać by dodać wszystkie osoby, które mają mieć możliwość korzystania z usługi FTP – oczywiście z pewnością możemy pominąć tych, którzy posiadają u nas tylko usługę poczty. W powyższych komendach kopiujemy plik z wpisami grup – jeśli zaszły jakieś w oryginalnym pliku systemowym – bezzwłocznie należy go uaktualnić. Po odczytaniu odpowiednich wartości możemy dodać pierwsze konto użytkownika:

echo /bin/false >> /etc/shells
./ftpasswd --passwd --name=agresor --uid=1000 --gid=100 --home=/home/of/agresor --shell=/bin/false

Po wydaniu ostatniej komendy program po prostu spyta się nas o hasło. Hasło jest standardowo szyfrowane poprzez funkcję MD5. Zostanie stworzony plik ftpd.passwd – posiadający taką samą strukturę jak dawny plik passwd – czyli będą w nim przechowywane zaszyfrowane hasła oraz informacje odnośnie kont użytkowników. Dlatego teraz zadbamy by tylko demon ProFTPD miał prawa do jego odczytu i zapisu – tak samo jak takie prawa posiada administrator (root) do pliku shadow (więcej informacji jak usuwać oraz dodawać czy modyfikować za pomocą narzędzia ftpasswd dowiemy się z pliku ftpasswd.html):

chown ftp:ftp ftpd.passwd
chmod 600 ftpd.passwd

Jeśli nasz serwer FTP został uruchomiony z innym identyfikatorem użytkownika niż ftp (lecz jest to także zwykły użytkownik), oczywiście należy podstawić odpowiednie wartości w wiersze komend, gdzie jest używany identyfikator demonstrujący np. jeśli zdecydowaliśmy się na użytkownika “nobody” wtedy zamiast wpisów z użyciem “ftp” używamy swojego “człowieka”. Druga metoda uwierzytelniania poza systemowego wykorzystuje bazę danych SQL (MySQL i PostreSQL). By uzyskać taki efekt wystarczy skompilować demona ProFTPD z modułem mod_sql – uwzględniając poprzednie moduły:

./configure --with-modules=mod_readme:mod_ratio:mod_tls:mod_wrap:mod_sql:mod_sql_mysql --with-includes=/usr/local/mysql/include --with-libraries=/usr/local/mysql/lib

Oczywiście, należy podać ścieżkę do swojej instalacji serwera MySQL, jeśli nie jest to katalog /usr/local/mysql – pomocną tutaj może być komenda: whereis mysql. Następnie kompilujemy i instalujemy kod poprzez komendy: make i make install. Przyszła kolej na utworzenie bazy danych, z której ma korzystać demon proftpd (serwer MySQL musi być już zainstalowany oraz sprawnie działać) – musi ona mieć dostęp w trybie tylko do odczytu z naszego demona FTP:

mysqladmin create proftpd
mysql -e "grant select on proftpd.* to proftpd@localhost identified by 'secret';"

Po dokonaniu tych czynności tworzymy dwie tabele w bazie danych o danych schematach. Zapiszemy je w pliku proftpd.tables: poprzez komendę touch proftpd.tables, a następnie edytujemy go za pomocą ulubionego edytora np. nano proftpd.tables – i wpisujemy do niego dwie następujące tabele:

CREATE TABLE users (
userid varchar(30) NOT NULL default '',
password varchar(30) NOT NULL default '',
uid int(11) default NULL,
gid int(11) default NULL,
homedir varchar(255) default NULL,
shell varchar(255) default NULL,
UNIQUE KEY uid (uid),
UNIQUE KEY userid (userid)
) TYPE=MyISAM;
CREATE TABLE groups (
groupname varchar(30) NOT NULL default '',
gid int(11) NOT NULL default '0',
members varchar(255) default NULL
) TYPE=MyISAM;

Teraz należy dodać te tabele do naszej bazy danych poprzez polecenie: mysql proftpd proftpd.tables. Teraz tak samo jak w poprzednim przypadku należy poinformować demon ProFTPD, że ma korzystać z bazy danych do uwierzytelniania użytkowników. Tak więc dodajemy następujące wiersze do /etc/proftpd.conf przed sekcją <Directory />:

SQLConnectInfo proftpd proftpd secret
SQLAuthTypes crypt backend
SQLMinUserGID 100
SQLMinUserUID 1000

Wiersz

SQLConnectInfo posiada konstrukcję: “nazwa_bazy_danych login hasło”. Jeśli chcemy sobie jeszcze bardziej pobiegać po komputerach możemy użyć bazy danych pochodzącej z innego serwera naszej sieci: SQLConnectInfo proftpd@bazadanych.nfsec.org:port login hasło. Wiersz SQLAuthTypes pozwala utworzyć użytkowników z hasłami zapisanymi w standardowym uniksowym formacie lub w formacie funkcji MysQL: PASSWORD(). Dlatego należy pamiętać, że przy korzystaniu z funkcji logowania modułu MySQL trzeba zabezpieczyć logi, w których mogą pojawić się hasła w postaci tekstu czytelnego. Opcja SQLAuthTypes zabrania używania haseł pustych (empty). Ostatnie dwa wiersze, czyli SQLMinUserGID i SQLMinUserUID określają minimalny identyfikator grupy i użytkownika, który demon ProFTPD ma dopuszczać do logowania. Musimy pamiętać, aby to była wartość większa od zera (aby zapobiec możliwości logowania użytkownika root), lecz powinna być niska, ponieważ potrzebne są właściwe uprawnienia w systemie plików. W systemie Slackware mamy grupę users posiadającą GID = 100 oraz pierwszy dodany użytkownik posiada UID = 1000. Ponieważ użytkownicy ci powinni móc logować się z tymi uprawnieniami, musimy ustalić minimalne wartości jako 100 i 1000. Teraz możemy dodać pierwszego użytkownika do bazy danych. Poniższe polecenie utworzy użytkownika agresor, z prawami użytkownika jego samego i grupy users. Po poprawnym zalogowaniu do systemu, będzie on skierowany do katalogu /home/of/agresor:
mysql -e "insert intro users values ('agresor',PASSWORD('enterFTP'),'100','1000',
'/home/of/agresor','/bin/false');" proftpd

Hasło użytkownika agresor jest szyfrowane funkcją PASSWORD() serwera MySQL przed zapisaniem. Wiersz /bin/false jest przekazywany do demona ProFTPD w celu przesłania dyrektywy RequireValidShell (patrz wyżej) demona FTP. Oczywiście nie ma to żadnego związku z przyznaniem faktycznego dostępu do interpretera poleceń użytkownikowi. Pokazane tutaj możliwości modułu MySQL to tylko mała demonstracja. Moduł ten ma większe horyzonty – może on m.in. łączyć się z istniejącymi bazami danych MySQL z dowolnymi nazwami tabel, rejestrować całą aktywność w bazie danych, modyfikować wyszukania użytkowników dowolną klauzulą WHERE.

Więcej informacji: ProFTPd Docs, Proftpd, Mod_SQL

Dnia 02.11.2009

Niebezpieczne nazwy plików

P

rogramiści, zarówno początkujący, jak i profesjonaliści, mają tendencje do pokładania przesadnego zaufania w poprawności otrzymywanych z zewnątrz nazw plików. W konsekwencji ich aplikacje mogą stać się wejściem do systemu dla potencjalnego włamywacza.

Artykuł ten został opublikowany w numerze 01/2008 (33) magazynu hakin9.

Artykuł w formacie PDF