Jncis Sec P2 - 2011 09 22

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Worldwide Education Services Worldwide Education Services
JNCIS-SEC Study GuidePart 2
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, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered
trademarks, or registered service marks are the property of their respective owners.
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.
JNCIS-SEC Study GuidePart 2.
Copyright 2011, Juniper Networks, Inc.
All rights reserved. Printed in USA.
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 10.4R1.9. 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.
Contents iii
Contents
Chapter 1: UTM Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Chapter 2: Antispam. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Chapter 3: Full File-Based Antivirus and Express Antivirus . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Chapter 4: Content Filtering and Web Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
www.juniper.net v
Overview
Welcome to the JNCIS-SEC Study GuidePart 2. The purpose of this guide is to help you prepare for
your JN0-331 exam and achieve your JNCIS-SEC credential. The contents of this document are
based on the Junos Unified Threat Management (JUTM) course. This study guide covers Web
filtering, antivirus, antispam, and content filtering. Students will gain experience in configuring and
monitoring the Unified Threat Management (UTM) features of the Junos operating system.
Agenda
Chapter 1: UTM Overview
Chapter 2: Antispam
Chapter 3: Full File-Based Antivirus and Express Antivirus
Chapter 4: Content Filtering and Web Filtering
vi 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.
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.
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.
Style Description Usage Example
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
Courier New Console text:
Screen captures
Noncommand-related
syntax
GUI text elements:
Menu names
Text field entry
commit complete
Exiting configuration mode
Select File > Open, and then click
Configuration.conf in the
Filename text box.
Normal CLI
Normal GUI
No distinguishing variant. Physical interface:fxp0,
Enabled
View configuration history by clicking
Configuration > History.
CLI Input
GUI Input
Text that you must enter. lab@San_Jose> show route
Select File > Save, and type
config.ini in the Filename field.
CLI Variable
GUI Variable
Text where variable value is already
assigned.
policy my-peers
Click my-peers in the dialog.
CLI Undefined
GUI Undefined
Text where the variables value is
the users discretion or text where
the variables value as shown in
the lab guide might differ from the
value the user must input
according to the lab topology.
Type set policy policy-name.
ping 10.0.x.y
Select File > Save, and type
filename in the Filename field.
www.juniper.net 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 JNCIS-SEC Study GuidePart 2 was developed and tested using software Release 10.4R1.9.
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).
UTM Overview Chapter 11
2011 Juniper Networks, Inc. All rights reserved.
Chapter 1: UTM Overview
This Chapter Discusses:
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.
Branch Office Vulnerabilities
A branch office network in todays market significantly contributes to the bottom line and is central to an
organizations success. Branch offices normally includes 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
Chapter 12 UTM Overview
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.
UTM Features Are Performed in the Flow Module Services

The graphic shows how traffic is forwarded through the Junos operating system flow module, and at which steps
UTM features are performed.
UTM Process Overview
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.
Verifying UTM
The graphic 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.
user@srx> show security utm session
UTM session info:
Maximum sessions: 4000
Total allocated sessions: 2267
Total freed sessions: 2167
Active sessions: 0
The show security utm status command displays whether the UTM service is running.
user@srx> show security utm status
UTM service status: Running
Custom Objects
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.
Feature Profile
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.
Policy
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, antispam).
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 graphic 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 SRX240-H. 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.
Licensing
The table illustrates which UTM features require a license.
Verify UTM Licensing
Licenses must be used for successful operation of UTM features. The graphic displays the output of the show
system license command. The output shows the licenses installed for each UTM feature.
Review Questions
Answers
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.
Antispam Chapter 21
Chapter 2: Antispam
Antispam methods and terminology;
How UTM examines traffic for spam;
The configuration of an effective antispam UTM policy; and
The verification and monitoring of an antispam operation.
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 featuresincluding content filtering,
antivirus, and Web filteringthat make up Junipers 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. Two methods for performing antispam on the SRX device exist, which we discuss next.
Chapter 22 Antispam
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 Series 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 lookups are 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.
Antispam Chapter 23
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.
Whitelist
A whitelist contains the sources of the e-mail senders that you want the device to accept. The e-mail messages that
match the whitelist are deemed harmless. A match allows the e-mail traffic through the SRX Series 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://*.
Chapter 24 Antispam
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 actiondepending 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 senders 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 senders domain name on the whitelist, and then the blacklist. If no matching domain name is
found, again the device looks for the senders 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 senders 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.
SMTP
End users use SMTP to send outbound e-mail, but they do not use SMTP to receive e-mail. On the 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 1s e-mail
message to her local e-mail server. SMTP is again used to relay the message across the Internet to User 2s local
e-mail server. After User 2s 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 10.4, the antispam feature supports
filtering only on SMTP. It does not support antispam filtering on POP3 nor IMAP.
Antispam Chapter 25
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 servers 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-mails sender, the type of matching spam filter, and what action the SRX device took.
Chapter 26 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, and finally, you assign the UTM policy to a
security policy.
Antispam Chapter 27
CLI Antispam Configuration
The graphic examines the
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, you can tag either the subject or the header with either tag-subject
or tag-header. You can specify only one tagging action.
Chapter 28 Antispam
Antispam UTM Policy
The graphic demonstrates how to
configure the UTM and security
policies.You choose the name for the
UTM policy. On the graphic, 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 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 under the then
| permit |
application-services
hierarchy, as demonstrated in the
graphic.
J-Web UTM Objects Configuration
The screen capture demonstrates how to configure the UTM custom objects using the Junos Web user interface
(J-Web). The UTM configuration is under the security menu on the left side. You begin by configuring the custom
objects so that they can be used in the feature profile and UTM policies.
Antispam Chapter 29
J-Web Antispam Configuration
The screen capture 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 screen capture), so that the whitelists and
blacklists can be applied to the antispam profile.
The user-defined profile shown on the screen capture 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***;
}
}
Chapter 210 Antispam
Verifying Antispam Operations
The graphic introduces the test command, which you use to determine whether an e-mail sender will be identified
as spam. The command is as follows:
test security utm anti-spam profile profile-name test-string test-string
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 graphic. 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
Examine the commands to verify and monitor antispam operation on the 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
Antispam Chapter 211
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, the SRX device creates log messages each time spam is identified. Use the pipe symbol (|) and match
option to display only the antispam log messages.
The code output 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: Antispam Implementation
The graphic illustrates the topology we use for the next several sections. 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 the following:
Configure the SRX device to tag inbound spam from spam@xyz.com before it reaches the local user;
Make sure inbound e-mails from john@xyz.com are not tagged as spam, and are allowed to reach the
local user;
Configure the default spam action to tag the subject line with the string ***spam***; and
Enable the SBL server to protect against other spam.
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
sbl hierarchy. This profile allows you to enable the SBL server and define the default spam action. In this case
study, we enabled the SBL server and specified the default action to tag the subject line of the spam e-mail
messages.
Antispam Chapter 213
UTM and Security Policy Configuration
The graphic 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 screen capture,
under the feature-profile hierarchy for antispam.
Verifying Antispam Operations
With the SBL server enabled, you must also configure the name-server (DNS server). The address shown in the
example is a public DNS server.
The graphic also 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 graphic shows that the SRX device identifies the string as spam (because it matched
the local blacklist).
Review Questions
Answers
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.
Full File-Based Antivirus and Express Antivirus Chapter 31
Junos Unified Threat Management
Chapter 3: Full File-Based Antivirus and Express Antivirus
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.
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.
Chapter 32 Full File-Based Antivirus and Express Antivirus
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 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 antivirus feature, scans
specific Application Layer traffic for viruses against a virus signature database. However, unlike full 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 decrease the level of security provided. Express antivirus
uses a different signature database than the full 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 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 shows file scanning
occurring as the file is received, reducing overall data throughput latency.
Pattern Matching
The antivirus module 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 scanning engine type 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, which is the recommended configuration. We discuss the pattern update configuration later
in the chapter.
Intelligent Prescreening
One technique used to increase performance with antivirus scanning 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
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 graphic 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 graphic 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.
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 shows both inbound and outbound traffic passing different file types through an
SRX240. Each of the file types shown are process for antivirus scanning.
Scan Mode By-Extension
The diagram shows an SRX240 using the by-extension scan mode. In this mode, the SRX device bases all
scanning decisions on the traffics 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 following command:
user@srx# show groups junos-defaults security utm custom-objects
filename-extension
386;ACE;ARJ;ASP;BAT;BIN;BZ2;CAB;CHM;CLA;CMD;COM;CPL;DLL;DOC;DOT;DPL;DRV;DWG;
ELF;EMF;EML;EXE;FON;FPM;GEA;GZ;HA;HLP;HTA;HTM;HTML;HTT;HXS;ICE;INI;ITSF;JAR;
JPEG;JPG;JS;JSE;LHA;LNK;LZH;MBX;MD?;MIME;MSG;MSI;MSO;NWS;OCX;OTM;OV?;PDF;PHP;
PHT;PIF;PK;PL;PLG;PP?;PRG;PRJ;RAR;REG;RTF;SCR;SH;SHS;SWF;SYS;TAR;TGZ;THE;TSP;
VBE;VBS;VXD;WSF;WSH;XL?;XML;ZIP;
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. If a files 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 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. Due to 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 graphic 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.
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 may bypass antivirus scanning. The graphic 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 cannot be scanned because of special conditions:
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.)
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 graphic 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 add to 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
graphic 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 following CLI command:
[edit]
user@srx> request security utm anti-virus
kaspersky-lab-engine|juniper-express-engine pattern-update
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 graphic shows the configuration for the fallback and notification options for antivirus. These settings are
configured under the antivirus profile, and are the same for full file-based antivirus and express antivirus. 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
in the graphic 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 graphic 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.
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 graphic. 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 graphic shows the output for the show
system license command. The output will show which license has 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.
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 graphic 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.
Review Questions
Answers
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.
Content Filtering and Web Filtering Chapter 41
Chapter 4: Content Filtering and Web Filtering
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.
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
Chapter 42 Content Filtering and Web Filtering
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 Options
A content filter must coincide with a list of custom objects, which is a list of objects you want to allow or block. The
one exception is with HTTP traffic, which can be configured to block content directly under the content filter.
The graphic shows 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.
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: 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.
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 graphic shows the options available for applying the content filtering profile and where the UTM policy is applied
to the security policy.
Content Filtering Example for HTTP
The graphic 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 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
The screen capture 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
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 black lists on the SRX device.
Once traffic has been blocked, the client can receive a custom message in the Web browser.
Junos Has Three 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 categories and associated URLs. The 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 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.
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 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.
SurfControl Configuration Options
This graphic 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. The default action is to permit the URL if the default
option is not configured.
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 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 graphic 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 must only
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 graphic 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 graphic shows where the Web filtering profile is applied to the UTM policy, and where the UTM policy is applied to
the security policy.
Local Web Filtering
This graphic 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 graphic illustrates configuring URL patterns and applying the URL pattern to a custom URL category.
Configuring the Web Filter Profile
The graphic 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 graphic 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 graphic 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.
Review Questions
Answers
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.

Jncis Sec P2 - 2011 09 22

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Jncis Sec P2 - 2011 09 22

Transféré par

Droits d'auteur :

Formats disponibles

1194 North Mathilda Avenue

Vous aimerez peut-être aussi