SRX APPLICATION FIREWALL

Today we will look at running an Application Firewall (AppFW) on the SRX. 

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





Note the URL in the picture above and the examine the pattern for the Steam Store sig and we can see why its blocked.
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]


5 comments:

  1. 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?

    ReplyDelete
  2. Hi Dumebi,

    It 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,

    ReplyDelete
  3. 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.
    +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.

    ReplyDelete
  4. very nice and detailed explanation. thanks for taking the time to share.

    ReplyDelete
  5. new at all this firewall thing; so Im wondering, is it possible to block certain webpages only on a certain VLAN?
    because I need to block SOCIAL NETWORKS to some user but not bosses.

    ReplyDelete