_-¯ Wczorajszo-dzisiejsze zamieszanie związane z zaginięciem mojego poradnika pt. ,,Jak przejmować konta na Tibii'' kolejny raz uświadomiło mi jak ważne jest regularne wykonywanie kopii zapasowych cennych danych. Gdyby nie wyrobiony przez lata nawyk, by wszystkie istotne informacje przechowywać w kilku dobrze zabezpieczonych kopiach - zapewne oryginalna treść ,,Poradnika...'' przepadłaby na zawsze. Na szczęście, parafrazując znane powiedzenie o czekistach - chakierem się nie bywa, chakierem się jest.

_-¯ W tym miejscu chciałbym się Państwu pochwalić, że swego czasu na własne potrzeby opracowałem nowoczesny i nowatorski mechanizm tworzenia kopii zapasowych, który postaram się zaprezentować w paru słowach. Jak wiadomo - powszechną praktyką tworzenia backupu jest co jakiś czas tworzenie pełnej kopii zbioru posiadanych danych (np. co miesiąc). Następnie, bazując na tym zbiorze nieco częściej tworzy się kopie różnicowe (np. co tydzień), a bazując na kopiach różnicowych jeszcze częściej tworzy się kopie przyrostowe (np. codziennie). Zestaw: kopia pełna + kopia różnicowa + kopia przyrostowa umożliwia nam odtworzenie zbioru danych z dowolnego dnia. Mechanizm ten działa bardzo dobrze, ale ma następujące uciążliwe ograniczenia:

• trzeba stworzyć dane, które chcemy zbackupować
• do momentu wykonania pierwszego backupu dane nie są chronione

W tym momencie ktoś mógłby powiedzieć, że przecież taka jest naturalna kolej rzeczy. Miałby rację. Jednak wymyślony przeze mnie mechanizm backupu eliminuje także te niedogodności! Opracowałem go wspólnie z moim przyjacielem, profesorem Wielomysłem Nigdziebądziem, światowej sławy fizykiem-praktykiem. Bazuje on na wyprowadzonych przez Wielomysła równaniach czasoprzestrzeni urojonej, gdzie t² = -1. Nie chcąc się wdawać w szczegóły powiem Państwu w skrócie, że wynika z tego mniej więcej tyle, że skoro dzisiejsza kopia - w przypadku utraty danych jutro - może stać się pojutrzejszymi danymi, to proces ten jest symetryczny na osi czasu względem punktu wykonania kopii! Zatem, nie jest ważne czy z punktu poniedziałkowych danych patrzymy poprzez wtorkowy backup na dane środowe, czy vice-versa. Pozwala nam to właściwie wyeliminować zmienną określającą czas z procesu backupowania. A skoro kopie bezpieczeństwa do tej pory były funkcją w czasie właśnie, a czas (jak to przed chwilą udowodniliśmy) - można pominąć, zatem nie jest ważne kiedy stworzymy kopię, ale gdzie. Z wyników równań oraz symulacji, które prowadzimy wspólnie z Wielomysłem póki co wychodzi, że najodpowiedniejszym miejscem jest kuchnia - ale o tym napiszę innym razem.

_-¯ Skoro zatem nie jest ważne kiedy, nie ma również relacji ,,co było pierwsze? dane, czy kopia''? Zatem - i tu proszę się złapać mocno krzeseł - fakt zaistnienia kopii danych nie wymaga wcześniejszego zaistnienia tych danych oryginału!, gdyż zależność wcześniej-później nie istnieje, co wynika bezpośrednio ze wzorów. Ergo - można (i na tym opiera się mój mechanizm) najpierw stworzyć kopię danych, by potem te dane z tej kopii odtworzyć. Dla odróżnienia od zaprezentowanych wcześniej rodzajów kopii bezpieczeństwa nazwałem takie niezależnie w czasie kopie odpowiednio: ubytkowe, sumowe i puste. Podkreślę to jeszcze raz: możemy je utworzyć w dowolnym momencie, nawet nie posiadając danych, nazwijmy je ,,bazowych'', które chcielibyśmy zabezpieczyć. Tylko tyle i aż tyle...

_-¯ Tak też postąpiłem w przypadku mojego, wspomnianego na wstępie, ,,Poradnika...''. Najpierw stworzyłem kopię pustą, potem kopię sumową z zeszłego weekendu, a następnie kopię ubytkową. Dodatkową zaletą tak przeprowadzonego procesu backupowania jest fakt, że wcale żadnego poradnika nie musiałem pisać. Odtworzyłem go po prostu ze wspomnianych kopii bezpieczeństwa!

_-¯ Postanowiłem zrobić małe podsumowanie tego, co się w dziedzinie bezpieczeństwa systemów komputerowych działo przez ostatni miesiąc. A działo się - proszę mi wierzyć - sporo.

_-¯ Zacznę od plagi wirusów które zaczęły nawiedzać użytkowników dość egzotycznego systemu o nazwie Linux. Twórcy tego systemu wykorzystali do jego ochrony bardzo sprytną sztuczkę, mianowicie sprawili że Linux jako-taki nie istnieje. Nie można iść do sklepu i kupić sobie pudełko z Linuksem, tak jak to się robi np. z Windows Vista. Użytkownicy wielu eksperymentalnych systemów o dziwacznie brzmiących nazwach (np. Ubuntu, Slackware, Debian, Fedora etc.) nawet nie zdawali sobie sprawy że tak naprawdę mają na swoich komputerach właśnie Linuksa. Zresztą - tak samo nie zdawali sobie z tego sprawy twórcy wirusów. Jednak, jak się okazało - do czasu...
Na zlecenie jednego z głównych producentów malware'u kilka wiodących firm przeprowadziło śledztwo, którego wyniki okazały się być przełomowe - większość nie-windowsowych systemów operacyjnych to pochodne systemu Unix®, z czego znaczna część to właśnie Linuksy! Dodatkowo odkryto, że twórcy Linuksa poza 'zabezpieczeniem' go poprzez ukrycie jego prawdziwego pochodzenia (tzw. security by obscurity) nie zastosowali żadnych innych mechanizmów ochronnych. Gdy czytałem raport nie wierzyłem własnym oczom, ale rzeczywiście napisano w nim prawdę: uzyskanie dostępu do głównego serwera kernel.org i wykradzenie stamtąd źródeł jądra systemu Linux zajęło początkującym chakierom mniej niż pół godziny...
Oczywiście, skutki tak fatalnych zabezpieczeń nie dały na siebie długo czekać. W ciągu niespełna 48 godzin powstało siedemnaście tysięcy linuksowych wirusów, a ich liczba podwaja się mniej więcej co dobę...

_-¯ Kolejną rzeczą która odbiła się szerokim echem w informatycznym światku była premiera zaprojektowanego przeze mnie beznośnikowego systemu przechowywania informacji o nieograniczonej pojemności. Zasada działania systemu jest prosta i polega na opisanym przeze mnie systemie kryptograficznym omnicrypt. Po przesłaniu na serwer dane użytkownika szyfrowane są dla bezpieczeństwa omnicryptem i kanałem zwrotnym otrzymuje on klucz identyfikujący jednoznacznie zachowane przez niego zasoby. Odzyskanie zasobu polega na zalogowaniu się do systemu i podaniu klucza identyfikującego przechowywane dane. Podczas trwających tydzień testów udało się za pomocą omnicrypta w pustym pliku tekstowym zachować (oraz poprawnie z niego odtworzyć) ponad siedemset eksabajtów danych.

_-¯ Kolejna rzecz o której chciałem wspomnieć to bezpieczeństwo systemów bankowych. Nie było o nim tak głośno jak o słynnym napadzie na strumień danych z transmisji sejmu, lecz jest to zrozumiałe - bankom nie zależy na rozgłosie. Mianowicie - z paru setek kont w trzech wiodących bankach działających na polskim rynku 'zniknęło' w tajemniczych okolicznościach około dwustu milionów złotych. Zostałem wynajęty jako ekspert do zbadania tej sprawy, jednak muszę przyznać że złodzieje wykazali się nie lada sprytem transferując pieniądze przez urządzenie /dev/null. Na razie jestem w trakcie pisania narzędzia potrafiącego podjąć tak zostawiony trop. Póki co jednak naprawiłem bankowe finanse modyfikując bezpośrednio bazy danych za pomocą poleceń SQL. Prawdę powiedziawszy nawet ustawiłem im trochę wyższe salda, ale nadwyżkę zaraz przelałem na swoje konto. Tak, żeby się zgadzało - i żeby wszyscy byli zadowoleni...

_-¯ Koniec miesiąca przyniósł też ciekawą informację o grupie chakierów którym udało się oszukać systemy biletowe komunikacji miejskiej. Opracowane przez nich metoda ochrzczona nazwą 'per pedes' pozwala przemieszczać się z umiarkowaną prędkością w dowolne miejsce metropolii. I to za darmo!