Jak zenbox.pl z domen klientów korzystał

Niedawno na blogu sprawnymarketing.pl pojawił się wpis o tym, jak rzekomo Zenbox stosował black hat SEO. Sprawa okazała się znacznie głębsza, szersza i ciekawa, niż na pierwszy rzut oka wyglądał. W różnych wymiarach, od technicznych, po prawne.

Przede wszystkim, niezaprzeczalnym faktem jest, że niektóre strony (raczej: większość) hostowane na zenbox.pl, pokazywały co innego przy wejściu przez HTTP, a co innego przez HTTPS. Jak pokazują zamieszczone w ww. wpisie zrzuty ekranu, narzędzia do badania SEO zauważały te linki. Raczej słusznie, bo wbrew temu, co twierdzi zenbox.pl, strony te nie zostały zignorowane przez Google, lecz normalnie zaindeksowane, co pokazuje poniższy zrzut ekranu:

Zenbox.pl SEO HTTPS

Szybko okazało się, że zenbox.pl nie jest jedynym hostingiem, który działa w ten sposób. Winny jest prawdopodobnie panel DirectAdmin, którego domyślna konfiguracja powoduje pokazywanie „zaślepki” przy braku podpiętego certyfikatu SSL. Potem było już tylko weselej, bo w dyskusji na Wykopie niektórzy sugerowali, że w zaślepkach powinien być w linkach atrybut nofollow. Uważam, że akurat brak nofollow świadczy w tym przypadku na korzyść zenbox.pl i braku celowego działania – gdyby ktoś zawracał sobie głowę atrybutami czy anchor text (a są i tacy), to znaczy, że pomyślał o pozycjonowaniu.

Jeszcze bardziej dziwi mnie skupienie się na SEO i ominięcie sedna sprawy: nie chodzi o – celowe lub nie – wprowadzenie w błąd Google. Przede wszystkim mamy do czynienia z podmianą treści na stronie zamieszczonej w określonej domenie. Wątpię, by właściciele domen mieli wiedzę, że taka podmiana miała miejsce. Jeszcze bardziej wątpię w ich zgodę na takie działanie.

HTTPS zamiast HTTP niewiele tu zmienia – oczywiście jest możliwość serwowania różnych treści w zależności od protokołu, podobnie jak strona z przedrostkiem www (de facto subdomena) z technicznego punktu widzenia może kierować zupełnie gdzie indziej, niż domena bez takiego przedrostka, ale przyjęte jest, że kierują w to samo miejsca. W przypadku HTTPS jest to IMO wręcz oczywiste.

Pamiętajmy też, że strony WWW, zwłaszcza popularniejsze blogi, potrafią po prostu sprzedawać miejsce na reklamę na stronie. Wydaje mi się, że w przypadku takich blogów wykazanie szkody w sądzie byłoby trywialne. Dlatego podejście zenbox.pl do sprawy mnie dziwi. Jak widać w komentarzach na blogu, mamy kolejno:

  1. straszenie „na takie działania godzić się nie można i zrobimy wszystko aby takie akcje miały konsekwencje”
  2. negacja, najpierw problemu w ogóle (screenshot w ww. wpisie), potem wpływu „działania nie mają wpływu na pozycję stron klientów ani wpływu na pozycję witryny zenbox.pl”
  3. przyznanie istnienia problemu „wspomnianego problemu nie doświadczyli” i w końcu podjęcie działań (zmiana konfiguracji, mailingi)

Wydaje mi się, że znacznie bardziej na miejscu byłaby analiza sytuacji, podziękowanie za zwrócenie uwagi, naprawienie problemu (poprawa konfiguracji) i przeproszenie klientów.

Cała sprawa ma jeszcze jeden ciekawy aspekt. Wydaje mi się, że największy błąd popełniło… Google, które podmienioną treść na stronie jak widać łyka jak pelikan. Mimo ewidentnych błędów HTTPS (certyfikat nie pasuje do domeny), które m.in. przed taką podmianą miały chronić. W czasach, gdy każda domena może mieć rozpoznawany przez przeglądarki certyfikat SSL za darmo (oczywiście chodzi o projekt Let’s Encrypt) strony za niepasującymi, wygasłymi i self signed certyfikatami powinny po prostu być ignorowane.

Prawidłowa konfiguracja to IMHO ta sama treść dostępna po HTTP i HTTPS. Czy to za sprawą odpowiedniego przekierowania (to sensownie uda się tylko z HTTP na HTTPS…), czy też – zwł. na shared hostingu – pod certyfikatem hostingodawcy, jeśli domena nie ma własnego.

Rozważania o blokowaniu ekranu

Przy okazji trwającej dramy dotyczącej xscreensavera w Debianie[1] przypomniał mi się pokrewny temat, o którym miałem robić wpis jakiś czas temu. Chodzi o blokadę dostępu do komputera, niezależnie od używanego systemu (Windows, Linux, OS X). Tradycyjnie jest to jakiegoś rodzaju wygaszacz ekranu, który po pierwsze blokuje możliwość odczytu danych z ekranu, po drugie, blokuje możliwość wprowadzania danych do uruchomionych programów. Do odblokowania zwykle konieczne jest podanie przez użytkownika hasła do systemu.

Rozwiązanie znane jest od dawna i wydawać by się mogło, że to wystarczy, ale czy tak jest faktycznie? Coraz więcej danych jest wprowadzanych i odbieranych z komputera nie tylko przy pomocy klawiatury i ekranu, ale także przy pomocy innych urządzeń. Programy do komunikacji VoIP, czy to Skype, czy aplikacja dostępna przez przeglądarkę typu appear.in czy hubl.in, po zablokowaniu ekranu nadal działają. Umożliwiają i odsłuchiwanie połączonych osób, i przekazują dane z otoczenia do nich. Zarówno za pośrednictwem audio, jak i video. Blokada ekranu co prawda wyłączy możliwość podglądu naszego rozmówcy, ale już nie wyłączy naszego webcama…

Jak na razie nie wiem nic o alternatywach dla wygaszaczy ekranu, które w momencie aktywacji blokowałyby nie tylko klawiaturę i ekran, ale dodatkowo wyłączały webcam(y) oraz wyciszały (mute) audio[2]. Pobieżne testy urządzeń z Androidem pokazują, że także na nich problem jest aktualny, przynajmniej w zakresie dźwięku. Warto po prostu pamiętać, że zablokowany komputer czy telefon w naszym otoczeniu wcale nie musi być tak do końca zablokowany…

[1] Skomentowałem u developera na blogu i wystarczy, wpisu nie będzie, sytuacja jest IMHO żenująca, więc szkoda klawiatury – jeśli ktoś ma cierpliwość, to wystarczy śledzić podlinkowane źródła.

[2] Jeśli istnieją systemy z takimi rozwiązaniami, albo samodzielne aplikacje, to chętnie poznam – u nikogo z nowszym Windowsem nie widziałem takiego rozwiązania.

Let’s encrypt i lighttpd – HOWTO

Czym jest Let’s Encrypt wie już chyba każdy, kogo interesują certyfikaty SSL. Wypada jednak 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. 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. Dodatkowo 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. Liczę więc, ż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 użycia dla różnych serwerów.