Enterprise network administrators are facing an increasing number of challenges when it comes to network monitoring. Business critical services must be clearly distinguished from the other traffic classes and always monitored in terms of specific QoS parameters. Depending on the AUP (acceptable use policy) aside from business-oriented applications and services, other application may be available in an enterprise network and even necessary to carry out core business. In this blog, we focus on the social networking applications and services, which are sometimes either strictly prohibited to the users or are being held under scrutiny in terms of that only a specific set of social networking applications are available.
Traffic visibility is hard to achieve with high diversity of services and applications roaming through the enterprise network infrastructure. Clearly, for thorough network monitoring a combination of software tools and hardware should be used in order to keep track of traffic statistics that a specific application is generating.
In the context of monitoring tools, Netflow analyzer is able to provide detailed flow information generated by social networking applications.
Current trend is that many applications are nested inside another Layer 7 application. The most popular applications today such as Facebook, Gmail, Youtube and Twitter are nested in HTTP payload. This enables flexible access to the users via Web browser, but on the other hand, these services are consequently classified like any other HTTP traffic. This classification has inadvertent effect on the implementation of proper security policies that also refers to social networking usage rules in enterprise networks. More granular classification that includes application identification through deep packet inspection requires dedicated hardware (such as firewall appliance with specific modules for application recognition) and software containing application signatures.
Netflow analyzer can prove as a useful tool to provide a baseline for particular application and traffic classes. In this blog, social networking application monitoring is addressed through defining traffic patterns that classify flows based on the configured parameters. Each traffic pattern may be defined to classify particular social networking application and to provide insight into how much network resources are being used by these type of applications.
Netflow analyzer can provide additional visibility in terms of user behavior and even particular attack signatures reflected in the abnormal flow behavior.
Using Netvizura flow analyzer, traffic pattern configuration is shown in order to classify flows that belong to Facebook, Twitter, Google and Microsoft. Definition of traffic patterns in this context requires that address range is known for internal network (address range in enterprise network that needs to be monitored for a specific service) and for external network (e.g. Facebook address range where enterprise traffic is terminated). Internal network address ranges are included, whereas the same ranges are excluded from the external address range automatically. Same applies for inclusion of external address range. Thus, both directions are accounted and Facebook traffic flows may be observed between the internal and external specified address ranges as is depicted in Fig. 1. AMRES Facebook HTTP traffic pattern represents traffic flows relating to the Facebook services observed from AMRES (Academic Network of Serbia). It is important to point out that external address ranges are sometimes difficult to specify. Current tendency of global CDNs is to provide perform replication of content across a geographically distributed set of servers and to redirect clients to the closest server. Therefore, DNS will resolve facebook.com to addresses based on user's location and will not always be the same. Consequently, it is important to specify complete CDN address list as accurate as possible so all traffic flows directed to the specific CDN are accounted for. These address lists are always subjected to change so it is important keep it updated.
By defining address ranges, traffic pattern encompasses all services residing on all ports. As was mentioned before, majority of today's applications are nested in HTTP payload and as a result of this embedding, granular classification is required in terms of source and destination ports. The definition of HTTP and HTTPS ports is depicted in Fig. 2 which takes into account both flow directions for ports 80 and 443, respectively. 
Aside from address range and service (port numbers), additional parameters are available to tailor the traffic pattern according to the administrative needs. Currently available parameters include exporter IP address, ASN (autonomous system number), protocol number, QoS (ToS marked packets) and next hop.
One of the previously mentioned traffic pattern parameters is also ASN. Traffic patterns may be fine-tuned using ASN to specify source (origin), destination or peer-AS. It is important to distinguish these three terms on the following example (depicted in Picture on the right). We observe packet that is sourced from R1 towards R4 and which is routed over blue path. Router R2 in AS2 performs Netflow export. In order for AS to be a part of exported Netflow records to the collector, R2 must participate in BGP routing. Whether the R2 flow export is configured as origin or peer, source and destination AS for the designated packet flow will be different.
Origin AS configuration means that packet flow traversing from AS1 to AS4 will export source AS1 and destination AS4 to the Netflow collector. On the other side, peer AS configuration will mean that flow records will show that this packet flow has source AS2 and destination AS3. Origin AS configuration is appropriate choice for traffic patterns in which origin and final destination of packet is necessary (such as previously shown Facebook traffic pattern). Conversely, if traffic patterns are required to make the flow classification according to the neighboring source and destination domains, peer AS configuration is a prudent choice. Latter is useful if custom traffic pattern are used to track flows coming from or going towards specific neighboring domains.
We have already covered Netflow configuration in our previous blogs for Cisco and Juniper devices. The following configuration will designate whether the origin or peer approach is used in flow export.
Cisco network device configuration requires that a single command „ip flow-export version 9 [origin-as | peer-as]" is added to the rest of the flow export configuration which will decide if origin or peer is in use, respectively. We must point out that if neither origin nor peer is configured, AS parameter will not be exported. It is not possible to configure both options at the same time. Furthermore, some IOS versions command will also require adding bgp-nexthop argument to the ip flow-export version 9 command. This argument includes BGP next hop-related information in the export statistics.
! Flow export configuration
Router(config)#ip flow-export destination 192.168.1.1 4444
Router (config)#ip flow-export version 9 [origin-as | peer-as]
Router (config)#ip flow-cache timeout active 5
Router (config)#ip flow-cache timeout inactive 15
! Interface flow activation and configuration
Router (config)#interface GigabitEthernet 0/1
Router (config-if)#ip flow ingressFor Juniper network devices autonomous-system-type is configured to designate peer or origin concept. Also, in comparison to Cisco configuration, Juniper has the origin default and same constraint applies relating to the configuration of both options simultaneously. We present only a part of flow export configuration where autonomous-system-type is configured. The rest of the flow export configuration may be found in our previous Juniper blog.
[edit services]
sampling {
instance {
IPFIX-INSTANCE {
input {
rate 1;
}
family inet {
output {
flow-server 192.168.1.1 {
autonomous-system-type (origin | peer);
port 4444;
version-ipfix {
template {
IPv4-example;
}
}
}
inline-jflow {
source-address 172.17.1.1;
}
}
}
family inet6 {
output {
flow-server 192.168.1.1 {
port 4444;
version-ipfix {
template {
IPv6-example;
}
}
}
inline-jflow {
source-address 172.17.1.1;
}
}
}
}
}
}Using ASN for specifying traffic patterns is very useful but it is limited by the fact that router exporting particular flows must participate in BGP routing, which is not deployed in every enterprise network. Therefore, the usage of ASN for traffic pattern fine-tuning must be carefully considered and mentioned constraints should be accounted for.
In the following figures, traffic patterns relating to the HTTP/HTTPS traffic for Facebook, Google, Microsoft and Twitter are depicted. Each traffic pattern is classified based on address ranges like it was shown for Facebook traffic pattern.
So now you can go and save your time and enjoy your work :)
