haproxy

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.

 

 

 

 

Load balancing MySQL – Haproxy

07 czerwca 2015 Komentarze (0)

logo-medLoad balancing MySQL z wykorzystaniem Haproxy

Przy niektórych projektach potrzebujemy wyższej niezawodności baz danych lub też wyższej ich wydajności. Możemy tego dokonać instalując więcej niż jeden serwer MySQL i tworząc między nimi replikacje. Ale jak teraz prosto wykrywać usterki i  balansować ruchem pomiędzy kilkoma serwerami MySQL ?

Za pomocą Haproxy ! 🙂

Haproxy to bardzo wydajny loadbalancer który znany jest z wykorzystania dla serwerów WWW, jednak bardzo dobrze radzi sobie też np. z serwerami baz danych.

Poniżej przygotowana została podstawowa konfiguracje złożona z dwóch hostów MySQL: głównego oraz zapasowego i jednego Loadbalancera Haproxy w trybie failover.

IP hostów oraz role:

– 172.16.10.1 – Haproxy LoadBalancer,

– 172.16.10.2 – MySQL serwer główny ( Master ),

– 172.16.10.3 – MySQL serwer zapasowy ( Backup ).

Do sprawdzania żywotności MySQL musimy dodać użytkownika bez hasła z możliwością połączenia się do niego z hosta haproxy. Możemy to zrobić np. tak:

mysql -u root -p -e "INSERT INTO mysql.user (Host,User) values ('172.16.10.1','haproxy_check'); FLUSH PRIVILEGES;"

Przykładowa konfiguracja dla dwóch hostów z wykrywaniem awarii MySQL:

 global
 log /dev/log local0 notice
 log /dev/log local0 err
 daemon
 user haproxy
 group haproxy
 pidfile /var/run/haproxy.pid
 stats socket /var/run/haproxy.stat uid 108 gid 112 mode 600
 ulimit-n 1000000
 maxconn 409600

 defaults
 log global
 mode http
 option tcplog
 option dontlognull
 retries 3
 option redispatch
 maxconn 409600
 timeout client 300s
 timeout server 300s
 timeout connect 10s

 listen MySQL 172.16.10.1:3306
 mode tcp
 balance roundrobin
 option tcpka
 option mysql-check user haproxy-check post-41
 server MySQL-node1 172.16.10.2:3306 check
 server MySQL-node2 172.16.10.3:3306 check backup

Konfiguracje tą możemy dowolnie dostosować, tak by obsłużyła większą ilość hostów czy ustawić Loadbalancer w trybie HA ( High Availability ) niwelując SPOF ( Single Point of Failure ). Poniższe ustawienia mogą też działać bezpośrednio na serwerze z którego chcemy się podłączyć, wystarczy wtedy zmienić IP z 172.16.10.1 na 127.0.0.1 i aplikacja może pracować tak jak serwer bazodanowy MySQL byłby zainstalowany lokalnie.