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.