Serwis webhostingtalk.pl traktujący o polskim hostingu został kupiony przez Nazwa.pl. Więcej można przeczytać na Wykopie i na samym forum. Nie pisałbym o tym, ale mam przeczucie, że na skutek intensywnego zamiatania pod dywan różnymi sposobami link może zniknąć, więc w ramach mirrora będzie wpis.
Forum było jakie było, ranking też. Wiadomo, że przy swobodnej wypowiedzi ludzie zamieszczają różne opinie i że są to tylko opinie pojedynczych osób. Do których jak najbardziej mają prawo. Wiadomo też, że człowiek, żeby coś zrobić, potrzebuje bodźca. Niemniej, część firm posiadała wysokie oceny, a samo forum było neutralne i funkcjonujące na przejrzystych zasadach.
Tymczasem po kupnie, oceny Nazwa.pl zostały zmodyfikowane. Oczywiście na korzyść firmy. Z 49 opinii o Nazwa.pl istniejących we wrześniu 2016 zostało 31. Średnia ocena zmieniła się z 2,27 na 4,07. Co ciekawe, było 18 osób poleca i 31 nie poleca. Teraz jest 26 poleca, 5 nie poleca. Oczywiście nie sposób wykluczyć, że naturalnie pojawiło się w tym czasie 8 pozytywnych opinii, ale biorąc pod uwagę dotychczasowe ilości, jest to bardzo mało prawdopodobne. Bardzo prawdopodobna jest za to manipulacja, mająca na celu wybielenie Nazwa.pl.
Pojawił się też wątek wzrostu liczby domen, który powoduje, że Nazwa.pl wskoczyła na pierwsze miejsce w rankingu, ale to trochę bardziej skomplikowane, więc z braku czasu pomijam.
Wygląda, że szykuje się lekka rewolucja w mobilnej części internetu. Wersja testowa (canary) Chrome w wersji mobilnej wyposażona jest przez producenta w blokowanie inwazyjnych reklam. Zobaczymy jak to w praktyce wyjdzie, ale wygląda, że szykuje się zmiana zasad gry - de facto oznacza to kontrolowanie rynku reklam przez dostawcę przeglądarki, będącego przy okazji jednym z większych (o ile nie największym) graczy na rynku reklamy w sieci. Podobna zmiana jest zapowiedziana dla wersji desktopowej na początek roku.
Firefox Focus już w tej chwili ma podobne rozwiązanie - wbudowana blokada reklam i ochrona prywatności. Przy okazji, przetestowałem Focusa i wygląda on bardzo zachęcająco. W przeciwieństwie do Firefoksa jest lekki (~2 MB do pobrania) i działa żwawo. Czego o Firefoksie (no dobrze, rok temu, nie wiem jak teraz) powiedzieć się nie dało, więc na smartfonie korzystałem z Chrome. W każdym razie Focus domyślnie blokuje reklamy, nie ładuje zbędnych części strony i czyści historię, co czyni tradycyjne ad-trackery bezużytecznymi. Chwilę poklikałem - jest szybko, jest wygodnie, strony wyświetlały się OK. Polecam, jeśli ktoś nie potrzebuje na smartfonie tabów w przeglądarce. Niestety nie widzę wersji dla desktopa ani kodu źródłowego.
Mam mieszane uczucia jeśli chodzi o korzyści dla użytkowników. Z jednej strony strony mają być szansę lżejsze, nie zamulać urządzeń zbędnymi javascriptami czy animacjami i ładować się szybciej, zużywając mniej transferu. Z drugiej strony, szczególnie w przypadku Google, nie mam złudzeń. Natura nie znosi próżni, więc reklamy nadal będą. Ale od Google (lub za ich zgodą). A Google i tak ma śmieci w reklamach AdSense. Podobnie ze śledzeniem - może strony nie będą w stanie tego robić, ale przeglądarka jak najbardziej... No i może historia zatoczy koło - albo płatna przeglądarka, albo wyświetlanie reklam? To już oczywiście było, w czasach płatnej wersji Opery.
W każdym razie właściciele stron stracą (znowu) trochę wolności.
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:
Szybko okazało się, że zenbox.pl nie jest jedynym hostingiem, który działa w ten sposób, a 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:
straszenie "na takie działania godzić się nie można i zrobimy wszystko aby takie akcje miały konsekwencje"
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"
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.
Pierwszego kwietnia SixXS wysłał do swoich użytkowników maila, w którym poinformował, że
We are now fully stopping accepting signups and tunnel & subnet requests.
Czyli że ograniczają świadczenie usług do istniejących klientów i usług. Decyzja jest motywowana brakiem czasu oraz tym, że część ISP uważa, że darmowe tunele IPv6 są dla nich alibi do nie wdrażania IPv6 swoim klientom końcowym.
Unfortunately it seems a large number of ISPs think that our service is a free pass for them to not deploy IPv6, as they direct their (paying) customers who want IPv6 to our service.
Trudno się z tym nie zgodzić. Wdrożenia IPv6 są rzadkością, także - czy może raczej: zwłaszcza - w Polsce (tu ciekawa prezentacja z Orange z komentarza do innego wpisu, dzięki za podrzucenie).
Piszę o tym z dwóch powodów. Po pierwsze, gogoNET ogłosił, że się zamykają:
After 5 years we are closing down gogoNET on April 23, 2016. Freenet6 will continue to work for some time but we can't guarantee for how long.
Po drugie, umknęła mi dość istotna akcja pt. zadzwoń do ISP po IPv6. Jest też uruchomiona wiki, gdzie można wpisywać co udało się osiągnąć w sprawie IPv6.
Nie jestem do końca przekonany, czy rewolucję należałoby faktycznie zaczynać od ISP, ale faktem jest polscy dostawcy treści nadal nie dystrybuują treści po IPv6 (brak rekordów AAAA, źródło ww. prezentacja), a IPv6 w większości przypadków jest poruszane jedynie od święta, na spotkaniach branżowych typu PLNOG.
Warto w tym momencie przypomnieć (nieco zbyt ambitne IMO) stanowisko prezesa UKE, zakładające, że końcowi użytkownicy otrzymają publiczne adresy IPv6 od stycznia 2012 (stacjonarni, mobilni rok później). Tymczasem otwarte pozostaje pytanie kiedy nadejdzie era IPv6?
To co, "zadzwonimy" do ISP? Wpisujcie na wiki i w komentarzach, co usłyszeliście. A cudzysłów, bo może być zgłoszenie emailem czy zapytanie w social media. Kto wie, czy to ostatnie nie jest najlepsze...
Parę dni temu do przeglądarek dostępnych na rynku dołączył nowy gracz - Vivaldi. A w zasadzie nie tyle dołączył, co ukazała się wersja 1.0. Oczywiście zainstalowałem i się pobawiłem. Jest parę ciekawych ficzerów, które przypadły mi do gustu, ale nie wszystko mi się podoba.
Pierwszą rzeczą, którą widzimy po instalacji i uruchomieniu przeglądarki, jest tzw. wizard. Można wybrać schemat kolorów, rozmieszczenie belki z tabami i... obrazek, który będzie służył za tło przy speed dial. Wszystko oczywiście można zmienić później w ustawieniach, ale uważam, że taka szybka i łatwo dostępna personalizacja to miła rzecz. Poza nieszczęsną tapetą dla speed dial - po co tam komu tapeta? Przecież to potrzebne jak tapeta w systemie - widzę ją przez parę sekund po uruchomieniu i tyle.
Kolejną rzeczą, która zwróciła moją uwagę, jest pasek postępu - pokazuje ilość pobranych danych, postęp ładowania w postaci przesuwającego się paska i chyba ilość obrazków na stronie. W każdym razie kiedyś któraś przeglądarka już tak miała i uważam to za lepsze rozwiązanie, niż niewiele mówiące kręcące się kółeczko.
Vivaldi ma chyba pewne ambicje do zastąpienia systemu operacyjnego. Jest i wspomniana tapeta, jest wbudowany w przeglądarkę klient poczty, jest możliwość tworzenia notatek, no i w końcu są panele, czyli tak naprawdę funkcjonalność kafelkowego managera okien. O ile do pierwszych dwóch podchodzę zdecydowanie negatywnie, to do tworzenia notatek mam mieszane uczucia. Za to panele nawet mi się podobają - jest to coś w stylu mini strony WWW, domyślnie w wersji mobilnej, dostępna na każdej zakładce. Po prostu podział powierzchni okna na dwie części. Przy obecnych szerokich monitorach może zdawać egzamin, a w panelach można umieścić np. social media, które i tak nie wymagają wiele miejsca.
OgólnieVivaldi bardzo przypomina mi Operę. Jak się okazało, słusznie, bo projekt tworzą ludzie, którzy kiedyś pisali Operę. Jest parę różnic, przede wszystkim większy nacisk na prezentację. Jest parę innowacji, więc przypuszczam, że - podobnie jak niegdyś Opera - Vivaldi zdobędzie pewne grono gorących zwolenników. Wielkiej popularności nie wróżę, ale zdecydowanie warto spróbować. Ja planuję od czasu do czasu używać, być może Vivaldi zostanie moją przeglądarką do social mediów.
Na koniec słowo o obsługiwanych systemach operacyjnych - Vivaldi dostępna jest dla Maców, Windows (wersje 32 i 64 bit) oraz Linuksa (pakiety deb i rpm w wersjach 32 i 64 bit). Twórcy nie chwalą się adresami repozytoriów, ale są one dostępne i dodawane automatycznie po instalacji (bez ostrzeżenia, nie lubię). Dla porządku, dla gałęzi stabilnej przeglądarki i Debiana wpis dla sources.list to:
deb http://repo.vivaldi.com/stable/deb/ stable main
Dawno nie było notki. W sumie to chyba jeszcze nie było tak długiej przerwy między wpisami. Nie dlatego, że nic się nie dzieje, bo się dzieje aż za dużo, ale po pierwsze jakaś blokada przed jakimkolwiek pisaniem (nie tylko na blogu), po drugie, jakiś taki wypompowany z pracy przychodzę, że mi się nie chce już pisać, nawet jak są ciekawe tematy. No to może na przełamanie...
Ostatnio jeden z czytelników przysłał maila z pytaniem: czy jest możliwość zmodyfikowania TOR-a tak by zawsze przydzielał polski adres IP? Już zacząłem odpisywać, że byłoby to bez sensu, bo przecież wybór exit node tylko z jednego kraju znacznie zmniejsza poziom anonimowości (nie rozwijając: i łatwiej podsłuchać, i łatwiej namierzyć korzystającego), ale... coś mnie tknęło i zacząłem drążyć temat, bo patrząc na to z drugiej strony, do pewnych usług dostęp może być tylko z pewnych lokalizacji geograficznych.
Podrążyłem i - ku memu niewielkiemu zdziwieniu - okazuje się, że można wybrać kraj, czyli np. użyć sieci Tor do obejścia blokady regionalnej. Co lepsze, można wybrać zarówno konkretny exit node, z którego chcemy korzystać (lub ich zbiór), jak i sam kraj (lub zbiór krajów).
Za każdym razem zmiany należy wprowadzić w pliku torrc (pod Debian/Ubuntu: /etc/tor/torrc) i przeładować Tora. Podobno działa, mi na TAILS nie udało się wyedytować konfiga i uruchomić ponownie Tora (ale nie drążyłem specjalnie).
Źródła (i więcej informacji, w tym lista kodów krajów):
Odwieczny problem administratorów sieci to mogę sprawdzić trasę od siebie do danego hosta, ale jak wygląda w drugą stronę? Próbą rozwiązania tego zagadnienia były looking glass, pozwalające na wykonanie od określonego operatora ping czy traceroute. Czasem potrzeba jednak czegoś więcej - sprawdzenia resolvowania DNS, zbadanie stabilności transferu itp. Ogólnie przydałby się shell.
Projekt NLNOG RING jest odpowiedzią na to zapotrzebowanie. Opiera się na prostej zasadzie wzajemności: udostępniamy maszynę wirtualną (administrowaną przez opiekunów projektu) dla projektu, w zamian otrzymujemy dostęp do pozostałych maszyn projektu, w różnych częściach świata i - co ważniejsze - w wielu różnych ASN.
Wymagania co do maszyny są naprawdę niewielkie - 1 GB RAM, 20 GB dysku, 1 core 64bit procesora, adresy IPv4 oraz IPv6. Musi stać w naszym AS i na naszej adresacji. Myślę, że w tej chwili większość operatorów, nawet niewielkich sieci radiowych jest w stanie sprostać. Pozostałe wymagania stawiane organizacji (usługa jest kierowana do firm) to m.in.: bycie operatorem sieciowym, własne ASN, prefiksy IPv4 i IPv6, zgoda organizacji na uczestnictwo w projekcie.
Możliwe jest zarówno połączenie po SSH do wybranej maszyny, jak i wykonywanie, przy pomocy dostępnych narzędzi, operacji na wszystkich maszynach projektu jednocześnie. Generalnie potrafi bardzo pomóc w diagnostyce.
Projekt działa od wielu lat, ale dziś dowiedziałem się, że nawet w środowisku sieciowym niekoniecznie jest znany, więc uważam, że warto przypomnieć o jego istnieniu. Teoretycznie istnieje ryzyko nadużyć, ale użytkownikami są administratorzy sieci, polityka to zero tolerancji dla nadużyć i nie kojarzę jakichkolwiek problemów związanych z udostępnianiem maszyny. Korzystałem, polecam.
Wszystko zaczęło się od tego, że Wampiryczny blog zmienił sposób dostępu, wymuszając HTTPS. Skomentowałem pół żartem, pół serio. Dostałem odpowiedź w komentarzu, przeczytałem i trochę mi się włos zjeżył na głowie. Bo zdecydowanie o zużyciu energii ktoś nie pomyślał. Jak jestem zwolennikiem udostępniania treści po HTTPS i bardzo sobie ostrzę zęby na projekt letsencrypt.org, tak uważam, że wybór powinien być po stronie odbiorcy, a jedynie miejsca, gdzie są przesyłane wrażliwe dane (np. hasła) powinny mieć wymuszony HTTPS.
Postanowiłem zrobić mały test, czyli pobrać stronę po HTTP i zobaczyć, ile zostało pobranych bajtów (i w jakim czasie), a następnie to samo dla HTTPS. Jako system został użyty base system Debiana, uruchomiony w wirtualce (KVM), uruchomionej na laptopie. Jako stronę serwującą dokładnie to samo po HTTP i HTTPS dobrzy ludzie podrzucili stronę OVH. Google.com na ten przykład serwowało wgetowi nieidentyczną zawartość.
HTTP
$ ifconfig eth0 | grep "RX bytes" ; time for NUM in {1..20}; do wget --no-check-certificate -qO - http://ovh.pl/ >> out_http.txt; done ; ifconfig eth0 | grep "RX bytes"
RX bytes:11251203 (10.7 MiB) TX bytes:495042 (483.4 KiB)
real 0m9.471s
user 0m0.000s
sys 0m0.772s
RX bytes:14173253 (13.5 MiB) TX bytes:583042 (569.3 KiB)
Jak widać wysłano 88000 bajtów, odebrano 2922050.
HTTPS
$ ifconfig eth0 | grep "RX bytes" ; time for NUM in {1..20}; do wget --no-check-certificate -qO - https://ovh.pl/ >> out_https.txt; done ; ifconfig eth0 | grep "RX bytes"
RX bytes:14173313 (13.5 MiB) TX bytes:583102 (569.4 KiB)
real 0m13.938s
user 0m0.000s
sys 0m0.904s
RX bytes:17387531 (16.5 MiB) TX bytes:739702 (722.3 KiB)
Z kolei tutaj wysłano 156600 bajtów, a odebrano 3214218.
Podsumowując: HTTPS w tym teście był wolniejszy o 46%, przy korzystaniu z niego wysłane zostało o 78% więcej danych, a odebrano o blisko 10% więcej danych. Efekt, czyli pobrana zawartość jest dokładnie taka sama. Oczywiście ww. narzut procentowy będzie się różnił w zależności od rozmiaru pliku wynikowego, ale jak widać narzuty są spore.
Do prędkości bym się zbytnio nie przywiązywał, bo o ile za brak ruchu na wirtualce ręczę, to na lapku różne rzeczy się dzieją, choć generalnie idluje, a sam lapek zapięty po wifi. Niemniej, pomiarów było kilka, także dla mojej strony ze stanem rowerów na stacjach Nextbike. Wyniki podobne - wolniej i więcej przesłanych danych po HTTPS.
Dlatego przerażają mnie zmiany planowane zmiany w Chromium powodujące, że strony po odwiedzane po HTTP będą oznaczone jako niezaufane. Podobnie robi Mozilla. Rozumiem, że jeśli wysyłamy dane, zwł. z kamery czy mikrofonu, ba, jeśli cokolwiek wprowadzamy na stronie czy wysyłamy pliki. Ale sam odbiór? Trochę przesada. Tym bardziej, że istnieją narzędzia, do wymuszania HTTPS, jeśli ktoś ma taką potrzebę - choćby HTTPS Everywhere.
Zupełnie nie rozumiem podejścia Google do wykorzystania HTTPS jako sygnału rankingowego. Zdobycie certyfikatu nie jest problemem, a jak ruszy Let's Encrypt, to już w ogóle. Znaczy rozumiem ideę, ale do sprawdzenia autentyczności, wystarczyłoby np. pobierać po HTTPS sitemap.xml. Czy tam robots.txt. Czy stronę główną.
Trochę zastanawiam się, po co ta nagonka. I mam wrażenie, że nie tyle o bezpieczeństwo chodzi (dobry pretekst, fakt), a o pieniądze. O ile certyfikaty tanieją i będą za darmo (ale czy wszystkie?), o tyle pewnie jest to pretekst do kolejnego wzrostu narzutu na ruch, nowych usług (terminowanie SSL na proxy czy CDN), wymiany pudełek itp. Nawiasem, jest nawet strona zachwalająca, jaki to TSL jest szybki, na współczesnych procesorach i nowym oprogramowaniu. Tyle, że nie. Ale nie omieszkam sprawdzić (na najnowszym Debianie), jak tylko Let's Encrypt ruszy...
Zachęcam do polemiki. Polecenia podałem wyżej, można samemu sprawdzić, podać kontrprzykłady, pochwalić się konfiguracją z minimalnym narzutem na wersję szyfrowaną.
UPDATE: Poprawione polecenia (było dwa razy HTTP, zamiast raz HTTP i raz HTTPS). Bug przy przeklejaniu, wyniki są i były prawidłowe. W sumie jestem rozczarowany, że tak długo nikt tego nie zauważył.
Ludzie zajmujący się security śmiechnęli, że śmierdzi fake. Też mi to przeszło przez głowę, ale w dzisiejszych czasach nieustannie trzeba zachowywać czujność. Nieustannie! ;-)
Drogi Użytkowniku,
Otrzymujesz od nas tę wiadomość ponieważ istnieje uzasadniona obawa, że Twój komputer jest zainfekowany przez wirusa/trojana. Przypuszczamy że wirus/trojan przejął kontrolę nad Twoją skrzynką mailową i wysyła SPAM w Twoim imieniu.
W związku z powyższym prosimy o wykonanie wskazanych czynności:
1. Należy niezwłocznie przeskanować komputer programem antywirusowym 2. Następnie dokonać zmiany hasła do konta pocztowego na stronie: https://konto.onet.pl/update-password.html. 3. Po zmianie hasła, należy wylogować się z konta, a następnie zalogować ponownie na stronie https://poczta.onet.pl. 4. Po zalogowaniu prosimy o wysłanie wiadomości mailowej na adres blokadaskrzynki@grupaonet.pl z potwierdzeniem wykonania powyższych kroków.
Do chwili wykonania wszystkich wymienionych czynności mogą występować problemy z wysyłką wiadomości.
Przypominamy, że ze względów bezpieczeństwa Grupa Onet.pl SA nigdy nie prosi o podawanie lub potwierdzanie haseł oraz nie umieszcza w wysyłanych e-mailach odsyłaczy do stron, na których hasło można zmienić.
Hasła nie wolno nikomu ujawniać. Nie należy odpowiadać na e-maile lub telefony z prośbami o podanie hasła. W przypadku otrzymania e-maila zawierającego podobne prośby, prosimy ten fakt zgłosić pod adresem abuse@onet.pl lub dzwonić na numery: 0 801 080 200 lub 012 26 00 200 (poniedziałek-piątek, 7:00-23:00; sobota-niedziela, 10:00-18:00). Polecamy nasze porady na temat bezpieczeństwa: http://pomoc.onet.pl/46,1120,przewodnik.html
Uprzejmie tłumaczę, że Linux, silne hasło, szyfrowane protokoły i raczej false positive, bo dostałem dziwny komunikat przy wysyłce maila do SpamCopa, więc niczego skanować nie będę ot tak, tylko dajcie najpierw logi i przede wszystkim odblokujcie konto.
Otrzymałem dziś odpowiedź:
Witamy,
Dziękujemy za list.
Przekazywane przez Pana wiadomości (raporty) to był spam, dlatego też nasz system antyspamowy zareagował zablokowaniem kanału smtp oraz wysłaniem powiadomienia.
W tym przypadku nie ma konieczności wykonania opisanych w Alercie bezpieczeństwa czynności.
I w zasadzie chyba powinienem im teraz wytłumaczyć, że to nie był spam, tylko legalna wiadomość (nadawca zamawiał!). Że można, ba, powinno się traktować inaczej maile, które całą treść mają w załączniku eml. No i pewnie że przydała by się whitelista na spamcop.net. Ale nie sądzę, by zrozumieli. Gdyby rozumieli, że zjepsuli, to w treści pojawiłoby się przecież słowo przepraszam. Pozostaje odezwać się do SpamCopa nt. obsługi GPG. Może wtedy Onet przestanie zaglądać mi w pocztę i - co gorsza - wyciągać błędne wnioski na tej podstawie.
Krótkie przypomnienie: około pół roku temu pisałem, jak zablokować węzły wyjściowe Tora. Lista węzłów wyjściowych (exit nodes) Tora jest publiczna, więc wygląda, że mamy sielankę.
Tymczasem dziś podczas rozmowy w gronie administratorów padło stwierdzenie od osoby, która badała ruch w sieci Tor, że podczas swoich eksperymentów zarejestrowała ruch z węzłów wyjściowych, których nie było na liście. Metodyka badania prosta jak budowa cepa: wyślij znane żądanie przez Tora do swojego hosta, zapisz IP z którego nadeszło połączenie, porównaj z listą exit nodes.
I wtedy mnie olśniło. Dla pewności zapytałem jeszcze na kanale IRC poświęconym Torowi czy nie ma jakiejś weryfikacji i... jak najbardziej jest to wykonalne. Po prostu jako exit node listowany jest IP, który jest podłączony do sieci Tor. Wystarczy więc, że maszyna ma więcej niż jedno IP lub przekierowuje ruch na inną maszynę (choćby iptables) i... połączenia Tor będą widoczne z nielistowanego adresu. Co więcej, może się on zmieniać w czasie...
Usłyszałem nawet znamienne zdanie na kanale: założę się, że są exit node'y, które po prostu wysyłają ruch przez VPN. I to by było tyle w temacie prostych, błędnych odpowiedzi na pozornie proste pytania...
Przypadkiem wpadłem na pomysł sprawdzenia statystyk dotyczących programu certyfikacji IPv6 prowadzonego przez Hurricane Electric. Okazało się, że od ostatniego sprawdzenia minęły prawie równo trzy lata. Dla przypomnienia, tamtego wpisu:
Szczerze mówiąc, myślałem, że Sage jest więcej, szczególnie, że sporo spotkałem na IRCu. Tymczasem na PLNOG dowiedziałem się, że jest raptem 87 osób w Polsce i ok. 4600 na całym świecie.
A po trzech latach? 10600 sages na świecie, 224 w Polsce. Szału nie ma, delikatnie mówiąc, biorąc pod uwagę okoliczności. Firmy radzą sobie bez IPv6, np. niektórzy ISP w Polsce zaczęli po cichu ładować klientów za NAT. Praktyka, co do której mam mieszane uczucia - z jednej strony typowy klient indywidualny niby nie potrzebuje publicznego IP, z drugiej strony pewne rzeczy działają lepiej z publicznym IP, więc powinien mieć możliwość uzyskania go, jeśli ma takie życzenie.
Oczywiście, pytanie na ile można traktować program certyfikacji HE za miarodajny. Jakiś miernik zainteresowania tematem to jest. Zresztą, postanowiłem sprawdzić "do drugiej strony", czyli ile stron z najpopularniejszych w Polsce wg rankingu Alexa dostępnych jest po IPv6. Popularne w Polsce nie oznacza stron polskich, ale mniejsza z tym. Z pierwszej setki najpopularniejszych adres IPv6 posiada (zakładam, że jak adres jest, to serwis na nim działa) 14 sztuk, konkretnie są to, wg popularności:
Google.pl
Facebook.com
Google.com
Youtube.com
Wikipedia.org
Blogspot.com
O2.pl
Pudelek.pl
Kwejk.pl
Home.pl
Bezuzyteczna.pl
Xhamster.com
Gratka.pl
Naszemiasto.pl
Ale portale takie jak allegro.pl, onet.pl, wp.pl, gazeta.pl czy interia.pl są dostępne tylko po IPv4.
Dawno temu pisałem o walce z Tor. Odsyłałem tam do strony, na której można sprawdzić, czy IP jest węzłem wyjściowym Tora, jest też stronka z listą węzłów. Niestety, stronka popełnia częsty błąd i wrzuca wszystkie węzły do jednego wora, zarówno węzły wyjściowe (exit node) jaki pośredniczące (relay node). Niestety, błąd ten później pokutuje, bo taki admin, który chce wyciąć exit nodes bierze, nie patrzy, nie rozumie i... wycina np. moje domowe IP, choć z Tora się do jego serwera nie łączę, tylko dorzucam parę groszy do projektu przerzucając czyjś ruch.
Ponieważ potrzebowałem (no dobrze, ja jak ja...) listę węzłów wyjściowych na niezupełnie swoje potrzeby, zrobiłem własną listę. Tylko IP i tylko węzły wyjściowe. Idealne do automatycznego przetwarzania.
Dane brane są z z oficjalnej strony projektu Tor ( https://check.torproject.org/exit-addresses). Aktualizacja odbywa się raz na godzinę o pełnej godzinie (nie ma sensu pytać częściej). Jakby było zainteresowanie i potrzeba, to mogę zwiększyć częstotliwość. Mi wystarcza.
Plik dostępny jest po HTTP i HTTPS pod tym adresem: Tor exit node IP list. Udostępniam as is, bez żadnych gwarancji działania, dostępności, kompletności czy poprawności danych czy braku złośliwych danych. Jak widać wisi to na darmowej domenie, co może mieć dotyczące zawartości. You get what you pay for. ;-)
Zresztą ogólnie korzystanie z tego typu automatycznych źródeł bez jakiejś weryfikacji uważam za nierozsądne.
UPDATE: Metoda nie jest doskonała. O tym, że część exit nodes może nie być widocznych przeczytasz tutaj.
Wpis, który przeleżał jako szkic ponad rok. I bardziej go już nie skończę, więc publikuję, jak jest. Miały być testy i dokładne konfiguracje, ale z braku czasu będzie czysta teoria. Tak czy inaczej myślę, że przyda się ludziom z wolnymi łączami lub korzystającym z WWW (i nie tylko...), a chcącym zminimalizować ilość przesłanych danych do urządzenia końcowego. Do rzeczy.
Na podstawie doświadczeń z Aero2, czyli łącza zarówno wolnego (niska przepływność) jak i zlagowanego (duże opóźnienia pakietów), postanowiłem popełnić krótki poradnik, jak przyspieszyć działanie sieci na wolnym łączu internetowym. Zwykle zakładam w tym poradniku, że użytkownik korzysta z Linuksa, ale nie zawsze i część sposobów przyda się niezależnie od systemu.
Krok pierwszy - przyspieszanie zapytań DNS
Ważna sprawa, bo serwery DNS odpytywane są coraz częściej. Otwarcie pojedynczej strony internetowej to w dzisiejszych czasach często kilkanaście, a nawet kilkadziesiąt zapytań do serwerów DNS. W przypadku zlagowanego połączenia do każdego zapytania dochodzi opóźnienie łącza. Można sobie pomóc poprzez wykorzystanie lokalnego cache DNS. Z prostych w konfiguracji polecam opisany kiedyś dnsmasq lub lekki i wydajny unbound. Cache DNS działa dla całego systemu, nie tylko dla stron WWW, ale w ich przypadku różnica powinna być najbardziej widoczna. Dodatkowa zaleta to uniezależnienie się od potencjalnych problemów z serwerami DNS naszego dostawcy łącza.
Krok drugi - kompresja danych
Mechanizm kompresji danych na wolnym odcinku nie jest niczym nowym. Od dawna z powodzeniem stosuje go Opera w swojej funkcji turbo. Pierwsza obróbka strony odbywa się na ich serwerach, które dysponują szybkimi łączami. Dodatkowo może się odbywać redukcja zbędnych elementów. Zaletą rozwiązania jest łatwość uruchomienia - wystarczy kliknąć przycisk w Operze. Wadą rozwiązania jest to, że wymaga korzystania z Opery i działa tylko dla stron WWW.
Kompresja danych - DIY
ziproxy
Jeśli mamy dostęp do serwera (może być VPS) z Linuksem, możemy w prosty sposób stworzyć podobne rozwiązanie samodzielnie, korzystają z programu ziproxy. Instalujemy je na serwerze, konfigurujemy, jak bardzo mają być redukowane grafiki (60-70% wygląda znośnie), ustawiamy adres IP i port serwera jako proxy w przeglądarce i.. tyle. Od tej pory przez wolne łącze przesyłane są zredukowane (stratnie, zatem gorzej wyglądające) obrazy. Reszta danych jest przesyłana w postaci skompresowanej.
Zaleta jest taka, że działa z każdą przeglądarką i - dla paranoików - że nasze dane nie błądzą po serwerach Opery.
Wady: działa tylko dla WWW, stopień redukcji obrazów ustala się raz, nie ma możliwości dynamicznej zmiany jakości (np. obejrzenie wybranych obrazów w lepszej jakości).
sshuttle
Jeśli mamy dostęp do serwera z Linuksem i dodatkowo ma on zainstalowanego Pythona, to możemy skorzystać z VPN over SSH, czyli shuttle. Rozwiązanie powstało jako namiastka VPN i miało pierwotnie bardziej zapewniać bezpieczeństwo transmisji (szyfrowanie) w przypadku otwartych hotspotów. Można je jednak skonfigurować tak, aby ruch był kompresowany (wykorzystanie kompresji SSH).
Zaletą jest to, że działa dla całego ruchu (TCP), nie tylko dla WWW. Można określić, do których sieci ruch ma być obsługiwany przez to rozwiązanie.
Wada: działa tylko dla TCP (oraz zapytań DNS), wymaga zainstalowanego Pythona na maszynie pełniącej rolę serwera.
ssh + socks proxy
Jeśli nie chcemy instalować dodatkowego oprogramowania, a mamy dostęp do serwera z Linuksem, możemy w prosty sposób wykorzystać tunelowanie SSH oraz - podobnie jak w poprzednim przypadku - wykorzystać kompresję oferowaną przez SSH. W tym celu ustawiamy socks proxy w przeglądarce na localhost oraz port 9000, oraz uruchamiamy ssh -CND 9000 user@serwer. Od tej pory ruch WWW tunelowany jest przez SSH do serwera. Jeśli zależy nam nie tylko na wydajności, ale i na prywatności, warto sprawdzić ustawienia przeglądarki dotyczące przesyłania zapytań DNS przez proxy.
Zaleta: łatwość uruchomienia (na systemach *nix).
Wady: działa tylko dla ruchu WWW (lub jawnie przetunelowanego z innych aplikacji), wymaga przeglądarki WWW ze wsparciem dla socks proxy (praktycznie każda sensowna ma tę opcję dostępną w ten lub inny sposób).
OpenVPN
Ostatni sposób to wykorzystanie OpenVPN oraz wbudowanej kompresji. Wymaga skonfigurowanego OpenVPN zarówno po stronie klienta jak i serwera.
Zalety: działa dla wszystkich rodzajów ruchu.
Wady: wymaga zainstalowania i skonfigurowania OpenVPN. Dochodzi narzut CPU na szyfrowanie (domyślnie będzie włączone, zwł. u zewnętrznych providerów).
Oczywiście cudów nie ma i ww. sposoby pomogą jedynie dla treści, które przesyłane są jako nieskompresowane i dobrze się kompresują. Nie ma co liczyć, że filmy na YouTube zaczną działać szybciej. Osobiście idę na łatwiznę i korzystam zwykle z ssh i socks proxy.
Dziś wróciłem z trzynastej edycji PLNOG. Znacznie lepsze wrażenia, niż po edycji 11. Krótko i subiektywnie o wykładach, na których byłem.
Peering vs Tranzyt prowadzony przez Grzegorza Janoszkę z Booking.com. Zaskoczenia nie było; w skrócie: peering oznacza mniejsze opóźnienia, szybsze transfery i mniejsze odchylenia czasu transferu. Czyli - patrząc z punktu widzenia lepiej róbmy sieć/usługę - warto. Niestety, podobno nie przełożyło się to w żaden sposób na wyniki sprzedaży. Duży szacunek za kulturę pomiarów i weryfikację tez w praktyce, mimo trudnych warunków pomiaru (każdy okres jest inny, wzrost ruchu w czasie, zmienne środowisko).
James Kretchmar z Akamai mówił o obsłudze największych wydarzeń w Internecie. Czyli np. transmisje video z MŚ w piłce nożnej. Bez wielkich zaskoczeń, z grubsza tak to sobie wyobrażałem. Ciekawe wyzwania i mechanizmy przy tego typu skali. Największe wrażenie zrobiła właśnie skala i poziom poukładania.
O systemie ochrony przed atakami DDOS Wanguard mówił Piotr Okupski. Wykład ciekawy, praktyczny, przekonujący. Sporo namiarów i ciekawostek nt. wpływu optymalizacji systemu Linux i wyboru kart sieciowych na wydajność. Ogólnie sporo o wydajności, zwł. w kontekście przetwarzania informacji o ruchu sieciowym w większej skali live. Zdecydowanie będę musiał zgłębić temat. W tej chwili mam to rozwiązane nieco inaczej (i też działa i wystarcza), ale warto znać alternatywy.
Czy bezpłatne WiFi może być opłacalne? Chyba najbardziej marketingowy wykład, na jaki trafiłem. Paradoksalnie, cieszę się, że byłem, choć ze względu na ochronę prywatności. Z punktu widzenia użytkownika końcowego: nie ma darmowych obiadów. Zalogujesz się do darmowego WiFi przy pomocy konta FB/maila/numeru telefonów, to spodziewaj się reklam na wallu, spamu, SMSów. Darmowe WiFi w galerii[1]? Pomiar, gdzie chodzisz (dokładność do kilku m), ukierunkowane reklamy przy przejściu obok danego sklepu, na wallu itd. I wszechobecne parcie w kierunku big data. Trochę ciary, mocne skojarzenia z Rok 1984 i Wielkim Bratem.
O narzędziach open source w służbie ISP mówili ludzie z FiberRing. Wyniosłem głównie da się połączone z pewne rzeczy warto rozwijać samemu (bo nie ma alternatyw ;-)) i parę nazw narzędzi, którym chcę się bardziej przyjrzeć.
Mechanizmy ochrony anty-DDoS w Telekomunikacji Polskiej/Orange - taki był tytuł wykładu Andrzeja Karpińskiego. Fajny, poukładany, przemyślany wykład w formie, która bardzo mi się podobała, bo łączyła teorię z praktyką. Czyli z jednej strony co należy robić, a z drugiej jak my to robimy. Myślę, że dobry instruktaż, albo przynajmniej przypomnienie. Mam dość niewesołe przemyślenia w temacie security, niestety. Mianowicie: dużym jest łatwiej, a bezpieczeństwo coraz mniej jest sprawą community sieciowego, a coraz bardziej produktem. Dużą zmianę jakościową mogłaby przynieść dopiero zmiana mentalności end userów, ale na to się nie zanosi. Nawiasem, nie zdziwiłbym się, gdyby wykład okazał się też owocny handlowo (bo o produktach TP/Orange w tym zakresie też było).
Pierwszy dzień konferencji zakończyłem spotkaniem SP Security Community Working Group. Ustalenia są w skrócie takie, że nadal to będzie działać, ma być bardziej otwarte na nowych ludzi i bardziej lokalne. I chyba dobrze, bo IMO do tej pory formuła nie do końca się sprawdzała.
Dzień drugi zaczął Artur Pająk z Huawei wykładem o iSCSI i FCoE. Dobry przegląd technologii. FCoE wygląda jakby lepie w dłuższej perspektywie, ale obecnie barierą może być brak "wspólnego języka" między vendorami.
Mateusz Viste z Border 6 mówił o optymalizacji BGP w czasie rzeczywistym. Dobrze poprowadzony wykład typu co i jak można zrobić. Jeśli się trochę pomyśli i porzeźbi, oczywiście. I napisze trochę swojego kodu[2]. A firma dla tych, którym się nie chce/nie potrafią daje gotowca. Wyniki ciekawe, pewnie parę lat temu byłbym poważnie zainteresowany produktem. Teraz trochę się zmieniła pozycja - ceny hurtowego dostępu do internetu spadły, pojawiły się punkty wymiany ruchu, które też znacznie pomagają (patrz wykład z pierwszego akapitu), a dodatkowo capacity daje pewną odporność na DDoSy (przynajmniej teoretycznie). Może po prostu nie jestem odbiorcą docelowym w tym momencie, tzn. nie mam takich potrzeb.
Ostatni wykład na którym byłem prowadził Adam Obszyński z Infoblox. Zupełnie niemarketingowy wykład o DNSSEC, czy warto, czemu warto, czemu nie warto i co to daje. Ogólnie IMO trochę poprawia bezpieczeństwo, zwł. w przypadku przejęcia ruchu (MITM), ale problemu nie rozwiązuje, w szczególności nie rozwiązuje go dla użytkownika końcowego. Bo ten nadal jest narażony na podmianę adresów serwerów DNS na swoim komputerze/routerze (i wtedy DNSSEC nic nie daje), ruch do DNS nadal jest widoczny (DNSSEC to podpisywanie, nie szyfrowanie) i ogólnie nadal musi ufać swojemu ISP[3]. Widać, że nie do końca się standard przyjął (w Polsce jest naprawdę słabo), wiele ostatnich artykułów jest z okolic 2010-2012, ale przyznam, że ja zostałem przekonany do włączenia (w tym: dla moich użytkowników, aktualnie testuję na sobie). Będzie odrobinę bezpieczniej, a włączenie jest trywialne.
Bo że z bezpieczeństwem DNS nie jest za dobrze, to wiadomo - niedawno dość modny (z braku lepszego określenia zostawię to słowo) stał się DNSCrypt, który robi zupełnie co innego, ale... ma inne wady, a jego uruchomienie to na ten moment porażająca rzeźba, niestety.
W każdym razie zupełnie prywatnie wykład inspirujący i planuję wkrótce wpis(y?) o DNSSEC.
[1] Obawiam się, że do samego pomiaru położenia wystarczy włączone WiFi w telefonie, nie trzeba podłączać się do sieci... A potem, kiedyś, jak już się podłączy na podstawie MAC karty sparuje się urządzenie z użytkownikiem i dołoży parę puzzli do układanki.
[2] Tak, kolejny wykład o tym, że DIY w sieciach ma rację bytu.
[3] I swojemu ISP od DNS też, jeśli przypadkiem nie jest to ten sam byt.
