Przewodnik po hartowaniu i bezpieczeństwie Apache Tomcat

Praktyczne wskazówki dotyczące wzmocnienia i zabezpieczenia serwera Apache Tomcat

Tomcat to popularny serwer kontenerów Servlet i JSP, wykorzystywany przez wiele witryn o dużym natężeniu ruchu, takich jak LinkedIn.com, Dailymail.co.uk, Comcast.net, Wallmart.com, Reuters.com, Meetup.com i Webs.com.

Poniższy wykres ilustruje pozycję rynkową Tomcata wśród serwerów aplikacji Java.

Źródło: Plumbr

Z technicznego punktu widzenia, Tomcat może pełnić funkcję serwera frontowego, obsługując bezpośrednio żądania witryn. Jednak w środowiskach produkcyjnych zaleca się użycie serwerów internetowych, takich jak Apache czy Nginx, jako warstwy pośredniej do przekierowywania żądań do Tomcata.

Wykorzystanie serwera WWW do obsługi żądań niesie za sobą korzyści w zakresie wydajności i bezpieczeństwa. W przypadku korzystania z Apache HTTP jako serwera frontowego, należy również zadbać o jego odpowiednie zabezpieczenie.

Pozostawienie domyślnej konfiguracji Tomcata może ujawnić wrażliwe informacje, co ułatwia potencjalnym intruzom przygotowanie ataku na aplikację.

Poniższe wskazówki zostały przetestowane na środowisku UNIX z Tomcatem w wersji 7.x.

Dla kogo jest ten przewodnik?

Ten przewodnik jest przeznaczony dla administratorów oprogramowania pośredniego, osób zajmujących się wsparciem aplikacji, analityków systemowych oraz wszystkich, którzy pracują z Tomcatem lub chcą nauczyć się, jak go wzmocnić i zabezpieczyć.

Wymagana jest dobra znajomość komend Tomcata i systemu UNIX.

Ważne informacje

Do weryfikacji zmian będziemy potrzebować narzędzia do sprawdzania nagłówków HTTP. Można to zrobić na dwa sposoby:

Dla aplikacji dostępnych w Internecie można skorzystać z zewnętrznych narzędzi do analizy nagłówków HTTP.

W przypadku aplikacji intranetowych można użyć narzędzi deweloperskich w przeglądarkach Google Chrome lub Firefox.

Zaleca się wykonanie kopii zapasowej każdego pliku, który ma być modyfikowany.

W tym przewodniku folder instalacyjny Tomcata będziemy oznaczać jako $tomcat.

Przejdźmy teraz do procedur wzmacniania i zabezpieczania Tomcata.

Usuwanie banera serwera

Pierwszym krokiem w zabezpieczaniu serwera jest usunięcie banera serwera z nagłówka HTTP.

Wyświetlanie banera serwera ujawnia nazwę produktu i jego wersję, co może prowadzić do ujawnienia informacji o potencjalnych lukach w zabezpieczeniach.

Domyślnie strona obsługiwana przez Tomcat wyświetla nagłówek zawierający informacje o serwerze.

Ukryjmy szczegóły dotyczące produktu i wersji w nagłówku serwera.

  • Przejdź do katalogu $tomcat/conf.
  • Otwórz plik server.xml w edytorze vi.
  • Dodaj następującą linię do konfiguracji portu złącza:
Server =” “

Przykład:

<Connector port="8080" protocol="HTTP/1.1" 
connectionTimeout="20000" 
Server =" "
redirectPort="8443" />
  • Zapisz plik i ponownie uruchom serwer Tomcat. Po ponownym uruchomieniu, nagłówek serwera powinien być pusty.

Uruchamianie Tomcata z menedżerem bezpieczeństwa

Menedżer bezpieczeństwa chroni przed nieautoryzowanymi apletami działającymi w przeglądarce.

Uruchamianie Tomcata z menedżerem bezpieczeństwa jest zalecane, a Tomcat udostępnia szczegółową dokumentację na temat Menedżera bezpieczeństwa Tomcat.

W tym przypadku nie ma potrzeby modyfikacji żadnych plików konfiguracyjnych. Wystarczy uruchomić skrypt startup.sh z odpowiednim argumentem.

Uruchom Tomcata z argumentem –security.

[[email protected] bin]# ./startup.sh -security
Using CATALINA_BASE: /opt/tomcat
Using CATALINA_HOME: /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JRE_HOME: /usr
Using CLASSPATH: /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar
Using Security Manager
Tomcat started.
[[email protected] bin]#

Włączanie protokołu SSL/TLS

Obsługa żądań internetowych przez HTTPS jest niezbędna do zapewnienia bezpieczeństwa danych przesyłanych między klientem a Tomcatem. Aby aplikacja internetowa była dostępna przez HTTPS, należy wdrożyć certyfikat SSL.

Zakładając, że posiadasz już magazyn kluczy z certyfikatem, dodaj poniższy wiersz do pliku server.xml w sekcji konfiguracji portu łącznika.

SSLEnabled="true" scheme="https" keystoreFile="ssl/bloggerflare.jks" keystorePass="chandan" clientAuth="false" sslProtocol="TLS"

Pamiętaj, aby dostosować nazwę pliku magazynu kluczy i hasło do swoich ustawień.

W razie potrzeby, instrukcje dotyczące procesu generowania magazynu kluczy i CSR znajdziesz w odpowiednich przewodnikach.

Wymuszanie HTTPS

Ta opcja jest dostępna tylko w przypadku włączenia protokołu SSL. W przeciwnym razie może spowodować problemy z działaniem aplikacji.

Po włączeniu protokołu SSL zaleca się przekierowanie wszystkich żądań HTTP na HTTPS, aby zapewnić bezpieczną komunikację między użytkownikiem a serwerem aplikacji Tomcat.

  • Przejdź do katalogu $tomcat/conf.
  • Otwórz plik web.xml w edytorze vi.
  • Dodaj poniższy kod przed znacznikiem </web-app>
<security-constraint> 
<web-resource-collection> 
<web-resource-name>Protected Context</web-resource-name> 
<url-pattern>/*</url-pattern>
</web-resource-collection> 
<user-data-constraint> 
<transport-guarantee>CONFIDENTIAL</transport-guarantee> 
</user-data-constraint> 
</security-constraint>
  • Zapisz plik i ponownie uruchom serwer Tomcat.

Dodawanie flag Secure i HttpOnly do plików cookie

Bezpieczeństwo sesji i plików cookie aplikacji internetowej może być zagrożone, jeśli nie zastosuje się odpowiednich zabezpieczeń. Flagi Secure i HttpOnly są dodawane do nagłówka odpowiedzi.

Aby to zrobić, dodaj poniższy kod w sekcji session-config pliku web.xml.

<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>

Zrzut ekranu konfiguracji:

Zapisz plik i ponownie uruchom serwer Tomcat, aby sprawdzić nagłówek odpowiedzi HTTP.

Uruchamianie Tomcata z nieuprzywilejowanego konta

Zaleca się używanie oddzielnego, nieuprzywilejowanego konta użytkownika do uruchamiania Tomcata. Chroni to inne usługi w przypadku potencjalnego naruszenia jednego z kont.

  • Utwórz użytkownika UNIX, na przykład tomcat:
useradd tomcat
  • Zatrzymaj serwer Tomcat, jeśli jest uruchomiony.
  • Zmień właściciela folderu $tomcat na użytkownika tomcat:
chown -R tomcat:tomcat tomcat/

Uruchom serwer Tomcat i upewnij się, że działa z uprawnieniami użytkownika tomcat.

Usuwanie domyślnych i niechcianych aplikacji

Domyślnie, Tomcat dostarczany jest z szeregiem aplikacji internetowych, które mogą, ale nie muszą być potrzebne w środowisku produkcyjnym.

Można je usunąć, aby uprościć konfigurację i uniknąć potencjalnych luk w zabezpieczeniach związanych z domyślnymi aplikacjami Tomcata.

  • ROOT – Domyślna strona powitalna
  • Dokumenty – dokumentacja Tomcata
  • Przykłady – przykładowe strony JSP i serwlety
  • Manager, host-manager – administracja Tomcatem

Aplikacje te znajdują się w katalogu $tomcat/webapps.

[[email protected] webapps]# ls -lt
drwxr-xr-x 14 tomcat tomcat 4096 Sep 29 15:26 docs
drwxr-xr-x 7 tomcat tomcat 4096 Sep 29 15:26 examples
drwxr-xr-x 5 tomcat tomcat 4096 Sep 29 15:26 host-manager
drwxr-xr-x 5 tomcat tomcat 4096 Sep 29 15:26 manager
drwxr-xr-x 3 tomcat tomcat 4096 Sep 29 15:26 ROOT
[[email protected] webapps]#

Zmiana portu i polecenia wyłączania

Domyślnie Tomcat jest skonfigurowany do wyłączania na porcie 8005.

Możliwe jest zdalne wyłączenie instancji Tomcata poprzez połączenie telnet z adresem IP i portem serwera, a następnie wydanie polecenia SHUTDOWN.

Chandans # telnet localhost 8005
Trying ::1... telnet:
connect to address ::1:
Connection refused Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SHUTDOWN Connection closed by foreign host.
Chandans #

Jest to potencjalne zagrożenie bezpieczeństwa.

Pozostawienie domyślnej konfiguracji zwiększa ryzyko związane z bezpieczeństwem.

Zaleca się zmianę portu zamykania i domyślnego polecenia na coś nieprzewidywalnego.

  • Zmodyfikuj następujące elementy w pliku server.xml:
<Server port="8005" shutdown="SHUTDOWN">

8005 – Zmień na inny nieużywany port.

SHUTDOWN – Zmień na bardziej skomplikowaną wartość.

Przykład:

<Server port="8867" shutdown="NOTGONNAGUESS">

Zastępowanie domyślnych stron błędów 404, 403, 500

Domyślna strona dla nieznalezionych, zabronionych lub błędnych żądań serwera może ujawniać szczegóły dotyczące używanej wersji serwera.

Przyjrzyjmy się domyślnej stronie błędu 404.

Aby temu zapobiec, można utworzyć ogólną stronę błędu i skonfigurować plik web.xml w taki sposób, aby przekierowywał do niej w przypadku wystąpienia błędu.

  • Przejdź do katalogu $tomcat/webapps/$application.
  • Utwórz plik error.jsp za pomocą edytora vi.
<html>
<head> 
<title>Error Page</title>
</head>
<body> That's an error! </body>
</html>
  • Przejdź do katalogu $tomcat/conf.
  • Dodaj następujący kod do pliku web.xml przed znacznikiem </web-app>
<error-page> 
<error-code>404</error-code> 
<location>/error.jsp</location>
</error-page>
<error-page> 
<error-code>403</error-code> 
<location>/error.jsp</location>
</error-page>
<error-page> 
<error-code>500</error-code> 
<location>/error.jsp</location>
</error-page>
  • Uruchom ponownie serwer Tomcat, aby przetestować zmiany.

Dużo lepiej!

Można również obsłużyć wyjątki typu java.lang.Exception, aby nie ujawniać informacji o wersji Tomcata w przypadku wystąpienia błędu w kodzie Java.

W tym celu dodaj następujący kod do pliku web.xml i ponownie uruchom serwer Tomcat.

<error-page> 
<exception-type>java.lang.Exception</exception-type> 
<location>/error.jsp</location>
</error-page>

Mam nadzieję, że powyższe wskazówki pomogą Ci w zabezpieczeniu serwera Tomcat. Jeśli chcesz dowiedzieć się więcej na temat administracji Tomcatem, zapoznaj się z tym kursem online.
Dowiedz się także, jak skonfigurować WAS, aby nie pytał o hasło podczas zamykania.