This is different to the normal firewalling in that we are not filtering based on TCP/UDP ports but instead filtering on application signatures that can detect applications whether or not they are not running on the standard ports expected.Further even when we are running on the standard ports, through the signatures we can detect and block access to specific services without you having to worry about blocking all access to a certain IP on a certain port. Eg. We could block access to Facebook Farmville without having to know the either the IP of Facebook or having to block all of Facebook. I will try and show some examples of this functionality.
1) THE LICENSE
To run the AppFW you need the application signature package which is via a subscription service.
a) Download the trial license.
a. Login to this site with your Juniper ID.. https://www.juniper.net/lcrs/mylic.do?methodToCall=setUpTrial&family_id=1
b. Select your version of Junos, enter your serial number and click “Get Available Trials”
c. Select Application Security Updates and click the "Generate" button to get your license key
b) Status before adding the license
blogger@LEFTY> show system license
License usage:
Licenses Licenses Licenses Expiry
Feature name used installed needed
wf_key_surfcontrol_cpa 1 0 1 15 days
idp-sig 1 0 1 invalid
dynamic-vpn 0 2 0 permanent
ax411-wlan-ap 0 2 0 permanent
mem-upg 0 1 0 permanent
wf_key_websense_ewf 1 0 1 23 days
c) Add the new license and check status
blogger@LEFTY> request system license add terminal
[Type ^D at a new line to end input,
enter blank line between each license key]
JUNOS427775 apnqea qmiwkt eobrgf aqmmbu gm36qb qctt63
bpooa4 ukhawd fixpvw t33vpi ahaha5 7wtr3c
5notns 54law5 zreale bsigtx thh5zu 4s26rx
w43
JUNOS427775: successfully added
add license complete (no errors)
blogger@LEFTY> show system license
License usage:
Licenses Licenses Licenses Expiry
Feature name used installed needed
wf_key_surfcontrol_cpa 1 0 1 15 days
idp-sig 1 0 1 invalid
dynamic-vpn 0 2 0 permanent
ax411-wlan-ap 0 2 0 permanent
mem-upg 0 1 0 permanent
appid-sig 0 1 0 2013-04-27 10:00:00 EST
wf_key_websense_ewf 1 0 1 23 days
2) DOWNLOAD AND CHECK THE SIGNATURES
a) Download
If you have an active IDP subscription then there is nothing special to download as the IDP signatures download already has the application signatures.
If you don't have IDP (As in my case as its expired) then install the signatures like so...
blogger@LEFTY> request services application-identification download
Please use command "request services application-identification download status" to check status
blogger@LEFTY> request services application-identification download status
Fetching/Uncompressing https://services.netscreen.com/xmlupdate/194/Applications/2249/applications.xml.gz
blogger@LEFTY> request services application-identification download status
Downloading application package 2249 succeed.
blogger@LEFTY> request services application-identification install
Please use command "request services application-identification install status" to check status
blogger@LEFTY> request services application-identification install status
Checking compatibility of application package version 2249 ...
blogger@LEFTY> request services application-identification install status
Compiling application signatures of package version 2249 ...
blogger@LEFTY> request services application-identification install status
Install application package 2249 succeed
b) Check
So with IDP not running and not enabling any features of AppFW yet, lets check if we can see the application signatures.
blogger@LEFTY> show services application-identification version
Application package version: 2249
IF you had IDP that version would be the same as the IDP security package version.
blogger@LEFTY> show services application-identification version
Application package version: 2249
blogger@LEFTY> show services application-identification group summary
Application Group(s): 83
Application Groups Disabled ID
junos:web:infrastructure:networking No 85
junos:web:social-networking:business No 84
junos:web:infrastructure:encryption No 83
junos:web:remote-access:tunneling No 82
junos:web:infrastructure:mobile No 81
junos:web:infrastructure:software-update No 80
junos:web:infrastructure:database No 79
junos:web:infrastructure No 78
junos:web:gaming:protocols No 77
junos:web:p2p:file-sharing No 76
junos:web:p2p No 75
junos:web:multimedia:audio-streaming No 74
etc
etc
blogger@LEFTY> show services application-identification application summary
Application(s): 230
Nested Application(s): 877
Applications Disabled ID Order
junos:STEAM-USER-AGENT No 1303 33027
junos:BITTORRENT-APPLICATION No 1302 33696
junos:BITTORRENT-WEB-CLIENT No 1301 33697
junos:YMSG-CONTACTS No 1298 33694
junos:YMSG-CHAT No 1297 33695
junos:SOAP No 1296 33693
junos:OUTLOOK-WEBMAIL-SSL No 1288 32995
junos:TWITTER-SSL No 1287 33692
junos:MYSPACE-SSL No 1285 33691
etc
etc
877 apps and 83 groups. Impressive. Though not quite as impressive as... http://www.checkpoint.com/products/application-control-software-blade/index.html
See all the Juniper signatures and their details at http://services.netscreen.com/documentation/applications/
So our application signatures are here. Next step - use them!
3) CONFIGURE THE APPLICATION FIREWALL
a) Identify signatures to use.
We are going to test the AppFW by trying to block access to 3 different things.
Facebook, the Steam Store and Bittorrent.
First we need to find the signatures we need.
>>STEAM signatures
blogger@LEFTY> show services application-identification application summary | match STEAM
junos:STEAM-USER-AGENT No 1303 33027
junos:STEAM-STORE No 428 33028
junos:STEAM No 194 50
junos:STEAM-FRIENDS No 193 28
Right, there is one there for the steam Store specifically so we will use that.
>>FACEBOOK signatures
blogger@LEFTY> show services application-identification application summary | match facebook | count
Count: 65 lines
I see 65 Facebook categories. Most of them seemed to be contained in the predefined group junos:web:social-networking:facebook so we will use that.
>>BITTORRENT signatures
blogger@LEFTY> show services application-identification application summary | match bittorrent
junos:BITTORRENT-APPLICATION No 1302 33696
junos:BITTORRENT-WEB-CLIENT No 1301 33697
junos:BITTORRENT-DHT4 No 1017 206
junos:BITTORRENT-UDP No 824 138
junos:BITTORRENT-DHT No 131 118
junos:BITTORRENT No 60 146
A couple of versions ago that list just had 4 entries. So, as you would expect, Juniper are actively working on the development of these signatures. Good!
Anyway, I'll take all of those. Is there a group for them?
blogger@LEFTY> show services application-identification group summary | match bittorrent
Nothing with Bittorrent as part of the name
Lets look closer at one of the Bittorrent sigs...
blogger@LEFTY> show services application-identification application detail junos:BITTORRENT
Application Name: junos:BITTORRENT
Application type: BITTORRENT
Description: This signature detects BitTorrent protocol, which defines a method for advertising and sharing files over a network. It is a variation of earlier
P2P protocols that allowed groups of computers to share files with one another.
Application ID: 60
Disabled: No
Number of Parent Group(s): 1
Application Groups:
junos:p2p:file-sharing
Application Tags:
characteristic : Carrier of Malware
characteristic : Can Leak Information
characteristic : Supports File Transfer
characteristic : Prone to Misuse
characteristic : Bandwidth Consumer
risk : 5
subcategory : File-Sharing
category : P2P
Port Mapping:
Default ports: N/A
Signature:
Port range: TCP/0-65535
Client-to-server
DFA Pattern: .*\x13\x\[BitTorrent\sprotocol\].*
Regex Pattern: None
Server-to-client
DFA Pattern: .*\x13\x\[BitTorrent\sprotocol\].*
Regex Pattern: None
Minimum data client-to-server: 20
Minimum data server-to-client: 20
Order: 146
So its part of junos:p2p:file-sharing.
Lets check that group out to be sure it has what we want.
blogger@LEFTY> show services application-identification group detail junos:p2p:file-sharing | match BITTORRENT
junos:BITTORRENT-DHT4
junos:BITTORRENT-UDP
junos:BITTORRENT
junos:BITTORRENT-DHT
junos:BITTORRENT-WEB-CLIENT
junos:BITTORRENT-APPLICATION
junos:p2p:file-sharing contains all the bittorrent sigs and whole lot more for other p2p apps so we will use that.
b) Construct the AppFW rulebase.
Here is the resulting config...
root> show configuration security application-firewall
rule-sets blogger-appfw {
rule p2p-block {
match {
dynamic-application-group junos:p2p:file-sharing;
}
then {
deny;
}
}
rule steam-block {
match {
dynamic-application junos:STEAM-STORE;
}
then {
deny;
}
}
rule facebook-block {
match {
dynamic-application-group junos:web:social-networking:facebook;
}
then {
deny;
}
}
default-rule {
permit;
}
}
Note: you can have multiple rule sets and individual firewall rules can have different AppFW rule-sets associated with them
c) Apply it to the rules you want to protect. In our case the default out-of-the-box rule
root> show configuration security policies
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
application-services {
application-firewall {
rule-set blogger-appfw;
}
}
}
log {
session-init;
}
}
}
}
3) TESTING
Steam Store - WORKS!*
I cannot access the Steam Store through either a browser (http://store.steampowered.com) or the Steam client itself
Pattern: (store|cdn|api)\.steampowered\.com
* However if you google "steam store" the number 2 hit is..
Different URL that does not match the pattern and so is not blocked.
Facebook - WORKS!
Facebook not accessible - great!
Lets check the stats at this point.
blogger@LEFTY# run show security application-firewall rule-set all
Rule-set: blogger-appfw
Rule: facebook-block
Dynamic Application Groups: junos:web:social-networking:facebook
Action:deny
Number of sessions matched: 2
Rule: p2p-block
Dynamic Application Groups: junos:p2p:file-sharing
Action:deny
Number of sessions matched: 0
Rule: steam-block
Dynamic Applications: junos:STEAM-STORE
Action:deny
Number of sessions matched: 6
Default rule:permit
Number of sessions matched: 506
Number of sessions with appid pending: 0
The hits also show up in the logs...
blogger@LEFTY> show log POLICY | match deny
Mar 29 23:00:23 LEFTY RT_FLOW: RT_FLOW_SESSION_DENY: session denied 10.10.10.10/4121->31.13.70.7/80 junos-http 6(0) trust-to-untrust trust untrust HTTP FACEBOOK-ACCESS N/A(N/A) vlan.0 No
Mar 29 23:42:02 LEFTY RT_FLOW: RT_FLOW_SESSION_DENY: session denied 10.10.10.10/4161->208.64.202.69/80 junos-http 6(0) trust-to-untrust trust untrust HTTP STEAM-STORE N/A(N/A) vlan.0 No
Bittorrent - WORKS (With a lot of work)
Using the Tixati client I made the following findings as to the effectiveness of the SRX to stop Bittorrent traffic.
So we see the only time that Bittorrent was blocked is when using unencrypted TCP connections. Therefore effectively ineffective as way too easy to work around.
Enabling Heuristics didn't make any difference to the results but we will leave it on anyway.
set services application-identification enable-heuristics
Adding junos:UNSPECIFIED-ENCRYPTED as an AppFW sig in combination with heuristics gives the best results.
The new rule with junos:UNSPECIFIED-ENCRYPTED added
rule p2p-block {
match {
dynamic-application junos:UNSPECIFIED-ENCRYPTED;
dynamic-application-group junos:p2p:file-sharing;
}
then {
deny;
}
}
The results...
Basically, it looks like at this point that the AppFW cannot stop, by itself, unencrypted UDP torrents at least in my lab. I found that even when it does stop torrents, depending on how I set the client, a single torrent may, occasionally, get a foot hold for a while before being stopped or else permanently hold traffic while all others are stopped. Other times and again depending on settings, some torrents seem to just start, "dribble" a little traffic in or out at a very slow rate and then get stopped. So it seems to not exactly stop them dead in its tracks even though from the end user perspective trying to download the torrents would appear effectively as good as dead.
There are a lot of variables here; the client, how it is set and used and even the torrent itself so your mileage may vary. Do your own testing to prove whether or not it is effective for you. Saying all that. I stand by these results and ran them all from scratch twice to make sure the results were repeatable and they were.
In the real world however there is a good chance that if you have AppFW you will also have IDP. At a customer site of mine I have setup AppFW to stop torrents as above (I.e with heuristics, junos:UNSPECIFIED-ENCRYPTED and junos:p2p:file-sharing) but also added a custom IDP rule...
rule 10 {
description "Torrent Blocker";
match {
from-zone any;
source-address any;
to-zone any;
destination-address any;
application default;
attacks {
predefined-attack-groups "P2P - All";
}
}
then {
action {
drop-connection;
}
notification {
log-attacks;
}
}
}
All of this (IDP + AppFW as per above) together is actually proving effective at stopping bittorrent traffic from being a bandwidth thief.
Due to the issues I found with the Bittorrent traffic on the SRX, I thought it would be interesting to see how another type of device handles the same traffic. So I ran the same tests from the same client through a Checkpoint (R75.45 GAiA) using its application filtering. The Checkpoint IPS was disabled for the tests to not give it any advantage over my SRX lab tests which also had no IDP.
I.e Checkpoint Application Control blade vs Juniper Application Firewall.
Here is the Checkpoint rule and tracker results...
I can only tell you 2 things about the Checkpoint's ability in regards stopping Bittorrent traffic
1) It is incredibly easy to configure
2) It is devastatingly effective: No matter how I configured the client nothing got through. Nothing.
On this Bittorrent stopping battlefield the winner is Checkpoint. Sorry fans.
We Now Return You To Your Regularly Scheduled Programming
4) MONITORING
So we have our AppFW in but how can we see if it is actually being effective.
How can we see what is actually using our bandwidth?
The answer is Application Tracking.
blogger@LEFTY> show services application-identification statistics application-groups
Last Reset: 2013-03-29 08:52:14 EST
blogger@LEFTY> show services application-identification statistics applications
Last Reset: 2013-03-29 08:52:14 EST
No output!
You need this command to get the stats to work..
set security zones security-zone untrust application-tracking
Of course you could apply that on any zone you want and it can work independently of the AppFW.
Its more useful in the real world to turn this feature on before setting up AppFW to see what is stealing you precious bandwidth and then make your AppFW rules as appropriate. You'll be surprised if you never had this kind of visibility before.
After you commit that lets check the stats again after accessing few pages and apps.
blogger@LEFTY> show services application-identification statistics applications
Last Reset: 2013-03-29 08:52:14 EST
Application Sessions Bytes Encrypted
BITTORRENT-DHT 203 27894 No
BITTRACKER 1 1103 No
DNS 179 37445 No
HTTP 17 111609 No
MICROSOFT-LIVE-SERVICES 7 52433 No
NTP 2 304 No
OCSP 1 2987 No
PICASA-WEB 3 768 No
SPDY 2 5198 No
SSL 1 8094 Yes
STEAM-STORE 1 2507 No
YAHOO-MAIL 2 8103 No
unknown 162 34404 No
blogger@LEFTY> show services application-identification statistics application-groups
Last Reset: 2013-03-29 08:52:14 EST
Application Group Sessions Kilo Bytes
junos:infrastructure 187 18
junos:infrastructure:encryption 4 18
junos:infrastructure:networking 183 0
junos:p2p 203 0
junos:p2p:file-sharing 203 0
junos:web 91 1788
junos:web:applications 12 353
junos:web:cdn 3 16
junos:web:file-sharing 1 1
junos:web:gaming 1 2
junos:web:gaming:web-based 1 2
junos:web:image-sharing 24 124
junos:web:infrastructure 3 8
junos:web:infrastructure:encryption 3 8
junos:web:messaging 2 7
junos:web:messaging:mail 2 7
junos:web:multimedia 6 277
junos:web:multimedia:web-based 6 277
unknown 292 9
That look better! Give a really granular view of whats happening on your network.
With this tool you can see whats being abused in your network and block accordingly.
Seems to be recognising Bittorrent traffic but cant completely block it (At this point I am successfully running again unencrypted UDP on Tixati) Hmmmmmm.........
The best way to view these stats though is via the WebUI as you can sort the data very easily which you don't seem to be able to do at all on the cli output. Also you can do some graphical sorted displays of the data as per below,
The Unknown in the above 2 charts is the unencrypted UDP torrents hence why its getting through.
So on the one hand the application-identification statistics is picking up Bittorrent (Or at least some of it) but unfortunately the vast majority of the unencrypted UDP torrrents are being seen as Unknown and getting through.
Model: srx100h
JUNOS Software Release [12.1R5.5]
Hi, thanks for you excellent guide. I am working on an SRX550...I have done all the necessary configurations but it only detects the torrent applications but doesn't block them. I'm running on a 1month trial license...could that be the reason it's not blocking it?
ReplyDeleteHi Dumebi,
ReplyDeleteIt wouldn't be the case that it's the trial license that is making it not block torrents.
I have recently done some more testing and I really have to say that the SRXs are just not completely effective in blocking torrents IMHO.
I have thrown everything at the problem - IDP & AppFW with all possible options that have anything to do with torrents and P2P and well..some stop but some do manage to get through if you give them enough time.
So - in addendum to the above I don't really believe that IDP + AppFW together is actually proving effective at stopping bittorrent traffic.
What it can do is make "most" torrents stop and or start up very slowly - hopefully annoying enough to stop some users.
This whole issue is both annoying and disappointing and serves fuel to those who say that the SRX is good - but not past layer 4: What it means is if you go with SRXs to stop torrents, logging and tracking down the culprits is a very important step in the process because you cant really set and forget the SRX to do the job itself. It needs your assistance you might say,
Saying it has proved effective at stopping other apps - it just has a particular issue with torrents.(So many clients and so many ways to run them..?)
If anybody knows otherwise, please let us know how you use SRXs to stop torrents 100% (THATS 100%) dead,
Thanks for your response. I finally had to reverse my approach. I monitored the network for a while (about 2weeks) and took note of the applications my office was constantly using. Then I default-rule blocked everything and permitted only those applications.
ReplyDelete+ve: torrents no longer work
-ve: I'll probably be getting requests to allow new applications that didn't show up during my monitoring period. Also dunno how to allow any legitimate application that falls under UNKNOWN/PENDING.
very nice and detailed explanation. thanks for taking the time to share.
ReplyDeletenew at all this firewall thing; so Im wondering, is it possible to block certain webpages only on a certain VLAN?
ReplyDeletebecause I need to block SOCIAL NETWORKS to some user but not bosses.