Konfiguracja MikroTik — Część 62: MikroTik jako Transparentny Serwer Proxy HTTPS z Obsługą Transparent TLS Inspection i Kontroli Ruchu Aplikacyjnego
Konfiguracja MikroTik — Część 62: MikroTik jako Transparentny Serwer Proxy HTTPS z Obsługą Transparent TLS Inspection i Kontroli Ruchu Aplikacyjnego
Wprowadzenie
W nowoczesnych sieciach coraz częściej zachodzi potrzeba monitorowania i kontroli ruchu HTTPS. Szyfrowanie TLS, chociaż poprawia bezpieczeństwo, utrudnia administratorom sieci monitorowanie i inspekcję ruchu wychodzącego. MikroTik RouterOS, w połączeniu z odpowiednimi narzędziami zewnętrznymi, może pełnić funkcję transparentnego proxy HTTPS z mechanizmami analizy i kontroli aplikacyjnej, pozwalając administratorom na pełne zarządzanie ruchem wychodzącym, nawet tym zaszyfrowanym.
W tej części serii omówimy, jak skonfigurować MikroTik jako bramę transparentną dla HTTPS z przekierowaniem ruchu do serwera Proxy/SSL Inspection, jak korzystać z policy routing i jak skutecznie zarządzać dostępem w sieci korporacyjnej.
Krok 1 — Koncepcja Transparent Proxy dla HTTPS
Ze względu na specyfikę protokołu TLS, MikroTik nie może natywnie deszyfrowywać ruchu HTTPS. Jednak może działać jako transparentna brama, przekierowując ruch HTTPS do dedykowanego serwera Proxy/SSL Inspection, np. Squid z SSL Bump lub rozwiązania typu Blue Coat czy FortiProxy.
Scenariusz:
- MikroTik przekierowuje ruch HTTPS na serwer Proxy/SSL Inspection
- Serwer Proxy wykonuje SSL Inspection i forwarduje ruch do internetu
- MikroTik zarządza routingiem i ACL
Krok 2 — Przekierowanie ruchu HTTPS do Proxy
Przykładowa konfiguracja przekierowania ruchu HTTPS do lokalnego Proxy na porcie 3129:
/ip firewall nat
add chain=dstnat protocol=tcp dst-port=443 action=dst-nat to-addresses=192.168.100.50 to-ports=3129 comment="Redirect HTTPS to Proxy"
Uwaga:
W przypadku ruchu HTTPS konieczna jest akceptacja lub dystrybucja zaufanego certyfikatu root użytkownikom końcowym, ponieważ SSL Inspection działa w trybie MITM (Man-in-the-Middle).

Krok 3 — Wykorzystanie Policy Routing dla Proxy
Jeżeli korzystasz z kilku segmentów sieci i chcesz, aby tylko określony ruch przechodził przez Proxy, użyj policy routing:
/ip route
add gateway=192.168.100.50 routing-mark=to_proxy
/ip firewall mangle
add chain=prerouting src-address=192.168.1.0/24 protocol=tcp dst-port=443 action=mark-routing new-routing-mark=to_proxy passthrough=yes
Krok 4 — Kontrola Aplikacji za pomocą L7 i Firewall
Chociaż MikroTik nie posiada natywnej inspekcji HTTPS, można ograniczać dostęp na poziomie DNS lub adresów IP oraz protokołów L7:
/ip firewall layer7-protocol
add name=youtube regexp="^.+(youtube.com|ytimg.com).*\$"
/ip firewall filter
add chain=forward layer7-protocol=youtube action=drop comment="Block YouTube"
Krok 5 — Monitoring i Logowanie Przekierowanego Ruchu
Możesz monitorować przekierowywany ruch z wykorzystaniem systemu logowania MikroTik:
/ip firewall filter
add chain=forward protocol=tcp dst-port=443 action=log log-prefix="HTTPS Proxy"
Krok 6 — Integracja z Proxy Systemem Monitoringu
Serwer Proxy, taki jak Squid z SSL Bump, może być integrowany z:
- SIEM (np. Wazuh, Splunk)
- LDAP/AD dla autoryzacji użytkowników
- Systemami raportowania i filtracji treści
Krok 7 — Wydajność i Ograniczenia
Pamiętaj, że:
- MikroTik nie deszyfruje ruchu HTTPS — pełni funkcję routera/przełącznika
- Całkowite deszyfrowanie wymaga zewnętrznych narzędzi
- SSL Inspection powinien być stosowany zgodnie z polityką prywatności firmy
Zastosowania Transparent HTTPS Proxy z MikroTik
- Egzekwowanie polityki bezpieczeństwa w korporacji
- Monitorowanie nieautoryzowanego ruchu HTTPS
- Integracja z systemami DLP (Data Loss Prevention)
- Ochrona przed nieautoryzowanymi usługami w sieci
Podsumowanie
MikroTik w połączeniu z transparentnym proxy HTTPS pozwala zbudować potężne centrum zarządzania ruchem w sieci, zapewniając kontrolę nad protokołami szyfrowanymi. Dzięki temu organizacje mogą wdrażać polityki bezpieczeństwa, monitorować ruch i zapobiegać zagrożeniom w czasie rzeczywistym, nie rezygnując z wydajności sieci LAN/WAN.






