Application Visibility : 6.0r2a : Bittorrent classification does not work as advertised

  • 2
  • Question
  • Updated 5 years ago
  • Answered
HMOL 6.02r a, AP170s, running HiveOS 6.0r2.1148 , User Profile trying to block BitTorrent and also for testing: Flickr and ICMP traffic.

IP Firewall Policy:
Access-From:
Access-To:
source any, dest any, app service Bittorrent, Deny
source any, dest any, app service Flickr, Deny
source any, dest any, app service ICMP, Deny
Default: Permit

So Transmission(bittorrent) belts away and continues to DL files and seed them so the BitTorrent blocking/identification doesn't work, also access to http://flickr.com *is* blocked appropriately and ICMP works too (i.e. is blocked) for part of the test.

Torrents these days are such an arms race that it's almost pointless as most traffic goes out as encrypted UDP? Does the application inspection look at hex in the binary chatter or just static ports? (Meraki can't block/shape torrents either even though they say they can).

Oh and additionally I'm not getting any app stats on the dashboard :(
Photo of irldexter

irldexter

  • 37 Posts
  • 1 Reply Like
  • very sad, frustrated

Posted 5 years ago

  • 2
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
It does look at data, not just ports.

As an abstract point, if a protocol is obfuscated and encrypted to the point that you cannot discern what it is, it will get through.

There is little to nothing that you can conceptually do about it short of white listing. Statistical analysis based methods often have a high false positive rate so are typically ill suited.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
To get application statistics, select each AP, hit modify and do a save without any changes. It should begin showing data shortly after that.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Also, have you updated the application signatures to 2.0.0?

(The latest software for your HiveAPs is also 6.0r2a, not that it should make a difference.)
Photo of irldexter

irldexter

  • 37 Posts
  • 1 Reply Like
Yup on APs, yup on sigs though on the second AP it will not update sigs :( I had tried the modify/save from previous thread but to no avail. I am now SSH'ing in to set "application reporting enable" manually and hope to see something.... perhaps I hit something on these AP170s? Even did a bootstrap reset and thinking about a "reset config" if I can't push the sigs.... so all in all one of them is v2 sigs and the other I'm still working on! Tks for response though and I agree with protocol arms race however on our VPS' we use pre-routing on IPTABLES with some successful pre-amble: https://docs.google.com/document/edit...
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
Just to be clear, did you assign that firewall policy only to To-Access? Or did you assign it to To-Access and From-Access? From-Access controls downloads (ie, from network to client).
Photo of irldexter

irldexter

  • 37 Posts
  • 1 Reply Like
Hiya, I tried both and as the ICMP and Flickr sites were blocked on just "To-Access", I left it on "To-Access", I will assign to both again however it's strange that 2 out of 3 would work in either scenario but that torrents were still working. The FW rule states SRC IP any , DST IP any.
Photo of Brian Ambler

Brian Ambler

  • 245 Posts
  • 126 Reply Likes
I was interested when you mentioned that we were not correctly classifying BitTorrent since I have seen torrent traffic correctly identified on my dashboard.

To confirm, I set up a simple firewall rule and ran a few tests.

My simple firewall rule blocking BitTorrent:
ip-policy no-bittorrent id 1 from 0.0.0.0 0.0.0.0 to 0.0.0.0 0.0.0.0 service L7-BITTORRENT action deny


For my first test I set up a from-access and to-access firewall, default action permit:


With the to/from firewall rule in place, I was unable to connect to peers with a new torrent (debian-6.0.7-amd64-DVD-1.iso.torrent from http://debian.org/distrib/) after trying for over 10 minutes (I validated this was a good, live torrent before applying the rule).


To confirm, I disabled the firewall rule on my AP120 running 6.0r2a (no ip-policy no-bittorrent) and I was able to connect to peers and begin downloading.


For good measure I tried the same test with only a to-access firewall rule in place:


This affected BitTorrent traffic in the same way. I was unable to connect to peers after 10 minutes of connecting with the rule enabled, but once I disabled the to-access rule I connected and began downloading the file.


What I did find was that if I enabled either rule while I was currently downloading the same torrent, my traffic was not affected. It would appear that we are effective at classifying and blocking BitTorrent traffic based on Application, but this does not apply to active sessions. I would be interested if there is any difference between your config and mine, as we seem to be getting opposite results.

Hope this helps
Photo of irldexter

irldexter

  • 37 Posts
  • 1 Reply Like
I tip my hat to the level of and comprehensive answer you have provided. I will try again and perhaps it is my 2x AP170s WAPs as 2 problems were presenting themselves. A) the "application reporting disabled" was not being removed from the local configs and B) one of the WAPs was refusing to upgrade its signature pack to v2.

My config was exactly the same as yours and I indeed noticed that one only needs to include the "To-Access" to have a rule block access to, for example ICMP etc... (note: it's a bit confusing to have both though and then have child policies that can specify SRC/DST too, however..) I will let you know as soon as I get the A) sorted (which I did via the CLI) and B) once I get access back to the second AP170 as they are currently offline as I am travelling in NZ.

Again kudos to the level of your answer (albeit I do wonder if debian uses non-standard port/encrypted peers/magnet/μTP links etc?)... perhaps a test with a not-so savoury torrent in the interests of science? :)
Photo of Brian Ambler

Brian Ambler

  • 245 Posts
  • 126 Reply Likes
It does appear that BitTorrent is included in the default 1.0.0 Application Signatures, so while updating to 2.0.0 is recommended, it shouldn't have any bearing on your APs capability to detect torrent traffic. Are you seeing traffic statistics for BitTorrent in your Application dashboard even when your firewalls do not seem to be blocking traffic?

Once I get home I will look into testing with other torrent sources/trackers as it is a valid point; generally the only torrent traffic I generate is from linux distro downloads.
Photo of Brian Ambler

Brian Ambler

  • 245 Posts
  • 126 Reply Likes
A quick update, with the same firewall policy pushed to my AP330 I tested a non-standard torrent as well as my Debian torrent and I cannot reach the tracker and am at 0 peers after letting it sit for about 40 minutes. I think your network may be playing into this issue (as you suspect) and I will be interested in the results of your resumed testing once you are able.

For the record, my home network is quite simple:
Photo of irldexter

irldexter

  • 37 Posts
  • 1 Reply Like
Hiya, finally got round to testing on HMOL 6.0r2a, and HiveOS 6.0r2b.1190 which is correctly identifying Bittorrent, albeit I have not tried to explicitly block TPB like torrents yet (as this is another network). Once the HiveOS and app sigs v2 went up on these other AP330s as opposed to the AP170's it was all good.

NotE: I had a small issue with the AP170's and pushing updates which I'll take offline.
Photo of Terry Bates

Terry Bates

  • 7 Posts
  • 0 Reply Likes
Hey, I have tested these rules.

Src: Any, Dst: Any, Service: App-Bittorrent, Action: Deny, Logging: Off
Src: Any, Dst: Any, Service: App-torrentz.eu, Action: Deny, Logging: Off

Applied to our default user profile ip policies from and to access drop downs with default action permit.

This doesn't seem to block bittorrent traffic, but it does block torrentz.eu I'm pretty sure the bittorrent filter is not working.

Would be good to get an answer from Aerohive on this...
Photo of Brian Ambler

Brian Ambler

  • 245 Posts
  • 126 Reply Likes
Terry,

Please see me above post, I did test this a while back and was successfully able to block bittorrent with a "any any app-bittorrent deny" rule. What version of HiveOS/HiveManager are you running? The last time I played around with filtering bittorrent I tested on the then current 6.0r2b release, but I have not tested this yet on 6.1r1. If I can find the time to run a test I will try again on 6.1r1 (if this is the version you are running).

Thanks
Photo of Terry Bates

Terry Bates

  • 7 Posts
  • 0 Reply Likes
Yes we are currently deploying a new Aerohive install, using 6.1R1 hivemanager and hiveOS, also app sigs are 3.0.1