Konfiguracja MikroTik — Część 51: MikroTik jako Transparentny Proxy HTTP/S z Kontrolą Dostępu i Integracją z SIEM
Konfiguracja MikroTik — Część 51: MikroTik jako Transparentny Proxy HTTP/S z Kontrolą Dostępu i Integracją z SIEM
Wprowadzenie
W dobie rosnącego ruchu HTTPS oraz konieczności kontroli dostępu do zasobów sieciowych, administratorzy coraz częściej szukają rozwiązań, które pozwolą na przechwytywanie, analizę oraz kontrolę ruchu HTTP/S bez ingerencji w konfigurację końcowych użytkowników.
W tej części serii pokażemy, jak skonfigurować MikroTik jako Transparentny Proxy z funkcjami monitoringu i podstawowej inspekcji pakietów, zintegrowany z systemem SIEM, aby zapewnić pełną widoczność i kontrolę ruchu sieciowego w małych i średnich środowiskach.
Założenia
- MikroTik RouterOS (preferowana wersja 7.x z FastTrack wyłączonym dla analizowanego ruchu)
- Użytkownicy podłączeni bezpośrednio do routera lub poprzez bridge
- External Proxy/Proxy Cache (np. Squid, ICAP) za MikroTik dla pełnego proxy HTTPS
- SIEM z obsługą Syslog lub API (np. Wazuh, Graylog, Splunk)
Krok 1 — Wstępna konfiguracja przekierowania ruchu HTTP
/ip firewall nat
add chain=dstnat protocol=tcp dst-port=80 action=redirect to-ports=8080
To przekierowuje cały ruch HTTP na port lokalnego proxy (może być Squid na porcie 8080).

Krok 2 — Kontrola ruchu HTTPS (SNI-based i TCP ACK)
Ponieważ MikroTik nie wspiera pełnego proxy HTTPS (brak terminacji TLS), możesz wykorzystać Layer7 Protocol do podstawowego filtrowania SNI lub używać Proxy TLS pod Linuksem za NAT-em:
/ip firewall layer7-protocol
add name=tls_google regexp="^.+\\.google\\.com\$"
/ip firewall filter
add chain=forward protocol=tcp dst-port=443 layer7-protocol=tls_google action=drop
Krok 3 — Przekazywanie logów do SIEM (Syslog, JSON API)
Syslog klasyczny:
/system logging
add action=remote topics=firewall
/system logging action
add name=remote target=remote remote-address=192.168.100.100 remote-port=514
Integracja JSON API do SIEM (przykład z Python):
import requests
response = requests.get('http://192.168.88.1/rest/ip/firewall/filter')
print(response.json())
Krok 4 — Monitorowanie Ruchu HTTP/S przez Torch i Traffic Flow
/tool torch interface=ether2 src-port=80
/tool traffic-flow
set enabled=yes interfaces=ether2 cache-entries=128
/tool traffic-flow target
add address=192.168.100.200 port=2055 version=9
Krok 5 — Ograniczanie dostępu na poziomie aplikacji
MikroTik pozwala na stosowanie reguł L7 oraz list adresów:
/ip firewall address-list
add address=example.com list=blocked_sites
/ip firewall filter
add chain=forward dst-address-list=blocked_sites action=drop
Krok 6 — Połączenie z External Proxy przez Policy Routing
/ip route
add dst-address=0.0.0.0/0 gateway=192.168.99.1 routing-table=use-proxy
/ip firewall mangle
add chain=prerouting protocol=tcp dst-port=80 action=mark-routing new-routing-mark=use-proxy
Krok 7 — Automatyzacja zgłaszania incydentów do SIEM
Przykład w Python (Webhook do SIEM):
import requests
payload = {"event":"Blocked HTTP Access", "source_ip":"192.168.1.10"}
requests.post('http://siem.local/api/events', json=payload)
Przykładowe Scenariusze Użycia
| Scenariusz | Cel | Mechanizm |
|---|---|---|
| Przechwycenie HTTP do analizy | Kontrola treści | NAT Redirect |
| Detekcja nieautoryzowanych HTTPS | Blokada dostępu | L7 + Filter |
| Logowanie ruchu | Audyt | Syslog + Traffic Flow |
| Wysyłka alertów do SIEM | Monitoring | Python API |
| Routing przez proxy zewnętrzne | Filtrowanie | Policy Routing |
Podsumowanie
Transparentny Proxy na MikroTik to niepełna, ale bardzo użyteczna metoda przechwytywania i kontrolowania ruchu sieciowego — szczególnie HTTP. W połączeniu z External Proxy, Traffic Flow, Firewall i integracją z SIEM, tworzy realne rozwiązanie do zarządzania i monitoringu w środowiskach SOHO i SMB.
Choć MikroTik nie zastąpi pełnoprawnego Next-Gen Proxy, jego możliwości w połączeniu z automatyzacją dają spore pole do popisu dla administratorów i integratorów systemów bezpieczeństwa.






