Appendix: Common Test Cases for All Topologies

Advanced Application Steering

Applications represent traffic destinations. In Juniper® Session Smart® Networking, applications determine the traffic destination used in an application policy.

In a Juniper Mist WAN Assurance design, applications refer to the services or programs that network users access. These can be manually defined within the Juniper Mist portal by selecting a category (for example, Social Media) or choosing specific applications (for example, Microsoft Teams) from a predefined list. Alternatively, you can use a built-in list of common traffic types or create custom application definitions as needed.

Note:

When configuring your internal VPN, always start by using IP prefixes in a custom rule to establish the fundamental traffic forwarding policies. Once these basic rules have been tested and verified, you can refine the configuration by incorporating additional criteria to detect and steer specific applications.

To enable users to access applications, you must first define the applications and then use application policies to control access—either allowing or denying it. This involves associating applications with specific users or networks and assigning both a traffic steering policy and an access rule.

When defining applications, you have the following options defined by their types:

• Using Custom Apps as application identifier one can configure:
  • IP address or IP prefix. Enter one or more IP addresses or subnets, separated by commas.
  • Domain Names. Use FQDN-DNS names; multiple entries can be separated by commas.
  • Protocol. TCP, UDP, GRE, or a custom value are allowed.
  • Destination ports. Specify start and end ports, applicable to protocols that support port numbers.
• Using Apps as application identifier:
  • You can select each pre-configured and known application individually from the drop-down menu or search for them.
• Using URL Categories as application identifier
  • Define applications based on categorized websites using the built-in URL categorization database. You can apply rules using URL Category Groups, URL Categories, or URL Subcategories, depending on the level of granularity required.
  • URL Category Groups are: All, Standard, Strict
  • URL Categories are: Adult, Advertisement, Arts and Entertainment, Business, Career and Education, Collaboration, Conferencing, Device IOT, File Sharing, Financial, Games, Government, Images, Infrastructure, Malware, Networking, News and Reference, Recreation, Religion, Remote Desktop, Search Engines, Security, Shopping, Social Media, Software Updates, Sports, Streaming Media, Technology, Violence
  • URL Subcategories are: Abortion, Adult Content, Adult Material, Advanced Malware Command and Control, Advanced Malware Payloads, Advertisements, Alcohol and Tobacco, Alternative Journals, Application and Software Download, Bandwidth, Blog Commenting, Blog Posting, Blogs and Personal Sites, Bot Networks, Business and Economy, Classifieds Posting, Collaboration Office, Compromised Websites Computer Security, Content Delivery Networks, Cultural Institutions, Education, Educational Institutions, Educational Materials, Educational Video, Emerging Exploits, Entertainment, File Download Servers, Files Containing Passwords, Financial Data and Services, Freeware and Software Download, Games, Gay or Lesbian or Bisexual Interest, Government, Hacking, Hobbies, Hosted Business Applications, Image Servers, Images Media, Information Technology, Internet Auctions, Internet Radio and TV, Internet Telephony, Intolerance, Job Search, Keyloggers, Lingerie and Swimsuit, Malicious Embedded iFrame, Malicious Embedded Link, Malicious Web Sites, Media File Download, Militancy and Extremist, Military, Mobile Malware, Network Errors, News and Media, Non Traditional Religions, Non Traditional Religions and Occult and Folklore, Nudity, Office Apps, Office Documents, Office Drive, Office Mail, Online Brokerage and Trading, Parked Domain, Peer to Peer File Sharing, Personal Network Storage and Backup, Personals and Dating, Phishing and Other Frauds, Political Organizations, Potentially Exploited Documents, Potentially Unwanted Software, Private IP Addresses, Pro Choice, Pro Life, Professional and Worker Organizations, Proxy Avoidance, Real Estate, Reference Materials, Religion, Restaurants and Dining, Search Engines and Portals, Security, Service and Philanthropic Organizations, Sex, Sex Education, Shopping, Social and Affiliation Organizations, Social Organizations, Social Web Facebook Social Web Linkedin, Social Web Twitter, Social Web Youtube, Society and Lifestyles, Special Events, Sport Hunting and Gun Clubs, Sports, Spyware, Streaming Media, Surveillance, Suspicious Content, Suspicious Embedded Link, Tasteless, Traditional Religions, Unauthorized Mobile Marketplaces, Violence, Viral Video, Web Analytics, Web and Email Marketing, Web and Email Spam, Web Hosting, Web Images, Web Infrastructure, Website Translation
• Using Custom URLs as application identifier
  • With custom URLs, you can identify services and applications that are not pre-defined apps or URL categories in some way. Please see the figure below for an example:

Example Usage of a Predefined Application

Go to Organization -> Applications and create a new application with the following configuration:

• Name=MYAPP
• Type=Apps
• Apps=BBC + CNN

Then, go to your existing WAN Edge template and insert the following application policy:

• Number=4
  • Name=MYAPP-traffic
  • Network=SPOKE-LAN1
  • Action=Pass
  • Application=MYAPP
  • Traffic Steering=VPN. If you have already configured LBO from the previous lab Local Traffic Breakout at the Spoke you can use that as well.

The changes above do not alter the actual traffic flow—it will still use central breakout at the hub due to the broader rule defined below. This step is simply to verify that our rule correctly identifies the traffic. Ensure your changes are saved and successfully applied to the spoke.

Now we need to generate traffic for this custom application. In our example, we use desktop1 VM attached to spoke1 by pointing a browser towards https://www.cnn.com.

After you generate the traffic, use the Testing Tools on your spoke by going to Applications -> Session with Application Name=MYAPP as shown in the figure below. You see that this traffic was identified and handled correctly.

IDP-Based Threat Detection

An Intrusion Detection and Prevention (IDP) policy lets you selectively enforce various attack detection and prevention techniques on network traffic. You can enable IDP on the Session Smart Router operating as a spoke device in your Juniper Mist network by activating it in an application policy.

Intrusion detection is the process of monitoring the events occurring on your network and analyzing them for signs of incidents, violations, or imminent threats to your security policies. Intrusion prevention is the process of performing intrusion detection and then stopping the detected incidents. For details, see Intrusion Detection and Prevention Overview.

Note:

1. You can configure IDP on Session Smart Routers only when the devices are operating as spoke devices.

2. Consider a maintenance window when activating IDP for the first time. The start of the IDP engine and inclusion into the path from LAN to WAN (that is, service-chaining) might take a few minutes and might also interrupt ongoing communications.

3. When using traffic steering for local breakout, a matching rule on the hub is not required. However, with Session Smart Routers, if IDP is to inspect traffic crossing the VPN overlay to a hub, you must also configure a matching rule with IDP enabled on the hub. This is necessary because the internal service name changes when IDP is applied, and a corresponding service name must exist on the remote hub—even if the hub itself is not performing IDP inspection.

Juniper Mist cloud supports the following IDP profiles:

• Standard—The standard profile is the default profile and represents the set of IDP signatures and rules that we recommend. Each attack type and severity have a Juniper-defined, non-configurable action that the IDP engine enforces when it detects an attack. The possible actions are as follows:
  • Close the client and server TCP connection.
  • Drop the current packet and all subsequent packets
  • Send an alert only (no additional action).
• Alert—Alert profiles are suitable only for low-severity attacks. When the IDP engine detects malicious traffic on the network, the system generates an alert, but it does not take additional measures to prevent the attack. The IDP signature and rules are the same as in the standard profile.
• Strict—The strict profile contains a similar set of IDP signatures and rules as the standard profile. However, when the system detects an attack, this profile actively blocks any malicious traffic or other attacks detected on the network.

You can apply an IDP profile to an application policy. Each profile has an associated traffic action, and these actions define how to apply a rule set to a service or an application policy. Actions in the IDP profile are preconfigured and are not available for users to configure.

Example IDP Test Case

In this test case, we modify the first lab Appendix: Building a base SD-WAN Topology with Three Spokes and Two Hubs to do the following:

• Local breakout for all non-VPN traffic instead of central breakout.
• Activate IDP alerting for this traffic.
• Install a security scanner on a client attached to a spoke.
• Run the security scanner to inspect a webserver in our lab (not part of the VPN).
• Review the captured IDP events in the Juniper Mist portal.

To configure our example with IDP-based threat detection:

• In the Juniper Mist cloud portal, click Organization > WAN Edge Templates and select a template for your spoke device.
• Then, configure an additional traffic steering policy in the spoke WAN Edge template:
  • Name=LBO
  • Strategy=Weighted
  • Paths
    • Type1=WAN: INET
    • Cost1=10
    • Type2=WAN: MPLS
    • Cost2=20
• Modify the existing Applications Policies
  • Number=4
    • Name= internet-via-hub-cbo
    • Network=SPOKE-LAN1
    • Action=Pass
    • Application=any
    • IDP=Alert
    • Traffic Steering=LBO

Save your template to get this IDP configuration committed on the spokes.

Inspect the WAN Edge spoke after a few minutes. Under Advanced Security, the IDP service should now be activated.

We shall now continue our testing on the clients attached to the spokes. We connect to desktop1 VM with IP address 10.99.99.99 attached to Spoke1. There, we install a security scanner service called nikto and let it inspect a local webserver that our lab happens to have.

Then, we go to Site -> Security Events and check IDP to review the captured IDP events as seen in the figure below.