Porażka systemu wyborczego PKW

Jak powszechnie wiadomo, przy wyborach samorządowych zaliczyliśmy malowniczego w tym roku malowniczego faila. Nie, żeby było to trudne do przewidzenia, biorąc pod uwagę błędy w zabezpieczeniach widoczne już wcześniej. No, ale powiedzmy, że niezabezpieczenie maszyn developerskich może się zdarzyć najlepszym i nie musi rzutować na zachowanie produkcji.

Tak się składa, że w pewnym okresie mojego życia miałem regularne doświadczenia z komisjami. Pierwszy raz pracowałem w komisji dawno temu, gdy jeszcze każdy mógł się zgłaszać samodzielnie (a nie przez partię) i było losowanie wśród zgłoszonych. Miało to pewne wady, więc zmieniono sposób zgłaszania kandydatów do komisji – musiały robić to komitety wyborcze. I z tym sobie poradziłem, bo zawsze znalazł się ten czy inny komitet wyborczy, który nie wymagał bycia partyjnym aktywistą i po prostu zgłaszał studenta, który chciał sobie dorobić. Tu też mam pewne ciekawe doświadczenia i przemyślenia, ale to może przy innej okazji. Koniec końców, w młodym wieku miałem całą procedurę dobrze opanowaną, parokrotne doświadczenie, spory dystans do którejkolwiek partii politycznej… Jednym słowem, bezstronny wyborczy gun for hire.

Zwieńczeniem mojej kariery okołowyborczej było wystawienie mnie przez jeden z komitetów jako… męża zaufania. Tu akurat znajomi organizowali partii kampanię i szukali zaufanych ludzi znających się na rzeczy. Pamiętam, że już wtedy średnio się kwapiłem do pracy w komisjach ze względu na stawki. No ale jako mąż zaufania jakoś lepsze pieniądze dostałem (a pracy mniej), więc jakoś poszedłem.

Pamiętam, że były to chyba pierwsze „zinformatyzowane” wybory. Pamiętam, że samo liczenie poszło komisji, nawet sprawnie, natomiast pojawiły się „problemy z systemem”. IIRC rzecz działa się w szkole. Szkolny informatyk robił za obsługę informatyczną lokalu i rozłożył ręce przy wprowadzaniu. System „nie przyjmował” danych z karty (poprawnie wypełnionej). IIRC poszło m.in. o nieprzyjmowanie ilości kart nieważnych innej niż zero. Komisja wpadła na pomysł, że w sumie w takim razie najprościej będzie… poprawić na protokołach na zero, bo w sumie i tak nieważne. I byliby to chyba zrobili, gdybym nie uświadomił, że od razu mogą wpisać mój protest na protokole i najpewniej do rana nie wyjdą, bo centrala ich cofnie do poprawki.

Atmosfera na moment zgęstniała, ale niedługo później okazało się, że nie tylko my mamy problem (wcześniej jakoś nikt takiej informacji nie udzielił), nie działa więcej rzeczy i przyszło z centrali zarządzenie, że olać system informatyczny, przechodzimy na ręczne. Czyli, że robimy wszystko po staremu i wszystko mamy gotowe do zawiezienia. Tak czy inaczej, wtedy system zaliczył malowniczą porażkę. Swoją drogą przez tego typu akcje (robisz dobrze, siedzisz parę godzin dłużej) i brak przewidywalności czasu trwania pracy (bo w komisji jednak różni ludzie się trafiają) zniechęciłem się ostatecznie do siedzenia w komisjach.

Teraz mamy powtórkę. Znajomi z IT są bardzo rozbawieni słysząc o problemach z 3 tys. jednoczesnych połączeń. Nie dziwię się. Zaprojektowanie systemu, który przyjmie dane nie jest trudne. Dziwi mnie – i nie tylko mnie – co innego. Mianowicie, czemu co roku projektuje się i wykonuje system od zera, bez żadnego doświadczenia z lat ubiegłych? Jaki byłby problem z tym, żeby specyfikacja protokołu była prosta i jawna, część zarówno serwerowa, jak i kliencka rozwijana jako open source i używana ponownie przy każdych wyborach? Przecież format protokołu praktycznie się nie zmienia. I jest bardzo prosty. Spokojnie można studentom jako zadanie na zaliczenie semestru zadać opracowanie formatu przesyłu danych[1]. Dokumentacja systemu też na wolnej licencji, żeby łatwo można było odtworzyć – i w razie potrzeby poprawić – środowisko.

Żeby nie było, że tylko firma winna, IMHO sporą winę za sytuację ponosi PKW, która powinna być w stanie w dowolnym momencie przejść skutecznie na system ręczny. Informatyzacja wyborów to jedynie bonus, nie ich sedno. Ale u nas pokutuje wciąż – nie tylko przy wyborach – bożek systemu informatycznego, najwyższej wyroczni i zarazem wykładni. System nie pozwala i koniec, bo system to rzecz święta.

Na Niebezpieczniku jest dobry artykuł nt. wyborów, w którym jest więcej informacji nt. systemu oraz przyczyn porażki. Osobiście najbardziej przerażony jestem tym, co tam wyczytałem:

Nikt nie weryfikuje protokołów papierowych opracowanych przez GKW i wprowadzonych do kalkulatora a następnie zatwierdzonych przez TKW o ile nie pojawią się protesty wyborcze, bodajże po 30 dniach od upłynięcia czasu na zgłaszanie protestów protokoły oryginalne są utylizowane, na kolejnych szczeblach sprawdzana jest tylko suma kontrolna. (chodzi o skan kodu z protokołu papierowego i jego porównanie z sumą kontrolną danych dostarczonych elektronicznie — dop. red.)

Mam nadzieję, że suma kontrolna jest wyliczana w taki sposób, że weryfikuje jednocześnie dane nt. oddanych głosów. Tak czy inaczej spodziewałbym się, że w tak ważnym wydarzeniu nie będzie polegać się tylko na widzimisię wprowadzającego, tylko ktoś dane z papierowego protokołu wklepie dla pewności jeszcze raz. Bo prosta suma kontrolna, czy też suma kontrolna o znanym algorytmie wyliczania jak najbardziej zabezpieczy przed literówką, ale nie przed celową manipulacją (partii A dodać 50, partii B odjąć 10, partii C odjąć 40). A do komputera nie wprowadza komisja, tylko pojedynczy operator.

[1] Przynajmniej za czasów moich studiów można było, nie wiem jaki teraz jest poziom na uczelniach. Z systemem już bym nie polegał na studentach, tu się jednak trochę praktyki przydaje.

Testowanie szybkości kluczy Zabbix agenta

Było tak, że jeden z kluczy w Zabbiksie działał wolno. Nawet: bardzo wolno. Ile czasu może się wykonywać proste sprawdzenie wersji programu typu chef-client -v, nawet na umiarkowanie dobitym systemie? Zainteresowani znajdą odpowiedź na końcu wpisu[1], dość powiedzieć, że czasami załączał się timeout po stronie zabbix agent. Problem został rozwiązany w sposób najdoskonalszy, czyli poprzez zrzucanie wartości z crona do pliku, i czytanie jej z pliku, ale niesmak pozostał. Poza niesmakiem, pozostało pytanie które jeszcze klucze są nieoptymalne?

Ponieważ na ten moment Zabbix nie daje możliwości sprawdzenia statystyk czasu zapytań dla poszczególnych kluczy, wykonałem małą protezę w postaci skryptu w Perlu, który odpyta danego hosta o wszystkie klucze kilka(naście) razy i policzy dla nich statystyki. Wklejka poniżej.

 

Skrypt przyjmuje dokładnie jeden parametr – hosta na którym będzie przeprowadzać test. Poza tym, wymaga wszystkich kluczy dla danego hosta, które ma testować, w pliku określonym w zmiennej $file. Na końcu wyświetli łączny czas wykonania zdefiniowanej ilości zapytań dla każdego klucza wyrażony w sekundach oraz sam klucz. Czytaj: pewnie chcesz przepuścić wynik przez sort -n. 😉

Parę rzeczy, które wyszły w trakcie pisania tego skryptu lub których się nauczyłem (w sumie gdyby nie one, to nie powstałby ten wpis):

Pętla sprawdzające N razy wszystkie klucze po kolei jest dokładniejsza od pętli, która sprawdza kolejno wszystkie klucze N razy każdy. Chodzi o rozkład obciążanie na maszynie, w tym drugim przypadku jest większa szansa, że któryś klucz trafi w nietypowe obciążenie maszyny.

Dokumentacja do modułu Time::HiRes jest… taka sobie. Można to zrobić prościej, jak wyżej. Początkowo kombinowałem ze sprintf oraz clock_gettime(CLOCK_REALTIME);

Może zastanawiać, skąd mnożenie przez 1000000. Otóż chodzi o bug z zapisem liczb zmiennoprzecinkowych (kojarzyłem to raczej z ośmiobitowców i dzielenia, nie wiem czy słusznie…):

perl -e '$a=1415907504.646884; $b=1415907504.603042; $d=$a-$b; print $d,$/'

vs.

perl -e '$a=1415907504.646884*1000000; $b=1415907504.603042*1000000; $d=($a-$b)/1000000; print $d,$/'

Że tak zacytuję real programmers use integer. 😉

Na koniec niezła wiadomość: jest szansa, że w przyszłości Zabbix będzie miał coś w stylu MySQLowego slowloga, czyli nie będzie trzeba robić testów na poszczególnych hostach, tylko będzie wbudowane narzędzie do wykrywania wolnych zapytań. Można głosować na ten feature. 😉

Specjalne podziękowania za uwagi i wyjaśnienia dla Tona z #perl @ IRCnet (thanks Ton!).

I wracając do pytania o nieoptymalne klucze z początku wpisu – tylko nieszczęsny chef-client okazał się być czarną owcą. Pozostałe klucze, choć czasem wymagają uruchomienia Perla lub kilku poleceń w Bashu, wykonywały się w zdecydowanie przyzwoitym czasie, grubo poniżej sekundy.

[1] Wykonuje się nawet cbanq cvęganśpvr frxhaq (rot13)! Bo na tyle ustawiony był timeout…

Własna strona w sieci Tor

Za sprawą normalnych tradycyjnych stron w sieci Tor zrobiło się ostatnio głośno z powodu Facebooka. Nie dość, że Facebook wystawił stronę oficjalnie do sieci Tor pod adresem .onion, to adres był ciekawy, a całość jest dostępna po HTTPS, czyli w wersji szyfrowanej[1]. Mniejsza o powody, dla których to uczynili. Wydaje się, że nie tyle chodziło im o anonimowość użytkowników (nie miejcie złudzeń), co o ich prywatność i bezpieczeństwo (ukrycie lokalizacji). Plus przy okazji rozwiązali sobie problem false positives przy wykrywaniu włamań, które mieli przy użytkownikach korzystających z tradycyjnych exit node[2]. Będzie zatem o własnej stronie w sieci Tor.

Tor logoŹródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg

Tak czy inaczej, wygląda, że Tor został dostrzeżony przez dużych w z właściwej perspektywy, czyli po prostu jako medium transmisji, a nie odrębna sieć, używana przez złoczyńców[3]. Myślę, że można spodziewać się kolejnych naśladowców.

Warto zauważyć, że to co zrobił Facebook to nie jest typowy hidden service w sieci Tor. W typowym chodzi o ukrycie tożsamości właściciela, miejsca hostowania itp. Czyli masa pracy poświęcona uszczelnianiu systemu i serwera WWW, która nie jest przedmiotem tego wpisu. Na stronie projektu Tor też się tym nie zajmują, ale zainteresowani znajdą tam ogólne wskazówki. Tu przeciwnie – wszystko jest dostępne, a tożsamość jest potwierdzona certyfikatem SSL, czyli wersja znacznie łatwiejsza w wykonaniu.

I właśnie takim przypadkiem zajmę się w tym wpisie. Całość opisana jest dokładnie na stronie projektu Tor. Widzę jednak, że pojawiają się pytania jak to zrobić, więc zamieszczę wersję skróconą i uproszczoną. Tak naprawdę całość sprowadza się do dwóch linii w pliku konfiguracyjnym. Zakładam, że Tor jest już skonfigurowany jako relay node lub bridge node. I nawet nie do napisania, tylko do odhashowania/edycji.

Przede wszystkim w pliku konfiguracyjnym[4] szukamy sekcji dotyczącej hidden services, zaczynającej się od linii:

############### This section is just for location-hidden services ###

Następnie odhashowujemy/edytujemy dwie linie:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 IP_SERWERA_WWW:80

Pierwsza musi wskazywać na katalog, który musi mieć prawa odczytu i zapisu dla użytkownika na którym działa demon Tor. W Debianie wystarczy odhashować.

Druga to wskazanie który port chcemy przekierowywać i na jaki adres oraz port. IPv4 działa na pewno, IPv6 nie udało mi się skłonić do działania. Jedyna zmiana, czy też wymóg konfiguracji po stronie serwera WWW, jest taki, że musi on pozwalać na dostęp do zasobów po IP, bez podania domeny (vhosta)[5].

Następnie należy zrestartować demona Tor i… gotowe. Pozostało jeszcze tylko sprawdzić, jaki adres ma nasz hidden service:

cat /var/lib/tor/hidden_service/hostname

Potem można już tylko zweryfikować działania serwisu za pośrednictwem adresu .onion. Jeśli nie mamy pod ręką normalnego dostępu do Tora, można posiłkować się bramką Tor2web.

[1] I całe szczęście, bo przypominam, że Tor nie szyfruje użycie Tora nie oznacza automatycznie szyfrowania danych. Co więcej, każdy węzeł, ma możliwość przechwycenia całej (co prawda zaszyfrowanej) transmisji. A exit node, jest w stanie podsłuchać nieszyfrowaną transmisję do końcowego hosta.

[2] Więcej w tym wpisie (ANG).

[3] Nie ukrywajmy, typowy użytkownik Tora kojarzył się do tej pory z nielegalnymi działaniami.

[4] W Debianie jest to /etc/tor/torrc, pewnie w Ubuntu i innych pochodnych jest analogicznie.

[5] Tu uwaga dla chcących stawiać bramki hidden service – z punktu widzenia zewnętrznego serwisu (i tylko jego, i tylko w przypadku połączeń poprzez adres .onion) mój klient Tor IP jest teraz exit node! W przypadku nadużyć za pośrednictwem sieci Tor i adresu .onion może się to skończyć wizytą policji. W przypadku serwisów, których nie jesteśmy właścicielami bezwzględnie należy mieć zgodę właściciela serwisu.