mod_security

Ochrona przed luką – HTTPoxy

18 lipca 2016 Komentarze (0)

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 – proste zabezpieczenie WordPress

08 lutego 2016 Komentarze (0)

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