Letsencrypt i lighttpd – HOWTO

Czym jest Let’s Encrypt wie już chyba każdy, kogo interesują certyfikaty SSL, ale wypada jakieś wprowadzenie napisać, więc: to prosty sposób na odnawialne automatycznie, rozpoznawane przez przeglądarki, bezpłatne certyfikaty SSL dla każdego. Projekt jest w fazie public beta, więc przystąpić może każdy, stoją za nim duzi (przykładowi, bardziej znani sponsorzy: Mozilla, EFF, Cisco, OVH, Google Chrome, Facebook), więc raczej coś z tego będzie i jest krokiem w kierunku zwiększania bezpieczeństwa w sieci pod hasłem wszystko po HTTPS (które to rozwiązanie ma wady, ale o tym już było).

Let's Encrypt logo

Źródło: https://letsencrypt.org/trademarks/

Ponieważ właśnie dostałem maila od Let’s Encrypt, że wygenerowany przez nich, darmowy certyfikat SSL dla mojej domeny wygasa, postanowiłem skorzystać z największego dobrodziejstwa, czyli zautomatyzować całość. Prosty skrypt, który zadziała dla lighttpd i jednej domeny:

#!/bin/bash LECMD="/opt/bin/letsencrypt/letsencrypt-auto"DOMAIN="mojadomena.com"WEBROOT="/var/www/mojadomena.com/html/"EMAIL="adres@email"$LECMD --renew-by-default -a webroot --webroot-path $WEBROOT --server https://acme-v01.api.letsencrypt.org/directory --email $EMAIL --text --agree-tos -d $DOMAIN authcat /etc/letsencrypt/live/$DOMAIN/privkey.pem /etc/letsencrypt/live/$DOMAIN/cert.pem > /etc/letsencrypt/live/$DOMAIN/ssl.pemservice lighttpd restart

Zakładam oczywiście, że skrypt letsencrypt jest pobrany z gita, masz dostęp do roota, lighttpd jest skonfigurowane i ma podpięty certyfikat SSL. Plus, że w konfiguracji lighttpd jest linia w stylu:

ssl.pemfile = "/etc/letsencrypt/live/mojadomena.com/ssl.pem"

To co wyżej to sama esencja, brakuje choćby kontroli błędów/statusu wykonania poleceń, ale wywołane z ręki działa i pewnie dodam do crona wykonywanie raz w miesiącu (wzmocnione przez && w ramach „kontroli błędów”). Opisuję, by mi nie zginęło, poza tym, widziałem albo skrypty automatyzujące, albo opisy uruchomienia letsencrypt z lighttpd, więc liczę, że zebrane do kupy się komuś przyda.

UPDATE Wpis się lekko zdezaktualizował o czym więcej w tym wpisie. A krótko: jest gotowiec od EFF o nazwie Certbot do automatycznego zarządzania darmowymi certyfikatami SSL Let’s Encrypt, z opisami dla różnych serwerów.

Włamanie na serwery Minta

Jak donosi blog Minta, atakujący wykradli bazę danych (pełną – hash hasła, adres email, wiadomości prywatne) użytkowników forum, udało im się też podmienić linki na stronie kierując do wyposażonego w backdoora ISO.

Z racji zamykania Joggera trochę przeglądałem stare wpisy i widzę, że to nie pierwszy raz i nic nowego[1]. W roku 2008 doszło do włamania na serwery Fedory oraz Red Hata. Wtedy atakującym udało się nawet podpisać pakiety SSH w Red Hacie, co uważam za groźniejsze. Włamanie na serwery Linux Mint przypomina mi zatem póki co bardziej to, co spotkało choćby TAILS, czyli jedynie naruszenie dystrybucyjnego „frontendu”, bez dostępu do kluczowych elementów dystrybucji.

Warto przypomnieć o sprawdzaniu podpisów pobranych ISO[2]. I nie chodzi mi o sumy kontrolne typu MD5 czy SHA1, które są zamieszczane na stronach WWW, a o podpisy GPG, które dobrze opisuje strona TAILS. Suma kontrolna weryfikuje jedynie brak przekłamań przy pobieraniu i zapisie. Pobieranie przy pomocy protokołu torrent również nie jest gwarancją autentyczności ISO! Pojawiają się informacje, że ISO Linuksa Mint pobrane przez torrent były bezpieczne, ale stało się tak tylko dlatego, że przypadku atakujący po prostu nie pomyśleli o publikacji zainfekowanej wersji ISO przez torrent i podmianie plików torrent na stronie.

[1] Widzę też, że kiedyś pisałem o takich drobiazgach na blogu, teraz bym pominął, gdybym nie znalazł tamtego wpisu… Czasy się zmieniają, ludzie się zmieniają nawet nar^Wblogi się zmieniają.

[2] Na temat kontenerów różnej maści tym razem będę litościwie milczał.

Blog roku 2015

Logo Blog Roku 2015

Trochę za sprawą zamknięcia Joggera i uświadomienia sobie, że bloguję ponad 10 lat, bardziej za sprawą zachęty ze strony Blox, postanowiłem zgłosić tego bloga do konkursu Blog Roku 2015. Bez złudzeń[1]. 😉 Ale zawsze jest to szansa na dotarcie do paru nowych czytelników, a „kosztuje” tyle, co wypełnienie zgłoszenia, więc niech będzie.

Fun fact: grafika promująca z oficjalnej strony (602×452 px, PNG) waży 389 kB. Zmiana formatu na JPG (85%) powoduje spadek rozmiaru do 94 kB. Blogerzy, dbajmy o mobilki!

[1] Znaczy jak ktoś wyśle SMS, to bardzo mi miło, choć osobiście uważam, że są lepsze sposoby spożytkowania tych pieniędzy. Choćby WOŚP. Doczytałem, że środki uzyskane przez organizatora z głosowania SMS zostaną przekazane Fundacji Dziecięca Fantazja, więc głosując robicie dwa dobre uczynki w jednym. 😉

Chcesz zagłosować? Wyślij SMS o treści E11332 na numer 7124. Koszt SMS 1,23 zł (z VAT).

UPDATE Głosowanie zakończone, wynik nienajgorszy: etap SMS 1 głos.

Zamknięcie serwisu jogger.pl

Wczoraj przeczytałem ogłoszenie o planowanym zamknięciu serwisu jogger.pl. Mimo wszystko smutno, bo było to miejsce, gdzie znalazłem wiele ciekawych blogów (czyt.: ludzi), a przede wszystkim miejsce, gdzie zacząłem przygodę z blogowaniem. Więc trochę wspomnień jest. Nawet myślałem o tym niedawno, bo nie dalej jak parę dni temu wpisałem w CV w zdolnościach komunikacyjnych ponad dziesięć lat pisania blogów… No i cała otoczka sieciowa, od składni HTML przez Markdown i jakiekolwiek pojęcie o standardach dotyczących stron WWW, zawdzięczam Joggerowi.

Tak czy inaczej, wiadomo było, że ten moment nastąpi. Żaden serwis nie może stać w miejscu – albo się rozwija, albo – prędzej czy później – umiera. Widać było, że czasu i chęci na rozwój i utrzymanie brakuje coraz bardziej, a autorzy mają opory przed opublikowaniem kodu as is. Była co prawda propozycja przepisania Joggera, czyli wersji 3.0, ale jak pisałem, i za późno, i nie tędy droga.

Dawno temu porównywałem Joggera i Blox, nawet dwa razy. Pod wieloma względami Jogger miał bardzo ciekawe rozwiązania (integracja z jabberem, poziomy wpisów, możliwość dynamicznych feedów RSS, ciekawy, dający bardzo dużą kontrolę nad blogiem, system szablonów). Udało się też przyciągnąć ciekawie piszących ludzi. TBH nadal regularnie czytam parę osób z Joggera. W pewnym momencie coś nie wypaliło/coś się posypało (tak pobieżnie patrząc, to stała pięta achillesowa Joggera, czyli kontrola nad komentarzami i spamem…). IMHO ciekawy temat do analizy, swoją drogą.

Pisałem już o tym w komentarzu (podkreślam, nie negując w żaden sposób praw właścicieli do kodu i domeny), ale powtórzę, bo to nie jest IMO dobre zamknięcie, a stamtąd zaraz zniknie:

  1. Mało czasu na wyniesienie się. Pięć tygodni przy braku narzędzi i planu, to niewiele. Nie widać powodu, czemu akurat teraz i tak nagle (oczywiście może być coś, o czym autorzy nie chcą/nie mogą pisać), więc można by ten czas wydłużyć.
  2. Można było rozważyć przejście do wersji archiwalnej – read only, bez możliwości komentowania. Przypuszczam, że całość obecnie dostępnej treści to raptem małe kilkaset GB, więc koszt utrzymania i nakład pracy są minimalne, podejrzewam, że aktualnie używający chętnie się zrzucą.
  3. Można w końcu uwolnić kod źródłowy – jest tam parę osób technicznych, może ktoś się skusi na kontynuację, może pohostuje innym…
  4. Można sprzedać serwis bez danych osobistych. Wystarczy nie eksportować/usunąć wpisy na poziomie 3 i wyższych.
  5. Nieszczęśnikom, którzy nie korzystali z własnych domen można udostępnić subdomeny na prawach domeny.
  6. No i w końcu: można było zapytać ludzi, jakie widzą rozwiązania.

Tak czy inaczej, kolejny serwis z którego korzystałem umiera (wcześniej zniknął blip.pl), i trochę żal. Szeroko rozumianej ekipie z Joggera dziękuję za wszystko.

UPDATE Administratorzy Joggera jednak nie planują po prostu trzasnąć drzwiami, a kwiecień nie jest datą ostateczną, po prostu kod jest stary, utrzymanie pracochłonne stąd pomysł wyłączenia serwisu w dotychczasowej formie. Prawdopodobnie zostanie zachowana jakaś forma statyczna strony, archiwum i zbiór linków do miejsc, w których autorzy będą utrzymywać swoje blogi.

UPDATE2 Statyczny mirror bloga na Joggerze można zrobić przy pomocy opisywanego kiedyś sposobu na backup bloga przy pomocy wget. Efekt działania wersji statycznej można zobaczyć tutaj.

Jak zrobić router GSM na Linuksie?

Niedawno miałem awarię netu. Stwierdziłem, że warto przy tej okazji poćwiczyć awaryjne udostępnianie sieci na Linuksie. Oczywiście zrobienie routera z komputera z Linuksem to kwestia paru poleceń, ale stwierdziłem, przećwiczyć udostępnianie sieci po wifi.

Istnieje pakiet hostapd, który ułatwia zamianę komputera z Linuksem w access point. Instalacja pakietu hostapd:

apt-get install hostapd

Jakość pakietu nie zachwyca, ale jest niezły tutorial do hostapd. Skrypt init nie zadziała (należy go uzupełnić o ścieżkę do pliku – zmienna DAEMON_CONF), podobnie sam pakiet nie dostarcza – jak to zwykle ma miejsce w przypadku pakietów Debiana – pliku konfiguracyjnego umieszczonego w katalogu /etc. Przykładowy plik konfiguracyjny dla hostapd znajdziemy jednak w /usr/share/doc/hostapd/examples.

Żeby nie przedłużać, poniżej cały plik konfiguracyjny, którego ostatecznie użyłem:

interface=wlan0country_code=PLssid=NAZWA_SIECIhw_mode=gchannel=6wpa=2wpa_passphrase=TAJNE_HASLOwpa_key_mgmt=WPA-PSKwpa_pairwise=TKIPrsn_pairwise=CCMPauth_algs=1macaddr_acl=0

Jak widać, są lekkie różnice w stosunku do tutoriala. Brakujące ustawienie zmiennej w skrypcie startowym znalazłem później, więc ostatecznie uruchamiałem hostapd z ręki, bez demonizacji (w ramach debugu, zresztą).

Oczywiście sama konfiguracja hostapd nie wystarczy. Trzeba mieć jeszcze skonfigurowane „przyjście” netu. W moim przypadku internet był dostarczony z modemu GSM (tutaj opis konfiguracji Aero2 na modemie Huawei E3131). Użycie modemu LTE pozwoli oczywiście zrobić router LTE na Linuksie. Przyda się również serwer DHCP i konfiguracja DNS. Obie rzeczy może załatwić dość dokładnie opisany kiedyś dnsmasq, ale tak naprawdę dla przydzielania adresów IP systemom łączącym się z naszym routerem GSM wystarczą dla ww. konfiguracji dwie linie w /etc/dnsmasq.conf:

interface=wlan0dhcp-range=192.168.1.100,192.168.1.200,255.255.255.0,1h

Należy też dodać adres IP na interfejsie wlan0, włączyć forward pakietów dla IPv4 oraz uruchomić NAT. Wersja „ręczna” ww. czynności (dla mojej konfiguracji, interfejsy mogą się zmieniać) to:

ip a a 192.168.10.1/24 dev wlan0
ip link set wlan0 up
service dnsmasq restart
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Po tym wszystkim, inne komputery powinny móc się połączyć z naszym linuksowym routerem GSM, dostać adres IP oraz posiadać dostęp do internetu za jego pośrednictwem. W przypadku problemów warto sprawdzić kolejno: otrzymanie adresu IP, ping do routera (192.168.10.1), ping do świata po IP, ping do świata pod domenie (w zasadzie: resolvowanie DNS).

Na rynku jest sporo sprzętów, które pozwolą na budowę mocnego routera GSM na Linuksie (przykładowo Banana Pi, Orange Pi czy nieśmiertelne Raspberry Pi). Oczywiście jeśli miałby być to sam router, to nie bardzo widzę sens ekonomiczny, bo zestaw modem+płytka+karta wifi+zasilacz pewnie będzie kosztował więcej, niż tani router LTE (no chyba, że ktoś akurat – jak ja – ma ww. graty pod ręką 😉 ), ale w przeciwieństwie do taniego routera GSM można tu uruchomić dodatkowe funkcjonalności typu NAS, VPN czy serwer WWW. Ten ostatni to może niekoniecznie na łączu GSM…

Mam nadzieję, że opis się przyda. Gdybym o czymś zapomniał, albo coś nie działało, proszę o uwagi.

PS. Oczywiście mam świadomość, że udostępnienie internetu z GSM potrafi w trzech kliknięciach zrobić chyba każdy smartfon z Androidem i w przypadkach awaryjnych jest to najszybsza droga. I tak, użyłem Aero2 i pakietu testowego bez captcha. Niskie opóźnienia pozytywnie zaskakują.

Ubuntu 14.04 LTS, apt-dater i restart usług

Jakiś czas temu zachwalałem apt-dater jako narzędzie do aktualizacji większej ilości systemów. Jak pisałem w późniejszych uwagach, apt-dater nieźle integruje się z programem needrestart. Tyle teorii…

Niestety, o ile na Debianie Jessie wyglądało to naprawdę dobrze i sprawdzenie przez checkrestart (inne polecenie realizujące podobne zadanie) dawało spójne wyniki z needrestart, o tyle na Ubuntu 14.04 LTS needrestart pokazywał często, że do restartu nic nie ma, o tyle checkrestart był zupełnie innego zdania... I – co gorsza – miał rację.

Przyczyną okazała się różnica w wersji needrestart. W Jessie jest to 1.2, w Ubuntu 14.04 LTS – 0.5. Ponieważ to skrypt perlowy, to dałem szansę i wrzuciłem wersję z Debiana (stable). Instaluje się czysto, działa bardzo dobrze – w połączeniu z apt-dater wykrywa więcej usług do restartu i także tu wyniki needrestart są teraz spójne z checkrestart.

Nawiasem, checkrestart w Jessie ma problem z mysql i zawsze pokazuje, że należy go zrestartować. Jest na to zgłoszony bug. Ale to tak nawiasem, kto korzysta, ten wie, zresztą można dopisać mysql do wyjątków w konfigu.