[ Megoldva by hzsolt94 ] Mikrotik HTTPS

Hálózatok általános

Sziasztok!

Az alábbi feladatra keresek megoldást.
Adott egy oktatási terem, ahol Wifin keresztül lépnek fel a megadott oldalra. A http kéréseket elfogja a Mikrotik web proxy és átdobja az oktatóanyag elérhetőségére.
Ez működött eddig gond nélkül.
Viszont az oktatóanyagot tartalmazó oldal egy része áttért https-re.
Az oldal nevére kb. 6 ip cím kerül feloldásra.

Https-en keresztül, csak ennek kellene mennie.
Amivel eddig próbálkoztam, sikertelenül:
- web proxy: nem tud https-t
- firewall filter content-be weboldal domain : nem veszi figyelembe
- layer7: nem néz bele a https forgalomba
- "kókány" scipt, ami felveszi a domain ip címeit address list-be, azán egy tűzfalszabály engedi a Dst. address list-et 443 fele a forward láncban: nem megy

Valakinek valami ötlete?
(Ez a Mikrotik adott, nem lehet proxy szervert, vagy más tűzfalat berakni)

  • 6974 megtekintés

( hzsolt94 v | 2016. 01. 10., v – 13:29 )

A peremfeltételek mellett két dologra van esélyed:

Layer7 szűrővel belenézni a https forgalomnál az SNI-be (ez még nem titkosított), és ez alapján megjelölni a kapcsolatot engedélyezettnek, a későbbiekben pedig kiengedni.
A weboldal IP címeit engedélyezni - nem derül ki a hozzászólásodból hogy ez miért nem megy, mert ennek kellene.

Átirányítást vagy hasonlót proxy-szerver nélkül nem tudsz csinálni.

Köszi, megnézem.

"A weboldal IP címeit engedélyezni - nem derül ki a hozzászólásodból hogy ez miért nem megy, mert ennek kellene."
Szerintem törlöm az összes tűzfal szabályt, mert más semmi sem megy.

"Layer7 szűrővel belenézni a https forgalomnál az SNI-be"
Erre egy példa layer7 weboldal névvel?

http://bfy.tw/3eom https://rbgeek.wordpress.com/2012/05/29/how-to-block-facebook-in-mikrot…

A lényeg hogy az layer7 szűrő csak az első 10 csomag valamelyikére fog illeszkedni, ezért úgy kell összerakni a tűzfalszabályokat hogy megjegyezd melyik kapcsolat illeszkedett, és azt utána is átengedd.

Sajnos konkrétan erre a feladatra még nem használtam mikrotiket, de ha elárulod a site nevét csinálok rá egy teszt konfigot. Úgy sejtem azzal lesz gond hogy minden forgalmat engedni kell addig amíg el nem jut az SNI-ig, utána pedig szétválogatni és megjegyezni az átengedetteket.

Nem akarom rabolni az idődet...

Az a furcsa, hogy a mangle ágban megjelölöm a kapcsolatot és a csomagot is.
Ez megy szépen http, ftp esetén.
Viszont https-nél nem érvényesül.

Az oldal mindegy,pl: twitter.com.

twitter.com. 19 IN A 199.16.156.70
twitter.com. 19 IN A 199.16.156.102
twitter.com. 19 IN A 199.16.156.38
twitter.com. 19 IN A 199.16.156.230

Nos, megcsináltam neked :-)

A probléma: át kell engedned minden HTTPS forgalmat mindaddig amíg a kliens el nem jut az SNI-ig, különben nincs mire L7 szűrnöd. Tehát nem tilthatod le a tcp:443-at. Az SNI a TLS handshake előtt utazik, tehát akkor kellene tiltani
Megoldás: detektálni kell hogy a kliens a kívánt oldalra csatlakozik-e, és detektálni kell hogy elkezdett-e már titkosítva forgalmazni (TLS handshake)

Regex szűrő az oldaladhoz: .*example\.org.*
Regex szűrő a TLS handshakehez: ^\x16\x03[\0\x01\x02\x03]

Ezek után már csak 3 feladatod van.
Mangle ágban:
A TCP/443 kapcsolatokat megjelölöd TLS-OK -nak ha nincsenek megjelölve és megfelelő SNI-t találtál
A TCP/443 kapcsolatokat megjelölöd TLS-nek ha nincsenek megjelölve és handshake-et találtál (tehát nem volt megfelelő SNI)

Ezek után a forward ágban a TLS-t tiltod, a TLS-OK-t átengeded.

Megcsináltam, letszteltem, működik.

További probléma: Innentől kezdve ki lehet pl. SSH-zni 443-as porton, mert az nem fog TLS handshaket tartalmazni. Elkerülő megoldás: számláld a csomagokat, és ha X csomag után sem TLS-nek sem TLS-OK-nak nincs megjelölve, akkor is dobd el a kapcsolatot.

Ha segítségre van szükséged akkor írj.

A mai nap rohanás volt, most kezdem nézni az ötleted (egy factory-defaults-sal).
A twitterrel tesztelem, de a regexp valamiért nem az igazi.
Most ezzel nézem:
^.+(twitter).*\$

Eddig itt tartok:
/ip firewall layer7-protocol
add name=TLS_handsnake regexp="^\\x16\\x03[\\0\\x01\\x02\\x03]"
add name=L7_twitter.com regexp="^.+(twitter).*\\\$"

/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark dst-port=443 layer7-protocol=L7_twitter.com log=yes log-prefix=L7_twitter \
new-connection-mark=L7_twitter protocol=tcp
add action=mark-connection chain=prerouting connection-mark=no-mark dst-port=443 layer7-protocol=TLS_handsnake log=yes log-prefix=TLS new-connection-mark=\
TLS protocol=tcp

/ip firewall filter
add action=jump chain=forward comment="jump to chain fw_forward" jump-target=fw_forward
add action=drop chain=forward comment="Drop any forward connection"
add action=drop chain=fw_forward comment="drop invalid connections" connection-state=invalid protocol=tcp

add action=reject chain=fw_forward comment="TLS drop" connection-mark=TLS dst-port=443 protocol=tcp reject-with=tcp-reset
add chain=fw_forward comment="TLS-OK accept" connection-mark=L7_twitter dst-port=443 protocol=tcp
add chain=fw_forward dst-port=443 protocol=tcp
add chain=fw_forward dst-port=80 protocol=tcp
add chain=fw_forward comment="allow already established connections" connection-state=established
add chain=fw_forward comment="allow related connections" connection-state=related

Fontos hogy csak domainekre megy, urlekre nem, valamint hogy minden más domainről behívott https dolgot is vagy engedélyezel, vagy hiányozni fog. Ilyen szempontból a cdn-ek miatt a nagy oldalak elég rossz teszt-alanyok. Próbáld pl. A veremcsere.hu-val itt minimális a külső tartalom.

Ha megosztod velünk az oldal nevét, megnézem mire van szükség rajta.

az oldalatokkal elsőre : )

/ip firewall layer7-protocol
add name=TLS_handshake regexp="^\\x16\\x03[\\0\\x01\\x02\\x03]"
add name=L7_veremcsere.hu regexp=".*veremcsere\\.hu.*"

/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark dst-port=443 layer7-protocol=L7_veremcsere.hu log=yes log-prefix=L7_veremcsere \
new-connection-mark=L7_veremcsere protocol=tcp
add action=mark-connection chain=prerouting connection-mark=no-mark dst-port=443 layer7-protocol=TLS_handshake log=yes log-prefix=TLS new-connection-mark=\
TLS protocol=tcp

/ip firewall filter
add action=jump chain=forward comment="jump to chain fw_forward" jump-target=fw_forward
add action=drop chain=forward comment="Drop any forward connection"
add action=drop chain=fw_forward comment="drop invalid connections" connection-state=invalid protocol=tcp
add action=reject chain=fw_forward comment="TLS drop" connection-mark=TLS dst-port=443 protocol=tcp reject-with=tcp-reset
add chain=fw_forward comment="TLS-OK accept" connection-mark=L7_veremcsere dst-port=443 protocol=tcp
add chain=fw_forward dst-port=443 protocol=tcp
add chain=fw_forward dst-port=80 protocol=tcp
add chain=fw_forward comment="allow already established connections" connection-state=established
add chain=fw_forward comment="allow related connections" connection-state=related

Még nem teljesen értem, de működik. Köszönöm a megoldást.
Csak az oldalatokat nézve így is van TLS-drop, de ez más csak hangolás.

( uid_6201 v | 2016. 01. 11., h – 09:20 )

Eddig a Mikrotik DNS feloldásával korlátoztam hasonló esetekben SSL kapcsolatokat.
Köszönöm én is a tippet az SNI-ről, tanulságos.

( gigalomania v | 2018. 02. 03., szo – 17:40 )

Végre ... működik (IS)

New way to match websites in firewall

Since most of the internet now uses https, it has become much harder to filter specific web content. For this
reason, RouterOS 6.41 introduces a new firewall matcher which allows you to block https websites (TLS traffic)
based on the TLS SNI extension, called “TLS-HOST”. The new parameter supports glob-style patterns, which
should be enough for whatever you’re trying to match.

For example, to block example.com, you would use a rule like this:
/ip firewall filter add chain=forward dst-port=443 protocol=tcp tls-host=*.example.com action=reject

tls-host (string; Default: )
Allows to match https traffic based on TLS SNI hostname. Accepts GLOB syntax for wildcard matching. Note that matcher will not be able to match hostname if TLS handshake frame is fragmented into multiple TCP segments (packets).

What's new in 6.41.1 (2018-Jan-30 10:26):
firewall - fixed "tls-host" firewall feature (introduced v6.41);

: )))

https://download2.mikrotik.com/news/news_80.pdf

New way to match websites in firewall
Since most of the internet now uses https, it has become much harder to filter specific web content. For this
reason, RouterOS 6.41 introduces a new firewall matcher which allows you to block https websites (TLS traffic)
based on the TLS SNI extension, called “TLS-HOST”. The new parameter supports glob-style patterns, which
should be enough for whatever you’re trying to match.
For example, to block example.com, you would use a rule like this:
/ip firewall filter add chain=forward dst-port=443 protocol=tcp tls-host=*.example.com action=reject

én ezt teszteltem, működött tesztkörnyezetben

Azzal nekem sem akart menni ...

Ezzel teszteltem:

/ip firewall mangle
add action=mark-connection chain=prerouting dst-port=443 new-connection-mark=TLS-HOST_conn protocol=tcp tls-host=*.facebook.com passthrough=no
add action=mark-packet chain=prerouting connection-mark=TLS-HOST_conn new-packet-mark=TLS-HOST_packet passthrough=no

/ip firewall filter
add action=tarpit chain=forward out-interface=WAN1 packet-mark=TLS-HOST_packet protocol=tcp

( KicsiBocs | 2018. 02. 05., h – 19:21 )

Sajnos ezzel is továbbra is bejön a Facebook.

Pedig a Fasttrack elé tettem.

Frissítés: Fasttrack a ludas. Ha be van kapcsolva a Fasttrack, akkor bejön a Facebook, ha a Fasttrack ki van kapcsolva, akkor a mangle szabályos megoldással megy rendesen a Facebook tiltás. Nem jön be a Facebook. Nagy Köszönet a segítségért!

Frissítés2: A sima tls-host-os szabállyal is működik. De ekkor sem szabad a Fasttrack-nek bekapcsolva lennie.

https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack

IPv4 FastTrack handler is automatically used for marked connections. Use firewall action "fasttrack-connection" to mark connections for fasttrack. Currently only TCP and UDP connections can be actually fasttracked (even though any connection can be marked for fasttrack). IPv4 FastTrack handler supports NAT (SNAT, DNAT or both).

Note that not all packets in a connection can be fasttracked, so it is likely to see some packets going through slow path even though connection is marked for fasttrack. This is the reason why fasttrack-connection is usually followed by identical action=accept rule. Fasttracked packets bypass firewall, connection tracking, simple queues, queue tree with parent=global, ip traffic-flow(restriction removed in 6.33), IP accounting, IPSec, hotspot universal client, VRF assignment, so it is up to administrator to make sure fasttrack does not interfere with other configuration;

Akkor már csak megfelelően kell beállítani - azaz a kérdéses csomag NE kerüljön be fasttrack-be

Bocsánat, kicsit feléleszteném ezt a szálat!

A Fasttrack-el vagyok bajban magam is.
Adott egy UPC 500-as net. Modem üzemmódba raktam a fehér dobozukat, így DHCP-n kapom a netet.
2 hálózat van, s abból az egyiket szeretném szűrni plusz az internetet lassítani.

Már jó ideje próbálkozom sokmindennel, eddig 2 dolog közül csak 1-et választhatok.
Ha nincsen bekapcsolva a Fasttrack, akkor az internet maximális sebessége 90-100 Mbit.
Bekapcsolva 500 jön szépen.

Van valami megoldás, hogy Fasttrack-et csak WAN/internet felé alkalmazzak?
Köszönöm szépen a segítséget!

Azok a kapcsolatok kerülnek fasttrackre, amikre egyszer matchelt a fasttrack destination a tűzfalban. Értelemszerűen ezeket innen levenni már nem tudod, mert a további csomagjaik nem mennek át a tűzfalon.

Az alapértelmezett tűzfalszabályok között van egy, ami minden related,established állapotban lévő kapcsolatot fasttrackre tesz. Ezt vedd ki, és állíts be helyette sajátot, ami szigorúbban szűri hogy mi mehet fasttrackre.