vermin.eu.org

Knockd jest niewielkim pakietem (circa 20kB), który pozwala m.in. na czasowe otwieranie i zamykanie odpowiednich portów w firewall’u. Pakiet jest bardzo prosty w instalacji i konfiguracji - nie wymaga otwierania w firewallu portów na których nasłuchuje (działa w warstwie łącza - link-layer). Dodatkowo pozwala na bardzo szczegółowe ustawienie parametrów zdarzenia na jakie będzie reagował.

Sama idea działania programu jest banalna - po otrzymaniu sekwencji pakietów TCP lub UDP, zawierających określone flagi (np. SYN, FIN, ACK…), na serwerze wykonywana jest zdefiniowana akcja. Domyślnie jest nią otwarcie portu 22 w zaporze iptables dla adresu IP z którego nadeszły stuki-puki. Podobnie, określoną sekwencją, zdefiniowane jest zamknięcie tego portu. Program ponadto dopuszcza wykonanie dwóch komend (start_command i stop_command - opcje nie ujęte w domyślnym pliku konfiguracyjnym) po zdefinowanym interwale czasowym. Pozwala to administratorom na jeszcze mocniejsze zaostrzenie polityki bezpieczeństwa i zamykanie portu po, powiedzmy, kwadransie.
Oczywiście można zdefiniować inne niż iptables programy uruchamiane zdalnie - można wymusić przeprowadzenie skanowania systemu, włączenie backupu, co adminowi przyjdzie do głowy Należy tylko pamiętać, że dane polecenie jest wykonywane w kontekście roota i przy wpisywaniu go warto byłoby użyc sudo.

Żeby szybko i sprawnie włączyć knockd a jednocześnie nie odciąć sobie dostępu do zdalnego serwera podczas ustawień warto pamiętać, żeby:

• dobrze zdefiniować reguły otwierające i zamykające w /etc/knockd.conf - szczególnie, jeśli domyślnie nie wypuszczamy ruchu related,
• zmienić regułę -A na -I. Inaczej możemy przez przypadek nie móc otworzyć sobie dziurki…
• jeśli ustawiliśmy zasady ograniczania ilości połączeń omówione w jednym z poprzednich artykułów, to warto je wyłączyć (jest tam przypadkiem reguła DENY…),
• tak ustawić porty na które będzie reagował knockd, żeby nie generowac fałszywych alarmów, (warto przeglądać strony sans institute),
• pamiętać, że w razie problemów jest plik /var/log/knockd.log (chociaż knockd może logowac do sysloga) a także opcja -j LOG lub ULOG w iptables.

Zapisywanie haseł w programie ma niestety jeden minus - brak ich używania prowadzi do zapomnienia. Okazało się, że jedno z haseł do konta jabber’owego zostało w psi i tylko tam. Oczywiście szybki rzut oka do profilu psi, otwarcie config.xml i… ciąg znaków wskazujący na jakąś obfuskację. Szybkie próby odczytania spełzły na niczym, ale pomogło google wskazując na rozwiązanie.

Krótki programik w perlu, który po wyciagnięciu danych (pól jid i password) odkoduje bezproblemowo hasło:

Na pewno można go skrócić do one-linera…

Updated: pojawiła się stronka, która dekoduje to wszystko live. Oczywiście nie odpowiadam za przekazywanie haseł do niezaufanych stron

Google w końcu wprowadził możliwość komunikacji w tekstowej wersji swojego komunikatora nie tylko pomiędzy klientami Google Talk, ale także z innymi kontami umieszczonymi na dowolnych serwerach w sieci. W końcu obsługa protokołu xmmp wyszła poza domenę gmail

Przed chwilą moje Psi krzyknęło do mnie - ktoś chce mieć Cię na swojej liście. Nie byłoby w tym nic dziwnego, gdyby nie fakt, że pytało sie o to moje konto na chrome, a kontakty po obu stronach dodałem jak tylko ruszała usługa… i o nich zapomniałem. Teraz tylko czekać kiedy w końcu wszelakie klienty jabbera zaczną obsługiwać libjingle.

Albo kiedy pozostali członkowie społeczności przesiądą się na google talk, żeby obsługiwać swoje konta. Cóż - google rządzi i nie ma to tamto.

Edit: Cóż, chyba za rzadko odpalałem konto na google, ponieważ moje “odkrycie” jest na sieci już od dwóch dni - źródło http://googletalk.blogspot.com/2006/01/xmpp-federation.html za www.jabberpl.org (gdzie przez przypadek znalałem to info bo szukałem informacji o tym, że dziś ruszył transport do GG), ale nic to - przez te kilka chwil czułem się świetnie Taki hotnews w rękach…

Edit 2: A jednak 7thGuard opublikował newsa (po obróbce honey’a)

Dziś pit przesłał mi zaproszenie do testowania bety MSN Messengera. Mój postfix nie widział połaczeń od M$, ale już kiedyś miałem problem z robakiem MSN, który miał problemy z ilością połączeń - tj. moje małe biedne wąskie łącze nie wyrabiało i wysyłało wciąż resety… Dostałem więc skopiowanego linka z maila - kliknąłem i… Niestety, Microsoft broni swoich stron przed obcymi przeglądarkami. Po przebrnięciu przez kilka stron, (na szczęście jako MCP paszport mam juz od dawna), dotarłem do magicznego download i… cóż - natychmiast kliknąłem w view-source, żeby zobaczyć CZEMU nie mogę obejrzeć tej witryny. Odpowiedź była bananalna - fragment kodu w javascript sprawdzał czy przeglądarka przedstawia się jako MSIE. Jeśli tak to dopisywał URL do kodu, w innym wypadku… cóż - przycisk był. Na szczęście wystarczyło skopiować odnośnik z kodu i już można było ściągnąć plik. Notabene, ta sytuacja występuje nie tylko przy tej okazji, ale już miałem przyjemność się na nią natknąć na innych stronach w domenie microsoft.com. Podejrzewam, że oficjalna odpowiedź koncernu na ten zarzut brzmiałaby - “compatibility”. lol

Na podręcznym komputerze stoi debian we odmianie testing. Debian w wersji testing jest stabilny na tyle, że rozsądnie updatowany w zasadzie się nie wykłada, a ma nowe wersje oprogramowania. Żeby zwiększyć sobie poziom adrenaliny dość często aktualizuję komponenty bez wczytywania się co te zmiany właściwie wnoszą, (ok, wiem, że to tylko lekkie podniesienie ciśnienia - większe byłoby na unstable/experimental, ale ja naprawdę muszę pracować na tej maszynie ).
Ostatnio niestety, po aktualizacji ponowne wczytanie repozytoriów zakończyło się błędem

Przeniosłem się natychmiast na serwer, gdzie zaktualizowałem repozytoria bez problemu. Najpierw pomyślałem, że to wobec tego problem z transferem, jednak w momencie, gdy synaptic na podręcznym komputerze zapytał się mnie, czy jestem pewien, że chcę instalować niezweryfikowane oprogramowanie (WARNING: The following packages cannot be authenticated!), w głowie zaświeciła się lampa ‘you have been hacked!’. Oczywiście natchmiast przerwałem instalację aktualizacji i rozpocząłem poszukiwanie informacji o tym co się właściwie dzieje. (OK - wiem, że mogłem wpisać apt –allow-unauthenticated, ale to nie jest rozwiązanie, prawda?)
Problem jak się okazało leżał po stronie oprogramowania do zarządzania pakietami - apt. Otóż podczas pobierania danych o pakietach, apt/aptitude/synaptic pobierają plik Release, który zawiera sumy MD5 (a w przyszłości SHA1) pozostałych pobieranych plików, oraz plik Packages.gz, zawierający m.in. sumy kontrolne poszczególnych pakietów. System ten ma w swoich założeniach chronić instalacje pakietów przed zainstaowanie oprogramowania o niesprawdzonej sygnaturze. Oczywiście słabym punktem jest plik Release, zawierający sygnatury wyjściowe. W celu polepszenia bezpieczeństwa, dodany został plik Release.gpg, zawierający tzw. ascii-armored deteached gpg signature, czyli sygnaturę kryptograficzną gpg zapisaną znakami ascii. Pliku tego wymaga apt w wersji 0.6x w górę, co także oznacza, dlaczego wersja stable posiadająca starszego apt’a nie wykazywała tego błędu.

Cała sprawa polegała na tym, iż w momencie, gdy mu się nie zgodzi podpis elektroniczny, to zaczynają się wzmiankowane powyżej problemy. Podpisy dla ftp-master’a mają ważność jednego roku, co oznacza, że na początku roku wygasają. Co oznacza, że generowane są nowe podpisy i starym kluczem już nie sprawdzimy wiadomości (o szyfrowaniu kluczem asymetrycznym nie chce mi się tu rozwodzić).

Trzeba zdobyć teraz ten klucz (klucze można wylistować z pomocą polecenia apt-key list). W zasadzie rzecz jest banalna - mając zainstalowany pakiet gpg-rsca (czyli pakiet wirtualny instalujący gpg-pg) uruchamiamy w kontekście użytkownika aktualizującego system (podpowiem, chodzi zazwyczaj o root’a) gpg z następującymi przełącznikami:

Warto zauważyć, że ważne jest ostatnie 8 znaków klucza. Uzyskany w ten sposób klucz exportujemy w zrozumiałej formie z keyringa do apt-key

(możemy też bezpośrednio nakarmić nim apt’a). Jest jednak pewien problem - gpg, żeby pozyskać klucze łączy się z serwerami na porcie rzędu 11137, co oznacza, że niektórzy mogą mieć z tym problem (złapanie tego klucza z serwera WWW też wymaga połączenia na tym porcie). Rozwiązaniem jest ściągnięcie pliku http://ftp-master.debian.org/ziyi_key_2006.asc, gdzie 2006 to rok na który obowiązuje klucz a ziyi to jakaś chińska tancerka (?) i nakarmienie nim apt-key.
Voila! I po problemie.

Edit: w zasadzie, to pojawiła się nowa paczka, której instlacja sama rozwiąże problem - apt-get install debian-archive-keyring. Jak widać rozwiązanie z secure aptem musi się dotrzeć porządnie zanim będzie mogło przejść do testing, szczególnie, że to przełom roku pokaże sprawność działania infrastruktury…

Edit2: Pozdrawiam czytelników Linux news, którzy zawitali na te strony dzięki pewnej notce - zapraszam do komentarzy!

Powyższy tekst powstał na podstawie doświadczeń własnych oraz tekstu SecureApt, który choć ukazał się późno w stosunku do występującego problemu (niestety), to pozwolił mi usystematyzować wiedzę i który gorąco polecam wszystkim chcącym mocniej zgłębić temat.

W 6 odcinku 5 serii Southpark, Eric Cartman dostaje w spadku milion dolarów i kupuje wesołe miasteczko. Biznes nie przynosi zysków - ale jemu to nie przeszkadza, ma miasteczko tylko dla siebie. Ludzie, jak to ludzie, z ciekawości przychodzą i koniecznie chcą się dostać do tej wyjątkowej puli osób mogących wejść - i są za to wstanie wiele zapłacić.W tą stronę poszło google, tworząc serwis beta gmail.com a następnie google talk. Widzę, że podobna polityka przyświeca ostatnio marketingowcom firmy Microsoft, którzy najpierw tworzą wrażenie zamkniętych testów, szczególnie ograniczonej publiki swoich produktów, która nawet nie może publikować zdjęć. Grupy testerów, do której aby się dostać, ludzie gotowi są płacić konkretne pieniądze. i wszystko to tylko po to, żeby po chwili rzucić na rynek tony ‘zaproszeń’ - rozprowadzanych czy to na bink.nu rozdającemu zaproszenia do Visty, czy też 2k3r2 albo testers paradise rozdającym zaproszenia do MSN Messenger 8.0. Swoją drogą wspaniale, że chłopaki się dzielą, zamiast sprzedawać zaproszenia na ebayu - nie mniej po co to? Po co tworzyć pre-beta preview dla tak szerokiej publiki? Nie lepiej na stałe zmienić politykę wprowadzania produktu na rynek? No, ale z drugiej strony to są jednak ciągnące masy zainteresowane produktem, który kiedyś nadejdzie. Nie mogące o nim zapomnieć… Lejące w majty na myśl o tym, że są pierwsi… Że zobaczą, zanim za preview pojawi sie na technecie. Ciekawe ile nowych osób zarejestrowało sie na bink.nu?

Nie chodzi mi o zazdrość - broń boże! Jak znam życie to visty nie zainstaluję (choćby ze wzgledu na ograniczenia DRM) na swojej maszynie dość długo, a na roboczej to pewnie jeszcze dłużej (dopiero w czerwcu 2004 przesiadłem się na XP). Chodzi mi o jasne stawianie sprawy, o przejrzystość - jesteś testerem, masz taką wersję, publika dostanie to, technet to. Robienie ludziom wody z mózgu fachowo nazywa się marketingiem. tylko dlaczego to ma dotyczyć specjalistów od IT?
P.S. Edycja WYSIWYG w Wordpress 2 to porażka

Debian standardowo jako MTA instaluje Exim’a. Tak samo standardowo natychmiast wymieniam go na postfixa, ze względu na prostotę instalacji oraz konfiguracji tego ostatniego. Faza instalacji przebiega szybciutko, pozostawiając działający serwer SMTP. No - działający o tyle o ile, bo próba wysłania z sieci innej niż wewnętrzne, czy też localhost powoduje błąd bodajże 550, czyli relaying denied.

Admin w takiej sytuacji stoi na rozdrożu - albo otworzyć serwer i dodać się do RBLi jako open-relay, albo wdrożyć jakąś autoryzację. Oczywiście można próbować znaleźć tzw. trzecią drogę, czyli dodawać sieci z których użytkownicy wysyłają pocztę, ale kończy się to na sytuacji, gdy otwiera się na przykład na całą klasę adresową neostrady albo innego chello. Nie na darmo mówili Rzymianie - tertium non datur.

Jeśli chodzi o autoryzację, to najprościej zarówno dla admina jak i użytkowników serwera jest dodać paczkę pop-before-smtp. W zasadzie program prawie nie wymaga konfiguracji (ok, mój przemiły popa3d sprawił tutaj drobne problemy i wymagał ręcznego przeredagowania regexpów), oprócz odhashowania wpisów w /etc/pop-before-smtp/pop-before-smtp.conf dotyczących właściwej identyfikacji faktu autentykacji użytkownika. Sam program działa na zasadzie prostej jak budowa cepa - obserwuje zdefiniowany uprzednio plik, (warto sprawdzić który ma obserwować i to ewentualnie uzupełnic w konfiguracji, np. popa3d wpisuje się domyślnie do daemon.log a ipopd do mail.log), a wypadku zgodności z odpowiednim regexepem dodaje wpis do odpowiedniego pliku (domyślnie /var/lib/pop-before-smtp/hosts). Fakt modyfikacji tegoż pliku wykrywa postfix, któremu w /etc/postfix/main.cf należy do linii mynetworks dodać wpis hash:/var/lib/pop-before-smtp/hosts (o ile zachowaliśmy domyślne ustawienie w zmiennej smtpd_recipient_restrictions i jest tam wartość permit_mynetworks). Wszystko powinno działać, nawet bez zaznaczania magicznej opcji, która pojawiła się w Outlooku 2003 - odbierz pocztę przed wysłaniem. Zazwyczaj użytkownik, w momencie gdy mu się przy pierwszje próbie nie wyśle poczta, wciska ‘Wyślij i odbierz’, no a wtedy wszystkie wpisy sa już aktualne…

No tak, ale porządny admin nie będzie lamerem i nie zostawi tak sprawy. Po co mu dodatkowy soft i to nie zachowujący pełni wygody, skoro użytkownik powinien móc jedynie wysłać pocztę, ze względów chociażby przepustowości łącza w GPRS… (wysyła tylko maila bo ma wordpresa gdzieś, który czyta dość specyficzne maile przechodzące przez rygorystyczną kontrolę… procmaila?). No ale sama autoryzacja to jeszcze nie wszystko, bo latają tacy różni (np. Bigo na MTS2005) z laptopami i nie mając co robić podsłuchują komunikację? Trzeba włączyć także szyfrowanie sesji, żeby nikt użyszkodnikowi hasła nie przechwycił… Ale o tym w częsci drugiej

Zanim przejdę do właściwej treści, to chciałbym powitać wszystkich czytelników w Nowym Roku 2006! Pisanie bloga wymaga pracy (co zauważył Michał w komentarzu na R2), na którą w końcówce 2oo5 nie było niestety czasu, a wszelkie idee artykułów, które ulegały odłożeniu, ulegały także zapomnieniu. Czas nadrobić zaległości

Przy okazji porządków na serwerze przyszedł czas na standardowe zwiększenie poziomu zabezpieczeń jakiegoś protokołu komunikacyjnego - wybór padł na pop3 i smtp. Chciałem włączyć możliwość szyfrowania komunikacji, a po jakimś czasie wymusić konieczność używania szyfrowania. Wykorzystywanym na serwerze demonem, ze względu na prostotę był popa3d (jedyne opcje konfiguracyjne to czy ma chodzić jako standalone a reszta niestety w źródle, ale za to kompilacja także banalna). Ponieważ jednak ustawienie szyfrowania SSL dla tego demona wymagałoby włączenia stunnel’a, czyli dodatkowej jakby nie było pracy, postanowiłem użyc oprogramowania zawierającego take możliwości w sobie. Ponieważ organicznie nie trawię oprogramowania z pakietu courier, a na serwerze już chodził demon uw-imapd-ssl, do kompletu doinstalowałem ipopd-ssl, który także jest dość, (jak myślałem), banalny. Po szybkiej pracy aptitude po chwili cieszyłem się nowym demonem. No, prawie cieszyłem, ponieważ po wykonaniu komendy telnet server 110 dostałem piękny komunikat Unknown AUTHORIZATION state command. Outlook, (co do którego muszę przygotowywać wszelkie konfiguracje), powiedział to samo. Chwila googlania nie przyniosła rezulatów, więc trzeba było odnieść się do katalogu /usr/share/doc (RTFM!).
I cóż się okazało? Otóż oprogramowanie korzystające z libc-client2002edebian ma standardowo wyłączoną możliwość autoryzacji otwartym tekstem, (od razu przypomniało mi się, że imap też miał jakies problemy, ale jako nowo wdrażana usługa został od razu postawiony w wersji z SSL). Objawia się to tym, że w protokole pop3 wyłączana jest propagacja polecenia user. No i po ptakach. Przecież nie odbiorę w poniedziałek tony telefonów od ludzi, którzy nie moga odebrać poczty inaczej niż przez WWW (na szczęście jakaś furtka im została), i nie powiem im, że trzeba wybrac Menu -> Narzędzia -> Konta blah blah blah zakładka blah checkbox blah zakładka blah OK.
W tej sytuacji należało się zagłębić ciut mocniej i… rozwiązanie mnie rozbawiło. Otóż dokumentacja mówi, że: jest nieoficjalna, jest niewspierana, nikt nie bierze za działanie niczego jakiejkolwiek odpowiedzialności, a pierwsza linia pliku konfiguracyjnego, którego oczywiście nie ma, brzmi: “I accept the risk”. Ostatecznie rozwiązaniem okazało się stworzenie pliku /etc/c-client.cf o brzmieniu:

Voila! Ale i tak przestawienie portu na 995 jest zdecydowanie lepsze A zmiana w libc-client przy wymianie wersji może przestac działać…

Ponieważ googlanie mi osobiście nie dało odpowiedzi, zamieszczę ją in English - może komuś się przyda?
Installing (upgrading, etc) package ipopd-ssl/uw-imapd-ssl leaves one without the possibility to authenticate with unencrypted (plain text) password over an insecure connection (except for localhost). To check if this is the problem, one should try to connect over SSL tunnel first (ports 995 for pop3s and 993 for imaps). If this works and normal authorization shows Unknown AUTHORIZATION state command” for pop3 and similar error for imapd, then one need to create file /etc/c-client.cf containing two lines:

Although things should start working now, I strongly advise to switch to secure connection if the server is in the DMZ/internet.