vermin.eu.org

Ciekawa wyszukiwarka kodu… Co jest śmieszniejsze, wyszukiwarka ciekawych komentarzy w kodzie. Chociaż znając (nie tylko) swój styl nazywania zmiennych tymczasowych i komentowania kodu to jestem zdziwiony jak rzadko występuje tam bardzo popularne słowo zmiennej tymczasowej i komunikatów debugujących…

Swoją drogą, co już zostało zauważone - wyszukiwarka otwiera kolejny wektor ataku, bo ileż osób hardcoduje w plikach include w PHP hasła dostępu do baz danych, użytkowników i inne przydatne dla szukającego informacje…

W ramach walki ze spamem przeszliśmy już przez MUA oraz wstępnie zabezpieczyliśmy MTA. Wstępnie, ponieważ nadal ktoś może podszyć się pod domenę z whitelisty a także nie wszędzie możemy zastosować greylisting. W tej sytuacji wyposażymy naszego postfixa w kolejne narzędzia.

Dwoma chyba najpopularniejszymi pakietami do walki ze spamem oraz wirusami są spamassassin oraz clamav. Ponieważ są to pakiety zewnętrzne, do integracji ich z postfixem użyjemy pośrednika - amavisd-new. Po instalacji odpowiednich pakietów, czyli standardowym aptitude install amavisd-new spamassassin clamav clamav-daemon clamav-freshclam otrzymujemy działające środowisko. Teraz musimy tylko poinstruować amavisa i postfixa jak z niego korzystać.

Read more »

W poprzednim artykule tyczącym się walki ze spamem na stacji klienckiej wspomniałem o konieczności przerzucenia ciężaru filtrowania na serwer. Ten sposób filtrowania ma niestety, jak każdy dobry kij, conajmniej dwa końce. Po pierwsze - musimy zapewnić użytkownikowi możliwość dotarcia do przesyłki, która jednak może spamem nie być (false positives), po drugie wszystkie wiadomości i tak są wrzucane na serwer - czyli mamy zajęte pasmo oraz przestrzeń dyskową.

Metodą, która pozwala obejść te minusy jest graylisting. Działa on w sposób bardzo prosty, wykorzystując sposób działania serwerów SMTP oraz typowe zasady działania spamerów.
Serwery SMTP próbują przesłać wiadomość ‘do skutku’, to znaczy jeśli sesja SMTP nie powiedzie się przy pierwszej próbie, po chwili (równej zazwyczaj długości kolejki i interwałowi jej opróżniania - wiadomość na serwerze wysyłającym przesuwana jest na koniec kolejki przy niemożności dostarczenia), próbują ponownie. Spamerzy zazwyczaj nie wysyłają wiadomości ponownie i ignorują kody błędów. Oznacza to, że jeśli przy pierwszej próbie wysłania nowej wiadomości serwer specjalnie odpowie kodem błędu, to “za chwilę” ta wiadomość jednak do niego dotrze. Jak każda metoda, także ta ma pewne minusy - pierwszym i podstawowym jest zgoda zarządu na jej wprowadzenie - niektóre firmy nie chcą/nie mogą pozwolić sobie na opóźnienia w przyjmowaniu poczty. Ponadto ze względów organizacyjnych wprowadza się często adres publiczny, na który może przychodzić niezamówiona oferta handlowa. Drugim powodem, techcznicznym, jest dodanie kolejnego punktu, gdzie może pojawić się problem w sposobie działania serwera pocztowego. Trzecim, także technicznym problemem są sytuacje, gdy serwer po uzyskaniu kodu 450 zaprzestaje prób i raportuje problem z wysłaniem wiadomości - niestety takie rzeczy także się zdarzają.

Sposobem na zminiminalizowanie opóźnień w kontaktach z partnerami biznesowymi jest stworzenie listy ich domen pocztowych i dodanie ich do białej listy domen, które nie będą poddawane graylistingowi. Oczywiście, jeśli nie jest wprowadzony SPF pozwalający na jako-taką weryfikację adresu nadawcy, to każdy kto wstawi sobie adres domeny z białej listy będzie mógł przesłać spam na nasz serwer pocztowy… Implikuje to niestety także konieczność zastosowania także innych metod walki ze spamem.

To tyle tytułem przydługiego wstępu o samej metodzie, w końcu warto jednak dać odpowiedź na temat - czyli jak dodać graylisting do naszego postfixa? Za przykład posłuży oczywiście mój ulubiony debian i jego pakiet postgrey - o którym warto poczytać na stronie autora. Paczki postgrey są dostępne także dla gentoo, fBSD oraz Fedory.
Jego instalacja jest prosta - komenda aptitude install postgrey spowoduje zainstalowanie dwóch pakietów libberkeleydb-perl oraz postgrey. Automatycznie po instalacji wstaje demon postgrey umiejscawiający się na porcie tcp 60000. Port oraz interfejs (domyślnie localhost) możemy zmodyfikować w /etc/default/postgrey. Możemy tam także zmodyfikować komunikat pojawiający się wraz z błędem 450 - wystarczy do opcji dodać parametr –greylist-text. Najprostsza część instalacji za nami.
Teraz musimy w /etc/postfix/main.cf dodać do smtpd_recipient_restrictions część check_policy_service inet:127.0.0.1:60000. Warto zastanowić się po jakich regułach dodamy tą wartość. U mnie występuje ona po permit_mynetworks, permit_sasl_authenticated co pozwala ominąć greylisting dla wysyłających z moich sieci oraz dla użytkowników zautentykowanych.

Po restarcie postfixa mamy już działający greylisting - jak teraz jednak dopuścić pracę bez graylistingu dla konkretnych domen oraz adresów? Odpowiednie pliki znajdują się w /etc/postgrey - są to odpowiednio whitelist_clients (częściowo zapełniony) oraz whitelist_recipients.

Na koniec ciekawostka - ze względu na te pliki właśnie, postgrey znajduje się także w repozytorium volatile…

Strategii walki ze spamem jest kilka. Pierwsza z nich, to filtry antyspamowe użytkownika zawarte w samym MUA, takie jak filtr bayesowski w thunderbird, czy też aktualizowane co jakiś czas filtry w Oulooku. Plusem tego rozwiązania jest to, że możemy spokojnie przejrzeć wszystkie wiadomości - żadne false positives nie zaszkodzą ciągłości naszego biznesu. Niestety te metody zmuszają nas do ściągnięcia wszystkich wiadomości na stację lokalną, co powoduje czasem spore obciążenie łącza, konieczność składowania tego całego bałaganu gdzieś choćby na chwilę - no i zazwyczaj i tak przejdziemy przez zawartość Junk-mail, chociażby po to, żeby przejrzeć co tam sie znalazło.

Drugim, ciekawszym rozwiązaniem jest zainstalowanie na komputerze pośrednika, swego rodzaju MTA, który będzie filtrował wiadomości przychodzące na naszą pocztę wg zdefiniowanych reguł. Przykładem takiego rozwiązania jest chociażby spampal. Pozwala on na sprawdzenie poczty pod kątem występowania w niej odpowiednich wyrażeń regularnych, dodatkowo ma opcję filtru Bayesa oraz sprawdzenia poczty przychodzącej w bazach RBL.
Ogromnym plusem takiego rozwiązania jest możliwość jego dowolnej konfiguracji, stworzenia białych list poczty a na dodatek uniezależnienie się od mechanizmu antyspamowego samego klienta pocztowego, w szczególności, jeśli na raz używamy kilku (ot chociażby thunderbird, opera, outlook).
Minusów jest także kilka - dużo możliwości konfiguracji to zazwyczaj także pewien problem z poprawnym ustawieniem programu. Są jednak większe problemy - pierwszym z nich jest konieczność współpracy z oprogramowaniem antywirusowym, które ma czasem problem z takim pośredniczącym MTA, co wymusza specyficzną konfigurację oprogramowania klienckiego. Drugim, to problemy z używaniem szyfrowania poczty - w końcu takie MTA to typowy MITM. Nie wspominam już tutaj nawet o exchange czy protokołach innych niż POP3… Widać ewidentnie, że ciężar walki przerzucić trzeba na serwer.

Czasem może zdarzyć się, że ISP blokuje bezpośredni dostęp do portów 25 w sieciach znajdującej się poza jego domeną. Tak akurat dzieje się w lokalizacji gdzie aktualnie się znajduję, co oznacza, że trzeba własny serwer pocztowy przestawić na inny port. Oczywiście nie można go przestawić całkowicie, ponieważ inne serwery pocztowe nie porozumieją się z nami nie mogąc znaleźć punktu wejścia serwera.

Okazuje się jednak, że konfiguracja postfixa jest przygotowana na taką ewentualność. Jeśli mamy w posfixie uruchomiony mechanizm TLS to spokojnie możemy uruchomić postfixa na porcie 465 (smtps). Wystarczy w pliku /etc/postfix/master.cf odhaszować linijkę:

oraz oczywiście dodać regułkę do firewall’a przepuszczającą ruch na wzmiankowanym porcie
Warto zauważyć, że demon czuwający na porcie 465 nie przedstawia się tak ładnie jak ten porcie 25 - od razu wymaga rozpoczęcia negocjacji TLS.

Osięgniemy w ten sposób dwa cele - pierwszy z nich to możliwość wysyłania poczty, drugi - to pewność bezpiecznego skonfigurowania klientów pocztowych, którym oczywiście nakazujemy łączyć się z portem 465 zamiast 25. Pozostaje jeszcze problem dobrego dopasowania certyfikatów, ale to temat na inny art.

Na serwerze nie używaj jako domyślnej dla łańcucha INPUT polisy DENY. Lepiej użyć polisy ACCPET i dodać regułę

.

Dlaczego? Zrób czyszczenie reguł (

) przez ssh. Zrozumiesz.

A ze śmiesznych rzeczy - praca zdalna dziś: reboot drugiego komputera z laptopa, i patrzenie przez okulary na odległy o circa trzy metry monitor czy się komputer podniesie i co pisze w logach przy starcie.

Podejrzewam, że nikt ze wspaniałej instytucji działającej pod egidą Allied Irish Bank tego nie przeczyta, ale cóż - w końcu od tego jest blog, żeby ‘dać wyraz fragmentom moich myśli’.

BZ WBK zmienił swój system logowania - zamiast standardowego formularza login/hasło mamy na pierwszym ekranie login, a na drugim ekranie (przeładowanie w przeglądarce - żaden AJAX), hasło. Nie jest to jednak zwykłe pole formularza, ale kratki na poszczególne literki hasła - przy długim haśle wyłączając niektóre litery na zasadzie autentykacji telefonicznej, (podaj. drugą. cyfrę. hasła, podaj. piątą. cyfrę. hasła).
Wszystko fajnie, zmiana systemu logowania jest może i bezpieczeniejsza - ale tylko wtedy, kiedy wymusi się zmianę polityki haseł z tych krótkich haseł domyślnych (4 cyfrowy PIN w zasadzie) na dłuższe - inaczej to tylko wkurza, ponieważ pola z formularza za wolno się przełączają (testowałem pod kilkoma przeglądarkami). Nie muszę dodawać, że o polityce haseł nie ma tam ani słowa?
Oczywiście rozumiem dlaczego tak się stało - za dużo ostatnio spywaru i trojanów czytających pola z formularzy WWW, ale swoją drogą zastanawia mnie dlaczego aż tak bardzo utrudniają zwykłemu użytkownikowi życie, jeśli żadnej operacji po zalogowaniu się do konta nie przeprowadzę bez potwierdzenia kodem z tokena lub SMSem? W sumie jeśli ktoś zobaczy ile mam na koncie to aż tak wiele złego się nie stanie (no dobra - będą na mnie mówić Kenny zamiast vermin ;-))

To w zasadzie by mnie jeszcze nie zdenerwowało, gdyby nie kolejny kamyczek - i to już moim zdaniem nie mały. Ogromnie denerwujące jest to, skoro Bank tak walczy o bezpieczny interfejs, iż tuż po zalogowaniu się wyskakują jakieś pop-upy z reklamą banku, które sprawiają wrażenie jakby jakiś spyware się ładował. Przecież to jakaś paranoja?

Całkowicie przy okazji - kwestia usability. Bank wprowdził nową usługę - ewyciąg. Ciekawa być może usługa (nie dla mnie - już się przekonałem, że gdziekolwiek w Polsce papier - to papier), ale zajęła domyślne miejsce przycisku historia konta, która dla mnie była szczególnie istotna (co tam wpłynęło albo jakim płatnościom nie udało się pokonać mojego niskiego stan posiadania?)
Dla mnie takie wiadomości powinna zawierać jakieś newslettery (subskrybuję - ale nie przychodzą), a może informacja na stronie logowania? Szkoda także, że bank nie czerpie z doświadczeń konkurencji - np. kliknięcie w saldo pokazuje od razu historię, kliknięcie w opis - pokazuje dane. Na dodatek brakuje np. możliwość filtrowania wyciągu na stronie wg typu, kwot, kontrahenta czy czegokolwiek. Jedynym plusem jest eksport wyciągu do CSV/Excel…

Ponieważ wysłałem do Banku zapytanie w powyższej sprawie (security) - czekam na jakąś odpowiedź. Hehe - już ją widzę… eufemistycznie mówiąc ‘na drzewo (eufemistycznie bardzo) robaku’. Na dodatek pewnie nie odniosą się nawet do połowy treści mojego zapytania - a taka szkoda, bo w końcu naprawdę lubię ten Bank… No, ale cóż, jak mówi reklama ING, (którego nie lubię) - banki nie są od lubienia, są od zarabiania pieniędzy (ponoć także dla klientów? ;-)).

Edit: szybkie google pokazało, że nie tylko mnie nowy interfejs nie sprawia przyjemności

Typowy scenariusz - mamy serwerek FTP, oczywiście chrootujemy użytkowników do katalogów domowych. Nagle okazuje się, że jeden z nich musi mieć dostęp do dodatkowych danych, np. utrzymać stronę WWW, którą do tej pory zajmował się inny użytkownik. Symlinki oczywiscie nie wchodzą w grę, ale jest kilka opcji:

• można dać mu kolejny login i hasło, (które zgubi, zapomni), co jest proste dla admina, ale niewygodne dla usera
• można przekopiować dane do jego katalogu, zmienić uprawnienia, zmienić konfigurację apache, co jest trudne, długie, wymaga restartu usługi, no i jak ten user odejdzie, to trzeba operację powtórzyć
• można też zastosować rzecz wygodną i dla admina i dla usera - czyli mount

W zasadzie wydanie komendy

załatwia nam sprawę (jak to jest na czas powyżej średniego uptime maszyny to warto to dodać do /etc/fstab). Proste, czyste, przyjemne

Źródło: MDLog:/sysadmin

Sobota, godziny popołudniowe, szybki look w logi i co widzę? Gdzieś w środku nocy, jakiś dzieciak zza oceanu wybrał sobie jeden z moich serwerków w celu przetestowania swoich narzędzi. Bardzo to niefajne, bo szybkie łącze pozwoliło mu na dosłownie zalanie serwera requestami o autoryzację - do DOSa nie doszło - niemniej jest to trochę wkurzające…

O ile SSH się w miarę łatwo zabezpiecza przed zbyt duża ilością wpisów, to już serwery FTP zabezpieczyć trudniej. Z pomocą przychodzą dwa narzędzia - pierwsze z nich to znane z pakietu *sentry Logsentry, zaś drugie, nad którym się skupię - fail2ban. Obydwa działają tak samo - monitorują logi i na tej zasadzie podejmują odpowiednie działania. Obydwa mają zbliżone zalety i tą samą wadę - regexpy¹. Obydwa używają /etc/deny.hosts lub iptables. Obydwu nie ma w stable

Fail2ban niestety nie znajduje się w stable - jest za to w testing i unstable, więc można go ściągnąć stamtąd lub bezpośrednio ze stron projektu Debian. Z wymogów instalacyjnych trzeba wspomnieć o pythonie i lsb-base, które na szczęście są w stable i to w odpowiednich wersjach. Po instalacji fail2ban od razu rozpoczyna działanie - niemniej dobrego admina to nie zadawala i od razu rusza do /etc/fail2ban.conf, żeby poprawić konfigurację.

Co warto zmienić? Na pewno warto dodać listę adresów, które nie będą blokowane (bo w końcu każdy może wysłać stworzone przez siebie pakiety wskazujące na dowolne IP) - opcja ignoreip. Kolejną opcją, którą warto zmienić, to czas blokady (bantime) - domyślne 10 minut to za mało - warto dać więcej, a mając fizyczny dostęp do maszyny nawet -1 (for ever). Jeśli ktoś lubi, to warto włączyć opcję powiadamiania emailem o zablokowaniu konkretnego IP (jeśli dostajemy wiadomości w stylu in-your-face, to trudniej zapomnieć, że taki niskopoziomowy mechanizm gdzieś tam sobie działa i można szybciej zdiagnozować problem). Pozostaje włączenie odpowiednich demonów, czyli zmiana enabled na true w odpowiednich sekcjach pliku konfiguracyjnego.
Domyślnie skrypt ma wpisane kilka typowych demonów - SSH (włączone domyślnie), SASL, Apache, ApacheAttacks, VSFTPD, PROFTPD, ale bazując na wyrażeniach regularnych¹ można dodać dowolne inne, co jest duuużym plusem. Kolejnym plusem jest przyjemna konfiguracja iptables, którą wykonuje program - tworzy własne łańcuchy opisujące przez jaką regułę dany IP został zablokowany, co pozwala łatwiej przejrzeć logi w razie narzekań userów czy innych adminów.

¹regexpy to mieszane błogosławieństwo - pozwalają na wspaniałe dostosowanie programu pod de facto dowolnego demona, niemniej pozwalają także na przemycenie, przez użycie zbyt szerokiego zakresu wyrażenia, błędów, pozwalających w tym wypadku na DOS maszyny…

Warto poczytać dodatkowo: Debian Administration

W dzisiejszym komunikacie prasowym Microsoft ogłosił przejęcie firmy Winternals, znanej najbardziej z postaci Marka Russinovicha, (o którym pisałem w tym artykule) i zestawu narzędzu sysinternals - w zasadzie podstawy do pracy dla admina, chcącego wiedzieć co dzieje się ‘pod maską’ systemu.

Zastanawia mnie, jak przejęcie tej bardzo znanej administratorom systemów Windows firmy wpłynie na narzędzia dostarczane z produktami serwerowymi? Szczególnie z rodziną systemów zarządzania infrastrukturą, (do której zalicza się WSUS, a przede wszystkim SMS), która to rodzina ewidentnie wraz z pojawieniem się koncepcji kontroli dostępu do sieci (NAC - Network Access Control) rośnie w siłę i znaczenie. Bardzo mnie zastanawia jak integracja bardzo przydatnego zestawu narzędzi z winternals wpłynie na stan systemu Windows? Czy staną się jakimś resource packiem? Czy też może będą nadal niezależnym produktem a Russinovich wzmocni brygadę zajmującą się bezpieczeństwem systemu? Zobaczymy.

Na razie widać ewidentnie, że Microsoft stawia coraz mocniej na zestaw narzędzi, który pozwoli zarządzać systemem z konsoli - powershell, który będzie to wszystko integrował oraz zestaw narzędzi, które pozwolą rozszerzyć możliwości diagnostyczne tego co jest oferowane w Resource Kit’ach. W sumie - oby tak dalej. Niech tylko jeszcze dadzą ssh…

NOD32 to najlepszy znany mi software AV. Do Symanteca się zraziłem wersją dla osób prywatnych świeższą niż 2001, Kaspersky zabijał wolne komputery poprzez tworzenie skrótów plików, MKS niestety przestał się jakoś w którymś momencie rozwijać, (chociaż czuję do niego ogromny sentyment i przy jego polityce licencjonowania uważam za najlepszy wybór dla pracowni szkolnych), a teraz wyewoluował w ArcaVira, którego nie testowałem w sumie. NOD zresztą sprawdził się - jego technologia ThreatSense (znaczy się ładnie nazwana heurystyka) i bardzo duża częstotliwość aktualizacji już parę razy ochroniły mi cztery litery w momencie, kiedy inne programy AV jeszcze nie wiedziały, że coś się dzieje. Ogólnie jak mogę coś klientowi polecić to wybieram zawsze NODa.

Problemik się pojawił ostatnio, ponieważ po instalacji SBSa, klient chciał rozrzucić NODa pod domenie. Instalacja NODa nie jest szczególnie skomplikowana (next, next, next…), ale w domenie już można się trochę pobawić - chociażby skonfigurowanie kopii dystrybucyjnej na serwerze, zabezpieczeniem konfiguracji hasłem i takie tam. NOD domyślnie ma takie cudo jak Remote Administrator, ale klientowi to nie było potrzebne. Praca instalatora software byłaby dla niego tańsza (-:

SBS jak wiadomo ma wspaniałą zaletę a’la SMS, pozwalającą na publikowanie paczek oprogramowania dla stacji klienckich. W zasadzie używa się dwóch metod - pierwsza z nich to wrzucenie paczki z oprogramowaniem do katalogu ClientApps i dodanie w konsoli Zarządzanie Serwerem nowej paczki wraz z przypisaniem jej do konta komputera. Po zalogowaniu się użytkownika na tej maszynie na jego pulpicie pojawi się skrót do dodanej instalacji, którą użytkownik MOŻE sobie zainstalować. Oczywiście dla oprogramowanai typu AV słowo może jest złym słowem, które powinno zamienić się na słówko MUSI. Na to na szczęście jest metoda - GPO. W zasadach grupy można przypisać aplikację do konta komputera i voila - zainstaluje się sama.

Czym się różnią te dwie metody instalacji? Pierwsza z nich wymaga (moze wymagać) interakcji z użytkownikiem. Ponadto pozwala użytkownikowi na niezainstalowanie oprogramowania no i odbywa się PO zalogowaniu użytkownika na stacji. Druga jest metodą nieiterakcyjną (co oznacza dla większości softu stworzenie plików transformacji (MST) albo innego cuda), która wykona się podczas wyświetlania ekranu logowania i jest wymuszona zasadami GPO. Jak widać - co kto lubi lub co mu jest potrzebne.

Wróćmy jednak do naszego zadania, czyli instalacji NODa. Wiemy juz, że powinno się dodać paczkę tak, aby zainstalowała się sama, bez ingerencji, a najlepiej tak, żeby użyszkodnik nie mógł nic zmienić w konfiguracji. Z pomocą przychodzi narzędzie configuration editor, (jest dostępne po wykonaniu instalacji administracyjnej, czyli z lokalnym mirrorem), które generuje plik w formacie XML opisujący wszystkie parametry konfigurujące oprogramowania - sposóby aktualizacji, metody postępowania z plikiem, adresy pod którymi znajdują się aktualizacje, hasła (oczywiście zakodowane), blokady profili i same profile, etc. Sam plik niestety to niezawiele - jak to uruchomić? Otóż trzeba, (i tak by było trzeba), ściągnąć ze strony NOD aktualną wersję oprogramowania, rozpakować ja (RAR) i dodać plik config.xml wygenerowany w edytorze konfiguracji. Teraz pakujemy to ładnie ponownie do SFXa, ale dodajemy mu miła komendę -

albo publikujemy tą właśnie komendę do wykonania z określonej lokacji. Ważne jest, żeby pamiętać o opcji reboot, ponieważ inaczej nie uruchomi się jądro systemu NOD i de facto nie będzie działać ochrona ciągła, a jedynie na żądanie (do rebootu). Przy deinstalacji, jeśłi byłaby wymagana, używa się parametrów uninstall oraz pwd=hasło. Dzięki temu, po poprawnym skonfigurowaniu raportowania przez klienckie stacje NOD możemy dzięki SBS czuć się (prawie) tak, jakbyśmy posiadali RemoteAdministratora (-:

“Ten adres jest zastrzeżony
Ten adres zawiera numer portu sieciowego, który zazwyczaj nie jest wykorzystywany do przeglądania stron www. Firefox anulował żądanie dla bezpieczeństwa użytkownika.”

Firefox, niewiadomo dlaczego ;-), odmawia połączenia z pewnymi portami, na których nie spodziewa się odnaleźć usługi WWW. Niestety, czasem tam naprawdę znajduje się odpowiednia usługa, z której chcemy pobrać dane - np. certyfikaty SSL typu self-signed albo poświadczone przez CA, którego nie ma domyślnie w przeglądarce są do pobrania własnie przez przeglądarkę (dzięki wpisaniu w firefox https://nazwa_serwera:995 dla POP3S, https://nazwa_serwer:993 dla IMAPS czy też https://nazwa_serwera:465 dla Secure SMTP - które to wszystkie serwisy mogą też działać na standardowych portach, co właśnie powoduje problem).
Jak poradzić sobie z tym problemem? Wystarczy dodać w konfiguracji firefox (about:config w pasku adresu) opcję typu ciąg znaków (string) nową opcję network.security.ports.banned.override i wymienić jako wartości listę portów oddzielaną przecinkami. I już działa!

Jako człowiek ceniacy sobie swój czas, (i zużywający go często i gęsto na czytanie blogów), rzadko kiedy odwiedzam oddział swojego banku. Ba, w zasadzie mam konta w bankach, których fizyczna siedziba jest dla mnie nieznana. Do swoich pieniędzy docieram przez internet, (komórka jakoś mnie nie przekonuje). No i tu pojawia się problem. Banki walczą o zabezpieczenia pieniędzy klienta, (chociaż jak się czyta o BPH…). Jednak to jak walczą czasem woła o pomstę do nieba. Przykładem niech będzie tu inteligo - formularz na stronie logowania pozwala na zapamiętanie 8 cyfrowego loginu, nie dając użytkownikowi opcji typu ‘komputer z którego korzysta wiele osób’. Jeśli tego nie ma, to nie lepiej było dodać do pola na stronie właściwości autocomplete=”off”? Ale dalej jest lepiej. Najprawdopodbniej ktoś w banku chcąc dostać podwyżkę i wykazać się jakiż to on nie jest “jedwabisty”, wprowadził na stronie potwierdzania przelewu element mechanizmu CAPTCHA. Objawia się to tym, że po podaniu magicznego kodu z kartki muszę jeszcze wślepiać się w monitor, co wieczorem przy niskiej jasności matrycy jest dość trudne, gdzie szaro na szarym wypisane są magiczne znaki. Po co? Przecież jak ktoś już ma mój login, (bo został na komputerze), hasło (im dłużej pracuję tym widzę, że wiedza o danych osobowych pracownika pozwala na odgadnięcie hasła w około 10 próbach) to ta magiczna karteczka jest ostatnią linią obrony przed złodziejem. No chyba, że PKO BP zginęły dane osobowe klientów i złodzieje stworzyli magic-bota obrabiającego automatycznie konta i tylko mechanizm CAPTCHA chroni nasze pieniądze?

O pozostałych zabezpieczeniach banków polecam poczytać w raporcie na ten temat. Napawa optymizmem, nieprawdaż?

Chociaż to się nasuwa wprost jako dość oczywiste, to jednak nie piszę tu o występach naszej reprezentacji, której śpieszy się do domu tak ewidentnie, że nawet wchodząc na murawę była wciąż w kontakcie z bliskimi by cell phone a potem grała tak, żeby wrócić jak najszybciej w domowe pielesze. Nie chodzi mi tu nawet o naszego Pinokio drużynowego, czyli Rasiaka-Drewniaka. Nie, naprawdę nie piszę tu wcale o tym jak jestem rozczarowany występem naszej reprezentacji i o tym jak ze smutkiem chowałem wczoraj biało-czerwoną…

Otóż kończy się security-support dla najpopularniejszej wersji debiana, z którą wielu żyło przez ostatnie 4 lata - Debian 3.0 Woody. Szkoda oczywiście, że team security ogłasza to raptem z miesięcznym opóźnieniem, chociaż jeśli ktoś na serwerze do tej pory nie przemigrował na Sarge, to pewnie nie ma maszyny na frontendzie a raczej coś schowanego w głebi infrastruktury z aplikacją non-critical, której lepiej nie tykać bo nie ma teamu, który ją tworzył… Tak czy siak, jeśli ktoś nie jest w takiej sytuacji to najwyższy czas zmigrować na nowszą wersję! Najlepiej już na Etch z testingu, jeśli to nie jest system mission-critical

Jak podaje dziś Rzeczpospolita:

Każdy, kto prowadzi obsługę kont poczty elektronicznej, będzie musiał kupić kasę pancerną i założyć tajną kancelarię, by w niej przechowywać informacje o wysłanych i otrzymanych e-mailach. Taka może być konsekwencja nowelizacji ustawy - Prawo telekomunikacyjne, przygotowanej przez Ministerstwo Transportu i Budownictwa (jeszcze przed podziałem).

Wprowadzenie tej z pozoru drobnej zmiany w prawie spowoduje, że firmy i osoby, które mają serwery pocztowe, będą musiały przechowywać dane o e-mailach przez 24 miesiące. Jeśli rząd i Sejm przystaną na wspieraną przez resorty siłowe koncepcję Ministerstwa Sprawiedliwości, okres ten zostanie wydłużony nawet do pięciu lat. (…)

Dostawca będzie musiał także całą dobę utrzymać w gotowości pracowników z certyfikatami oraz zbudować specjalne systemy bezpiecznego dostępu do danych.

Co to oznacza? Jeśli dobrze rozumiem, to jeśli mała firma wdrożyła sobie Exchange lub bardziej prawdopodbnie SBS, to podpada pod wzmiankowaną ustawę. Jeśli szkoła publiczna mając łącze internetowe postawiła sobie przy okazji serwer z postfixem, choćby jako mail relay, to też będzie nagle musiała budować kancelarię tajną. Jeśli prywatna osoba ma serwer pocztowy w domu na DDNS… także? A postfix służący jako mail relay dla sieci, które korzystają ze smarthostów albo połączeń wdzwanianych?

Uważam, że przeciw takiej nowelizacji ustawy powinna zaprotestować PIIT, ale nie tylko - przede wszystkim sami internauci, którzy nie tylko nagle będą mocniej inwigilowani, (bo i tak są, więc stąd słowo mocniej), ale przede wszystkim poniosą nagle większe koszty korzystania z internetu - bo o ile sama kasa pancerna to tylko parę k złotych, to budowa kancelarii tajnej, wyposażenie conajmniej jednego dostępnego 24/7 (lol) pracownika do jej obsługi wraz z odpowiednim certyfikatem ABW to już kilkanaście ładnych tysięcy.

Jedynym plusem tej ustawy jest wydanie przez firmy pieniędzy na bezpieczeństwo teleinformatyczne - ale chociaż mój portfel także by od tego wzrósł, to wolę, żeby klient pieniądze wydał rozsądniej - świadomie, a nie przez przymus…

To co panie i panowie? Klawiatura w dłoń, baseball do plecaka zamiast laptopa i na ministerstwo! I to w realu a nie wirtualu, żeby kolegom z .gov nie narobić kłopotu