Plik .htaccess
jest kluczowym elementem konfiguracji serwera Apache, pozwalającym na dynamiczne zarządzanie ustawieniami witryny internetowej bez konieczności modyfikowania głównych plików konfiguracyjnych serwera. Odpowiednio skonfigurowany, może znacząco zwiększyć bezpieczeństwo strony, chroniąc ją przed różnorodnymi zagrożeniami, takimi jak ataki typu SQL Injection, Cross-Site Scripting (XSS), czy próby uzyskania nieautoryzowanego dostępu do plików. Zabezpieczenia wprowadzone w pliku .htaccess
nie tylko wzmacniają ochronę przed złośliwymi botami i skryptami, ale także pomagają kontrolować dostęp do określonych zasobów oraz wymuszają korzystanie z szyfrowania, co w efekcie chroni wrażliwe dane przesyłane przez stronę.
1. Zabezpieczenie przed wyciekiem informacji o wersji serwera Apache
ServerSignature Off
ServerTokens Prod
Te dyrektywy wyłączają podpis serwera Apache w odpowiedziach HTTP oraz minimalizują informacje o wersji serwera, co utrudnia ataki bazujące na wersji oprogramowania.
2. Ograniczenie dostępu do pliku .htaccess
i innych plików konfiguracyjnych
<Files .htaccess>
Order Allow,Deny
Deny from all
</Files>
<FilesMatch "^.*\.([Hh][Tt][Aa])">
Order Allow,Deny
Deny from all
</FilesMatch>
Zabezpiecza pliki konfiguracyjne przed nieautoryzowanym dostępem.
3. Blokada dostępu do plików i katalogów systemowych
<FilesMatch "(\.git|\.svn|\.env|composer\.json|composer\.lock|wp-config\.php)">
Order allow,deny
Deny from all
</FilesMatch>
Blokuje dostęp do plików systemowych, takich jak .git
, .svn
, plików konfiguracyjnych oraz kluczowych dla systemu (np. wp-config.php
w WordPress).
4. Ochrona przed atakami XSS (Cross-Site Scripting)
Header set X-XSS-Protection "1; mode=block"
Włącza ochronę przeglądarki przed atakami XSS.
5. Ochrona przed MIME Sniffing
Header set X-Content-Type-Options "nosniff"
Zapobiega przeglądarce w wykrywaniu rodzaju pliku na podstawie jego zawartości, co może ochronić przed atakami typu MIME-sniffing.
6. Content Security Policy (CSP)
Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';"
Ustawia politykę bezpieczeństwa dotycząca zasobów, które mogą być ładowane przez stronę. Warto dostosować reguły CSP do specyficznych potrzeb strony.
7. Zabezpieczenie przed kliknięciem w ramce (Clickjacking)
Header always append X-Frame-Options DENY
Uniemożliwia umieszczanie strony w ramkach iframe, co zapobiega atakom typu Clickjacking.
8. Zabezpieczenie ciasteczek przed atakami typu Cross-Site Scripting i Cross-Site Request Forgery
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=Strict
Ustawia ciasteczka w trybie HttpOnly, Secure oraz SameSite, co chroni przed atakami XSS i CSRF.
9. Ograniczenie metod HTTP
<LimitExcept GET POST>
Order Deny,Allow
Deny from all
</LimitExcept>
Blokuje inne metody HTTP, takie jak PUT
, DELETE
, OPTIONS
, które mogą być używane w atakach.
10. Zabezpieczenie przed bezpośrednim dostępem do plików PHP
<Files *.php>
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</Files>
Pozwala na dostęp do plików PHP tylko z lokalnego serwera.
11. Ochrona przed atakami DDoS poprzez limitowanie liczby połączeń
<Limit GET POST>
Order Allow,Deny
Allow from all
Deny from 192.168.0.0/24
</Limit>
Blokuje dostęp dla konkretnych adresów IP lub zakresów, które mogą być źródłem ataku.
12. Ochrona przed indeksowaniem katalogów
Options -Indexes
Wyłącza automatyczne wyświetlanie zawartości katalogów, jeśli nie ma w nich plików indeksowych (np. index.html
).
13. Ochrona przed dostępem do katalogów zdefiniowanych przez CMS (np. WordPress)
# Blokowanie dostępu do wp-config.php
<Files wp-config.php>
Order Allow,Deny
Deny from all
</Files>
# Blokowanie dostępu do katalogu wp-includes
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-includes/ - [F,L]
</IfModule>
Blokowanie dostępu do kluczowych plików WordPress, które mogą być celem ataków.
14. Wymuszenie HTTPS
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Automatycznie przekierowuje wszystkie zapytania HTTP na HTTPS, co zabezpiecza transmisję danych.
15. Wymuszenie mocnej polityki HSTS (HTTP Strict Transport Security)
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Wymusza korzystanie z HTTPS przez przeglądarki na okres jednego roku (31536000 sekund), włączając wszystkie subdomeny.
16. Blokowanie hotlinkowania
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?twojadomena\.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [F,NC,L]
Zapobiega hotlinkowaniu obrazków i innych zasobów z serwera, co chroni przed nadmiernym wykorzystaniem zasobów.
Oczywiście! Oto kolejne przykłady dyrektyw zabezpieczających, które można dodać do pliku .htaccess
, aby dodatkowo zwiększyć bezpieczeństwo strony:
17. Zabezpieczenie przed atakami SQL Injection
<IfModule mod_rewrite.c>
RewriteEngine On
# Blokowanie prób SQL Injection
RewriteCond %{QUERY_STRING} (\%27)|(\')|(\-\-)|(\%23)|(#) [NC,OR]
RewriteCond %{QUERY_STRING} (\%28)|(\()|(\%29)|(\)) [NC,OR]
RewriteCond %{QUERY_STRING} union [NC,OR]
RewriteCond %{QUERY_STRING} select.*from [NC,OR]
RewriteCond %{QUERY_STRING} insert.*into [NC,OR]
RewriteCond %{QUERY_STRING} drop.*table [NC]
RewriteRule ^(.*)$ - [F,L]
</IfModule>
Ta reguła blokuje próby ataków SQL Injection, wyłapując niebezpieczne zapytania w parametrach URL.
18. Ograniczenie wielkości żądań HTTP (Max Request Body Size)
LimitRequestBody 1024000
Ustawia maksymalny rozmiar żądania HTTP, co może zapobiegać atakom DoS polegającym na wysyłaniu dużych zapytań.
19. Ochrona przed złośliwymi botami i skanerami
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^BadBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EvilScanner [NC]
RewriteRule .* - [F,L]
</IfModule>
Blokuje dostęp dla konkretnych botów na podstawie nagłówka User-Agent
.
20. Zabezpieczenie przed atakami poprzez przesyłanie plików
<FilesMatch "\.(php|php3|php4|php5|phtml)$">
Order Deny,Allow
Deny from all
</FilesMatch>
<FilesMatch "\.(jpg|jpeg|png|gif)$">
Order Allow,Deny
Allow from all
</FilesMatch>
Blokuje wykonywanie plików PHP, które mogłyby zostać przesłane na serwer przez atakującego (np. przez formularz przesyłania plików).
21. Zabezpieczenie pliku xmlrpc.php
w WordPress
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
Blokuje dostęp do pliku xmlrpc.php
, który może być celem ataków brute force i DoS, zwłaszcza w instalacjach WordPressa.
22. Zablokowanie dostępu do folderów niepublicznych
<Directory "/path/to/private_folder">
Order Deny,Allow
Deny from all
</Directory>
Umożliwia zablokowanie dostępu do określonych katalogów, takich jak foldery z danymi, logami czy backupami.
23. Ochrona przed atakami typu Directory Traversal
RewriteEngine On
RewriteCond %{REQUEST_URI} (\.\./|\.\.\\) [NC]
RewriteRule ^ - [F,L]
Blokuje próby eksploracji katalogów w górę struktury plików za pomocą sekwencji ../
.
24. Ochrona przed próbami eksploatacji serwera (Remote File Inclusion)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} (\.\./|\.\.\\|\.\.\\|\.\.|%00|https?:|data:|ftp:) [NC]
RewriteRule ^(.*)$ - [F,L]
</IfModule>
Blokuje potencjalne próby ataków związanych z wczytywaniem zewnętrznych zasobów na serwerze poprzez parametry w zapytaniu URL.
25. Zablokowanie dostępu do niektórych typów plików (np. logów, danych)
<FilesMatch "\.(log|sh|ini|bak|psd|sql|swp)$">
Order Allow,Deny
Deny from all
</FilesMatch>
Blokuje dostęp do plików o rozszerzeniach, które mogą zawierać dane wrażliwe, takie jak logi, kopie zapasowe, czy pliki konfiguracyjne.
26. Zabezpieczenie przed manipulowaniem nagłówkami HTTP (Security Headers)
Header set Referrer-Policy "no-referrer-when-downgrade"
Header set X-Download-Options "noopen"
Header set X-DNS-Prefetch-Control "off"
Ustawia dodatkowe nagłówki, które kontrolują politykę prywatności odniesień, blokują automatyczne otwieranie plików do pobrania oraz zapobiegają prefetchingowi DNS.
27. Wymuszenie odpowiedniego zarządzania plikami JSON i XML
<FilesMatch "\.(json|xml)$">
Order Allow,Deny
Deny from all
</FilesMatch>
Blokuje dostęp do plików JSON i XML, które mogą zawierać dane, takie jak konfiguracje lub dane użytkowników.
28. Zablokowanie dostępu na podstawie adresu IP (whitelist/blacklist)
Blokada IP
<RequireAll>
Require not ip 192.168.1.100
Require not ip 192.168.1.101
</RequireAll>
Dopuszczenie IP (whitelist)
<RequireAll>
Require ip 192.168.1.100
Require ip 192.168.1.101
</RequireAll>
Możliwość blokowania lub dopuszczania dostępu do strony z określonych adresów IP.
29. Ograniczenie wielkości przesyłanych plików (Upload Limits)
php_value upload_max_filesize 10M
php_value post_max_size 12M
Ustawia maksymalny rozmiar przesyłanych plików oraz danych POST, co może zapobiec atakom opartym na przesyłaniu dużych plików na serwer.
30. Wymuszenie silniejszego szyfrowania (TLS)
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite HIGH:!aNULL:!MD5
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Wymusza korzystanie z nowoczesnych protokołów szyfrowania (TLSv1.2 i wyżej), blokując przestarzałe, słabe protokoły, takie jak SSLv3.
31. Ograniczenie dostępu do panelu administracyjnego (np. WordPress)
<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from 192.168.1.100
</Files>
Zabezpiecza plik logowania do panelu administracyjnego, dopuszczając dostęp jedynie z określonych adresów IP.
32. Blokowanie metod HTTP DELETE, TRACE, OPTIONS i inne
<Limit DELETE TRACE TRACK OPTIONS>
Order Deny,Allow
Deny from all
</Limit>
Blokuje metody HTTP, które nie są potrzebne na stronie, ale mogą być wykorzystane przez atakujących.
Wprowadzanie zmian w pliku .htaccess
wymaga ostrożności, ponieważ niewłaściwa konfiguracja może spowodować problemy z funkcjonowaniem strony internetowej lub jej dostępnością. Nie każda z opisanych dyrektyw jest niezbędna dla każdej witryny – ich dobór powinien być uzależniony od specyfiki strony, jej funkcji, używanego oprogramowania oraz poziomu zagrożeń, z jakimi może się spotkać. Zbyt rygorystyczne ustawienia mogą prowadzić do ograniczenia funkcjonalności strony lub problemów z dostępem dla użytkowników, dlatego każda zmiana powinna być przemyślana i testowana przed wdrożeniem w środowisku produkcyjnym.
0 komentarzy