Ochrona przed luką – HTTPoxy

Przed kilkoma godzinami pojawiła się dość groźna luka nazwana Httpoxy na którą podatne są środowiska web działające w oparciu CGI/FastCGI. Podatność stwierdzono dla języków PHP, Python i GO.

Przypisane zostały jej numery CVE:

  • CVE-2016-5385: PHP
  • CVE-2016-5386: Go
  • CVE-2016-5387: Apache HTTP Server
  • CVE-2016-5388: Apache Tomcat
  • CVE-2016-1000109: HHVM
  • CVE-2016-1000110: Python

Powstała też  strona dokładnie opisująca lukę oraz cały czas aktualizowany artykuł na na stronie Cert.

Na poziomie systemu możemy poradzić sobie z luką poprzez edycje konfiguracji:

NGINX:

Dodajemy do pliku: /etc/nginx/fastcgi_params lub bezpośrednio w konfiguracji PHP vhosta:

fastcgi_param HTTP_PROXY „”;

a jeżeli używamy modułu proxy:

proxy_set_header Proxy „”;

APACHE:

Dodajemy zmienną odwołującą  się do modułu headers ( dla Debian można uaktywnić moduł poleceniem: a2enmod headers ):

RequestHeader unset Proxy early

lub w przypadku gdy korzystamy z mod_security:

SecRule &REQUEST_HEADERS:Proxy „@gt 0” „id:1000005,log,deny,msg:’httpoxy denied'”

HAPROXY:

Dodajemy do konfiguracji:

http-request del-header Proxy

VARNISH:

Dodajemy do sekcji vcl_recv:

unset req.http.proxy;

 

Gdyby były pytania/problemy zapraszamy do kontaktu.

 

 

 

 

Nginx – open_file_cache

Nginx – open_file_cache

nginxKolejny post o Nginx który ma ogromne możliwości konfiguracyjne już w standardowym wydaniu. Przy sporym ruchu bardzo fajnym dodatkiem jest open_file_cache, tu jednak trzeba zastrzec, że ten ruch musi być naprawdę duży. Pozwala on cachować metadane plików ( nie cachuje plików ) odciążając dysk i procesor.

Wracając do open_file_cache, to całość opiera się na dodaniu kilku linijek do bloku http w nginx.conf:

open_file_cache max=20000 inactive=5m;
open_file_cache_valid 10m;
open_file_cache_min_uses 1;
open_file_cache_errors on;

Wyjaśniając znaczenie:

open_file_cache max – definiuje ilość plików które znajdą się w cache, a parametr „inactive” odpowiada za usunięcie z cache plików do których nie było zapytań przez ostanie 5 min ( standardowo jest to 60 sekund).

open_file_cache_valid – czas który elementy są utrzymywane w cache

open_file_cache_min_uses – minimalna ilość requestów potrzebna by element „nie wyleciał” z cache ( inactive ).

open_file_cache_errors – określa czy cachować błędy przy poszukiwaniu plików np. 404.

W kolejnych postach o Nginx możemy poruszyć już cachowanie całych plików 😉

Nginx – proste zabezpieczenie WordPress

Nginx – proste zabezpieczenie WordPress

 

zabezpieczenie wordpressPopulary skrypt blogowy jest jednym z najczęściej atakowanych w sieci, w poniższym wpisie pokażemy jak można wykonać proste zabezpieczenie WordPress. Całość polegać będzie na dodaniu do konfiguracji Virtualhosta kilku wpisów blokujących niebezpieczne zapytania:

  1. Blokada wszystkiego z kropką z przodu np. .htaccess
location ~ /\. {
 deny all;
 }

2. Blokada wykonywania skryptów PHP w katalogach:

location ~* ^/wp-content/.*.(php|phps)$ {
 deny all;
}
     location ~* ^/wp-includes/.*\.(php|phps)$ {
      internal;
     }

3. Blokada odczytu różnych rozszerzeń plików ( tu można dostosować  pod własne wymagania ):

location ~* ^/wp-content/.*.(txt|md|exe|sql|sh|pl|py|zip|rar|gz|tar.gz)$ {
 deny all;
 }

4. Blokada dostępu do logowania, możemy ją zrobić na dwa sposoby, dodatkowa autoryzacja na podstawie IP lub hasła. Do każdego z wpisów musimy dodać konfiguracje fastcgi wymaganą do uruchomienia PHP, tą możemy skopiować z głównego location i może ona wyglądać tak:

Autoryzacja IP:

location ~ ^/(wp-admin|wp-login\.php) {
 location ~ \.php$ {
 try_files $uri =404;
 include /etc/nginx/fastcgi_params;
 fastcgi_pass 127.0.0.1:9001;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 allow IP1;
 allow IP2;
 deny all;
 }

Autoryzacja hasłem:

location ~ ^/(wp-admin|wp-login\.php) {
 location ~ \.php$ {
 try_files $uri =404;
 include /etc/nginx/fastcgi_params;
 fastcgi_pass 127.0.0.1:9001;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 auth_basic "Login";
 auth_basic_user_file /etc/nginx/.htpasswd;
}

Oczywiście składania pliku .htpasswd jest taka sama jak dla Apache i możemy ją wygenerować samemu lub programem pochodzącym z Apache:  htpasswd ( dla Debian: apt-get install apache2-utils dla Centos: yum install httpd-tools ).

Blokadę możemy rozszerzyć o plik xmlrpc.php który jest często wykorzystywany w Atakach. Wystarczy wtedy zmienić zawartość zmiennej location na:

location ~ ^/(wp-admin|wp-login|xmlrpc\.php) {

 

Dodatkowymi zabezpieczeniami może być wyłączenie niebezpiecznych funkcji w PHP oraz aktywacją open_basedir ( w przypadku środowisk bez chroot’owanch kont ).

Zabezpieczenie WordPress może odbyć się również w bardziej profesjonalny sposób z wykorzystaniem rozwiązań WAF ( Web Application Firewall ) dla Nginx mamy do dyspozycji mod_security mod_security oraz Naxsi.

W przypadku problemów z bezpieczeństwem aplikacji internetowych i chęcią ich zabezpieczenia za pomocą m.in. mechanizmów WAF, zapraszamy do kontaktu: https://netfs.pl/kontakt

Bezpieczny SSL na Apache i Nginx

SSL Server Test  netfs.pl  Powered by Qualys SSL Labs

Bezpieczeństwo SSL na Apache i Nginx 

 

Jak zabezpieczyć się przed atakami Poodle, Logjam i przy okazji uzyskać wynik A+ w teście SSLLABS ( https://www.ssllabs.com/ssltest/analyze.html ) ?

 

Wystarczy zastosować się do kilku poniższych kroków:

1. Mieć aktualny system z pakietem OpenSSL wspierającym TLS w wersji 1.2 ( Dla Debian od wersji 7.x, ale zalecamy aktualną stabilną czyli 8.x ).

2. Stosować zawsze certyfikaty CA które dostajemy od wystawcy, dla Apache dodajemy je pod zmienną: ‚SSLCACertificateFile’, a dla Nginx dodajemy poniżej do pliku z certyfikatem domeny.

3. Wygenerować plik dhparams.pem – najlepiej tym w którym trzymamy klucze SSL.

openssl dhparam -out dhparams.pem 2048

4. Dostosować poniższą konfiguracje:

Konfiguracja dla serwera Apache:

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA
SSLCompression Off
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

Dla Apache w wersji 2.4.8+ i OpenSSL 1.0.2+ możemy zmienić zmienną „SSLCipherSuite” na:

SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

I dodać:

SSLOpenSSLConfCmd DHParameters "scieżka do wygenerowanego pliku dhparams.pem"

 

Konfiguracja dla serwera Nginx:

ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS';
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_session_cache shared:SSL:10m;
ssl_stapling on;
ssl_stapling_verify on;
resolver 127.0.0.1 8.8.4.4 8.8.8.8 valid=300s;
resolver_timeout 10s;
ssl_dhparam "scieżka do wygenerowanego pliku dhparams.pem";
add_header Strict-Transport-Security max-age=63072000;

Zostaje na koniec zrestartować usługę ; – )