Managing TikTok traffic with MikroTik – what’s the best approach?

RouterOS General
1

I’ve been noticing that TikTok traffic has started consuming a big chunk of bandwidth on our network, especially during peak hours. I know some admins shape or limit it, while others try more advanced filtering or even allow it freely depending on policy.

Recently, I’ve also seen traffic coming from TikTok 18, which seems to be an modified version of the app. Since it isn’t verified like the main TikTok, I’m not sure if it behaves differently on the network side or if it raises extra concerns in terms of security and bandwidth usage.

For those of you who have dealt with this, what methods have worked best on MikroTik for handling TikTok traffic (including variants like TikTok 18)? Do you rely on layer7 filters, address lists, or maybe DPI with third-party tools? Also, how do you balance between controlling bandwidth usage and not frustrating users who rely on the app?

2

Hi,

no way as Mikrotik is not designed to inspect traffic.

3

As per Bartoszp, you cannot fix social issues with MT equipment.
You have two options, spend $$$ to get a router with subscriptions that can monitor HTTPS type traffic.
OR use accountability. Employees found using TikTock first time are fined $1000 and receive addiction counselling, next time 10,0000 and final warning, and third strike fired. Those employees turning in other employees, first time receive $1000, next time 5,000 and third time 10,000 ( max of three payments to any individual )

4

A solution: You could filter it completely based on umbrella openDNS, if you have full control over DNS traffic, you could block all DNS traffic through your router except umbrella openDNS servers. It has free and payware versions also.
If your goal is shaping or policing TikTok traffic, you should use an expensive NGFW, as anav said.

Edit: https://www.opendns.com/

5

https://www.imdb.com/it/title/tt0079470/quotes/?item=qt0471984&ref_=ext_shr_lnk

6

If your concern is truly bandwidth related, and *not* blocking or preventing tiktok (or any other types of traffic), then you might investigate PCQ or even cake interface queues, to allocate your available internet bandwidth in a more "fair" manner overall.

Edit: If it turns out you do wish to totally block TikTok or some other applications, then just drop a snort or suricata box inline on the lan side. I’ve found that Snort’s openappid does a pretty good job, for free even.

7

Snort is like some other "faux IDP" solutions that do not inspect inside https traffic. Its a non-starter.
Try something real that uses code and logic :stuck_out_tongue_winking_eye: , like fortigate with subscriptions.....

8

Sure, I’m all ears if you care to explain further how snort won’t block TikTok.

9

I dont really care about tik tok. Dont use it, I have a life. What I care about is functionality that will deliver on promises.
As most if not all top end social media platforms evolve they have gotten into the https or other ways of sending traffic to avoid basic blocking techniques.

By default, Snort

cannot examine the contents (payload) of encrypted packets like those on port 443 (HTTPS) because it lacks the session keys necessary for decryption. It primarily inspects metadata and the initial handshake to make limited detections.

In more detail........

How Snort Handles Encrypted Traffic

Metadata and Handshake Inspection: Snort's SSL preprocessor (SSLPP) is designed to inspect the unencrypted portions of the SSL/TLS handshake. This allows it to:
    Identify the SSL/TLS version being used (e.g., TLS 1.2, TLS 1.3).
    Check the state of the connection (e.g., client_hello, server_hello).
    Use this metadata for basic anomaly detection, such as the Heartbleed attack, by checking record lengths during the handshake.
    Identify general application types based on port and handshake patterns (e.g., distinguishing HTTPS from other services on port 443).
Payload Invisibility: Once the handshake is complete and the actual application data is encrypted, Snort cannot perform deep packet inspection (DPI) on the payload without an external mechanism to decrypt the traffic. The data within the encrypted tunnel remains opaque to the IDS.

Solutions for Inspecting Encrypted Traffic
To inspect the actual content of encrypted traffic, a "man-in-the-middle" (MitM) setup or SSL/TLS decryption is required, typically performed by a dedicated device (like a firewall, proxy, or specific security appliance) placed in the traffic path.

SSL Offloading/Decryption: In a network with SSL termination, an external proxy (e.g., HAProxy) decrypts the traffic, passes the unencrypted data to Snort for inspection, and then re-encrypts it before sending it to its final destination.
Endpoint Inspection: The most reliable way to inspect all traffic is at the endpoints (the clients or servers themselves), where the data is in its clear-text form before encryption or after decryption.

In summary, Snort alone only examines the envelope of the encrypted packet, not the letter inside, unless a separate decryption solution is implemented.

Now go visit a real router aka Fortigate......... and by the way you need to pay for additional subscription services so its going to cost an arm and a leg.
https://www.youtube.com/watch?v=oXLzq-K3J3w