Detecting Incoming BW Tests

ammar83 · Sat May 27, 2017 10:48 am

Hello All,

I've been consulted to detect the actual BW consumption of a Network and report should a BW Expansion is needed. A friend of mine, suspects that his ISP is not giving him the whole BW he has agreed on which is the BW he is paying for. Instead, they compensate for the BW shortage by using BW test (Dirty Trick!

) sometimes at peak hours from multiple strange routers on their network so he can still see the amount of BW agreed on at his up-link interface, but actually he notices very slow internet speed internally similar to what happens if he has consumed the whole BW. His agreement with the ISP states that he should provide the ISP Support with an account in order to trouble shoot once a customer (my friend in this case) reports an issue.

I need a Mechanism through which I can detect when someone is using that account to make BW Test to a specific router. I have configured an E-MAIL notification should a specific event occurred and the Logs printed that out. I've also installed a Syslog-sensor on PRTG monitoring System that can receive logs from that router and can notify someone via e-Mails and SMS should something wrong happened.. Is there any work around I can detect and LOG BW test login?

Thanks

..

pukkita · Sat May 27, 2017 12:10 pm

Do you mean mikrotik BW-Test?

A possible way would be L7...

BW-Test uses UDP starting from port 2000 so you could just look at connection tracking table.

However...

Instead, they compensate for the BW shortage by using BW test (Dirty Trick! ) sometimes at peak hours from multiple strange routers on their network so he can still see the amount of BW agreed on at his up-link interface, but actually he notices very slow internet speed internally similar to what happens if he has consumed the whole BW. His agreement with the ISP states that he should provide the ISP Support with an account in order to trouble shoot once a customer (my friend in this case) reports an issue.

Fellow forum users graciously made available publicly accesible BW-Test servers that you can use to truly test BW, there are also more specifics regarding how to firewall etc BW-Test so it may help you having a look at the whole thread.

I would advice your customer to start looking for an alternate ISP... and also not to sign any fishy agreements like the present one, in fact it should have scared him away of that ISP without even contracting anything.

ammar83 · Sun May 28, 2017 11:58 am

Hi pukkita,

Thanks for your feedback

. You mentioned something about using Layer 7 .. How would you suggest approaching that

? It would be rather helpful I think..

Yes, I needed a mechanism so the router logs when anyone tries to use bw test towards the router. Today and after seeing your response, I figured out how to go around that.. Authentication must take place before the actual traffic will be flooded so that TCP connection have to be established first. I tried to mangle incoming TCP traffic to the IP of the Router (x.x.x.x), dst-port=2000, and I was able to mark related connection and log that.

chain=input action=mark-connection new-connection-mark=BWTESTLOG_CONNECTION passthrough=yes protocol=tcp dst-address=x.x.x.x in-interface=ether5 dst-port=2000 log=yes log-prefix="BWTESTLOG"

Alternatively, a Filter can do the same:

chain=input action=accept connection-state=new protocol=tcp dst-address=x.x.x.x in-interface=ether5 dst-port=2000 log=yes log-prefix="BWTESTLOG"

Then I had a script searching the logs for new entries having "BWTESTLOG" every 15 seconds and send a notification e-mail upon detecting that this will notify the Customer when there is an unplanned BW test. However, I still need to know how much bandwidth is thrown to the router should BW test occurs. I've not figured out how to mark connections and packets for the real UDP traffic (so I can add it in an unlimited Queue) because the source and destination ports are changing continuously. Any Ideas?

Thanks Again..

pukkita · Sun May 28, 2017 1:19 pm

I've not figured out how to mark connections and packets for the real UDP traffic (so I can add it in an unlimited Queue) because the source and destination ports are changing continuously. Any Ideas?

For TCP, you can use Ip > Firewall > Mangle connection marking/packet marking to achieve this. Instead of just accepting the connection, mark it; ROS will do the "magic" to track the connection even if different ports are used by leveraging conntrack:

/ip firewall mangle
add chain=input action=mark-connection new-connection-mark=BWTEST packet-mark=no-mark connection-state=new protocol=tcp dst-address=x.x.x.x in-interface=ether5 dst-port=2000 log=yes log-prefix="BWTESTLOG" \
comment="Mark Connections to BW Test server - TCP"
add chain=input action=mark-packet connection-mark=BWTEST new-packet-mark=BWTEST_P passthrough=no \
comment="Mark all packets from previous connections"

First we mark the connection, then we mark all packets pertaining to that connection.

Now that its packets are marked, you can use queues with packet-mark=BWTEST_P

For UDP... have a look at that thread. However TCP is the test done usually.

ammar83 · Mon May 29, 2017 9:26 am

Hi There pukkita,

I did exactly since I posted my last response and I was expecting that ROS will track packets that are related to that connection but it didn't!

[symon@ROS] /ip firewall mangle> print

chain=input action=mark-connection new-connection-mark=BWTESTLOG_TCP_CONNECTION passthrough=yes connection-state=new protocol=tcp dst-address=x.x.x.x interface=ether5 dst-port=2000 connection-mark=no-mark log=yes log-prefix="BWTESTLOG_TCP" 

chain=input action=add-src-to-address-list address-list=BW_TEST_ADDRESS_LIST address-list-timeout=3d connection-mark=BWTESTLOG_TCP_CONNECTION log=no log-prefix="" 

chain=input action=mark-packet new-packet-mark=BWTESTLOG_TCP_PACKETS passthrough=no connection-mark=BWTESTLOG_TCP_CONNECTION log=no log-prefix="" 

[symon@ROS] /queue tree> print
name="BWTESTLOG_TCP_QUEUE" parent=global packet-mark=BWTESTLOG_TCP_PACKETS limit-at=0 queue=default priority=8 max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s

The queue reads only a few kilobytes while I was throwing around 95 Mbps. I am using UDP protocol in Bandwidth Test. May be it is establishing a new Connection to pass UDP traffic? do you suggest?

Thanks in advance..

pukkita · Mon May 29, 2017 10:44 am

That's the reason, UDP won't be marked by those mangling rules as there's no initial UDP connection, but TCP.

Did some testing and had a look at a packet capture, the src-port for UDP to be 2001 for the first BW-test, 2002 for the next, and so on, so we'd better not use that to mark UDP.

Marking UDP is tricky, as the first connection is TCP, then the UDP streaming starts, so we cannot use conntrack to directly relate the two on a single mangle rule to mark a new connection, as that won't happen with UDP; but, we can still use that in our advantage:

1.- On initial TCP connection (done by both TCP/UDP) add the IP initiating the BW test to an address list
2.- Check that address list when marking BW Test UDP Tx/Rx traffic:

/ip firewall mangle
add chain=input dst-port=2000 packet-mark=no-mark protocol=tcp action=add-src-to-address-list \
address-list=BW_TEST_ADDRESS_LIST address-list-timeout=1h 

add chain=prerouting connection-state=new dst-port=2000 packet-mark=no-mark protocol=tcp \
action=mark-connection new-connection-mark=BWTEST log=yes log-prefix=BWTESTLOG_TCP  passthrough=yes 

add chain=prerouting protocol=udp packet-mark=no-mark  src-address-list=BW_TEST_ADDRESS_LIST \
action=mark-connection  new-connection-mark=BWTEST  passthrough=yes comment="ROS UDP Rx Test"

add chain=output protocol=udp packet-mark=no-mark  dst-address-list=BW_TEST_ADDRESS_LIST \
action=mark-connection  new-connection-mark=BWTEST  passthrough=yes comment="ROS UDP Tx Test"

add  chain=prerouting connection-mark=BWTEST action=mark-packet new-packet-mark=BTEST_P passthrough=no comment="ROS Rx BW Test "
add  chain=output connection-mark=BWTEST action=mark-packet new-packet-mark=BTEST_P passthrough=no comment="ROS Tx BW Test"

ammar83 · Tue May 30, 2017 1:00 pm

Thanks for your help pukkita,

I was able to track them using your script with a few more touches.. here is the final script

[symon@ROS] /ip firewall mangle> print
 chain=prerouting action=add-src-to-address-list connection-state=new protocol=tcp address-list=BW_TEST_ADDRESS_LIST address-list-timeout=1h in-interface=ether5-Public dst-port=2000 packet-mark=no-mark log=no log-prefix="" 
 chain=prerouting action=mark-connection new-connection-mark=BWTEST passthrough=yes connection-state=new protocol=tcp dst-address=x.x.x.x dst-port=2000 packet-mark=no-mark log=yes log-prefix="BWTESTLOG_TCP" 
;;; ROS UDP Rx Test
      chain=prerouting action=mark-connection new-connection-mark=BWTEST_RX passthrough=yes protocol=udp src-address-list=BW_TEST_ADDRESS_LIST packet-mark=no-mark log=no log-prefix="" 
;;; ROS UDP Tx Test
      chain=output action=mark-connection new-connection-mark=BWTEST_TX passthrough=yes protocol=udp dst-address-list=BW_TEST_ADDRESS_LIST packet-mark=no-mark log=no log-prefix="" 
;;; ROS Rx BW Test 
      chain=prerouting action=mark-packet new-packet-mark=BTEST_P_RX passthrough=no connection-mark=BWTEST_RX log=no log-prefix="" 
;;; ROS Tx BW Test
      chain=output action=mark-packet new-packet-mark=BTEST_P_TX passthrough=no connection-mark=BWTEST_TX log=no log-prefix="" 

 [symon@ROS] queue simple print
name="BWTEST_Q_RX" target=ether5-Public parent=none packet-marks=BTEST_P_RX priority=8/8 queue=default/default limit-at=0/0 max-limit=0/0 burst-limit=0/0  burst-threshold=0/0 burst-time=0s/0s 
name="BWTEST_Q_TX" target=ether5-Public parent=none packet-marks=BTEST_P_TX priority=8/8 queue=default/default limit-at=0/0 max-limit=0/0 burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s

Thanks again for your Help..

pukkita · Tue May 30, 2017 1:50 pm

glad it helped

Detecting Incoming BW Tests

Detecting Incoming BW Tests

Re: Detecting Incoming BW Tests

Re: Detecting Incoming BW Tests

Re: Detecting Incoming BW Tests

Re: Detecting Incoming BW Tests

Re: Detecting Incoming BW Tests

Re: Detecting Incoming BW Tests

Re: Detecting Incoming BW Tests