Junos Unified Threat Management: Student Guide

Junos Unified Threat Management
12.a
Student Guide
Worldwide Education Services
1133 Innovation Way

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Course Number: EDU-JUN-JUTM

This document is produced by Juniper Networks, Inc.
This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks
Education Services.
Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Junos Unified Threat Management Student Guide, Revision 12.a

Copyright © 2014 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.a—March 2011
Revision 11.a—February 2012
Revision 12.a—June 2014
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 12.1X46-D15.3. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary,
incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has
no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.
Contents
Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Chapter 2: UTM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1

Branch Office Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
UTM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Design Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10
Hardware Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14
Licensing Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18
Initial Setup Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-23
Chapter 3: Antispam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Methods and Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Antispam Traffic Examination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10
Configuring Antispam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14
Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23
Antispam Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-31
Chapter 4: Full File-Based Antivirus and Express Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Antivirus Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Antivirus Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11
Antivirus Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16
Full File-Based Antivirus Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-26
Monitoring Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-37
Antivirus Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-44
Chapter 5: Content Filtering and Web Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Content Filtering Overview and Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Content Filtering Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Content Filtering Verification and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11
Web Filtering Overview and Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17
Enhanced Web Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-23
Web Filtering Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-25
Web Filtering Verification and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-35
Content Filtering and Web Filtering Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-45
Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACR-1
www.juniper.net Contents • iii

iv • Contents www.juniper.net
Course Overview
This one-day course includes detailed coverage of Web filtering, antivirus, antispam, and content
filtering. Through demonstrations and hands-on labs, students will gain experience in configuring
and monitoring the Unified Threat Management (UTM) features of the Junos operating system. This
course is based on the Junos OS Release 12.1X46-D15.3.
Objectives
After successfully completing this course, you should be able to:
• Describe the challenges that branch offices present to network managers.
• List the major features that UTM offers.
• Explain how each major feature addresses the challenges of the branch office.
• List the SRX Series Services Gateways on which UTM is available.
• Describe the UTM features that require specific licenses.
• Define terms used in the creation of effective antispam UTM policies.
• Describe the process by which UTM examines traffic for spam.
• Describe the overall process of configuring an antispam UTM policy.
• Describe the kinds of information available from the device when it has detected
spam.
• Describe how the antivirus process examines traffic.
• Describe the differences between full file-based antivirus versus express antivirus.
• Describe the settings that are required for configuring antivirus protection.
• Explain how antivirus settings affect scanning performance and effectiveness.
• Describe options available for scanning supported protocols.
• List the general steps required to configure antivirus.
• Describe the statistical information available to verify antivirus functionality.
• Describe content filtering and Web filtering and their purpose.
• List and describe each of the parameters used when configuring Web filtering and
content filtering.
• Describe the basic steps necessary to configure Web filtering and content filtering.
• Monitor Web filtering and content filtering.
Intended Audience
This course benefits individuals responsible for implementing and monitoring the UTM features
available on branch SRX Series Services Gateways and J Series Services Routers.
Course Level
Junos Unified Threat Management is an intermediate-level course.
Prerequisites
Students should have basic networking knowledge and an understanding of the Open Systems
Interconnection (OSI) model and the TCP/IP protocol suite. Students should also have working
knowledge of security policies.
Students should also attend the Introduction to the Junos Operating System (IJOS), Junos Routing
Essentials (JRE), and Junos Security (JSEC) courses prior to attending this class.
www.juniper.net Course Overview • v

Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: UTM Overview
Lab 1: Initial Setup
Chapter 3: Antispam
Lab 2: Antispam
Chapter 4: Full File-Based Antivirus and Express Antivirus
Lab 3: Antivirus
Chapter 5: Content Filtering and Web Filtering
Lab 4: Content Filtering and Web Filtering
vi • Course Agenda www.juniper.net

Document Conventions
CLI and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface (CLI)
or a graphical user interface (GUI). To make the language of these documents easier to read, we
distinguish GUI and CLI text from chapter text according to the following table.
Style Description Usage Example
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
Courier New Console text:

commit complete
• Screen captures
• Noncommand-related Exiting configuration mode
syntax
GUI text elements:
Select File > Open, and then click
• Menu names Configuration.conf in the
Filename text box.
• Text field entry
Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances
will be shown in the context of where you must enter them. We use bold style to distinguish text
that is input versus text that is simply displayed.
Normal CLI No distinguishing variant. Physical interface:fxp0,

Enabled
Normal GUI
View configuration history by clicking
Configuration > History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
Defined and Undefined Syntax Variables

Finally, this course distinguishes between regular text and syntax variables, and it also
distinguishes between syntax variables where the value is already assigned (defined variables) and
syntax variables where you must assign the value (undefined variables). Note that these styles can
be combined with the input style as well.
CLI Variable Text where variable value is already policy my-peers

assigned.
GUI Variable Click my-peers in the dialog.
CLI Undefined Text where the variable’s value is Type set policy policy-name.
the user’s discretion or text where
ping 10.0.x.y
the variable’s value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.
www.juniper.net Document Conventions • vii

Additional Information
Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to: 
http://www.juniper.net/training/education/.
About This Publication
The Junos Unified Threat Management Student Guide was developed and tested using software
Release 12.1X46-D15.3. Previous and later versions of software might behave differently so you
should always consult the documentation and release notes for the version of code you are
running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the
format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or
at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).
viii • Additional Information www.juniper.net

Chapter 1: Course Introduction

We Will Discuss:
• Objectives and course content information;
• Additional Juniper Networks, Inc. courses; and
• The Juniper Networks Certification Program.
Chapter 1–2 • Course Introduction www.juniper.net

Introductions
The slide asks several questions for you to answer during class introductions.
www.juniper.net Course Introduction • Chapter 1–3

Course Contents
The slide lists the topics we discuss in this course.

Prerequisites
The slide lists the prerequisites for this course.

General Course Administration

The slide documents general aspects of classroom administration.

Training and Study Materials

The slide describes Education Services materials that are available for reference both in the classroom and online.

Additional Resources
The slide provides links to additional resources available to assist you in the installation, configuration, and operation of
Juniper Networks products.

Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and feedback. Depending on the
class you are taking, please complete the survey at the end of the class, or be sure to look for an e-mail about two weeks
from class completion that directs you to complete an online survey form. (Be sure to provide us with your current e-mail
address.)
Submitting your feedback entitles you to a certificate of class completion. We thank you in advance for taking the time to
help us improve our educational offerings.

Juniper Networks Education Services Curriculum

Juniper Networks Education Services can help ensure that you have the knowledge and skills to deploy and maintain
cost-effective, high-performance networks for both enterprise and service provider environments. We have expert training
staff with deep technical and industry knowledge, providing you with instructor-led hands-on courses in the classroom and
online, as well as convenient, self-paced eLearning courses.
Courses
You can access the latest Education Services offerings covering a wide range of platforms at 
http://www.juniper.net/training/technical_education/.

Juniper Networks Certification Program

A Juniper Networks certification is the benchmark of skills and competence on Juniper Networks technologies.

Juniper Networks Certification Program Overview

The Juniper Networks Certification Program (JNCP) consists of platform-specific, multitiered tracks that enable participants
to demonstrate competence with Juniper Networks technology through a combination of written proficiency exams and
hands-on configuration and troubleshooting exams. Successful candidates demonstrate a thorough understanding of
Internet and security technologies and Juniper Networks platform configuration and troubleshooting skills.
The JNCP offers the following features:
• Multiple tracks;
• Multiple certification levels;
• Written proficiency exams; and
• Hands-on configuration and troubleshooting exams.
Each JNCP track has one to four certification levels—Associate-level, Specialist-level, Professional-level, and Expert-level. The
Associate-level, Specialist-level, and Professional-level exams are computer-based exams composed of multiple choice
questions administered at Prometric testing centers worldwide.
Expert-level exams are composed of hands-on lab exercises administered at select Juniper Networks testing centers. Please
visit the JNCP website at http://www.juniper.net/certification for detailed exam information, exam pricing, and exam
registration.

Preparing and Studying

The slide lists some options for those interested in preparing for Juniper Networks certification.

Junos Genius
The Junos Genius application takes certification exam preparation to a new level. With Junos Genius you can practice for
your exam with flashcards, simulate a live exam in a timed challenge, and even build a virtual network with device
achievements earned by challenging Juniper instructors. Download the app now and Unlock your Genius today!
Find Us Online
The slide lists some online resources to learn and share information about Juniper Networks.

Find Us Online
The slide lists some online resources to learn and share information about Juniper Networks.

Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice them now so that your
instructor can best address your needs during class.
This chapter contains no review questions.

Chapter 2: UTM Overview

We Will Discuss:
• The challenges that branch offices present to network managers;
• The major features of Unified Threat Management (UTM);
• How each major feature addresses the challenges of the branch office;
• The SRX hardware devices on which UTM is available; and
• The UTM features that require specific licenses.
Chapter 2–2 • UTM Overview www.juniper.net

Branch Office Challenges

The slide lists the topics we will discuss. We discuss the highlighted topic first.
www.juniper.net UTM Overview • Chapter 2–3

Branch Office Vulnerabilities

A branch office network in today’s market significantly contributes to the bottom line and is central to an organization’s
success. Branch offices normally include a relatively smaller number of computing resources when compared to central
facilities or headquarters locations. Branch offices are typically located where customer interactions occur, which means
there is increased demand for supporting applications and assuring application performance, an increased demand for
security. General security vulnerabilities exist for every branch office network. These vulnerabilities include spam and
phishing attacks, viruses, trojans and spyware infected files, unapproved website access, and unapproved content.

UTM Provides and Enforces Security

UTM security features are provided in the branch SRX devices, enabling a business to protect itself from spam, viruses,
worms, spyware, trojans, and malware. With UTM, you can implement a comprehensive set of security features that include
antispam, antivirus, Web filtering, and content filtering protection. These UTM features provide the ability to prevent threats
at the SRX gateway before the threats enter the network.
Note that, starting in Junos OS Release 12.1X46-D10, Sophos antivirus, antispam, content filtering and enhanced Web
filtering features are supported on all SRX Series devices. That is, the high-end SRX Series is now supported for these
features as well.

UTM Overview
The slide highlights the topic we discuss next.

UTM Features Are Performed in the Flow Module Services

The slide shows how traffic is forwarded through the Junos operating system flow module, and at which steps UTM features
are performed. The flow module is integrated into the forwarding path, where the hardware performs data-plane packet
forwarding. The flow module performs UTM features during the services processing. Intelligent packet processing ensures
that one single thread exists for packet flow processing associated with a single flow. Real-time processes enable the Junos
OS to perform session-based packet forwarding. The unified threat management process (UTMD) performs the UTM features
and protects the network from all types of attack. The flowd module and logical packet flow are described in more detail in
the JSEC and AJSEC courses.

UTM Traffic Processing Overview

The slide shows UTM traffic processing occurring within the Junos flow module services. As traffic travels inbound on an
interface of the SRX device, security policies process the traffic. If the security policy contains a UTM policy that specifies the
traffic being evaluated, a TCP proxy is used to process the matching traffic. The TCP proxy is used for both a TCP client and
TCP server, to terminate and originate a TCP session. The TCP proxy feeds the data stream to the application proxy. The
application proxy contains a protocol parser, which extracts the application protocol information. The protocol information is
evaluated by the various UTM feature modules.

Antispam
The SRX Series for the branch provides comprehensive UTM features to protect against network-level and application-level
attacks, and simultaneously stops content-based attacks. The antispam feature tags or blocks unwanted e-mail traffic by
scanning inbound and outbound SMTP e-mail traffic.
Antivirus
The antivirus feature uses a scanning engine and virus signature databases to protect against virus-infected files, trojans,
worms, spyware, and other malicious code.
Content Filtering
Content filtering provides basic data loss prevention functionality. Content filtering filters traffic based on MIME type, file
extension, and protocol commands.
Web Filtering
Web filtering is an option that can use either a local Websense server or Internet-based SurfControl server. Web filtering is
critical as a service for tracking productivity and corporate user behavior.

Design Basics

Design Considerations
Some UTM features require additional CPU processing, such as antivirus. Available memory and CPU cycles limit the number
of files that can be simultaneously scanned, as well as the size of files that can be scanned. Different antivirus options exist
to accommodate different levels of CPU and memory usage. We discuss antivirus options in more detail in Chapter 4.
Configuration Components
The custom-objects hierarchy level is where you first begin to implement UTM on the SRX device. Custom objects are
global parameters for all UTM features, and are used to create object lists. These object lists contain the building blocks of IP
addresses, domain names, e-mail addresses, URL websites, and so on, used in the different UTM feature profiles. The
majority of UTM settings are configured within the feature profile. The feature profile defines the operation of each UTM
feature. For example, the antivirus feature profile settings control how a protocol is scanned, and what the action will be
when spam is identified. The UTM policy is the central point where all the different feature profiles of UTM are applied.
Security policies reference the UTM policy so that as traffic passes between zones, the SRX device can offer the increased
security that UTM provides.

UTM Policy Flow

The UTM policy within the Junos OS leverages security policies as a central point where traffic is classified and directed to
the appropriate modules for processing. Traffic traversing the security zones of the SRX device are matched against a
security policy. If the security policy contains a UTM policy that matches a protocol supported by UTM, namely SMTP, Post
Office Protocol 3 (POP3) or Internet Message Access Protocol (IMAP), Hyptertext Transfer Protocol (HTTP), or FTP, then the
application protocol data is sent to the UTM feature profile. Each feature profile determines the specific configuration for
each feature (antivirus, content filtering, Web filtering, and antispam).

Display UTM Sessions and Status

The slide shows the CLI commands to verify UTM operation. The outputs shown are from an SRX240 device. The show
security utm session command displays general UTM session information including maximum UTM sessions,
allocated UTM sessions, and active UTM sessions. Any session matching a security policy with a UTM profile attached and
using one of the protocols configured for UTM (HTTP, IMAP, POP, SMTP, or FTP) will count as a UTM session. The show
security utm status command displays whether the UTM service is running.

Hardware Support

UTM Hardware Support

UTM features are only supported on high memory branch SRX platforms. You can verify the version (high memory or low
memory) of the SRX device by running the show chassis hardware command. The slide displays the output for this
command. The chassis description will contain either an H or B after the SRX platform model number. In this case, the
output shows SRX240H. The H indicates high memory, and the B indicates a base memory (low memory) version. UTM
requires the Junos OS version to be 9.5 or later. The SRX100 does not have a Content Security Accelerator (CSA), which is
used with express antivirus, to improve data throughput performance.

Chassis Cluster Support for UTM Features

UTM functionality is supported in both active/active and active/backup chassis cluster configurations. This feature
introduces UTM support for active/active chassis cluster configurations where the Packet Forwarding Engine (PFE) can be
active on both the cluster nodes. UTM supports stateless PFE active/active chassis cluster configurations, where the UTM
state is not synchronized between the cluster nodes. UTM with chassis cluster supports several failover types:
• Manual failover
• RG0 automatic failover
• RG1+ automatic failover
• Failover through flowd restart
• Failover through reboot
Chassis cluster support is enabled for the following UTM features:
• Antispam
• Express antivirus scanning
• Full file-based antivirus scanning
• Content filtering
• Web filtering

Proxy Server Support for UTM Features

Proxy server support for UTM features is supported on SRX100, SRX210, SRX220, SRX240, SRX650, and all J Series
devices. In certain enterprise networks, the internal network device might not have direct access to the Internet, and the
device reaches the Internet only through a proxy server. The branch SRX devices support UTM feature functionality through a
proxy server.

Licensing Features

Licensing
The slide illustrates which UTM features require a license.

Verify UTM Licensing

Licenses must be used for successful operation of UTM features. The slide displays the output of the show system
license command. The output shows the licenses installed for each UTM feature. We cover installation and verification of
UTM licenses in Lab 1.

We Discussed:
• The security challenges of branch offices;
• The features which UTM offers;
• How each UTM feature addresses the challenges of the branch office;
• The SRX hardware devices on which UTM is available; and
• The UTM features which require specific licenses.

Review Questions
1.
2.
3.

Initial Setup Lab

The slide provides the objectives for this lab.

Answers to Review Questions
1.
The four supported features of UTM are antispam, antivirus, Web filtering, and content filtering.
2.
A UTM policy is used to apply a UTM feature profile to application traffic. A security policy is used to evaluate traffic between security
zones of the SRX device. A UTM policy is applied to a security policy.
3.
The UTM features or subfeatures that do not require licensing are content filtering, Websense Web filtering, and local list Web filtering.

Chapter 3: Antispam
We Will Discuss:
• Antispam methods and terminology;
• How Unified Threat Management (UTM) examines traffic for spam;
• The configuration of an effective antispam UTM policy; and
• The verification and monitoring of an antispam operation.
Chapter 3–2 • Antispam www.juniper.net

Methods and Terminology

www.juniper.net Antispam • Chapter 3–3

What Is Spam?
Spam consists of unwanted e-mail messages. These e-mail messages are usually sent by commercial, malicious, or fraudulent
entities. Antispam is the ability to prevent spam before it enters the network. Antispam is one of several features—including
content filtering, antivirus, and Web filtering—that make up Juniper’s UTM suite on the SRX Series Services Gateway device. The
antispam feature examines transmitted e-mail messages to identify spam. When the device detects a message deemed to be
spam, it blocks the e-mail message or tags the e-mail message header or subject with a preprogrammed string. Note that the
antispam feature is not meant to replace an existing antispam server on the network, but to complement it. Two methods for
performing antispam on the SRX device exist, which we discuss next.

Using an External Spam Block List Server to Identify Spam

The first type of antispam method we discuss is server-based antispam. Server-based antispam means that the SRX device
uses a third-party vendor spam block list (SBL) server over the Internet to identify and eliminate spam. The SBL server uses
a constantly updated, IP-based spam blocking service. It stays current by constantly adding to its IP list of known spammers.

SBL Server Requirements and Restrictions

The SRX device must meet a few requirements to use the SBL server. First, you must have a valid antispam license
purchased and installed on the SRX device (like the licenses you installed during Lab 1).
Also, you must have Internet connectivity with the SBL server. The entry for the third-party SBL server is predefined on the
SRX device, and it is not configurable. Juniper has partnered with a particular vendor (Sophos) to provide server-based
antispam functionality.
Additionally, the Domain Name System (DNS) must be available to access the SBL server. Therefore, a name-server entry
must be properly defined and working on the SRX device. The SRX device performs the SBL lookups through the DNS. The
SBL lookups are performed against the IP address of the e-mail sender or relaying agent. The DNS server then forwards each
request to the SBL server, which returns a DNS response to the SRX device. The SRX device looks at the DNS response to
determine if the e-mail sender is a spammer.
This process automatically occurs when inbound or outbound e-mail traverses the SRX device. You can manually test or
query the SBL server to determine whether an IP address is identified as spam. We discuss this process later in the chapter.

Locally Filter IP Addresses, Domain Names, and E-Mail Addresses

The second method of antispam filtering is the use of local lists. This method allows you to manually add an IP address,
domain name entry, or e-mail address to whitelists and blacklists. The SRX device stores and enforces these lists locally. No
license is required for local list spam filtering.
We discuss the nature of whitelists and blacklists on the next slide.

Whitelist
The slide defines whitelists and blacklists. A whitelist identifies known good e-mail senders that you want the SRX device to
accept. The e-mail messages that match a source on the whitelist are deemed harmless. A match allows the e-mail traffic
through the SRX device.
Blacklist
A blacklist contains the e-mail sources that you want the device to reject. The e-mail messages that match the blacklist are
deemed malicious. A match either blocks the e-mail message or tags the message, depending on the action specified in the
antispam profile configuration. The tag option allows you to configure a message in the e-mail subject line, or in the protocol
header of the packet. When you choose to tag the subject line, a user-defined string is added at the beginning of the subject
of the e-mail. When you choose to tag the header, a user-defined string is added to the protocol header of the packet.
You can configure entries on either list by IP address, e-mail address, or domain name. You can use asterisk * or question
mark ? wildcards on the local lists. You must precede all wildcard URLs with http://. You can only use the asterisk * wildcard
character if it is at the beginning of the URL and is followed by a period. You can only use the question mark ? wildcard
character at the end of the URL. The following wildcard syntax is supported: http://*.juniper.net. The following wildcard
syntax is not supported: http://*.

Order of List Checking

The SRX device follows a specific order for checking antispam. The device first checks incoming e-mail against local
whitelists and blacklists. If no match exists on either of these lists, the SRX device queries the SBL server for a match. If a
match exists on any of these lists, the SRX device takes the action—depending upon which list was matched, and the default
spam action either blocks or tags.
Order of Match Importance

When configuring the local lists, you should know how the SRX device checks the lists. The sender’s IP address is checked
first on the whitelist, and then the blacklist, and then the SBL server. If no matching IP address is found, the device checks
for the sender’s domain name on the whitelist, and then the blacklist. If no matching domain name is found, again the
device looks for the sender’s e-mail address, again on the whitelist first, and then the blacklist.
On either list, if multiple domain suffixes are configured, the SRX device matches against the longest suffix. For example, if
the sender’s e-mail address has a domain name aaa.bbb.ccc, the SRX device looks to match “aaa.bbb.ccc”. If no match is
found, it will try to match “bbb.ccc”, then “ccc”. The SRX device cannot do a partial match against IP addresses. Once a
match occurs on a list, no more matching is processed.

Antispam Traffic Examination

The slide highlights the topic we will discuss next.

SMTP
End users use SMTP to send outbound e-mail, but they do not use SMTP to receive e-mail. On the slide diagram, User 1 is
sending an e-mail to User 2. The arrows show the path of the e-mail message. SMTP is used to send User 1’s e-mail message
to her local e-mail server. SMTP is again used to relay the message across the Internet to User 2’s local e-mail server. After
User 2’s e-mail server receives the inbound e-mail message, the client connection between User 2 and his local e-mail
server synchronizes through either Post Office Protocol 3 (POP3) or Internet Message Access Protocol (IMAP). This distinction
is important because as of Junos OS Release 12.1, the antispam feature supports filtering only on SMTP. It does not support
antispam filtering on POP3 nor IMAP.

Identifying Spam
Identifying spam means identifying the senders of spam e-mail. The SBL server filters on an IP-based blacklist, and it
considers IP addresses included in the lists to be invalid addresses for mail servers. Criteria must be met to list an e-mail
server’s IP address as spam.
The SBL criteria to determine spam includes the following:
• Running an open relay service;
• Running an open proxy (of various kinds);
• Zombie hosts;
• Dynamic IP range (which will unlikely host a mail server); and
• A confirmed spam source (known IPs owned by spammers).
When no positive identification exists for spam on an e-mail message, the e-mail message passes normally.

Handling Identified Spam

Once the SRX device identifies spam, it either blocks or tags the e-mail traffic. Blocked spam is dropped at either the
connection level or e-mail level.
Blocked at the connection level:
• When the SMTP sender is identified as a spam sender based on its IP address or domain name, the SMTP
connection is rejected.
• An error message with a corresponding SMTP error code is sent to close the connection.
Blocked at the e-mail level:
• When the SMTP sender is identified as a spam sender based on its e-mail address, the e-mail is rejected.
• An error message with a corresponding SMTP error code is sent back to the sender.
If the SRX device tags spam at the connection level (based on its IP address or domain name), it tags all e-mails on the
connection. Otherwise, if the SRX device tags spam at the e-mail level, it tags just the individual e-mail message. The SRX
device generates a log message each time it identifies a spam message. The log message contains information about the
spam e-mail’s sender, the type of matching spam filter, and what action the SRX device took.

Configuring Antispam

Configuring Antispam
To prevent or reduce the volume of spam messages you receive, you must configure custom objects, an antispam profile, and a
UTM policy.
If you are using local list spam filtering, you must configure whitelists and blacklists under custom objects. If you are using only
server-based spam filtering, you do not have to configure the local lists under custom objects.
The antispam feature-profile is where you apply any local lists that are configured. The feature-profile also
includes the configuration for the default spam action. Note that when you configure the antispam profile, you must either
enable or disable the SBL server.
Next, you create a UTM policy that references the antispam profile. Finally, you assign the UTM policy to a security policy.

CLI Antispam Configuration

The slide examines the command-line interface (CLI) configuration for the UTM custom objects and feature profile for
antispam. Under the custom-objects hierarchy, you configure the local whitelists and blacklists. Remember the
matching order of the entries: by IP address, then domain name, then e-mail address.
Under the feature-profile hierarchy, you apply the whitelists and blacklists, as well as configure the antispam profile
settings under the sbl hierarchy level. After giving the profile a name (in this case we named the profile profile1), you
can specify to use the SBL server with the configuration statement sbl-default-server. If you are not going to use the
SBL server, configure no-sbl-default-server. You must configure no-sbl-default-server if you are only going
to use local list filtering.
Next, you specify the spam action, whether it is block or tag under the spam-action hierarchy (the command to block is
block). With the spam action tag-subject, you can add a user-defined string the subject line of the e-mail message.
With the spam action tag-header, the user-defined string is added to the e-mail header. You can specify only one tagging
action.

Antispam UTM Policy

The slide demonstrates how to configure the UTM and security policies.You choose the name for the UTM policy. On the
slide, the policy is named spam1. Then, under the anti-spam level of the UTM policy, you specify the smtp-profile. In this
case, the profile is named profile1. This profile is the SBL profile you created on the previous slide, under the feature
profile.
Next, apply the UTM policy to the security policy. Be sure to verify that the security policy is the one referencing the two
correct zones; the first zone is from where the external SMTP traffic comes, and the second zone is where your SMTP server
is located.
Apply the UTM policy to the appropriate security policy using the application-services extended permit action, as
demonstrated on the slide.

J-Web UTM Objects Configuration

This slide demonstrates how to configure the UTM custom objects using the Junos Web user interface (J-Web). To access the
UTM configuration workspace, select the Configuration tab at the top and then select Security > UTM > Custom
Objects from the sidebar menu. You begin by configuring the custom objects so that they can be used in the feature profile
and UTM policies.

J-Web Antispam Configuration

The slide demonstrates how to configure the antispam profile using the J-Web. Note that the custom objects must already be
defined (which is shown on the previous slide), so that the whitelists and blacklists can be applied to the antispam profile.
The user-defined profile shown on the slide is named test. When you edit the profile, you can use the default SBL server, or
you can use the default action for identified spam. In this case, the tag-subject option is selected, with the custom tag
string ***spam*** to appear in the subject line of the spam e-mail.
Notice also that another profile is shown on the screen named junos-as-defaults. This profile is a predefined system
profile, preconfigured with the antispam fallback options. You can view the defaults by using the following operational mode
command:
user@srx> show configuration groups junos-defaults security utm feature-profile
anti-spam
sbl {
profile junos-as-defaults {
sbl-default-server;
spam-action block;
custom-tag-string ***SPAM***;
}
}

Verifying Antispam Operations

The slide introduces the test command, which you use to determine whether an e-mail sender will be identified as spam.
The command is shown on the slide.
When an IP address is specified in the test string, the device checks both local whitelists and blacklists, and the SBL server.
With a non-IP address test string (in other words, domain name or an e-mail address), the device checks only the local lists.
Two examples of this command are shown on the slide. The first command matches an IP address that is configured on the
local blacklist. Note that the returned query value reports the IP address as spam. The second example matches against the
domain name string juniper.net. The string is not matched against any list, and returns a value of NON SPAM.

Monitoring Antispam
The slide introduces the commands to verify and monitor antispam operation on an SRX device. The first of these
commands shows how many e-mails are scanned, tagged, or dropped:
user@srx> show security utm anti-spam statistics
UTM Anti Spam statistics:
Total connections: 3
Denied connections: 0
Total greetings: 3
Denied greetings: 0
Total e-mail scanned: 3
White list hit: 1
Black list hit: 2
Spam total: 2
Spam tagged: 2
Spam dropped: 0
DNS errors: 0
Timeout errors: 0
Return errors: 0
Invalid parameter errors: 0
Continued on the next page.

Monitoring Antispam (contd.)
Statistics start time: 11/12/2010 16:32:13
Statistics for the last 10 days (permitted emails / spams):
day 1: 1/2
The output shows the total number of e-mail messages, how many hit the whitelist or blacklist, and the total number of spam
messages.
The next show command displays the antispam status for connections, including whitelist and blacklist server information:
user@srx> show security utm anti-spam status
SBL Whitelist Server:
SBL Blacklist Server:
msgsecurity.juniper.net
DNS Server:
Primary : 208.67.222.222, Src Interface: ge-0/0/0
Secondary: 0.0.0.0, Src Interface: ge-0/0/8
Ternary : 0.0.0.0, Src Interface: ge-0/0/9
This command is especially helpful when verifying the SBL server status. From the output of this command, we see that the
domain name used to reach the SBL server is msgsecurity.juniper.net, and we see also that the DNS server is specified. The
output of this command also lists the source interface used to reach the DNS server.
In addition, an SRX device creates log messages each time spam is identified. Use the pipe symbol (|) and match option to
display only the antispam log messages.
show log messages | match antispam
The slide shows two examples of log messages, both reporting that spam has been identified for nancy@utm.juniper.net. The
first log results from the spam action configured as block. When this action is configured, the log message states Deny
reason. The second message results from the spam action configured as tag-subject. When this action is configured,
the log message states Tag email subject reason.

Case Study

Case Study: Antispam Implementation

The slide illustrates the topology we use for the next several slides. To make things simple, we focus on a single, external
domain (xyz.com) to send inbound SMTP traffic through the SRX240 device.
The objectives for this case study are shown on the slide.

UTM Configuration
The first part of the UTM configuration is the custom objects. The local whitelist and blacklist have been defined. In this
configuration, the whitelist is named white and the blacklist black. The white list contains the domain name xyz.com.
The black list contains the e-mail address spam@xyz.com. Because of how the lists are processed, this configuration
accomplishes the objective in the case study. The e-mail address spam@xyz.com will be blocked, whereas all other e-mails
from xyz.com will be allowed.
The next part of the configuration is the antispam feature-profile. You apply the whitelist and blacklist using the
address-whitelist and address-blacklist commands. You create the antispam feature profile under the [edit
security utm feature-profile anti-spam sbl] hierarchy. This profile allows you to enable the SBL server and
define the default spam action. In this case study, we enable the SBL server and specify the default action to tag the subject
line of the spam e-mail messages.

UTM and Security Policy Configuration

The slide shows how to configure and apply the UTM and security policies. In the UTM policy, you must configure an
antispam smtp-profile. This profile is the name of the SBL profile specified on the previous slide, under the
feature-profile hierarchy for antispam.

Name Server Configuration

With the SBL server enabled, you must also configure the name-server (DNS server). The address shown in the example
on the slide is a public DNS server.

Verifying Antispam Operations

The slide demonstrates how to test the antispam profile to verify that what we configured on the lists will be properly
matched. The CLI command is specifically testing the string “spam@xyz.com”, which we configured under the blacklist. The
output on the slide shows that the SRX device identifies the string as spam (because it matched the local blacklist).

We Discussed:
• Antispam methods and terminology;
• How UTM examines traffic for spam;
• The configuration of antispam profiles, custom objects, and UTM policies; and
• The verification and monitoring of an antispam operation.

Review Questions
1.
2.
3.

Antispam Lab
The slide provides the objective for this lab.

1.
The global UTM configuration elements of antispam are whitelists and blacklists, configured as custom objects.
2.
The match importance order for identifying spam is IP address on the whitelist, IP address on the blacklist, IP address on the SBL
server, domain name on the whitelist, domain name on the blacklist, e-mail address on the whitelist, and e-mail address on the blacklist.
3.
The CLI commands to verify antispam operation are test security utm anti-spam profile profile-name test-string test-string, show
security utm anti-spam status, and show security utm anti-spam statistics.

Chapter 4: Full File-Based Antivirus and Express Antivirus

We Will Discuss:
• How the antivirus process examines traffic;
• Differences between full file-based and express antivirus;
• Antivirus configuration settings;
• Available scanning options for supported protocols; and
• Verifying antivirus functionality.
Chapter 4–2 • Full File-Based Antivirus and Express Antivirus www.juniper.net

Antivirus Terminology
www.juniper.net Full File-Based Antivirus and Express Antivirus • Chapter 4–3

What Is a Virus?
A virus is executable code that infects or attaches itself to other executable code to reproduce itself. Malicious viruses erase
files, lock up end host systems, or otherwise interfere with network operation. Other viruses merely infect files and
overwhelm the target host or network with bogus data. Additional virus-related threats include trojans, rootkits, and other
types of malicious code. Viruses are usually spread by attaching themselves as files or scripts inside protocol traffic.
What Is Antivirus?
Antivirus is an established part of the Unified Threat Management (UTM) suite on the Junos operating system, and is an
important part of any enterprise network security strategy. The antivirus feature of the branch SRX gateway prevents viruses
at the gateway before they enter the network. The SRX device uses an antivirus module that includes both a scan engine and
a virus signature database. The antivirus module compares network traffic against known virus types. If a virus is detected,
the file is dropped, and the originator of the traffic is notified. Antivirus scanning is a separately licensed subscription
service. When your antivirus license key expires, you can continue to use locally stored antivirus signatures without any
updates. But in that case, if the local database is deleted, antivirus scanning is disabled. Administrators can choose
between two different types of antivirus scanning methods. Only one type of scanning method can be applied at a time.

Full File-Based Antivirus Scanning

The first scanning method we discuss is full file-based antivirus scanning. Juniper Networks has partnered with Kaspersky
Lab to provide both the full file-based scan engine and the virus signature database. The full file-based antivirus scan engine
inspects Application Layer data streams, searching for attached files in e-mail messages, Hypertext Transfer Protocol (HTTP)
traffic, and FTP downloads or FTP uploads. This scanning method also searches for embedded scripts when downloading
HTTP Web pages. For the SRX device to scan FTP traffic, the FTP ALG must be enabled.
When the scan engine flags a file or script for inspection, it collects received data packets until it has reconstructed the
original application content, such as an e-mail file attachment, or embedded script. The scan engine caches the file (or
script) in memory and compares it against the virus signature database for a match. Full file-based antivirus scanning has a
high virus-detection rate, and protects against all types of viruses and malicious code, even polymorphic or metamorphic
viruses. These viruses can change themselves. The diagram on the slide shows how the entire file is received and
reconstructed before virus scanning begins. This process is CPU intensive. Available memory and CPU cycles limit the
number of files that can be simultaneously scanned, as well as the size of files that can be scanned.

Express Antivirus Scanning

The second antivirus scanning method is express antivirus scanning. Express antivirus is a less CPU-intensive alternative to
the full file-based antivirus feature. The express antivirus feature, like the full file-based antivirus feature, scans specific
Application Layer traffic for viruses against a virus signature database. However, unlike full file-based antivirus, express
antivirus does not reconstruct the original application content. Express scanning begins to scan data packets as they are
received. With express antivirus, the virus scanning is executed by a hardware pattern-matching engine. This improves
performance while scanning is occurring, but decreases the level of security provided. Express antivirus uses a different
signature database than the full file-based antivirus signature database. The express signature database targets only critical
viruses and malware, including worms, trojans, and spyware. The database is smaller in size, and provides less coverage
than the full file-based antivirus signature database. Express antivirus does not protect against polymorphic or metamorphic
viruses, because these viruses can change themselves. The engine utilizes pattern recognition only and does not use other
heuristics to detect these types of viruses. The diagram on the slide shows file scanning occurring as the file is received,
reducing overall data throughput latency.

Sophos Live Antimalware Protection

Sophos antivirus scanning is offered as a less CPU-intensive alternative to the full file-based antivirus feature. Sophos
supports the same protocols as full file-based antivirus and functions in much the same manner; however, it has a smaller
memory footprint and is compatible with lower end devices that have less memory. The virus pattern and malware database
is located on external servers maintained by Sophos Extensible List (SXL) servers, thus there is no need to download and
maintain large pattern databases on the Juniper device. The Sophos antivirus scanner also uses a local internal scanner
library cache to maintain query responses from the SXL server to improve lookup performance. Queries are performed using
the DNS protocol.

Sophos Live Antimalware Protection (contd.)
Because a significant amount of traffic processed by the SRX is HTTP based, Uniform Resource Identifier (URI) checking is
used to effectively prevent malicious content from reaching the endpoint client or server. The following checks are performed
for HTTP traffic: URI lookup, true file type detection, and file checksum lookup. The following application layer protocols are
supported: HTTP, FTP, SMTP, POP3 and IMAP. Sophos Antivirus has the following main features:
• Sophos Antivirus Expanded MIME Decoding Support: Sophos antivirus offers decoding support for HTTP, POP3,
SMTP, and IMAP. MIME decoding support includes the following for each supported protocol:
– Multipart and nested header decoding
– Base64 decoding, printed quote decoding, and encoded word decoding in the subject field
• Sophos URI Checking: Sophos provides URI checking, which is similar to antispam realtime blackhole list (RBL)
lookups. URI checking is a way of analyzing URI content in HTTP traffic against the Sophos database to identify
malware or malicious content. Because malware is predominantly static, a checksum mechanism is used to
identify malware to improve performance. Files that are capable of using a checksum include: .exe, .zip, .rar,
.swf, .pdf, and .ole2 (doc and xls).

Pattern Matching
The antivirus module for full file-based and express antivirus contains a database with virus signature patterns. The SRX
device checks files against the database for a match. This process is known as pattern matching. Both full file-based
scanning and express scanning perform pattern matching against a virus signature database, but in different ways. Full
file-based antivirus software pattern matching is where the CPU is responsible for performing the task of pattern matching.
The express antivirus scanning engine offloads the pattern-matching operation to a hardware engine, the Content Security
Accelerator (CSA), which significantly reduces CPU and memory usage. The CSA hardware engine is available on the
SRX210, SRX220, SRX240, and SRX650 platforms, and yields higher data throughput performance at the expense of
somewhat lower catch rates. Platforms not equipped with a CSA can still perform software pattern matching, but
performance will be lower (UTM always requires the high-memory option).
Pattern Updates
The virus database must stay current to continually match against new virus threats. Pattern update options are used for
either full file-based or express scanning to allow control of the antivirus engine and signature database updates. To
manually update the virus signature database, specify the URL of the database server. If you do not specify a URL, a default
URL is provided, 
http://update.juniper-updates.net/AV. We discuss the pattern update configuration later in the chapter. The antivirus and
malware database for Sophos antivirus is stored on SXL servers.

Pattern Updates (contd.)
Sophos maintains these servers, so there is no need to download and maintain large pattern databases on the SRX device.
Because the database is remote, there is no size limitation and there is a quicker response to new virus outbreaks. Sophos
antivirus uses a set of data files that must be updated on a regular basis. These are not typical virus pattern files; they are a
set of small files that help guide virus scanning logic. You can manually download the data files or set up an automatic
download.
Intelligent Prescreening
One technique used to increase the effectiveness of antivirus scanning is intelligent prescreening. Full file-based scanning
begins to scan data after the SRX device has received all the packets of a file. Express scanning begins to scan data packets
as they are received, but still scans all the packets of the file. Intelligent prescreening tells the antivirus scan engine to use
the first packet or the first several packets of a file to determine if the file could possibly contain malicious code. The scan
engine does a quick check on these first packets. If it finds that the file is unlikely infected, then the file is safe to bypass the
normal scanning procedure. It is not necessary to store and scan the whole file. Intelligent prescreening behaves the same
for both full file-based and express antivirus scanning. By default, intelligent prescreening is enabled to improve antivirus
scanning performance. You can disable it with the following command:
set security utm feature-profile anti-virus
kaspersky-lab-engine|juniper-express-engine profile profile-name scan-options
no-intelligent-prescreening
Note that the Sophos antivirus method does not provide the same intelligent prescreening detection as full file-based and
express antivirus scanning. Sophos does provide a similar solution that is part of the Sophos engine and cannot be turned
on and off.

Antivirus Process Overview


SRX Antivirus Module

The antivirus module is the software subsystem on the SRX device that scans specific Application Layer traffic to protect
users from virus attacks and prevent viruses from spreading. The antivirus module analyzes traffic and sends data to a scan
engine for virus scanning. The software subsystem consists of an application proxy, a scan manager, a scan engine and a
virus signature database. A client establishes a TCP connection with a server and then starts a transaction. If the antivirus
module is interested in the application protocol used, the traffic will be forwarded to the application proxy and the traffic gets
parsed for attached files. The scan manager monitors the antivirus sessions and checks the properties of data content
against the antivirus settings. If a scan request is sent out, the scan engine scans the data and queries the virus signature
database. After scanning, the result is handled by the scan manager.

Full File-Based Scanning

The slide shows the full file-based antivirus flow process. The scan engine for this process is provided by Kaspersky Lab, as
well as the virus signature database. When scanning is enabled, TCP data packets come into the SRX device and are
handled by the TCP proxy. The protocol parser inspects HTTP, e-mail, and FTP data streams, searching for attached files or
embedded scripts. Scripts can be found when downloading Web pages. When the protocol parser flags a file for inspection,
it caches the file (or embedded script) in memory to reassemble the original application content, and uses the scanning
engine to search for viruses, trojans, rootkits, and other types of malicious code. If a virus is detected, the file is dropped
immediately, and the sender of the traffic is notified. If no virus is found the traffic is forwarded through the SRX device.

Express Antivirus Flow Process

The slides demonstrates the express antivirus flow process. Express antivirus uses a modified version of the Kaspersky
signature database. Express antivirus catch rates are lower than full file-based antivirus, but express antivirus is able to
catch the most common viruses. The main advantage that express antivirus provides is higher throughput, as processing is
hardware accelerated. Files are not locally stored, and packets can be inspected as they are forwarded through the SRX
device. Packets still have to go through a TCP proxy and data buffer because TCP streams must be reassembled and packets
must be reordered. Express antivirus minimizes transfer delays because packets can be forwarded while virus scanning is
taking place.

Global Antivirus Settings

The antivirus module has global, policy-based, and profile-based settings. Global settings are general overall configurations
for the antivirus module or settings that are not specific to an antivirus profile. Global antivirus settings include UTM custom
objects, where you can configure whitelists for specific HTTP traffic to bypass antivirus scanning. We discuss the operation
and configuration of these lists later in the chapter.
Policy-Based Antivirus Settings

Policy-based antivirus settings are configured through UTM policies. UTM policies control which protocol traffic is sent to the
antivirus scanning engine. The UTM policy has antivirus profiles for FTP, HTTP, POP3, SMTP, and IMAP traffic. The UTM policy
is applied to a security policy, which determines if the protocol of a traffic flow matches the antivirus profile. If the protocol
traffic matches, it is sent to the antivirus module for virus scanning.
Profile-Based Antivirus Settings

The majority of antivirus settings are configured within the antivirus feature profile. Profile-based antivirus settings control
how each protocol is scanned within the antivirus module. The antivirus feature profile settings include the scanning options,
such as scan type, scan mode, content size limits, scanning timeout values, session throttling, and settings for scanning
compressed files. The feature profile settings also define fallback and notification options.

Antivirus Operation

Scan Mode All
The scanning options for full file-based scanning allow you to configure one of two different scan modes: all or
by-extension. When the scan mode is set to all, the antivirus scanning engine scans every file regardless of the file
extension. The diagram on the slide shows both inbound and outbound traffic passing different file types through an
SRX240. Each of the file types shown are processed for antivirus scanning. Note that, if you have an SRX device protecting
an internal network that has no HTTP traffic, or has Web servers that are not accessible to the outside world, you might want
to turn off URI checking. If the Web servers are not accessible to the outside world, it is unlikely that they contain URI
information that is in the Sophos URI database.

Scan Mode By-Extension

The diagram on the slide shows an SRX240 using the by-extension scan mode. In this mode, the SRX device bases all
scanning decisions on the traffic’s file extension. Only files that have a file extension matching the extension list are
scanned. In the diagram, the local user sends a file with an extension XSLT, which does not match the file extension list, and
is not scanned by antivirus. The SRX device has a default file extension list already preconfigured. To view the list, run the
command shown on the slide.
You cannot modify the default file extension list. However, you can configure a custom filename extension list to be used
instead of the default list. We demonstrate the configuration for a custom filename extension list later in the chapter. If a
file’s extension is not found on an extension list, the file is not scanned. If the file has no extension, the file is scanned for
viruses.

Scanning Compressed Files

The slide shows additional full file-based scanning options. The SRX antivirus feature supports compressed data detection,
in case a virus is sent inside compressed data. Three kinds of compressed data exist: a compressed file (zip, rar, gzip),
encoded data such as Multipurpose Internet Mail Extension (MIME), and packaged data (OLE, CAP, MSI, TAR, EML). As the
virus signature database becomes larger and the scan algorithms become more sophisticated, the scan engine has the
ability to look deeper into the data for embedded malware. As a result, it can uncover more layers of compressed data.
Scanning compressed files is only supported for HTTP and POP3 traffic. Some files can be compressed multiple times. The
SRX antivirus feature will decompress layers of files until it reaches either a user-configured decompress limit, or the device
decompress layer limit, based on memory allocation. If a file exceeds the compression layer limit, the scan engine either
drops or forwards the file based on the configured fallback options.
Content Size Limits

Antivirus requires the contents of files to be stored in memory to scan files for viruses. Because of resource constraints, a
default device-dependent limit exists on the maximum content size for a file. The content size usually refers to file size,
according to the content length field of the protocol header, or content size refers to the accumulated TCP payload size of the
received packets. The limit for maximum content size is user-configurable. If a file exceeds the content size limit, the scan
engine either drops or forwards the file based on the configured fallback options.

Scanning Timeout Values
The SRX device can use a scanning timeout value for files that take too long to scan. The timeout value covers the time
duration from when the scan request is generated to when the scan result is returned by the scan engine. The range is 1 to
1800 seconds. By default, it is 180 seconds. It is a parameter used in all protocols and each protocol can have a different
value.
Session Throttling
Session throttling restricts the amount of traffic a single source can consume at one time. The limit is an integer with 100 as
the default setting. This integer refers to the maximum allowed sessions from a single source. You can change this default
limit, but understand that if this limit is set high, the setting is comparable to no limit.

HTTP Antivirus Scanning Example

You can turn antivirus scanning on and off on a per protocol basis. If scanning for a protocol is disabled in an antivirus
profile, no application intelligence exists for this protocol, and in most cases, traffic using the protocol is not scanned. But if
the protocol in question is based on another protocol for which scanning is enabled in an antivirus profile, then the traffic is
scanned as that enabled protocol. The internal antivirus scan engine supports scanning for specific Application Layer
transactions allowing you to select the content (HTTP, FTP, SMTP, POP3, or IMAP traffic) to scan.
The slide shows a general example of how HTTP traffic is intercepted and scanned. Host-A sends an HTTP request to a
webserver. The SRX antivirus module intercepts the request, and parses the protocol for files or scripts. When a file or script
is identified, the data is passed to the antivirus scanner, which scans the data for viruses. After completing the scan, the
antivirus scan engine follows one of two courses. If no virus is detected, the device forwards the request to the webserver. If
a virus is detected, the device drops the request and sends an HTTP message reporting the infection to the client. Antivirus
scanning is supported for HTTP GET, POST (includes HTTP upload), and PUT methods. RFC 2616 is the reference for these
protocol methods. HTTP 1.0 and 1.1 are supported.
HTTP trickling is a time-based mechanism used to prevent the HTTP client or HTTP server from timing-out during antivirus
scanning. HTTP trickling forwards unscanned HTTP traffic to the requesting HTTP client to prevent the browser window from
timing out while the scan manager examines downloaded HTTP files. The SRX device forwards small amounts of data in
advance of transferring an entire scanned file. By default, trickling is disabled. HTTP trickling is only supported for HTTP
connections.

Sophos Live Protection Example

The slide demonstrates an example of Sophos live antimalware protection.

Antivirus Whitelists
When the SRX antivirus module parses traffic, it can identify file types that are not considered harmful and should not be
scanned. HTTP MIME headers and URL information can be used to obtain information about the file type being carried. The
URL whitelist is used in the Web filtering UTM feature, where URLs or IP addresses are always not scanned. The URL whitelist
specifies traffic that can bypass antivirus scanning. The SRX device also uses MIME types to decide which traffic can bypass
antivirus scanning. The slide shows the order of HTTP processing with regards to antivirus scanning. URL whitelists are
matched against first, followed by MIME whitelists. If no match occurs on either whitelist, the antivirus feature profile
settings are followed for virus scanning. The URL and MIME whitelists are only valid for HTTP traffic.

Blocking and Notifications

When the scan engine detects a virus, the file is blocked. Notification options inform users of detected viruses. Different
notification types are available. One option is the notification type message. When content is blocked with the notification
type message, the application client still gets a successful response code, but with modified content containing a warning
message. The warning message can be custom defined. With the notification type protocol-only message, a protocol-specific
error code might be returned to the client, so that the client knows something happened, rather than assuming that the
protocol transfer succeeded. For HTTP and FTP traffic, notifications are piggybacked in the protocols. For example, if a virus
is found while doing an HTTP request, users will see a custom error message on the page they are trying to access. E-mail
notifications for SMTP, IMAP, and POP3 protocols generate an error mail message, notifying the mail recipient (and optionally
the sender) of the offending mail. Three different settings exist for e-mail notifications:
• Virus-detection/notify-mail-sender: When enabled, this e-mail notifies the sender when a virus is detected.
• Fallback-block/notify-mail-sender: When enabled, this e-mail notifies the sender when other scan-codes or
scanning errors are returned and a message is dropped.
• Fallback-non-block/notify-mail-recipient: When enabled, this e-mail notifies the recipient when other
scan-codes or scanning errors are returned and the message is passed.

Scanning Fallback Options
Fallback options specify the actions to take when traffic cannot be scanned. The fallback actions are to either block, or
log-and-permit. Traffic that cannot be scanned because of special conditions fall into the following categories:
• Content-size: If the content size exceeds a set limit, the content is passed or blocked depending on the
max-content-size fallback option. The default action is BLOCK.
• Corrupt-file: Corrupt file is the error returned by the scan engine when engine detects a corrupted file. The
default action is PASS.
• Decompress-layer: Decompress layer error is the error returned by the scan engine when the scanned file has
too many compression layers. The default action is BLOCK.
• Default: All the errors other than those in the above list fall into this category. This could include either
unhandled system exceptions (internal errors) or other unknown errors. The default action is BLOCK.
• Engine-not-ready: The scan engine is initializing itself, for example, loading the signature database. During this
phase, it is not ready to scan a file. A file could either pass or be blocked according to this setting. The default
action is BLOCK.
• Out-of-resources: Virus scanning requires a great deal of memory and CPU resources. Due to resource
constraints, memory allocation requests can be denied by the system. This failure could be returned by either
scan engine (as a scan-code) or scan manager. When out-of-resources occurs, scanning is aborted. The default
action is BLOCK.
• Password-file: Password protected file is the error returned by the scan engine when the scanned file is
protected by a password. The default action is PASS.
• Timeout: Scanning a complex file could consume resources and time. If the time it is taking to scan exceeds the
timeout setting in the antivirus profile, the processing is aborted and the content is passed or blocked without
completing the virus checking. The decision is made based on the timeout fallback option. The default action is
BLOCK.
• Too-many-requests: If the total number of messages received concurrently exceeds the device limits, the
content is passed or blocked depending on the too-many-request fallback option. The default action is BLOCK.
(The allowed request limit is not configurable.)

Full File-Based Antivirus Configuration


UTM Custom Objects Configuration

The UTM custom-objects hierarchy contains global antivirus configuration settings. You can configure URL and MIME
whitelists, and a filename extension list. The filename extension list is used in by-extension scan mode for full file-based
antivirus. The extension list adds additional file extensions to the default list of extensions to be scanned. The slide shows
the configuration for the URL whitelist, MIME whitelist, and filename extension list. The url-pattern name hierarchy
defines the pattern list name, and value contains the entries for URLs that bypass antivirus scanning. The pattern name is
applied to the custom-url-category value hierarchy level.
The MIME whitelist consists of one or many MIME type entries. The MIME entry is case-insensitive. If the MIME entry ends
with a '/' character, a prefix match is used. Otherwise, exact match is used. Two types of MIME lists exist, a MIME whitelist
and a MIME exception list. The MIME whitelist is used for bypassing antivirus scanning. The MIME exception list is used for
excluding some MIME types from the MIME whitelist. For example, if the MIME whitelist has video/ configured, and the
exception list has video/x-shockwave-flash configured, traffic with MIME type video/ bypasses antivirus scanning,
but traffic with MIME type video/x-shockwave-flash does not bypass antivirus scanning.
The filename extension list contains value entries for file extensions that you want to use instead of the default file extension
list. The filename extension list, MIME list, exception list, and custom URL category are all applied to the antivirus feature
profile.

Automatic Update Configuration

Updates to the pattern file are added as new viruses are discovered. The default antivirus pattern-update interval is 60
minutes. When Kaspersky Lab updates the signatures in its pattern database, the SRX device downloads these updates so
that the antivirus scanner is using the most current signature database when scanning traffic. The process of downloading
updates is the same for both full file-based antivirus and express antivirus protection. The slide shows the configuration for
pattern updates within the antivirus feature profile.
Manually Force an Update

The security device can perform these updates automatically (the default), or you can manually perform a pattern update
using the CLI command shown on the slide.
To verify that the pattern update is successful, run the show security utm anti-virus status command. We
review the output of this command later in the chapter.

Fallback and Notification Options Configuration

The slide shows the configuration for the fallback and notification options for full file-based and express antivirus. These
settings are configured under the antivirus profile.
In contrast, the following fail mode options are supported for Sophos antivirus:
• content-size
• default
• engine-not-ready
• out-of-resource
• timeout
• too-many-requests
The fallback options are taken when traffic is unable to be scanned, and all fallback options have an action of either block
or log-and-permit. The notification options can be configured for fallback-block, fallback-non-block, or
virus-detection.You can configure a custom notification message for all three options. You can specify the notification
type of message or protocol-only for fallback-block and virus-detection options only.

Apply the Antivirus Profile to a UTM Policy

UTM policies control which protocol traffic is sent to the antivirus scanning engine. The UTM policy shown on the slide is
named policy1, and has the antivirus profile av-profile applied for FTP download and HTTP traffic. Therefore, any FTP
download or HTTP traffic that passes where the UTM policy is applied is processed by the antivirus module, and follows the
settings defined in the antivirus profile.
Apply the UTM Policy to a Security Policy

The slide configuration shows the UTM policy policy1 applied to the security policy client-to-server. This policy is
looked at for all traffic that passes between the client and server zones of the SRX device.

J-Web UTM Objects Configuration
This slide demonstrates how to configure the UTM custom objects using the Junos Web user interface (J-Web). To access the
UTM configuration workspace, select the Configuration tab at the top and then select Security > UTM > Custom
Objects from the sidebar menu. You begin by configuring the custom objects so that they can be used in the feature profile
and UTM policies.

J-Web Antivirus Configuration: Part 1

The slide demonstrates how to configure the antivirus profile using the J-Web. Note that the custom objects must already be
defined (which is shown on the previous slide).
The user-defined profile shown on the slide is named av_profile. When you edit the profile, there are four tabs available
containing the main, fallback, and notification options.
Note that there are three additional default profiles present:
• junos-av-defaults
• junos-eav-defaults
• junos-sophos-av-defaults
These are predefined system profiles and are preconfigured with the antivirus default options. You can view the defaults by
using the following operational mode command:
user@srx> show configuration groups junos-defaults security utm feature-profile
anti-virus
#
# should not set no-autoupdate at any time
#

Web Antivirus Configuration: Part 1 (contd.)
kaspersky-lab-engine {
pattern-update {
url http://update.juniper-updates.net/AV/SRX240/;
interval 60;
}
profile junos-av-defaults {
fallback-options {
default log-and-permit;
corrupt-file log-and-permit;
password-file log-and-permit;
decompress-layer log-and-permit;
content-size log-and-permit;
engine-not-ready log-and-permit;
timeout log-and-permit;
out-of-resources log-and-permit;
too-many-requests log-and-permit;
}
scan-options {
intelligent-prescreening;
scan-mode all;
content-size-limit 10000;
timeout 180;
decompress-layer-limit 2;
}
notification-options {
virus-detection {
type message;
no-notify-mail-sender;
custom-message "VIRUS WARNING";
}
fallback-block {
type message;
}
}
}
}
juniper-express-engine {
pattern-update {
url http://update.juniper-updates.net/EAV/SRX240/;
interval 1440;
}
profile junos-eav-defaults {
fallback-options {
}
scan-options {
intelligent-prescreening;
timeout 180;
}

Web Antivirus Configuration: Part 1 (contd.)
virus-detection {
type message;
}
fallback-block {
type message;
}
}
}
}
sophos-engine {
pattern-update {
url http://update.juniper-updates.net/SAV/;
interval 1440;
}
profile junos-sophos-av-defaults {
fallback-options {
}
scan-options {
uri-check;
timeout 180;
}
virus-detection {
type message;
}
fallback-block {
type message;
}
}
}
}


The slide shows the Main and Fallback settings tabs.

The slide shows both Notification options tabs.

Monitoring Antivirus

Verifying Pattern Updates

The output of the show security utm anti-virus status command displays the update server path, the pattern
update status, and last result, as shown on the slide. If the pattern update is successful, the last result will show that either
a new database has been loaded, or that the SRX device already has the latest database. When the pattern update is
successful, the scan engine is ready. If the pattern update is not successful, the scan engine is not ready, and the fallback
option engine-not-ready action is used.

Verify Licensing
A license must be used for successful antivirus operation. The top of the slide shows the output for the show system
license command. The output shows which licenses have been installed. In this case, it shows that the
av_key_kaspersky_engine license has been successfully installed. If the SRX device does not have a license for antivirus, the
show security utm anti-virus status command will display that a license is not installed. Note that the Sophos
antivirus scanning feature is a separately licensed subscription service. Also, the pattern lookup database is located on
remote servers maintained by Sophos, so when your antivirus license key expires, functionality will no longer work. You have
a 30-day grace period in which to update your license.

Antivirus Scan Results

The show security utm anti-virus statistics command displays antivirus statistics for connections including
clean files, infected files, and scan engine status. It also shows statistics for traffic that has matched any of the fallback
options.

Antivirus Log Messages

The slide demonstrates how to match against the log messages to view if any viruses have been detected. Each time a virus
is detected, the SRX device logs a message, indicating the source and destination addresses, the file name, and the source
zone of the traffic.

We Discussed:
• How the antivirus process examines traffic;
• Differences between full file-based and express antivirus;
• Antivirus configuration settings;
• Available scanning options for supported protocols; and
• Verifying antivirus functionality.

Review Questions
1.
2.
3.

Antivirus Lab

1.
The two full file-based scan mode types are all and by-extension. The difference is that scan mode all scans every file
regardless of the file extension, and scan mode by-extension only scans files matching the extension list.
2.
The methods available for HTTP traffic to bypass antivirus scanning are URL and MIME whitelists. They are defined under UTM
custom objects.
3.
Intelligent prescreening improves scanning performance by eliminating the need to store and scan the entire file. It uses the first packet
or the first several packets of a file to determine if the file could possibly contain malicious code.


Chapter 5: Content Filtering and Web Filtering

We Will Discuss:
• The purpose of content filtering and Web filtering;
• The parameters used to configure content filtering and Web filtering;
• Configuring content filtering and Web filtering; and,
• Monitoring content filtering and Web filtering.
Chapter 5–2 • Content Filtering and Web Filtering www.juniper.net

Content Filtering Overview and Terminology

www.juniper.net Content Filtering and Web Filtering • Chapter 5–3

Content Filtering
Content filtering is a feature that allows or blocks traffic based on the Multipurpose Internet Mail Extension (MIME) type, file
extension, protocol commands, and embedded object type. This feature is supported for HTTP, FTP, and mail protocols such
as SMTP, Post Office Protocol 3 (POP3), and Internet Message Access Protocol (IMAP).
Once content is blocked, users can be notified by a custom message or e-mail depending on the protocol.
This feature does not require a license.

Traffic Is Permitted Base on Parameters

Content filtering permits or blocks traffic based on the following parameters:
• MIME pattern: Identifies the type of traffic in HTTP and mail protocols.
• File extension: Identifies the type of traffic by file type.
• Protocol command: Identifies the type of commands protocols use. Using FTP as an example, the protocol
commands are the commands between the FTP client and server, not the commands you type when using FTP.
The following list are protocol command examples for the supported protocols:
– HTTP: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, OTHERS
– FTP: USER, PASS, ACCT, CWD, CDUP,SMNT, REIN, QUIT, PORT, PASV
– SMTP: HELO, EHLO, MAIL, RCPT, DATA, SIZE, QUIT, VRFY, EXPN
– POP3: APOP, DELE, LIST, NOOP, PASS, QUIT, RETR, RSET, STAT, TOP, UIDL, USER
– IMAP: CAPABILITY, NOOP, LOGOUT, AUTHENTICATE, LOGIN, SELECT, EXAMINE

Supported Protocols are HTTP, FTP, and Mail Protocols
HTTP supports all the content filtering attributes which includes MIME patterns, file extensions, and protocol commands.
HTTP traffic can also be blocked based on ActiveX, Java applet, cookies, EXE files, and ZIP files. The content filter checks
every HTTP request between client and server. If the content filter is configured to block the request using the protocol
command list, it drops the request and sends back a page with an explanation. If the request is to download a file, it checks
the response header for MIME type and file extension. The content filter also checks the file header for ActiveX and Java
applet, and drops the response if any of them are configured in the blocked content.
FTP supports the content filtering attributes file extensions and protocol commands. The content filter checks each
command, and drops the command if it is configured in the protocol list or the file extension list. If the command is dropped,
it sends back to the client the custom block message and the reason why. Content filtering support for FTP requires enabling
the FTP ALG.
Mail protocols support the content filtering attributes MIME patterns, file extensions, and protocol commands. Content
filtering has a limited ability with MIME type and file extensions. Only one level of the e-mail header is scanned, which means
recursive e-mail headers are not checked along with any encrypted attachments. Also, if the whole e-mail is MIME encoded,
only the mime type is checked. The content filter checks each command, and drops the command if it is configured in the
protocol list or the file extension list. If the command is dropped, It sends back an error code to the client with the
explanation.
Users Can Be Notified of Blocked Content in Two Ways

A message embedded in the protocol can be sent to the user, or an e-mail message can be sent. In both cases, the content
of the message is configured by the administrator.

Content Filtering Configuration


Content Filtering Configuration Options

A content filter must coincide with a list of custom objects, which is a list of objects you would like to allow or block. The one
exception is with HTTP traffic, which can be configured to block content directly under the content filter.
This slide lists all the configuration options available for custom objects and content filtering.
Custom objects options have the following configuration options:
• MIME pattern: This option enables the creation of a list that can be used for allowing or blocking MIME types. If
the MIME pattern ends with a “/” (as an example, video/), prefix matching takes place. If the MIME pattern
does not end with a “/”, exact matching occurs.
• Filename extension: This option enables the creation of a list for blocking file extensions.
• Protocol command: This option enables the creation of a list that can be used for allowing or blocking protocol
commands. The protocol commands are checked using a case-insensitive string comparison.

Content Filtering Configuration Options (contd.)
Content filtering has the following configuration options:
• Block or permit command: The block-command list indicates the commands that are blocked, and the
permit-command list has been designed as an exception list. If a command exists in the permit-command
list, it will not be blocked, even if it exists in the block-command list. Commands that do not exist in the
permit-command list will be allowed provided that they also do not exist in the block-command list.
• Block extension: Allows you to apply the custom object filename-extension to block files based on the
extension. You can also configure the predefined extension list junos-default-extension. Issue show
groups junos-defaults security utm custom-objects to view predefined custom objects.
• Block MIME: As shown in the slide provided, you can create a list to block MIME type video/, but allow video/
quicktime. The block-mine exception list has a higher priority than block-mime list. You can also configure the
predefined MIME list junos-default-bypass-mime.
• Block content type: You can also block files based on ActiveX, Java applet, cookies, EXE or ZIP file type. The
block-content-type configuration is for HTTP use only. This feature also blocks files that have been
renamed in an attempt to circumvent the block. For example, if you have a ZIP file named myfile.zip and
rename it to myfile.test, it would still be blocked.
• Notification options: Allows for the creation of a custom message sent to the client when traffic is blocked.

Content Filtering Configuration

After you have created a content filtering profile, you create a UTM policy and apply the content filtering profile to the
appropriate traffic you are filtering. The content filtering profile can be applied to multiple protocols. The final step is to apply
the UTM policy to the appropriate security policy.
The slide shows the options available for applying the content filtering profile and where the UTM policy is applied to the
security policy.

Content Filtering Verification and Monitoring


Content Filtering Example for HTTP

This slide illustrates the topology for this example. The next page shows the content filtering configuration steps to block
downloading ZIP files using HTTP.

Configuring Content Filtering

The slide shows the steps for configuring a content filter.
1. Configure the content filtering profile to block ZIP files for HTTP, with a custom message to be displayed in the
webpage.
2. Apply the content filtering profile to the UTM policy, under http-profile.
3. Finally, apply the UTM policy to the appropriate security policy using the application-services extended
permit action.

Verify That Content Filtering Is Working

This slide shows what the client would see in the Web browser after trying to download a ZIP file.

Verify and Monitor Using CLI

The syslog messages logs permitted and blocked content, and the show security utm content-filtering
statistics command counts how many times a custom object or HTTP blocked content has been blocked. The syslog
messages must be configured with a severity of any or info.

Verify and Monitor Using J-Web

The Junos Web user interface (J-Web) provides the same monitoring options as the CLI, and provides further statistics and
graphs to display the blocked traffic.

Web Filtering Overview and Terminology


Web Filtering
Web filtering or URL filtering provides the ability to permit or deny access to specific URLs based on the category to which
they belong. The Web filter intercepts HTTP requests, and a decision is then made with the HTTP request on an external
server (SurfControl or Websense), or on the SRX device (whitelist or blacklist) to permit or block the request.
Web filtering acts as a first line of defense. If a website is a known source of malware, what is easier than blocking access to
that site?
The supported three deployment options:
• SurfControl: This option uses an in-the-cloud server which keeps a database of categories for websites.
• Websense: This option uses a locally administrated server which keeps a database of categories and Web
filtering policies.
• Local lists: This option uses configured whitelists and blacklists on the SRX device.
Once traffic has been blocked, the client can receive a custom message in the Web browser.

Junos Has Four Solutions to Web Filtering

The first and most common Web filtering method is to use the in-the-cloud or Internet SurfControl server. The SurfControl
server stores a database of about 40 categories and associated URLs. The integrated SurfControl option requires the
purchase of a Juniper Web filtering license.
The second option is the use of a local Websense server that must be purchased and managed locally. The Websense server
maintains a database of categories and Web filtering policies. The Websense redirect option does not require a Juniper Web
filtering license.
The third option is the use of local URL blacklists and whitelists. The local lists can be used in conjunction with the
SurfControl or Websense option.
The fourth option is to use enhanced Web filtering. Enhanced Web filtering uses an Internet Websense server that stores a
database of over 95 categories and associated site reputation information. The enhanced Web filtering option requires the
purchase of a Juniper Web filtering license.

SurfControl Integrated Web Filtering Solution

The SurfControl server stores a database of categories and associated URLs. Every time a user tries to access a site, the SRX
device captures the requested URL and queries the SurfControl database. The server responds with the category of the
website, which is used by a Web filtering policy on the SRX device to allow or deny access. The SRX device generates a log
message indicating the action taken. If the action taken was to deny access, a custom message can be sent to the user.
Once a site is associated with a category, the result is cached locally. Subsequent requests for the same URL do not require
a new query to the centralized database. The main advantage of this solution is that users do not need to host the database,
which often requires a redundant server infrastructure.
The SurfControl database features:
• More than 26 million URLs;
• Approximately 40 categories; and
• More than 70 languages.

Websense Redirect Web Filtering Solution

The Websense redirect solution does not require a separate Juniper license, but utilizes a local database, which must be
purchased separately from Websense. As opposed to querying the SurfControl server, the SRX device redirects the URL to
the local Websense server. The Websense server contains both the category database and the Web filtering policies. The
Websense server then compares the URL against its database and returns the result according to its configured policy. The
response is then forwarded to the SRX device indicating whether the URL is allowed or denied.
The Websense redirect server features:
• 95 categories;
• Support for over 100 protocols;
• Local policy evaluation; and
• Logging and reporting support.
This solution has the advantage of minimizing processing delays because the database is locally stored. The disadvantages are
an administrator to keep the database current and multiple servers if you want redundancy.

Local Blacklists and Whitelists

You can also configure custom URL categories, which can be included in blacklists and whitelists that are evaluated on the
SRX device. All URLs for each category in a blacklist are denied, while all URLs for each category in a whitelist are permitted.
The processing order is as follows:
1. A new URL is first compared to the blacklist URLs. If a match is found, the traffic is dropped without any further
processing.
2. If no match is found, the URL is evaluated against the whitelist, where traffic is allowed if a match is found.
3. If no user defined category results in a match, processing continues either by SurfControl or Websense.

Enhanced Web Filtering

Enhanced Web filtering uses an Internet Websense server that stores a database of more than 95 predefined categories
and associated site reputation information. The enhanced Web filtering option requires the purchase of a Juniper Web
filtering license. Enhanced Web filtering intercepts HTTP and HTTPS requests and sends the HTTP URL or the HTTPS source
IP to the Websense ThreatSeeker Cloud (TSC) server. The TSC server categorizes the URL into one of the predefined
categories and obtains site reputation information. The TSC server returns the URL category and the site reputation
information to the SRX device. The SRX device determines if it can permit or block the request based on the information
provided by the TSC, and the feature profile configuration. Enhanced Web filtering supports the following HTTP methods:
• GET
• POST
• OPTIONS
• HEAD
• PUT
• DELETE
• TRACE
• CONNECT

Enhanced Web Filtering (contd.)
The slide demonstrates an example of how HTTP or HTTPS traffic is intercepted, scanned, and acted upon by the enhanced
Web filtering solution. The SRX device makes a TCP socket connection to the TSC server. The SRX device intercepts an HTTP
or HTTPS client connection and extracts each URL in the HTTP request or the IP address in the HTTPS request. The SRX
device verifies whether the URL is in the user-configured blacklist or whitelist. If the URL is in the user-configured blacklist,
the device blocks the URL. If the URL is in the user-configured whitelist, the device permits the URL. If no match against the
local lists exists, the SRX device queries the TSC server for a URL category lookup. The TSC server responds with the URL
category and site reputation information. The SRX device queries the user-defined categories in the feature profile, and
blocks or permits the URL based on the user-specified action for the category.
UTM Enhanced Web Filtering supports block, log-and-permit, and permit actions for HTTP/HTTPS requests. In addition to
this, UTM Enhanced Web Filtering now supports the quarantine action which allows or denies access to the blocked site
based on the user’s response to the message. The quarantine action is supported only for UTM Enhanced Web Filtering or
Juniper-Enhanced type of Web Filtering.
The following sequence explains how the HTTP or HTTPs request is intercepted, redirected, and acted upon by the
quarantine action:
1. The HTTP client requests URL access.
2. The device intercepts the HTTP request and sends the extracted URL to the Websense Thread Seeker Cloud
(TSC).
3. The TSC returns the URL category and the site reputation information to the device.
4. If the action configured for the category is quarantine, the device logs the quarantine action and sends a
redirect response to HTTP client.
5. The URL is sent to the HTTP server for redirecting.
6. The device shows a warning message stating that the access to the URL is blocked according to the
organization’s security policies and prompts the user to respond.
7. If the user response is “No,” the session is terminated. If the user response is “Yes,” the user is allowed access
to the site and such access is logged and reported to the administrator.
The quarantine message sent to the HTTP client is user-configurable and is of the following two types:
1. Default message:
The default quarantine message is displayed when a user attempts to access a quarantined website and
it contains the following information:
URL name
Quarantine reason
Category (if available)
Site-reputation (if available)
For example, if you have set the action for Enhanced_Search_Engines_and_Portals to quarantine, and
you try to access www.search.yahoo.com, the quarantine message is as follows:
***The requested webpage is blocked by your organization's access
policy***
2. Syslog message:
The syslog message will be logged by the system when the user access the web page that has already
been quarantined and marked as block or permit.
The corresponding syslog message on the device under test is:
Jan 25 15:10:40 rodian utmd[3871]: WEBFILTER_URL_BLOCKED: WebFilter:
ACTION="URL Blocked" 99.99.99.4(60525)->74.125.224.114(80)
CATEGORY="Enhanced_Search_Engines_and_Portals" REASON="by predefined
category(quarantine)" PROFILE="ewf-test-profile" URL=www.search.yahoo.com
OBJ=/

Web Filtering Configuration


SurfControl Configuration Options

This slide illustrates the configuration options available for SurfControl Web filtering.
The SurfControl options are:
• Type: This option allows you to configure the type of Web filtering you are using. SurfControl is the default Web
filtering type.
• Cache: This option allows you to configure the size and duration of the cache. The cache is used for the URL
categories from the SurfControl server.
• Server: This option allows you to configure the host or address, and port of the SurfControl server. A server host
or address is required.
• Category: This option allows you to permit or block URLs based on the category with which the SurfControl
server responds. You can also permit or block any custom categories you configure.
• Default: This option allows you to configure a default permit or block action. If a URL does not match a category,
the URL is either permitted or blocked. If the default option is not configured, the URL is permitted.
• Custom block message: This option allows you to configure a custom message. The message will be seen by the
client when a URL is blocked.

SurfControl Configuration Options (contd.)
This list is a continuation of the SurfControl options on the preceding page:
• Fallback settings: This option allows you to permit or block URLs during the following error conditions:
– Default: Default error condition;
– Server connectivity: No connectivity to the Web filter server;
– Timeout: A Web filter request times out; and
– Too many requests: There are too many concurrent requests.
• Timeout: This option allows you to configure the timeout value in seconds, after which a request is considered
to have timed out.

Websense Configuration Options

The slide illustrates the configuration options available for Websense Web filtering.
The Websense options are:
• Type: This option allows you to configure the type of Web filtering you are using. Websense must be configured
or SurfControl will be used.
• Server: This option allows you configure the host or address, and port of the Websense server.
• Custom block message: This option allows you to configure a custom message. The message will be seen by the
client when a URL is blocked.
• Fallback settings: This option allows you to permit or block URLs during error conditions. The error conditions
configuration options are the same as SurfControl.
• Timeout: This option allows you to configure the timeout value in seconds, after which a request is considered
to have timed out.
• Sockets: This option allows you to configure the number of persistent sockets to be opened to the Websense
server.
• Account: This option allows you to configure the Websense server account.

Local Blacklist and Whitelist Options

Local Web filtering by default permits all URLs, therefore a URL pattern to allow URLs is not needed. You only need to
configure a whitelist if you configure the default action to block under the juniper-local profile. The Web filtering type
must be configured for juniper-local, or the default Web filtering SurfControl will be used. You must configure a URL
pattern for the websites you want to block, and apply the URL pattern to a custom URL category. The custom URL category is
then applied under the web-filtering hierarchy as a url-blacklist to block the URL. You can also configure the
same custom message and fallback options as previously mentioned.
The slide shows how the URL pattern is associated with the custom URL category, and how the custom URL category
associates with the Web filter.

The Web Filter Must be Applied

The Web filtering profile must be applied to a UTM policy and the UTM policy must be applied to the appropriate security
policy.
The slide shows where the Web filtering profile is applied to the UTM policy, and where the UTM policy is applied to the
security policy.

Custom Objects Configuration

The first step to configuring enhanced Web filtering is to create any custom objects to be applied to the enhanced Web
filtering feature profile. In the slide example, we create a URL pattern list called urllist3 that contains the pattern values
http://www.juniper.net and 1.2.3.4. The urllist3 custom object is then added to the custom URL category
custurl3. The slide also demonstrates URL pattern lists for trusted and untrusted sites called urllistwhite and
urllistblack.The URL pattern lists are applied to the custom-objects custom-url-category lists called custwhitelist
and custblacklist.

Apply Custom Objects to the Feature Profile

The next step is to configure the global options for the enhanced Web filtering feature profile. By default the, the enhanced
Web filtering profile name is called junos-wf-enhanced-default. The slide example shows the custom object
custwhitelist applied to the URL whitelist, and the custom object custblacklist applied to the URL blacklist. The
type of Web filtering engine for enhanced Web filtering is Juniper-Enhanced. Then you set the cache size and cache
timeout parameters. Configure the Enhanced Web Filtering server as rp.cloud.threatseeker.com . Configure the
TCP port number for communicating with it. The default port number is 80.

Configure the Feature Profile URL Categories and Site Reputation

Next, edit the enhanced Web filtering feature profile and navigate to the URL category action list tab. Select a category from
the included whitelist and blacklist categories or select a custom URL category list you created for filtering against. Configure
each category with an action of permit, log and permit, or block. The slide example blocks URLs in the
Enhanced_Gambling category, but logs and permits URLs in the Enhanced_Hacking category. You also specify the
action to be taken depending on the site reputation returned for the URL if there is no category match found. You can
configure a custom message to be sent when HTTP requests are blocked. The slide also shows the site reputation actions
you can configure for each URL.

Apply the UTM Policy to the Security Policy

The last step is to create a UTM policy that references the enhanced Web Filtering feature profile. In the slide example, the
UTM policy is named junos-wf-policy. The slide shows the UTM policy being applied under the application services tab
of the security policy.

Web Filtering Verification and Monitoring


Local Web Filtering

This slide illustrates the topology for this example. The next few pages show the Web filtering configuration steps to block
access to a bad website.

Configuring Custom URL Patterns and Categories

The slide illustrates configuring URL patterns and applying the URL pattern to a custom URL category.

Configuring the Web Filter Profile

The slide shows applying the custom URL categories under the Web filter, and creating a local profile with a custom block
message. The URL whitelist and blacklist can be used with other Web filtering solutions, such as SurfControl.

Applying the Policies

The slide shows where the Web filtering profile is applied to the UTM policy, and where the UTM policy is applied to the
security policy.
You can also apply predefined Web filtering profiles to the UTM policy. To view the predefined Web filtering profiles, issue the
show group junos-defaults security utm feature-profile web-filtering command.
The following output shows the Web filtering UTM policy options:
user@srx# set utm-policy policy1 web-filtering http-profile ?
Possible completions:
<http-profile> Web-filtering HTTP profile
block-bad [security utm feature-profile web-filtering juniper-local
profile]
junos-wf-cpa-default [security utm feature-profile web-filtering
surf-control-integrated profile]
junos-wf-local-default [security utm feature-profile web-filtering juniper-local
profile]
junos-wf-websense-default [security utm feature-profile web-filtering
websense-redirect profile]

Verify That Web Filtering Is Working

The slide shows what the client would see in the Web browser after trying to access a blocked website.

Verify and Monitor Using CLI

The syslog messages log permitted or blocked content, and the show security utm web-filtering statistics
command counts how many times a URL was permitted or blocked. The syslog messages must be configured with a severity
of any or info.

Verify and Monitor Using J-Web

J-Web provides the same monitoring options as CLI, and also provides further statistics and graphs to display the blocked
traffic.

We Discussed:
• The purpose of content filtering and Web filtering;
• The parameters used to configure content filtering and Web filtering;
• Configuring content filtering and Web filtering; and
• Monitoring content filtering and Web filtering.

Review Questions
1.
2.
3.

Content Filtering and Web Filtering Lab


1.
The Junos OS supports the file extension and protocol command content filtering attributes.
2.
The three Web filtering solutions are SurfControl, Websense, and local whitelist and blacklist.
3.
The Web filtering solution SurfControl requires a Juniper license.

Acronym List
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface
CSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Content Security Accelerator
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Name System
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface
HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Hypertext Transfer Protocol
IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Message Access Protocol
JNCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Juniper Networks Certification Program
MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multipurpose Internet Mail Extension
PFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Forwarding Engine
OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Systems Interconnection
POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Post Office Protocol 3
SBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . spam block list
UTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unified Threat Management
UTMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . unified threat management process
www.juniper.net Acronym List • ACR–1

ACR–2 • Acronym List www.juniper.net

Junos Unified Threat Management: Student Guide

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Junos Unified Threat Management: Student Guide

Hochgeladen von

Copyright:

Verfügbare Formate

Junos Unified Threat Management

Worldwide Education Services

1133 Innovation Way

Course Number: EDU-JUN-JUTM

Junos Unified Threat Management Student Guide, Revision 12.a

Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

Chapter 2: UTM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1

Chapter 3: Antispam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Chapter 4: Full File-Based Antivirus and Express Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Chapter 5: Content Filtering and Web Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACR-1

www.juniper.net Contents • iii

www.juniper.net Course Overview • v

vi • Course Agenda www.juniper.net

CLI and GUI Text

Style Description Usage Example

Courier New Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Defined and Undefined Syntax Variables

Style Description Usage Example

CLI Variable Text where variable value is already policy my-peers

www.juniper.net Document Conventions • vii

Education Services Offerings

viii • Additional Information www.juniper.net

Chapter 1: Course Introduction

Chapter 1–2 • Course Introduction www.juniper.net

www.juniper.net Course Introduction • Chapter 1–3

Chapter 1–4 • Course Introduction www.juniper.net

www.juniper.net Course Introduction • Chapter 1–5

General Course Administration

Chapter 1–6 • Course Introduction www.juniper.net

Training and Study Materials

www.juniper.net Course Introduction • Chapter 1–7

Chapter 1–8 • Course Introduction www.juniper.net

www.juniper.net Course Introduction • Chapter 1–9

Juniper Networks Education Services Curriculum

Chapter 1–10 • Course Introduction www.juniper.net

Juniper Networks Certification Program

www.juniper.net Course Introduction • Chapter 1–11

Juniper Networks Certification Program Overview

Chapter 1–12 • Course Introduction www.juniper.net

Preparing and Studying

www.juniper.net Course Introduction • Chapter 1–13

Chapter 1–14 • Course Introduction www.juniper.net

www.juniper.net Course Introduction • Chapter 1–15

Chapter 1–16 • Course Introduction www.juniper.net

Chapter 2: UTM Overview

Chapter 2–2 • UTM Overview www.juniper.net

Branch Office Challenges

www.juniper.net UTM Overview • Chapter 2–3

Branch Office Vulnerabilities

Chapter 2–4 • UTM Overview www.juniper.net

UTM Provides and Enforces Security

www.juniper.net UTM Overview • Chapter 2–5

Chapter 2–6 • UTM Overview www.juniper.net

UTM Features Are Performed in the Flow Module Services

www.juniper.net UTM Overview • Chapter 2–7

UTM Traffic Processing Overview

Chapter 2–8 • UTM Overview www.juniper.net

www.juniper.net UTM Overview • Chapter 2–9

Chapter 2–10 • UTM Overview www.juniper.net