Traffic Intelligence in AFM through Categories

 

Introduction

In previous article I talked about how we can configure AFM for filtering URL traffic using URL classification feature, this allows us to control web traffic traversing AFM. This can be very useful because using FQDN in firewall rules can be resource expensive while using URL classification relies in Traffic Intelligence module and it will save resources that AFM can spend in its firewall policies.

In this article I want to go beyond this point, and I will describe how we can use AFM for filtering application traffic. This will allow us to analyse and identify higher level protocols and applications providing us the ability to detect applications and protocols, that is, not only HTTP, but also popular P2P, and top category applications like Audio, Video, File Transfer, Instant Messaging or Mail.Flow of the packet is the same than the one described in my previous article however this time we are filtering by Category (see below) instead of URL Category:

Upgrading IM package

Depending on the IM package installed in your device the number of Applications and Categories can vary, so first step is updating the package to take more advantage of the feature. In the example below we can see that the number of Applications is 4244 for factory default IM in v15:

# tmsh show ltm classification| grep Active
FactoryDefaults                         15.1.5  0.0.10  12/10/21 20:53:09          None  Active

# tmsh list ltm classification application all |grep "ltm classification application" -c
4244

 

So, our first step is downloading, installing and deploying the last Signature Update:

# tmsh run ltm classification update
Success: Hitless Upgrade downloaded package (classification_updates_15.1.0-20220419_0541.im)

# tmsh install ltm classification updates file classification_updates_15.1.0-20220419_0541.im
# tmsh load ltm classification updates classification_updates_15.1.0-20220419_0541.im

 

 Now let’s confirm that the number of Applications classified has increased:

# tmsh  show ltm classification| grep Active
classification_updates_15.1.0-20220419_0541.im   15.1.0  20220419_0541  04/19/22 07:45:03  04/28/22 10:58:39         Active

 # tmsh list ltm classification application all |grep "ltm classification application" -c
4857

 

How to

Filtering application traffic requires only two steps:

• Create a Traffic Intelligence policy
• Attach this Traffic Intelligence (classification policy) into a firewall rule.

As you can see steps are the same than the ones we followed when we played with URL categories, the only difference is the condition part of the classification policy.

So, let’s start by creating a policy for rejecting any traffic related to adult content, and also for sending a log to /var/log/ltm:

tmsh create ltm policy /Common/Drafts/adult { controls add { classification } requires add { classification } rules add { rule1 { actions add { 0 { log write classification-detected facility local0 message "An employee tried to access to forbidden application" priority info }  1 { classification classification-detected reject } } conditions add { 0 { classification category-id values  { 16448 } classification-detected } } } } strategy all-match }

tmsh publish ltm policy Drafts/adult

 

This will create the following published policy:

ltm policy adult {
    controls { classification }
    last-modified 2022-04-29:14:29:55
    requires { classification }
    rules {
        rule1 {
            actions {
                0 {
                    log
                    classification-detected
                    write
                    facility local0
                    message "An employee tried to access to forbidden application"
                    priority info
                }
                1 {
                    classification
                    classification-detected
                    reject
                }
            }
            conditions {
                0 {
                    classification
                    classification-detected
                    category-id
                    values { 16448 }
                }
            }
        }
    }
    status published
    strategy all-match
}

 

At this point I want to make you notice the key point when creating classification policies. If you pay attention into the classification policy, we have used a ‘category-id’ to identify de category, however the ID used is in fact the f5-id for this category not the category-id. 

Therefore, the first thing that we need to know is the f5-id for each category. The easiest way is checking this value through tmsh. With the command below you will list all the built-in categories existing in your IM deployed package:

tmsh list sys url-db url-category | awk '/sys/ {print $4} /f5-id/ {print $0}'

 

In our case we will use ‘Adult_Content’ F5 category ID, that is 16448:

# tmsh list sys url-db url-category | awk '/sys/ {print $4} /f5-id/ {print $0}' | grep -i Adult_Content -A1
Adult_Content
    f5-id 16448

 

Now we just need to attach above policy into a firewall rule. In our case we are going to create a firewall policy from scratch which will contain a rule applying the classification policy. Then we will attach it to the global context:

tmsh create security firewall policy internet_access rules add { r1 { action accept classification-policy adult place-before last } }

tmsh modify security firewall global-rules enforced-policy internet_access

 

As you can see firewall rule is configured to allow traffic, this is because this rule is only used for matching the traffic, but in order to apply any action to the traffic we rely on the classification policy.

Finally, it only rest to test it. We will make a simple test, sending a request to an adult content website:

# curl 10.10.10.161 -H "Host: youporn.com" -s -I

 

I can confirm that request never reaches its destination and we also get logs like the ones below in AFM:

Apr 29 14:41:11 localhost.localdomain info tmm2[16811]: [/Common/adult/rule1]: An employee tried to access to forbidden application
Apr 29 14:41:11 localhost.localdomain err tmm2[16811]: 01230140:3: RST sent from 10.10.20.150:33240 to 10.10.20.2:80, [0x2b96f41:628] {peer} classification policy action
Apr 29 14:41:11 localhost.localdomain err tmm2[16811]: 01230140:3: RST sent from 10.10.10.161:80 to 10.10.10.3:33240, [0x2b96f41:628] classification policy action

 

Troubleshooting

In order to troubleshoot this feature first we should confirm that firewall is accepting the traffic by activating logging in the affected rule. In the described example we would expect to see how firewall rule is accepting the traffic:

Apr 29 20:25:40 localhost.localdomain info tmm[16811]: 23003137 "10.154.39.38","bigip1","Global","/Common/global-firewall-rules","No-lookup","10.10.10.3","No-lookup","10.10.10.161","41504","80","/Common/external","TCP","0","","","","","","","","Enforced","/Common/internet_access","r1","","Accept","","","","0000000000000000","unknown","unknown","unknown","unknown","","","","","No-lookup","No-lookup"

 

If firewall is working without issues then we need to confirm that packet is being classified as we expect.  In order to do it we will enable classification logging in the security log profile used by the virtual server that handles this traffic, for example:

security log profile classification_log {
    classification {
        log-all-classification-matches enabled
        log-publisher varLogLtm
    }
}

 

Where varLogLtm is an existing log publisher configured for sending traffic to local syslog (/var/log/ltm). For our example we would get a log similar to the one below:

Apr 29 20:34:30 localhost.localdomain info tmm[16811]: 27656193 "27656193","bigip1","10.10.10.3","41722","10.10.10.161","80","/Common/external","10.10.20.150","41722","10.10.20.2","80","/Common/internal","Unknown","Unknown","TCP","00025653f9e375e9","/Common/test_traffic_intelligence","/Common/adult","/Common/internet_access","r1","Apr 29 2022 20:34:30","reject","","tcp","http","youporn","","","","","","4","Network_Management_and_Services","Network_Management_and_Services","Adult_Content","","","","","","","","",""

As we can see traffic has been currently classified as Adult Content.

 

Conclusion

Filtering access to applications can be very useful since it will allow us to forget about investigating how different applications works and then translating this behaviour to firewall rules. Also, these types of applications require firewall rules that involves many ports for both communication directions, so category classification will save memory for AFM firewall policies.

Note that using category classification together with AFM can help us to control access to web services, as we have seen in the example described throughout this article, however the goal of category classification is filtering application protocols in general. This means that these categories are not limited to web and therefore if we want to work only with web traffic then URL-category filtering could be a better option because the number of pre-defied web categories is higher.