O Trend Micro Deep Security na tym blogu pisałem wielokrotnie, nie wspominałem jednak do tej pory o jednej z funkcji tego rozwiązania, czyli inspekcji ruchu SSL. Zgodnie z ostatnimi statystykami Google, ponad 70% ruchu w sieci jest już szyfrowane. Oznacza to, że wszystkie rozwiązania IDS/IPS/WAF które nie potrafią rozszywać ruchu SSL i dokonywać jego inspekcji, są bezradne wobec ataków! W przypadku Deep Security mamy możliwość włączenia inspekcji SSL na poziomie modułu Intrusion Prevention. Oczywiście nie osiągniemy tutaj takiej wydajności i skuteczności jak w przpakdu np. BIG-IP F5, nie mam mowy tez o SSL-Offload, ale dzięki temu podniesiemy wyraźnie poziom bezpieczeństwa ochranianych usług.

Inspekcja ruchu SSL niesie ze sobą pewne ograniczenia, włączenie jej bezmyślnie może doprowadzić do odcięcia usługi. W tym poście opiszę, na przykładzie Apache HTTPD, jak to zrobić bezpiecznie i skutecznie. Wspomniane ograniczenia biorą się ze sposobu obsługi inspekcji SSL przez Trend Micro Deep Security, to czego nie potrafi zdeszyfrować, jest z automatu blokowane. Dlatego oprócz włączenia inspekcji, należy odpowiednio przygotować usługę (w tym wypadku Apache Httpd). Zaczniemy od warunków jakie muszą być spełnione. Deep Security wspiera protokoły SSL 3.0, TLS 1.0-1.2, dodatkowo nie wspierana jest kompresja SSL oraz Diffie-Hellman jako protokół autentykacji przy zestawianiu połączenia szyfrowanego (handshake) . Mamy też ograniczoną liczbę wspieranych szyfrów (cipher), protokoły te to:

RC4-MD5
RC4-SHA
DES-CBC-SHA
DES-CBC3-SHA
AES128-SHA
AES256-SHA
AES128-SHA256
AES256-SHA256
CAMELLIA128-SHA
CAMELLIA256-SHA
DES-CBC3-MD5

Używając tych protokołów nie dostaniecie zielonej ikonki w żadnym teście typu “SSL Check”, co nie oznacza, że AES256-SHA256 jest protokołem do złamania (wiem wiem). W kwestii bezpieczeństwa jest to zawsze wyważenie pryncypiów, co jest ważniejsze? Mocne szyfrowanie czy inspekcja zaszyfrowanego ruchu? W przypadku usługi nie krytycznej, jaką jest mój blog, interesuje mnie inspekcja i ochrona przed atakami. Odpowiednie przygotowanie konfiguracji wygląda tak, że dodajemy odpowiednie dyrektywy do pliku konfiguracyjnego:

SSLEngine on
SSLProtocol             all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          AES128-SHA:AES256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:DES-CBC3-MD5:AES128-SHA256:AES256-SHA256:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!DH:!EDH:!ADH
SSLHonorCipherOrder     on
SSLCompression          off
SSLOptions +StrictRequire

Użycie szyfru AES128-SHA jako pierwszego jest też kompromisem pomiędzy bezpieczeństwem a szybkością działania. Im “cięższy” szyfr tym potrzebujemy więcej mocy na deszyfrację i czasu na jej przeprowadzenie. Aby deszyfrować ruch, potrzebujemy wgrać klucz i certyfikat do Deep Security w module Intrusion Prevention w sekcji Advanced.

W trakcie konfiguracji musimy podać, port, interfejs, wskazać IP (wybrany, lista lub wszystkie) oraz załadować zestaw klucz certyfikat wraz z hasłem.

W przypadku konkretnej, znanej Deep Security usługi, która jest wystawiona na niestandardowym porcie. Musimy zmodyfikować odpowiednią regułę IPS lub listę portów dostępną w zakładce “Policies”. Dla Apache byłaby to reguła “Web Server Common”, bez wskazania właściwego portu reguła ta nie zadziała.

Pamiętajmy też, że licencja VMware NSX for vSphere nie wspiera bez agentowej inspekcji ruchu dla IPS, tutaj musimy zastosować ochronę agentową. Jeśli wszystko poprawnie skonfigurowaliśmy, to działa i usługa i IPS.

Interpretacja tego obrazka jest bardzo ciekawa, to co widzimy oznacza, że przychodzą z Internetu konkretne skany próbujące wymusić użycie dziurawego, słabego, nie wspieranego szyfru. I to pomimo, że Apache przy zapinaniu sesji zwraca listę protokołów i szyfrów jakie jest w stanie obsłużyć. A według testów jakie przeprowadziłem (SSL Check) to sam AES128-SHA jest wspierany przez 99% procent przeglądarek funkcjonujących na rynku.