Hosting – jak wyłączyć modsecurity

Większość hostingów posiada aktywne zabezpieczenia anty spamowe które mają chronić klientów przed różnymi zagrożeniami niestety mają też one jedną wadę – znacznie opóźniają  ładowanie stron internetowych. Aby pozbyć się problemu należy do pliku .htaccess w public_html dodać następującą linijkę:

#Disable modSecurity
SecRuleEngine Off

Zapisujemy i odświeżamy stronę. Problemy z modsecurity powinny zniknąć.

Jak skonfigurować wirtualne hosty Apache w systemie Ubuntu 16.04

Serwer WWW Apache jest najpopularniejszym sposobem udostępniania treści internetowych w Internecie. Stanowi on ponad połowę wszystkich aktywnych stron internetowych i jest niezwykle wydajny i elastyczny.

Apache dzieli swoją funkcjonalność i komponenty na poszczególne jednostki, które można indywidualnie dostosować i skonfigurować. Podstawowa jednostka, która opisuje pojedynczą witrynę lub domenę, nazywa się virtual host.

Te oznaczenia umożliwiają administratorowi korzystanie z jednego serwera do obsługi wielu domen na jednym adresie IP przy użyciu mechanizmu dopasowującego. Jest to istotne dla każdego, kto chce zamieścić więcej niż jedną witrynę na jednym VPS.

Każda skonfigurowana domena kieruje użytkownika do określonego katalogu zawierającego informacje tej witryny, nie wskazując, że ten sam serwer jest odpowiedzialny również za inne witryny. Ten schemat można rozszerzyć bez żadnego limitu oprogramowania, o ile twój serwer może obsłużyć obciążenie.

W tym przewodniku pokażemy, jak skonfigurować wirtualne hosty Apache na systemie Ubuntu 16.04 VPS. Podczas tego procesu dowiesz się, jak wyświetlać różne treści różnym użytkownikom w zależności od żądanych domen.

Wymagania wstępne
Przed rozpoczęciem tego samouczka powinieneś utworzyć użytkownika innego niż root, jak opisano w krokach 1-4 tutaj.

Konieczne będzie również zainstalowanie Apache w celu wykonania tych kroków. Jeśli jeszcze tego nie zrobiłeś, możesz zainstalować Apache na swoim serwerze poprzez apt-get:

sudo apt-get update
sudo apt-get install apache2

Po wykonaniu tych kroków możemy rozpocząć.

Na potrzeby tego przewodnika nasza konfiguracja będzie wirtualnym hostem dla moja.domena.pl dla innego test.com. Zostaną one przywołane w całym przewodniku, ale powinieneś je zastąpić własnymi domenami.

Krok pierwszy – Utwórz strukturę katalogów

Pierwszym krokiem, jaki podejmiemy, jest utworzenie struktury katalogów, która będzie przechowywać dane o witrynie.

Nasz katalog najwyższego poziomu, w którym Apache szuka, aby znaleźć treść do wyświetlenia zostanie ustawiony na poszczególne katalogi w /var/www. Stworzymy tutaj katalogi dla obu wirtualnych hostów, które planujemy.

W każdym z tych katalogów utworzymy folder public_html, w którym przechowywane będą nasze pliki stron.

Dla naszych witryn zamierzamy utworzyć katalogi w następujący sposób:

sudo mkdir -p /var/www/moja.domena.pl/public_html
sudo mkdir -p /var/www/test.com/public_html

 

Krok drugi – Przyznaj uprawnienia

Teraz mamy strukturę katalogów dla naszych plików, ale są one własnością naszego użytkownika root. Jeśli chcemy, aby zwykły użytkownik mógł modyfikować pliki w naszych katalogach internetowych, musimy zmienić uprawnienia:

sudo chown -R $USER:$USER /var/www/moja.domena.pl/public_html
sudo chown -R $USER:$USER /var/www/test.com/public_html

$USER – to zmienna określająca naszego użytkownika musisz wpisać własną.

Powinniśmy również nieco zmodyfikować nasze uprawnienia, aby zapewnić, że dostęp do odczytu jest dozwolony w ogólnym katalogu internetowym oraz wszystkich zawartych w nim plikach i folderach, aby strony mogły być wyświetlane poprawnie:

sudo chmod -R 755 /var/www

Twój serwer internetowy powinien mieć teraz uprawnienia potrzebne do wyświetlania treści, a Twój użytkownik powinien mieć możliwość tworzenia treści w odpowiednich folderach.

Krok trzeci – Utwórz lub przenieś strony  dla każdego wirtualnego hosta

Posiadamy strukturę katalogów. Możemy już przenieść pliki naszej strony przez ftp.

 

Krok czwarty – Utwórz pliki wirtualnego hosta

Pliki wirtualnego hosta to pliki, które określają faktyczną konfigurację naszych hostów wirtualnych i określają, w jaki sposób serwer WWW Apache będzie odpowiadał na różne żądania domeny.

Apache ma domyślny plik wirtualnego hosta,( 000-default.conf ) który możemy wykorzystać jako punkt wyjścia. Należy skopiować go, aby utworzyć wirtualny plik hosta dla każdej z naszych domen.

Utwórz pierwszy plik wirtualnego hosta
Rozpocznij od skopiowania pliku dla pierwszej domeny:

sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/moja.domena.pl.conf

Otwórz nowy plik w edytorze z uprawnieniami roota:

sudo nano /etc/apache2/sites-available/example.com.conf

Plik będzie wyglądać mniej więcej tak (usunąłem tu komentarze, aby plik był bardziej dostępny):

/etc/apache2/sites-available/example.com.conf

<VirtualHost *:80>
 ServerAdmin webmaster@localhost
 DocumentRoot /var/www/html
 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Jak widać, nie ma tu zbyt wiele. Spersonalizujemy tutaj elementy dla naszej pierwszej domeny i dodamy kilka dodatkowych dyrektyw. Ta sekcja wirtualnego hosta pasuje do wszystkich żądań, które są wykonywane na porcie 80, domyślnym porcie HTTP.

W sumie nasz plik virtualhost powinien wyglądać tak:

/etc/apache2/sites-available/moja.domena.pl.conf
<VirtualHost *:80>
 ServerAdmin admin@moja.domena.pl
 ServerName moja.domena.pl
 ServerAlias www.moja.domena.pl
 DocumentRoot /var/www/moja.domena.pl/public_html
 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Zapisz i zamknij plik.

 

Krok piąty – Włącz nowe pliki hosta wirtualnego

Po utworzeniu plików hostów wirtualnych musimy je włączyć. Apache zawiera kilka narzędzi, które pozwalają nam to zrobić.

Możemy użyć  a2ensite, aby włączyć każdą z naszych stron w następujący sposób:

sudo a2ensite moja.domena.pl.conf

Następnie wyłącz domyślną witrynę zdefiniowaną w 000-default.conf:

sudo a2dissite 000-default.conf

Kiedy skończysz, musisz ponownie uruchomić Apache, aby wprowadzić te zmiany:

sudo systemctl restart apache2

lub tym poleceniem:

sudo service apache2 restart

To wszystko, sprawdź czy twoja witryna wyświetla się teraz prawidłowo.

 

 

Instalacja certyfikatu SSL Let’s Encrypt na VPS

Ten samouczek pokazuje, jak skonfigurować certyfikat TLS / SSL z Let’s Encrypt na serwerze Ubuntu 16.04 z uruchomionym Apache jako serwerem WWW.

Certyfikaty SSL są używane na serwerach sieciowych do szyfrowania ruchu między serwerem a klientem, zapewniając dodatkowe bezpieczeństwo użytkownikom uzyskującym dostęp do aplikacji. Let’s Encrypt zapewnia łatwy sposób na uzyskanie i zainstalowanie zaufanych certyfikatów za darmo.

Wymagania wstępne
Aby ukończyć ten przewodnik, będziesz potrzebować:

Serwer Ubuntu 16.04.
Serwer sieciowy Apache2 zainstalowany z jedną lub więcej domenami poprawnie skonfigurowanymi za pomocą wirtualnych hostów, które określają ServerName.

Krok 1 – Zainstaluj klienta Let’s Encrypt

Najpierw dodaj repozytorium Cerbot:

sudo add-apt-repository ppa:certbot/certbot

Musisz nacisnąć, ENTER aby zaakceptować. Następnie zaktualizuj listę pakietów, aby pobrać informacje o nowym repozytorium:

sudo apt-get update

I wreszcie zainstaluj Certbot z nowego repozytorium za pomocą apt-get:

sudo apt-get install python-certbot-apache

Certbot jest teraz gotowy do użycia.

Krok 2 – Skonfiguruj certyfikat SSL
Generowanie certyfikatu SSL dla Apache za pomocą Certbota jest dość proste. Klient automatycznie uzyska i zainstaluje nowy certyfikat SSL, który jest ważny dla domen dostarczonych jako parametry.

Aby uruchomić instalację i uzyskać certyfikat obejmujący tylko jedną domenę, uruchom certbot poleceniem:

sudo certbot --apache -d moja.domena.pl

Jeśli chcesz zainstalować pojedynczy certyfikat, który jest ważny dla wielu domen lub subdomen, możesz wpisać je jako dodatkowe parametry do polecenia. Pierwsza nazwa domeny na liście parametrów będzie domeną podstawową używaną przez Let’s Encrypt do utworzenia certyfikatu i z tego powodu zalecamy podanie nazwy domeny najwyższego poziomu jako pierwszej na liście, a następnie dowolnej dodatkowej subdomeny. lub aliasy:

sudo certbot –apache -d moja.domena.pl -d www.moja.domena.pl

W tym przykładzie będzie to domena podstawowa moja.domena.pl .

Jeśli masz wiele hostów wirtualnych, uruchom certbot dla każdego, aby wygenerować nowy certyfikat dla każdego z nich. Możesz dystrybuować wiele domen i subdomen na swoich wirtualnych hostach.

Po zainstalowaniu zależności zostanie wyświetlony przewodnik krok po kroku, w celu dostosowania opcji certyfikatu. Zostaniesz poproszony o podanie adresu e-mail, aby odzyskać utracone klucze i powiadomienia, a będziesz mógł wybrać między włączeniem http i https uzyskaniem dostępu lub wymuszeniem wszystkich żądań przekierowania https.

Po zakończeniu instalacji powinno być możliwe znalezienie wygenerowanych plików certyfikatów na

/etc/letsencrypt/live.

Możesz zweryfikować status swojego certyfikatu SSL za pomocą poniższego linku (nie zapomnij zamienić  moja.domena.pl na swoją domenę podstawową ):

https://www.ssllabs.com/ssltest/analyze.html?d=moja.domena.pl&latest

Powinieneś teraz mieć dostęp do swojej strony internetowej za pomocą https.

Krok 3 – Weryfikacja automatycznego odnawiania certyfikatów

Certyfikaty Let’s Encrypt mają ważność tylko 90 dni. Jednak zainstalowany przez nas pakiet certbot-a zajmuje się tym dla nas, uruchamiając certbot renew dwa razy dziennie przez systemowy timer. W dystrybucjach niesystemowych tę funkcjonalność zapewnia skrypt cron umieszczony w /etc/cron.d. Zadanie jest uruchamiane dwa razy dziennie i odnawia certyfikat, który kończy w ciągu trzydziestu dni.

Aby przetestować proces odnawiania, możesz wydać komendę certbot:

sudo certbot renew --dry-run

Jeśli nie widzisz żadnych błędów, wszystko jest gotowe. W razie potrzeby Certbot odnowi certyfikaty i przeładuje serwer Apache, aby pobrać zmiany. Jeśli proces automatycznego odnawiania się nie powiedzie, Let’s Encrypt wyśle ​​wiadomość na podany adres e-mail, ostrzegając Cię, gdy Twój certyfikat wkrótce wygaśnie.

Luka w procesorach Intela spowoduje obniżenie wydajności o 30%

Intel czeka w najbliższym czasie bardzo trudny okres, ponieważ jak wynika z pojawiających się w sieci doniesień, jego procesory zawierają poważną lukę bezpieczeństwa, której nie można załatać przez aktualizację mikrokodu i wymaga to wprowadzenia poprawki w OS. Co więcej, tyczyć ma się to wszystkich CPU Niebieskich przynajmniej z ostatniej dekady.

Stosowny patch został już wydany dla Linuxa i lada moment Microsoft powinien dostarczyć go także na urządzenia z Windowsem. Jak na razie ze względów bezpieczeństwa nie są oficjalnie podawane szczegóły exploita, ani zagrożenie jakie ze sobą niesie. Z przecieków wynika jednak, że sprawa jest bardzo poważana, ponieważ mówiąc najprościej luka pozwalać ma standardowym programom na “nielegalny” dostęp do pewnej zawartości chronionej w pamięci jądra systemu operacyjnego (Kernel). Naprawienie tego wymaga implementacji Kernel Page Table Isolation (KPTI), które ukrywa Kernel dla działających procesów, ale niesie ze sobą poważne konsekwencje dla wydajności procesorów. Wiąże się to z dodatkowym obciążeniem procesora związanym z utrzymaniem bariery pomiędzy przestrzeniami adresowymi pamięci i podobno spodziewać mamy się tu obniżenia osiągów o 5% do nawet 30% (w mniejszym stopniu podatne mają być nowsze CPU procesory Intela z włączonym Process-Context Identifiers). Spadek wydajności w dużej mierze zależny będzie od modelu procesora i zastosowania – nie wiemy, czy wpłynie to na wydajność w grach.

intel-cpu-kernel-memory-bug

Luka jest szczególnie groźna w przypadku korzystania z wirtualnych środowisk, ponieważ pozwalać ma użytkownikom wirtualnej maszyny  (VM) na dostęp do danych innego VM na tym samym fizycznym sprzęcie. Celem ataków wykorzystujących tę podatność mają być takie środowiska, jak Amazon EC2 czy Google Compute Engine, a nie bez powodu wiele osób łączy z tą sprawą zaplanowane na przyszły tydzień konserwacje Microsoft Azure i Amazon Web Services Basically.

Co warto podkreślić, procesory AMD nie są podatne na to zagrożenie, ale co ciekawe, wypuszczona dla Linuxa łatka wpływa na wszystkie procesory x86, dlatego też, by uniknąć spadków wydajności, Czerwoni zalecają jej nie instalować. W przypadku aktualizacji dla Windowsa szykowanej przez Microsoft, poprawki powinny objąć już tylko procesory Niebieskich.

Portal Phoronix opublikował już nawet wstępne testy po zainstalowaniu aktualizacji na systemie Linux i wydajność w tym wypadku zaliczyła spadek rzędu 17-18%. Jak sytuacja będzie wyglądać na Windowsie? Tego jeszcze nie wiemy, ale zapewne najbliższe dni przyniosą odpowiedź na to pytanie.

phronix-compile-bench-test

źródło: frazpc.pl

Ekran śmierci po łatce Microsoftu – winne programy antywirusowe

Wydana w tym tygodniu przez Microsoft łatka KB4056892 uodparnia Windowsa na atak Meltdown – odczytanie chronionej pamięci kernela przez zwykłą aplikację. Uodpornienie wiąże się jednak z ogromnymi zmianami w architekturze pamięci, nie dziwcie się więc, jeśli po jej zainstalowaniu zobaczyliście niebieski ekran śmierci. Winę w tym wypadku może ponosić program antywirusowy.

Najnowsza łatka wprowadza do Windows 10 wersji 1709 po zastosowaniu łatki rozwiązanie analogiczne do tego, co znamy z Linuksa (KPTI), całkowicie oddzielając od siebie pamięć kernela i pamięć przestrzeni użytkownika. Nosi to nazwę ASLR/VA Isolation, i podobnie jak KPTI dokładnie czyści też bufor TLB (translation lookaside buffer), czyli pamięć podręczną mikroprocesora, w której przechowywane są fragmenty tablicy stron pamięci operacyjnej komputera. Jak to wygląda w praktyce przedstawił ostatnio badacz Alex Ionescu w swoim tweecie:

 

View image on TwitterView image on Twitter

Wszyscy ci, którzy pospieszyli się z instalowaniem jak najszybciej tej łatki, wydanej dotąd tylko na najnowsze Windows 10 i Windows Servera, mogą mieć problemy, związane z nieprzeczytaniem wcześniej ostrzeżeń dla wszystkich tych, którzy korzystają z antywirusa innego niż Windows Defender.

Problem wynika z tego, że nagle wiele zachowań antywirusów stało się „nielegalnych” – wywołań bezpośrednio do pamięci kernela Windowsa. Takie zaś wywołania kończą się zwykle niebieskim ekranem śmierci i niemożliwością uruchomienia systemu. Aby uniknąć tej sytuacji, łatka z ASLR/VA Isolation powinna zostać pobrana i zainstalowana tylko na tych komputerach, na których antywirusy zostały wcześniej zaktualizowane i umieściły specjalny wpis w rejestrze. Najwyraźniej nie w każdym wypadku to zadziałało, albo użytkownicy na własną rękę wymusili instalację łatki – a później patrzyli na piękny niebieski ekran.

Jak do tej pory (5 stycznia 2018 roku) takie zmiany wprowadziła już większość popularnych producentów antywirusów – szczegóły znajdziecie w poniższej tabelce.

Producent Klucz w rejestrze Wsparcie dla ASLR/VA Więcej informacji
AVAST T T Forum Avasta
Avira T T Forum Wildersecurity
BitDefender N N Wsparcie BitDefender
ESET T T
F-Secure T T Społeczność F-Secure
G-DATA N N
Kaspersky T T Wsparcie Kaspersky Lab
Malwarebytes T T Blog Malwarebytes
McAfee N T Baza wiedzy McAfee
Microsoft T T
Norton T T
Sophos N T Społeczność Sophos
Symantec T T Twitter
Trend Micro N T Wsparcie Trend Micro

Jeśli antywirus nie jest wspierany, lepiej nie ryzykować. Tam jednak, gdzie klucz rejestru nie został jeszcze ustawiony, a producent dał znać, że dostosował swój produkt do zmian w architekturze pamięci Windowsa, można spróbować wymusić instalację KB4056892 ręcznie.

W ten celu należy do Rejestru dodać odpowiedni klucz. Jego lokalizacja toHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat, nazwa to cadca5fe-87d3-4b96-b7fb-a231484277cc, typ REG_DWORD a wartość to 0x00000000.

 

źdródło: dobre programy.pl

Włącz ochronę przed ransomware w Windows 10

Wśród rozlicznych funkcji wprowadzonych przez Microsoft do Windowsa 10 w aktualizacji Fall Creators Update jedna jest szczególnie na czasie. Dręczeni plagą ransomware użytkownicy mogą teraz zabezpieczyć teraz swoje dane tak, że nawet po zainfekowaniu komputera przez nawet najbardziej zaawansowane dziś szkodniki, pozostaną one nietknięte. Zapraszamy do zapoznania się z wykorzystaniem funkcji Kontrolowany dostęp do folderu, będącej częścią ulepszeń wprowadzonych w narzędziu antywirusowym Windows Defender.

Tak jak sama nazwa wskazuje, Kontrolowany dostęp do folderu pozwala użytkownikom określić, kto i na jakich warunkach będzie mógł uzyskać dostęp do danych przechowywanych we wskazanych folderach. Domyślna konfiguracja jest nastawiona na maksymalne bezpieczeństwo, tj. blokuje wszelkie próby dostępu innych procesów. Dzięki temu w teorii powinno to ocalić pliki przed zaszyfrowaniem przez szkodnika – o ile oczywiście w końcu nie zostaną znalezione sposoby obejścia tego zabezpiecznie.

Jak włączyć Kontrolowany dostęp do folderu?

W systemowych Ustawieniach należy przejść do Aktualizacje i zabezpieczenia, a tam z listy paska bocznego wybrać Windows Defender i w jego panelu kliknąć przycisk Otwórz usługę Windows Defender Security Center.

Otwarty panel zarządzania Windows Defendera na drugiej pozycji listy menu bocznego zawiera pozycję Ochrona przed wirusami i zagrożeniami. Należy ją wybrać, a następnie w głównym widoku programu kliknąć Ustawienia ochrony przed wirusami i zagrożeniami.

Kolejny widok należy przewinąć myszką w dół, aż dotrzemy do opcji Kontrolowany dostęp do folderu. Włączamy ją normalnym przełącznikiem – Windows zapyta wówczas o zgodę na wprowadzenie zmian przez Windows Defender Security Center. Oczywiście należy się zgodzić.

Teraz należy wskazać foldery, które będą tą funkcją chronione. Klikamy link Chronione foldery – jak widać, domyślnie są już chronione wszystkie foldery systemowe. By dodać własne foldery, należy kliknąć przycisk Dodaj chroniony folder.

Teraz należy wskazać aplikacje, która będą miały prawo dostępu do chronionego folderu. W tym celu cofamy się do poprzedniego widoku i wybieramy link Zezwalaj aplikacji na dostęp przez funkcję Kontrolowany dostęp do folderu, a na następnym ekranie klikamy Dodaj dozwoloną aplikację. Niestety Microsoft nie zrobił tego dobrze, zamiast wyświetlić okno dialogowe z listą zainstalowanych aplikacji, wyświetla zwykły selektor plików, za którego pomocą należy odnaleźć i wskazać aplikację w systemie plików. Przykładowo wybraliśmy Notatnik (C:\Windows\notepad.exe).

Macie dość klikania? Na szczęście Kontrolowany dostęp do folderu można szybko włączyć z konsoli Powershella, wydając polecenie

Set-MpPreference -EnableControlledFolderAccess Enabled

Wyłączenie odbywa się analogicznie, poleceniem
Set-MpPreference
-EnableControlledFolderAccess Disabled

Co się stanie, jeśli jakiś nieupoważniony program spróbuje uzyskać dostęp do chronionego folderu? Nic takiego – po prostu go nie dostanie i nie wprowadzi zmian. Sprawdziliśmy (oczywiście w maszynie wirtualnej z odłączonym dostępem do sieci) działanie popularnego CryptoWalla: zainstalowany i uruchomiony zaszyfrował wszystko poza chronionymi folderami.

Potwierdza to spostrzeżenia niezależnych badaczy: choć interfejs użytkownika jest taki sobie, a system nie wyświetla powiadomień o nieupoważnionym dostępie do plików (można skorzystać z funkcji logowania Windows Defendera, dostępnej po aktywacji trybu audytu za pomocą rozszerzenia Windows Defender Exploit Guard), to jednak Kontrolowany dostęp robi to, co powinien robić – skutecznie chroni przed atakami ransomware, nawet jeśli sam Windows Defender przed nimi nie obroni.

 

źródło:dobreprogramy.pl

Aplikacje na androida wykradają dane logowania do polskich banków

Eksperci z ESET informują, że w sklepie Google Play, mimo wieloetapowej weryfikacji, znów pojawiło się niebezpieczne oprogramowanie. Wykorzystując fałszywe powiadomienia i strony podszywające się pod serwisy bankowe, aplikacje StorySaver i Crypto Monitor mogą wykradać dane do 14 aplikacji dużych polskich banków.

W teorii obie aplikacje mają dostarczać całkiem przydatne możliwości – StorySaver (opublikowany przez kirilsamsonov45) ma służyć pobieraniu na pamięć urządzenia filmów i zdjęć Story z serwisu Instagram, które z założenia mają być dostępne tylko tymczasowo. CryptoMonitor (aurostwa wallteststudio) to zaś z pozoru aplikacja umożliwiająca śledzenie kursów kryptowalut. W rzeczywistości oba wykorzystują ten sam mechanizm kradzieży danych, wycelowany w polskich użytkowników bankowości mobilnej.

W pierwszej kolejności aplikacje skanują pamięć smartfonu w poszukiwaniu dowolnej z czternastu aplikacji bankowych: Alior Mobile, BZWBK24 mobile, Getin Mobile, IKO, Moje ING mobile, Bank Millennium, mBank PL, BusinessPro, Nest Bank, Bank Pekao, PekaoBiznes24, plusbank24, Mobile Bank oraz Citi Handlowy. Następnie, jeśli użytkownik posiada na swoim smartfonie dowolną z aplikacji, StorySaver i CryptoMonitor wysyłają powiadomienie naśladujące komunikat z konkretnego banku, jakiego klientem jest ofiara.

Dalej procedura jest już oczywista – po przejściu na stronę z powiadomienia, użytkownik proszony jest o logowanie na fałszywej stronie, co służy przechwyceniu danych logowania. Ponadto aplikacje proszą także o dostęp do skrzynki SMS-owej, co może służyć przechwyceniu kodów autoryzujących transakcje. ESET rozpoznał zagrożenie jako Android/Spy.Banker.QL, zgłosił zagrożenie Google, co poskutkowało usunięciem programów z Google Play.

Do tego czasu pobrano ją jednak tysiące razy, zaś lwia część użytkowników (96%) pochodzi z Polski. Użytkownikom złośliwych aplikacji zalecamy ich natychmiastowe odinstalowanie, zmianę danych logowania w serwisach bankowych oraz prześledzenie historii transakcji w poszukiwaniu kradzieży środków.

 

źródło:dobreprogramy.pl

Windows 10 Anniversary Update instaluje oprogramowanie bez zgody użytkownika

Wraz z Windows 10 Anniversary Update (wersja 1607) Microsoft wprowadził nową funkcjonalność do Content Delivery Manager, komponentu wcześniej wykorzystywanego głównie do sugerowania użytkownikom aplikacji w menu Start czy wyświetlaniu im ładnych obrazków na ekranie logowania. Pozwala ona na zdalne instalowanie użytkownikom przeróżnego oprogramowania – i to bez żadnej interakcji z jej strony. Niepokojące? Czytajcie dalej. Pół roku temu w ten sposób Microsoft zainstalował menedżera haseł Keeper, firmy Keeper Security Inc. Teraz Tavis Ormandy, słynny ekspert Google’a od bezpieczeństwa oprogramowania, zademonstrował, jak dowolna strona internetowa może z Keepera wykraść wszystkie hasła użytkownika.

W założeniu Content Delivery Manager miał preinstalować aplikacje w systemie Windows 10, bazując na znanych Microsoftowi upodobaniach użytkownika. W ten sposób można było dostać np. Adobe Photoshopa Express, Netflixa czy nawet Farmville. Wybór zależał najpewniej od porozumień partnerskich, jakie Microsoft zawarł z producentami oprogramowania. Mechanizm dystrybucji wydawał się niezawodny – zwykły użytkownik praktycznie nie miał jak uniknąć tych niechcianych korzyści, by wyłączyć ich instalację, musiał ingerować w Rejestr.

Tak właśnie na komputery użytkowników trafił Keeper, program do zarządzania hasłami, co do którego Tavis Ormandy miał już wcześniej zastrzeżenia. W zeszłym roku odkrył on, że jego rozszerzenie przeglądarkowe wstrzykuje swój zaufany interfejs w niezaufane strony, co pozwalało uzłośliwionej stronie na wykradnięcie hasła poprzez niewidoczny formularz. Luka ta została załatana w wersji 10.1.3 aplikacji… choć łatka była dość specyficzna. Po prostu usunięto funkcje wyszukiwania i dodawania hasła do istniejącego rekordu, które można było wykorzystać do ataku.

Teraz Ormandy znów sobie przypomniał o Keeperze. Odkrył, że znów Keeper robi to samo – w wersji dostarczanej dla nie mających wyboru użytkowników Windowsa 10. Wystarczyło zmienić selektory i stary atak znów działał. Okazał jednak deweloperom menedżera łaskę i poinformował ich z wyprzedzeniem. Zespół Keepera wydał poprawkę (w wersji 11.4.4 aplikacji) po otrzymaniu jego zgłoszenia. Jak pisze Craig Lurey, dyrektor techniczny Keeper Security, znów zrobiono to samo co wcześniej – usunięto funkcję dodawania hasła do istniejącej witryny, podjęto też starania by ponownie ta podatność się nie ujawniła.

Zespół bezpieczeństwa Keepera podkreśla, że odkryta przez Ormandy’ego luka nie została wykorzystana w atakach, jednak wszelkie takie zgłoszenia traktuje bardzo poważnie, ponieważ bezpieczeństwo i ochrona danych użytkowników jest priorytetem dla firmy.

Tymczasem Content Delivery Manager wciąż działa, instalując w tle oprogramowanie użytkownikom Windowsa 10. Jeśli chcecie wyłączyć tę funkcję, musicie uruchomić edytor Rejestru (regedit.exe), następnie dostać się do klucza HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager, a następnie zmienić wartość SilentInstalledAppsEnabled na 0.

 

źródło: dobreprogramy.pl

Powiadomienia o nowych wpisach WordPress

Konfigurujemy wysyłanie powiadomień o nowych wpisach czytelnikom

Każdemu z prowadzących bloga lub serwis informacyjny zależy, by publikowane treści dotarły do wszystkich zainteresowanych. W tym celu warto wykorzystać narzędzie, które w łatwy sposób pozwoli nam wysyłać powiadomienia o nowych materiałach nawet wtedy, gdy nasi czytelnicy nie odwiedzają naszej strony. Jak to zrobić? Łatwiej, niż myślisz.

Po zalogowaniu się do naszego panelu administracyjnego na WordPressie instalujemy wtyczkę OneSignal. Po jej włączeniu przechodzimy na stronę onesignal.com, zakładamy tam konto i dodajemy nową aplikację, którą nazywamy tak samo, jak naszą stronę. Po zatwierdzeniu nazwy musimy wybrać platformę, na którą wysyłać będziemy powiadomienia. W nasym przypadku będzie to „Website Push”. W kolejnym widoku konfiguratowa wprowadzić natomiast musimy adres URL strony. Poniżej podanego powinniśmy wskazać plik, który posłuży nam jako domyślna ikona przy wyświetlanych powiadomieniach. Możemy wskazać w tym miejscu na przykład logo strony. Link do niego możemy uzyskać przy wykorzystaniu panelu WordPressa.

Ustawienia OneSignal

W kolejnym kroku wskazujemy „WordPress” i przechodzimy do następnego widoku. Wyświetlone zostaną nam klucze aplikacji, które wprowadzić należy do ustawień wtyczki w panelu administracyjnym WordPressa. Po ich zapisaniu otwórzmy naszą stronę za pomocą dowolnej przeglądarki (poza Safari). W prawym dolnym rogu strony powinniśmy zobaczyć ikonę dzwonka.

Widok OneSignal na WordPress

Za pomocą panelu ustawień wtyczki możemy dostosować jego wygląd, a także dostosować wyświetlające się komunikaty. Teraz czas na skonfigurowanie powiadomień dedykowanych przeglądarce Safari. Powracamy na stronę onesignal.com i korzystając z menu umieszczonego po lewej stronie ekranu, wybieramy „App Settings”, by następnie wcisnąć „Configurate” przy Apple Safari. Ponownie wpisujemy nazwę, adres strony i zapisujemy wprowadzone dane. Teraz możemy odwiedzić stronę przy pomocy Safari (tylko na systemie Mac OS) i sprawdzić, czy wyświetli nam się powiadomienie o możliwości zasybskrybowania powiadomień. Jeśli tak – dane wprowadziliśmy poprawnie.

Powiadomienie OneSignal na WordPress

Od tej chwili możemy wysyłać naszym subskrybentom informacje zarówno o nowych postach, jak i okolicznościowe. Zacznijmy od tych pierwszych. Przy publikacji wpisu w prawym górnym rogu wpisu zobaczymy mały panel „OneSignal Push Notification” z domyślnie zaznaczoną opcją „Send notification on post publish”. Jeśli jej nie odznaczymy, subskrybent naszych powiadomień otrzyma powiadomienie o naszym nowym wpisie. Jeśli je kliknie, jego przeglądarka otworzy ów nowy wpis.

W każdej chwili możemy wysłać również niestandardowe powiadomienie. W tym celu musimy otworzyć stronę onesignal.com, z lewego menu wysłać „New Message” i wybrać grupę docelową, która je otrzyma. Następnie klikamy „Next”, wpisujemy tytuł i treść wiadomości i również je zatwierdzając, by w następnym kroku wybrać, czy powiadomienie chcemy wysłać do użytkowników wszystkich obsługiwanych przeglądarek, którzy nas subskrybują, czy tylko np. do tych, którzy korzystają z Firefoxa. W ostatnim już kroku wybieramy, czy nasza notyfikacja ma być wysłane natychmiast, wtedy gdy użytkownik najprawdopodobniej będzie przy komputerze (dane takie posiada OneSignal), czy też o konkretnej godzinie.

Rozbudowany panel OneSignal pozwoli nam badać statystyki zainteresowania naszymi powiadomieniami oraz testować ich treści wykonując badania A/B. Dzięki temu w skuteczny sposób poinformujemy zainteresowanych czytelników o nowym wpisie.

Przyspieszamy stronę na wordpress

Jak przyspieszyć stronę za pomocą .htaccess

Istnieje wiele sposobów na przyśpieszenie strony internetowej, ale czy wiedziałeś, że możesz to zrobić także za pomocą jednego pliku? Dzięki .htaccess możesz zdefiniować zasady po stronie serwera i znacznie zoptymalizować stronę pod kątem szybkości działania.

Do przyspieszenia strony internetowej wybieramy odpowiedni hosting, rozważnie dostosowujemy szablon, a także instalujemy często wtyczki np. do cache’owania naszej witryny. Wiele osób zapomina jednak o prostym pliku .htaccess. Znajduje się on w głównym katalogu ze stroną i pozwala dostosować ustawienia związane z działaniem serwera. Dzięki niemu możemy lepiej zoptymalizować naszą stronę pod kątem wydajności.

Czym jest plik .htaccess?

Potęga pliku .htaccess jest bardzo duża i pozwala on dostosować wiele funkcji. Umożliwia on m.in. tworzenie przekierowań czy zarządzanie przyjaznymi linkami (tzw. przepisywanie adresów URL), a także blokowanie dostępu do strony z poszczególnych adresów IP oraz ochronę folderów hasłem. Na potrzeby tego poradnika musisz po prostu wiedzieć, że plik ten pozwala kontrolować ustawienia w obrębie całego serwera lub konkretnego katalogu, w którym plik .htaccess się znajduje.

To, co nas interesuje najbardziej, to opcje związane z szybkością działania strony. W pliku .htaccess możesz dostosować funkcje związane z pamięcią podręczna czy kompresją strony. Dzięki temu będzie się ona szybciej ładować u osoby odwiedzającej.

Włącz kompresję przez mod_deflate lub mod_gzip

Komunikacja między przeglądarką internetową użytkownika a twoim serwerem ze stroną internetową polega na prostej zasadzie. Gdy ktoś wchodzi na twoją stronę, to najpierw przeglądarka wysyła zapytanie do serwera, a następnie serwer na to zapytanie odpowiada, wysyłając zawartość strony.

Oczywistym faktem jest, że im mniej danych serwer ma do przesłania tym szybciej strona się załaduje osobie odwiedzającej. Dzięki funkcji kompresji G-Zip możesz znacznie zmniejszyć ilość zapytań do swojej strony i przyspieszyć jej przekazywanie z serwera do przeglądarek internetowych. A aktywować tę funkcję możesz właśnie w pliku .htaccess za pomocą poniższego kodu:

<ifModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
  AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript application/json
</ifModule>

Jeśli mod_deflate nie jest dostępny na serwerze, można skorzystać z mod_gzip, który daje podobne efekty:

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

Po wklejeniu tego fragmentu do pliku .htaccess funkcja kompresji G-Zip zostanie aktywowana. Od teraz twoja strona powinna uruchamiać się szybciej. Możesz też sprawdzić, czy kompresja G-Zip na pewno działa. Wystarczy wejść na stronę sprawdzania kompresji G-Zip i wpisać tam swój adres strony. Wyświetlone zostanie podsumowanie, które informuje, ile wynosi rozmiar strony w formie nieskompresowanej i ile w formie skompresowanej. Jasno widać, że dzięki kompresji G-Zip waga danych do przesłania zmniejsza się nawet o 70-80%.

Włącz mod_expires i dostosuj trwałość cache

Z pewnością nieraz spotkałeś się z terminem cache, czyli pamięci podręcznej. Na szybko możemy wyróżnić dwa rodzaje pamięci podręcznej – po stronie serwera oraz po stronie klienta.

Cache po stronie serwera działa w ten sposób, że na twoim serwerze przygotowywana jest gotowa wersja strony z najbardziej optymalnymi danymi do wysłania. Taki rodzaj pamięci podręcznej zarządzany jest zazwyczaj przez wtyczki np. do WordPressa. Dzięki temu serwer „ma mniej roboty” podczas generowania strony.

Drugim rodzajem cache jest ten po stronie klienta, czyli po stronie przeglądarki internetowej. Gdy ktoś odwiedzi twoją stronę, to niezmienna część witryny (np. grafiki, style CSS) mogą zostać zapamiętane bezpośrednio w urządzeniu osoby odwiedzającej. Dzięki temu po kolejnym wejściu na stronę większość danych zostanie załadowana z jego komputera / smartfona, co jest znacznie szybsze. Cache po stronie klienta możesz dostosować właśnie za pomocą pliku .htaccess. Dzięki regułom Expire (czasu trwałości danego elementu) możesz informować przeglądarkę, po jakim czasie ma prosić o nowe pliki ze serwera. Odpowiada za to poniższy kod.

<ifModule mod_mime.c>
  AddType application/x-font-ttf ttc ttf
  AddType application/font-woff woff
  AddType application/font-woff2 woff2
  AddType application/vnd.ms-fontobject eot
</ifModule> <ifModule mod_expires.c>  ExpiresActive On  ExpiresDefault "access plus 5 seconds"  ExpiresByType image/x-icon "access plus 2592000 seconds"  ExpiresByType image/jpeg "access plus 2592000 seconds"  ExpiresByType image/png "access plus 2592000 seconds"  ExpiresByType image/gif "access plus 2592000 seconds"  ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"  ExpiresByType text/css "access plus 604800 seconds"  ExpiresByType text/javascript "access plus 216000 seconds"  ExpiresByType application/javascript "access plus 216000 seconds"  ExpiresByType application/x-javascript "access plus 216000 seconds"  ExpiresByType text/html "access plus 600 seconds"  ExpiresByType application/xhtml+xml "access plus 600 seconds" ExpiresByType application/x-font-ttf "access plus 216000 seconds"
ExpiresByType application/font-woff "access plus 216000 seconds"
ExpiresByType application/x-font-woff "access plus 216000 seconds"
ExpiresByType font/woff "access plus 216000 seconds"
ExpiresByType application/font-woff2 "access plus 216000 seconds" </ifModule>

Powyższy kod ustawia czas ważności poszczególnych typów plików – obrazów JPG, PNG, GIF, skryptów JavaScript, a także stylów CSS. Gdy ktoś załaduje twoją stronę, to pliki tego typu zostaną zapamiętane w przeglądarce osoby odwiedzającej na wskazany okres czasu. Gdy ktoś ponownie wejdzie na twoją stronę, to pliki te nie będą ponownie pobierane z serwera. Zamiast tego załadują się z dysku osoby odwiedzającej. Dyrektywy te wprowadzają także obsługę niestandardowych czcionek, które możemy mieć na stronie i sprawia, że one również będą odczytywane z pamięci lokalnej podczas kolejnych wizyt.

Proces ten będzie się powtarzać przez wskazany okres czasu. Znacznie przyspiesza to przeglądanie strony, a zwłaszcza sklepów internetowych, na które użytkownicy często powracają. Raz załadowane zdjęcia produktów będą już potem odczytywane z dysku użytkownika, a więc przeglądanie asortymentu twojego sklepu będzie znacznie szybsze.

Warto w tym kodzie zwrócić uwagę zwłaszcza na linię odpowiedzialną za treści typu “text/html”. Dodanie tej linii znacznie przyspieszy ponowne otwarcie strony, którą klient już raz odwiedził, jednak w przypadku wprowadzenia jakichkolwiek zmian będą one u odwiedzającego widoczne dopiero po 10 minutach (600 sekundach).

 

Włącz funkcję Keep-Alive

Funkcja Keep-Alive pozwala kontrolować sposób przesyłania plików od serwera do klienta (przeglądarki internetowej). Gdy funkcja ta jest wyłączona, a serwer do przesłania ma np. 50 plików do otwarcia strony, to do każdego pliku nawiązywane jest nowe połączenie TCP. Z kolei gdy funkcja ta jest włączona, to wszystkie pliki mogą zostać przesłane bez konieczności każdorazowego odnawiania połączenia TCP.

Działanie tego mechanizmu można przedstawić na przykładzie zakupów w sklepie. Wyobraź sobie, że idziesz do sklepu i przy kasie prosisz o jeden produkt. Otrzymujesz produkt, ale przypominasz sobie, że chcesz kupić coś jeszcze. Znów prosisz o kolejną rzecz i tak kilka razy. Zakupy wtedy potrwają bardzo długo – mógłbyś jednak je przyspieszyć, gdybyś od razu poprosił o wszystko, co chcesz kupić. I na to właśnie pozwala funkcja Keep-Alive, dzięki której przeglądarka może odebrać więcej plików z serwera za jednym zamachem.

<ifModule mod_headers.c>
 Header set Connection keep-alive
</ifModule>

Dzięki powyższej formule raz nawiązane połączenie z serwerem pozwala przeglądarce poprosić o więcej plików i odebrać je jednocześnie.

Dostosuj rodzaj cache dla poszczególnych plików (dla rozwiązań typu Varnish i CloudFlare)

Oprócz czasu, po jakim przeglądarka ma odświeżyć pliki z serwera możesz także ustawić sposób cache’owania poszczególnych typów plików. Dla każdego typu plików (np. CSS, JPG, PHP, JS) możesz ustawić konkretny sposób przechowywania. Pliki mogą być przechowywane jako publiczne, jako prywatne lub w ogóle mogą być nieprzechowywane.

Ma to dość duże znaczenie podczas korzystania z rozwiązań opartych na serwerach proxy (np. Varnish czy popularny CloudFlare). Strony wykorzystujące np. chmurę CloudFlare działają szybciej, gdyż korzystają z serwerowni rozsianych po całym świecie. W zależności od tego, skąd ktoś próbuje wejść na naszą stronę, CloudFlare udostępni ją z najbliższej lokalizacji. Oczywiście strona w rzeczywistości nadal znajduje się na naszym głównym serwerze np. w LH.pl, jednak CloudFlare udostępnia część strony na podstawie pamięci cache ze swoich serwerów.

Dzięki poniższym dyrektywom możemy poniekąd określić, jakie typy plików mają być ustawione jako publiczne, a jakie jako prywatne. Pliki publiczne mogą być w pełni cache’owane i przechowywane we współdzielonej pamięci podręcznej na cache-serwerze (np. CloudFlare), natomiast elementy oznaczone jako prywatne będą ignorowane (nie będą przechowywane w pamięci współdzielonej serwera cache).

Generalnie większość plików możemy cache’ować jako publiczne i jest to domyślny sposób przechowywania danych. Istnieją jednak rodzaje plików, gdzie to zachowanie nie jest wskazane. Przykładem jest chociażby zawartość strony indywidualnie wygenerowana dla danego użytkownika – każdy, kto wejdzie na Facebooka czy Twittera zobaczy dużą część strony w takiej samej formie, jak inni użytkownicy, ale główna zawartość na osi czasu czy w aktualnościach będzie inna dla każdego użytkownika. Takie elementy nie powinny być cache’owane w taki sam sposób, jak np. logo serwisu społecznościowego, które jest wspólne dla wszystkich.

Dlatego możemy poszczególne typy plików oznaczyć jako publiczne (public), prywatne (private) lub nadać im taki status, aby nie były przechowywane wcale (no-store).

Przykładowa formuła do pliku .htaccess ustawiająca konkretne reguły:

<ifModule mod_headers.c>
  <filesMatch "\.(ico|jpe?g|png|gif|swf)$">
    Header set Cache-Control "public"
  </filesMatch>
  <filesMatch "\.(css)$">
    Header set Cache-Control "public"
  </filesMatch>
  <filesMatch "\.(js)$">
    Header set Cache-Control "private"
  </filesMatch>
  <filesMatch "\.(x?html?|php)$">
    Header set Cache-Control "private, must-revalidate"
  </filesMatch>
</ifModule>

Na powyższym przykładzie widać, że pliki ICO, JPEG, PNG czy GIF mogą być przechowywane jako pliki publiczne, z kolei pliki JS czy PHP jako prywatne. Jak jednak wspomniałem, ta opcja przyda się przede wszystkim osobom, które korzystają z rozwiązań typu Varnish czy CloudFlare.

Przetestuj stronę w Google PageSpeed Insight

Google udostępnia test szybkości Google PageSpeed Insight, który możesz przeprowadzić na swojej stronie. Test ten sprawdza witrynę pod kątem renderowania kodu JavaScript i CSS, szybkości ładowania wszystkich elementów, użycia pamięci podręcznej, optymalizacji obrazów i przestrzegania zasad związanych z kompresją strony i ładowanych w niej ozdobnych dodatków.

Nie wymaga on od użytkownika wykonywania żadnych zaawansowanych procedur. Wystarczy wpisać swój adres strony i kliknąć przycisk „Analizuj”. Po chwili uzyskasz wyniki, oddzielne dla wersji mobilnej strony i wersji na komputery. W wynikach znajdziesz punktację w skali od 0 do 100, a także sugestie odnośnie tego, co należy zrobić, aby zwiększyć swój wynik. Im wyższy wynik, tym strona szybciej się otwiera i zwiększa się jej pozycja w wynikach wyszukiwania Google.