ACS Midterm Merged

2011 International Conference on Advanced Materials Engineering
IPCSIT vol.15 (2011) © (2011) IACSIT Press, Singapore
Intrusion Detection System (IDS): Case Study
Asmaa Shaker Ashoor and Sharad Gore+

Department Computer Science, Department Statistic, Pune University-pune-india
Abstract. Intruders computers, who are spread across the Internet have become a major threat in our world,
The researchers proposed a number of techniques such as (firewall, encryption) to prevent such penetration
and protect the infrastructure of computers, but with this, the intruders managed to penetrate the computers.
IDS has taken much of the attention of researchers, IDS monitors the resources computer and sends reports
on the activities of any anomaly or strange patterns. The aim of this paper is to explain the stages of the
evolution of the idea of IDS and its importance to researchers and research centres, security, military and to
examine the importance of intrusion detection systems and categories , classifications, and where can put IDS
to reduce the risk to the network.
Keywords: IDS, anomaly , misuse, NID
1. Introduction
Security is an important issue for all the networks of companies and institutions at the present time and
all the intrusions are trying in ways that successful access to the data network of these companies and Web
services and despite the development of multiple ways to ensure that the infiltration of intrusion to the
infrastructure of the network via the Internet, through the use of firewalls, encryption, etc.
But IDS is a relatively new technology of the techniques for intrusion detection methods that have emerged
in recent years. Intrusion detection system’s main role in a network is to help computer systems to prepare
and deal with the network attacks.
Intrusion detection functions include:

• Monitoring and analyzing both user and system activities
• Analyzing system configurations and vulnerabilities
• Assessing system and file integrity
• Ability to recognize patterns typical of attacks
• Analysis of abnormal activity patterns
• Tracking user policy violations
The purpose of IDS is to help computer systems on how to deal with attacks, and that IDS is collecting
information from several different sources within the computer systems and networks and compares this
information with pre-existing patterns of discrimination as to whether there are attacks or weaknesses.
2. Intrusion Detection Systems: A Brief History

The goal of intrusion detection is to monitor network assets to detect anomalous behaviour and misuse in
network. This concept has been around for nearly twenty years but only recently has it seen a dramatic rise in
popularity and incorporation into the overall information security infrastructure. Beginning in 1980, with
James Anderson's paper, Computer Security Threat Monitoring and Surveillance, the intrusion detection was
+
Corresponding author. Tel.: + 919158797897
E-mail address: asmaa_zaid218@yahoo.com
6
born. Since then, several polar events in IDS technology have advanced intrusion detection to its current
state. James Anderson's seminal paper, was written for a government organization, introduced the notion that
audit trails contained vital information that could be valuable in tracking misuse and understanding of user
behaviour. With the release of this paper, the concept of "detecting" misuse and specific user events emerged.
His insight into audit data and its importance led to tremendous improvements in the auditing subsystems of
virtually every operating system. Anderson's hypothesize also provided the foundation for future intrusion
detection sstem design and development. His work was the start of host-based intrusion detection and IDS in
general.
In 1983, SRI International, and Dr. Dorothy Denning, began working on a government project that
launched a new effort into intrusion detection system development. Their goal was to analyze audit trails
from government mainframe computers and create profiles of users based upon their activities. One year
later, Dr. Denning helped to develop the first model for intrusion detection, the Intrusion Detection Expert
System (IDES), which provided the foundation for the IDS technology development that was soon to follow.
In 1984, SRI also developed a means of tracking and analyzing audit data containing authentication
information of users on ARPANET, the original Internet. Soon after, SRI completed a Navy SPAWAR
contract with the realization of the first functional intrusion detection system, IDES. Using her research and
development work at SRI, Dr. Denning published the decisive work, An Intrusion Detection Model, which
revealed the necessary information for commercial intrusion detection system development. Her paper is the
basis for most of the work in IDS that followed. The subsequent iteration of this tool was called the
Distributed Intrusion Detection System (DIDS). DIDS augmented the existing solution by tracking client
machines as well as the servers it originally monitored. Finally in 1989, the developers from the Haystack
project formed the commercial company, Haystack Labs, and released the last generation of the technology,
Stalker. Crosby Marks says that "Stalker was a host-based, pattern matching system that included robust
search capabilities to manually and automatically query the audit data." The Haystack advances, coupled
with the work of SRI and Denning, greatly advanced the development of host-based intrusion detection
technologies.
Commercial development of intrusion detection technologies began in the early 1990s. Haystack Labs
was the first commercial vendor of IDS tools, with its Stalker line of host-based products. SAIC was also
developing a form of host-based intrusion detection, called Computer Misuse Detection System (CMDS).
Simultaneously, the Air Force's Crypto logic Support Canter developed the Automated Security
Measurement System (ASIM) to monitor network traffic on the US Air Force's network. ASIM made
considerable progress in overcoming scalability and portability issues that previously plagued NID products.
Additionally, ASIM was the first solution to incorporate both a hardware and software solution to network
intrusion detection. ASIM is still currently in use and managed by the Air Force's Computer Emergency
Response Team (AFCERT) at locations all over the world. As often happened, the development group on the
ASIM project formed a commercial company in 1994, the Wheel Group. Their product, Net Ranger, was the
first commercially viable network intrusion detection device. The intrusion detection market began to gain in
popularity and truly generate revenues around 1997. In that year, the security market leader, ISS, developed
a network intrusion detection system called Real Secure. A year later, Cisco recognized the importance of
network intrusion detection and purchased the Wheel Group, attaining a security solution they could provide
to their customers. Similarly, the first visible host-based intrusion detection company, Centrex Corporation,
emerged as a result of a merger of the development staff from Haystack Labs and the departure of the CMDS
team from SAIC. From there, the commercial IDS world expanded its market-base and a roller coaster ride
of start-up companies, mergers, and acquisitions ensued.
The above chart from US-CERT shows how the cyber incidents rose in current internet network
environment; this gives requirement of IDS deployment in network security model.
Network intrusion detection actually deals with information passing on the wire between hosts. Typically
referred to as "packet-sniffers," network intrusion detection devices intercept packets travelling in and out in
network along various communication mediums and protocols, usually TCP/IP. Once captured, the packets
are analyzed in a number of different ways. Some IDS devices will simply compare the packet to a signature
7
database consisting of known attacks and malicious packet "fingerprints", while others will look for
anomalous packet activity that might indicate malicious behaviour.
Fig. 1: Number of incidents reported Fig. 2: Vulnerabilities reported
The IDS basically monitors network traffic for activity that falls within the banned activity in the
network. The IDS main job is gives alert to network admins for allow them to take corrective action,
blocking access to vulnerable ports, denying access to specific IP address or shutting down services used to
allow attacks. This is nothing but front line weapon in the network admins war against hackers. This
information is then compared with predefined blueprints of known attacks and vulnerabilities.
3. Categories of Intrusion Detection System

Intrusion detection system is classified into three categories: signature based detection systems, anomaly
based detection systems and specification based detection systems.
3.1. Signature Based Detection Systems

Signature based detection system (also called misuse based) , This type of detection is very effective
against known attacks, and it depends on the receiving of regular updates of patterns and will be unable to
detect unknown previous threats or new releases.
3.2. Anomaly based Detection System

This type of detection depends on the classification of the network to the normal and anomalous, as this
classification is based on rules or heuristics rather than patterns or signatures and the implementation of this
system we first need to know the normal behaviour of the network.
Anomaly based detection system unlike the misuse based detection system because it can detect previous
unknown threats, But the false positive to rise more probably.
3.3. Specification based Detection System

This type of detection systems is responsible for monitoring the processes and matching the actual data
with the program and in case of any Abnormal behaviour will be issued an alert and must be maintained and
updated whenever a change was made on the surveillance programs in order to be able to detect the previous
attacks the unknown and the number of false positives what can be less than the anomaly detection system
approach.
4. Classification of Intrusion Detection System

Intrusion detection system are classified into three types
[1]. Host based IDS
[2]. Network based IDS
[3]. Hybrid based IDS
4.1. Host based IDS (HIDS)
8
This type is placed on one device such as server or workstation, where the data is analyzed locally to the
machine and are collecting this data from different sources. HIDS can use both anomaly and misuse
detection system.
4.2. Network based IDS (NIDS)

NIDS are deployed on strategic point in network infrastructure. The NIDS can capture and analyze data
to detect known attacks by comparing patterns or signatures of the database or detection of illegal activities
by scanning traffic for anomalous activity. NIDS are also referred as “packet-sniffers”, Because it captures
the packets passing through the of communication mediums.
4.3. Hybrid based IDS

The management and alerting from both network and host-based intrusion detection devices, and provide
the logical complement to NID and HID - central intrusion detection management.
Fig. 3: Layered security approach for reducing network risk
5. Conclusion
An intrusion detection system is a part of the defensive operations that complements the defences such as
firewalls, UTM etc. The intrusion detection system basically detects attack signs and then alerts. According
to the detection methodology, intrusion detection systems are typically categorized as misuse detection and
anomaly detection systems. The deployment perspective, they are be classified in network based or host
based IDS. In current intrusion detection systems where information is collected from both network and host
resources. In terms of performance, an intrusion detection system becomes more accurate as it detects more
attacks and raises fewer false positive alarms.
6. References
[1] Computer Security Threat Monitoring and Surveillance. Fort Washington, J. P. Anderson, Pa. 1980.
[2] D. E. Denning. An intrusion-detection model. IEEE Transactions on Software Engineering. Feb. 1987, 13(2):222-
232,.
[3] L. E. Heberlein. A Network Security Monitor. Proceedings of the IEEE Computer Society Symposium. Research in
Security and Privacy. May 1990, pp. 296-303.
[4] The Evolution of Intrusion Detection Systems. Digital Integrity, P. I. Tetrad, LLC on November 16, 2001.
[5] Intrusion Detection: Host-Based and Network-Based Intrusion Detection Systems. H. Kozushko. on September 11,
2003.
9
Reg. No.:
Name :
MID EXAM – Nov 2022

Programme : B.Tech – Cyber Security and Digital Forensics Semester : Interim 2022-2023
Course : Secure Software Engineering Code : CSD3002
Faculty : Dr. AZATH Slot/Class No. : A11+A12+A13+A14+A15/
BL2022234000564
Time : 1½ hours Max. Marks : 50
Answer all the Questions
Q. No. Question Description Marks
Justify the reasons with appropriate parameters exist behind the comparison for given table 3-5.
1
10
2 Use a tabulation to relate the attack pattern components with your own example.
10
3 Demonstrate a security assurance case example in order to assert and specify the desired security
10
properties with neat schematic diagram.
4 Apply your own creative inputs and outputs for the respective techniques and participants
10
involved in the nine steps of the SQUARE process model.
5 Demonstrate a source code in C language with sample I/O, for insecure coding which can be
exploited by attackers such as ‘Buffer overflow Attacks’. 10

Page 1 of 1
Cyber Defence in Depth
What does cyber defense in depth
• Cyber defence in depth covers five important elements: detection,
protection, management, response and recovery.
Detection
• Understanding your threats

• Understanding the threats you face and where your cyber defences are most at
risk of being breached is critical to securing your organisation against cyber
attacks.
• Most attacks exploit two types of vulnerability: technical and human.
• New technical vulnerabilities are discovered and exploited by criminals every day.
Previously patched vulnerabilities can also be reintroduced into systems by
updates and reconfigurations.
• A programme of regular vulnerability scanning is a critical component of a risk-
based approach to security: it identifies security vulnerabilities in workstations,
internal and external networks, and communications equipment.
• It is an automated activity that scans infrastructure targets for known
vulnerabilities and misconfigurations, enabling you to bolster your defences
where you most need to.
Protection
• Protect your organisation
• Protecting your organisation against cyber attacks and data breaches is a
complex undertaking. It is inevitable that some attacks will get past your
defences, through threats such as zero-day attacks and well-designed
phishing emails.
• It is therefore essential to implement more robust cyber security controls
and ensure you have appropriately trained staff to manage cyber security
defences and breaches.
• Not all organisations need to implement extensive security measures, but a
base level of cyber security is essential to protect against automated
attacks that seek to exploit common vulnerabilities.
• Certification to basic security schemes such as Cyber Essentials helps
protect organisations from the most common cyber threats and
demonstrate their commitment to cyber security.
Management
• Manage your cyber security risks

• or many organisations, managing cyber security risks requires a more intensive
approach than simply implementing basic protections. Cyber security isn’t a
destination – it is an ongoing process, requiring continual evaluation,
maintenance and revision.
• This should include such measures as embedding risk-based security controls in
corporate processes, managing the security of supply chains and carrying out
regular audits to ensure security controls remain up to date.
• ISO 27001 is the international standard for an ISMS (information security
management system), a risk-based approach to information security that
encompasses people, processes and technology. Independently audited
certification to the Standard demonstrates to customers, stakeholders and staff
that the organisation has implemented and maintains information security best
practice.
Response
• Prepare your response

• Cyber criminals need to find only one weakness to infiltrate your systems,
so it is essential to be prepared. The security measures you have
implemented should minimize the impact of a successful attack, but how
you respond is critical to limiting disruption and costs.
• This is especially important when it comes to breaches of personal data,
which must be reported to the data protection authorities within 72 hours
of being aware of the breach under the GDPR and DPA 2018.
• Organizations need a robust business continuity management system,
combined with cyber security and data protection audits, and supply chain
security to minimise the attack’s likelihood and impact.
• Implementing cyber incident response management plans means you
won’t waste valuable time when the worst happens
Recovery
• Safeguard your organization from cyber threats and gain peace

• Cyber Safeguard provides all the essential support, training, testing and insurance cover
you need for a cyber secure business. Our easy-to-manage service enables you to:
• Access cyber insurance cover from day one;
• Quickly roll out staff awareness training and track staff participation, both in the office
and remotely;
• Ensure staff are appropriately trained to spot phishing emails, avoid email misuse and
adhere to data privacy and information security best practices;
• Perform unlimited scans to check for vulnerabilities and use your ‘Scanned by IT
Governance’ badge to demonstrate to clients that you take security seriously;
• Access emergency cyber incident and breach support whenever and however you need
it; and
• Gain peace of mind with advice from legal and cyber security experts.
(Endpoints/Edge)Devices
Edge Device
• An edge device is any piece of hardware that controls data flow at the
boundary between two networks.
• Edge devices are pieces of equipment that serve to transmit data
between the local network and the cloud
• They are able to translate between the protocols, or languages, used
by local devices into the protocols used by the cloud where the data
will be further processed.
• Edge devices fulfill a variety of roles, depending on what type of
device they are, but they essentially serve as network entry -- or exit -
- points.
• Local devices use protocols like Bluetooth, wi-fi, Zigbee, and NFC
while the cloud uses protocols like AMQP, MQTT, CoAP, and HTTP.
• Cloud computing and the internet of things (IoT) have elevated the
role of edge devices, ushering in the need for more intelligence,
computing power and advanced services at the network edge. This
concept, where processes are decentralized and occur in a more
logical physical location, is referred to as edge computing.
•.
function
• transmission, routing, processing, monitoring, filtering, translation and
storage of data passing between networks.
• Edge devices are used by enterprises and service providers.
Types of edge devices
• edge router:
• Usually deployed to connect a campus network to the internet or a WAN, edge routers chiefly
function as gateways between network
• An edge router is a specialized router located at a network boundary that enables an internal
network to connect to external networks. They are primarily used at two demarcation points:
the wide area network (WAN) and the internet.
• The edge router typically sends or receives data directly to or from other organizations'
networks, using either static or dynamic routing capabilities. Handoffs between the campus
network and the internet or WAN edge primarily use Ethernet -- typically, Gigabit Ethernet
(GbE) over copper or over single or multimode fiber optics.
• Edge routers are often hardware devices, but their functions can also be performed by
software running on a standard x86 server.
Typical Corporate Deployment
Types of edge routers
1. Subscriber edge routers and

2. label edge routers
• Subscriber edge routers function in two ways:
1. As external Border Gateway Protocol (BGP) routers that connect one autonomous system to
other ASes, which includes connecting an enterprise network to the network edge of its
internet service provider (ISP); and
2. as small or midsize business (SMB) or consumer broadband routers connecting a home
network or small office to an ISP's network edge.
Label edge routers
• Label edge routers, which are used at the edge of Multiprotocol Label
Switching (MPLS) networks, act as gateways between a local network
and a WAN or the internet and assign labels to outbound data
transmissions.
• Edge routers are not internal routers that partition a given AS
network into separate subnets. To connect to external networks,
routers use the Internet Protocol (IP) and the Open Shortest Path First
(OSPF) protocol to route packets efficiently.
endpoint device
• An endpoint device is an Internet-capable computer hardware device
on a TCP/IP network.
• The term can refer to desktop computers, laptops, smart phones,
tablets, thin clients, printers or other specialized hardware such as
sensors, actuators, point of sale terminals (POS terminals) and Smart
meters.
• Most experts recommend a policy-based approach to network
security that requires endpoint devices to comply with specific
criteria before they are granted access to network resources.
• Endpoints are physical devices that connect to and exchange
information with a computer network. Some examples of endpoints
are mobile devices, desktop computers, virtual machines, embedded
devices, and servers. Internet-of-Things devices—like cameras,
lighting, refrigerators, security systems, smart speakers, and
thermostats—are also endpoints.
• When a device connects to a network, the flow of information
between, for instance, a laptop and a network, is much like a
conversation between two people over the phone.
Importance of endpoint security
• Endpoint security, or endpoint protection, helps protect endpoints from malicious actors
and exploits.
• Cybercriminals target endpoints because they are doorways to corporate data and by
nature vulnerable to attack. They are outside network security and dependent on users
to put security measures into place—leaving room for human error. Protecting endpoints
from attack has become more challenging as the workforce becomes more distributed,
with office-based, remote, and hybrid workers using more devices from anywhere in the
world.
• Businesses of all sizes are vulnerable. Forty-three percent of cyberattacks involve small
businesses, according to a Verizon Data Breach Investigations Report. Small businesses
are prime targets because they can be entry points for criminals to penetrate even larger
companies, and they often don’t have cybersecurity defenses in place.
Special Publication 800-94
Guide to Intrusion Detection

and Prevention Systems
(IDPS)
Recommendations of the National Institute

of Standards and Technology
Karen Scarfone
Peter Mell
NIST Special Publication 800-94 Guide to Intrusion Detection and
Prevention Systems (IDPS)
Recommendations of the National

Institute of Standards and Technology
Karen Scarfone
Peter Mell
C O M P U T E R S E C U R I T Y
Computer Security Division

Information Technology Laboratory
National Institute of Standards and Technology
Gaithersburg, MD 20899-8930
February 2007
U.S. Department of Commerce
Carlos M. Gutierrez, Secretary

Technology Administration
Robert C. Cresanti, Under Secretary of Commerce for

Technology
National Institute of Standards and Technology
William Jeffrey, Director

GUIDE TO INTRUSION DETECTION AND PREVENTION SYSTEMS (IDPS)
Reports on Computer Systems Technology
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology
(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s
measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of
concept implementations, and technical analysis to advance the development and productive use of
information technology. ITL’s responsibilities include the development of technical, physical,
administrative, and management standards and guidelines for the cost-effective security and privacy of
sensitive unclassified information in Federal computer systems. This Special Publication 800-series
reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative
activities with industry, government, and academic organizations.
National Institute of Standards and Technology Special Publication 800-94

Natl. Inst. Stand. Technol. Spec. Publ. 800-94, 127 pages (February 2007)
Certain commercial entities, equipment, or materials may be identified in this

document in order to describe an experimental procedure or concept adequately.
Such identification is not intended to imply recommendation or endorsement by the
National Institute of Standards and Technology, nor is it intended to imply that the
entities, materials, or equipment are necessarily the best available for the purpose.
iii
Acknowledgements
The authors, Karen Scarfone and Peter Mell of the National Institute of Standards and Technology
(NIST), wish to thank their colleagues who reviewed drafts of this document and contributed to its
technical content. The authors would like to acknowledge John Connor, Tim Grance, Anoop Singhal, and
Murugiah Souppaya of NIST; Michael Gerdes, Ralph Martins, Angela Orebaugh, and Mike Zeberlein of
Booz Allen Hamilton; and Steve Sharma of Project Performance Corporation for their keen and insightful
assistance throughout the development of the document. The authors particularly want to thank Rebecca
Bace of KSR for her careful review of the publication and for her work on the predecessor publication,
NIST Special Publication 800-31, Intrusion Detection Systems. The authors would also like to express
their thanks to security experts Andrew Balinsky (Cisco Systems), Anton Chuvakin (LogLogic), Jay
Ennis (Network Chemistry), John Jerrim (Lancope), and Kerry Long (Center for Intrusion Monitoring
and Protection, Army Research Laboratory), as well as representatives from the Department of State and
Gartner, for their particularly valuable comments and suggestions. Additional acknowledgements will be
added to the final version of the publication.
Trademarks
All product names are registered trademarks or trademarks of their respective companies.
iv
Table of Contents
Executive Summary..............................................................................................................ES-1
1. Introduction ......................................................................................................................1-1
1.1 Authority...................................................................................................................1-1
1.2 Purpose and Scope .................................................................................................1-1
1.3 Audience ..................................................................................................................1-1
1.4 Document Structure .................................................................................................1-1
2. Intrusion Detection and Prevention Principles .............................................................2-1
2.1 Uses of IDPS Technologies .....................................................................................2-1
2.2 Key Functions of IDPS Technologies ......................................................................2-2
2.3 Common Detection Methodologies..........................................................................2-3
2.3.1 Signature-Based Detection...........................................................................2-4
2.3.2 Anomaly-Based Detection ............................................................................2-4
2.3.3 Stateful Protocol Analysis.............................................................................2-5
2.4 Types of IDPS Technologies ...................................................................................2-6
2.5 Summary..................................................................................................................2-7
3. IDPS Technologies...........................................................................................................3-1
3.1 Components and Architecture .................................................................................3-1
3.1.1 Typical Components.....................................................................................3-1
3.1.2 Network Architectures ..................................................................................3-1
3.2 Security Capabilities ................................................................................................3-2
3.2.1 Information Gathering Capabilities ...............................................................3-2
3.2.2 Logging Capabilities .....................................................................................3-2
3.2.3 Detection Capabilities...................................................................................3-3
3.2.4 Prevention Capabilities.................................................................................3-4
3.3 Management ............................................................................................................3-4
3.3.1 Implementation .............................................................................................3-4
3.3.2 Operation and Maintenance .........................................................................3-6
3.3.3 Building and Maintaining Skills .....................................................................3-9
3.4 Summary................................................................................................................3-10
4. Network-Based IDPS........................................................................................................4-1
4.1 Networking Overview ...............................................................................................4-1
4.1.1 Application Layer ..........................................................................................4-1
4.1.2 Transport Layer ............................................................................................4-2
4.1.3 Network Layer ..............................................................................................4-2
4.1.4 Hardware Layer ............................................................................................4-3
4.2.2 Network Architectures and Sensor Locations...............................................4-4
4.3.4 Prevention Capabilities...............................................................................4-12
4.4 Management ..........................................................................................................4-13
v
4.4.1 Implementation ...........................................................................................4-14

4.4.2 Operation and Maintenance .......................................................................4-14
4.5 Summary................................................................................................................4-14
5. Wireless IDPS ...................................................................................................................5-1
5.1 Wireless Networking Overview ................................................................................5-1
5.1.1 WLAN Standards..........................................................................................5-1
5.1.2 WLAN Components......................................................................................5-2
5.1.3 Threats against WLANs................................................................................5-3
5.2.3 Sensor Locations..........................................................................................5-6
5.3.4 Prevention Capabilities...............................................................................5-11
5.4 Management ..........................................................................................................5-11
5.4.1 Implementation ...........................................................................................5-11
5.5 Summary................................................................................................................5-12
6. Network Behavior Analysis (NBA) System....................................................................6-1
6.1.3 Sensor Locations..........................................................................................6-2
6.3 Management ............................................................................................................6-7
6.3.1 Implementation .............................................................................................6-7
6.3.2 Operation and Maintenance .........................................................................6-7
6.4 Summary..................................................................................................................6-7
7. Host-Based IDPS..............................................................................................................7-1
7.1.3 Agent Locations............................................................................................7-3
7.1.4 Host Architectures ........................................................................................7-3
7.2.4 Other Capabilities .........................................................................................7-8
7.3 Management ............................................................................................................7-9
7.3.1 Implementation .............................................................................................7-9
vi
7.3.2 Operation....................................................................................................7-10
7.4 Summary................................................................................................................7-10
8. Using and Integrating Multiple IDPS Technologies ......................................................8-1
8.1 The Need for Multiple IDPS Technologies...............................................................8-1
8.2 Integrating Different IDPS Technologies..................................................................8-2
8.2.1 Direct IDPS Integration.................................................................................8-2
8.2.2 Indirect IDPS Integration ..............................................................................8-3
8.3 Other Technologies with IDPS Capabilities .............................................................8-4
8.3.1 Network Forensic Analysis Tool (NFAT) Software .......................................8-4
8.3.2 Anti-Malware Technologies ..........................................................................8-5
8.3.3 Firewalls and Routers...................................................................................8-6
8.3.4 Honeypots ....................................................................................................8-7
8.4 Summary..................................................................................................................8-7
9. IDPS Product Selection ...................................................................................................9-1
9.1 General Requirements.............................................................................................9-1
9.1.1 System and Network Environments .............................................................9-1
9.1.2 Goals and Objectives ...................................................................................9-2
9.1.3 Security and Other IT Policies ......................................................................9-2
9.1.4 External Requirements .................................................................................9-3
9.1.5 Resource Constraints ...................................................................................9-3
9.2 Security Capability Requirements ............................................................................9-4
9.3 Performance Requirements .....................................................................................9-6
9.4 Management Requirements.....................................................................................9-8
9.4.1 Design and Implementation..........................................................................9-8
9.4.3 Training, Documentation, and Technical Support ......................................9-12
9.5 Life Cycle Costs .....................................................................................................9-12
9.6 Evaluating Products ...............................................................................................9-13
9.6.1 IDPS Testing Challenges ...........................................................................9-14
9.6.2 Recommendations for Performing IDPS Evaluations .................................9-15
9.7 Summary................................................................................................................9-18
List of Appendices
Appendix A— Glossary .......................................................................................................... A-1
Appendix B— Acronyms........................................................................................................ B-1
Appendix C— Tools and Resources ..................................................................................... C-1
Appendix D— Index ................................................................................................................ D-1
vii
List of Figures
Figure 4-1. TCP/IP Layers ........................................................................................................4-1

Figure 4-2. Inline Network-Based IDPS Sensor Architecture Example.....................................4-5
Figure 4-3. Passive Network-Based IDPS Sensor Architecture Example.................................4-7
Figure 5-1. Wireless LAN Architecture Example.......................................................................5-2
Figure 5-2. Wireless IDPS Architecture ....................................................................................5-6
Figure 6-1. NBA Sensor Architecture Example.........................................................................6-2
Figure 7-1. Host-Based IDPS Agent Deployment Architecture Example..................................7-2
List of Tables
Table 8-1. Comparison of IDPS Technology Types..................................................................8-1
viii
Executive Summary
Intrusion detection is the process of monitoring the events occurring in a computer system or network and
analyzing them for signs of possible incidents, which are violations or imminent threats of violation of
computer security policies, acceptable use policies, or standard security practices. Intrusion prevention is
the process of performing intrusion detection and attempting to stop detected possible incidents. Intrusion
detection and prevention systems (IDPS) 1 are primarily focused on identifying possible incidents, logging
information about them, attempting to stop them, and reporting them to security administrators. In
addition, organizations use IDPSs for other purposes, such as identifying problems with security policies,
documenting existing threats, and deterring individuals from violating security policies. IDPSs have
become a necessary addition to the security infrastructure of nearly every organization.
IDPSs typically record information related to observed events, notify security administrators of important
observed events, and produce reports. Many IDPSs can also respond to a detected threat by attempting to
prevent it from succeeding. They use several response techniques, which involve the IDPS stopping the
attack itself, changing the security environment (e.g., reconfiguring a firewall), or changing the attack’s
content.
This publication describes the characteristics of IDPS technologies and provides recommendations for
designing, implementing, configuring, securing, monitoring, and maintaining them. The types of IDPS
technologies are differentiated primarily by the types of events that they monitor and the ways in which
they are deployed. This publication discusses the following four types of IDPS technologies:
Network-Based, which monitors network traffic for particular network segments or devices and
analyzes the network and application protocol activity to identify suspicious activity
Wireless, which monitors wireless network traffic and analyzes it to identify suspicious activity
involving the wireless networking protocols themselves
Network Behavior Analysis (NBA), which examines network traffic to identify threats that generate
unusual traffic flows, such as distributed denial of service (DDoS) attacks, certain forms of malware,
and policy violations (e.g., a client system providing network services to other systems)
Host-Based, which monitors the characteristics of a single host and the events occurring within that
host for suspicious activity.
Implementing the following recommendations should facilitate more efficient and effective intrusion
detection and prevention system use for Federal departments and agencies.
Organizations should ensure that all IDPS components are secured appropriately.
Securing IDPS components is very important because IDPSs are often targeted by attackers who want to
prevent the IDPSs from detecting attacks or want to gain access to sensitive information in the IDPSs,
such as host configurations and known vulnerabilities. IDPSs are composed of several types of
components, including sensors or agents, management servers, database servers, user and administrator
consoles, and management networks. All components’ operating systems and applications should be kept
fully up-to-date, and all software-based IDPS components should be hardened against threats. Specific
1
An intrusion detection system (IDS) is software that automates the intrusion detection process. An intrusion prevention system
(IPS) is software that has all the capabilities of an intrusion detection system and can also attempt to stop possible incidents.
IDS and IPS technologies offer many of the same capabilities, and administrators can usually disable prevention features in
IPS products, causing them to function as IDSs. Accordingly, for brevity the term intrusion detection and prevention system
(IDPS) is used throughout the rest of this guide to refer to both IDS and IPS technologies.
ES-1
protective actions of particular importance include creating separate accounts for each IDPS user and
administrator, restricting network access to IDPS components, and ensuring that IDPS management
communications are protected appropriately, such as encrypting them or transmitting them over a
physically or logically separate network. Administrators should maintain the security of the IDPS
components on an ongoing basis, including verifying that the components are functioning as desired,
monitoring the components for security issues, performing regular vulnerability assessments, responding
appropriately to vulnerabilities in the IDPS components, and testing and deploying IDPS updates.
Administrators should also back up configuration settings periodically and before applying updates to
ensure that existing settings are not inadvertently lost.
Organizations should consider using multiple types of IDPS technologies to achieve more
comprehensive and accurate detection and prevention of malicious activity.
The four primary types of IDPS technologies—network-based, wireless, NBA, and host-based—each
offer fundamentally different information gathering, logging, detection, and prevention capabilities. Each
technology type offers benefits over the others, such as detecting some events that the others cannot and
detecting some events with significantly greater accuracy than the other technologies. In many
environments, a robust IDPS solution cannot be achieved without using multiple types of IDPS
technologies. For most environments, a combination of network-based and host-based IDPS technologies
is needed for an effective IDPS solution. Wireless IDPS technologies may also be needed if the
organization determines that its wireless networks need additional monitoring or if the organization wants
to ensure that rogue wireless networks are not in use in the organization’s facilities. NBA technologies
can also be deployed if organizations desire additional detection capabilities for denial of service attacks,
worms, and other threats that NBAs are particularly well-suited to detecting. Organizations should
consider the different capabilities of each technology type along with other cost-benefit information when
selecting IDPS technologies.
Organizations planning to use multiple types of IDPS technologies or multiple products of the same
IDPS technology type should consider whether or not the IDPSs should be integrated.
Direct IDPS integration most often occurs when an organization uses multiple IDPS products from a
single vendor, by having a single console that can be used to manage and monitor the multiple products.
Some products can also mutually share data, which can speed the analysis process and help users to better
prioritize threats. A more limited form of direct IDPS integration is having one IDPS product provide
data for another IDPS product (but no data sharing in the opposite direction). Indirect IDPS integration is
usually performed with security information and event management (SIEM) software, which is designed
to import information from various security-related logs and correlate events among them. SIEM
software complements IDPS technologies in several ways, including correlating events logged by
different technologies, displaying data from many event sources, and providing supporting information
from other sources to help users verify the accuracy of IDPS alerts.
Before evaluating IDPS products, organizations should define the requirements that the products
should meet.
Evaluators need to understand the characteristics of the organization’s system and network environments,
so that a compatible IDPS can be selected that can monitor the events of interest on the systems and/or
networks. Evaluators should articulate the goals and objectives they wish to attain by using an IDPS,
such as stopping common attacks, identifying misconfigured wireless network devices, and detecting
misuse of the organization’s system and network resources. Evaluators should also review their existing
security policies, which serve as a specification for many of the features that the IDPS products need to
provide. In addition, evaluators should understand whether or not the organization is subject to oversight
ES-2
or review by another organization. If so, they should determine if that oversight authority requires IDPSs
or other specific system security resources. Resource constraints should also be taken into consideration
by evaluators. Evaluators also need to define specialized sets of requirements for the following:
Security capabilities, including information gathering, logging, detection, and prevention

Performance, including maximum capacity and performance features
Management, including design and implementation (e.g., reliability, interoperability, scalability,
product security), operation and maintenance (including software updates), and training,
documentation, and technical support
Life cycle costs, both initial and maintenance costs.
When evaluating IDPS products, organizations should consider using a combination of several
sources of data on the products’ characteristics and capabilities.
Common product data sources include test lab or real-world product testing, vendor-provided
information, third-party product reviews, and previous IDPS experience from individuals within the
organization and trusted individuals at other organizations. When using data from other parties,
organizations should consider the fidelity of the data because it is often presented without an explanation
of how it was generated. There are several major challenges in performing in-depth hands-on IDPS
testing, such as the considerable resources needed and the lack of a standard test methodology and test
suites, which often make it infeasible. However, limited IDPS testing is helpful for evaluating security
requirements, performance, and operation and maintenance capabilities.
ES-3
This page has been left blank intentionally.
ES-4
1. Introduction
1.1 Authority
The National Institute of Standards and Technology (NIST) developed this document in furtherance of its
statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002,
Public Law 107-347.
NIST is responsible for developing standards and guidelines, including minimum requirements, for
providing adequate information security for all agency operations and assets; but such standards and
guidelines shall not apply to national security systems. This guideline is consistent with the requirements
of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency
Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental
information is provided in A-130, Appendix III.
This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental
organizations on a voluntary basis and is not subject to copyright, though attribution is desired.
Nothing in this document should be taken to contradict standards and guidelines made mandatory and
binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these
guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,
Director of the OMB, or any other Federal official.
1.2 Purpose and Scope
This publication seeks to assist organizations in understanding intrusion detection system (IDS) and
intrusion prevention system (IPS) technologies and in designing, implementing, configuring, securing,
monitoring, and maintaining intrusion detection and prevention systems (IDPS). It provides practical,
real-world guidance for each of four classes of IDPS products: network-based, wireless, network behavior
analysis, and host-based. The publication also provides an overview of complementary technologies that
can detect intrusions, such as security information and event management software and network forensic
analysis tools. It focuses on enterprise IDPS solutions, but most of the information in the publication is
also applicable to standalone and small-scale IDPS deployments. This publication replaces NIST Special
Publication 800-31, Intrusion Detection Systems.
1.3 Audience
This document has been created for computer security staff and program managers, computer security
incident response teams (CSIRT), and system and network administrators who are responsible for
managing or monitoring IDPS technologies. This document does not assume that the reader has previous
experience with any IDPS technologies, but it does assume that the reader has experience with
information security.
1.4 Document Structure
The remainder of this document is organized into the following nine major sections:
Section 2 provides an introduction to the basic concepts of intrusion detection and prevention.
Section 3 gives an overview of IDPS technologies, including typical components, general detection
methodologies, and implementation and operation guidance.
1-1
Sections 4 through 7 contain detailed discussions of particular categories of IDPS technologies:
– Section 4: Network-based
– Section 5: Wireless
– Section 6: Network behavior analysis
– Section 7: Host-based
Section 8 discusses other technologies with IDPS capabilities.
Section 9 provides recommendations for using and integrating multiple IDPS technologies within an
enterprise.
Section 10 gives guidance on IDPS product selection.
The document also contains appendices with supporting material. Appendices A and B contain a glossary
and acronym list, respectively. Appendix C lists print resources and online tools and resources that may
be useful references for gaining a better understanding of IDPSs. Appendix D contains an index for the
publication.
1-2
2. Intrusion Detection and Prevention Principles
computer security policies, acceptable use policies, or standard security practices. Incidents have many
causes, such as malware (e.g., worms, spyware), attackers gaining unauthorized access to systems from
the Internet, and authorized users of systems who misuse their privileges or attempt to gain additional
privileges for which they are not authorized. Although many incidents are malicious in nature, many
others are not; for example, a person might mistype the address of a computer and accidentally attempt to
connect to a different system without authorization.
An intrusion detection system (IDS) is software that automates the intrusion detection process. An
intrusion prevention system (IPS) is software that has all the capabilities of an intrusion detection system
and can also attempt to stop possible incidents. This section provides an overview of IDS and IPS
technologies as a foundation for the rest of the publication. It first explains how IDS and IPS
technologies can be used. Next, it describes the key functions that IDS and IPS technologies perform and
the detection methodologies that they use. Finally, it provides an overview of the major classes of IDS
and IPS technologies.
IDS and IPS technologies offer many of the same capabilities, and administrators can usually disable
prevention features in IPS products, causing them to function as IDSs. Accordingly, for brevity the term
intrusion detection and prevention systems (IDPS) is used throughout the rest of this guide to refer to both
IDS and IPS technologies. 2 Any exceptions are specifically noted.
2.1 Uses of IDPS Technologies
IDPSs are primarily focused on identifying possible incidents. For example, an IDPS could detect when
an attacker has successfully compromised a system by exploiting a vulnerability in the system. The IDPS
could then report the incident to security administrators, who could quickly initiate incident response
actions to minimize the damage caused by the incident. 3 The IDPS could also log information that could
be used by the incident handlers. 4 Many IDPSs can also be configured to recognize violations of security
policies. For example, some IDPSs can be configured with firewall ruleset-like settings, allowing them to
identify network traffic that violates the organization’s security or acceptable use policies. Also, some
IDPSs can monitor file transfers and identify ones that might be suspicious, such as copying a large
database onto a user’s laptop.
Many IDPSs can also identify reconnaissance activity, which may indicate that an attack is imminent.
For example, some attack tools and forms of malware, particularly worms, perform reconnaissance
activities such as host and port scans to identify targets for subsequent attacks. An IDPS might be able to
block reconnaissance and notify security administrators, who can take actions if needed to alter other
security controls to prevent related incidents. Because reconnaissance activity is so frequent on the
Internet, reconnaissance detection is often performed primarily on protected internal networks.
2
This term is used for the purposes of this publication. It has not been widely used in the security community, and the reason
for using it in this publication is strictly brevity, not to replace the well-established “IDS” and “IPS” terms.
3
If the IDPS had successfully prevented the attack, security administrators still might want to be notified of the attack. This
is particularly important if the target has a known vulnerability that the attack could have exploited. Attackers could
potentially use a different attack for the same vulnerability that the IDPS might not recognize.
4
A detailed discussion of incident response is outside the scope of this guide. For guidance on establishing an effective
incident response capability, see NIST Special Publication (SP) 800-61, Computer Security Incident Handling Guide, which
is available at http://csrc.nist.gov/publications/nistpubs/.
2-1
In addition to identifying incidents and supporting incident response efforts, organizations have found
other uses for IDPSs, including the following:
Identifying security policy problems. An IDPS can provide some degree of quality control for
security policy implementation, such as duplicating firewall rulesets and alerting when it sees
network traffic that should have been blocked by the firewall but was not because of a firewall
configuration error.
Documenting the existing threat to an organization. IDPSs log information about the threats that
they detect. Understanding the frequency and characteristics of attacks against an organization’s
computing resources is helpful in identifying the appropriate security measures for protecting the
resources. The information can also be used to educate management about the threats that the
organization faces.
Deterring individuals from violating security policies. If individuals are aware that their actions
are being monitored by IDPS technologies for security policy violations, they may be less likely to
commit such violations because of the risk of detection.
Because of the increasing dependence on information systems and the prevalence and potential impact of
intrusions against those systems, IDPSs have become a necessary addition to the security infrastructure of
nearly every organization.
2.2 Key Functions of IDPS Technologies
There are many types of IDPS technologies, which are differentiated primarily by the types of events that
they can recognize and the methodologies that they use to identify incidents. In addition to monitoring
and analyzing events to identify undesirable activity, all types of IDPS technologies typically perform the
following functions:
Recording information related to observed events. Information is usually recorded locally, and
might also be sent to separate systems such as centralized logging servers, security information and
event management (SIEM) solutions, and enterprise management systems.
Notifying security administrators of important observed events. This notification, known as an
alert, occurs through any of several methods, including the following: e-mails, pages, messages on
the IDPS user interface, Simple Network Management Protocol (SNMP) traps, syslog messages, and
user-defined programs and scripts. A notification message typically includes only basic information
regarding an event; administrators need to access the IDPS for additional information.
Producing reports. Reports summarize the monitored events or provide details on particular events
of interest.
Some IDPSs are also able to change their security profile when a new threat is detected. For example, an
IDPS might be able to collect more detailed information for a particular session after malicious activity is
detected within that session. An IDPS might also alter the settings for when certain alerts are triggered or
what priority should be assigned to subsequent alerts after a particular threat is detected.
IPS technologies are differentiated from IDS technologies by one characteristic: IPS technologies can
respond to a detected threat by attempting to prevent it from succeeding. They use several response
techniques, which can be divided into the following groups:
The IPS stops the attack itself. Examples of how this could be done are as follows:
2-2
– Terminate the network connection or user session that is being used for the attack
– Block access to the target (or possibly other likely targets) from the offending user account, IP
address, or other attacker attribute
– Block all access to the targeted host, service, application, or other resource.
The IPS changes the security environment. The IPS could change the configuration of other
security controls to disrupt an attack. Common examples are reconfiguring a network device (e.g.,
firewall, router, switch) to block access from the attacker or to the target, and altering a host-based
firewall on a target to block incoming attacks. Some IPSs can even cause patches to be applied to a
host if the IPS detects that the host has vulnerabilities.
The IPS changes the attack’s content. Some IPS technologies can remove or replace malicious
portions of an attack to make it benign. A simple example is an IPS removing an infected file
attachment from an e-mail and then permitting the cleaned email to reach its recipient. A more
complex example is an IPS that acts as a proxy and normalizes incoming requests, which means that
the proxy repackages the payloads of the requests, discarding header information. This might cause
certain attacks to be discarded as part of the normalization process.
Another common attribute of IDPS technologies is that they cannot provide completely accurate
detection. When an IDPS incorrectly identifies benign activity as being malicious, a false positive has
occurred. When an IDPS fails to identify malicious activity, a false negative has occurred. It is not
possible to eliminate all false positives and negatives; in most cases, reducing the occurrences of one
increases the occurrences of the other. Many organizations choose to decrease false negatives at the cost
of increasing false positives, which means that more malicious events are detected but more analysis
resources are needed to differentiate false positives from true malicious events. Altering the
configuration of an IDPS to improve its detection accuracy is known as tuning.
Most IDPS technologies also offer features that compensate for the use of common evasion techniques.
Evasion is modifying the format or timing of malicious activity so that its appearance changes but its
effect is the same. Attackers use evasion techniques to try to prevent IDPS technologies from detecting
their attacks. For example, an attacker could encode text characters in a particular way, knowing that the
target understands the encoding and hoping that any monitoring IDPSs do not. Most IDPS technologies
can overcome common evasion techniques by duplicating special processing performed by the targets. If
the IDPS can “see” the activity in the same way that the target would, then evasion techniques will
generally be unsuccessful at hiding attacks.
2.3 Common Detection Methodologies
IDPS technologies use many methodologies to detect incidents. Sections 2.3.1 through 2.3.3 discuss the
primary classes of detection methodologies: signature-based, anomaly-based, and stateful protocol
analysis, respectively. Most IDPS technologies use multiple detection methodologies, either separately or
integrated, to provide more broad and accurate detection.
2-3
2.3.1 Signature-Based Detection
A signature is a pattern that corresponds to a known threat. Signature-based detection is the process of
comparing signatures against observed events to identify possible incidents. 5 Examples of signatures are
as follows:
A telnet attempt with a username of “root”, which is a violation of an organization’s security policy
An e-mail with a subject of “Free pictures!” and an attachment filename of “freepics.exe”, which are
characteristics of a known form of malware
An operating system log entry with a status code value of 645, which indicates that the host’s auditing
has been disabled.
Signature-based detection is very effective at detecting known threats but largely ineffective at detecting
previously unknown threats, threats disguised by the use of evasion techniques, and many variants of
known threats. For example, if an attacker modified the malware in the previous example to use a
filename of “freepics2.exe”, a signature looking for “freepics.exe” would not match it.
Signature-based detection is the simplest detection method because it just compares the current unit of
activity, such as a packet or a log entry, to a list of signatures using string comparison operations.
Signature-based detection technologies have little understanding of many network or application
protocols and cannot track and understand the state of complex communications. For example, they
cannot pair a request with the corresponding response, such as knowing that a request to a Web server for
a particular page generated a response status code of 403, meaning that the server refused to fill the
request. They also lack the ability to remember previous requests when processing the current request.
This limitation prevents signature-based detection methods from detecting attacks that comprise multiple
events if none of the events contains a clear indication of an attack.
2.3.2 Anomaly-Based Detection
Anomaly-based detection is the process of comparing definitions of what activity is considered normal
against observed events to identify significant deviations. An IDPS using anomaly-based detection has
profiles that represent the normal behavior of such things as users, hosts, network connections, or
applications. The profiles are developed by monitoring the characteristics of typical activity over a period
of time. For example, a profile for a network might show that Web activity comprises an average of 13%
of network bandwidth at the Internet border during typical workday hours. The IDPS then uses statistical
methods to compare the characteristics of current activity to thresholds related to the profile, such as
detecting when Web activity comprises significantly more bandwidth than expected and alerting an
administrator of the anomaly. Profiles can be developed for many behavioral attributes, such as the
number of e-mails sent by a user, the number of failed login attempts for a host, and the level of processor
usage for a host in a given period of time.
The major benefit of anomaly-based detection methods is that they can be very effective at detecting
previously unknown threats. For example, suppose that a computer becomes infected with a new type of
malware. The malware could consume the computer’s processing resources, send large numbers of e-
5
Signature-based detection is sometimes referred to as misuse detection, but this publication does not use that term because it
implies that misuse is only detected using signatures, which is not true. Also, signature-based detection is considered by
some parties to include stateful protocol analysis, as described in Section 2.3.3. For the purposes of this publication,
signature-based detection is defined so as not to include stateful protocol analysis, but other publications may have different
definitions.
2-4
mails, initiate large numbers of network connections, and perform other behavior that would be
significantly different from the established profiles for the computer.
An initial profile is generated over a period of time (typically days, sometimes weeks) sometimes called a
training period. Profiles for anomaly-based detection can either be static or dynamic. Once generated, a
static profile is unchanged unless the IDPS is specifically directed to generate a new profile. A dynamic
profile is adjusted constantly as additional events are observed. Because systems and networks change
over time, the corresponding measures of normal behavior also change; a static profile will eventually
become inaccurate, so it needs to be regenerated periodically. Dynamic profiles do not have this problem,
but they are susceptible to evasion attempts from attackers. For example, an attacker can perform small
amounts of malicious activity occasionally, then slowly increase the frequency and quantity of activity. If
the rate of change is sufficiently slow, the IDPS might think the malicious activity is normal behavior and
include it in its profile. Malicious activity might also be observed by an IDPS while it builds its initial
profiles.
Inadvertently including malicious activity as part of a profile is a common problem with anomaly-based
IDPS products. (In some cases, administrators can modify the profile to exclude activity in the profile
that is known to be malicious.) Another problem with building profiles is that it can be very challenging
in some cases to make them accurate, because computing activity can be so complex. For example, if a
particular maintenance activity that performs large file transfers occurs only once a month, it might not be
observed during the training period; when the maintenance occurs, it is likely to be considered a
significant deviation from the profile and trigger an alert. Anomaly-based IDPS products often produce
many false positives because of benign activity that deviates significantly from profiles, especially in
more diverse or dynamic environments. Another noteworthy problem with the use of anomaly-based
detection techniques is that it is often difficult for analysts to determine why a particular alert was
generated and to validate that an alert is accurate and not a false positive, because of the complexity of
events and number of events that may have caused the alert to be generated.
2.3.3 Stateful Protocol Analysis
Stateful protocol analysis is the process of comparing predetermined profiles of generally accepted
definitions of benign protocol activity for each protocol state against observed events to identify
deviations. 6 Unlike anomaly-based detection, which uses host or network-specific profiles, stateful
protocol analysis relies on vendor-developed universal profiles that specify how particular protocols
should and should not be used. The “stateful” in stateful protocol analysis means that the IDPS is capable
of understanding and tracking the state of network, transport, and application protocols that have a notion
of state. For example, when a user starts a File Transfer Protocol (FTP) session, the session is initially in
the unauthenticated state. Unauthenticated users should only perform a few commands in this state, such
as viewing help information or providing usernames and passwords. An important part of understanding
state is pairing requests with responses, so when an FTP authentication attempt occurs, the IDPS can
determine if it was successful by finding the status code in the corresponding response. Once the user has
authenticated successfully, the session is in the authenticated state, and users are expected to perform any
of several dozen commands. Performing most of these commands while in the unauthenticated state
would be considered suspicious, but in the authenticated state performing most of them is considered
benign.
6
Some vendors use the term “deep packet inspection” to refer to performing some type of stateful protocol analysis, often
combined with a firewall capability that can block communications determined to be malicious. This publication uses the
term “stateful protocol analysis” because it is appropriate for analyzing both network-based and host-based activity, whereas
“deep packet inspection” is an appropriate term for network-based activity only. Also, historically there has not been
consensus in the security community as to the meaning of “deep packet inspection”.
2-5
Stateful protocol analysis can identify unexpected sequences of commands, such as issuing the same
command repeatedly or issuing a command without first issuing a command upon which it is dependent.
Another state tracking feature of stateful protocol analysis is that for protocols that perform
authentication, the IDPS can keep track of the authenticator used for each session, and record the
authenticator used for suspicious activity. This is helpful when investigating an incident. Some IDPSs
can also use the authenticator information to define acceptable activity differently for multiple classes of
users or specific users.
The “protocol analysis” performed by stateful protocol analysis methods usually includes reasonableness
checks for individual commands, such as minimum and maximum lengths for arguments. If a command
typically has a username argument, and usernames have a maximum length of 20 characters, then an
argument with a length of 1000 characters is suspicious. If the large argument contains binary data, then
it is even more suspicious.
Stateful protocol analysis methods use protocol models, which are typically based primarily on protocol
standards from software vendors and standards bodies (e.g., Internet Engineering Task Force [IETF]
Request for Comments [RFC]). The protocol models also typically take into account variances in each
protocol’s implementation. Many standards are not exhaustively complete in explaining the details of the
protocol, which causes variations among implementations. Also, many vendors either violate standards
or add proprietary features, some of which may replace features from the standards. For proprietary
protocols, complete details about the protocols are often not available, making it difficult for IDPS
technologies to perform comprehensive, accurate analysis. As protocols are revised and vendors alter
their protocol implementations, IDPS protocol models need to be updated to reflect those changes.
The primary drawback to stateful protocol analysis methods is that they are very resource-intensive
because of the complexity of the analysis and the overhead involved in performing state tracking for
many simultaneous sessions. Another serious problem is that stateful protocol analysis methods cannot
detect attacks that do not violate the characteristics of generally acceptable protocol behavior, such as
performing many benign actions in a short period of time to cause a denial of service. Yet another
problem is that the protocol model used by an IDPS might conflict with the way the protocol is
implemented in particular versions of specific applications and operating systems, or how different client
and server implementations of the protocol interact.
2.4 Types of IDPS Technologies
There are many types of IDPS technologies. For the purposes of this document, they are divided into the
following four groups based on the type of events that they monitor and the ways in which they are
deployed:
analyzes the network and application protocol activity to identify suspicious activity. It can identify
many different types of events of interest. It is most commonly deployed at a boundary between
networks, such as in proximity to border firewalls or routers, virtual private network (VPN) servers,
remote access servers, and wireless networks. Section 4 contains extensive information on network-
based IDPS technologies.
Wireless, which monitors wireless network traffic and analyzes its wireless networking protocols to
identify suspicious activity involving the protocols themselves. It cannot identify suspicious activity
in the application or higher-layer network protocols (e.g., TCP, UDP) that the wireless network traffic
is transferring. It is most commonly deployed within range of an organization’s wireless network to
2-6
monitor it, but can also be deployed to locations where unauthorized wireless networking could be
occurring. More information on wireless IDPSs is presented in Section 5.
unusual traffic flows, such as distributed denial of service (DDoS) attacks, certain forms of malware
(e.g., worms, backdoors), and policy violations (e.g., a client system providing network services to
other systems). NBA systems are most often deployed to monitor flows on an organization’s internal
networks, and are also sometimes deployed where they can monitor flows between an organization’s
networks and external networks (e.g., the Internet, business partners’ networks). NBA products are
discussed in more detail in Section 6.
host for suspicious activity. Examples of the types of characteristics a host-based IDPS might
monitor are network traffic (only for that host), system logs, running processes, application activity,
file access and modification, and system and application configuration changes. Host-based IDPSs
are most commonly deployed on critical hosts such as publicly accessible servers and servers
containing sensitive information. Section 7 contains additional information on host-based IDPSs.
Some forms of IDPS are more mature than others because they have been in use much longer. Network-
based IDPS and some forms of host-based IDPS have been commercially available for over ten years.
Network behavior analysis software is a somewhat newer form of IDPS that evolved in part from
products created primarily to detect DDoS attacks, and in part from products developed to monitor traffic
flows on internal networks. Wireless technologies are a relatively new type of IDPS, developed in
response to the popularity of wireless local area networks (WLAN) and the growing threats against
WLANs and WLAN clients.
2.5 Summary
computer security policies, acceptable use policies, or standard security practices. Intrusion prevention is
the process of performing intrusion detection and attempting to stop detected possible incidents. Intrusion
detection and prevention systems (IDPS) are primarily focused on identifying possible incidents, logging
information about them, attempting to stop them, and reporting them to security administrators. In
addition, organizations use IDPSs for other purposes, such as identifying problems with security policies,
documenting existing threats, and deterring individuals from violating security policies. IDPSs have
become a necessary addition to the security infrastructure of nearly every organization.
There are many types of IDPS technologies, which are differentiated primarily by the types of events that
they can recognize and the methodologies that they use to identify possible incidents. This publication
discusses the following four types of IDPS technologies:
analyzes the network and application protocol activity to identify suspicious activity.
involving the wireless networking protocols themselves.
unusual traffic flows, such as DDoS attacks, scanning, and certain forms of malware.
host for suspicious activity.
2-7
IDPSs typically record information related to observed events, notify security administrators of important
observed events, and produce reports. Many IDPSs can also respond to a detected threat by attempting to
prevent it from succeeding. They use several response techniques, which involve the IDPS stopping the
attack itself, changing the security environment (e.g., reconfiguring a firewall), or changing the attack’s
content.
IDPSs cannot provide completely accurate detection; they all generate false positives (incorrectly
identifying benign activity as malicious) and false negatives (failing to identify malicious activity). Many
organizations choose to tune IDPSs so that false negatives are decreased and false positives increased,
which necessitates additional analysis resources to differentiate false positives from true malicious events.
Most IDPSs also offer features that compensate for the use of common evasion techniques, which modify
the format or timing of malicious activity to alter its appearance but not its effect, to attempt to avoid
detection by IDPSs.
Most IDPSs use multiple detection methodologies, either separately or integrated, to provide more broad
and accurate detection. The primary classes of detection methodologies are as follows:
Signature-based, which compares known threat signatures to observed events to identify incidents.
This is very effective at detecting known threats but largely ineffective at detecting unknown threats
and many variants on known threats. Signature-based detection cannot track and understand the state
of complex communications, so it cannot detect most attacks that comprise multiple events.
Anomaly-based detection, which compares definitions of what activity is considered normal against
observed events to identify significant deviations. This method uses profiles that are developed by
monitoring the characteristics of typical activity over a period of time. The IDPS then compares the
characteristics of current activity to thresholds related to the profile. Anomaly-based detection
methods can be very effective at detecting previously unknown threats. Common problems with
anomaly-based detection are inadvertently including malicious activity within a profile, establishing
profiles that are not sufficiently complex to reflect real-world computing activity, and generating
many false positives.
Stateful protocol analysis, which compares predetermined profiles of generally accepted definitions
of benign protocol activity for each protocol state against observed events to identify deviations.
Unlike anomaly-based detection, which uses host or network-specific profiles, stateful protocol
analysis relies on vendor-developed universal profiles that specify how particular protocols should
and should not be used. It is capable of understanding and tracking the state of protocols that have a
notion of state, which allows it to detect many attacks that other methods cannot. Problems with
stateful protocol analysis include that it is often very difficult or impossible to develop completely
accurate models of protocols, it is very resource-intensive, and it cannot detect attacks that do not
violate the characteristics of generally acceptable protocol behavior.
2-8
3. IDPS Technologies
This section provides an overview of IDPS technologies. The information presented in this section
applies to all types of IDPS products; additional information specific to each product type is presented in
Sections 4 through 7. This section first covers the major components of IDPS technologies and explains
the architectures typically used for deploying the components. It also provides a high-level description of
the security capabilities of the technologies, including the methodologies they use to identify suspicious
activity. The rest of the section discusses the management capabilities of the technologies, including
detailed recommendations for implementation and operation.
3.1 Components and Architecture
This section describes the major components of IDPS solutions and illustrates the most common network
architectures for these components.
3.1.1 Typical Components
The typical components in an IDPS solution are as follows:
Sensor or Agent. Sensors and agents monitor and analyze activity. The term sensor is typically used
for IDPSs that monitor networks, including network-based, wireless, and network behavior analysis
technologies. The term agent is typically used for host-based IDPS technologies.
Management Server. A management server is a centralized device that receives information from
the sensors or agents and manages them. 7 Some management servers perform analysis on the event
information that the sensors or agents provide and can identify events that the individual sensors or
agents cannot. Matching event information from multiple sensors or agents, such as finding events
triggered by the same IP address, is known as correlation. Management servers are available as both
appliance and software-only products. Some small IDPS deployments do not use any management
servers, but most IDPS deployments do. In larger IDPS deployments, there are often multiple
management servers, and in some cases there are two tiers of management servers.
Database Server. A database server is a repository for event information recorded by sensors,
agents, and/or management servers. Many IDPSs provide support for database servers.
Console. A console is a program that provides an interface for the IDPS’s users and administrators.
Console software is typically installed onto standard desktop or laptop computers. Some consoles are
used for IDPS administration only, such as configuring sensors or agents and applying software
updates, while other consoles are used strictly for monitoring and analysis. Some IDPS consoles
provide both administration and monitoring capabilities.
3.1.2 Network Architectures
IDPS components can be connected to each other through an organization’s standard networks or through
a separate network strictly designed for security software management known as a management network.
If a management network is used, each sensor or agent host has an additional network interface known as
a management interface that connects to the management network. Also, each sensor or agent host is
unable to pass any traffic between its management interface and any of its other network interfaces. The
7
Because this publication focuses on enterprise IDPS deployment, it assumes that management servers are used with sensors
and agents. However, some types of IDPS sensors and agents can be deployed standalone, and managed and monitored
directly by administrators without using a management server.
3-1
management servers, database servers, and consoles are attached to the management network only. This
architecture effectively isolates the management network from the production networks. The benefits of
doing this are to conceal the existence and identity of the IDPS from attackers; to protect the IDPS from
attack; and to ensure that the IDPS has adequate bandwidth to function under adverse conditions (e.g.,
worm attack or distributed denial of service [DDoS] on the monitored networks). Disadvantages of using
a management network include the additional costs in networking equipment and other hardware (e.g.,
PCs for the consoles) and the inconvenience for IDPS users and administrators of using separate
computers for IDPS management and monitoring.
If an IDPS is deployed without a separate management network, another way of improving IDPS security
is to create a virtual management network using a virtual local area network (VLAN) within the standard
networks. Using a VLAN provides protection for IDPS communications, but not as much protection as a
separate management network. For example, misconfiguration of the VLAN could lead to the exposure
of IDPS data. Another concern is that under adverse conditions, such as DDoS attacks or major malware
incidents, the network devices shared by the organization’s primary networks and VLAN might become
completely saturated, negatively impacting the availability and performance of the IDPS.
3.2 Security Capabilities
Most IDPS technologies can provide a wide variety of security capabilities. Sections 3.2.1 through 3.2.4
describe common security capabilities, divided into four categories: information gathering, logging,
detection, and prevention, respectively.
3.2.1 Information Gathering Capabilities
Some IDPS technologies offer information gathering capabilities, such as collecting information on hosts
or networks from observed activity. Examples include identifying hosts and the operating systems and
applications that they use, and identifying general characteristics of the network.
3.2.2 Logging Capabilities
IDPSs typically perform extensive logging of data related to detected events. This data can be used to
confirm the validity of alerts, investigate incidents, and correlate events between the IDPS and other
logging sources. Data fields commonly used by IDPSs include event date and time, event type,
importance rating (e.g., priority, severity, impact, confidence), and prevention action performed (if any).
Specific types of IDPSs log additional data fields, such as network-based IDPSs performing packet
captures and host-based IDPSs recording user IDs. IDPS technologies typically permit administrators to
store logs locally and send copies of logs to centralized logging servers (e.g., syslog, security information
and event management software). Generally, logs should be stored both locally and centrally to support
the integrity and availability of the data (e.g., a compromise of the IDPS could allow attackers to alter or
destroy its logs). 8 Also, IDPSs should have their clocks synchronized using the Network Time Protocol
(NTP) or through frequent manual adjustments so that their log entries have accurate timestamps. 9
8
For additional information on log management, see NIST SP 800-92, Guide to Computer Security Log Management, which
is available at http://csrc.nist.gov/publications/nistpubs/.
9
NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response, contains additional information on the
importance of clock synchronization for investigating events and correlating information across systems. The publication is
available at http://csrc.nist.gov/publications/nistpubs/.
3-2
3.2.3 Detection Capabilities
IDPS technologies typically offer extensive, broad detection capabilities. Most products use a
combination of detection techniques, which generally supports more accurate detection and more
flexibility in tuning and customization. The types of events detected and the typical accuracy of detection
vary greatly depending on the type of IDPS technology. Most IDPSs require at least some tuning and
customization to improve their detection accuracy, usability, and effectiveness, such as setting the
prevention actions to be performed for particular alerts. Technologies vary widely in their tuning and
customization capabilities. Typically, the more powerful a product’s tuning and customization
capabilities are, the more its detection accuracy can be improved from the default configuration.
Organizations should carefully consider the tuning and customization capabilities of IDPS technologies
when evaluating products. Examples of such capabilities are as follows:
Thresholds. A threshold is a value that sets the limit between normal and abnormal behavior.
Thresholds usually specify a maximum acceptable level, such as x failed connection attempts in 60
seconds, or x characters for a filename length. Thresholds are most often used for anomaly-based
detection and stateful protocol analysis.
Blacklists and Whitelists. A blacklist is a list of discrete entities, such as hosts, TCP or UDP port
numbers, ICMP types and codes, applications, usernames, URLs, filenames, or file extensions, that
have been previously determined to be associated with malicious activity. Blacklists, also known as
hot lists, are typically used to allow IDPSs to recognize and block activity that is highly likely to be
malicious, and may also be used to assign a higher priority to alerts that match entries on the
blacklists. Some IDPSs generate dynamic blacklists that are used to temporarily block recently
detected threats (e.g., activity from an attacker’s IP address). A whitelist is a list of discrete entities
that are known to be benign. Whitelists are typically used on a granular basis, such as protocol-by-
protocol, to reduce or ignore false positives involving known benign activity from trusted hosts.
Whitelists and blacklists are most commonly used in signature-based detection and stateful protocol
analysis.
Alert Settings. Most IDPS technologies allow administrators to customize each alert type.
Examples of actions that can be performed on an alert type include the following:
– Toggling it on or off 10
– Setting a default priority or severity level
– Specifying what information should be recorded and what notification methods (e.g., e-mail,
pager) should be used
– Specifying which prevention capabilities should be used.

Some products also suppress alerts if an attacker generates many alerts in a short period of time, and
may also temporarily ignore all future traffic from the attacker. This is to prevent the IDPS from
being overwhelmed by alerts.
Code Viewing and Editing. Some IDPS technologies permit administrators to see some or all of the
detection-related code. This is usually limited to signatures, but some technologies allow
administrators to see additional code, such as programs used to perform stateful protocol analysis.
10
In some IDPS technologies, turning off an alert also disables related detection capabilities; in other products, the detection
processing is still done but an alert message is not generated. For technologies in the first category, shutting off unneeded
alerts can reduce the load on the IDPS.
3-3
Viewing the code can help analysts to determine why particular alerts were generated, helping to
validate alerts and identify false positives. The ability to edit all detection-related code and write new
code (e.g., new signatures) is necessary to fully customize certain types of detection capabilities. For
example, a particular alert might be generated by a complex series of events involving several code
modules; customizing the IDPS to understand organization-specific characteristics might not be
possible without editing the code directly. Editing the code requires programming and intrusion
detection skills; also, some IDPSs use proprietary programming languages, which would necessitate
the programmer learning a new language. Bugs introduced into the code during the customization
process could cause the IDPS to function incorrectly or fail altogether, so administrators should treat
code customization as they would any other alteration of production systems’ code.
Administrators should review tuning and customizations periodically to ensure that they are still accurate.
For example, whitelists and blacklists should be checked regularly and all entries validated to ensure that
they are still accurate and necessary. Thresholds and alert settings might need to be adjusted periodically
to compensate for changes in the environment and in threats. Edits to detection code might need to be
replicated whenever the product is updated (e.g., patched, upgraded). Administrators should also ensure
that any products collecting baselines for anomaly-based detection have their baselines rebuilt
periodically as needed to support accurate detection.
3.2.4 Prevention Capabilities
Most IDPSs offer multiple prevention capabilities; the specific capabilities vary by IDPS technology type.
IDPSs usually allow administrators to specify the prevention capability configuration for each type of
alert. This usually includes enabling or disabling prevention, as well as specifying which type of
prevention capability should be used. Some IDPS sensors have a learning or simulation mode that
suppresses all prevention actions and instead indicates when a prevention action would have been
performed. This allows administrators to monitor and fine-tune the configuration of the prevention
capabilities before enabling prevention actions, which reduces the risk of inadvertently blocking benign
activity.
3.3 Management
Most IDPS products offer similar management capabilities. This section discusses major aspects of
management—implementation, operation, and maintenance—and provides recommendations for
performing them effectively and efficiently. It also briefly discusses the skills needed for IDPS
management and provides recommendations for gaining these skills.
3.3.1 Implementation
Once an IDPS product has been selected, the administrators need to design an architecture, perform IDPS
component testing, and deploy and secure the IDPS components. Sections 3.3.1.1 through 3.3.1.3
provide more information on these actions.
3.3.1.1 Architecture Design
The first step in IDPS implementation is designing an architecture. Architectural considerations include
the following:
Where the sensors or agents should be placed
3-4
How reliable the solution should be and what measures should be used to achieve that reliability, such
as having multiple sensors monitor the same activity in case a sensor fails, or using multiple
management servers so that a backup server can be used in case the primary server fails
Where the other components of the IDPS will be located (e.g., management servers, database servers,
consoles), and how many of each component are needed to achieve the necessary usability,
redundancy, and load balancing goals
With which other systems the IDPS needs to interface, including the following:
– Systems to which it provides data, such as security information and event management software,
centralized log servers, e-mail servers, and paging systems
– Systems on which it initiates prevention responses (e.g., firewalls, routers, switches)
– Systems that manage IDPS components, such as network management software (for a
management network) or patch management software (for keeping consoles’ operating systems
and applications fully up-to-date)
Whether or not a management network will be used; if so, what its design will be, and if not, how the
IDPS communications will be protected on the standard networks
What other security controls and technologies need to be altered to accommodate IDPS deployment,
such as changing firewall rulesets to allow IDPS components to communicate.
3.3.1.2 Component Testing and Deployment
Organizations should consider implementing the components in a test environment first, instead of a
production environment, to reduce the likelihood of implementation problems disrupting the production
networks. When the components are being deployed to production networks, organizations should
initially activate only a few IDPS sensors or agents, with their prevention capabilities disabled. Because a
new deployment is likely to generate a large number of false positives until fully tuned and customized,
activating many sensors or agents at once might overwhelm the management servers and consoles,
making it difficult for administrators to perform tuning and customization. Many false positives are
likely to be the same across sensors or agents, so it is helpful to identify such false positives either during
the testing process or when deploying the first few sensors or agents, so that those false positives can be
addressed before widespread deployment. A phased deployment of sensors or agents is also helpful in
identifying potential problems with scalability.
Implementing an IDPS can necessitate brief network or system outages for component installation. As
mentioned above, performing a deployment in a test environment can be very helpful in identifying likely
implementation problems, so that they can be mitigated appropriately when the production deployment
occurs.
Appliance-based IDPS components are typically simple to deploy. Administrators might need to perform
software updates or signature updates to ensure the IDPS software is current. Otherwise, administrators
usually just need to provide power and connect network cables, boot the appliance, and perform some
basic configuration (e.g., enter a product license key, assign a name to the sensor).
Software-based IDPS components usually take more time to deploy than appliance-based components.
The organization first needs to acquire the appropriate hardware, which might include purchasing high-
bandwidth network cards and otherwise ensuring that the hardware is robust enough for the IDPS. Next,
administrators need to install an operating system (OS) that is compatible with the IDPS software, and
3-5
then harden the host as much as possible. Hardening should include updating the OS, services, and
applications, including the IDPS software. Administrators also need to perform basic configuration of the
IDPS software, just as is done for appliance-based IDPS components.
After deploying either appliance-based or software-based IDPS components, considerable effort may be
needed to configure the products’ detection and prevention capabilities, depending on the type of IDPS
being deployed. Without performing this configuration work, some IDPSs might be capable of detecting
only a small number of older, easily identified attacks.
3.3.1.3 Securing IDPS Components
Securing IDPS components is very important because IDPSs are often targeted by attackers. If an
attacker can compromise an IDPS, it can be rendered useless in detecting subsequent attacks against other
hosts. Also, IDPSs often contain sensitive information such as host configurations and known
vulnerabilities that could be helpful in planning additional attacks. In addition to hardening software-
based IDPS components and ensuring that all IDPS components are fully up-to-date, administrators
should perform additional actions to ensure that the IDPS components themselves are secured
appropriately. Specific security recommendations are as follows:
Administrators should create separate accounts for each user and administrator of the IDPS, and
assign each account only the necessary privileges.
Administrators should configure firewalls, routers, and other packet filtering devices to limit direct
access to all IDPS components to only those hosts that need such access.
Administrators should ensure that all IDPS management communications are protected appropriately,
either through physical (e.g., management network) or logical (e.g., management VLAN) separation,
or through encryption of communications. If encryption is used for protection, it should be performed
using FIPS-approved encryption algorithms. 11 Many products encrypt their communications using
Transport Layer Security (TLS); for products that do not provide sufficient protection through
encryption, organizations should consider using a virtual private network (VPN) or other encrypted
tunneling method to protect the traffic.
Some organizations also require the use of strong authentication for remote access to IDPS components,
such as two-factor authentication. This provides an additional layer of security.
3.3.2 Operation and Maintenance
Nearly all IDPS products are designed to be operated and maintained through a graphical user interface
(GUI), also known as the console. The console typically permits administrators to configure and update
the sensors and management servers, as well as monitor their status (e.g., agent failure, packet dropping).
Administrators can also manage user accounts, customize reports, and perform many other functions
using the console. IDPS users can also perform many functions through the console, including
monitoring and analyzing the IDPS data and generating reports. Most IDPSs permit administrators to set
up individual user accounts for each administrator and user, and to grant each account only the privileges
necessary for each person’s role. The console often reflects this by showing different menus and options
based on the currently authenticated account’s designated role. Some products also provide finer-grained
11
Federal agencies must use Federal Information Processing Standard (FIPS) approved encryption algorithms contained in
validated cryptographic modules. The Cryptographic Module Validation Program (CMVP) at NIST coordinates FIPS
testing; the CMVP Web site is located at http://csrc.nist.gov/cryptval/. See http://csrc.nist.gov/cryptval/des.htm for
information on FIPS-approved symmetric key algorithms. FIPS 140-2, Security Requirements for Cryptographic Modules,
is available at http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf.
3-6
access control, such as specifying for which sensors or agents particular users can monitor or analyze data
or generate reports or particular administrators can alter configurations. This allows a large IDPS
deployment to be divided into logical units for operational purposes.
Some IDPS products also offer command-line interfaces (CLI). Unlike GUI consoles, which are typically
used for remote management of sensors or agents and management servers, CLIs are typically used for
local management of those components. Sometimes a CLI can be reached remotely through an encrypted
connection established through secure shell (SSH) or other means. Consoles are typically much easier to
use than CLIs, and CLIs often provide only some of the functionality that consoles provide.
The rest of this section provides additional information on the operation and maintenance of IDPSs.
Section 3.3.2.1 describes how users can make effective use of consoles in their daily IDPS tasks. Section
3.3.2.2 provides more information on ongoing maintenance of the technologies, with Section 3.3.2.3
focusing specifically on acquiring and applying updates.
3.3.2.1 Typical Use
Most IDPS consoles offer many features to assist users in their daily tasks. For example, most consoles
offer drill-down capabilities, which means that when a user examines an alert, more details and
information are available in layers. 12 This allows users to see basic information on many alerts at once,
and to show additional information on particular events of interest as needed. Some products allow users
to see extensive supporting information, such as packet captures (both raw and parsed with a protocol
analyzer) and related alerts (e.g., other alerts for the same source or destination), as well as documentation
on the alert itself. Generally, the more data that the IDPS records, the easier it is for analysts to determine
what has happened. Some consoles also offer incident response features, such as turning an alert into an
incident case and providing workflow mechanisms that allow users to document additional information
on the alert and route the alert to particular users or groups of users for further review.
Most consoles also offer various reporting functions. For example, administrators or users might be able
to use the console to have certain reports run at set times and to e-mail or transfer the reports to the
appropriate users or hosts. Many consoles also allow users to generate reports as needed (including
reports for specific incidents) and to customize reports as needed. If an IDPS product stores its logs in a
database or in an easily parsed file format (e.g., comma-separated values in a text file), database queries
or scripts can also be used to generate custom reports, particularly if the console does not offer
sufficiently flexible report customization.
3.3.2.2 Ongoing Solution Maintenance
Administrators should maintain IDPSs on an ongoing basis. This should include the following:
Monitoring the IDPS components themselves for operational and security issues
Periodically verifying that the IDPS is functioning properly (e.g., processing events, alerting
appropriately on suspicious activity) 13
12
A detailed discussion of the analysis of IDPS data is outside the scope of this document. For more information, see NIST
SP 800-86, Guide to Integrating Forensic Techniques into Incident Response, which is available at
http://csrc.nist.gov/publications/nistpubs/. NIST SP 800-86 discusses the analysis of data from IDPSs and other sources of
security event information.
13
One way of verifying component functionality is to perform periodic testing of the IDPS, either in a test environment or a
production environment. Performing such testing in a production environment can inadvertently disrupt operations. See
Section 9 for additional information on IDPS testing.
3-7
Performing regular vulnerability assessments

Receiving notifications from vendors of security problems with IDPS components (including OSs and
non-IDPS applications) and responding appropriately to those notifications
Receiving notifications from the IDPS vendor of updates, and performing testing and deployment of
the updates. Updates are described in Section 3.3.2.3.
3.3.2.3 Acquiring and Applying Updates
There are two types of IDPS updates: software updates and signature updates. Software updates fix bugs
in the IDPS software or add new functionality, while signature updates add new detection capabilities or
refine existing detection capabilities (e.g., reducing false positives). For many IDPSs, signature updates
cause program code to be altered or replaced, so they are really a specialized form of software update.
For other IDPSs, signatures are not written in code, so a signature update is a change to the configuration
data for the IDPS.
Software updates can include any or all IDPS components, including sensors, agents, management
servers, and consoles. Software updates for sensors and management servers, particularly appliance-
based devices, are often applied by replacing an existing IDPS CD with a new one and rebooting the
device. Many IDPSs run the software directly from the CD, so that no software installation is required.
Other components, such as agents, require an administrator to install software or apply patches, either
manually on each host or automatically through IDPS management software. Some vendors make
software and signature updates available for download from their Web sites or other servers; often, the
administrator interfaces for IDPSs have features for downloading and installing such updates.
Administrators should verify the integrity of updates before applying them, because updates could have
been inadvertently or intentionally altered or replaced. The recommended verification method depends
on the update’s format, as follows:
Files downloaded from a Web site or FTP site. Administrators should compare file checksums
provided by the vendor with checksums that they compute for the downloaded files.
Update downloaded automatically through the IDPS user interface. If an update is downloaded
as a single file or a set of files, either checksums provided by the vendor should be compared to
checksums generated by the administrator, or the IDPS user interface itself should perform some sort
of integrity check. In some cases, updates might be downloaded and installed as one action,
precluding checksum verification; the IDPS user interface should check each update’s integrity as
part of this.
Removable media (e.g., CD, DVD). Vendors may not provide a specific method for customers to
verify the legitimacy of removable media apparently sent by the vendors. If media verification is a
concern, administrators should contact their vendors to determine how the media can be verified, such
as comparing vendor-provided checksums to checksums computed for files on the media, or verifying
digital signatures on the media’s contents to ensure they are valid. Administrators should also
consider scanning the media for malware, with the caveat that false positives might be triggered by
IDPS signatures for malware on the media.
IDPSs are typically designed so that applying software and signature updates has no effect on existing
tuning and customization settings. The primary exception is code customization, which often has to be
repeated when code updates from the vendor are installed. For any IDPS, administrators should back up
configuration settings periodically and before applying software or signature updates to ensure that
existing settings are not inadvertently lost.
3-8
Administrators should test software and signature updates before applying them except for emergency
situations (e.g., a signature identifies a new, active threat that is damaging the organization and cannot
otherwise be detected or blocked). It is beneficial to have at least one sensor or agent host (one for each
type of agent) that is used strictly for testing updates. New detection capabilities can often cause large
numbers of alerts to be triggered, so testing signature updates on a single sensor or agent host, even
briefly (e.g., loading the update and observing how the IDPS functions when monitoring typical activity),
can help to identify signatures that are likely to be problematic and should possibly be disabled. In non-
emergency situations, software and signature updates should be tested and deployed using the same
practices that would be used for updating any other major security controls, such as firewalls and
antivirus software. When updates are deployed into production, administrators should be ready to disable
particular signatures or perform other minor reconfigurations as needed.
3.3.3 Building and Maintaining Skills
Various skills are needed for IDPS implementation, operation, and maintenance, including the following:
The administrators implementing IDPS components need to understand the basics of system
administration, network administration, and information security.
The administrators tuning and customizing the IDPS need reasonably comprehensive knowledge of
information security and IDPS principles. An understanding of incident response principles and the
organization’s incident response policies and procedures is also recommended. Administrators
should also have an understanding of the network protocols, applications, and operating systems to be
monitored by the IDPS.
Programming skills might also be needed for extensive code customization, report writing, and other
tasks.
Skills in IDPS principles can be built and maintained through many methods, including training, technical
conferences, books and other technical references, and mentoring programs. Knowledge of specific IDPS
products can also be gained through several methods, including the following:
Vendor Training. Many vendors of IDPS products offer one or more training courses for people
that will be administering or using their products. Training courses are often hands-on, permitting
attendees to learn how to use the technology in a non-production environment.
Product Documentation. Most products offer several manuals, such as an installation guide, a
user’s guide, and an administrator’s guide. Some also offer separate guides or databases that provide
supplemental information for alerts and signatures.
Technical Support. Most vendors offer technical support for their customers, either as part of
purchasing a product or for an additional fee. Support is used primarily to resolve problems and
clarify the capabilities of the product to its users and administrators.
Professional Services. Some vendors offer professional services, which is essentially consulting
services provided by the vendor. For example, an organization could pay a vendor to write custom
signatures or reports, or to assist administrators in understanding how to tune and customize their
sensors effectively.
User Communities. Some products have active user communities, which typically function through
mailing lists or online forums. Users can exchange information and code with each other, and assist
each other in troubleshooting problems. Although user communities can be a source of information,
administrators and users should be cautious when using them, because posting details about an
3-9
organization’s IDPS configuration or problems could inadvertently reveal sensitive information about
the organization’s security infrastructure, systems, and networks.
3.4 Summary
The typical components in an IDPS solution are sensors or agents, management servers, database servers,
and consoles. Sensors and agents monitor and analyze activity; sensors are used to monitor networks and
agents to monitor hosts. Management servers receive information from sensors or agents and manage
them. Database servers are repositories for event information recorded by the sensors or agents and
management servers. Consoles are programs that provide interfaces for IDPS users and administrators.
These components can be connected to each other through an organization’s standard networks or through
a separate network strictly designed for security software management known as a management network.
A management network helps to protect the IDPS from attack and to ensure it has adequate bandwidth
under adverse conditions. A virtual management network can be created using a virtual local area
network (VLAN); this provides protection for IDPS communications, but not as much protection as a
management network would provide.
Most IDPSs can provide a wide variety of security capabilities. Some products offer information
gathering capabilities, such as collecting information on hosts or networks from observed activity. IDPSs
also typically perform extensive logging of data related to detected events. This data can be used to
confirm the validity of alerts, investigate incidents, and correlate events between the IDPS and other
logging sources. Generally, logs should be stored both locally and centrally to support the integrity and
availability of the data.
IDPSs typically offer extensive, broad detection capabilities. The types of events detected and the typical
accuracy of detection vary greatly depending on the type of IDPS technology. Most IDPSs require at
least some tuning and customization to improve their detection accuracy, usability, and effectiveness.
Typically, the more powerful a product’s tuning and customization capabilities are, the more its detection
accuracy can be improved from the default configuration. Examples of these capabilities are thresholds,
blacklists and whitelists, alert settings, and code editing. Organizations should carefully consider the
tuning and customization capabilities of IDPSs when evaluating products. Administrators should review
tuning and customizations periodically to ensure that they are still accurate. Administrators should also
ensure that any products collecting baselines for anomaly-based detection have those baselines rebuilt
periodically as needed to support accurate detection.
Most IDPSs offer multiple prevention capabilities; the specific capabilities vary by IDPS technology type.
IDPSs usually allow administrators to specify the prevention capability configuration for each type of
alert. This includes enabling or disabling prevention, as well as specifying which type of prevention
capability should be used.
Once an IDPS product has been selected, the administrators need to design an architecture, perform IDPS
component testing, and deploy and secure the IDPS components. There are many architectural
considerations, including component placement, solution reliability, interoperability with other systems,
management network architecture, and necessary changes to other security controls. Before performing a
production implementation, organizations should consider implementing the components in a test
environment first to reduce the likelihood of implementation problems disrupting production. When the
components are being deployed to production networks, organizations should initially activate only a few
IDPS sensors or agents. Because a new deployment is likely to generate a large number of false positives
until fully tuned and customized, activating many sensors or agents at once might overwhelm the
management servers and consoles, making it difficult for administrators to perform tuning and
customization.
3-10
In addition to hardening software-based IDPS components and ensuring that all IDPS components are
fully up-to-date, administrators should perform additional actions to ensure that the IDPS components
themselves are secured appropriately. Examples include creating separate accounts for each IDPS user
and administrator, restricting network access to IDPS components, and ensuring that IDPS management
communications are protected appropriately. All encryption used for protection should be performed
using FIPS-approved encryption algorithms.
Administrators should maintain IDPSs on an ongoing basis. This should include monitoring the IDPS
components for operational and security issues, performing regular vulnerability assessments, responding
appropriately to vulnerabilities in the IDPS components, and testing and deploying IDPS software and
signature updates. Administrators should verify the integrity of updates before applying them, because
updates could have been inadvertently or intentionally altered or replaced. Administrators should test
software and signature updates before applying them, except for emergency situations. Administrators
should also back up configuration settings periodically and before applying software or signature updates
to ensure that existing settings are not inadvertently lost.
3-11
3-12
4. Network-Based IDPS
A network-based IDPS monitors network traffic for particular network segments or devices and analyzes
network, transport, and application protocols to identify suspicious activity. This section provides a
detailed discussion of network-based IDPS technologies. First, it contains a brief overview of TCP/IP,
which is background material for understanding the rest of Section 4. Next, it covers the major
components of network-based IDPSs and explains the architectures typically used for deploying the
components. It also examines the security capabilities of the technologies in depth, including the
methodologies they use to identify suspicious activity. The rest of the section discusses the management
capabilities of the technologies and provides recommendations for implementation and operation.
4.1 Networking Overview
TCP/IP is widely used throughout the world to provide network communications. TCP/IP
communications are composed of four layers that work together. When a user wants to transfer data
across networks, the data is passed from the highest layer through intermediate layers to the lowest layer,
with each layer adding more information. The lowest layer sends the accumulated data through the
physical network; the data is then passed up through the layers to its destination. Essentially, the data
produced by a layer is encapsulated in a larger container by the layer below it. The four TCP/IP layers,
from highest to lowest, are shown in Figure 4-1.
Application Layer. This layer sends and receives data for particular applications, such as
Domain Name System (DNS), Hypertext Transfer Protocol (HTTP), and Simple Mail Transfer
Protocol (SMTP).
Transport Layer. This layer provides connection-oriented or connectionless services for
transporting application layer services between networks. The transport layer can optionally
ensure the reliability of communications. Transmission Control Protocol (TCP) and User
Datagram Protocol (UDP) are commonly used transport layer protocols.
Internet Protocol (IP) Layer (also known as Network Layer). This layer routes packets
across networks. IPv4 is the fundamental network layer protocol for TCP/IP. Other commonly
used protocols at the network layer are IPv6, Internet Control Message Protocol (ICMP), and
Internet Group Management Protocol (IGMP).
Hardware Layer (also known as Data Link Layer). This layer handles communications on the
physical network components. The best known data link layer protocol is Ethernet.
Figure 4-1. TCP/IP Layers
The four TCP/IP layers work together to transfer data between hosts. Network-based IDPSs typically
perform most of their analysis at the application layer. They also analyze activity at the transport and
network layers both to identify attacks at those layers and to facilitate the analysis of the application layer
activity (e.g., a TCP port number may indicate which application is being used). Some network-based
IDPSs also perform limited analysis at the hardware layer. Sections 4.1.1 through 4.1.4 describe each
layer in greater detail.
4.1.1 Application Layer
The application layer enables applications to transfer data between an application server and client. An
example of an application layer protocol is Hypertext Transfer Protocol (HTTP), which transfers data
between a Web server and a Web browser. Other common application layer protocols include Domain
Name System (DNS), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), and Simple
4-1
Network Management Protocol (SNMP). There are hundreds of unique application layer protocols in
common use, and many more that are not so common. Regardless of the protocol in use, application data
is generated and then passed to the transport layer for further processing.
4.1.2 Transport Layer
The transport layer is responsible for packaging data so that it can be transmitted between hosts. Most
applications that communicate over networks rely on the transport layer to ensure reliable delivery of
data. Generally, this is accomplished by using TCP. When loss of some application data is not a concern
(e.g., streaming audio, video), or the application itself ensures reliable delivery of data, UDP is typically
used. UDP is connectionless; one host simply sends data to another host without any preliminary
negotiations. Each TCP or UDP packet has a source port number and a destination port number. One of
the ports is associated with a server application on one system; the other port is associated with a
corresponding client application on the other system. Client systems typically select any available port
number for application use, whereas server systems usually have a static port number dedicated to each
application. Although UDP and TCP ports are very similar, they are distinct from each other and are not
interchangeable.
4.1.3 Network Layer
The network layer, also known as the IP layer, is responsible for handling the addressing and routing of
data that it receives from the transport layer. After the network layer has encapsulated the transport layer
data, the resulting logical units are referred to as packets. Each packet contains a header, which is
composed of various fields that specify characteristics of the transport protocol in use; optionally, packets
may also contain a payload, which holds the application data. The IP header contains a field called IP
Version, which indicates which version of IP is in use. Typically this is set to 4 for IPv4; but the use of
IPv6 is increasing, so this field may be set to 6 instead. 14 Other significant IP header fields are as
follows:
Source and Destination IP Addresses. These are the “from” and “to” addresses that are intended to
indicate the endpoints of the communication. 15 Examples of IP addresses are 10.3.1.70 (IPv4) and
1000::2F:8A:400:427:9BD1 (IPv6).
IP Protocol Number. This indicates which network or transport layer protocol the IP payload
contains. 16 Commonly used IP numbers include 1 (ICMP), 6 (TCP), 17 (UDP), and 50
(Encapsulating Security Payload [ESP]).
The network layer is also responsible for providing error and status information involving the addressing
and routing of data; it does this with ICMP. ICMP is a connectionless protocol that makes no attempt to
guarantee that its error and status messages are delivered. Because it is designed to transfer limited
information, not application data, ICMP does not have ports; instead, it has message types, which indicate
the purpose of each ICMP message. 17 Some message types also have message codes, which can be
thought of as subtypes. For example, the ICMP message type Destination Unreachable has several
14
There are other possible IP version numbers as well, although none are commonly used. The official list of valid IP Version
field values is available at http://www.iana.org/assignments/version-numbers. This document assumes the use of IPv4,
unless otherwise specified.
15
IP addresses are often inaccurate or misleading for identifying the actual endpoints of communication.
16
The official list of valid IP Protocol Number values is available at http://www.iana.org/assignments/protocol-numbers.
17
The current list of valid ICMP types is available at http://www.iana.org/assignments/icmp-parameters.
4-2
possible message codes that indicate what is unreachable (e.g., network, host, protocol). Most ICMP
message types are not intended to elicit a response. 18
4.1.4 Hardware Layer
As the name implies, the hardware layer, also called the data link layer, involves the physical components
of the network, including cables, routers, switches, and network interface cards (NIC). The hardware
layer also includes various hardware layer protocols, with Ethernet being the most widely used. Ethernet
relies on the concept of a media access control (MAC) address, which is a unique six-byte value (such as
00-02-B4-DA-92-2C) that is permanently assigned to a particular NIC. 19 Each frame, the logical unit at
the hardware layer, contains two MAC addresses, which indicate the MAC address of the NIC that just
routed the frame and the MAC address of the next NIC to which the frame is being sent. As a frame
passes through networking equipment (such as routers and firewalls) on its way between the original
source host and the final destination host, the MAC addresses are updated to refer to the local source and
destination. Several separate hardware layer transmissions may be linked together within a single
network layer transmission.
In addition to the MAC addresses, each frame also contains an EtherType value, which indicates the
protocol that the frame’s payload contains (typically IP or Address Resolution Protocol [ARP]). 20 When
IP is used, each IP address maps to a particular MAC address. (Because multiple IP addresses can map to
a single MAC address, a MAC address does not necessarily uniquely identify an IP address.)
This section describes the major components of typical network-based IDPSs and illustrates the most
common network architectures for these components. It also provides recommendations for the
placement of network-based IDPS sensors.
A typical network-based IDPS is composed of sensors, one or more management servers, multiple
consoles, and optionally one or more database servers (if the network-based IDPS supports their use). All
of these components are similar to other types of IDPS technologies, except for the sensors. A network-
based IDPS sensor monitors and analyzes network activity on one or more network segments. The
network interface cards that will be performing monitoring are placed into promiscuous mode, which
means that they will accept all incoming packets that they see, regardless of their intended destinations.
Most IDPS deployments use multiple sensors, with large deployments having hundreds of sensors.
Sensors are available in two formats:
Appliance. An appliance-based sensor is comprised of specialized hardware and sensor software.

The hardware is typically optimized for sensor use, including specialized NICs and NIC drivers for
efficient capture of packets, and specialized processors or other hardware components that assist in
analysis. Parts or all of the IDPS software might reside in firmware for increased efficiency.
18
ICMP is designed to limit responses, particularly to error messages. If ICMP had not been designed in this way, message
loops could occur. For example, if Host A received an ICMP error message from Host B and responded with an error
message, and Host B responded to that error message with an error message, the two hosts could continue sending error
messages regarding the error messages.
19
Various software utilities are publicly available that allow people to configure systems to spoof other MAC addresses.
There have also been cases in which manufacturers accidentally created NICs with duplicate MAC addresses.
20
EtherType value 0x0800 is IP, while 0x0806 is ARP. See http://www.iana.org/assignments/ethernet-numbers for more
information on EtherType values.
4-3
Appliances often use a customized, hardened operating system (OS) that administrators are not
intended to access directly.
Software Only. Some vendors sell sensor software without an appliance. Administrators can install
the software onto hosts that meet certain specifications. The sensor software might include a
customized OS, or it might be installed onto a standard OS just as any other application would.
4.2.2 Network Architectures and Sensor Locations
Organizations should consider using management networks for their network-based IDPS deployments
whenever feasible. If an IDPS is deployed without a separate management network, organizations should
consider whether or not a VLAN is needed to protect the IDPS communications.
In addition to choosing the appropriate network for the components, administrators also need to decide
where the IDPS sensors should be located. Sensors can be deployed in one of two modes:
Inline. An inline sensor is deployed so that the network traffic it is monitoring must pass through it,
much like the traffic flow associated with a firewall. In fact, some inline sensors are hybrid
firewall/IDPS devices, while others are simply IDPSs. The primary motivation for deploying IDPS
sensors inline is to enable them to stop attacks by blocking network traffic. Inline sensors are
typically placed where network firewalls and other network security devices would be placed—at the
divisions between networks, such as connections with external networks and borders between
different internal networks that should be segregated. Inline sensors that are not hybrid firewall/IDPS
devices are often deployed on the more secure side of a network division so that they have less traffic
to process. Figure 4-2 shows such a deployment. Sensors can also be placed on the less secure side
of a network division to provide protection for and reduce the load on the dividing device, such as a
firewall.
4-4
Figure 4-2. Inline Network-Based IDPS Sensor Architecture Example
Passive. A passive sensor is deployed so that it monitors a copy of the actual network traffic; no
traffic actually passes through the sensor. Passive sensors are typically deployed so that they can
monitor key network locations, such as the divisions between networks, and key network segments,
such as activity on a demilitarized zone (DMZ) subnet. Passive sensors can monitor traffic through
various methods, including the following:
– Spanning Port. Many switches have a spanning port, which is a port that can see all network
traffic going through the switch. Connecting a sensor to a spanning port can allow it to monitor
traffic going to and from many hosts. Although this monitoring method is relatively easy and
inexpensive, it can also be problematic. If a switch is configured or reconfigured incorrectly, the
spanning port might not be able to see all the traffic. Another problem with spanning ports is that
their use can be resource-intensive; when a switch is under heavy loads, its spanning port might
4-5
not be able to see all traffic, or spanning might be temporarily disabled. Also, many switches
have only one spanning port, and there is often a need to have multiple technologies, such as
network monitoring tools, network forensic analysis tools, and other IDPS sensors, monitor the
same traffic.
– Network Tap. A network tap is a direct connection between a sensor and the physical network
media itself, such as a fiber optic cable. The tap provides the sensor with a copy of all network
traffic being carried by the media. Installing a tap generally involves some network downtime,
and problems with a tap could cause additional downtime. Also, unlike spanning ports, which are
usually already present throughout an organization, network taps need to be purchased as add-ons
to the network.
– IDS Load Balancer. An IDS load balancer is a device that aggregates and directs network
traffic to monitoring systems, including IDPS sensors. A load balancer can receive copies of
network traffic from one or more spanning ports or network taps and aggregate traffic from
different networks (e.g., reassemble a session that was split between two networks). The load
balancer then distributes copies of the traffic to one or more listening devices, including IDPS
sensors, based on a set of rules configured by an administrator. The rules tell the load balancer
which types of traffic to provide to each listening device. Common configurations include the
following:
• Send all traffic to multiple IDPS sensors. This could be done for high availability or to
have multiple types of IDPS sensors perform concurrent analysis of the same activity.
• Dynamically split the traffic among multiple IDPS sensors based on volume. This is
typically done to perform load balancing so that no sensor is overwhelmed with the
amount of traffic and corresponding analysis.
• Split the traffic among multiple IDPS sensors based on IP addresses, protocols, or
other characteristics. This could be done for load balancing purposes, such as having
one IDPS sensor dedicated to Web activity and another IDPS sensor monitoring all other
activity. Splitting traffic could also be done to perform more detailed analysis of certain
types of traffic (e.g., activity involving the most important hosts).
Splitting traffic among multiple IDPS sensors can cause a reduction in detection accuracy if
related events or portions of a single event are seen by different sensors. For example, suppose
that two sensors each see different steps of an attack; if each step is considered benign on its own
but the two steps in sequence are malicious, then the attack might not be recognized.
Figure 4-3 shows examples of passive sensors connected to the monitored network using IDS load
balancers, network taps, and spanning ports.
As explained in Section 4.3.4, most techniques for having a sensor prevent intrusions require that the
sensor be deployed in inline mode, not passive. Because passive techniques monitor a copy of the traffic,
they typically provide no reliable way for a sensor to stop the traffic from reaching its destination. In
some cases, a passive sensor can place packets onto a network to attempt to disrupt a connection, but such
methods are generally less effective than inline methods. Generally, organizations should deploy sensors
inline if prevention methods will be used and passive if they will not.
4-6
Figure 4-3. Passive Network-Based IDPS Sensor Architecture Example
Network-based IDPS products provide a wide variety of security capabilities. Sections 4.3.1 through
4.3.4 describe common security capabilities, divided into four categories: information gathering, logging,
detection, and prevention, respectively. Some network-based IDPS products also provide some security
information and event management (SIEM) capabilities; see Section 8.2.2 for information on SIEM.
Some network-based IDPSs offer limited information gathering capabilities, which means that they can
collect information on hosts and the network activity involving those hosts. Examples of information
gathering capabilities are as follows:
4-7
Identifying Hosts. An IDPS sensor might be able to create a list of hosts on the organization’s
network arranged by IP address or MAC address. The list can be used as a profile to identify new
hosts on the network.
Identifying Operating Systems. An IDPS sensor might be able to identify the OSs and OS versions
used by the organization’s hosts through various techniques. For example, the sensor could track
which ports are used on each host, which could indicate a particular OS or OS family (e.g., Windows,
Unix). Another technique is to analyze packet headers for certain unusual characteristics or
combinations of characteristics that are exhibited by particular OSs; this is known as passive
fingerprinting. Some sensors can also identify application versions (as described below), which in
some cases implies which OS is in use. Knowing which OS versions are in use can be helpful in
identifying potentially vulnerable hosts.
Identifying Applications. For some applications, an IDPS sensor can identify the application
versions in use by keeping track of which ports are used and monitoring certain characteristics of
application communications. For example, when a client establishes a connection with a server, the
server might tell the client what application server software version it is running, and vice versa.
Information on application versions can be used to identify potentially vulnerable applications, as
well as unauthorized use of some applications.
Identifying Network Characteristics. Some IDPS sensors collect general information about
network traffic related to the configuration of network devices and hosts, such as the number of hops
between two devices. This information can be used to detect changes to the network configuration.
Network-based IDPSs typically perform extensive logging of data related to detected events. This data
can be used to confirm the validity of alerts, to investigate incidents, and to correlate events between the
IDPS and other logging sources. Data fields commonly logged by network-based IDPSs include the
following:
Timestamp (usually date and time)

Connection or session ID (typically a consecutive or unique number assigned to each TCP connection
or to like groups of packets for connectionless protocols)
Event or alert type 21
Rating (e.g., priority, severity, impact, confidence)
Network, transport, and application layer protocols
Source and destination IP addresses
Source and destination TCP or UDP ports, or ICMP types and codes
Number of bytes transmitted over the connection
Decoded payload data, such as application requests and responses
State-related information (e.g., authenticated username)
21
In the console, the event or alert type often links to supporting information for the specific vulnerability or exploit, such as
references for additional information and associated Common Vulnerabilities and Exposures (CVE) numbers.
4-8
Prevention action performed (if any).

Most network-based IDPSs can also perform packet captures. Typically this is done once an alert has
occurred, either to record subsequent activity in the connection or to record the entire connection if the
IDPS has been temporarily storing the previous packets.
Network-based IDPSs typically offer extensive and broad detection capabilities. Most products use a
combination of signature-based detection, anomaly-based detection, and stateful protocol analysis
techniques to perform in-depth analysis of common protocols; organizations should use network-based
IDPS products that use such a combination of techniques. The detection methods are usually tightly
interwoven; for example, a stateful protocol analysis engine might parse activity into requests and
responses, each of which is examined for anomalies and compared to signatures of known bad activity.
Some products also use the same techniques and provide the same functionality as network behavior
analysis (NBA) software; see Section 6 for additional information.
This section discusses the following aspects of detection capabilities:
Types of events detected

Detection accuracy
Tuning and customization
Technology limitations.
4.3.3.1 Types of Events Detected
The types of events most commonly detected by network-based IDPS sensors include the following:
Application layer reconnaissance and attacks (e.g., banner grabbing, buffer overflows, format
string attacks, password guessing, malware transmission). Most network-based IDPSs analyze
several dozen application protocols. Commonly analyzed ones include Dynamic Host Configuration
Protocol (DHCP), DNS, Finger, FTP, HTTP, 22 Internet Message Access Protocol (IMAP), Internet
Relay Chat (IRC), Network File System (NFS), Post Office Protocol (POP), rlogin/rsh, Remote
Procedure Call (RPC), Session Initiation Protocol (SIP), Server Message Block (SMB), SMTP,
SNMP, Telnet, and Trivial File Transfer Protocol (TFTP), as well as database protocols, instant
messaging applications, and peer-to-peer file sharing software.
Transport layer reconnaissance and attacks (e.g., port scanning, unusual packet fragmentation,
SYN floods). The most frequently analyzed transport layer protocols are TCP and UDP.
Network layer reconnaissance and attacks (e.g., spoofed IP addresses, illegal IP header values).
The most frequently analyzed network layer protocols are IPv4, ICMP, and IGMP. Many products
are also adding support for IPv6 analysis. The level of IPv6 analysis that network-based IDPSs can
22
Although network-based IDPSs can analyze HTTP protocol activity, they usually cannot perform analysis on the use of Web
services, such as Simple Object Access Protocol (SOAP) and Extensible Markup Language (XML) messages carried over
HTTP. Security technologies known as XML gateways or XML firewalls have been created specifically to analyze Web
services activity. In addition to providing intrusion prevention functions, these technologies also perform firewalling,
authentication and authorization services, access control, and audit logging. More information on XML gateways is
available from NIST SP 800-95, Guide to Web Services Security (DRAFT), which is available at
http://csrc.nist.gov/publications/drafts.html.
4-9
perform varies considerably among products. Some products provide no IPv6 support or can simply
alert administrators that IPv6 activity is present. Other products can do basic processing of IPv6 and
tunneled IPv6 traffic, such as recording source and destination IP addresses, and extracting payloads
(e.g., HTTP, SMTP) for in-depth analysis. Some products can do full analysis of the IPv6 protocol,
such as confirming the validity of IPv6 options, to identify anomalous use of the protocol.
Organizations with a current or future need to monitor IPv6 activity should carefully evaluate the
IPv6 analysis capabilities of network-based IDPS products. 23
Unexpected application services (e.g., tunneled protocols, backdoors, hosts running unauthorized
application services). These are usually detected through stateful protocol analysis methods, which
can determine if the activity in a connection is consistent with the expected application protocol, or
through anomaly detection methods, which can identify changes in network flows and open ports on
hosts.
Policy violations (e.g., use of inappropriate Web sites, use of forbidden application protocols). Some
types of security policy violations can be detected by IDPSs that allow administrators to specify the
characteristics of activity that should not be permitted, such as TCP or UDP port numbers, IP
addresses, Web site names, and other pieces of data that can be identified by examining network
traffic.
Some IDPSs can also monitor the initial negotiation conducted when establishing encrypted
communications to identify client or server software that has known vulnerabilities or is misconfigured.
This can include application layer protocols such as secure shell (SSH) and Secure Sockets Layer (SSL),
and network layer virtual private networking protocols such as IP Security (IPsec).
Network-based IDPS sensors can often determine if an attack is likely to succeed. For example, as
described in Section 4.3.3.3, sensors might know which Web server software versions are running on
each of the organization’s Web servers. If an attacker launches an attack against a Web server that is not
vulnerable to the attack, then the sensor might produce a low-priority alert; if the server is thought to be
vulnerable, then the sensor might produce a high-priority alert. IDPS sensors are typically configured to
stop attacks whether or not they are likely to succeed, but an IDPS might still log the activity with
different priority levels depending on what its outcome probably would have been if not blocked.
4.3.3.2 Detection Accuracy
Historically, network-based IDPSs have been associated with high rates of false positives and false
negatives. Most of the early technologies relied primarily on signature-based detection, which by itself is
accurate only for detecting relatively simple well-known threats. Newer technologies use a combination
of detection methods to increase accuracy and the breadth of detection, and generally the rates of false
positives and false negatives have declined. Another common problem with network-based IDPSs’
accuracy is that they typically require considerable tuning and customization to take into account the
characteristics of the monitored environment.
False positives and false negatives for network-based IDPS sensors can only be reduced somewhat
because of the complexity of the activities being monitored. A single sensor is often monitoring traffic
involving hundreds or thousands of internal and external hosts. The number and variety of OSs and
applications in use over the monitored network can be immense; also, OSs and applications are constantly
being changed. This makes it impossible for a sensor to understand everything it sees.
23
NIST SP 500-267, A Profile for IPv6 in the U.S. Government, Version 1.0 (DRAFT), provides recommendations for the
IPv6-handling capabilities of network-based IDPS products. The draft is available at http://www.antd.nist.gov/.
4-10
Even worse, sensors have to monitor activity for many different combinations of servers and clients. For
example, an organization could use 10 different types and versions of Web servers, which users could
access with 50 different types and versions of Web browsers. Each combination of browser and server
could have unique communication characteristics (e.g., sequence of commands, response codes) that
could impact the accuracy of analysis. Also, different configurations and customizations could be applied
to the browsers and servers. Security controls between the servers and clients that alter network activity,
such as firewalls and proxy servers, could cause additional difficulties for sensors.
Ideally, network-based IDPSs would be able to interpret all network activity just as the endpoints do. For
example, different types of Web servers can interpret the same Web request in different ways. Stateful
protocol analysis techniques often attempt to do this by replicating the processing performed by common
types of clients and servers. This allows the sensors to improve their detection accuracy slightly. Many
attackers employ client and server-specific processing characteristics, such as handling character
encodings, in their attacks as evasion techniques. Organizations should use network-based IDPSs that can
compensate for the use of common evasion techniques.
4.3.3.3 Tuning and Customization
As mentioned in Section 4.3.3.2, network-based IDPSs usually require extensive tuning and
customization to improve their detection accuracy. Examples of tuning and customization capabilities are
thresholds for port scans and application authentication attempts, blacklists and whitelists for host IP
addresses and usernames, and alert settings. Some products also provide code editing features, which is
usually limited to signatures but in some cases may allow access to additional code, such as programs
used to perform stateful protocol analysis.
Some network-based IDPSs can use information regarding the organization’s hosts to improve detection
accuracy. For example, an IDPS might allow administrators to specify the IP addresses used by the
organization’s Web servers, mail servers, and other common types of hosts, and also specify the types of
services provided by each host (e.g., the Web server application type and version run by each Web
server). This allows the IDPS to better prioritize alerts; for example, an alert for an Apache attack
directed at an Apache Web server would have a higher priority than the same attack directed at a different
type of Web server. Some network-based IDPSs can also import the results of vulnerability scans and use
them to determine which attacks would likely be successful if not blocked. This allows the IDPS to make
better decisions on prevention actions and prioritize alerts more accurately.
4.3.3.4 Technology Limitations
Although network-based IDPSs offer extensive detection capabilities, they do have some significant
limitations. Three of the most important are analyzing encrypted network traffic, handling high traffic
loads, and withstanding attacks against the IDPSs themselves. These limitations are discussed below.
Network-based IDPSs cannot detect attacks within encrypted network traffic, including virtual private
network (VPN) connections, HTTP over SSL (HTTPS), and SSH sessions. As previously mentioned,
some network-based IDPSs can do some analysis of the setup of encrypted connections, which can
identify that the client or server software has known vulnerabilities or is misconfigured. To ensure that
sufficient analysis is performed on payloads within encrypted network traffic, organizations should use
IDPSs that can analyze the payloads before they are encrypted or after they are decrypted. Examples
include placing network-based IDPS sensors to monitor unencrypted traffic (e.g., traffic that entered an
organization through a VPN gateway and has since been decrypted) and using host-based IDPS software
to monitor activity within the source or destination host.
4-11
Network-based IDPSs may be unable to perform full analysis under high loads. Passive IDPS sensors
might drop some packets, which could cause some incidents to go undetected, especially if stateful
protocol analysis methods are in use. For inline IDPS sensors, dropping packets under high loads causes
disruptions in network availability; also, delays in processing packets could cause unacceptably high
latency. To avoid this, organizations using inline IDPS sensors should select ones that can recognize high
load conditions and either pass certain types of network traffic through the sensor without performing full
analysis (i.e., partial or no analysis) or drop low-priority traffic to reduce load. Many vendors attempt to
optimize their sensors to provide better performance under high loads by taking measures such as using
specialized hardware (e.g., high-bandwidth network cards) and recompiling components of their software
to incorporate settings and other customizations made by administrators. Although vendors typically rate
their sensors by maximum bandwidth capability, the actual capacity of any product depends on several
factors, including the following:
The network, transport, and application layer protocols in use, and the depth of analysis performed for
each protocol. Vendors often rate their products based on their ability to perform reasonable analysis
of a “typical” mix of protocols. The level of analysis that an individual organization wants to perform
and the organization’s mix of protocols may vary significantly from the tested conditions.
The longevity of connections. For example, a sensor might have less overhead for one long-term
connection than several consecutive short-term connections.
The number of simultaneous connections. Sensors usually are limited as to how many connections
for which they can track state.
IDPS sensors are susceptible to various types of attacks. Attackers can generate unusually large volumes
of traffic, such as distributed denial of service (DDoS) attacks, and anomalous activity (e.g., unusually
fragmented packets) to attempt to exhaust a sensor’s resources or cause it to crash. Another attack
technique, known as blinding, generates network traffic that is likely to trigger many IDPS alerts in a
short period of time; typically, the network traffic is specially crafted to take advantage of typical
configurations of IDPS sensors. In many cases, the blinding traffic is not intended to actually attack any
targets. An attacker runs the “real” attack separately at the same time as the blinding traffic. The
attacker’s goal is that the blinding traffic will either cause the IDPS to fail in some way or generate so
many alerts that the alerts for the real attack will go unnoticed. Many IDPS sensors can recognize the use
of common DDoS and blinding tools and techniques; the sensors can alert administrators to the attack and
then ignore the rest of the activity, reducing the load on the sensors. Organizations should select products
that offer features that make them resistant to failure due to attack.
Network-based IDPS sensors offer various prevention capabilities, including the following (grouped by
sensor type):
Passive Only
– Ending the Current TCP Session. A passive sensor can attempt to end an existing TCP session
by sending TCP reset packets to both endpoints; this is sometimes called session sniping. 24 The
sensor does this to make it appear to each endpoint that the other endpoint is trying to end the
connection. The goal is for one of the endpoints to terminate the connection before an attack can
succeed. Unfortunately, in many cases the reset packets are not received in time because the
24
An inline sensor could potentially use this technique, but it is much weaker than other methods that inline sensors can
perform, so in practice session sniping is rarely used on inline sensors.
4-12
attack traffic has to be monitored and analyzed, the attack detected, and the packets sent across
networks to the endpoints. Also, since this technique is only applicable to TCP, it cannot be used
for attacks carried in other types of packets, including UDP and ICMP. Session sniping is not
widely used any more because other, newer prevention capabilities are more effective.
Inline Only
– Performing Inline Firewalling. Most inline IDPS sensors offer firewall capabilities that can be
used to drop or reject suspicious network activity.
– Throttling Bandwidth Usage. If a particular protocol is being used inappropriately, such as for
a DoS attack, malware distribution, or peer-to-peer file sharing, some inline IDPS sensors can
limit the percentage of network bandwidth that the protocol can use. This prevents the activity
from negatively impacting bandwidth usage for other resources.
– Altering Malicious Content. As described in Section 2.2, some inline IDPS sensors can sanitize
part of a packet, which means that malicious content is replaced with benign content and the
sanitized packet sent to its destination. A sensor that acts as a proxy might perform automatic
normalization of all traffic, such as repackaging application payloads in new packets. This has
the effect of sanitizing some attacks involving packet headers and some application headers,
whether or not the IDPS has detected an attack. Some sensors can also strip infected attachments
from e-mails and remove other discrete pieces of malicious content from network traffic.
Both Passive and Inline
– Reconfiguring Other Network Security Devices. Many IDPS sensors can instruct network
security devices such as firewalls, routers, and switches to reconfigure themselves to block
certain types of activity or route it elsewhere. This can be helpful in several situations, such as
keeping an external attacker out of a network and quarantining an internal host that has been
compromised (e.g., moving it to a quarantine VLAN). This prevention technique is useful only
for network traffic that can be differentiated by packet header characteristics typically recognized
by network security devices, such as IP addresses and port numbers.
– Running a Third-Party Program or Script. Some IDPS sensors can run an administrator-
specified script or program when certain malicious activity is detected. This could trigger any
prevention action desired by the administrator, such as reconfiguring other security devices to
block the malicious activity. Third-party programs or scripts are most commonly used when the
IDPS does not support the prevention actions that administrators want to have performed.
Most IDPS sensors allow administrators to specify the prevention capability configuration for each type
of alert. This usually includes enabling or disabling prevention, as well as specifying which prevention
capability should be used. Some IDPS sensors have a learning or simulation mode that suppresses all
prevention actions, and instead indicates when a prevention action would have been performed. This
allows administrators to monitor and fine-tune the prevention capabilities’ configuration before enabling
them, which reduces the risk of inadvertently blocking benign activity.
4.4 Management
Most network-based IDPS products offer similar management capabilities. This section discusses major
aspects of management—implementation, operation, and maintenance—and provides recommendations
for performing them effectively and efficiently.
4-13
Once a network-based IDPS product has been selected, the administrators need to design an architecture,
perform IDPS component testing, secure the IDPS components, and then deploy them. The following
items list additions to the material presented in Section 3.3.1:
Architecture Design. A consideration specific to network-based IDPSs is where the sensors should
be placed on the network, which includes deciding how many sensors are needed, which sensors
should be inline and which should be passive, and how passive sensors should be connected to the
network (e.g., IDS load balancer, network tap, switch spanning port).
Component Testing and Deployment. Implementing a network-based IDPS can necessitate brief
network outages, particularly when deploying inline sensors. However, passive sensor deployment
can also cause outages for several reasons, including installation of network taps and IDS load
balancers, and reconfiguration of switches to activate spanning port functions.
Securing the IDPS Components. Administrators should ensure that for both passive and inline
sensors, IP addresses are not assigned to the network interfaces used to monitor network traffic,
except for network interfaces also used for IDPS management. Operating a sensor without IP
addresses assigned to its monitoring interfaces is known as operating in stealth mode. Stealth mode
improves the security of the IDPS sensors because it prevents other hosts from initiating connections
to them. This conceals the sensors from attackers and thus limits their exposure to attacks. However,
attackers may be able to identify the existence of an IDPS sensor and determine which product is in
use by analyzing the characteristics of its prevention actions. Such analysis might include monitoring
protected networks, and determining which scan patterns trigger particular responses and what values
are set in certain packet header fields.
The operation and maintenance of network-based IDPSs is performed in the same manner as that
documented in the general information provided in Section 3.3.2.
4.5 Summary
A network-based IDPS monitors network traffic for particular network segments or devices and analyzes
network, transport, and application protocols to identify suspicious activity. Network-based IDPS
components are similar to other types of IDPS technologies, except for the sensors. A network-based
IDPS sensor monitors and analyzes network activity on one or more network segments. Sensors are
available in two formats: appliance-based sensors, which are comprised of specialized hardware and
software optimized for IDPS sensor use, and software-only sensors, which can be installed onto hosts that
meet certain specifications.
Organizations should consider using management networks for their network-based IDPS deployments
whenever feasible. If an IDPS is deployed without a separate management network, organizations should
consider whether or not a VLAN is needed to protect the IDPS communications. In addition to choosing
the appropriate network for the components, administrators also need to decide where the IDPS sensors
should be located. Sensors can be deployed in one of two modes: inline sensors are deployed so that the
network traffic they monitor must pass through them, while passive sensors are deployed so that they
monitor copies of the actual network traffic. Generally, organizations should deploy inline sensors if
prevention methods will be used and passive sensors if they will not.
4-14
Network-based IDPSs provide a wide variety of security capabilities. Some products can collect
information on hosts such as which OSs they use and which application versions they use that
communicate over networks. Network-based IDPSs can also perform extensive logging of data related to
detected events; most can also perform packet captures. Network-based IDPSs usually offer extensive
and broad detection capabilities. Most products use a combination of signature-based detection, anomaly-
based detection, and stateful protocol analysis to perform in-depth analysis of common protocols;
organizations should use network-based IDPS products that provide such a combination of detection
features, because the combination increases detection accuracy. Organizations should also use network-
based IDPSs that can compensate for the use of common evasion techniques, which further improves
detection accuracy.
Network-based IDPSs have some significant limitations. They cannot detect attacks within encrypted
network traffic; accordingly, either they should be deployed where they can monitor traffic before
encryption or after decryption, or host-based IDPSs should be used on endpoints to monitor unencrypted
activity. Network-based IDPSs are often unable to perform full analysis under high loads; organizations
using inline sensors should select those that can recognize high load conditions and either pass certain
types of traffic without performing full analysis or drop low-priority traffic to reduce load. Another
limitation of network-based IDPSs is that they are susceptible to various types of attacks, most involving
large volumes of traffic. Organizations should select products that offer features designed to make them
resistant to failure due to attack. Organizations should also ensure that IP addresses are not assigned to
the network interfaces of passive or inline sensors used to monitor network traffic, except for network
interfaces used for both traffic monitoring and IDPS management.
Network-based IDPS sensors offer various prevention capabilities. Many passive sensors can attempt to
end TCP sessions by resetting them, but this technique often does not work in time, and it is not
applicable to non-TCP sessions, such as UDP and ICMP. Inline sensor-specific techniques include
performing inline firewalling, throttling bandwidth usage, and altering malicious content, all of which are
helpful for certain circumstances. Both passive and inline sensors can reconfigure other network security
devices; they can also run third-party programs or scripts to initiate additional prevention actions.
4-15
4-16
5. Wireless IDPS
A wireless IDPS monitors wireless network traffic and analyzes its wireless networking protocols to
identify suspicious activity involving the protocols themselves. This section provides a detailed
discussion of wireless IDPS technologies. First, it contains a brief overview of wireless networking,
which is background material for understanding the rest of the section. Next, it covers the major
components of wireless IDPSs and explains the architectures typically used for deploying the
components. It also examines the security capabilities of the technologies in depth, including the
methodologies they use to identify and stop suspicious activity. The rest of the section discusses the
management capabilities of the technologies, including recommendations for implementation and
operation.
5.1 Wireless Networking Overview
Wireless networking enables devices with wireless capabilities to use computing resources without being
physically connected to a network. The devices simply need to be within a certain distance (known as the
range) of the wireless network infrastructure. A wireless local area network (WLAN) is a group of
wireless networking nodes within a limited geographic area that is capable of exchanging data through
radio communications. WLANs are typically used by devices within a fairly limited range, such as an
office building or corporate campus, and are implemented as extensions to existing wired local area
networks (LAN) to provide enhanced user mobility.
This section provides a brief introduction to wireless networking. Section 5.1.1 provides an overview of
the most commonly used WLAN standards. Section 5.1.2 discusses the fundamental components of
WLANs. Finally, Section 5.1.3 briefly examines the major threats against WLANs. This material is
intended only to provide a high-level overview of wireless networking as background information for the
wireless IDPS material in the rest of the section. 25
5.1.1 WLAN Standards
Most WLANs use the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of WLAN
standards. 26 The most commonly used WLAN radio transmission standards are IEEE 802.11b and IEEE
802.11g, which use the 2.4 gigahertz (GHz) band, and IEEE 802.11a, which uses the 5 GHz band. IEEE
802.11a, b, and g include security features known collectively as Wired Equivalent Privacy (WEP).
Unfortunately, WEP has several well-documented security problems. To overcome these, IEEE 802.11i
was created; it specifies security components that work in conjunction with IEEE 802.11a, b, and g.
Another set of WLAN standards has been created by a non-profit industry consortium of WLAN
equipment and software vendors called the Wi-Fi Alliance. 27 While IEEE was working on finalizing the
802.11i standard, the Alliance created an interim solution called Wi-Fi Protected Access (WPA).
Published in October 2002, WPA is essentially a subset of the draft IEEE 802.11i requirements available
at that time. WPA provides stronger security for WLAN communications than WEP. In conjunction
25
This publication does not address IDPS technologies for other forms of wireless networking, such as Bluetooth. Bluetooth
IDPS products have just started to become available, and as of late 2006 they offer few capabilities (device detection,
service enumeration, limited vulnerability scanning). It also does not address technologies based on the IEEE 802.11n
WLAN standard, which as of late 2006 has not been finalized. It is expected that the recommendations in this section
should generally be applicable to wireless IDPS technologies for IEEE 802.11n-based WLANs.
26
For more information on the IEEE 802.11 standards and other aspects of wireless network security, see NIST SP 800-97,
Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i, and NIST SP 800-48, Wireless Network
Security: 802.11, Bluetooth and Handheld Devices (http://csrc.nist.gov/publications/nistpubs/index.html).
27
For more information on the Wi-Fi Alliance, visit their Web site at http://www.wi-fi.org/.
5-1
with the ratification of the IEEE 802.11i amendment, the Wi-Fi Alliance introduced WPA2, its term for
interoperable equipment that is capable of supporting IEEE 802.11i requirements. WPA2 offers stronger
security controls than either WPA or WEP.
5.1.2 WLAN Components
IEEE 802.11 WLANs have two fundamental architectural components:
Station (STA). A STA is a wireless endpoint device. Typical examples of STAs are laptop
computers, personal digital assistants (PDA), mobile phones, and other consumer electronic devices
with IEEE 802.11 capabilities.
Access Point (AP). 28 An AP logically connects STAs with a distribution system (DS), which is
typically an organization’s wired infrastructure. The DS is the means by which STAs can
communicate with the organization’s wired LANs and external networks such as the Internet. Figure
5-1 shows an example of how APs, STAs, and DSs are related.
Figure 5-1. Wireless LAN Architecture Example
Some WLANs also use wireless switches. A wireless switch is a device that acts as an intermediary
between APs and the DS. The purpose of the switch is to assist administrators in managing the WLAN
infrastructure. In WLANs without wireless switches, the APs connect directly to the DS.
The IEEE 802.11 standard also defines the following two WLAN architectures:
Ad Hoc Mode. The ad hoc mode does not use APs. Ad hoc mode, also known as peer-to-peer mode,
involves two or more STAs communicating directly with one another.
Infrastructure Mode. In infrastructure mode, an AP connects wireless STAs to a DS, typically a
wired network.
28
Technically, APs are also STAs. Some literature distinguishes between AP STAs and non-AP STAs. In this document, the
term STA refers to non-AP STAs only.
5-2
Each AP and STA on a WLAN can be identified by its media access control (MAC) address, which is a
unique 48-bit value that is assigned to a wireless network interface card. Part of the MAC address can be
used to identify the card’s vendor; the rest of the address acts as a serial number from the vendor. Ideally,
MAC addresses could be used to uniquely identify every wireless device; however, it is relatively trivial
to spoof a MAC address.
Nearly all organization WLANs use infrastructure mode. Each AP in a WLAN has a name assigned to it
called a service set identifier (SSID). The SSID allows STAs to distinguish one WLAN from another.
SSIDs are broadcast in plaintext by APs, so any listening wireless device can easily learn the SSID for
each WLAN in its range. 29 Organizations may have no WLANs, one WLAN, or multiple WLANs. Also,
many organizations have facilities that are within range of other organizations’ WLANs.
5.1.3 Threats against WLANs
Although wireless and wired networks face the same general types of threats, the relative risk of some
threats varies significantly. For example, wireless attacks typically require the attacker or a device placed
by the attacker to be within close physical proximity to the wireless network; many attacks on wired
networks can be performed remotely from any location. However, many WLANs are configured so that
they do not require any authentication or require only weak forms of authentication; this makes it much
easier for local attackers to perform several types of attacks, such as a man-in-the-middle attack.
Most WLAN threats involve an attacker with access to the radio link between a STA and an AP (or
between two STAs, in ad hoc mode). Many attacks rely on an attacker’s ability to intercept network
communications or inject additional messages into them. This highlights the most significant difference
between protecting wireless and wired LANs: the relative ease of accessing and altering network
communications. In a wired LAN, an attacker would have to gain physical access to the LAN or remotely
compromise systems on the LAN; in a wireless LAN, an attacker simply needs to be within range of the
WLAN infrastructure. 30
This section describes the major components of typical wireless IDPS solutions and illustrates the most
common network architectures for these components. It also provides recommendations for the
placement of certain components.
The typical components in a wireless IDPS are the same as a network-based IDPS: consoles, database
servers (optional), management servers, and sensors. All of the components except sensors have
essentially the same functionality for both types of IDPSs. Wireless sensors perform the same basic role
as network-based IDPS sensors, but they function very differently because of the complexities of
monitoring wireless communications.
Unlike a network-based IDPS, which can see all packets on the networks it monitors, a wireless IDPS
works by sampling traffic. There are two frequency bands to monitor (2.4 GHz and 5 GHz), and each
29
Two WLANs within range of each other could have the same SSID. In such a case, the WLANs could be distinguished
through the MAC addresses of their APs.
30
More details on threats against WLANs are available from NIST SP 800-97, Establishing Wireless Robust Security
Networks: A Guide to IEEE 802.11i and NIST SP 800-48, Wireless Network Security: 802.11, Bluetooth and Handheld
Devices (http://csrc.nist.gov/publications/nistpubs/index.html).
5-3
band is separated into channels. 31 It is not currently possible for a sensor to monitor all traffic on a band
simultaneously; a sensor has to monitor a single channel at a time. When the sensor is ready to monitor a
different channel, the sensor must shut its radio off, change the channel, then turn its radio on. The longer
a single channel is monitored, the more likely it is that the sensor will miss malicious activity occurring
on other channels. To avoid this, sensors typically change channels frequently, which is known as
channel scanning, so that they can monitor each channel a few times per second. To reduce or eliminate
channel scanning, specialized sensors are available that use several radios and high-power antennas, with
each radio/antenna pair monitoring a different channel. Because of their higher sensitivities, the high-
power antennas also have a larger monitoring range than regular antennas. Some implementations
coordinate scanning patterns among sensors with overlapping ranges so that each sensor needs to monitor
fewer channels. 32
Wireless sensors are available in multiple forms:
Dedicated. A dedicated sensor is a device that performs wireless IDPS functions but does not pass
network traffic from source to destination. Dedicated sensors are often completely passive,
functioning in a radio frequency (RF) monitoring mode to sniff wireless network traffic. Some
dedicated sensors perform analysis of the traffic they monitor, while other sensors forward the
network traffic to a management server for analysis. The sensor is typically connected to the wired
network (e.g., Ethernet cable between the sensor and a switch). Dedicated sensors are usually
designed for one of two deployment types:
– Fixed—the sensor is deployed to a particular location. Such sensors are typically dependent on
the organization’s infrastructure (e.g., power, wired network). 33 Fixed sensors are usually
appliance-based.
– Mobile—the sensor is designed to be used while in motion. For example, a security

administrator could use a mobile sensor while walking through an organization’s buildings and
campus to find rogue APs. Mobile sensors are either appliance-based or software-based (e.g.,
software installed onto a laptop with a wireless NIC capable of doing RF monitoring). 34
Bundled with an AP. Several vendors have added IDPS capabilities to APs. A bundled AP
typically provides a less rigorous detection capability than a dedicated sensor because the AP needs to
divide its time between providing network access and monitoring multiple channels or bands for
31
IEEE 802.11b and g support 14 channels: 11 authorized for U.S. use and 3 authorized for international use. IEEE 802.11a
supports 12 channels authorized for U.S. use and 4 channels authorized for international use. Some attackers use unusual
channels or non-IEEE 802.11 frequency bands, such as 900 MHz or 4.9 GHz, because their activity is less likely to be
detected than the use of the typical WLAN frequencies and channels. For example, an attacker who can gain unauthorized
physical access to a wired network could install a wireless device that can subsequently transmit information from the
organization to the attacker over an atypical frequency. Spectrum analyzer products can monitor activity on different
frequency bands to identify attacks and to find benign sources of interference, such as cordless phones and microwaves. As
of mid-2006, few IDPS products offer any spectrum analysis capabilities. However, several companies offer mobile
handheld spectrum analyzers that can monitor common bands. A detailed discussion of them is outside the scope of this
document.
32
Organizations need to determine which channels should be monitored. As previously explained, attackers often use unusual
channels, such as IEEE 802.11a, b, or g channels that are not authorized for U.S. use. Although monitoring these channels
can detect such activity, it could reduce the percentage of time monitoring the channels that are used both by the
organization’s WLANs and also typical rogue WLANs, such as unauthorized access points. Organizations should consider
the likelihood of the possible threats and choose a channel scanning plan that best addresses the threats.
33
Some sensors can use the IEEE 802.3af protocol, also known as Power over Ethernet (PoE). This allows a sensor to receive
its electrical power through the same Ethernet cable that connects it to the wired network. PoE is implemented in some
dedicated sensors and access points. More information on PoE is available at http://www.ieee802.org/3/af/index.html
34
Mobile sensors may be part of an enterprise wireless IDPS solution or may be standalone devices, managed and monitored
directly by an administrator.
5-4
malicious activity. If the IDPS only needs to monitor a single band and channel, a bundled solution
might provide reasonable security and network availability. If the IDPS has to monitor multiple
bands or channels, then the sensor needs to perform channel scanning, which will disrupt the AP
functions of the sensor by making it temporarily unavailable on its primary band and channel.
Bundled with a Wireless Switch. Wireless switches are intended to assist administrators with
managing and monitoring wireless devices; some of these switches also offer some wireless IDPS
capabilities as a secondary function. Wireless switches typically do not offer detection capabilities as
strong as bundled APs or dedicated sensors.
Because dedicated sensors can focus on detection and do not need to carry wireless traffic, they typically
offer stronger detection capabilities than wireless sensors bundled with APs or wireless switches.
However, dedicated sensors are often more expensive to acquire, install, and maintain than bundled
sensors because bundled sensors can be installed on existing hardware, whereas dedicated sensors involve
additional hardware and software. Organizations should consider both security and cost when selecting
wireless IDPS sensors.
Some vendors also have host-based wireless IDPS sensor software that can be installed on STAs, such as
laptops. The sensor software detects attacks within range of the STAs, as well as misconfigurations of the
STAs, and reports this information to management servers. The sensor software may also be able to
enforce security policies on the STAs, such as limiting access to wireless interfaces. More information on
host-based IDPS products is presented in Section 7.
Wireless IDPS components are typically connected to each other through a wired network, as shown in
Figure 5-2. As with a network-based IDPS, a separate management network or the organization’s
standard networks can be used for wireless IDPS component communications. Because there should
already be a strictly controlled separation between the wireless and wired networks, using either a
management network or a standard network should be acceptable for wireless IDPS components. Also,
some wireless IDPS sensors (particularly mobile ones) are used standalone and do not need wired
network connectivity.
5-5
Figure 5-2. Wireless IDPS Architecture
5.2.3 Sensor Locations
Choosing sensor locations for a wireless IDPS deployment is a fundamentally different problem than
choosing locations for any other type of IDPS sensor. If the organization uses WLANs, wireless sensors
should be deployed so that they monitor the RF range of the organization’s WLANs (both APs and
STAs), which often includes mobile components such as laptops and PDAs. Many organizations also
want to deploy sensors to monitor physical regions of their facilities where there should be no WLAN
activity, as well as channels and bands that the organization’s WLANs should not use, as a way of
detecting rogue APs and ad hoc WLANs. Other considerations for selecting wireless sensor locations
include the following:
Physical Security. Sensors are often deployed into open locations (e.g., hallway ceilings, conference
rooms) because their range is much greater there than in closed locations (e.g., wiring closets).
Sensors are sometimes deployed outdoors as well. 35 Generally, sensors in open interior locations and
external locations are more susceptible to physical threats than other sensors. If the physical threats
are significant, organizations might need to select sensors with anti-tamper features or deploy sensors
where they are less likely to be physically accessed (e.g., within view of a security camera).
35
Special sensors are available for outdoor use that offer better resistance to environmental threats than regular sensors.
5-6
Sensor Range. The actual range of a sensor varies based on the surrounding facilities (e.g., walls,
doors). Some wireless IDPS vendors offer modeling software that can analyze building floor plans
and the attenuation characteristics of walls, doors, and other facility components to determine
effective locations for sensors. Sensor range can also vary based on the location of people within the
facility and other changing characteristics, so sensors should be deployed so that their ranges have
some overlap (e.g., at least 20%).
Wired Network Connections. The sensors typically need to be connected to the wired network. If
there is a need to deploy sensors in an area where there is no wired network, then it might be
necessary to extend the wired network into that area. This is generally a concern only if the
organization wants to monitor portions of their facilities that are outside the range of the WLAN.
Cost. Ideally, an organization could deploy sensors throughout its facilities to perform full wireless
monitoring. However, the number of sensors needed to do so can be quite large, especially in wide-
open campus environments. Organizations should compare WLAN threats to the cost of sensor
purchases, deployment, and maintenance, and develop a solution that creates an acceptable level of
risk. For example, an organization might decide to deploy fixed sensors throughout the range of the
organization’s WLANs, and to do periodic checks of other areas using mobile sensors.
AP and Wireless Switch Locations. If a bundled solution (e.g., wireless IDPS software on an AP)
would meet the organization’s other requirements, then the locations of APs and wireless switches are
particularly important because the wireless IDPS software could potentially be deployed onto those
devices.
Wireless IDPSs provide several types of security capabilities. Because wireless IDPS is a relatively new
form of IDPS, capabilities currently vary widely among products; over time, product capabilities should
become more consistent. Sections 5.3.1 through 5.3.4 describe common security capabilities, divided into
four categories: information gathering, logging, detection, and prevention, respectively.
Most wireless IDPSs can collect information on wireless devices. Examples of these information
gathering capabilities are as follows:
Identifying WLAN Devices. Most IDPS sensors can create and maintain an inventory of observed
WLAN devices, including APs, WLAN clients, and ad hoc (peer-to-peer) clients. The inventory is
usually based on SSIDs and the MAC addresses of the devices’ wireless network cards; the first
portion of each MAC address identifies the vendor of the card. 36 Some sensors can also use
fingerprinting techniques on observed traffic to verify the vendor, instead of relying on the MAC
information (which could be spoofed). The inventory can be used as a profile to identify new WLAN
devices and the removal of existing devices.
Identifying WLANs. Most IDPS sensors keep track of observed WLANs, identifying them by their
SSIDs. Administrators can then tag each entry as being an authorized WLAN, a benign neighboring
WLAN (e.g., another organization in the same building), or a rogue WLAN. This information can be
used to identify new WLANs, as well as to prioritize responses to identified events.
36
Some STAs transmit multiple SSIDs while trying to identify previously accessed WLANs.
5-7
Wireless IDPSs typically perform extensive logging of data related to detected events. This data can be
used to confirm the validity of alerts, to investigate incidents, and to correlate events between the IDPS
and other logging sources. Data fields commonly logged by wireless IDPSs include the following:

Event or alert type 37
Priority or severity rating
Source MAC address (the vendor is often identified from the address)
Channel number
ID of the sensor that observed the event
Wireless IDPSs can detect attacks, misconfigurations, and policy violations at the WLAN protocol level,
primarily examining IEEE 802.11a, b, g, and i protocol communication. Wireless IDPSs do not examine
communications at higher levels (e.g., IP addresses, application payloads). Some products perform only
simple signature-based detection, while others use a combination of signature-based detection, anomaly-
based detection, and stateful protocol analysis techniques; organizations should use wireless IDPS
products that use such a combination of techniques, to achieve broader and more accurate detection. This
section discusses the following aspects of detection capabilities:

Detection accuracy
The types of events most commonly detected by wireless IDPS sensors include the following:
Unauthorized WLANs and WLAN devices. Through their information gathering capabilities, most
wireless IDPS sensors can detect rogue APs, unauthorized STAs, and unauthorized WLANs (both
infrastructure mode and ad hoc mode).
Poorly secured WLAN devices. Most wireless IDPS sensors can identify APs and STAs that are not
using the proper security controls. This includes detecting misconfigurations and the use of weak
WLAN protocols and protocol implementations. This is accomplished by identifying deviations from
organization-specific policies for settings such as encryption, authentication, data rates, SSID names,
and channels. For example, a sensor could detect that a STA is using WEP instead of WPA2 or IEEE
37
Some products may use identifiers from the Wireless Vulnerabilities & Exploits (WVE) database, which contains
information on wireless protocol and product vulnerabilities and known exploits for these vulnerabilities. The WVE
database is located at http://www.wve.org/.
5-8
802.11i. The majority of types of events that can be detected by wireless IDPSs fall into this
detection category.
Unusual usage patterns. Some sensors can use anomaly-based detection methods to detect unusual
WLAN usage patterns. For example, if many more STAs than usual are using a particular AP, or
there is a much higher than usual amount of network traffic between a STA and AP, one of the
devices might have been compromised, or unauthorized parties might be using the WLAN. Many
sensors can identify failed attempts to join the WLAN, such as alerting on several failed attempts in a
short period of time, which could indicate an attempt to gain unauthorized access to the WLAN.
Some sensors can also alert if any WLAN activity is detected during off-hours periods.
The use of wireless network scanners (e.g., war driving tools). Such scanners are used to identify
unsecured or weakly secured WLANs. Wireless IDPS sensors can detect only the use of active
scanners—scanners that generate wireless network traffic. They cannot detect the use of passive
sensors that simply monitor and analyze observed traffic. 38
Denial of service (DoS) attacks and conditions (e.g., network interference). DoS attacks include
logical attacks such as flooding, which involves sending large numbers of messages to an AP at a
high rate, and physical attacks such as jamming, which involves emitting electromagnetic energy on
the WLAN’s frequencies to make the frequencies unusable by the WLAN. DoS attacks can often be
detected through stateful protocol analysis and anomaly detection methods, which can determine if
the observed activity is consistent with the expected activity. Many denial of service attacks are
detected by counting events during periods of time and alerting when threshold values are exceeded.
For example, a large number of events involving the termination of wireless network sessions can
indicate a DoS attack.
Impersonation and man-in-the-middle attacks. Some wireless IDPS sensors can detect when a
device is attempting to spoof the identity of another device. This is done by identifying differences in
the characteristics of the activity, such as certain values in frames.
Most wireless IDPS sensors can identify the physical location of a detected threat by using
triangulation—estimating the threat’s approximate distance from multiple sensors by the strength of the
threat’s signal received by each sensor, then calculating the physical location at which the threat would be
the estimated distance from each sensor. This allows an organization to send physical security staff to the
location to address the threat. Wireless IDPS products that can use building floor plans can also
determine if the threat is inside or outside a building, or if it is in a public area or secured area. This
information is helpful not only in finding and stopping the threat, but also in prioritizing the response to
the threat. Wireless IDPS sensors can set the priority of alerts based in part on the location of each threat.
Handheld IDPS sensors can also be used to pinpoint a threat’s location, particularly if fixed sensors do
not offer triangulation capabilities or if the threat is moving.
Compared to other forms of IDPS, wireless IDPS is generally more accurate; this is largely due to its
limited scope (analyzing wireless networking protocols). False positives are most likely to be caused by
anomaly-based detection methods, especially if threshold values are not properly maintained. Although
many alerts might occur based on benign activity, such as another organization’s WLAN being within
range of the organization’s WLANs, these alerts are not truly false positives because they are accurately
detecting an unknown WLAN within the organization’s facilities.
38
In many cases, the most effective way to identify the use of passive scanners is through physical security controls, such as
seeing individuals with computers and antennas in proximity to the organization’s facilities.
5-9
Wireless IDPS technologies usually require some tuning and customization to improve their detection
accuracy. The main effort is in specifying which WLANs, APs, and STAs are authorized, and in entering
the policy characteristics into the wireless IDPS software. Because wireless IDPSs are only examining
wireless network protocols, not higher level protocols (e.g., application), there are generally not a large
number of alert types, and consequently not many customizations or tunings available. Some wireless
IDPSs offer industry-specific templates that can be helpful in establishing base policies.
Wireless IDPSs offer some customization features. Most have thresholds that can be used for anomaly-
based detection. Blacklists and whitelists are used to hold lists of known malicious and benign WLAN
devices, respectively. The lists can also be used to record authorized or unauthorized WLAN NIC
vendors; alerts can be generated when any NICs not on the authorized list are used for APs or STAs.
Individual alerts can be customized, just as they can for network-based IDPSs. Code editing is not
available for most products, although some vendors allow administrators to enter complex logical
expressions to tune certain detection capabilities.
Besides reviewing tuning and customizations periodically to ensure that they are still accurate,
administrators should also ensure that changes to building plans are incorporated occasionally. This is
needed for accurate identification of the physical location of threats and accurate planning of sensor
deployments.
Although wireless IDPSs offer robust detection capabilities, they do have some significant limitations.
Three of the most important are being unable to detect certain wireless protocol attacks, being susceptible
to evasion techniques, and being unable to withstand attacks against the IDPSs themselves. These
limitations are discussed in detail below.
Wireless IDPSs cannot detect certain types of attacks against wireless networks. An attacker can
passively monitor wireless traffic, which is not detectable by wireless IDPSs. If weak security methods
are being used (e.g., WEP), the attacker can then perform offline processing of that collected traffic to
find the encryption key used to provide security for the wireless traffic. With this key, the attacker can
decrypt the traffic that was already collected, as well as any other traffic that is collected from the same
WLAN. Wireless IDPSs cannot fully compensate for the use of insecure wireless networking protocols.
Another problem with some wireless IDPS sensors is the use of evasion techniques. Attackers can
identify the wireless IDPS product in use by various means, including a physical survey of the area in
which the sensors are deployed, and the use of fingerprinting techniques that can identify the product in
use by the characteristics of its prevention actions (see Section 5.3.4 for information on prevention).
Once an attacker has identified the product, evasion techniques can be used that take advantage of the
product’s channel scanning scheme. One example is performing attacks in very short bursts on channels
that are not currently being monitored. An attacker could also launch attacks on two channels at the same
time. If the wireless IDPS sensor detects the first attack, it cannot detect the second attack unless it scans
away from the channel of the first attack. Another drawback of channel scanning is the impact it could
have on network forensics. Since each sensor sees only a fraction of the activity on each channel, the
forensic data is quite incomplete, making it considerably more difficult to analyze.
Wireless IDPS sensors are also susceptible to attack. The same denial of service attacks (both logical and
physical) that attempt to disrupt WLANs can also disrupt sensor functions. Sensors are also often
particularly susceptible to physical attack because they are usually located in hallways, conference rooms,
5-10
and other open areas. Some sensors have anti-tamper features, such as being designed to look like fire
alarms or regular APs, that can reduce the likelihood that they will be attacked. All sensors are
susceptible to physical attacks such as jamming that disrupt RF; there is no defense against such attacks
other than to establish a physical perimeter around the facility so that attackers cannot get close enough to
the WLAN to jam it.
Wireless IDPS sensors offer two types of intrusion prevention capabilities:
Wireless. Some sensors can terminate connections between a rogue or misconfigured STA and an
authorized AP or between an authorized STA and a rogue or misconfigured AP through the air. This
is typically done by sending messages to the endpoints, telling them to deassociate the current
session. The sensor then refuses to permit a new connection to be established.
Wired. Some sensors can instruct a switch on the wired network to block network activity involving
a particular STA or AP based on the device’s MAC address or switch port. For example, if a STA is
sending attacks to a server on the wired network, a sensor could direct a wired switch to block all
activity to and from the STA. This technique is only effective for blocking the malicious STA or
AP’s wired network communications. It will not stop a STA or AP from continuing to perform
malicious actions through wireless protocols.
Most IDPS sensors allow administrators to specify the prevention capability configuration for each type
of alert. This usually includes enabling or disabling prevention, as well as specifying which type of
prevention capability should be used. Some IDPS sensors have a learning or simulation mode that
suppresses all prevention actions, and instead indicates when a prevention action would have been
performed. This allows administrators to monitor and fine-tune the prevention capabilities’ configuration
before enabling prevention, which reduces the risk of performing prevention actions on benign activity.
An important consideration is the effect that prevention actions can have on sensor monitoring. For
example, if a sensor is transmitting signals to terminate connections, it may not be able to perform
channel scanning to monitor other communications until it has completed the prevention action. To
mitigate this, some sensors have two radios—one for monitoring and detection, and another for
performing prevention actions. When selecting sensors, organizations should consider what prevention
actions may need to be performed and how the sensor’s detection capabilities could be affected by
performing prevention actions.
5.4 Management
Most wireless IDPS products offer similar management capabilities. This section discusses major aspects
of management—implementation, operation, and maintenance—and provides recommendations for
performing them effectively and efficiently.
Once a wireless IDPS product has been selected, the administrators need to design an architecture,
perform IDPS component testing, secure the IDPS components, and then deploy them. The only addition
to the material presented in Section 3.3.1 involves component testing and deployment. Implementing a
wireless IDPS can necessitate brief wireless network outages if existing APs or wireless switches need to
be upgraded or have IDPS software installed. Generally, the deployment of dedicated sensors causes no
network outages.
5-11
The operation and maintenance of a wireless IDPS solution is nearly identical to that of a network-based
IDPS solution. Wireless IDPS consoles offer similar management, monitoring, analysis, and reporting
capabilities. One significant difference is that wireless IDPS consoles can display the physical location of
threats. A minor difference is that because wireless IDPS sensors detect a relatively small variety of
events, compared to other types of IDPSs, they tend to have signature updates less frequently.
5.5 Summary
A wireless IDPS monitors wireless network traffic and analyzes its wireless networking protocols to
identify suspicious activity. The typical components in a wireless IDPS are the same as a network-based
IDPS: consoles, database servers (optional), management servers, and sensors. However, unlike a
network-based IDPS sensor, which can see all packets on the networks it monitors, a wireless IDPS
sensor works by sampling traffic because it can only monitor a single channel at a time. The longer a
single channel is monitored, the more likely it is that the sensor will miss malicious activity occurring on
other channels. To avoid this, sensors typically change channels frequently, so that they can monitor each
channel a few times per second.
Wireless sensors are available in multiple forms. A dedicated sensor is a fixed or mobile device that
performs wireless IDPS functions but does not pass network traffic from source to destination. The other
wireless sensor forms are bundled with access points (AP) or wireless switches. Because dedicated
sensors can focus on detection and do not need to carry wireless traffic, they typically offer stronger
detection capabilities than wireless sensors bundled with access points or wireless switches. However,
dedicated sensors are often more expensive to acquire, install, and maintain than bundled sensors because
bundled sensors can be installed on existing hardware, whereas dedicated sensors involve additional
hardware and software. Organizations should consider both security and cost when selecting wireless
IDPS sensors.
Wireless IDPS components are typically connected to each other through a wired network. Because there
should already be a strictly controlled separation between the wireless and wired networks, using either a
management network or a standard network should be acceptable for wireless IDPS components.
Choosing sensor locations for a wireless IDPS deployment is a fundamentally different problem than
choosing locations for any other type of IDPS sensor. If the organization uses wireless local area
networks (WLAN), wireless sensors should be deployed so that they monitor the range of the WLANs.
Many organizations also want to deploy sensors to monitor parts of their facilities where there should be
no WLAN activity, as well as channels and bands that the organization’s WLANs should not use. Other
considerations for selecting sensor locations include physical security, sensor range, wired network
connection availability, cost, and AP and wireless switch locations.
Wireless IDPSs provide several types of security capabilities. Most can collect information on observed
wireless devices and WLANs and perform extensive logging of event data. Wireless IDPSs can detect
attacks, misconfigurations, and policy violations at the WLAN protocol level. Organizations should use
wireless IDPS products that use a combination of detection techniques to achieve broader and more
accurate detection. Examples of events detected by wireless IDPSs are unauthorized WLANs and WLAN
devices, poorly secured WLAN devices, unusual usage patterns, the use of active wireless network
scanners, denial of service attacks, and impersonation and man-in-the-middle attacks. Most wireless
IDPS sensors can also identify the physical location of a detected threat by using triangulation.
Compared to other forms of IDPS, wireless IDPS is generally more accurate; this is largely due to its
limited scope (analyzing wireless networking protocols). Wireless IDPSs usually require some tuning
5-12
and customization to improve their detection accuracy. The main effort is in specifying which WLANs,
APs, and STAs are authorized, and in entering the policy characteristics into the wireless IDPS software.
administrators should also ensure that changes to building plans are incorporated occasionally. This is
needed for accurate identification of the physical location of threats and accurate planning of sensor
deployments.
Although wireless IDPSs offer robust detection capabilities, they do have some significant limitations.
Wireless IDPSs cannot detect certain types of attacks against wireless networks, such as attacks involving
passive monitoring and offline processing of wireless traffic. Wireless IDPSs are also susceptible to
evasion techniques, especially those involving knowledge of a product’s channel scanning scheme.
Channel scanning can also impact network forensics because each sensor sees only a fraction of the
activity on each channel. Wireless IDPS sensors are also susceptible to denial of service attacks and
physical attacks.
Wireless IDPS sensors can offer intrusion prevention capabilities. Some sensors can instruct endpoints to
terminate a session and prevent a new session from being established. Some sensors can instruct a switch
on the wired network to block network activity for a particular wireless endpoint; however, this method
can only block wired network communications and will not stop an endpoint from continuing to perform
malicious actions through wireless protocols. Most IDPS sensors allow administrators to specify the
prevention capability configuration for each type of alert. Prevention actions can affect sensor
monitoring; for example, if a sensor is transmitting signals to terminate connections, it may not be able to
perform channel scanning to monitor other communications until it has completed the prevention action.
To mitigate this, some sensors have two radios—one for monitoring and detection, and another for
performing prevention actions. When selecting sensors, organizations should consider what prevention
actions may need to be performed and how the sensor’s detection capabilities could be affected by
performing prevention actions.
5-13
5-14
6. Network Behavior Analysis (NBA) System
A network behavior analysis (NBA) system examines network traffic or statistics on network traffic to
identify unusual traffic flows, such as distributed denial of service (DDoS) attacks, certain forms of
malware (e.g., worms, backdoors), and policy violations (e.g., a client system providing network services
to other systems). 39 This section provides a detailed discussion of NBA technologies. First, it covers the
major components of the NBA technologies and explains the architectures typically used for deploying
the components. It also examines the security capabilities of the technologies in depth, including the
methodologies they use to identify suspicious activity. The rest of the section discusses the management
capabilities of the technologies, including recommendations for implementation and operation.
This section describes the major components of typical NBA solutions and illustrates the most common
network architectures for these components. It also provides recommendations for the placement of
certain components.
NBA solutions usually have sensors and consoles, with some products also offering management servers
(which are sometimes called analyzers). NBA sensors are usually available only as appliances. Some
sensors are similar to network-based IDPS sensors in that they sniff packets to monitor network activity
on one or a few network segments. Other NBA sensors do not monitor the networks directly, but instead
rely on network flow information provided by routers and other networking devices. Flow refers to a
particular communication session occurring between hosts. There are many standards for flow data
formats, including NetFlow 40 and sFlow. 41 Typical flow data particularly relevant to intrusion detection
and prevention includes the following:

Source and destination TCP or UDP ports or ICMP types and codes
Number of packets and number of bytes transmitted in the session
Timestamps for the start and end of the session.
As with a network-based IDPS, a separate management network or the organization’s standard networks
can be used for NBA component communications. If sensors that collect network flow data from other
devices are used, the entire NBA solution can be logically separated from the standard networks. Figure
6-1 shows an example of an NBA network architecture.
39
Some vendors refer to NBA technology as network behavior anomaly detection (NBAD) software, network behavior
analysis and response software, or network anomaly detection software.
40
More information on NetFlow is available from RFC 3954, Cisco Systems NetFlow Services Export Version 9
(http://www.ietf.org/rfc/rfc3954.txt) and from the Cisco Web site at
http://www.cisco.com/en/US/products/ps6645/products_ios_protocol_option_home.html.
41
More information on sFlow is available at http://www.sflow.org/.
6-1
Figure 6-1. NBA Sensor Architecture Example
6.1.3 Sensor Locations
In addition to choosing the appropriate network for the components, administrators also need to decide
where the sensors should be located. Most NBA sensors can be deployed in passive mode only, using the
same connection methods (e.g., network tap, switch spanning port) as network-based IDPSs. Passive
sensors that are performing direct network monitoring should be placed so that they can monitor key
network locations, such as the divisions between networks, and key network segments, such as
demilitarized zone (DMZ) subnets. Inline sensors are typically intended for network perimeter use, so
they would be deployed in close proximity to the perimeter firewalls, often between the firewall and the
Internet border router to limit incoming attacks that could overwhelm the firewall.
6-2
NBA products provide a variety of security capabilities. Sections 6.2.1 through 6.2.4 describe common
security capabilities, divided into four categories: information gathering, logging, detection, and
prevention, respectively. Some NBA products also provide security information and event management
(SIEM) capabilities; see Section 8.2.2 for information on SIEM.
NBA technologies offer extensive information gathering capabilities, because knowledge of the
characteristics of the organization’s hosts is needed for most of the NBA product’s detection techniques.
NBA sensors can automatically create and maintain lists of hosts communicating on the organization’s
monitored networks. They can monitor port usage, perform passive fingerprinting, and use other
techniques to gather detailed information on the hosts. (As described in Section 6.2.3.1, most products
also allow administrators to specify detailed firewall ruleset-like policies for host-to-host
communications, including permitted or forbidden port numbers.) Information typically collected for
each host includes the following:
IP address
Operating system
What services it is providing, including the IP protocols and TCP and UDP ports it uses to do so
Other hosts with which it communicates, and what services it uses and which IP protocols and TCP or
UDP ports it contacts on each host.
NBA sensors constantly monitor network activity for changes to this information. Additional information
on each host’s flows is also collected on an ongoing basis; this is discussed in Section 6.2.3.
NBA technologies typically perform extensive logging of data related to detected events. This data can
be used to confirm the validity of alerts, to investigate incidents, and to correlate events between the NBA
solution and other logging sources. Data fields commonly logged by NBA software include the
following:

Event or alert type
Network, transport, and application layer protocols
Source and destination TCP or UDP ports, or ICMP types and codes
Additional packet header fields (e.g., IP time-to-live [TTL])
Number of bytes and packets sent by the source and destination hosts for the connection
6-3
Some NBA sensors that directly monitor network traffic are able to log limited payload information from
packets, such as authenticated user identifiers. This allows actions to be traced to specific user accounts.
NBA technologies typically have the capability to detect several types of malicious activity. Most
products use primarily anomaly-based detection, along with some stateful protocol analysis techniques, to
analyze network flows. Most NBA technologies offer no signature-based detection capability, other than
allowing administrators to manually set up custom filters that are essentially signatures to detect or stop
specific threats. This section discusses the following aspects of NBA software detection capabilities:

Detection accuracy
The types of events most commonly detected by NBA sensors include the following:
Denial of service (DoS) attacks (including distributed denial of service [DDoS] attacks). These
attacks typically involve significantly increased bandwidth usage or a much larger number of packets
or connections to or from a particular host than usual. By monitoring these characteristics, anomaly
detection methods can determine if the observed activity is significantly different than the expected
activity. Some NBA sensors are aware of the characteristics of common DoS tools and methods,
which can help them to recognize the threats more quickly and prioritize them more accurately.
Scanning. Scanning can be detected by atypical flow patterns at the application layer (e.g., banner
grabbing), transport layer (e.g., TCP and UDP port scanning), and network layer (e.g., ICMP
scanning).
Worms. Worms spreading among hosts can be detected in more than one way. Some worms
propagate quickly and use large amounts of bandwidth. Worms can also be detected because they can
cause hosts to communicate with each other that typically do not, and they can also cause hosts to use
ports that they normally do not use. Many worms also perform scanning; this can be detected as
previously explained.
Unexpected application services (e.g., tunneled protocols, backdoors, use of forbidden application
protocols). These are usually detected through stateful protocol analysis methods, which can
determine if the activity within a connection is consistent with the expected application protocol.
Policy violations. Most NBA sensors allow administrators to specify detailed policies, such as which
hosts or groups of hosts a particular system may or may not contact, and what types of activity are
permissible only during certain hours or days of the week. Most sensors also detect many possible
policy violations automatically, such as detecting new hosts or new services running on hosts, which
could be unauthorized.
Most NBA sensors can reconstruct a series of observed events to determine the origin of a threat. For
example, if worms infect a network, NBA sensors can analyze the worm’s flows and find the host on the
organization’s network that first transmitted the worm to other hosts.
6-4
Because NBA sensors work primarily by detecting significant deviations from normal behavior, they are
most accurate at detecting attacks that generate large amounts of network activity in a short period of time
(e.g., DDoS attacks) and attacks that have unusual flow patterns (e.g., worms spreading among hosts).
NBA sensors are less accurate at detecting small-scale attacks, particularly if they are conducted slowly
and if they do not violate the administrator-set policies (e.g., the attack uses common ports and protocols).
Detection accuracy also varies over time. Because NBA technologies use primarily anomaly-based
detection methods, they cannot detect many attacks until they reach a point where their activity is
significantly different from what is expected. If a DoS attack starts slowly and increases in volume over
time, it is likely to be detected by NBA sensors, but the point during the attack at which the NBA
software detects it may vary considerably among NBA products. By configuring sensors to be more
sensitive to anomalous activity, alerts will be generated more quickly when attacks occur, but more false
positives are also likely to be triggered. Conversely, if sensors are configured to be less sensitive to
anomalous activity, there will be fewer false positives, but alerts will be generated more slowly, allowing
attacks to occur for longer periods of time.
False positives can also be caused by benign changes in the environment. For example, if a new service
is added to a host and a few hosts start using it, an NBA sensor is likely to detect this as anomalous.
However, typically this would be a low-priority alert, and not reported as an attack, so it is debatable
whether this can truly be considered a false positive. If a major service is moved from one host to another
and a thousand hosts start using it one day, that might inadvertently trigger an alert.
NBA technologies rely primarily on observing network traffic and developing baselines of expected flows
and inventories of host characteristics. NBA products automatically update their baselines on an ongoing
basis. As a result, typically there is not much tuning or customization to be done, other than updating
firewall ruleset-like policies that are offered by most products. Also, administrators might adjust
thresholds periodically (e.g., how much additional bandwidth usage should trigger an alert) to take into
account changes to the environment. Thresholds can often be set on a per-host basis or for administrator-
defined groups of hosts. Most NBA products also offer whitelist and blacklist capabilities for hosts and
services. Another common feature of NBA products is customization of each alert (e.g., specifying which
prevention option it should trigger). Unlike network-based IDPSs, code editing features are generally not
applicable to NBA products.
A few NBA products offer limited signature-based detection capabilities. The supported signatures tend
to be very simple, and primarily look for particular values in certain IP, TCP, UDP, or ICMP header
fields. This capability is most helpful for inline NBA sensors because they can use the signatures to find
and block attacks that a firewall or router might not be capable of blocking. For example, suppose that
there is a DDoS attack that uses a flood of specially crafted HTTP traffic against a Web server. A
firewall or router might not be able to block the attack without blocking all HTTP activity to the Web
server, but an inline NBA sensor could be configured with a customized signature to block just the attack
activity if it has a unique set of characteristics. On the other hand, an inline NBA sensor might be able to
block the attack anyway because of its flow patterns.
administrators should also ensure that significant changes to hosts, such as new hosts and new services,
are reflected in NBA settings. Although it might not feasible to automatically link NBA systems with
6-5
change management systems, administrators could review change management records regularly and
adjust host inventory information in the NBA to prevent false positives.
NBA technologies offer strong detection capabilities for certain types of threats, but they also have
significant limitations. Some of these limitations are described in Section 6.2.3.2. An important
limitation is the delay in detecting attacks. Some delay is inherent in anomaly detection methods that are
based on deviations from a baseline, such as increased bandwidth usage or additional connection
attempts. However, NBA technologies often have additional delay caused by their data sources,
especially when they rely on flow data from routers and other network devices. This data is often
transferred to the NBA system in batches; depending on the product’s capabilities, network capacity, and
administrator preferences, this could occur relatively frequently (e.g., every minute, every two minutes) or
relatively infrequently (e.g., every 15 minutes, every 30 minutes). Because of this delay, attacks that
occur quickly, such as malware infestations and DoS attacks, may not be detected until they have already
disrupted or damaged systems.
This delay can be avoided by using sensors that do their own packet captures and analysis instead of
relying on flow data from other devices. However, performing packet captures and analysis is much more
resource-intensive than analyzing flow data. A single sensor can analyze flow data from many networks,
or perform direct monitoring (packet captures) itself generally for a few networks at most. Therefore, to
do direct monitoring instead of using flow data, organizations might have to purchase more powerful
sensors and/or more sensors.
NBA sensors offer various intrusion prevention capabilities, including the following (grouped by sensor
type):
Passive Only
– Ending the Current TCP Session. A passive NBA sensor can attempt to end an existing TCP
session by sending TCP reset packets to both endpoints.
Inline Only
– Performing Inline Firewalling. Most inline NBA sensors offer firewall capabilities that can be
used to drop or reject suspicious network activity.
Both Passive and Inline
– Reconfiguring Other Network Security Devices. Many NBA sensors can instruct network
security devices such as firewalls and routers to reconfigure themselves to block certain types of
activity or route it elsewhere, such as a quarantine virtual local area network (VLAN).
– Running a Third-Party Program or Script. Some NBA sensors can run an administrator-
specified script or program when certain malicious activity is detected.
Most NBA sensors allow administrators to specify the prevention capability configuration for each type
of alert. This usually includes enabling or disabling prevention, as well as specifying which type of
prevention capability should be used. Most NBA system implementations use prevention capabilities in a
limited fashion or not at all because of false positives; blocking a single false positive could cause major
6-6
disruptions in network communications. Prevention capabilities are most often used for NBA sensors
when blocking a specific known threat, such as a new worm.
6.3 Management
Most NBA products offer similar management capabilities. This section discusses major aspects of
Once an NBA product has been selected, the administrators need to design an architecture, perform NBA
component testing, secure the NBA components, and then deploy them. The only addition to the material
presented in Section 3.3.1 involves component testing and deployment. When NBA components are
being deployed to production networks, organizations should typically install the sensors in a relatively
short period of time, so that they can all build their inventories and generate their initial baselines at the
same time. Detection accuracy is likely to be decreased during implementation and initial usage because
the sensors will have substantially incomplete information about their environment until they have
monitored it for days or weeks. Other than that, deployment of NBA sensors and consoles is essentially
the same as it is for network-based IDPS sensors and consoles.
NBA products are designed to be operated and maintained through consoles, which typically have very
similar capabilities to the consoles for network-based IDPSs. A key difference is that NBA consoles
usually offer visualization tools that can display the flow of attacks through an organization’s networks.
These tools can show a user which hosts were affected by an attack, the sequence of hosts that an attack
passed through, and the first host to be involved in the attack. Some NBA products also offer command-
line interfaces.
Ongoing maintenance of NBA products is also very similar to that for network-based IDPSs. The
primary exception is the application of updates. Because most NBA products do not use signatures,
administrators only need to test and apply updates to the NBA software itself. Because NBA sensors are
appliance-based, updating them usually involves replacing an existing CD and either rebooting the sensor
or installing software from the CD. For NBA products that do have signature capabilities, administrators
should also acquire, test, and apply signature updates in the same way that network-based IDPS signature
updates are performed.
6.4 Summary
A network behavior analysis (NBA) system examines network traffic or statistics on network traffic to
identify unusual traffic flows. NBA solutions usually have sensors and consoles, with some products also
offering management servers. Some sensors are similar to network-based IDPS sensors in that they sniff
packets to monitor network activity on one or a few network segments. Other NBA sensors do not
monitor the networks directly, but instead rely on network flow information provided by routers and other
networking devices.
Most NBA sensors can be deployed in passive mode only, using the same connection methods (e.g.,
network tap, switch spanning port) as network-based IDPSs. Passive sensors that are performing direct
network monitoring should be placed so that they can monitor key network locations, such as the
divisions between networks, and key network segments, such as DMZ subnets. Inline sensors are
6-7
typically intended for network perimeter use, so they would be deployed in close proximity to the
perimeter firewalls, often in front to limit incoming attacks that could overwhelm the firewalls.
NBA products provide a variety of security capabilities. They offer extensive information gathering
capabilities, collecting detailed information on each observed host and constantly monitoring network
activity for changes to this information. NBA technologies typically perform extensive logging of data
related to detected events. They also typically have the capability to detect several types of malicious
activity, including DoS attacks, scanning, worms, unexpected application services, and policy violations,
such as a client system providing network services to other systems. Because NBA sensors work
primarily by detecting significant deviations from normal behavior, they are most accurate at detecting
attacks that generate large amounts of network activity in a short period of time and attacks that have
unusual flow patterns. Most NBA sensors can also reconstruct a series of observed events to determine
the origin of a threat.
NBA products automatically update their baselines on an ongoing basis. As a result, typically there is not
much tuning or customization to be done, other than updating firewall ruleset-like policies that most
products support. A few NBA products offer limited signature customization capabilities; these are most
helpful for inline sensors because they can use the signatures to find and block attacks that a firewall or
router might not be capable of blocking. Besides reviewing tuning and customizations periodically to
ensure that they are still accurate, administrators should also ensure that significant changes to hosts are
incorporated, such as new hosts and new services. Generally it is not feasible to automatically link NBA
systems with change management systems, but administrators could review change management records
regularly and adjust host inventory information in the NBA to prevent false positives.
NBA technologies have some significant limitations. They are delayed in detecting attacks because of
their data sources, especially when they rely on flow data from routers and other network devices. This
data is often transferred to the NBA in batches from every minute to a few times an hour. Attacks that
occur quickly may not be detected until they have already disrupted or damaged systems. This delay can
be avoided by using sensors that do their own packet captures and analysis; however, this is much more
resource-intensive than analyzing flow data. Also, a single sensor can analyze flow data from many
networks, while a single sensor can generally directly monitor only a few networks at once. Therefore, to
do direct monitoring instead of using flow data, organizations might have to purchase more powerful
sensors and/or more sensors.
6-8
7. Host-Based IDPS
A host-based IDPS monitors the characteristics of a single host and the events occurring within that host
for suspicious activity. Examples of the types of characteristics a host-based IDPS might monitor are
wired and wireless network traffic (only for that host), system logs, running processes, file access and
modification, and system and application configuration changes. This section provides a detailed
discussion of host-based IDPS technologies. First, it covers the major components of the technologies
and explains the architectures typically used for deploying the components. It also examines the security
capabilities of the technologies in depth, including the methodologies they use to identify suspicious
activity. The rest of the section discusses the management capabilities of the technologies, including
recommendations for implementation and operation.
This section describes the major components of typical host-based IDPSs and illustrates the most
common network architectures for these components. It also provides recommendations for selecting
which hosts should use host-based IDPSs. This section also describes how host-based IDPSs can affect a
host’s internal architecture, such as intercepting process calls.
Most host-based IDPSs have detection software known as agents installed on the hosts of interest. Each
agent monitors activity on a single host and if IDPS capabilities are enabled, also performs prevention
actions. Section 7.2.2 discusses the types of activity monitored by host-based IDPSs. The agents
transmit data to management servers, which may optionally use database servers for storage. 42 Consoles
are used for management and monitoring.
Some host-based IDPS products use dedicated appliances running agent software instead of installing
agent software on individual hosts. Each appliance is positioned to monitor the network traffic going to
and from a particular host. Technically, these appliances could be considered network-based IDPSs,
because they are deployed inline to monitor network traffic. However, they usually monitor activity for
only one specific type of application, such as a Web server or database server, so they are more
specialized than a standard network-based IDPS. Also, the software running on the appliance often has
the same or similar functionality as the host-based agents. Therefore, host-based IDPS products using
appliance-based agents are included in this section.
Each agent is typically designed to protect one of the following:
A server. Besides monitoring the server’s operating system (OS), the agent may also monitor some
common applications.
A client host (desktop or laptop). Agents designed to monitor users’ hosts usually monitor the OS
and common client applications such as e-mail clients and Web browsers.
An application service. Some agents perform monitoring for a specific application service only,
such as a Web server program or a database server program. This type of agent is also known as an
application-based IDPS.
42
Because this publication focuses on enterprise IDPS deployment, it assumes that agents send their data to management
servers; however, some agents can be deployed standalone, and managed and monitored directly by the host’s administrators
without using a management server.
7-1
Most products do not have agents for other types of hosts, such as network devices (e.g., firewalls,
routers, switches).
The network architecture for host-based IDPS deployments is typically very simple. Because the agents
are deployed to existing hosts on the organization’s networks, the components usually communicate over
those networks instead of using a separate management network. Most products encrypt their
communications, preventing eavesdroppers from accessing sensitive information. Appliance-based
agents are typically deployed inline immediately in front of the hosts that they are protecting. Figure 7-1
shows an example of a host-based IDPS deployment architecture.
Figure 7-1. Host-Based IDPS Agent Deployment Architecture Example
7-2
7.1.3 Agent Locations
Host-based IDPS agents are most commonly deployed to critical hosts such as publicly accessible servers
and servers containing sensitive information. However, because agents are available for various server
and desktop/laptop operating systems, as well as specific server applications, organizations could
potentially deploy agents to most of their servers and desktops/laptops. Some organizations use host-
based IDPS agents primarily to analyze activity that cannot be monitored by other security controls. For
example, network-based IDPS sensors cannot analyze the activity within encrypted network
communications, but host-based IDPS agents installed on endpoints can see the unencrypted activity.
Organizations should consider the following additional criteria when selecting agent locations:
The cost to deploy, maintain, and monitor the agents

The OSs and applications supported by the agents
The importance of the host’s data or services
The ability of the infrastructure to support the agents (e.g., sufficient network bandwidth to transfer
alert data from the agents to centralized servers and to transfer software and policy updates from the
centralized servers to the agents).
7.1.4 Host Architectures
To provide intrusion prevention capabilities, most IDPS agents alter the internal architecture of the hosts
on which they are installed. This is typically done through a shim, which is a layer of code placed
between existing layers of code. A shim intercepts data at a point where it would normally be passed
from one piece of code to another. The shim can then analyze the data and determine whether or not it
should be allowed or denied. Host-based IDPS agents may use shims for several types of resources,
including network traffic, filesystem activity, system calls, Windows registry activity, and common
applications (e.g., e-mail, Web).
Some host-based IDPS agents do not alter the host architecture. Instead, they monitor activity without
shims, or they analyze the artifacts of activity, such as log entries and file modifications. Although less
intrusive to the host, reducing the possibility of the IDPS interfering with the host’s normal operations,
these methods are also generally less effective at detecting threats and often cannot perform any
prevention actions.
One of the important decisions in selecting a host-based IDPS solution is whether to install agents on
hosts or use agent-based appliances. From a detection and prevention perspective, installing agents on
hosts is generally preferable because the agents have direct access to the hosts’ characteristics, often
allowing them to perform more comprehensive and accurate detection and prevention. However, agents
often support only a few common OSs; if a host does not use a supported OS, an appliance can be
deployed instead. Another reason to use an appliance instead of installing an agent on a host is
performance; if an agent would negatively impact the performance of the monitored host too much, it
might be necessary to offload the agent’s functions to an appliance.
Host-based IDPSs provide a variety of security capabilities. Sections 7.2.1 through 7.2.4 describe
common security capabilities, divided into four categories: logging, detection, prevention, and other,
respectively.
7-3
Host-based IDPSs typically perform extensive logging of data related to detected events. This data can be
used to confirm the validity of alerts, to investigate incidents, and to correlate events between the host-
based IDPS and other logging sources. Data fields commonly logged by host-based IDPSs include the
following:

Event or alert type
Event details specific to the type of event, such as IP address and port information, application
information, filenames and paths, and user IDs
Most host-based IDPSs have the capability to detect several types of malicious activity. They often use a
combination of signature-based detection techniques to identify known attacks, and anomaly-based
detection techniques with policies or rulesets to identify previously unknown attacks. This section
discusses the following aspects of host-based IDPS detection capabilities:

Detection accuracy
The types of events detected by host-based IDPSs vary considerably based primarily on the detection
techniques that they use. Some host-based IDPS products offer several of these detection techniques,
while others focus on a few or one. For example, several products only analyze network traffic, and other
products only check the integrity of a host’s critical files. Specific techniques commonly used in host-
based IDPSs include the following:
Code Analysis. Agents might use one or more of the techniques listed below to identify malicious
activity by analyzing attempts to execute code. All of these techniques are helpful at stopping
malware and can also prevent other attacks, such as some that would permit unauthorized access,
code execution, or escalation of privileges.
– Code behavior analysis. Before code is run normally on a host, it can first be executed in a
virtual environment or a sandbox to analyze its behavior and compare it to profiles or rules of
known good and bad behavior. For example, when a particular piece of code is executed, it might
attempt to gain administrator-level privileges or to overwrite a system executable.
– Buffer overflow detection. Attempts to perform stack and heap buffer overflows can be
detected by looking for their typical characteristics, such as certain sequences of instructions and
attempts to access portions of memory other than those allocated to the process.
7-4
– System call monitoring. The agent knows which applications and processes should be calling
which other applications and processes or performing certain actions. For example, an agent
could recognize a process attempting to intercept keystrokes, such as a keylogger. Another
example is an agent that restricts component object model (COM) object loading, such as
permitting a PDA application, but not other applications, to access an e-mail client’s address
book. Agents can also restrict which drivers can be loaded, which can prevent the installation of
rootkits and other attacks.
– Application and library lists. An agent might monitor each application and library (e.g.,
dynamic link library [DLL]) that a user or process attempts to load and compare that information
to lists of authorized and unauthorized applications and libraries. This can be used not only to
restrict which applications and libraries can be used, but which versions of them can be used.
Network Traffic Analysis. This is often similar to what a network-based IDPS does; some products
can analyze both wired and wireless network traffic. In addition to network, transport, and
application layer protocol analysis, agents may include special processing for common applications,
such as popular e-mail clients. Traffic analysis also allows the agent to extract files sent by
applications such as e-mail, Web, and peer-to-peer file sharing, which can then be checked for
malware.
Network Traffic Filtering. Agents often include a host-based firewall that can restrict incoming and
outgoing traffic for each application on the system, preventing unauthorized access and acceptable
use policy violations (e.g., use of inappropriate external services). Some of these firewalls can
generate and use a list of the hosts with which this host should be communicating, particularly within
the organization.
Filesystem Monitoring. Filesystem monitoring can be performed using several different techniques,
including the ones listed below. Administrators should be aware that some products base their
monitoring on filenames, so if users or attackers alter filenames, filesystem monitoring techniques
might be made ineffective.
– File integrity checking. This involves periodically generating message digests or other
cryptographic checksums for critical files, comparing them to reference values, and identifying
differences. File integrity checking can only determine after-the-fact that a file has already been
changed, such as a system binary being replaced by a Trojan horse or a rootkit.
– File attribute checking. This is periodically checking the attributes of important files, such as
ownership and permissions, for changes. Like file integrity checking, it can only determine after-
the-fact that a change has occurred.
– File access attempts. An agent with a filesystem shim can monitor all attempts to access critical
files, such as system binaries, and stop attempts that are suspicious. The agent has a set of
policies regarding file access, so the agent compares those policies to the characteristics of the
current attempt, including which user or application is trying to access each file, and what type of
access has been requested (read, write, execute). 43 This could be used to prevent some forms of
malware from being installed, such as rootkits and Trojan horses, as well as preventing many
other types of malicious activity involving file access, modification, replacement, or deletion.
43
On Windows systems, many configuration settings reside in a set of special files known as the registry. Some agents have
special registry shims that restrict access to critical portions of the registry, especially those frequently used by malware.
7-5
Log Analysis. Some agents can monitor and analyze OS and application logs to identify malicious
activity. 44 These logs may contain information on system events, which are operational actions
performed by OS components (e.g., shutting down the system, starting a service); audit records,
which contain security event information such as successful and failed authentication attempts and
security policy changes; and application events, which are significant operational actions performed
by applications, such as application startup and shutdown, application failures, and major application
configuration changes.
Network Configuration Monitoring. Some agents can monitor a host’s current network
configuration and detect changes to it. Typically all network interfaces on the host are monitored,
including wired, wireless, virtual private network (VPN), and modem. Examples of significant
network configuration changes are network interfaces being placed in promiscuous mode, additional
TCP or UDP ports being used on the host, or additional network protocols being used, such as non-IP
protocols. These changes could indicate that the host has already been compromised and is being
configured for use in future attacks or for transferring data.
Organizations should determine which aspects of hosts need to be monitored and select IDPS products
that provide adequate monitoring and analysis for them.
Because host-based IDPSs often have extensive knowledge of hosts’ characteristics and configurations, a
host-based IDPS agent can often determine whether or not an attack against a host would succeed if not
stopped. Agents can use this knowledge to select prevention actions and to assign appropriate priorities
to alerts.
Like any other IDPS technology, host-based IDPSs often cause false positives and false negatives.
However, the accuracy of detection is more challenging for host-based IDPSs because several of the
possible detection techniques, such as log analysis and filesystem monitoring, do not have knowledge of
the context under which detected events occurred. For example, a host may be rebooted, a new
application installed, or a system file replaced. These actions could be done by malicious activity, or they
could be part of normal host operation and maintenance. The events themselves are detected accurately,
but their benign or malicious nature cannot always be determined without additional context. Some
products, particularly those intended for desktop/laptop use, prompt users to provide context, such as
whether or not the user is currently upgrading a particular application. If a user does not respond to the
prompt in a set period of time (typically a few minutes), the agent chooses a default action (allow or
deny).
Host-based IDPSs that use combinations of several detection techniques should generally be capable of
achieving more accurate detection than products that use one or a few techniques. Because each
technique can monitor different aspects of a host, using more techniques allows agents to collect more
information on the activities occurring. This provides a more complete picture of the events, and may
also provide additional context that can be helpful in assessing the intent of certain events.
Host-based IDPSs usually require considerable tuning and customization. For example, many rely on
observing host activity and developing baselines or profiles of expected behavior. Others need to be
44
Some products only perform log analysis and log management activities, such as log consolidation. Although these
products are often referred to as host-based IPS, some of them are actually security information and event management
(SIEM) products. Section 9 contains additional information on SIEM.
7-6
configured with detailed policies that define exactly how each application on a host should behave. As
the host environment changes, administrators should ensure that host-based IDPS policies are updated to
take those changes into account. Generally it is not feasible to automatically link host-based IDPSs with
change management systems, but administrators could review change management records regularly and
adjust host configuration and policy information in the host-based IDPS to prevent false positives.
Policies can often be set on a per-host basis or for groups of hosts, which provides flexibility. Some
products also permit multiple policies to be configured on a host for multiple environments; this is most
helpful for hosts that function in multiple environments, such as a laptop used both within an organization
and from external locations. Host-based IDPSs also offer whitelist and blacklist capabilities for hosts
(e.g., IP addresses of other hosts with which a host might communicate), applications, ports, filenames,
and other host characteristics. In fact, some products automatically update agents with the latest whitelist
and blacklist information, based on reports from other agents of newly detected malicious activity.
Another common feature of host-based IDPSs is customizing each alert, such as specifying which
response option should be performed for an alert.
The sophistication of signature capabilities for host-based IDPSs varies widely depending on the
detection techniques used by each product.
Host-based IDPSs have some significant limitations. Some of these limitations are described in Section
7.2.2.2. Other important limitations include the following:
Alert Generation Delays. Although agents generate alerts on a real-time basis for most detection
techniques, some techniques are used periodically to identify events that have already happened.
Such techniques might only be applied hourly or even just a few times a day, causing significant
delay in identifying certain events.
Centralized Reporting Delays. Many host-based IDPSs are intended to forward their alert data to
the management servers on a periodic basis, not in a near-real-time fashion. Alert data is typically
transferred in batches every 15 to 60 minutes to reduce overhead for the IDPS components and the
network. Smaller host-based IDPS implementations can usually transfer data more often, but for
larger implementations, vendors typically recommend less frequent transfers. This can cause delays
in initiating response actions, which especially increases the impact of incidents that spread quickly,
such as malware infestations.
Host Resource Usage. Unlike the other IDPS technologies, host-based IDPSs involve running
agents on the hosts being monitored. These agents can consume considerable host resources,
including memory, processor usage, and disk storage. The agents’ operation, particularly the shims,
can also cause slowdowns in operations such as network and filesystem usage. Testing of host
resource usage should be performed when evaluating host-based IDPS products for possible purchase.
Conflicts with Existing Security Controls. Installing an agent can cause existing host security
controls to be disabled automatically, such as personal firewalls, if those controls are perceived to
duplicate functionality provided by the agent. Installing an agent can also cause conflicts with other
security controls, especially those that use shims to intercept host activity (e.g., personal firewalls,
VPN clients). For some products, a network shim is optional, although it does permit greater
functionality, especially in prevention actions. To identify any potential conflicts, implementers
should test agents on hosts that are running the host security controls used on the hosts to which the
agents would be deployed.
7-7
Rebooting Hosts. For many host-based IDPS products, agent software upgrades and some agent
configuration changes can necessitate rebooting the monitored hosts. As with other problems
mentioned earlier, implementers should perform extensive testing of this before selecting products
and consider the impact that reboots could have on the effectiveness of the agents (e.g., agents being
unable to detect the latest threats because important hosts could not be rebooted).
Host-based IDPS agents offer various intrusion prevention capabilities. Because the capabilities vary
based on the detection techniques used by each product, the following items describe the capabilities by
detection technique.
Code Analysis. The code analysis techniques can prevent code from being executed, including
malware and unauthorized applications. Some host-based IDPSs can also stop network applications
from invoking shells, which could be used to attempt to perform certain types of attacks. If
configured and tuned well, code analysis can be very effective, particularly at stopping previously
unknown attacks.
Network Traffic Analysis. This can stop incoming network traffic from being processed by the host
and outgoing network traffic from exiting it. This might be done to stop network, transport, and
application layer attacks (and in some cases, wireless networking protocol attacks), as well as to stop
the use of unauthorized applications and protocols. Analysis can also identify malicious files being
downloaded or transferred and prevent those files from being placed on the host. The network traffic
might be dropped or rejected, and the host’s personal firewall (which might be built into the agent)
could be reconfigured to shun additional traffic related to the suspicious traffic. Network traffic
analysis is effective at stopping many known and previously unknown attacks.
Network Traffic Filtering. Working as a host-based firewall, this can stop unauthorized access and
acceptable use policy violations (e.g., use of inappropriate external services). It is effective only
against stopping activity that is identifiable by IP address and TCP port, UDP port, or ICMP type and
code.
Filesystem Monitoring. This can prevent files from being accessed, modified, replaced, or deleted,
which could stop malware installation, including Trojan horses and rootkits, as well as other attacks
involving inappropriate file access. This technique can provide an additional layer of access control
to supplement the existing access control technologies on a host.
Other host-based IDPS detection techniques, such as log analysis, network configuration monitoring, and
file integrity and attribute checking, generally do not support prevention actions because they identify
events well after they have occurred.
7.2.4 Other Capabilities
Some host-based IDPSs offer non-IDPS capabilities such as antivirus software, spam filtering, and Web
or e-mail content filtering. It is outside the scope of this guide to discuss these capabilities, which are
often provided by bundling separate products with the IDPS software. This section focuses on those
additional product capabilities that are more closely tied to host-based IDPS functionality. Examples of
these capabilities are as follows:
Removable Media Restriction. Some products can enforce restrictions on the use of removable
media, both USB-based (e.g., flash drive) and traditional (e.g., CD, floppy disk). This can prevent
7-8
malware or other unwanted files from being transferred to a host, and can also stop sensitive files
from being copied from the host to removable media.
Audiovisual Device Monitoring. A few host-based IDPS products can detect when a host’s
audiovisual devices, such as microphones, cameras, or IP-based phones are activated or used. This
could indicate that the host has been compromised by an attacker.
Host Hardening. Some host-based IDPSs can automatically harden hosts on an ongoing basis. For
example, if an application is reconfigured, causing a particular security function to be disabled, the
IDPS could detect this and enable the security function.
Process Status Monitoring. Some products monitor the status of processes or services running on a
host, and if they detect that one has stopped, they restart it automatically. Some products can also
monitor the status of security programs such as antivirus software.
Network Traffic Sanitization. Some agents, particularly those deployed on appliances, can sanitize
the network traffic that they monitor. For example, an appliance-based agent could act as a proxy and
rebuild each request and response that is directed through it. This can be effective at neutralizing
certain unusual activity, particularly in packet headers and application protocol headers. Sanitization
performed by an appliance can also reduce the amount of reconnaissance the attackers can perform on
the host it is protecting. Examples include hiding the servers’ OS fingerprints and application error
messages. Some products can also prevent sensitive information such as social security numbers and
credit card numbers from being displayed on Web server pages.
7.3 Management
Most host-based IDPSs offer similar management capabilities. This section discusses major aspects of
Once a host-based IDPS product has been selected, the administrators need to design an architecture,
perform IDPS component testing, secure the IDPS components, and then deploy them. The following
items list additions to the material presented in Section 3.3.1:
Component Testing and Deployment. After the host-based IDPS components have been evaluated
in a test environment, organizations should implement a small pilot in the production environment.
This allows administrators to perform tuning and customization activities on a small set of production
hosts in preparation for a larger deployment. The prevention features should be disabled during the
pilot and the subsequent production implementation until the agents have been sufficiently tuned and
customized.
Securing the Components. If the management servers or consoles must authenticate to each agent
host to manage the agents or collect their data, organizations should ensure that the authentication
mechanisms can be managed and secured properly. For example, if passwords are needed, there are
security concerns with using a single password for all agent hosts; if a separate password is used for
each agent host, the passwords can be difficult to track and maintain for hundreds or thousands of
agents. If cryptographic keys are used for authentication, key management can present challenges in
issuing and distributing keys.
7-9
7.3.2 Operation
Host-based IDPSs should be operated according to the recommendations presented in Section 3.3.2. The
only exception is in updating the agents. Some agents can periodically check the management server for
updates and automatically retrieve and install or apply those updates. Other agents cannot do this,
requiring an administrator to manually check for, transfer, and install or apply updates. In many cases, an
agent’s update capability is related to the type of operating system on which it is deployed.
7.4 Summary
Host-based IDPSs monitors the characteristics of a single host and the events occurring within that host
for suspicious activity. Examples of the types of characteristics a host-based IDPS might monitor are
wired and wireless network traffic, system logs, running processes, file access and modification, and
system and application configuration changes. Most host-based IDPSs have detection software known as
agents installed on the hosts of interest. Each agent monitors activity on a single host and if prevention
capabilities are enabled, also performs prevention actions. The agents transmit data to management
servers. Each agent is typically designed to protect a server, a desktop or laptop, or an application
service.
The network architecture for host-based IDPS deployments is typically very simple. Because the agents
are deployed to existing hosts on the organization’s networks, the components usually communicate over
those networks instead of using a management network. Host-based IDPS agents are most commonly
deployed to critical hosts such as publicly accessible servers and servers containing sensitive information.
However, because agents are available for various server and desktop/laptop operating systems, as well as
specific server applications, organizations could potentially deploy agents to most of their servers and
desktops/laptops. Organizations should consider several criteria when selecting agent locations, including
the need to analyze activity that cannot be monitored by other security controls; the cost of the agents’
deployment, maintenance, and monitoring; the OSs and applications supported by the agents; the
importance of each host’s data or services; and the ability of the network infrastructure to support the
agents’ communications.
Most IDPS agents alter the internal architecture of the hosts on which they are installed through shims,
which are layers of code placed between existing layers of code. Although it is less intrusive to the host
to perform monitoring without shims, which reduces the possibility of the IDPS interfering with the
host’s normal operations, monitoring without shims is also generally less accurate at detecting threats and
often precludes the performance of effective prevention actions.
Host-based IDPSs provide a variety of security capabilities. They typically perform extensive logging of
data related to detected events and can detect several types of malicious activity. Detection techniques
used include code analysis, network traffic analysis, network traffic filtering, filesystem monitoring, log
analysis, and network configuration monitoring. Host-based IDPSs that use combinations of several
detection techniques should generally be capable of achieving more accurate detection than products that
use one or a few techniques, because each technique can monitor different characteristics of hosts.
Organizations should determine which characteristics need to be monitored and select IDPS products that
provide adequate monitoring and analysis of those characteristics.
Host-based IDPSs usually require considerable tuning and customization. For example, many rely on
observing host activity and developing baselines or profiles of expected behavior. Others need to be
configured with detailed policies that define exactly how each application on a host should behave. As
the host environment changes, administrators should ensure that host-based IDPS policies are updated to
take those changes into account.
7-10
Host-based IDPSs have some significant limitations. Some detection techniques are performed only
periodically, such as hourly or a few times a day, to identify events that have already happened, causing
significant delay in identifying certain events. Also, many host-based IDPSs forward their alert data to
the management servers in batches a few times an hour, which can cause delays in initiating response
actions. Because host-based IDPSs run agents on the hosts being monitored, they can impact host
performance because of the resources the agents consume. Installing an agent can also cause conflicts
with existing host security controls, such as personal firewalls and VPN clients. Agent upgrades and
some configuration changes can also necessitate rebooting the monitored hosts.
Host-based IDPSs offer various intrusion prevention capabilities; these vary based on the detection
techniques used by each product. Code analysis techniques can prevent code from being executed; this
can be very effective at stopping both known and previously unknown attacks. Network traffic analysis
can stop incoming and outgoing network traffic containing network, transport, or application layer
attacks, wireless networking protocol attacks, and the use of unauthorized applications and protocols.
Network traffic filtering works as a host-based firewall and stops unauthorized access and acceptable use
policy violations. Filesystem monitoring can prevent files from being accessed, modified, replaced, or
deleted, which can stop malware installation and other attacks involving inappropriate file access. Other
host-based IDPS detection techniques generally do not support prevention actions because they identify
events well after they have occurred.
Some host-based IDPSs offer additional capabilities related to intrusion detection and prevention, such as
enforcing restrictions on the use of removable media, detecting the activation or use of audiovisual
devices, automatically hardening hosts on an ongoing basis, monitoring the status of running processes
and restarting failed ones, and performing network traffic sanitization.
7-11
7-12
8. Using and Integrating Multiple IDPS Technologies
As Sections 4 through 7 have explained, the four primary types of IDPS technologies—network-based,
wireless, network behavior analysis (NBA), and host-based—each offer fundamentally different
information gathering, logging, detection, and prevention capabilities. Each technology type offers
benefits over the other, such as detecting some events that the others cannot, detecting some events with
significantly greater accuracy than the other technologies, and performing in-depth analysis without
significantly impacting the performance of the protected hosts. Accordingly, organizations should
consider using multiple types of IDPS technologies to achieve more comprehensive and accurate
detection and prevention of malicious activity, with lower rates of false positives and false negatives.
This section provides guidance on using multiple IDPS technologies to create a broader IDPS solution
and discusses the advantages and disadvantages of using multiple technologies.
Organizations that are planning to use multiple types of IDPS technologies, or even multiple products
within a single IDPS technology class, should consider whether or not the IDPS products should be
integrated in some way, either working together directly or feeding their data into a centralized logging
system or security information and event management system. This section explains how different IDPS
products can be integrated, and the benefits and limitations of the integration methods. It also provides
overviews of other technologies that complement IDPS technologies and discusses how they can be
included in an IDPS solution to further improve detection and prevention.
8.1 The Need for Multiple IDPS Technologies
In many environments, a robust IDPS solution cannot be achieved without using multiple types of IDPS
technologies. For example, network-based IDPSs cannot monitor wireless protocols, and wireless IDPSs
cannot monitor application protocol activity. Table 8-1 provides a high-level comparison of the four
primary IDPS technology types. The strengths listed in the table indicate the roles or situations in which
each technology type is generally superior to the others. A particular technology type may have
additional benefits over others, such as logging additional data that would be useful for validating alerts
recorded by other IDPSs, or preventing intrusions that other IDPSs cannot because of technology
capabilities or placement (e.g., on the host instead of on the network).
Table 8-1. Comparison of IDPS Technology Types
IDPS Types of Malicious Scope per Sensor Strengths

Technology Activity Detected or Agent
Type
Network- Network, transport, and Multiple network Able to analyze the widest range of
Based application TCP/IP layer subnets and groups application protocols; only IDPS that can
activity of hosts thoroughly analyze many of them
Wireless Wireless protocol activity; Multiple WLANs Only IDPS that can monitor wireless
unauthorized wireless local and groups of protocol activity
area networks (WLAN) in use wireless clients
NBA Network, transport, and Multiple network Typically more effective than the others at
application TCP/IP layer subnets and groups identifying reconnaissance scanning and
activity that causes anomalous of hosts DoS attacks, and at reconstructing major
network flows malware infections
Host-Based Host application and operating Individual host Only IDPS that can analyze activity that
system (OS) activity; network, was transferred in end-to-end encrypted
transport, and application communications
TCP/IP layer activity
8-1
For most environments, a combination of network-based and host-based IDPSs is needed for an effective
IDPS solution. Wireless IDPSs may also be needed if the organization determines that its wireless
networks need additional monitoring or if the organization wants to ensure that rogue wireless networks
are not in use in the organization’s facilities. NBA products can also be deployed if organizations desire
additional detection capabilities for denial of service (DoS) attacks, worms, and other threats as discussed
in Section 6.
In addition to using multiple types of IDPS technologies, some organizations also use multiple products
of the same IDPS technology type. This is often done to improve detection capabilities. Because each
product uses somewhat different detection methodologies and detects some events that another product
cannot, using multiple products can allow for more comprehensive detection of possible incidents. Also,
having multiple products in use, particularly to monitor the same activity, makes it easier for analysts to
confirm the validity of alerts and identify false positives, and also provides redundancy, should one
product fail for any reason.
8.2 Integrating Different IDPS Technologies
Many organizations use multiple IDPS products, usually from different vendors (most vendors make
products in only one IDPS technology type). By default, these products function completely
independently of each other. This has some notable benefits, such as minimizing the impact that a failure
or compromise of one IDPS product has on other IDPS products. However, if the products are not
integrated in any way, the effectiveness of the entire IDPS implementation may be somewhat limited.
Data cannot be shared by the products, and IDPS users and administrators may have to expend extra
effort to monitor and manage multiple sets of products. IDPS products can be directly integrated, such as
one product feeding alert data to another product, or they can be indirectly integrated, such as all the IDPS
products feeding alert data into a security information and event management system. Sections 8.2.1 and
8.2.2 discuss the benefits and limitations of direct and indirect integration, respectively.
8.2.1 Direct IDPS Integration
Direct IDPS integration is most often performed when an organization uses multiple IDPS products from
a single vendor. For example, some vendors offer both network-based and host-based products. These
vendors frequently offer a single console that can be used to manage and monitor both types of products.
This can provide significant time savings to administrators and users because it streamlines their work.
Some products also share data; for example, a product might use host-based IDPS data to determine if an
attack detected by network-based IDPS sensors was successful, or if an attack stopped by network-based
IDPS data would have been successful if allowed to pass. This information can speed the analysis
process and help users to better prioritize threats. The primary disadvantage of using a fully integrated
solution is that a failure or compromise could endanger all the IDPS technologies that are part of the
integrated solution.
A more limited form of direct IDPS integration is having one IDPS product provide data for another IDPS
product. As mentioned previously, two products from the same vendor often share data with each other
for correlation purposes. Data can also be shared among products from different vendors, although
typically this simply involves one product providing data as input to the second product. For example, a
network-based IDPS could potentially provide network flow information to an NBA sensor. A host-
based IDPS could provide system configuration information to NBA or network-based IDPS sensors.
This data can be used for event correlation and better prioritization of alerts.
8-2
8.2.2 Indirect IDPS Integration
Indirect IDPS integration is usually performed with security information and event management (SIEM)
software. 45 SIEM software is designed to import information from various security-related logs and
correlate events among them. 46 Log types commonly supported by SIEM software include IDPSs,
firewalls, antivirus software, and other security software; OSs (e.g., audit logs); application servers (e.g.,
Web servers, e-mail servers); and even physical security devices such as badge readers. SIEM software
generally works by receiving copies of the logs from the logging hosts over secure network channels,
converting the log data into standard fields and values (known as normalization), then identifying related
events by matching IP addresses, timestamps, usernames, and other characteristics. 47 SIEM products can
identify malicious activity such as attacks and malware infections, as well as misuse and inappropriate
usage of systems and networks. Some SIEM software can also initiate prevention responses for
designated events. SIEM products usually do not generate original event data; instead, they generate
meta-events based on their analysis of the imported event data.
Ways in which SIEM software complements IDPSs include the following:
SIEM software can identify some types of events that individual IDPSs cannot because of its ability
to correlate events logged by different technologies.
The consoles for SIEM software can make data from many sources available through a single
interface, which can save time for users that need to monitor multiple IDPSs. SIEM consoles also
may offer analysis and reporting tools that certain IDPSs’ consoles do not.
Users can more easily verify the accuracy of IDPS alerts because the SIEM may be able to link each
alert to supporting information from other logs. This can also help users to determine whether or not
certain attacks succeeded.
Limitations of SIEM software in the context of IDPS include the following:
There is often a considerable delay between the time an event begins and the time the SIEM sees the
corresponding log data. Log data may be transferred from logging hosts to the SIEM in batch mode,
such as every 5 or 10 minutes. As a result, malicious activity alerts are often displayed on an IDPS
console earlier than on a SIEM console, and prevention actions are less timely.
SIEM products typically transfer only some data fields from the original logs. For example, if a
network-based IDPS records packets, the packets may not be transferred to the SIEM because of
bandwidth and storage limitations. Also, the log normalization process that converts each data field
to a standard format and labels the data consistently can occasionally introduce errors in the data or
cause some data to be lost. Fortunately, SIEM products typically do not alter the original data
sources, so they can be referenced to verify the accuracy of the data if needed.
SIEM software may not offer agents for all IDPS products. This could require administrators to write
custom agents to transfer IDPS data to the SIEM servers, or it could necessitate having the IDPSs
perform logging using a different mechanism so that the SIEM software can understand the log
format.
45
For additional information on SIEM software and log management, see NIST SP 800-92, Guide to Computer Security Log
Management, which is available at http://csrc.nist.gov/publications/nistpubs/.
46
SIEM is also sometimes known as security event management (SEM) or security information management (SIM).
47
There are no widely accepted standards for IPS log formats or data fields. As a result, each IPS product uses its own schema
for logging.
8-3
An alternative to using SIEM software for centralized logging is to use a solution based primarily on the
syslog protocol. 48 Syslog provides a simple framework for log generation, storage, and transfer that any
IDPS could use if designed to do so. Some IDPSs offer features that allow their log formats to be
converted to syslog format. Syslog is very flexible for log sources, because each syslog entry contains a
content field into which logging sources can place information in any format. However, this flexibility
makes analysis of the log data challenging. Each IDPS may use many different formats for its log
messages, so a robust analysis program would need to be familiar with each format and be able to extract
the meaning of the data within the fields of each format. It might not be feasible to understand the
meaning of all log messages, so analysis might be limited to keyword and pattern searches. Generally,
the use of syslog for centralized collection and analysis of IDPS logs does not provide sufficiently strong
analysis capabilities to support incident identification and handling.
8.3 Other Technologies with IDPS Capabilities
In addition to dedicated IDPS technologies, organizations typically have several other types of
technologies that offer some IDPS capabilities and complement the primary IDPSs. This section
discusses common types of complementary technologies: network forensic analysis tools, anti-malware
technologies (antivirus software and antispyware software), firewalls and routers, and honeypots. 49 For
each, a brief overview of the technology is provided, and its use in intrusion detection and prevention and
its relationship to IDPSs are explained. Recommendations are also made as applicable for how the
complementary technologies should be used alongside of IDPSs.
8.3.1 Network Forensic Analysis Tool (NFAT) Software
Network forensic analysis tools (NFAT) focus primarily on collecting and analyzing wired network
traffic. Unlike a network-based IDPS, which performs in-depth analysis and stores only the necessary
network traffic, an NFAT typically stores most or all of the traffic that it sees, and then performs analysis
on that stored traffic. In addition to its forensic capabilities, NFAT software also offers features that
facilitate network traffic analysis, such as the following:
Reconstructing events by replaying network traffic within the tool, ranging from an individual session
(e.g., instant messaging [IM] between two users) to all sessions during a particular time period. The
speed of the replaying can typically be adjusted as needed.
Visualizing the traffic flows and the relationships among hosts. Some tools can even tie IP addresses,
domain names, or other data to physical locations and produce a geographic map of the activity.
Building profiles of typical activity and identifying significant deviations.
Searching application content for keywords (e.g., “confidential”, “proprietary”).
This makes it more valuable for network forensics and less valuable for intrusion detection and
prevention than a typical network-based IDPS.
48
Although syslog has been in use for many years, it has not been standardized formally. Request for Comments (RFC) 3164,
The BSD Syslog Protocol, was published in August 2001, and it is an informational RFC that describes commonly used
syslog message formats based on existing implementations. It is available at http://www.ietf.org/rfc/rfc3164.txt. By default,
syslog’s transport mechanism is trivially simple; RFC 3164 states that “…the payload of any IP packet destined to UDP port
514 MUST be considered to be a valid syslog message”. RFC 3195, Reliable Delivery for Syslog, was published in
November 2001, and it defines multiple transport mechanisms for syslog. It is available at
http://www.ietf.org/rfc/rfc3195.txt.
49
Additional information on complementary tools is available from NIST SP 800-86, Guide to Integrating Forensic
Techniques into Incident Response, which is available at http://csrc.nist.gov/publications/nistpubs/.
8-4
Ways in which NFAT software complements IDPSs include the following:
NFAT software is often more valuable for network forensics than IDPS software because of its
extensive packet logging.
Having NFAT software perform packet logging can reduce the load on network-based IDPS sensors.
NFAT software might be better-suited to customization, especially for content searches (e.g.,
keywords), than some IDPS technologies.
Some NFAT graphical user interfaces (GUI) may offer analysis, visualization, and reporting
capabilities that IDPS consoles do not.
Limitations of NFAT software in the context of IDPS include the following:
NFAT software usually does not have the intrusion detection capabilities of network-based IDPSs.
NFAT software typically offers no intrusion prevention capabilities.
8.3.2 Anti-Malware Technologies
The most commonly used technical control for malware threat mitigation is antivirus software. Types of
malware that it can detect include viruses, worms, Trojan horses, malicious mobile code, and blended
threats, as well as attacker tools such as keystroke loggers and backdoors. Antivirus software typically
monitors critical OS components, filesystems, and application activity for signs of malware, and attempts
to disinfect or quarantine files that contain malware. Most organizations deploy antivirus software both
centrally (e.g., e-mail servers, firewalls) and locally (e.g., file servers, desktops, laptops) so that all major
malware entry vectors can be monitored.
Another commonly used control for malware threat mitigation is spyware detection and removal utilities,
also known as antispyware software. They are similar to antivirus software, but they focus on detecting
both malware and non-malware forms of spyware, such as malicious mobile code and tracking cookies,
and spyware installation techniques such as unauthorized Web browser plug-in installations, popup ads,
and Web browser hijacking.
Both antivirus and antispyware products detect threats primarily through signature-based analysis. To
identify previously unknown threats, they also use heuristic techniques that examine activity for certain
suspicious characteristics. The product vendors create and release additional signatures when new threats
emerge, so that the products can detect them.
Ways in which antivirus and antispyware software complements IDPSs include the following:
IDPSs usually have limited malware and spyware detection capabilities (often only for the most
common threats, such as widespread worms), so antivirus and antispyware software can detect many
threats that IDPSs cannot.
NBA technology might identify that a worm is spreading based on unusual traffic flows, but it
probably could not identify which worm it is. Antivirus software should be able to determine which
worm it is, if the threat is not a new one for which the antivirus software does not yet have signatures.
Antivirus software, and to a lesser extent antispyware software, can take some load from IDPSs, such
as having antivirus software identify instances of a particular worm and disabling the worm’s
signatures on the IDPS sensors. This is particularly important during a widespread malware
8-5
infection, when IDPSs might become overwhelmed with worm alerts and other important events
occurring at the same time might go unnoticed by IDPS users.
Limitations of antivirus and antispyware software in the context of IDPS include the following:
Antivirus and antispyware software cannot detect threats other than malware and spyware.
Network-based IDPS and NBA software are often better able to recognize network service worms
than antivirus software can because antivirus software often monitors only the most common
application protocols. Also, antispyware software typically cannot detect network service worms.
Network-based IDPS and NBA software can typically monitor any protocol.
For a new threat, antivirus and antispyware software often cannot recognize it until the vendor
releases new signatures and updates are installed. In some cases, especially for threats with easily
identifiable characteristics, an IDPS can detect the new threat during this window of time because
IDPS administrators can write a custom signature for the IDPS. Antivirus and antispyware software
typically do not permit administrators to write signatures. Also, NBA software can often recognize
new worms by their anomalous traffic patterns.
8.3.3 Firewalls and Routers
Firewalls (network-based and host-based) and routers filter network traffic based on TCP/IP
characteristics such as the source and destination IP addresses, the transport layer protocol (e.g., TCP,
UDP, ICMP), and basic protocol information (e.g., TCP or UDP port numbers, ICMP type and code).
Most firewalls and routers log which connections or connection attempts they block; the blocked activity
is often generated by unauthorized access attempts from automated attack tools, port scanning, and
malware. Some network-based firewalls also act as proxies. When a proxy is used, each successful
connection attempt actually results in the creation of two separate connections: one between the client and
the proxy server, and another between the proxy server and the true destination. Many proxies are
application-specific, and some actually perform some analysis and validation of common application
protocols, such as HTTP. The proxy may reject client requests that appear to be invalid (which could
include some forms of attacks) and log information regarding these requests.
Ways in which firewalls and routers complement IDPSs include the following: 50
Network-based firewalls and routers often perform network address translation (NAT), which is the
process of mapping addresses on one network to addresses on another network. NAT is most often
accomplished by mapping private addresses from an internal network to one or more public addresses
on a network that is connected to the Internet. Firewalls and routers that perform NAT typically
record each NAT address and mapping. IDPS users may need to make use of this mapping
information to identify the actual IP address of a host behind a device performing NAT.
If IDPSs and other security controls (e.g., antivirus software) cannot stop a new network-borne threat,
such as a network service worm or denial of service attack, firewalls or routers might have to be
temporarily reconfigured to block the threat.
As mentioned in Sections 4 through 7, many IDPSs can reconfigure firewalls or routers to block
particular threats.
Routers are often used as data sources for NBA deployments.
50
Some firewalls and routers can run IDPS software. The discussion in this section addresses only the core capabilities of
firewalls and routers, not add-on IDPS capabilities.
8-6
Limitations of firewalls and routers in the context of IDPS include the following:
Firewalls and routers cannot detect most types of malicious activity.

Firewalls and routers typically log relatively little information, such as the basic characteristics of
denied connection attempts only, and they rarely record the content of any packets. NBA
technologies and some network-based IDPSs can log much more information about network traffic
than firewalls and routers do.
8.3.4 Honeypots
Some organizations are sufficiently concerned with detecting the earliest signs of widespread incidents,
such as major new worms, that they deploy deceptive measures such as honeypots so that they can collect
better data on these threats. Honeypots are hosts that have no authorized users other than the honeypot
administrators because they serve no business function; all activity directed at them is considered
suspicious. Attackers will scan and attack honeypots, giving administrators data on new trends and attack
tools, particularly malware. However, honeypots are a supplement to, not a replacement for, other
security controls such as intrusion detection and prevention systems. If honeypots are to be used by an
organization, qualified incident handlers and intrusion detection analysts should manage them. The
legality of honeypots has not been clearly established; therefore, organizations should carefully study the
legal ramifications before planning any honeypot deployments.
8.4 Summary
The four primary types of IDPS technologies—network-based, wireless, NBA, and host-based—each
offer fundamentally different information gathering, logging, detection, and prevention capabilities. Each
technology type offers benefits over the other, such as detecting some events that the others cannot and
detecting some events with significantly greater accuracy than the other technologies. Accordingly,
organizations should consider using multiple types of IDPS technologies to achieve more comprehensive
and accurate detection and prevention of malicious activity. In many environments, a robust IDPS
solution cannot be achieved without using multiple types of IDPS technologies. For most environments,
a combination of network-based and host-based IDPSs is needed for an effective IDPS solution. Wireless
IDPSs may also be needed if the organization determines that its wireless networks need additional
monitoring or if the organization wants to ensure that rogue wireless networks are not in use in the
organization’s facilities. NBA technologies can also be deployed if organizations desire additional
detection capabilities for DoS attacks, worms, and other threats that NBAs are particularly good at
detecting.
Organizations that are planning to use multiple types of IDPS technologies, or even multiple products
within a single IDPS technology class, should consider whether or not the IDPS products should be
integrated in some way. Direct IDPS integration is most often performed when an organization uses
multiple IDPS products from a single vendor, by having a single console that can be used to manage and
monitor the multiple products. Some products can also share data, which can speed the analysis process
and help users to better prioritize threats. A more limited form of direct IDPS integration is having one
IDPS product provide data for another IDPS product, such as a network-based IDPS providing network
flow information to an NBA sensor.
Indirect IDPS integration is usually performed with security information and event management (SIEM)
software, which is designed to import information from various security-related logs and correlate events
among them. SIEM software complements IDPSs in several ways, including correlating events logged by
different technologies, displaying data from many event sources, and providing supporting information
from other sources to help users verify the accuracy of IDPS alerts. An alternative to using SIEM
8-7
software for centralized logging is the syslog protocol, which provides a simple standard framework for
log generation, storage, and transfer that any IDPS can use if designed to do so. Syslog is very flexible
for log sources, because each syslog entry contains a content field into which logging sources can place
information in any format. However, this flexibility makes analysis of the log data challenging. Each
IDPS may use many different formats for its log message content, so a robust analysis program would
need to be familiar with each format and be able to extract the meaning of the data within the fields of
each format. Generally, the use of syslog for centralized collection and analysis of IDPS logs does not
provide sufficiently strong analysis capabilities to support incident identification and handling.
In addition to dedicated IDPSs, organizations typically have several other types of technologies that offer
some IDPS capabilities and complement, but do not replace, the primary IDPSs. These include network
forensic analysis tools, anti-malware technologies (antivirus software and antispyware software), and
firewalls and routers.
8-8
9. IDPS Product Selection
This section provides guidance on selecting IDPS products. It first discusses the identification of general
requirements that the IDPS products should meet. Next, it provides sets of criteria that can be used to
evaluate four aspects of IDPS technologies: security capabilities, performance, management, and life
cycle cost. Finally, the section concludes with a brief discussion of performing hands-on and paper
evaluations of products, and when each evaluation technique is most appropriate. This section assumes
that an organization has already determined that a particular type of IDPS technology—network-based,
wireless, network behavior analysis (NBA), or host-based—is needed. A comparison of the technology
types, which can be helpful for selecting the one most appropriate for a particular need, is provided in
Section 8.
Organizations should use risk management techniques to identify the security controls necessary to
mitigate risk to an acceptable level. Although it may be tempting to simply choose a product, using a risk
management process to choose the most effective blend of controls enhances an organization’s security
posture. An explanation of the risk management process is outside the scope of this document; NIST SP
800-30, Risk Management Guide for Information Technology Systems, contains additional information on
it.
9.1 General Requirements
Before evaluating IDPS products, organizations should first define the general requirements that the IDPS
solution and products should meet. The features provided by IDPS products and the methodologies that
they use vary considerably, so a product that best meets one organization’s requirements might not be
suitable for meeting another organization’s requirements. Also, a single IDPS product might not be able
to meet all of an organization’s requirements for a particular type of IDPS technology (e.g., network-
based), necessitating the use of multiple IDPS products of the same technology type. This is most
common for large environments and for environments in which IDPS technologies serve multiple
operational purposes.
9.1.1 System and Network Environments
Evaluators first need to understand the characteristics of the organization’s system and network
environments, so that an IDPS can be selected that will be compatible with them and able to monitor the
events of interest on the systems and/or networks. This knowledge is also needed to design the IDPS
solution and determine how many components (e.g., sensors, agents) will be needed and where they will
be deployed (e.g., which systems will run IDPS agents, which network segments will be monitored).
Characteristics to consider include the following:
Technical specifications of the IT environment. Examples are as follows:
– Network diagrams and maps specifying the architecture (both logical and geographical) of the
network, including all connections to other networks, and the number and locations of hosts
– The operating systems (OS), network services, and applications run by each host that might need
to be protected by the IDPS 51
– The attributes of non-security systems with which the IDPS might need to be integrated, such as
network management systems.
51
In some cases, particularly for some host-based IDPSs, it may also be necessary to identify the application versions that
need to be protected, so that it can be confirmed that the IDPS provides support for those versions.
9-1
Technical specifications of the existing security protections. Examples of relevant protections are
as follows:
– Existing IDPS implementations
– Centralized logging servers and SIEM software
– Antimalware software, such as antivirus and antispyware software
– Content filtering software, including antispam software
– Network firewalls, routers, proxies, and other packet filtering devices and software
– Communication encryption services, including link encryptors, virtual private networks (VPN),
and Secure Sockets Layer (SSL)/Transport Layer Security (TLS).
9.1.2 Goals and Objectives
After gaining an understanding of the existing system and network environments, evaluators should
articulate the technical, operational, and business goals and objectives they wish to attain by using an
IDPS. The following questions should be considered in this area:
The types of threats for which the IDPS should provide protection. Evaluators should state, as
specifically as possible, the concerns that the organization has regarding the types of threats that
originate both outside the organization and inside the organization (insider threats). Insider threats
should encompass not only users who attack the system from within, but also authorized users who
overstep their privileges, thereby violating organizational security policy or laws.
Any needs to monitor system and network usage for acceptable use violations or non-security
reasons. In some organizations, there are system use policies that target user behaviors that may be
considered personnel management rather than system security issues. These might include accessing
Web sites that provide content of questionable taste or value (such as pornography) or using the
organization’s systems to send email or other messages to harass individuals. Some IDPSs provide
features that accommodate detecting such events. Monitoring usage can also assist organizations in
determining when systems and networks are reaching capacity and might need to be upgraded or
replaced.
9.1.3 Security and Other IT Policies
Evaluators should review their existing security policies and other IT policies before selecting products.
The policies serve as a specification for many of the features that the IDPS products need to provide. 52
Examples of policy elements that can contain helpful information for IDPS product selection are as
follows:
The goals of the policies. It is helpful to articulate the goals outlined in the policies in terms of the
standard security goals (integrity, confidentiality, and availability) as well as more generic
management goals (privacy, protection from liability, manageability).
Reasonable use policies or other management provisions. As mentioned above, many
organizations have system use policies included as part of security policies and other IT policies.
52
If the existing policies do not provide enough information on what types of activity should be permitted or denied, it may be
necessary to revise the policies first before selecting an IDPS product to enforce the policies.
9-2
Processes for dealing with specific policy violations. It is helpful to have a clear idea of what the
organization wishes to do when an IDPS detects that a policy has been violated. If the organization
does not intend to react to such violations, it may not make sense to configure the IDPS to detect
them. If the organization wishes to respond to such violations, it may be necessary to select an IDPS
product that can detect them, and perhaps also perform automated responses to stop them.
9.1.4 External Requirements
Evaluators should understand if the organization is subject to oversight or review by another organization,
or if it is likely that the organization will be subject to an additional form of oversight in the near term. If
either is true, the evaluators should determine if that oversight authority requires IDPSs or other specific
security resources. Examples of external requirements are as follows:
Security-specific requirements levied by law. For example, there may be legal requirements to
protect personally identifiable information (such as earnings information or medical records) stored
on the systems. There could also be legal requirements for investigation of security violations that
divulge or endanger that information.
Audit requirements for security best practices or due diligence. The audit requirements may
specify functions that the IDPS must provide or support. Some IDPSs offer features to meet special
needs of certain industries or market niches, such as reports designed to meet legislative requirements
for health care or financial institutions.
System accreditation requirements. If the organization’s systems are subject to accreditation, the
evaluators should identify and consider the accreditation authority’s requirements for IDPS or other
security protection.
Requirements for law enforcement investigation and resolution of security incidents. They may
impose additional requirements on IDPS functions, especially those having to do with collection and
protection of IDPS logs as evidence.
Requirements to purchase products previously evaluated through an independent process. For
example, an organization might be required to or prefer to purchase products that hold a certain rating
from an evaluating body.
Cryptography requirements. For example, Federal agencies are required to purchase products that
use FIPS-approved encryption algorithms to protect network communications and storage of sensitive
data. Also, if any of the IDPS components will be deployed in other countries, evaluators should
consider any restrictions or limitations that might affect the deployment or use of cryptographic
components incorporated in the IDPS.
9.1.5 Resource Constraints
IDPSs can protect the systems of an organization, but at a price. It makes little sense to incur additional
expense for IDPS features if the organization does not have sufficient systems or personnel to use them.
Evaluators should consider the following:
The budget for acquisition and life cycle support of IDPS hardware, software, and
infrastructure. The total cost of ownership of IDPSs well exceeds acquisition costs. Other costs
may be associated with acquiring systems on which to run software components, deploying additional
networks, providing sufficient storage for IDPS data, obtaining specialized assistance in installing and
configuring the system, and training personnel. See Section 9.5 for additional information on life
cycle costs.
9-3
The staff needed to monitor and maintain an IDPS. Some IDPSs are designed under the
assumption that personnel will be available to monitor and maintain them around the clock. If
evaluators do not anticipate having such personnel available, they may wish to explore those systems
that accommodate less than full-time attendance or are designed for unattended use, or they could
consider the possibility of outsourcing the monitoring and possibly also the maintenance of the
IDPS. 53
9.2 Security Capability Requirements
In addition to defining general requirements, as described in Section 9.1, evaluators also need to define
more specialized sets of requirements. This section specifically addresses security capability
requirements. Sections 9.3 through 9.5 discuss performance, management, and life cycle cost
requirements, respectively. The criteria in these sections are presented as possible evaluation criteria and
are not intended to be used as-is for performing product evaluations. Instead, organizations could use
them as a basis for creating an organization-specific set of criteria that takes into account an
organization’s environment, policies, and existing security and network infrastructure. Section 9.6
provides additional information on performing IDPS evaluations.
Evaluating the security capabilities of each IDPS product is obviously very important. If the product
cannot provide the necessary capabilities, then it ultimately is insufficient as a security control alone, and
either a different product should be selected or the product should be used in conjunction with other
security controls, such as a different IDPS product. This section presents IDPS security capability
considerations in four categories: information gathering, logging, detection, and prevention. Section 9.6
provides guidance on collecting data on IDPS security capabilities as part of an evaluation.
Organizations should identify the information gathering capabilities needed for their IDPS’s detection
methodologies and analysis functions, and evaluate each IDPS product under consideration for its ability
to offer those capabilities. Information on information gathering capabilities for each type of IDPS
technology are presented in Sections 4 through 7.
Organizations should carefully examine the event and alert logging capabilities of each IDPS solution
being evaluated. The quality of logging, both completeness and precision, affects an organization’s
ability to perform analysis, confirm the accuracy of alerts, and correlate logged events with events
recorded by other sources (e.g., other security controls, OS logs). IDPS products should log basic
information at a minimum, such as a timestamp, the event type, the source of the event, and the sensor or
agent that detected the event. Each IDPS product should also log supporting data involving the details of
the event; these data fields are specific to particular IDPS product types, and common data fields are
listed in Sections 4 through 7. IDPS products should also provide a mechanism that allows users to
associate each log entry with corresponding external references, including Common Vulnerabilities and
53
If portions of the IDPS will be or might be outsourced, organizations should ensure that their product requirements reflect
outsourcing-specific requirements, such as limiting the actions that the outsourcers can perform and performing auditing of
their actions.
9-4
Exposures (CVE) numbers, 54 which provide universal identifiers for vulnerabilities, and possibly other
references such as vendor security advisories.
Organizations should carefully evaluate the detection capabilities of each IDPS solution being evaluated.
For many implementations, the detection capabilities are the most important function. Comparing
detection capabilities is a complex undertaking because each product typically performs detection of a
somewhat different set of events using different methodologies. Factors that organizations should
consider in their IDPS evaluations include the following:
Which types of activities it currently analyzes fully and analyzes partially, as well as future plans for
additional analysis capabilities. Examples are as follows:
– For network-based IDPS, a listing of the network, transport, and application layer protocols
analyzed, and an explanation of the amount of analysis performed on each (e.g., signature-based
detection, anomaly-based detection, stateful protocol analysis)
– For host-based IDPS, a listing of the specific resources that can be monitored (e.g., log files,
system files, network interfaces) and an explanation of how each is monitored (e.g., after-the-fact
detection of changes, active handling of file access requests, TCP/IP stack monitoring)
What types of incidents it can identify, such as denial of service [DoS] attacks, backdoors, policy
violations, port scans, malware (e.g., worms, Trojan horses, rootkits, malicious mobile code), and
unauthorized application/protocol use.
How comprehensive its detection is for each type of incident it can identify (e.g., how many worms,
how many types of DoS attacks).
How effective its default, out-of-the-box configuration is. When an IDPS is first activated, its default
settings should be reasonable. For example, signatures or policies that tend to generate large numbers
of false positives should be disabled, and signatures or policies that are reliable and identify important
recent attacks should be enabled. Detection thresholds (e.g., x instances in y minutes) should be set to
values that attempt to balance false positives and false negatives. Also, features that are particularly
resource-intensive should be disabled.
How effective it is at detecting known malicious events, such as attacks, scans, or malware.
Signature-based detection techniques typically perform better than anomaly detection and stateful
protocol analysis techniques in recognizing known events. This should include the IDPS’s ability to
state precisely which exploit was performed and which vulnerability was targeted (e.g., CVE
reference identifier).
How effective it is at detecting previously unknown malicious events, such as new attacks or variants
on existing attacks, without reconfiguring or updating the IDPS. Anomaly detection and stateful
protocol analysis techniques typically perform better than signature-based detection techniques in
recognizing unknown events.
How effective it is at detecting known and unknown malicious events that have been concealed
through evasion techniques. Examples of such techniques include unusual IP packet fragmentation,
non-standard application port use, and alternate character sets or other character encoding.
54
More information on CVE is available from NIST SP 800-51, Use of the Common Vulnerabilities and Exposures (CVE)
Vulnerability Naming Scheme, which is located at http://csrc.nist.gov/publications/nistpubs/, and the CVE Web site at
http://cve.mitre.org/.
9-5
How accurately it can determine the success or failure of attacks.

What response mechanisms it offers, excluding prevention responses (which are covered in Section
9.2.4). Examples include logging events (both locally and to remote log servers), displaying console
alerts, and sending Simple Network Management Protocol (SNMP) traps, e-mails, text messages, and
pages. The criterion also includes effective prioritization of events, such as taking different actions
when a certain type of event occurs or when an event involves a certain system or service.
How administrators can customize detection capabilities by modifying signatures, policies, and other
settings. Examples include altering whitelists, blacklists, and thresholds; customizing code to reduce
false positives or false negatives; and writing new signatures or policies from scratch or based on
samples or frameworks. Evaluators should consider how easily the customizations can be performed
(e.g., through a GUI, through editing text files). If the customizations require knowledge of a
programming language, additional considerations include the following:
– Is the language commonly used or is it a specialty/proprietary language that administrators would

need to learn?
– How complex and powerful is the language?
– Does the product offer a development environment or other tools to assist in customization, such
as syntax checking or virtual machines for testing customizations before implementing them?
– When the product is updated or upgraded, how are code customizations preserved?
How effectively the product can use data from other sources, such as vulnerability scan results and
logs from other IDPSs, to correlate events and improve the prioritization of alerts.
Organizations should determine whether or not the IDPS solution may need to perform prevention
actions, including future needs, and evaluate the prevention capabilities of each candidate product. Most
prevention capabilities are specific to a particular type of IDPS; information on common capabilities is
presented in Sections 4 through 7 for each IDPS product type. When available, it is generally preferred to
have a product that has multiple prevention capabilities instead of only one, because some methods are
more effective than others in certain situations and ineffective in others. All IDPS products should offer
considerable granularity in configuration options for prevention methods, such as enabling or disabling
them only for particular alerts, suppressing prevention methods for hosts on whitelists, and allowing
administrators to specify which prevention method should be used for each alert if multiple methods are
available. Some products offer additional granularity that may be beneficial, such as performing
prevention actions only if a certain system is being attacked.
9.3 Performance Requirements
Comparing the performance of IDPS products is challenging for the following reasons:
Performance is highly dependent on the configuration and tuning of each product. Although testing
can be performed using the default settings of each product, some products are designed with the
assumption that they will need extensive customization and tuning.
Performance and detection are often at odds; having more complex and robust detection capabilities
often causes poorer performance because they require more processing capability and memory.
9-6
Many IDPS components are appliance-based and have many hardware models and configurations
available, each with its own performance characteristics. Other IDPS components are not appliance-
based, so their hardware, OSs, and OS configurations may vary widely, which can all affect
performance.
There are no open standards for performance testing, nor are there publicly available, comprehensive,
up-to-date test suites.
Accordingly, evaluators should focus on the general performance characteristics of IDPS products and
avoid differentiating products by slight differences in reported performance capabilities. Vendors
typically rate their products by maximum capacity, such as the volume of network traffic or number of
packets per second monitored for network-based IDPS, the number of events monitored per second for
host-based IDPS, or the flows monitored per second or the number of hosts that can be profiled for NBA
systems. Section 9.6 provides guidance on collecting data on IDPS performance as part of an evaluation.
When evaluating maximum capacity claims, evaluators should consider the following questions:
Does the maximum capacity reflect activity that is being analyzed or activity that is being monitored
but not necessarily analyzed? For example, a network-based IDPS might perform little or no analysis
on the use of certain application protocols.
What was the nature of the activity used to measure capacity? This knowledge can help evaluators to
determine if the testing used an environment similar to their own or had significant differences that
could affect performance results. Aspects of this to consider include the following:
– How was the activity used for testing generated?
– What types of malicious activity were included in the testing? What percentage of the events
monitored by the IDPS was malicious? What percentage of the malicious events was detected by
the IDPS under maximum load?
– For network traffic, what protocols were used and in roughly what percentages? For host-based
activity, what applications were run, and what other sources of events were used?
– How closely did the activity used for testing reflect the actual conditions of the production
environment?
How was the IDPS configured? Was the default configuration used? If not, what detection
capabilities, logging capabilities, and other features were enabled or disabled from the default?
For any non-appliance components, what hardware, OSs, and applications or services were in use?
Who performed the testing?
When was the testing performed?
Evaluators should also consider the performance features that each IDPS under consideration offers.
Possible considerations for performance features include the following:
Does the IDPS offer any performance tuning features, either manually configured or automatically
implemented? For example, if an IDPS is being overwhelmed by high volumes of activity, can it
alter its detection capabilities so that it temporarily performs less extensive analysis on all the traffic
or stops analyzing low-risk traffic?
9-7
For products that track state (e.g., stateful protocol analysis of network connections), how many
activities (e.g., connections) can they track state for simultaneously? How long is state information
maintained normally and under maximum load?
For products that process the actual events, not copies of the events (e.g., inline network-based IDPS
sensors), how much latency does the processing cause? For example, there might be a delay of 50
microseconds between when a network-based IDPS sensor receives a packet and when the IDPS
retransmits that packet to continue to its destination. A host-based IDPS might delay the execution of
system calls for a similarly short time. Under high loads, IDPS products might experience
significantly higher latency, so it is important to consider latency under both typical and extreme
loads.
For products that process copies of events, not the actual events (e.g., passive network-based IDPS
sensors, NBA software analyzing network flow logs sent by routers), how long does it take from the
occurrence of an event to the event’s detection and reporting by the IDPS?
9.4 Management Requirements
Evaluating the management capabilities of each IDPS product is very important because if a product is
hard to manage or does not offer the necessary management functionality, then it is likely that the product
will not be used as effectively as originally intended. This section presents IDPS management capability
considerations in three categories:
Design and implementation

Operation and maintenance
Training, documentation, and technical support.
Section 9.6 provides guidance on collecting data on IDPS management capabilities as part of an
evaluation.
9.4.1 Design and Implementation
Most aspects of IDPS design and implementation are specific to each IDPS technology type; Sections 4
through 7 contain detailed information on design and implementation considerations. In addition to
those, organizations should also consider general criteria related to reliability, interoperability, scalability,
and security.
9.4.1.1 Reliability
Organizations should ensure that the IDPS products they select will be sufficiently reliable to meet their
requirements. Possible considerations for reliability include the following:
What types of redundant hardware are included or available separately for appliances, such as
duplicate power supplies, network interface cards, storage devices (e.g., hard drives, flash ROMs),
and CPUs?
What software redundancy features are incorporated into the products, especially for agents and
sensors, such as the product automatically restarting itself and/or supporting services when they fail?
Can the product use multiple management servers so that if one fails, sensors or agents automatically
fail over to another one? How disruptive is the failover process?
9-8
Can multiple sensors be deployed to monitor the same activity so that if one fails, another
automatically assumes its responsibilities? How disruptive is the failover process (e.g., loss of state
tracking, loss of event counts for thresholds)?
If a sensor fails, how easily can its configuration be transferred to another sensor (e.g., transferring a
sensor CD and configuration floppy from the first sensor to the second sensor, then rebooting the
second sensor)?
9.4.1.2 Interoperability
Organizations should ensure that the IDPS products they select will interoperate effectively with the
desired systems. These systems could include the following:
Data input sources, such as other IDPS products, log files, and vulnerability scanning results
Log analysis and management software, such as syslog and other logging servers, SIEM software,
and network management software
Systems to be reconfigured by prevention actions, such as firewalls and routers.
9.4.1.3 Scalability
When evaluating IDPS products, organizations should consider not only their current needs, but also
possible future needs, so that they choose products that are sufficiently scalable. Possible considerations
for scalability include the following:
The number of sensors or agents, management servers, consoles, and other IDPS components that can
be part of a single logical implementation
The number of sensors or agents that a single management server can support
The range of appliances available for appliance-based IDPS components (e.g., appliance devices with
varying capacities), and the ability to expand appliances (e.g., add more memory, network interface
cards [NIC], or storage devices)
How multiple sensors or agents can share monitoring functions for a network or system, including
how load balancing can be performed with or without the use of separate load balancing devices
How many networks a network-based, wireless, or NBA sensor can monitor simultaneously; how
many network interfaces a host-based agent can monitor simultaneously
How the IDPS’s storage capabilities can be expanded and enhanced (e.g., automated archival of older
data, use of separate storage devices)
What levels of activity (e.g., network traffic, system calls, log entries) each of the IDPS components
can support
How well the IDPS solution integrates the management and monitoring of multiple sensors or agents,
management servers, and other components
The cost of and resources needed for each scalability option.
9-9
9.4.1.4 Security
When evaluating IDPS products, organizations should consider the security requirements for the IDPS
solution itself. Evaluators should review the security controls listed in NIST SP 800-53, Recommended
Security Controls for Federal Information Systems and consider which controls should be included in the
IDPS security criteria. Examples of security considerations include the following:
How stored data (including logs) and communications among all the IDPS components are protected,
such as using alternate data channels or FIPS-approved encryption and digital signature algorithms to
support data confidentiality and integrity when needed
The authentication, access control, and auditing features performed for IDPS usage and
administration
The IDPS’s resistance to attacks against it, such as blinding and DoS attacks.
This criterion focuses on requirements for the user and administrator interfaces for ongoing management
of the IDPS. This includes the ease of performing daily monitoring, analysis, and reporting activities;
managing and maintaining the IDPS; and applying updates. Possible specific criteria for each of these
areas is provided below. In addition, evaluators should consult with vendors, analysts, and/or trusted
peers to determine the level of technical and security expertise needed to use and maintain each product.
Evaluators should ask vendors what their assumptions are regarding the users and administrators of their
products.
9.4.2.1 Daily Use
Organizations should consider how the IDPS solution needs to be used on a daily basis for monitoring
security events, performing analysis of events of interest, and generating reports. Because these three
activities are often intertwined, it is often easiest to assess them together. Daily use considerations for
IDPSs should include the following:
How it displays events and alerts to users, what features it provides to ease analysis (e.g., drill-down
capability, links to supporting information, correlation of events from multiple sensors or agents,
color-coding alerts to indicate their severity/priority), and how users can customize the views and
filters to alter the display of events and alerts
How it displays its status information to users and administrators (e.g., how a sensor failure is
communicated)
How it notifies users and administrators of both serious security events and IDPS failures and other
operational problems
How much supporting information it records for events (e.g., is enough information recorded to allow
analysts to determine what happened?)
How many interfaces/programs are needed for the daily use functions (e.g., can a single GUI provide
all the functions that the IDPS users need?)
How many concurrent interfaces are supported
9-10
What default report formats are offered (e.g., text, comma-separated values [CSV], HTML,
Extensible Markup Language [XML], PDF, Microsoft Word, Microsoft Excel) and what data storage
formats are supported for IDPS data, log, and report retention
How reports can be customized (both altering existing reports and creating new reports)
Whether or not reports can be generated automatically (e.g., on a schedule, when certain events
occur), how the reports can be distributed (e.g., e-mailed to administrators), and how the distributed
reports are protected (e.g., file encryption)
Whether or not it offers any workflow tracking capabilities, such as incident tracking.
9.4.2.2 Maintenance
Organizations should consider how the IDPS solution and its components should be maintained, and then
evaluate products based on those maintenance requirements. Maintenance considerations should include
the following:
Whether or not sensors or agents can be managed both independently and through a management
server, and whether such accesses are logged
What local and remote maintenance mechanisms are available (e.g., locally installed GUI, Web-based
console, command-line interface [CLI], third-party tools), and what differences there are (if any) in
their functionality
Which components can be maintained locally and remotely with each maintenance mechanism
What security protections are provided for each maintenance mechanism (e.g., strong encryption for
network traffic)
How component configuration settings can be backed up and restored, and how they can be
transferred from a component to a replacement component (e.g., swapping sensor appliances because
of hardware failure)
How robust the product is at logging component status information (e.g., low disk space, high CPU
utilization), operational failures, and other events that may necessitate maintenance actions
Whether or not the IDPS provides sufficiently robust log management tools, and if not, how
administrators could compensate (e.g., write scripts, acquire third-party tools).
9.4.2.3 Updates
Organizations should carefully consider how the vendor of each evaluated IDPS product releases updates
for it. Aspects of this to consider include the following:
How often regular major and minor updates to each component are released (e.g., sensors,
management servers, consoles)
How often updates to detection capabilities are released in response to major new threats, and how
soon after the identification of a new threat the corresponding update is typically available
Which types of updates usually or sometimes require that IDPS components be rebooted or restarted
9-11
How the organization receives each type of update from the vendor (e.g., sensor upgrade distributed
on CD, signature updates available for download through the console or from the vendor’s technical
support Web site)
How the authenticity and integrity of updates can be confirmed (e.g., through cryptographic
checksums)
How updates can be distributed to IDPS components such as sensors and consoles (e.g., automated
process, manual installation)
How the installation of updates can affect existing IDPS settings or customizations.
9.4.3 Training, Documentation, and Technical Support
Organizations should consider the resources available to the IDPS administrators and users for learning
about the IDPS’s functionality and characteristics and for receiving assistance when problems occur.
These resources—training, documentation, and technical support—should take into account both
administrator and user needs, as well as different experience levels.
Training. Most IDPS vendors offer training classes for their products. Some offer a single class per
product, while others offer separate classes for users and administrators. Separate classes may also be
available for particular IDPS components, such as consoles or management servers, or for specialized
tasks such as code customization or report creation. Some vendors also offer general IDPS classes
that are intended to give users a better understanding of IDPS principles. Third parties also offer
general IDPS classes and classes for some specific IDPS products. Organizations should consider
which training classes are available that meet their needs, what format the classes are in (e.g.,
instructor-led, online, computer-based training [CBT]), and where the classes are held (e.g., the IDPS
vendor’s headquarters, regional locations, the customer’s site). For instructor-led classes,
organizations should determine if they include lab work or other hands-on exercises that allow users
to use the actual IDPS equipment.
Documentation. IDPS products usually include documentation in paper or electronic forms.
Examples include installation, user, administrator, and signature/policy development guides.
Electronic guides are often fully searchable; some products also offer context-sensitive help through
the console, allowing a user to easily access the pertinent documentation for a particular console
feature or security event type. If guides are provided on paper only, organizations should determine if
the guides can be duplicated, and if not, what the availability of additional copies is.
Technical Support. Most IDPS vendors offer multiple technical support contracts. For example,
one contract might provide basic phone, e-mail, and Web-based support during business hours with a
one-hour response time, while another contract might provide 24-hour access to senior support staff
with a 15-minute response time and include annual onsite visits and consulting services.
Organizations should take care to determine what activities are and are not covered by a contract; for
example, tuning and customization, such as writing signatures or customizing reports, might not be
included. Vendors typically provide multiple support contract options so that each customer can
select one that is cost-effective for them. Free technical support is also available for some products
through user groups, mailing lists, forums, and other methods.
9.5 Life Cycle Costs
Organizations should compare the funding they have available for IDPS solutions to the estimated life
cycle costs for each of the evaluated solutions. Quantifying the life cycle costs for IDPS solutions can be
difficult because there are many environment-specific factors that impact cost, and because it is usually
9-12
challenging to capture the cost benefits provided by IDPSs. The criteria presented below focus on the
basic costs of the IDPS solution itself and do not take into account any cost savings achieved by IDPS
use.
Initial Costs. The initial costs of acquiring and deploying a solution typically include the following:
– Hardware, including appliances, additional network equipment (e.g., management network,

network taps, IDS load balancers), and hosts for non-appliance components (e.g., consoles)
– Software and software licensing fees for IDPS components and supporting software (e.g.,
reporting tools, database software)
– Installation and initial configuration costs, which could include external assistance as well as
internal labor
– Customization costs, such as having programmers develop custom scripts or reports
– Training costs, if the necessary training is not included as part of the initial hardware and
software purchase.
Maintenance Costs. Expected maintenance costs for IDPS solutions typically include the following:
– Labor. This includes the cost of staff performing IDPS administration and analysis.
– Software licensing fees, subscription fees, or maintenance contracts. These costs, typically
incurred on an annual basis, usually provide the purchaser with IDPS software and signature
updates.
– Technical support fees. Many organizations purchase technical support contracts for their IDPS
products; these contracts are typically annual. Some organizations pay a fee per technical support
call instead of an annual contract.
– Training costs. Training might be needed periodically in preparation for deploying new versions
of an IDPS product, as well as for new IDPS users and administrators. Organizations might want
to have customized training classes that focus on the elements of the IDPS product that are most
important to the organization, and also take into account certain aspects of the organization’s
environment and needs.
– Customization costs. During the use of an IDPS product, users and administrators might need the
product to be further customized, such as having programmers develop additional custom reports
or modify existing reports, and having programmers or administrators create custom analyzers
and signatures.
– Professional services or technical support that falls outside the technical support contract.
Examples include designing IDPS implementations, performing product installations, tuning
sensors or agents, creating and customizing reports, and assisting with incident response efforts.
Organizations can perform these services themselves, or they can purchase services from IDPS
vendors and third parties.
9.6 Evaluating Products
After collecting requirements and selecting criteria, evaluators need to find sources of information about
the products to be evaluated. Common product data sources include the following:
9-13
Test lab or real-world environment testing of selected IDPS products

Previous real-world experience with IDPSs from individuals within the organization and trusted
individuals at other organizations
Vendor-provided information, such as product manuals and datasheets, whitepapers, product
demonstrations, and discussions with vendor employees
Third-party product reviews, including reviews of individual products and comparisons of multiple
products.
Section 9.6.1describes the challenges in performing IDPS product testing as part of an evaluation.
Section 9.6.2 presents recommendations for using the data sources described above when conducting an
evaluation.
9.6.1 IDPS Testing Challenges
An organization performing its own in-depth hands-on testing of IDPS products ideally could generate
comprehensive data on the products that would accurately reflect how well-suited each product is to
meeting the organization’s needs. However, this is generally not feasible to achieve because of how
difficult and resource-intensive it is to perform IDPS testing well. The following are some of the major
reasons for these problems: 55
Test Methodology. There is no standard methodology for performing IDPS testing. Also, details are
not available for most of the methodologies used for commercial evaluation of IDPS products.
Organizations performing IDPS testing need to create their own methodologies or perform a survey
of existing methodologies, determine which would be best for their needs, and then design and
implement testing processes using the selected methodology. Also, a different methodology,
including test environments and test suites, is needed for each type of IDPS technology.
Multiple Environments. Organizations performing IDPS testing should conduct it in both real-
world and lab environments. The real-world testing helps evaluators to understand how well the
product will likely function in their environment. The lab testing allows evaluators to better assess
the detection and prevention capabilities of the product. Detection results can be difficult to
understand when real-world activity is being monitored because the real-world activity is likely to
contain different types of malicious activity, and it is sometimes unclear whether or not the detected
activity was actually malicious. Prevention capabilities are generally not tested in real-world
environments because they can easily cause disruptions to benign activity. It is very difficult to
duplicate real-world environments in lab environments, so organizations performing IDPS testing
generally need to do their testing separately in each environment.
Test Availability. There are no standard IDPS test suites available. Organizations performing IDPS
testing need to find ways to generate both malicious activity (to see how well the products identify
them) and benign activity (to put the product under normal or heavy loads). The malicious activity
should accurately reflect the composition of recent threats against the organization’s systems and
networks; accordingly, it can take considerable time to identify those threats and acquire tests for
them. The tests also need to take into account all detection methodologies used by the IDPSs,
because usually different types of tests are needed to properly evaluate the effectiveness of each
55
For more information on the challenges of IDPS testing, see NIST Interagency Report (IR) 7007, An Overview of Issues in
Testing Intrusion Detection Systems. It is available at http://csrc.nist.gov/publications/nistir/nistir-7007.pdf. Although it is
focused primarily on testing network-based IDPSs, most of the testing problems it discusses are applicable to testing any
type of IDPS technology.
9-14
methodology. 56 Typically it takes a combination of carefully selected tools and custom-written attack
scripts to build a reasonable test suite. Each tool and script should be reviewed and tested to ensure
that it performs the tests properly.
Lab Environment Resources. Organizations performing IDPS testing in lab environments typically
need to expend considerable resources in setting up the lab environments. Attacker and victim
systems need to be set up and configured. The victim systems need to run the OSs, services, and
applications targeted by the attacks. Depending on the methodologies used by the IDPSs, the victim
systems may need to have all the vulnerabilities exploited by the attacks. Some IDPSs might alert
only on attacks that they think will be successful; also, some attacks will stop executing if they do not
detect exploitable vulnerabilities. Evaluators also need to be aware of the capabilities of the IDPSs;
for example, an IDPS might see a few attacks from a single attacker system and automatically
perform prevention actions to stop all future attacks from that system.
Product Equivalence. Most IDPS products need to be tuned and customized to meet the
requirements of the organization. Each product is configured somewhat differently by default, so
organizations performing IDPS testing should attempt to tune and customize the products so that they
are as similar as possible. For example, thresholds such as the number of failed login attempts
permitted in a certain time period should be set to the same values. Also, each detection feature
should be enabled or disabled consistently on all the IDPSs. This is often very difficult to
accomplish—for example, a product performing signature-based detection tends to have settings
based on specific exploits being performed, while a product performing stateful protocol analysis
detection often has settings based on specific vulnerabilities being exploited. Evaluators would need
to map the exploits and vulnerabilities to determine the equivalent settings on different IDPSs.
9.6.2 Recommendations for Performing IDPS Evaluations
The challenges in performing in-depth hands-on IDPS testing often make it infeasible; however,
performing some amount of IDPS testing is generally quite helpful in evaluating how well IDPSs meet an
organization’s requirements for security capabilities, performance, and operation and maintenance. IDPS
testing is also helpful in setting realistic expectations for the capabilities of the products and the amount
of labor required to maintain and monitor them in the organization’s environment. Accordingly,
organizations should consider using a combination of several data sources, such as limited product
testing, vendor-provided information, third-party product reviews, and individuals’ previous IDPS
experience, when performing IDPS product evaluations. For example, organizations could use data
sources other than product testing to narrow the product selection to only a few choices, and then perform
limited testing of those choices only. In some cases, omitting product testing and performing a paper-
only evaluation of a product is necessary because of time and resource constraints, but generally an
evaluation will produce better results if it incorporates at least some product testing.
When using data from other parties, organizations should consider the fidelity of the data. Data is often
presented without a detailed explanation of how it was created, such as maximum capacities or detection
accuracy rates. Because there are no standard methodologies for compiling such data, organizations
should be cautious when comparing data from different sources, because the measurements may have
been performed using fundamentally different methods.
When performing hands-on IDPS testing, organizations should focus on those testing methods that are
most likely to be valuable. Testers should also avoid disrupting the organization’s operations. The
following provides guidance on performing testing for each class of IDPS product. After testing has been
56
Another complicating factor is that it is often not apparent which methodologies particular products use, so it might be
difficult to determine which types of tests are needed.
9-15
completed, testers should ensure that any hardware on loan from IDPS vendors has its writable media
sanitized appropriately to remove the organization’s data. 57
9.6.2.1 Network-Based
Valuable insights into network-based IDPS security capabilities (especially detection accuracy and
tuning), performance with the organization’s network traffic, and the operation and maintenance of the
IDPS can be gained by performing real-world testing of the IDPS. However, it is generally prudent to
keep the IDPS somewhat separate from the production environment during this testing so that the IDPS
does not adversely affect it (e.g., increase latency) and so that any vulnerabilities in the IDPS cannot be
exploited by attackers. An IDS load balancer is ideal for giving multiple sensors identical copies of the
network traffic simultaneously, allowing for side-by-side comparisons of the products, while isolating the
sensors and preventing them from inadvertently disrupting production (traffic passes through a load
balancer in only one direction). Depending on the network architecture, it may be possible to test sensors
in inline deployments by duplicating traffic at the network locations where each of an inline sensor’s
network interfaces would be and feeding that traffic to the inline sensors’ interfaces. Otherwise, most
inline sensors can be placed into a passive mode and tested as passive; the benefit of testing them with
production traffic in inline mode is to study their performance.
Lab testing of network-based IDPSs is most beneficial for evaluating the following:
The prevention capabilities of products. Testers can set up test systems (targets and attacking
systems), generate attacks, and monitor the effectiveness of each IDPS’s prevention actions.
The performance of inline sensor deployments. If this cannot be done as part of real-world testing,
testers could use network traffic generation tools or replay previously recorded traffic to generate
activity to pass through the sensor.
Design and implementation-related characteristics. Product reliability could be tested by
deploying multiple sensors or management servers, configuring them for failover conditions,
generating traffic for them to process, and then intentionally causing a failure of one component and
monitoring the resulting product behavior. Interoperability could be tested by configuring test
systems representing the products with which the IDPS must interoperate, and then generating
activity that should cause the products to work together. The security of the IDPS itself can also be
tested through vulnerability scanning, penetration testing, and other methods.
9.6.2.2 Wireless
The methods to be used for testing wireless IDPSs should be selected primarily by the format of the
wireless IDPS sensors to be tested:
Mobile sensors, fixed sensors, and sensors bundled with APs. 58 Testing of security capabilities,
performance, and some facets of operation and maintenance can typically be performed by using the
sensors in production environments, with the caveat that prevention capabilities should be disabled.
Prevention capabilities could be evaluated in an isolated test environment that is out of range of all
other wireless local area networks. This test environment would contain test access points and test
wireless clients using the access points; testers might need to set up test systems that the wireless
57
For more information on media sanitization, see NIST SP 800-88, Guidelines for Media Sanitization, which is available at
http://csrc.nist.gov/publications/nistpubs/.
58
For sensors bundled with APs, these test instructions assume that a non-production AP is used for the testing. Deploying
sensor software onto production APs for testing purposes is not recommended because it could disrupt the production
environment.
9-16
clients can access to generate wireless network communications. Attacks can be issued from one or
more wireless clients, and rogue access points can be deployed in the test environment. If the sensors
will be integrated with an IDPS infrastructure, any testing of this should also be performed in the test
environment to evaluate performance, operation and maintenance, and design and implementation
characteristics without jeopardizing the production infrastructure (e.g., an IDPS sensor could have
vulnerabilities that could be exploited by attackers within range of the sensor).
Sensors bundled with wireless switches. Generally, this testing should be performed by setting up a
test switch with sensor software in a test environment like the one described above for other types of
wireless sensors. The same type of testing described above should be performed.
9.6.2.3 NBA
If the NBA products will be directly monitoring network traffic, then real-world and lab testing of that
capability should be performed based on the guidance given for testing network-based IDPSs. If the
NBA products will be monitoring network flow logs from other devices, the preferred method for real-
world testing of that capability is to set up a separate network and forward the logs from the devices over
that network to the NBA sensors. This protects the NBA solution and allows the bandwidth used by the
solution to be measured easily. If the production networks will be used instead of a separate network,
testers need to be very careful not to overwhelm the production networks with the volume of logs,
particularly if multiple NBA products are being tested simultaneously. Testing can also be performed in a
lab environment by providing copies of production logs to the NBA products. NBA product lab testing is
also beneficial for the same reasons cited for network-based IDPS lab testing: evaluating prevention
capabilities, inline sensor performance, and product design and implementation-related characteristics.
9.6.2.4 Host-Based
Host-based IDPSs are typically more challenging to perform real-world testing for than any other type of
IDPS. Agents alter the hosts that they monitor and can adversely affect their performance and
functionality (e.g., IDPS shims interfering with other applications); appliance-based IDPSs are deployed
inline in front of production systems. The methods to be used for testing host-based IDPSs should be
selected primarily by the roles of the hosts to be protected:
A server (including a single application service on a server). Testing should be performed in a test
environment only. For example, a test server could be created that mimics a production server or
even uses one of its backups. Typical activity directed at the server, both benign and malicious,
should be generated by test systems (e.g., scripts or tools to create HTTP requests) and monitored by
the host-based IDPS. Testers can perform attacks against the server and monitor the prevention
actions performed without endangering any production systems. Testers can also measure the impact
of the host-based IDPS on the performance of the server and evaluate the reliability and security of
the host-based IDPS by attempting to disrupt it.
A client host (desktop or laptop). Initial testing should be performed in a test environment to
identify major performance and functionality problems that host-based IDPSs might introduce. The
reliability and security of the IDPS can also be evaluated in a test environment. Testing of agents’
security capabilities, prevention actions, and other characteristics can be conducted in both a test
environment and a production environment because the risk posed by IDPS failure to the production
environment is very low. Attacks should only be issued against the hosts in a test environment, while
the agents’ behavior against benign activity can be tested most easily in a real-world environment.
For example, a few of the testers might volunteer to have IDPS agents installed on their production
desktops and document the agents’ behavior and any problems they cause for a week or two. This
provides true real-world testing of the agents. For agents that necessitate user interaction, such as
9-17
responding to queries about permitting or denying activity, conducting end user testing in a test or
production environment is also prudent.
When testing host-based IDPSs, organizations should test the most commonly used and important OSs
and applications that need to be protected. The architecture of each OS and each application is different,
so a single product might exhibit significantly different behavior when used on different platforms.
9.7 Summary
Before evaluating IDPS products, organizations should first define the general requirements that the
products should meet. The features provided by IDPS products and the methodologies that they use vary
considerably, so a product that best meets one organization’s requirements might not be suitable for
meeting another organization’s requirements. Evaluators first need to understand the characteristics of
the organization’s system and network environments and plans for near-term changes, so that an IDPS
can be selected that will be compatible with them and able to monitor the events of interest on the systems
and/or networks. This knowledge is also needed to design the IDPS solution. After gaining an
understanding of the existing system and network environments, evaluators should articulate the goals
and objectives they wish to attain by using an IDPS. Evaluators should also review their existing security
and other IT policies before selecting products. The policies serve as a specification for many of the
features that the IDPS products need to provide. In addition, evaluators should understand whether or not
the organization is subject to oversight or review by another organization. If so, they should determine if
that oversight authority requires IDPSs or other specific system security resources. Resource constraints
should also be taken into consideration by evaluators.
In addition to defining general requirements, evaluators also need to define more specialized sets of
requirements:
Security capabilities, including information gathering, logging, detection, and prevention

Performance, including maximum capacity and performance features
Management, including design and implementation, operation and maintenance, and training,
documentation, and technical support
Life cycle costs, both initial and maintenance costs.
Organizations could use these criteria as a basis for creating an organization-specific set of criteria that
takes into account an organization’s environment, policies, and existing security and network
infrastructure. After collecting requirements and selecting criteria, evaluators need to find viable sources
of information about the products to be evaluated. Common product data sources include test lab or real-
world product testing, vendor-provided information, third-party product reviews, and previous IDPS
experience from individuals within the organization and trusted individuals at other organizations.
There are major challenges in performing in-depth hands-on IDPS testing with satisfactory results, which
often make it infeasible. Most organizations find the results of limited IDPS testing helpful for evaluating
daily use, interoperability, and security requirements. Organizations should consider using a combination
of several data sources when performing IDPS product evaluations. When using data from other parties,
organizations should consider the fidelity of the data because it is often presented without an explanation
of how it was generated. When performing hands-on IDPS testing, organizations should focus on those
testing methods that are most likely to be valuable and should avoid methods that are more likely to
disrupt the organization’s operations.
9-18
Appendix A—Glossary
Selected terms used in the Guide to Intrusion Detection and Prevention Systems (IDPS) are defined
below.
Agent: A host-based intrusion detection and prevention program that monitors and analyzes activity and
may also perform prevention actions.
Alert: A notification of an important observed event.
Anomaly-Based Detection: The process of comparing definitions of what activity is considered normal
against observed events to identify significant deviations.
Antivirus Software: A program that monitors a computer or network to identify all major types of
malware and prevent or contain malware incidents.
Application-Based Intrusion Detection and Prevention System: A host-based intrusion detection and
prevention system that performs monitoring for a specific application service only, such as a Web server
program or a database server program.
Blacklist: A list of discrete entities, such as hosts or applications, that have been previously determined
to be associated with malicious activity.
Blinding: Generating network traffic that is likely to trigger many alerts in a short period of time, to
conceal alerts triggered by a “real” attack performed simultaneously.
Channel Scanning: Changing the channel being monitored by a wireless intrusion detection and
prevention system.
Console: A program that provides user and administrator interfaces to an intrusion detection and
prevention system.
Database Server: A repository for event information recorded by sensors, agents, or management
servers.
Evasion: Modifying the format or timing of malicious activity so that its appearance changes but its
effect on the target is the same.
False Negative: An instance in which an intrusion detection and prevention technology fails to identify
malicious activity as being such.
False Positive: An instance in which an intrusion detection and prevention technology incorrectly
identifies benign activity as being malicious.
Flooding: Sending large numbers of messages to a host or network at a high rate. In this publication, it
specifically refers to wireless access points.
Flow: A particular network communication session occurring between hosts.
Host-Based Intrusion Detection and Prevention System: A program that monitors the characteristics
of a single host and the events occurring within that host to identify and stop suspicious activity.
A-1
Incident: A violation or imminent threat of violation of computer security policies, acceptable use
policies, or standard security practices.
Inline Sensor: A sensor deployed so that the network traffic it is monitoring must pass through it.
Intrusion Detection: The process of monitoring the events occurring in a computer system or network
and analyzing them for signs of possible incidents.
Intrusion Detection and Prevention: The process of monitoring the events occurring in a computer
system or network, analyzing them for signs of possible incidents, and attempting to stop detected
possible incidents. See also “intrusion prevention”.
Intrusion Detection System Load Balancer: A device that aggregates and directs network traffic to
monitoring systems, such as intrusion detection and prevention sensors.
Intrusion Detection System: Software that automates the intrusion detection process.
Intrusion Prevention: The process of monitoring the events occurring in a computer system or network,
analyzing them for signs of possible incidents, and attempting to stop detected possible incidents. See
also “intrusion detection and prevention”.
Intrusion Prevention System: Software that has all the capabilities of an intrusion detection system and
can also attempt to stop possible incidents. Also called an intrusion detection and prevention system.
Jamming: Emitting electromagnetic energy on a wireless network’s frequencies to make them unusable
by the network.
Malware: A program that is inserted into a system, usually covertly, with the intent of compromising the
confidentiality, integrity, or availability of the victim’s data, applications, or operating system or of
otherwise annoying or disrupting the victim.
Management Network: A separate network strictly designed for security software management.
Management Server: A centralized device that receives information from sensors or agents and
manages them.
Network-Based Intrusion Detection and Prevention System: An intrusion detection and prevention
system that monitors network traffic for particular network segments or devices and analyzes the network
and application protocol activity to identify and stop suspicious activity.
Network Behavior Analysis System: An intrusion detection and prevention system that examines
network traffic to identify and stop threats that generate unusual traffic flows.
Network Tap: A direct connection between a sensor and the physical network media itself, such as a
fiber optic cable.
Passive Fingerprinting: Analyzing packet headers for certain unusual characteristics or combinations of
characteristics that are exhibited by particular operating systems or applications.
Passive Sensor: A sensor that is deployed so that it monitors a copy of the actual network traffic.
A-2
Promiscuous Mode: A configuration setting for a network interface card that causes it to accept all
incoming packets that it sees, regardless of their intended destinations.
Sensor: An intrusion detection and prevention system component that monitors and analyzes network
activity and may also perform prevention actions.
Shim: A layer of host-based intrusion detection and prevention code placed between existing layers of
code on a host that intercepts data and analyzes it.
Signature: A pattern that corresponds to a known threat.
Signature-Based Detection: The process of comparing signatures against observed events to identify
possible incidents.
Spanning Port: A switch port that can see all network traffic going through the switch.
Stateful Protocol Analysis: The process of comparing predetermined profiles of generally accepted
definitions of benign protocol activity for each protocol state against observed events to identify
deviations.
Stealth Mode: Operating an intrusion detection and prevention sensor without IP addresses assigned to
its monitoring network interfaces.
Threshold: A value that sets the limit between normal and abnormal behavior.
Triangulation: Identifying the physical location of a detected threat against a wireless network by
estimating the threat’s approximate distance from multiple wireless sensors by the strength of the threat’s
signal received by each sensor, then calculating the physical location at which the threat would be the
estimated distance from each sensor.
Tuning: Altering the configuration of an intrusion detection and prevention system to improve its
detection accuracy.
Whitelist: A list of discrete entities, such as hosts or applications, that are known to be benign.
Wireless Intrusion Detection and Prevention System: An intrusion detection and prevention system
that monitors wireless network traffic and analyzes its wireless networking protocols to identify and stop
suspicious activity involving the protocols themselves.
A-3
A-4
Appendix B—Acronyms
Selected acronyms used in the Guide to Intrusion Detection and Prevention Systems (IDPS) are defined
below.
AP Access Point
ARP Address Resolution Protocol
CAIDA Cooperative Association for Internet Data Analysis

CIAC Computer Incident Advisory Capability
CLI Command-Line Interface
CMVP Cryptographic Module Validation Program
COM Component Object Model
CPU Central Processing Unit
CSIRT Computer Security Incident Response Team
CSRC Computer Security Resource Center
CSV Comma Separated Values
CVE Common Vulnerabilities and Exposures
DDoS Distributed Denial of Service

DHCP Dynamic Host Configuration Protocol
DLL Dynamic Link Library
DMZ Demilitarized Zone
DNS Domain Name System
DoS Denial of Service
DS Distribution System
DShield Distributed Intrusion Detection System
EICAR European Institute for Computer Antivirus Research

ESP Encapsulating Security Payload
FIPS Federal Information Processing Standards

FISMA Federal Information Security Management Act
FTP File Transfer Protocol
GHz Gigahertz
GUI Graphical User Interface
HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol over SSL
ICMP Internet Control Message Protocol

IDPS Intrusion Detection and Prevention System
IDS Intrusion Detection System
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IGMP Internet Group Management Protocol
IM Instant Messaging
IMAP Internet Message Access Protocol
IP Internet Protocol
IPS Intrusion Prevention System
B-1
IPsec Internet Protocol Security

IRC Internet Relay Chat
ISC Internet Storm Center
IT Information Technology
ITL Information Technology Laboratory
LAN Local Area Network
MAC Media Access Control
NBA Network Behavior Analysis

NBAD Network Behavior Anomaly Detection
NFAT Network Forensic Analysis Tool
NFS Network File System
NIC Network Interface Card
NIST National Institute of Standards and Technology
NTP Network Time Protocol
NVD National Vulnerability Database
OMB Office of Management and Budget

OS Operating System
PDA Personal Digital Assistant

PoE Power over Ethernet
POP Post Office Protocol
RF Radio Frequency
RFC Request for Comment
ROM Read-Only Memory
RPC Remote Procedure Call
SEM Security Event Management

SIEM Security Information and Event Management
SIM Security Information Management
SIP Session Initiation Protocol
SMB Server Message Block
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SP Special Publication
SSH Secure Shell
SSID Service Set Identifier
SSL Secure Sockets Layer
STA Station
TCP Transmission Control Protocol

TCP/IP Transmission Control Protocol/Internet Protocol
TFTP Trivial File Transfer Protocol
TLS Transport Layer Security
TTL Time to Live
UDP User Datagram Protocol
B-2
USB Universal Serial Bus

US-CERT United States Computer Emergency Readiness Team
VLAN Virtual Local Area Network

VPN Virtual Private Network
WEP Wired Equivalent Privacy

WLAN Wireless Local Area Network
WPA Wi-Fi Protected Access
WVE Wireless Vulnerabilities and Exploits
XML Extensible Markup Language
B-3
B-4
Appendix C—Tools and Resources
The lists below provide examples of tools and resources that may be helpful.
Print Resources
Bace, Rebecca, Intrusion Detection, Macmillan Technical Publishing, 2000.
Bejtlich, Richard, Extrusion Detection, Addison-Wesley, 2005.
Bejtlich, Richard, The Tao of Network Security Monitoring: Beyond Intrusion Detection,
Addison-Wesley, 2004.
Crothers, Tim, Implementing Intrusion Detection Systems: A Hands-On Guide for Securing the
Network, 2002.
Endorf, Carl et al, Intrusion Detection and Prevention, McGraw-Hill Osborne Media, 2003.
Kruegel, Chris et al, Intrusion Detection and Correlation: Challenges and Solutions, Springer,
2004.
Nazario, Jose, Defense and Detection Strategies Against Internet Worms, Artech House
Publishers, 2003.
Northcutt, Stephen and Novak, Judy, Network Intrusion Detection: An Analyst’s Handbook,
Third Edition, New Riders, 2003.
Rash, Michael et al, Intrusion Prevention and Active Response: Deployment Network and Host
IPS, Syngress, 2005.
Organizations
Organization URL
Computer Incident Advisory Capability (CIAC) http://www.ciac.org/ciac/
Cooperative Association for Internet Data Analysis (CAIDA) http://www.caida.org/home/
Distributed Intrusion Detection System (DShield) http://dshield.org/indexd.html
European Institute for Computer Antivirus Research (EICAR) http://www.eicar.org/
IETF Intrusion Detection Exchange Format (idwg) Working Group http://www.ietf.org/html.charters/OLD/id
wg-charter.html
Internet Storm Center (ISC) http://isc.incidents.org/
SANS Institute http://www.sans.org/
United States Computer Emergency Readiness Team (US-CERT) http://www.us-cert.gov/
Virus Bulletin http://www.virusbtn.com/index
Viruslist.com http://www.viruslist.com/en/
WildList Organization International http://www.wildlist.org/
C-1
Technical Resource Sites
Resource Name URL

CSRC—Practices & Checklist/Implementation Guides http://csrc.nist.gov/pcig/cig.html
Unassigned IP Address Ranges http://www.cymru.com/Documents/bogon-list.html
General and Network-Based IDPS Resources
An Introduction to Intrusion Detection Systems http://www.securityfocus.com/infocus/1520
Comparison of Firewall, Intrusion Prevention and http://www.juniper.net/solutions/literature/white_papers/20
Antivirus Technologies 0063.pdf
Evaluating Intrusion Prevention Systems http://www.cioupdate.com/article.php/3563306
IDS: Intrusion Detection System http://www.javvin.com/networksecurity/ids.html
Intrusion Detection System Frequently Asked http://www.sans.org/resources/idfaq/
Questions
Intrusion Detection System Overview http://www.webopedia.com/TERM/I/intrusion_detection_s
ystem.html
Intrusion Detection: Implementation and Operational http://www.stsc.hill.af.mil/crosstalk/2001/01/mchugh.html
Issues
Intrusion Prevention Systems http://www.nfr.com/resource/downloads/SentivistIPS-
WP.pdf
Intrusion Prevention Systems (IPS) http://www.securecomputing.com/pdf/Intru-Preven-WP1-
Aug03-vF.pdf
Intrusion Prevention Systems (IPS) http://hosteddocs.ittoolbox.com/BW013004.pdf

Intrusion Prevention Systems: the Next Step in the http://www.securityfocus.com/infocus/1670
Evolution of IDS
Recommendations for Deploying an Intrusion- http://searchsecurity.techtarget.com/tip/1,289483,sid14_g
Detection System ci781471,00.html
SANS Glossary of Terms Used in Security and http://www.sans.org/resources/glossary.php
Intrusion Detection
State of the Practice of Intrusion Detection http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99t
Technologies r028.pdf
The Evolution of Intrusion Detection Systems http://www.securityfocus.com/infocus/1514
Wireless IDPS Resources
Wireless IDSes Defend Your Airspace http://www.eweek.com/article2/0,1895,1630842,00.asp
Wireless Intrusion Detection and Response http://users.ece.gatech.edu/~owen/Research/Conference
%20Publications/wireless_IAW2003.pdf
Wireless Intrusion Detection Systems http://www.securityfocus.com/infocus/1742
Wireless Intrusion Detection Systems: GIAC Security http://www.sans.org/rr/whitepapers/wireless/1543.php
Essentials
NBA IDPS Resources
Anomaly Detection Can Prevent Network Attacks http://www.techworld.com/networking/features/index.cfm?f
eatureid=2338&pagtype=samecat
Anomaly Detection in IP Networks http://users.ece.gatech.edu/~jic/sig03.pdf
Design and Implementation of an Anomaly Detection http://luca.ntop.org/ADS.pdf
System: an Empirical Approach
IDS: Signature Versus Anomaly Detection http://searchsecurity.techtarget.com/tip/1,289483,sid14_g
ci1092691,00.html?track=IDSLG
Packet vs Flow-Based Anomaly Detection http://www.esphion.com/pdf/ESP_WP_4_PACKET_V_FL
OWS.pdf
C-2
Resource Name URL

The State of Anomaly Detection http://www.securityfocus.com/infocus/1600
Host-Based IDPS Resources
Host-Based IDS vs Network-Based IDS http://www.windowsecurity.com/articles/Hids_vs_Nids_Pa
rt1.html
Host-Based IDSs Add to Security Policy http://www.networkworld.com/news/tech/2003/0915techup
date.html
Host-Based Intrusion Detection System Definition http://en.wikipedia.org/wiki/Host-
based_intrusion_detection_system
Host-Based Intrusion Detection Systems http://staff.science.uva.nl/~delaat/snb-2004-
2005/p19/report.pdf
What Is Host-Based Intrusion Detection? http://www.sans.org/resources/idfaq/host_based.php
Mailing Lists and Notification Services
Mailing List/Notification Service Name Location

Incidents http://www.securityfocus.com/cgi-
bin/index.cgi?c=11&op=display_threads&ListID=75&limit=30&offset=0&
date=2007-01-16&mode=threaded
Security Focus http://www.securityfocus.com/ids
SecurityTracker.com http://securitytracker.com/
Other Technical Resource Documents
Resource Name URL

IETF, RFC 2267, Network Ingress Filtering: Defeating Denial of http://www.ietf.org/rfc/rfc2267.txt
Service Attacks Which Employ IP Source Address Spoofing
NIST, SP 500-267, A Profile for IPv6 in the U.S. Government, Version http://www.antd.nist.gov/
1.0 (DRAFT)
NIST, SP 800-31, Intrusion Detection Systems http://csrc.nist.gov/publications/nistpubs/
NIST, SP 800-42, Guideline on Network Security Testing http://csrc.nist.gov/publications/nistpubs/
NIST, SP 800-51, Use of the Common Vulnerabilities and Exposures http://csrc.nist.gov/publications/nistpubs/
(CVE) Vulnerability Naming Scheme
NIST, SP 800-53, Recommended Security Controls for Federal http://csrc.nist.gov/publications/nistpubs/
Information Systems
NIST, SP 800-61, Computer Security Incident Handling Guide http://csrc.nist.gov/publications/nistpubs/
NIST, SP 800-70, Security Configuration Checklists Program for IT http://csrc.nist.gov/checklists/
Products
NIST, SP 800-83, Guide to Malware Incident Prevention and Handling http://csrc.nist.gov/publications/nistpubs/
NIST, SP 800-86, Guide to Integrating Forensic Techniques into http://csrc.nist.gov/publications/nistpubs/
Incident Response
NIST, SP 800-88, Guidelines for Media Sanitization http://csrc.nist.gov/publications/nistpubs/
NIST, SP 800-92, Guide to Computer Security Log Management http://csrc.nist.gov/publications/nistpubs/
NIST, SP 800-97, Establishing Wireless Robust Security Networks: A http://csrc.nist.gov/publications/nistpubs/
Guide to IEEE 802.11i
C-3
Common Enterprise Network-Based IDPSs
Product Line Vendor URL

Attack Mitigator Top Layer Networks http://www.toplayer.com/content/products/index.jsp
BBX DeepNines http://www.deepnines.com/bbx.php
Bro Vern Paxson http://bro-ids.org/
Cisco IPS Cisco Systems http://www.cisco.com/en/US/products/hw/vpndevc/index.html
Cyclops e-Cop.net http://www.e-cop.net/
DefensePro Radware, Ltd. http://www.radware.com/content/products/dp/default.asp
Dragon Enterasys Networks, Inc. http://www.enterasys.com/products/ids/
eTrust Intrusion Computer Associates http://www3.ca.com/solutions/Product.aspx?ID=163
Detection
Juniper Networks Juniper Networks https://www.juniper.net/products/intrusion/
IDP
IntruShield Network Associates http://www.mcafee.com/us/enterprise/products/network_intrusi
on_prevention/index.html
iPolicy iPolicy Networks http://www.ipolicynetworks.com/products/ipf.html
Proventia Internet Security Systems http://www.iss.net/products/product_sections/Intrusion_Preven
tion.html
SecureNet Intrusion http://www.intrusion.com/
Sentivist Check Point Software http://www.nfr.com/solutions/sentivist-ips.php
Technologies
Snort Sourcefire http://www.snort.org/
Sourcefire Sourcefire http://www.sourcefire.com/products/is.html
StoneGate StoneSoft Corporation http://www.stonesoft.com/en/products_and_solutions/products/
ips/
Strata Guard StillSecure http://www.stillsecure.com/strataguard/index.php
Symantec Network Symantec Corporation http://www.symantec.com/enterprise/products/index.jsp
Security
UnityOne TippingPoint Technologies http://www.tippingpoint.com/products_ips.html
Common Enterprise Wireless IDPSs

AirDefense AirDefense http://www.airdefense.net/products/index.php
AirMagnet AirMagnet http://www.airmagnet.com/products/
AiroPeek WildPackets http://www.wildpackets.com/products/airopeek/overview
BlueSecure BlueSocket http://www.bluesocket.com/products/centralized_intrusion.html
Highwall Highwall http://www.highwalltech.com/products.cfm
Technologies
Red-Detect Red-M http://www.red-m.com/products-and-services/red-detect.html
RFprotect Network Chemistry http://networkchemistry.com/products/
SpectraGuard AirTight Networks http://www.airtightnetworks.net/products/products_overview.html
C-4
Common Enterprise NBA Systems

Arbor Peakflow X Arbor Networks http://www.arbornetworks.com/products_x.php
Cisco Guard, Cisco Systems http://www.cisco.com/en/US/products/hw/vpndevc/index.html
Cisco Traffic
Anomaly Detector
GraniteEdge ESP GraniteEdge http://www.graniteedgenetworks.com/products
Networks
OrcaFlow Cetacea Networks http://www.orcaflow.ca/features-overview.php
Profiler Mazu http://www.mazunetworks.com/products/index.php
Proventia Network Internet Security http://www.iss.net/products/Proventia_Network_Anomaly_Detection_
Anomaly Detection Systems System/product_main_page.html
System (ADS)
QRadar Q1 Labs http://www.q1labs.com/content.php?id=175
StealthWatch Lancope http://www.lancope.com/products/
Common Enterprise Host-Based IDPSs

BlackIce Internet Security http://www.iss.net/products/product_sections/Server_Protection.html
Systems http://www.iss.net/products/product_sections/Desktop_Protection.html
Blink eEye Digital http://www.eeye.com/html/products/blink/index.html
Security
Cisco Security Cisco Systems http://www.cisco.com/en/US/products/sw/secursw/ps5057/index.html
Agent
Deep Security Third Brigade http://www.thirdbrigade.com/
DefenseWall HIPS SoftSphere http://www.softsphere.com/programs/
Technologies
Intrusion Intrusion http://www.intrusion.com/
SecureHost
McAfee Host McAfee http://www.mcafee.com/us/enterprise/products/host_intrusion_preventio
Intrusion n/index.html
Prevention
Primary Response Sana Security http://www.sanasecurity.com/products/pr/index.php
Proventia Internet Security http://www.iss.net/products/product_sections/Server_Protection.html
RealSecure Internet Security http://www.iss.net/products/product_sections/Server_Protection.html
SecureIIS Web eEye Digital http://www.eeye.com/html/products/secureiis/index.html
Server Protection Security
Symantec Critical Symantec http://www.symantec.com/enterprise/products/index.jsp
System Protection
C-5
C-6
Appendix D—Index
A E
Access point (AP), 5-2 Encrypted network traffic, 4-11
Ad hoc mode, 5-2 Environments, 9-1
Agent, 3-1, 7-1, 7-3 Evasion, 2-3, 4-11, 5-10
Alert, 2-2, 4-10
Notification method, 3-3
Settings, 3-3, 3-4
F
Anomaly-based detection, 2-3, 2-4 False negative, 2-3, 4-10
Antispyware software, 8-5 False positive, 2-3, 2-5, 3-5, 4-10, 5-9
Antivirus software, 8-5 File access attempts, 7-5
Appliance, 3-5 File attribute checking, 7-5
Application layer, 4-1, 4-9 File integrity checking, 7-5
Application-based intrusion detection and prevention File transfer monitoring, 2-1
system, 7-1 Filesystem monitoring, 7-5
Architecture, 3-4 Firewalls, 8-6
Attacks, 4-9 Flooding, 5-9
Audiovisual device monitoring, 7-9 Flow, 6-1
Authentication, 3-6 Frame, 4-3
Authenticator, 2-6
G
B
Graphical user interface (GUI), 3-6
Bandwidth usage throttling, 4-13
Baselines, 6-5
Blacklist, 3-3, 3-4 H
Blinding, 4-12 Hardware layer, 4-3
Buffer overflow detection, 7-4 High loads, 4-12
Honeypot, 8-7
C Host architecture, 7-3
Host hardening, 7-9
Channel scanning, 5-4 Host-based intrusion detection and prevention system, 2-7,
Code analysis, 7-4 7-1, 8-1
Code behavior analysis, 7-4 Hot list. See Blacklist
Command-line interface (CLI), 3-7
Common Vulnerabilities and Exposures (CVE), 4-8, 9-5
Configuration, 3-6 I
Console, 3-1, 3-6, 6-7 IDS load balancer, 4-6
Content sanitization, 4-13 IEEE 802.11, 5-1
Correlation, 3-1, 8-3 Implementation, 3-4, 3-5, 4-14, 7-9
Cost, 9-12 Incident, 2-1
Customization, 3-3, 3-4, 4-11, 5-10, 6-5, 7-6 Incident response, 2-1, 3-7
Information gathering, 3-2, 4-7, 5-7, 6-3, 9-4
D Infrastructure mode, 5-2
Inline firewalling, 4-13, 6-6
Data link layer, 4-1, 4-3 Inline sensor, 4-4, 4-13, 6-2, 6-6
Database server, 3-1 Integration, 8-1, 8-2
Denial of service (DoS) attacks, 5-10, 6-4 Direct, 8-2
Detection accuracy, 6-5, 7-6 Indirect, 8-3
Detection capabilities, 3-3, 4-9, 5-8, 6-4, 7-4, 9-5 Internet Control Message Protocol (ICMP), 4-2
Detection code Internet Protocol (IP) layer, 4-2
Editing and viewing, 3-3 Interoperability, 3-5, 9-9
Detection methodologies, 2-3 Intrusion detection, 2-1
Distributed denial of service (DDoS) attacks, 4-12 Intrusion detection and prevention (IDP), 1
Distribution system (DS), 5-2
D-1
Intrusion detection and prevention system (IDPS), 2-1, 2-6, Passive sensor, 4-5, 4-12, 6-2, 6-6
3-1 Patches. See Updates
Intrusion detection system (IDS), 1, 2-1, 2-2 Performance, 9-6
Intrusion prevention system (IPS), 1, 2-1, 2-2 Port number, 4-2
IPv6, 4-9 Power over Ethernet (PoE), 5-4
Prevention capabilities, 3-4, 4-12, 5-11, 6-6, 7-8, 9-6
Prevention methods, 4-6
J Process status monitoring, 7-9
Jamming, 5-9 Product evaluation, 9-13
Product requirements, 9-1
Product selection, 9-1
L Profile, 2-4
Learning mode, 3-4 Promiscuous mode, 4-3
Limitations, 4-11, 5-10, 6-6, 7-7 Protocol models, 2-6
Log analysis, 7-6
Logging, 2-2, 3-2, 4-8, 5-8, 6-3, 7-4, 8-3, 9-4 R
Reconnaissance, 2-1, 4-9
M Reliability, 3-5, 9-8
Maintenance, 3-6, 9-10 Remote access, 3-6
Malware, 8-5 Removable media restriction, 7-8
Management capabilities, 3-4, 4-13, 5-11, 6-7, 7-9, 9-8 Reporting, 2-2, 3-7
Management communications, 3-6 Resource constraints, 9-3
Management interface, 3-1 Risk management, 9-1
Management network, 3-1, 3-5, 4-4 Routers, 8-6
Management server, 3-1
Media Access Control (MAC) address, 4-3, 5-3 S
Misconfiguration identification, 4-10
Misuse detection, 2-4 Sanitization, 7-9
Multiple products, 8-1 Scalability, 9-9
Scanning, 6-4
Security, 3-6, 4-14, 7-9, 9-10
N Security capabilities, 5-7, 9-4
Network address translation (NAT), 8-6 Security control reconfiguration, 2-3, 4-13, 6-6
Network architecture, 3-1, 3-4, 4-3, 4-14, 5-5, 6-1, 7-2 Security information and event management (SIEM)
Network behavior analysis (NBA) system, 2-7, 6-1, 8-1 software, 8-3
Network configuration monitoring, 7-6 Security policy, 2-2, 9-2
Network forensic analysis tool (NFAT), 8-4 Security policy violation, 2-1, 4-10, 6-4
Network layer, 4-1, 4-2, 4-9 Sensor, 3-1, 4-3, 5-3, 6-1, 6-2
Network tap, 4-6 Service set identifier (SSID), 5-3
Network Time Protocol (NTP), 3-2 Session sniping, 4-12
Network traffic analysis, 7-5 Shim, 7-3
Network traffic filtering, 7-5 Signature, 2-4
Network traffic flow Editing and viewing, 3-3
See Flow, 6-1 Signature updates. See Updates, signature
Network-based intrusion detection and prevention system, Signature-based detection, 2-3, 2-4, 4-10, 6-5
2-6, 4-1, 8-1 Simulation mode, 3-4
Capacity, 4-12 Skills, 3-9
Normalization, 2-3, 4-13, 8-3 Software updates. See Updates, software
Spanning port, 4-5
State, 2-5
O Stateful protocol analysis, 2-3, 2-5, 4-11
Station (STA), 5-2
Operation, 3-6, 9-10
Stealth mode, 4-14
syslog, 8-4
P System call monitoring, 7-5
Packet, 4-2
Packet capture, 4-9, 6-6 T
Packet dropping, 4-12
TCP reset packets, 4-12, 6-6
Packet header, 4-2
Testing, 3-5, 4-14, 7-9
Passive fingerprinting, 4-8
Threats, 2-2, 5-3, 9-2
D-2
Known, 2-4 V
Unknown, 2-4
Threshold, 3-3, 3-4 Virtual local area network (VLAN), 3-2
Training period, 2-5 Vulnerability identification, 4-10
Training, documentation, and technical support, 9-12
Transmission Control Protocol (TCP), 4-2
Transmission Control Protocol/Internet Protocol, 4-1
W
Transport layer, 4-1, 4-2, 4-9 Whitelist, 3-3, 3-4
Triangulation, 5-9 Wireless intrusion detection and prevention system, 2-6, 5-
Tuning, 2-3, 3-3, 3-4, 4-11, 5-10, 6-5, 7-6 1, 8-1
Wireless local area network (WLAN), 5-1
U Wireless networking, 5-1
Wireless sensor, 5-3, 5-6
Updates, 3-8, 9-11 Bundled, 5-4
Signature, 3-8 Dedicated, 5-4
Software, 3-8 Fixed, 5-4
Testing, 3-9 Mobile, 5-4
User accounts, 3-6 Wireless switch, 5-2
User Datagram Protocol (UDP), 4-2 Worms, 6-4
D-3
Identity and Access Management
Identity and access management (IAM) ensures that the right people and job roles in your
organization (identities) can access the tools they need to do their jobs. Identity management
and access systems enable your organization to manage employee apps without logging into
each app as an administrator. Identity and access management systems enable your
organization to manage a range of identities including people, software, and hardware like
robotics and IoT devices.
Why Do You Need IAM?

Companies need IAM to provide online security and to increase employee productivity.
 Security. Traditional security often has one point of failure - the password. If a user's
password is breached - or worse yet, the email address for their password recoveries -
your organization becomes vulnerable to attack. IAM services narrow the points of
failure and backstops them with tools to catch mistakes when they are made.
 Productivity. Once you log on to your main IAM portal, your employee no longer has
to worry about having the right password or right access level to perform their duties.
Not only does every employee get access to the perfect suite of tools for their job, their
access can be managed as a group or role instead of individually, reducing the workload
on your IT professionals.
Does IAM Improve Regulatory Compliance?

Security is also a matter of law, regulation, and contracts. Data protection standards like
Europe's General Data Protection Regulation and HIPPA and the Sarbanes-Oxley Act in the
U.S. enforce strict standards for data security. With an IAM solution, your users and
organization can ensure that the highest standards of security, tracking, and administrative
transparency are a matter of course in your day-to-day operations.
How Does IAM Work?

Identity management solutions generally perform two tasks:
1. IAM confirms that the user, software, or hardware is who they say they are by
authenticating their credentials against a database. IAM cloud identity tools are more
secure and flexible than traditional username and password solutions.
2. Identity access management systems grant only the appropriate level of access. Instead
of a username and password allowing access to an entire software suite, IAM allows
for narrow slices of access to be portioned out, i.e. editor, viewer, and commenter in a
content management system.
What Does IAM Do?

IAM systems provide this core functionality:
Manage user identities
IAM systems can be the sole directory used to create, modify, and delete users, or it may
integrate with one or more other directories and synchronize with them. Identity and access
management can also create new identities for users who need a specialized type of access to
an organization's tools.
Provisioning and de-provisioning users
Specifying which tools and access levels (editor, viewer, and administrator) to grant a user is
called provisioning. IAM tools allow IT departments to provision users by role, department, or
other grouping in consultation with the managers of that department. Since it is time consuming
to specify each individual’s access to every resource, identity management systems enable
provisioning via policies defined based on role-based access control (RBAC). Users are
assigned one or more roles, usually based on job function, and the RBAC IAM system
automatically grants them access. Provisioning also works in reverse; to avoid security risks
presented by ex-employees retaining access to systems, IAM allows your organization to
quickly remove their access.
Authenticating users
IAM systems authenticate a user by confirming that they are who they say they are. Today,
secure authentication means multi-factor authentication (MFA) and, preferably, adaptive
authentication.
Authorizing users
Access management ensures a user is granted the exact level and type of access to a tool that
they are entitled to. Users can also be portioned into groups or roles so large cohorts of users
can be granted the same privileges.
Reporting
IAM tools generate reports after most actions taken on the platform (like login time, systems
accessed, and type of authentication) to ensure compliance and assess security risks.
Single Sign-On
Identity and access management solutions with single sign-on (SSO) allow users to
authenticate their identity with one portal instead of many different resources. Once
authenticated, the IAM system acts as the source of identity truth for the other resources
available to the user, removing the requirement for the user to remember several passwords.
What is the Difference Between Identity Management and

Access Management?
Identity management confirms that you are you and stores information about you. An identity
management database holds information about your identity - for example, your job title and
your direct reports - and authenticates that you are, indeed, the person described in the database.
Access management uses the information about your identity to determine which software
suites you're allowed access to and what you're allowed to do when you access them. For
example, access management will ensure that every manager with direct reports has access to
an app for timesheet approval, but not so much access that they can approve their own
timesheets.
Cloud Versus On-Premises IAM

In the past, a server on the physical premises of an organization, which was called on-prem.,
managed most identity and a provider in the cloud to avoid physical maintenance costs to the
organization, as well as to ensure uptime, distributed and redundant systems, and short SLAs
now manages access management Most IAM services.
What is AWS Identity and Access Management?

Amazon Web Services (AWS) identity and access management is simply the IAM system that
is built into AWS. By using AWS IAM, you can create AWS users and groups and grant or
deny them access to AWS services and resources. AWS IAM is available free of charge.
AWS IAM service provides:
 Fine-grained access control to AWS resources

 AWS multi-factor authentication
 Analysis features to validate and fine tune policies
 Integration with external identity management solutions
What Tools Do I Need to Implement Identity and Access

Management?
The tools needed to implement IAM include password-management tools, provisioning
software, security-policy enforcement applications, reporting and monitoring apps and identity
repositories. IAM tools can include, but are not limited to:
 MFA
Multi-factor authentication means that your IAM provider requires more than one type
of proof that you are who you say you are. A typical example is requiring both a
password and a fingerprint. Other MFA choices include facial recognition, iris scans,
and physical tokens like a Yubikey.
 SSO
SSO stands for single sign-on. If your IAM solution provides single sign-on, that means
your users can sign in only once and then treat the identity and access management tool
as a "portal" to the other software suites they have access to, all without signing in to
each one.
What Does an IAM Implementation Strategy Include?

As a cornerstone of a zero trust architecture, an IAM solution should be implemented using
zero-trust principles such as least privilege access and identity-based security policies.
 Central identity management

A key principle of zero trust is managing access to resources at the identity level,
therefore having centralized management of those identities can make this approach
much simpler. This could mean migrating users from other systems or at least
synchronizing your IAM with other user directories within your environment such as a
Human Resources directory.
 Secure access
Since securing at the identity level is key, an IAM should make sure that it is confirming
the identities of those who are logging in. This could mean implementing MFA or a
combination of MFA and adaptive authentication to be able to take into consideration
the context of the login attempt: location, time, device, etc.
 Policy-based control
Users should only be given authorization to perform their required tasks and no more
privilege than is necessary. An IAM should be designed to give users access to
resources based upon their job role, their department or any other attributes that seem
appropriate. As part of the centrally managed identity solution these policies can then
ensure that resources are secure no matter where they are being accessed from.
 Zero-Trust Policy
A zero trust policy means that an organization's IAM solution is constantly monitoring
and securing its users identity and access points. In the past, organizations operated on
a "once you're in, you have access" policy, but zero-trust policies ensure that each
member of the organization is constantly being identified and their access managed.
 Secured privileged accounts
Not all accounts in an access management system are created equal. Accounts with
special tools or privileged access to sensitive information can be provided a tier of
security and support that suits their status as a gatekeeper for the organization.
 Training and support
IAM providers provide training for the users who will be most engaged with the product
- including users and administrators - and often provide customer service for the long-
term health of your IAM installation and its users.
IAM Technologies
An IAM system is expected to be able to integrate with many different systems. Because of
this, there are certain standards or technologies that all IAM systems are expected to support:
Security Access Markup Language (SAML)
SAML is an open standard used to exchange authentication and authorization information

between an identity provider system such as an IAM and a service or application. This is the
most commonly used method for an IAM to provide a user with the ability to log in to an
application that has been integrated with the IAM platform.
OpenID Connect (OIDC)


OIDC is a newer open standard that also enables users to log in to their application from
an identity provider. It is very similar to SAML, but is built on the OAuth 2.0 standards
and uses JSON to transmit the data instead of XML, which is what SAML uses.
 System for Cross-domain Identity Management (SCIM)
 SCIM is standard used to automatically exchange identity information between two
systems. Though both SAML and OIDC can pass identity information to an application
during the authentication process, SCIM is used to keep the user information up to date
whenever new users are assigned to the service or application, user data is updated, or
users are deleted. SCIM is a key component of user provisioning in the IAM space.
Elements of a Network Security Architecture
A network security architecture includes both network and security elements, such as the
following:
Network Elements: Network nodes (computers, routers, etc.), communications protocols

(TCP/IP, HTTP, DNS, etc.), connection media (wired, wireless), and topologies (bus, star,
mesh, etc.).
Security Elements: Cybersecurity devices and software, secure communications protocols
(e.g. IPsec VPN and TLS), and data privacy technologies (classification, encryption, key
management, etc.).
The Purpose of a Network Security Architecture
A well-designed cybersecurity architecture enables businesses to maintain resiliency in the face

of a cyberattack or a failure of one or more components of their infrastructure. The architecture
should be optimized for daily use during normal business operations and prepare the company
to handle reasonable bursts, spikes, or surges in traffic and to appropriately manage potential
cyber threats to the organization.
How Does a Security Architect Create a Network Security Architecture?
A security architect is responsible for identifying and working to prevent potential cyber threats
to an organization’s network and systems. As part of their role, security architects should
develop a network and security architecture that provides the visibility and control necessary
to identify and respond to cyber threats to an organization’s systems. This includes developing
a plan for locating security controls to maximize their benefit to the company.
The Check Point Enterprise Security Framework (CESF) defines a process for developing a
network security architecture that includes four primary phases:
Assess: This phase of the process is for business and architecture reviews. The key steps in
this phase include data capture, business modeling, and risk assessments.
Design: This phase is intended to develop a response to the requirements and to build
customized logical design blueprints and recommendations.
Implement: This phase is for professional services, partners, etc. to add low-level design
details and deliver statement-of-works for real-world solutions.
Manage: This phase is geared towards continuous development and incremental
improvements of the security posture.
Network Security Architecture Frameworks
Network security architectures can be designed based on a few different frameworks. Two of
the most widely used models include zero trust and the Sherwood Applied Business Security
Architecture (SABSA).
Zero Trust
The zero trust security model is designed to replace traditional, perimeter-based security
models that place implicit trust in users, devices, and applications inside of the network. Zero
trust eliminates the network perimeter by treating all devices as potential threats regardless of
their location.
With a zero trust architecture, all requests for access to corporate resources are evaluated on a
case-by-case basis. If the request is deemed legitimate based on role-based access controls
(RBACs) and other contextual data, then access is granted only to the requested asset at the
requested level for the duration of the current session.
A zero trust security architecture provides deep visibility and control over the actions
performed within the corporate network. This is accomplished using a combination of strong
authentication systems, including multi-factor authentication (MFA), and granular access
control implemented using micro-segmentation.
The Sherwood Applied Business Security Architecture (SABSA)
SABSA is a model for developing a security architecture based upon risk and business security
needs. The model identifies business security requirements at the beginning of the process and
works to trace them throughout the entire process of designing, implementing, and maintaining
a security architecture.
SABSA includes a matrix for security infrastructure modeling. This includes multiple different
layers (contextual, conceptual, logical, physical, component, and operational) and questions to
be asked (what, why, how, who, where, and when). At each intersection, the model defines the
component of the security architecture that should address that question at that layer.
Architecting Network Security with Check Point
For nearly thirty years, Check Point has set the standard for cybersecurity. Across the ever-
evolving digital world, from enterprise networks through cloud transformations, from securing
remote employees to defending critical infrastructures, we protect organizations from the most
imminent cyber threats.
Check Point provides an integrated cybersecurity architecture designed to secure company

networks, clouds and users against modern threats. It consolidates an organization’s array of
Check Point solutions, and can be managed centrally via a single dashboard. This consolidated
security architecture expedites incident detection and response and allows all security solutions
to leverage threat intelligence generated by Check Point ThreatCloud, the world’s largest threat
intelligence database.
Need help designing a secure network, Check Point Security Architects leverage its industry
experience and employ independent frameworks, such as NIST CSF, SABSA, and Zero Trust
Architecture, to provide advisory and assessment services to secure customer networks from
threats.
Basic Firewall Configuration
Just as a firewall in a building attempts to prevent a fire from spreading, a computer firewall
attempts to prevent computer viruses from spreading to your computer and to prevent
unauthorized users from accessing your computer. A firewall exists between your computer
and the network. It determines which services on your computer remote users on the network
can access. A properly configured firewall can greatly increase the security of your system. It
is recommended that you configure a firewall for any Red Hat Enterprise Linux system with
an Internet connection.
11.1. Security Level Configuration Tool
During the Firewall Configuration screen of the Red Hat Enterprise Linux installation, you
were given the option to enable a basic firewall as well as to allow specific devices, incoming
services, and ports.
After installation, you can change this preference by using the Security Level Configuration
Tool.
To start the application, select Main Menu Button (on the Panel) => System Settings =>
Security Level or type the command system-config-securitylevel from a shell prompt (for
example, in an XTerm or a GNOME terminal).
Figure 11-1. Security Level Configuration Tool
Note
The Security Level Configuration Tool only configures a basic firewall. If the system
needs more complex rules, refer to the Red Hat Enterprise Linux Reference Guide for
details on configuring specific iptables rules.
11.1.1. Enabling and Disabling the Firewall
Select one of the following options:
 Disable firewall — Disabling the firewall provides complete access to your system and
does no security checking. Security checking is the disabling of access to certain
services. This should only be selected if you are running on a trusted network (not the
Internet) or plan to do more firewall configuration later.
Warning
If you have a firewall configured or any customized firewall rules in the
/etc/sysconfig/iptables file, the file is deleted by selecting Disable firewall and
clicking OK to save the changes.
 Enable firewall — This option configures the system to reject incoming connections
that are not in response to outbound requests, such as DNS replies or DHCP requests.
If access to services running on this machine is needed, you can choose to allow specific
services through the firewall.
If you are connecting your system to the Internet, but do not plan to run a server, this is
the safest choice.
11.1.2. Trusted Services
Enabling options in the Trusted services list allows the specified service to pass through the
firewall.
WWW (HTTP)
The HTTP protocol is used by Apache (and by other Web servers) to serve webpages.
If you plan on making your Web server publicly available, enable this option. This
option is not required for viewing pages locally or for developing webpages. You must
have the httpd package installed to serve webpages.
Enabling WWW (HTTP) will not open a port for HTTPS, the SSL version of HTTP.
FTP
The FTP protocol is used to transfer files between machines on a network. If you plan
on making your FTP server publicly available, enable this option. The vsftpd package
must be installed for this option to be useful.
SSH
Secure Shell (SSH) is a suite of tools for logging into and executing commands on a
remote machine. To allow remote access to the machine via ssh, enable this option. The
openssh-server package must be installed to access your machine remotely using SSH
tools.
Telnet
Telnet is a protocol for logging into remote machines. Telnet communications are
unencrypted and provide no security from network snooping. Allowing incoming
Telnet access is not recommended. To allow inbound Telnet access, you must have the
telnet-server package installed.
Mail (SMTP)
To allow incoming mail delivery through your firewall so that remote hosts can connect
directly to your machine to deliver mail, enable this option. You do not need to enable
this if you collect your mail from your ISP's server using POP3 or IMAP, or if you use
a tool such as fetchmail. Note that an improperly configured SMTP server can allow
remote machines to use your server to send spam.
11.1.3. Trusted Devices
Selecting any of the Trusted devices allows access to your system for all traffic from that
device; it becomes excluded from the firewall rules. For example, if you are running a local
network, but are connected to the Internet via a PPP dialup, you can check eth0 and any traffic
coming from your local network is allowed. Selecting eth0 as trusted means all traffic over the
Ethernet is allowed, but the ppp0 interface is still firewalled. To restrict traffic on an interface,
leave it unchecked.
You may have noticed a sit0 device in the Trusted devices section. This device stands for
simple internet transition, which encapsulates IPv6 traffic into IPv4 traffic, and then is
tunneled. For basic firewall rules, this device can be ignored and left as an untrusted device.
# Important
It is not recommended that you make any device that is connected to public networks,
such as the Internet, a Trusted device.
11.1.4. Other Ports
The Security Level Configuration Tool includes the Other ports section for adding custom IP
ports to become trusted by iptables. For example, to allow NFS, IRC, and Internet printing
protocol (IPP) to be allowed to pass through the firewall, the following would be inserted in
the Other ports section:
2049:tcp,194:tcp,631:tcp
11.1.5. Saving the Settings
Click OK to save the changes and enable or disable the firewall. If Enable firewall was selected,
the options selected are translated to iptables commands and written to the
/etc/sysconfig/iptables file. The iptables service is also started so that the firewall is activated
immediately after saving the selected options. If Disable firewall was selected, the
/etc/sysconfig/iptables file is removed and the iptables service is stopped immediately.
The options selected are also written to the /etc/sysconfig/system-config-securitylevel file so
that the settings can be restored the next time the application is started. Do not edit this file by
hand.
Even though the firewall is activated immediately, the iptables service is not configured to start
automatically at boot time refer to Section 11.2 Activating the iptables Service for details.
Key Functions of IDPS Technologies

There are many types of IDPS technologies, which are differentiated primarily by the types of
events that they can recognize and the methodologies that they use to identify incidents. In
addition to monitoring and analyzing events to identify undesirable activity, all types of IDPS
technologies typically perform the following functions:
􀀟
Recording information related to observed events. Information is usually recorded locally, and
might also be sent to separate systems such as centralized logging servers, security information
and event management (SIEM) solutions, and enterprise management systems.
􀀟
Notifying security administrators of important observed events. This notification, known as an
alert, occurs through any of several methods, including the following: e-mails, pages, messages
on the IDPS user interface, Simple Network Management Protocol (SNMP) traps, syslog
messages, and user-defined programs and scripts. A notification message typically includes
only basic information regarding an event; administrators need to access the IDPS for
additional information.
􀀟
Producing reports. Reports summarize the monitored events or provide details on particular
events of interest.
Some IDPSs are also able to change their security profile when a new threat is detected. For
example, an IDPS might be able to collect more detailed information for a particular session
after malicious activity is detected within that session. An IDPS might also alter the settings
for when certain alerts are triggered or what priority should be assigned to subsequent alerts
after a particular threat is detected.
IPS technologies are differentiated from IDS technologies by one characteristic: IPS
technologies can respond to a detected threat by attempting to prevent it from succeeding. They
use several response techniques, which can be divided into the following groups:
􀀟
The IPS stops the attack itself. Examples of how this could be done are as follows:
–
Terminate the network connection or user session that is being used for the attack
–
Block access to the target (or possibly other likely targets) from the offending user account, IP
address, or other attacker attribute
–
Block all access to the targeted host, service, application, or other resource.
􀀟
The IPS changes the security environment. The IPS could change the configuration of other
security controls to disrupt an attack. Common examples are reconfiguring a network device
(e.g., firewall, router, switch) to block access from the attacker or to the target, and altering a
host-based firewall on a target to block incoming attacks. Some IPSs can even cause patches
to be applied to a host if the IPS detects that the host has vulnerabilities.
􀀟
The IPS changes the attack’s content. Some IPS technologies can remove or replace malicious
portions of an attack to make it benign. A simple example is an IPS removing an infected file
attachment from an e-mail and then permitting the cleaned email to reach its recipient. A more
complex example is an IPS that acts as a proxy and normalizes incoming requests, which means
that the proxy repackages the payloads of the requests, discarding header information. This
might cause certain attacks to be discarded as part of the normalization process.
Another common attribute of IDPS technologies is that they cannot provide completely
accurate detection. When an IDPS incorrectly identifies benign activity as being malicious, a
false positive has occurred. When an IDPS fails to identify malicious activity, a false negative
has occurred. It is not possible to eliminate all false positives and negatives; in most cases,
reducing the occurrences of one increases the occurrences of the other. Many organizations
choose to decrease false negatives at the cost of increasing false positives, which means that
more malicious events are detected but more analysis resources are needed to differentiate false
positives from true malicious events. Altering the configuration of an IDPS to improve its
detection accuracy is known as tuning.
Most IDPS technologies also offer features that compensate for the use of common evasion
techniques. Evasion is modifying the format or timing of malicious activity so that its
appearance changes but its effect is the same. Attackers use evasion techniques to try to prevent
IDPS technologies from detecting their attacks. For example, an attacker could encode text
characters in a particular way, knowing that the target understands the encoding and hoping
that any monitoring IDPSs do not. Most IDPS technologies can overcome common evasion
techniques by duplicating special processing performed by the targets. If the IDPS can “see”
the activity in the same way that the target would, then evasion techniques will generally be
unsuccessful at hiding attacks.
2.3
Common Detection Methodologies
IDPS technologies use many methodologies to detect incidents. Sections 2.3.1 through 2.3.3
discuss the primary classes of detection methodologies: signature-based, anomaly-based, and
stateful protocol analysis, respectively. Most IDPS technologies use multiple detection
methodologies, either separately or integrated, to provide more broad and accurate detection.
2.3.1
Signature-Based Detection
A signature is a pattern that corresponds to a known threat. Signature-based detection is the
process of comparing signatures against observed events to identify possible incidents.5
Examples of signatures are as follows:
􀀟
A telnet attempt with a username of “root”, which is a violation of an organization’s security
policy
􀀟
An e-mail with a subject of “Free pictures!” and an attachment filename of “freepics.exe”,
which are characteristics of a known form of malware
􀀟
An operating system log entry with a status code value of 645, which indicates that the host’s
auditing has been disabled.
Signature-based detection is very effective at detecting known threats but largely ineffective at
detecting previously unknown threats, threats disguised by the use of evasion techniques, and
many variants of known threats. For example, if an attacker modified the malware in the
previous example to use a filename of “freepics2.exe”, a signature looking for “freepics.exe”
would not match it.
Signature-based detection is the simplest detection method because it just compares the current
unit of activity, such as a packet or a log entry, to a list of signatures using string comparison
operations. Signature-based detection technologies have little understanding of many network
or application protocols and cannot track and understand the state of complex communications.
For example, they cannot pair a request with the corresponding response, such as knowing that
a request to a Web server for a particular page generated a response status code of 403, meaning
that the server refused to fill the request. They also lack the ability to remember previous
requests when processing the current request. This limitation prevents signature-based
detection methods from detecting attacks that comprise multiple events if none of the events
contains a clear indication of an attack.
2.3.2
Anomaly-Based Detection
Anomaly-based detection is the process of comparing definitions of what activity is considered
normal against observed events to identify significant deviations. An IDPS using anomaly-
based detection has profiles that represent the normal behavior of such things as users, hosts,
network connections, or applications. The profiles are developed by monitoring the
characteristics of typical activity over a period of time. For example, a profile for a network
might show that Web activity comprises an average of 13% of network bandwidth at the
Internet border during typical workday hours. The IDPS then uses statistical methods to
compare the characteristics of current activity to thresholds related to the profile, such as
detecting when Web activity comprises significantly more bandwidth than expected and
alerting an administrator of the anomaly. Profiles can be developed for many behavioral
attributes, such as the number of e-mails sent by a user, the number of failed login attempts for
a host, and the level of processor usage for a host in a given period of time.
The major benefit of anomaly-based detection methods is that they can be very effective at
detecting previously unknown threats. For example, suppose that a computer becomes infected
with a new type of malware. The malware could consume the computer’s processing resources,
send large numbers of e-
5 Signature-based detection is sometimes referred to as misuse detection, but this publication
does not use that term because it implies that misuse is only detected using signatures, which
is not true. Also, signature-based detection is considered by some parties to include stateful
protocol analysis, as described in Section 2.3.3. For the purposes of this publication, signature-
based detection is defined so as not to include stateful protocol analysis, but other publications
may have different definitions.
2-4
mails, initiate large numbers of network connections, and perform other behavior that would
be significantly different from the established profiles for the computer.
An initial profile is generated over a period of time (typically days, sometimes weeks)
sometimes called a training period. Profiles for anomaly-based detection can either be static or
dynamic. Once generated, a static profile is unchanged unless the IDPS is specifically directed
to generate a new profile. A dynamic profile is adjusted constantly as additional events are
observed. Because systems and networks change over time, the corresponding measures of
normal behavior also change; a static profile will eventually become inaccurate, so it needs to
be regenerated periodically. Dynamic profiles do not have this problem, but they are
susceptible to evasion attempts from attackers. For example, an attacker can perform small
amounts of malicious activity occasionally, then slowly increase the frequency and quantity of
activity. If the rate of change is sufficiently slow, the IDPS might think the malicious activity
is normal behavior and include it in its profile. Malicious activity might also be observed by an
IDPS while it builds its initial profiles.
Inadvertently including malicious activity as part of a profile is a common problem with
anomaly-based IDPS products. (In some cases, administrators can modify the profile to exclude
activity in the profile that is known to be malicious.) Another problem with building profiles
is that it can be very challenging in some cases to make them accurate, because computing
activity can be so complex. For example, if a particular maintenance activity that performs
large file transfers occurs only once a month, it might not be observed during the training
period; when the maintenance occurs, it is likely to be considered a significant deviation from
the profile and trigger an alert. Anomaly-based IDPS products often produce many false
positives because of benign activity that deviates significantly from profiles, especially in more
diverse or dynamic environments. Another noteworthy problem with the use of anomaly-based
detection techniques is that it is often difficult for analysts to determine why a particular alert
was generated and to validate that an alert is accurate and not a false positive, because of the
complexity of events and number of events that may have caused the alert to be generated.
2.3.3
Stateful Protocol Analysis
Stateful protocol analysis is the process of comparing predetermined profiles of generally
accepted definitions of benign protocol activity for each protocol state against observed events
to identify deviations.6 Unlike anomaly-based detection, which uses host or network-specific
profiles, stateful protocol analysis relies on vendor-developed universal profiles that specify
how particular protocols should and should not be used. The “stateful” in stateful protocol
analysis means that the IDPS is capable of understanding and tracking the state of network,
transport, and application protocols that have a notion of state. For example, when a user starts
a File Transfer Protocol (FTP) session, the session is initially in the unauthenticated state.
Unauthenticated users should only perform a few commands in this state, such as viewing help
information or providing usernames and passwords. An important part of understanding state
is pairing requests with responses, so when an FTP authentication attempt occurs, the IDPS
can determine if it was successful by finding the status code in the corresponding response.
Once the user has authenticated successfully, the session is in the authenticated state, and users
are expected to perform any of several dozen commands. Performing most of these commands
while in the unauthenticated state would be considered suspicious, but in the authenticated state
performing most of them is considered benign.
6 Some vendors use the term “deep packet inspection” to refer to performing some type of
stateful protocol analysis, often combined with a firewall capability that can block
communications determined to be malicious. This publication uses the term “stateful protocol
analysis” because it is appropriate for analyzing both network-based and host-based activity,
whereas “deep packet inspection” is an appropriate term for network-based activity only. Also,
historically there has not been consensus in the security community as to the meaning of “deep
packet inspection”.
2-5
Stateful protocol analysis can identify unexpected sequences of commands, such as issuing the
same command repeatedly or issuing a command without first issuing a command upon which
it is dependent. Another state tracking feature of stateful protocol analysis is that for protocols
that perform authentication, the IDPS can keep track of the authenticator used for each session,
and record the authenticator used for suspicious activity. This is helpful when investigating an
incident. Some IDPSs can also use the authenticator information to define acceptable activity
differently for multiple classes of users or specific users.
The “protocol analysis” performed by stateful protocol analysis methods usually includes
reasonableness checks for individual commands, such as minimum and maximum lengths for
arguments. If a command typically has a username argument, and usernames have a maximum
length of 20 characters, then an argument with a length of 1000 characters is suspicious. If the
large argument contains binary data, then it is even more suspicious.
Stateful protocol analysis methods use protocol models, which are typically based primarily on
protocol standards from software vendors and standards bodies (e.g., Internet Engineering Task
Force [IETF] Request for Comments [RFC]). The protocol models also typically take into
account variances in each protocol’s implementation. Many standards are not exhaustively
complete in explaining the details of the protocol, which causes variations among
implementations. Also, many vendors either violate standards or add proprietary features, some
of which may replace features from the standards. For proprietary protocols, complete details
about the protocols are often not available, making it difficult for IDPS technologies to perform
comprehensive, accurate analysis. As protocols are revised and vendors alter their protocol
implementations, IDPS protocol models need to be updated to reflect those changes.
The primary drawback to stateful protocol analysis methods is that they are very resource-
intensive because of the complexity of the analysis and the overhead involved in performing
state tracking for many simultaneous sessions. Another serious problem is that stateful protocol
analysis methods cannot detect attacks that do not violate the characteristics of generally
acceptable protocol behavior, such as performing many benign actions in a short period of time
to cause a denial of service. Yet another problem is that the protocol model used by an IDPS
might conflict with the way the protocol is implemented in particular versions of specific
applications and operating systems, or how different client and server implementations of the
protocol interact.
2.4
Types of IDPS Technologies
There are many types of IDPS technologies. For the purposes of this document, they are divided
into the following four groups based on the type of events that they monitor and the ways in
which they are deployed:
􀀟
Network-Based, which monitors network traffic for particular network segments or devices
and analyzes the network and application protocol activity to identify suspicious activity. It can
identify many different types of events of interest. It is most commonly deployed at a boundary
between networks, such as in proximity to border firewalls or routers, virtual private network
(VPN) servers, remote access servers, and wireless networks. Section 4 contains extensive
information on network-based IDPS technologies.
􀀟
Wireless, which monitors wireless network traffic and analyzes its wireless networking
protocols to identify suspicious activity involving the protocols themselves. It cannot identify
suspicious activity in the application or higher-layer network protocols (e.g., TCP, UDP) that
the wireless network traffic is transferring. It is most commonly deployed within range of an
organization’s wireless network to
monitor it, but can also be deployed to locations where unauthorized wireless networking could
be occurring. More information on wireless IDPSs is presented in Section 5.
􀀟
Network Behavior Analysis (NBA), which examines network traffic to identify threats that
generate unusual traffic flows, such as distributed denial of service (DDoS) attacks, certain
forms of malware (e.g., worms, backdoors), and policy violations (e.g., a client system
providing network services to other systems). NBA systems are most often deployed to monitor
flows on an organization’s internal networks, and are also sometimes deployed where they can
monitor flows between an organization’s networks and external networks (e.g., the Internet,
business partners’ networks). NBA products are discussed in more detail in Section 6.
􀀟
Host-Based, which monitors the characteristics of a single host and the events occurring within
that host for suspicious activity. Examples of the types of characteristics a host-based IDPS
might monitor are network traffic (only for that host), system logs, running processes,
application activity, file access and modification, and system and application configuration
changes. Host-based IDPSs are most commonly deployed on critical hosts such as publicly
accessible servers and servers containing sensitive information. Section 7 contains additional
information on host-based IDPSs.
Some forms of IDPS are more mature than others because they have been in use much longer.
Network-based IDPS and some forms of host-based IDPS have been commercially available
for over ten years. Network behavior analysis software is a somewhat newer form of IDPS that
evolved in part from products created primarily to detect DDoS attacks, and in part from
products developed to monitor traffic flows on internal networks. Wireless technologies are a
relatively new type of IDPS, developed in response to the popularity of wireless local area
networks (WLAN) and the growing threats against WLANs and WLAN clients.
2.5
Summary
Intrusion detection is the process of monitoring the events occurring in a computer system or
network and analyzing them for signs of possible incidents, which are violations or imminent
threats of violation of computer security policies, acceptable use policies, or standard security
practices. Intrusion prevention is the process of performing intrusion detection and attempting
to stop detected possible incidents. Intrusion detection and prevention systems (IDPS) are
primarily focused on identifying possible incidents, logging information about them,
attempting to stop them, and reporting them to security administrators. In addition,
organizations use IDPSs for other purposes, such as identifying problems with security
policies, documenting existing threats, and deterring individuals from violating security
policies. IDPSs have become a necessary addition to the security infrastructure of nearly every
organization.
There are many types of IDPS technologies, which are differentiated primarily by the types of
events that they can recognize and the methodologies that they use to identify possible
incidents. This publication discusses the following four types of IDPS technologies:
􀀟
Network-Based, which monitors network traffic for particular network segments or devices
and analyzes the network and application protocol activity to identify suspicious activity.
􀀟
involving the wireless networking protocols themselves.
􀀟
Network Behavior Analysis (NBA), which examines network traffic to identify threats that
generate unusual traffic flows, such as DDoS attacks, scanning, and certain forms of malware.
􀀟
Host-Based, which monitors the characteristics of a single host and the events occurring within
that host for suspicious activity.
IDPSs typically record information related to observed events, notify security administrators
of important observed events, and produce reports. Many IDPSs can also respond to a detected
threat by attempting to prevent it from succeeding. They use several response techniques,
which involve the IDPS stopping the attack itself, changing the security environment (e.g.,
reconfiguring a firewall), or changing the attack’s content.
IDPSs cannot provide completely accurate detection; they all generate false positives
(incorrectly identifying benign activity as malicious) and false negatives (failing to identify
malicious activity). Many organizations choose to tune IDPSs so that false negatives are
decreased and false positives increased, which necessitates additional analysis resources to
differentiate false positives from true malicious events. Most IDPSs also offer features that
compensate for the use of common evasion techniques, which modify the format or timing of
malicious activity to alter its appearance but not its effect, to attempt to avoid detection by
IDPSs.
Most IDPSs use multiple detection methodologies, either separately or integrated, to provide
more broad and accurate detection. The primary classes of detection methodologies are as
follows:
􀀟
Signature-based, which compares known threat signatures to observed events to identify
incidents. This is very effective at detecting known threats but largely ineffective at detecting
unknown threats and many variants on known threats. Signature-based detection cannot track
and understand the state of complex communications, so it cannot detect most attacks that
comprise multiple events.
􀀟
Anomaly-based detection, which compares definitions of what activity is considered normal
against observed events to identify significant deviations. This method uses profiles that are
developed by monitoring the characteristics of typical activity over a period of time. The IDPS
then compares the characteristics of current activity to thresholds related to the profile.
Anomaly-based detection methods can be very effective at detecting previously unknown
threats. Common problems with anomaly-based detection are inadvertently including
malicious activity within a profile, establishing profiles that are not sufficiently complex to
reflect real-world computing activity, and generating many false positives.
􀀟
Stateful protocol analysis, which compares predetermined profiles of generally accepted
definitions of benign protocol activity for each protocol state against observed events to
identify deviations. Unlike anomaly-based detection, which uses host or network-specific
profiles, stateful protocol analysis relies on vendor-developed universal profiles that specify
how particular protocols should and should not be used. It is capable of understanding and
tracking the state of protocols that have a notion of state, which allows it to detect many attacks
that other methods cannot. Problems with stateful protocol analysis include that it is often very
difficult or impossible to develop completely accurate models of protocols, it is very resource-
intensive, and it cannot detect attacks that do not violate the characteristics of generally
acceptable protocol behavior.
3.
IDPS Technologies
This section provides an overview of IDPS technologies. The information presented in this
section applies to all types of IDPS products; additional information specific to each product
type is presented in Sections 4 through 7. This section first covers the major components of
IDPS technologies and explains the architectures typically used for deploying the components.
It also provides a high-level description of the security capabilities of the technologies,
including the methodologies they use to identify suspicious activity. The rest of the section
discusses the management capabilities of the technologies, including detailed
recommendations for implementation and operation.
3.1
Components and Architecture
This section describes the major components of IDPS solutions and illustrates the most
common network architectures for these components.
3.1.1
Typical Components
The typical components in an IDPS solution are as follows:
􀀟
Sensor or Agent. Sensors and agents monitor and analyze activity. The term sensor is typically
used for IDPSs that monitor networks, including network-based, wireless, and network
behavior analysis technologies. The term agent is typically used for host-based IDPS
technologies.
􀀟
Management Server. A management server is a centralized device that receives information
from the sensors or agents and manages them.7 Some management servers perform analysis
on the event information that the sensors or agents provide and can identify events that the
individual sensors or agents cannot. Matching event information from multiple sensors or
agents, such as finding events triggered by the same IP address, is known as correlation.
Management servers are available as both appliance and software-only products. Some small
IDPS deployments do not use any management servers, but most IDPS deployments do. In
larger IDPS deployments, there are often multiple management servers, and in some cases there
are two tiers of management servers.
􀀟
Database Server. A database server is a repository for event information recorded by sensors,
agents, and/or management servers. Many IDPSs provide support for database servers.
􀀟
Console. A console is a program that provides an interface for the IDPS’s users and
administrators. Console software is typically installed onto standard desktop or laptop
computers. Some consoles are used for IDPS administration only, such as configuring sensors
or agents and applying software updates, while other consoles are used strictly for monitoring
and analysis. Some IDPS consoles provide both administration and monitoring capabilities.
3.1.2
Network Architectures
IDPS components can be connected to each other through an organization’s standard networks
or through a separate network strictly designed for security software management known as a
management network. If a management network is used, each sensor or agent host has an
additional network interface known as a management interface that connects to the
management network. Also, each sensor or agent host is unable to pass any traffic between its
management interface and any of its other network interfaces. The
7 Because this publication focuses on enterprise IDPS deployment, it assumes that management
servers are used with sensors and agents. However, some types of IDPS sensors and agents can
be deployed standalone, and managed and monitored directly by administrators without using
a management server.
3-1
management servers, database servers, and consoles are attached to the management network
only. This architecture effectively isolates the management network from the production
networks. The benefits of doing this are to conceal the existence and identity of the IDPS from
attackers; to protect the IDPS from attack; and to ensure that the IDPS has adequate bandwidth
to function under adverse conditions (e.g., worm attack or distributed denial of service [DDoS]
on the monitored networks). Disadvantages of using a management network include the
additional costs in networking equipment and other hardware (e.g., PCs for the consoles) and
the inconvenience for IDPS users and administrators of using separate computers for IDPS
management and monitoring.
If an IDPS is deployed without a separate management network, another way of improving
IDPS security is to create a virtual management network using a virtual local area network
(VLAN) within the standard networks. Using a VLAN provides protection for IDPS
communications, but not as much protection as a separate management network. For example,
misconfiguration of the VLAN could lead to the exposure of IDPS data. Another concern is
that under adverse conditions, such as DDoS attacks or major malware incidents, the network
devices shared by the organization’s primary networks and VLAN might become completely
saturated, negatively impacting the availability and performance of the IDPS.
3.2
Security Capabilities
Most IDPS technologies can provide a wide variety of security capabilities. Sections 3.2.1
through 3.2.4 describe common security capabilities, divided into four categories: information
gathering, logging, detection, and prevention, respectively.
Some IDPS technologies offer information gathering capabilities, such as collecting
information on hosts or networks from observed activity. Examples include identifying hosts
and the operating systems and applications that they use, and identifying general characteristics
of the network.
IDPSs typically perform extensive logging of data related to detected events. This data can be
used to confirm the validity of alerts, investigate incidents, and correlate events between the
IDPS and other logging sources. Data fields commonly used by IDPSs include event date and
time, event type, importance rating (e.g., priority, severity, impact, confidence), and prevention
action performed (if any). Specific types of IDPSs log additional data fields, such as network-
based IDPSs performing packet captures and host-based IDPSs recording user IDs. IDPS
technologies typically permit administrators to store logs locally and send copies of logs to
centralized logging servers (e.g., syslog, security information and event management
software). Generally, logs should be stored both locally and centrally to support the integrity
and availability of the data (e.g., a compromise of the IDPS could allow attackers to alter or
destroy its logs).8 Also, IDPSs should have their clocks synchronized using the Network Time
Protocol (NTP) or through frequent manual adjustments so that their log entries have accurate
timestamps.9
Detection Capabilities- IDPS technologies typically offer extensive, broad detection
capabilities. Most products use a combination of detection techniques, which generally
supports more accurate detection and more flexibility in tuning and customization. The types
of events detected and the typical accuracy of detection vary greatly depending on the type of
IDPS technology. Most IDPSs require at least some tuning and customization to improve their
detection accuracy, usability, and effectiveness, such as setting the prevention actions to be
performed for particular alerts. Technologies vary widely in their tuning and customization
capabilities. Typically, the more powerful a product’s tuning and customization capabilities
are, the more its detection accuracy can be improved from the default configuration.
Organizations should carefully consider the tuning and customization capabilities of IDPS
technologies when evaluating products. Examples of such capabilities are as follows:
􀀟
Thresholds. A threshold is a value that sets the limit between normal and abnormal behavior.
Thresholds usually specify a maximum acceptable level, such as x failed connection attempts
in 60 seconds, or x characters for a filename length. Thresholds are most often used for
anomaly-based detection and stateful protocol analysis.
􀀟
Blacklists and Whitelists. A blacklist is a list of discrete entities, such as hosts, TCP or UDP
port numbers, ICMP types and codes, applications, usernames, URLs, filenames, or file
extensions, that have been previously determined to be associated with malicious activity.
Blacklists, also known as hot lists, are typically used to allow IDPSs to recognize and block
activity that is highly likely to be malicious, and may also be used to assign a higher priority
to alerts that match entries on the blacklists. Some IDPSs generate dynamic blacklists that are
used to temporarily block recently detected threats (e.g., activity from an attacker’s IP address).
A whitelist is a list of discrete entities that are known to be benign. Whitelists are typically used
on a granular basis, such as protocol-by-protocol, to reduce or ignore false positives involving
known benign activity from trusted hosts. Whitelists and blacklists are most commonly used
in signature-based detection and stateful protocol analysis.
􀀟
Alert Settings. Most IDPS technologies allow administrators to customize each alert type.
Examples of actions that can be performed on an alert type include the following:
–
Toggling it on or off10
–
Setting a default priority or severity level
–
Specifying what information should be recorded and what notification methods (e.g., e-mail,
pager) should be used
–
Specifying which prevention capabilities should be used.
Some products also suppress alerts if an attacker generates many alerts in a short period of
time, and may also temporarily ignore all future traffic from the attacker. This is to prevent the
IDPS from being overwhelmed by alerts.
􀀟
Code Viewing and Editing. Some IDPS technologies permit administrators to see some or all
of the detection-related code. This is usually limited to signatures, but some technologies allow
administrators to see additional code, such as programs used to perform stateful protocol
analysis.
10 In some IDPS technologies, turning off an alert also disables related detection capabilities;
in other products, the detection processing is still done but an alert message is not generated.
For technologies in the first category, shutting off unneeded alerts can reduce the load on the
IDPS.
Viewing the code can help analysts to determine why particular alerts were generated, helping
to validate alerts and identify false positives. The ability to edit all detection-related code and
write new code (e.g., new signatures) is necessary to fully customize certain types of detection
capabilities. For example, a particular alert might be generated by a complex series of events
involving several code modules; customizing the IDPS to understand organization-specific
characteristics might not be possible without editing the code directly. Editing the code requires
programming and intrusion detection skills; also, some IDPSs use proprietary programming
languages, which would necessitate the programmer learning a new language. Bugs introduced
into the code during the customization process could cause the IDPS to function incorrectly or
fail altogether, so administrators should treat code customization as they would any other
alteration of production systems’ code.
Administrators should review tuning and customizations periodically to ensure that they are
still accurate. For example, whitelists and blacklists should be checked regularly and all entries
validated to ensure that they are still accurate and necessary. Thresholds and alert settings might
need to be adjusted periodically to compensate for changes in the environment and in threats.
Edits to detection code might need to be replicated whenever the product is updated (e.g.,
patched, upgraded). Administrators should also ensure that any products collecting baselines
for anomaly-based detection have their baselines rebuilt periodically as needed to support
accurate detection.
Most IDPSs offer multiple prevention capabilities; the specific capabilities vary by IDPS
technology type. IDPSs usually allow administrators to specify the prevention capability
configuration for each type of alert. This usually includes enabling or disabling prevention, as
well as specifying which type of prevention capability should be used. Some IDPS sensors
have a learning or simulation mode that suppresses all prevention actions and instead indicates
when a prevention action would have been performed. This allows administrators to monitor
and fine-tune the configuration of the prevention capabilities before enabling prevention
actions, which reduces the risk of inadvertently blocking benign activity.
3.3 Management
Most IDPS products offer similar management capabilities. This section discusses major
aspects of management—implementation, operation, and maintenance—and provides
recommendations for performing them effectively and efficiently. It also briefly discusses the
skills needed for IDPS management and provides recommendations for gaining these skills.
Once an IDPS product has been selected, the administrators need to design an architecture,
perform IDPS component testing, and deploy and secure the IDPS components. Sections
3.3.1.1 through 3.3.1.3 provide more information on these actions.
3.3.1.1 Architecture Design
The first step in IDPS implementation is designing an architecture. Architectural considerations
􀀟
Where the sensors or agents should be placed
􀀟
How reliable the solution should be and what measures should be used to achieve that
reliability, such as having multiple sensors monitor the same activity in case a sensor fails, or
using multiple management servers so that a backup server can be used in case the primary
server fails
􀀟
Where the other components of the IDPS will be located (e.g., management servers, database
servers, consoles), and how many of each component are needed to achieve the necessary
usability, redundancy, and load balancing goals
􀀟
With which other systems the IDPS needs to interface, including the following:
–
Systems to which it provides data, such as security information and event management
software, centralized log servers, e-mail servers, and paging systems
–
Systems on which it initiates prevention responses (e.g., firewalls, routers, switches)
–
Systems that manage IDPS components, such as network management software (for a
management network) or patch management software (for keeping consoles’ operating systems
and applications fully up-to-date)
􀀟
Whether or not a management network will be used; if so, what its design will be, and if not,
how the IDPS communications will be protected on the standard networks
􀀟
What other security controls and technologies need to be altered to accommodate IDPS
deployment, such as changing firewall rulesets to allow IDPS components to communicate.
3.3.1.2 Component Testing and Deployment
Organizations should consider implementing the components in a test environment first,
instead of a production environment, to reduce the likelihood of implementation problems
disrupting the production networks. When the components are being deployed to production
networks, organizations should initially activate only a few IDPS sensors or agents, with their
prevention capabilities disabled. Because a new deployment is likely to generate a large
number of false positives until fully tuned and customized, activating many sensors or agents
at once might overwhelm the management servers and consoles, making it difficult for
administrators to perform tuning and customization. Many false positives are likely to be the
same across sensors or agents, so it is helpful to identify such false positives either during the
testing process or when deploying the first few sensors or agents, so that those false positives
can be addressed before widespread deployment. A phased deployment of sensors or agents is
also helpful in identifying potential problems with scalability.
Implementing an IDPS can necessitate brief network or system outages for component
installation. As mentioned above, performing a deployment in a test environment can be very
helpful in identifying likely implementation problems, so that they can be mitigated
appropriately when the production deployment occurs.
Appliance-based IDPS components are typically simple to deploy. Administrators might need
to perform software updates or signature updates to ensure the IDPS software is current.
Otherwise, administrators usually just need to provide power and connect network cables, boot
the appliance, and perform some basic configuration (e.g., enter a product license key, assign
a name to the sensor).
Software-based IDPS components usually take more time to deploy than appliance-based
components. The organization first needs to acquire the appropriate hardware, which might
include purchasing high-bandwidth network cards and otherwise ensuring that the hardware is
robust enough for the IDPS. Next, administrators need to install an operating system (OS) that
is compatible with the IDPS software, and
then harden the host as much as possible. Hardening should include updating the OS, services,
and applications, including the IDPS software. Administrators also need to perform basic
configuration of the IDPS software, just as is done for appliance-based IDPS components.
After deploying either appliance-based or software-based IDPS components, considerable
effort may be needed to configure the products’ detection and prevention capabilities,
depending on the type of IDPS being deployed. Without performing this configuration work,
some IDPSs might be capable of detecting only a small number of older, easily identified
attacks.
Wireless and Wired Network Guide
HP all-in-one Network Guide
© Copyright 2004 Hewlett-Packard The Hewlett-Packard Company shall 3 Observe all warnings and
Development Company, L.P. not be liable for incidental or instructions marked on the
The information contained herein is consequential damages in connection product.
subject to change without notice. with, or arising out of the furnishing, 4 Unplug this product from wall
performance, or use of this document outlets before cleaning.
Reproduction, adaptation or translation
and the program material which it 5 Do not install or use this product
without prior written permission is
describes. near water or when you are wet.
prohibited, except as allowed under
copyright laws. Note: Regulatory information can be 6 Install the product securely on a
found in the technical information stable surface.
This product incorporates Adobe’s PDF
chapter of this guide. 7 Install the product in a protected
technology, which contains an
implementation of LZW licensed under location where no one can step
U.S. Patent 4,558,302. on or trip over the line cord, and
where the line cord will not be
damaged.
8 If the product does not operate
normally, see the onscreen
It is not lawful in many places to make
Troubleshooting Help.
copies of the following items. When in
doubt, check with a legal 9 No operator-serviceable parts
representative first. inside. Refer servicing to
qualified service personnel.
Adobe and the ● Governmental paper or
10 Use in a well-ventilated area.
Acrobat logo are either registered documents:
trademarks or trademarks of Adobe – Passports
Systems Incorporated in the United – Immigration papers
States and/or other countries.
– Selective service papers
Portions Copyright © 1989-2003 – Identification badges,
Palomar Software Inc. The HP Officejet cards, or insignias
5500 Series includes printer driver
● Governmental stamps:
technology licensed from Palomar
Software, Inc. www.palomar.com Postage stamps
Copyright © 1999-2003 Apple Food stamps
Computer, Inc. ● Checks or drafts drawn on
This product includes software Governmental agencies
developed by the OpenSSL Project for ● Paper currency, traveler’s
use in the OpenSSL Toolkit. (http:// checks, or money orders
www.openssl.org/)</ ● Certificates of deposit
Apple, the Apple logo, Mac, Mac logo, ● Copyrighted works
Macintosh, and Mac OS are
trademarks of Apple Computer, Inc.,
safety information
registered in the U.S. and other
Warning To prevent fire or
countries.
shock hazard, do not expose
Publication number: Q3462-90198 this product to rain or any type
First edition: July 2004 of moisture.
Windows®, Windows NT®, Windows
ME®, Windows XP®, and Windows Always follow basic safety precautions
2000® are U.S.-registered trademarks when using this product to reduce risk
of Microsoft Corporation. of injury from fire or electric shock.
Intel® and Pentium® are registered Warning Potential shock
trademarks of Intel Corporation. hazard
notice
1 Read and understand all
The only warranties for HP products
instructions in the setup poster.
and services are set forth in the
express warranty statements 2 Use only a grounded electrical
accompanying such products and outlet when connecting the
services. Nothing herein should be device to a power source. If you
construed as constituting an additional do not know whether the outlet is
warranty. HP shall not be liable for grounded, check with a qualified
technical or editorial errors or electrician.
omissions contained herein.
Contents
1 Get started.............................................................................................................3
Choose a network type...........................................................................................3
Choose a connection type......................................................................................3
Use the network management tools.......................................................................4
Switch from a USB connection to a network connection......................................... 4
Connect additional computers................................................................................5
Get HP support.......................................................................................................5
2 Choose a recommended wireless network........................................................7
Wireless connection networks................................................................................7
3 Choose a recommended Ethernet network......................................................11
Ethernet connection to a wired network with DSL or cable Internet access..........11
Ethernet connection to a wired network with modem Internet access..................12
Ethernet connection to a wired network without Internet......................................13
Ethernet connection to a wireless network...........................................................13
4 Connect to a wireless network with an access point......................................15
What you need.....................................................................................................15
Connect to the network.........................................................................................16
5 Connect to a wireless network without an access point.................................19
What you need.....................................................................................................19
Prepare your computer.........................................................................................19
Create a network profile........................................................................................ 20
Connect to the network using the Wireless Setup Wizard....................................23
6 Connect with an Ethernet cable........................................................................25
What you need.....................................................................................................25
Connect your HP all-in-one...................................................................................26
7 Install the software.............................................................................................27
For Windows.........................................................................................................27
For Macintosh.......................................................................................................28
8 Manage your network.........................................................................................29
Use the HP all-in-one control panel......................................................................29
Use the Embedded Web Server...........................................................................31
9 Network troubleshooting...................................................................................35
Wireless setup wizard troubleshooting.................................................................35
Wireless network setup troubleshooting...............................................................36
Wireless discovery troubleshooting......................................................................40
Wired network setup troubleshooting...................................................................45
Common Internet File System troubleshooting.....................................................48
a Configuration page definitions..........................................................................49
General network settings......................................................................................49
Wireless network settings.....................................................................................51
Miscellaneous.......................................................................................................53
b Glossary..............................................................................................................55
Index...........................................................................................................................57
HP all-in-one Network Guide 1

2
1 Get started
This guide complements the information in the printed Setup Guide and the User Guide
that came with your HP all-in-one. It describes how to set up your HP all-in-one in a
network, which includes configuring and connecting the device, and installing the
software. This guide also provides examples of recommended networks, network
management information, and troubleshooting tips.
Connecting your HP all-in-one to a network enables you to share your HP all-in-one and
all of its capabilities with every computer on the network. However, if you do not intend
to connect to a network and want a direct USB connection instead, please see the
Setup Guide for information.
Use this chapter to help you find information on the following topics:
● Choose a network type
● Choose a connection type
● Use the network management tools
● Switch from a USB connection to a network connection
● Connect additional computers
● Get HP support
Note For definitions of terms used in this guide, see the Glossary.
Choose a network type

The kind of network you have, or the one you plan to set up, will determine how you
connect your HP all-in-one to the network. If you already have a functioning network,
and you know the kind of connection you want to use, you can go on to the next section
and choose a connection type. However, for ideas on setting up your network, please
see Choose a recommended wireless network and Choose a recommended Ethernet
network.
Choose a connection type

There are two types of wireless network connections and one Ethernet (wired) network
connection that you can use for your HP all-in-one. Each of these is described briefly
below.
Wireless connection with an access point (infrastructure)

An infrastructure wireless network uses an access point (also known as a wireless
router) that provides a secure and flexible connection for your HP all-in-one. For
information, see Connect to a wireless network with an access point.

Chapter 1
Wireless connection without an access point (ad hoc)

An ad hoc network is a simple wireless connection without an access point. For
information, see Connect to a wireless network without an access point.
Wired connection (Ethernet)

The traditional wired network uses Ethernet cables to connect computers and devices
through a router or switch. An Ethernet network is fast, reliable, and secure. For
information, see Connect with an Ethernet cable.
Use the network management tools

For information on using the HP all-in-one management tools, see Manage your
network.
Switch from a USB connection to a network connection

If you first install your HP all-in-one with a USB connection, you can later switch to a
network connection.
To switch a USB connection to a network connection

1 Unplug the USB connection from the back of your HP all-in-one.
4
2 Connect your HP all-in-one, as described in Connect to a wireless network with an
access point, Connect to a wireless network without an access point, or Connect
with an Ethernet cable.
3 Install the software, as described in Install the software.
4 When the installation is complete, access the printer icons on your computer as
follows:
– For Windows XP: Open the Printers and Faxes folder.
– For Windows 9.x or Windows 2000: Open the Printers folder.
– For Macintosh OS X: Open the Printer Setup Utility in the Utilities list.
5 Check to see if the USB printer icon for your HP all-in-one is there. If it is, delete it.
Connect additional computers

If your HP all-in-one is connected to one of the recommended networks you can share
your HP All-in-One with additional computers on the network. For each additional
computer, you must install the HP all-in-one software, as described in Install the
software. During installation, the software will discover the SSID (network name) of the
existing network. Once you have set up your HP all-in-one on the network you will not
need to configure it again when you add additional computers.
Get HP support
For information on how to get HP customer support, please see the printed User Guide
that came with your HP all-in-one.

Chapter 1
6
2 Choose a recommended wireless
network
Use this chapter to help you identify what kind of wireless network you already have in
place or want to set up. Each network shown in this chapter uses a wireless access
point to connect the network elements. A network connected in this manner is called an
infrastructure network.
Wireless infrastructure network
If you want a wireless connection between your HP all-in-one and your computer
without using a wireless access point, see Connect to a wireless network without an
access point.
For Ethernet (wired) networks, see Choose a recommended Ethernet network.
Note For definitions of terms not defined here, see the Glossary.
Wireless connection networks

In addition to the other benefits of a network, an infrastructure mode network enables
you to share an Internet connection. A broadband Internet connection (such as cable or
DSL) is required in order to use the HP Instant Share features on your HP all-in-one.
For more information about HP Instant Share, see the printed User Guide that came
with your HP all-in-one.
We recommend the wireless LAN (local area network) configurations below to support
your HP all-in-one.

Chapter 2
Wireless connection to a wireless network with DSL or cable Internet access
A wireless router (also known as an access point) manages the network connections
and a DSL or cable modem is used to provide Internet access. If you have this
configuration, use the wireless setup wizard to connect your HP all-in-one to the router
in infrastructure mode. For connection instructions, see Connect to a wireless network
with an access point.
With this configuration, you are able to access the full functionality of your HP all-in-
one, including sharing pictures over the Internet with HP Instant Share.
Wireless connection to an all wireless network without Internet
All wireless communication between your network devices goes through an access
point (or base station). The access point acts as a central hub or gateway connecting
wireless devices. Each wireless network device must have an adapter that connects it
to the access point. This network configuration does not have Internet access. For
connection instructions, see Connect to a wireless network with an access point.
Note In order to use the HP Instant Share features on your HP all-in-one, you will need
broadband Internet access, such as cable or DSL. For more information about
HP Instant Share, see the printed User Guide that came with your HP all-in-one.
8
Wireless connection to a wired network
Your access point connects a wireless network to a wired network. In this model, your
computer is configured for wired networking and is connected with an Ethernet cable to
the access point. Your HP all-in-one is configured for infrastructure mode and its
wireless adapter transfers and receives data through the access point. A DSL or cable
modem can provide Internet access. For connection instructions, see Connect to a
wireless network with an access point.

Chapter 2
10
3 Choose a recommended
Ethernet network
Use this chapter to help you identify what kind of Ethernet network you already have in
place or want to set up. Each network shown here uses a device, such as an Ethernet
router, to connect the network elements. A network connected in this manner is called
an infrastructure network. An Ethernet network provides superior performance,
reliability, and network security.
Ethernet networks might or might not be connected to the Internet. If you place your
HP all-in-one on an Ethernet network connected to the Internet, it is recommended that
you use a gateway so that the HP all-in-one’s IP address is assigned dynamically
through Dynamic Host Configuration Protocol (DHCP). A gateway can either be a
router or a Windows computer running Internet Connection Sharing (ICS).
For wireless networks, see Choose a recommended wireless network.
We recommend the wired LAN (local area network) configurations below to support
your HP all-in-one.
Ethernet connection to a wired network with DSL or cable

Internet access
If your network has DSL or cable Internet access, you can use either a router or a
computer as the Internet gateway. With either DSL or cable, you are able to access the
full functionality of your HP all-in-one, including sharing pictures over the Internet with
HP Instant Share.
Router gateway
In this example, a router manages the network connections, and a DSL or cable modem
provides Internet access. If you use this configuration, connect your HP all-in-one to the
router with an Ethernet cable.
With this configuration, you are able to access the full functionality of the HP all-in-one,
including sharing pictures over the Internet . For connection instructions, see Connect
with an Ethernet cable.

Chapter 3
Computer gateway
In this example, the network devices are connected to a switch or router. A computer on
the network acts as the gateway between the network and the Internet. The gateway
computer uses Windows Internet Connection Sharing (ICS) or similar software to
manage the network connections and provide Internet access to the other devices.
Note If the computer acting as a gateway is turned off, the other computers on the
network will lose their Internet connection. The HP all-in-one will not support
Internet-related functions.
If you use this configuration, connect your HP all-in-one to the switch or router with an
Ethernet cable. For connection instructions, see Connect with an Ethernet cable.
Ethernet connection to a wired network with modem

Internet access
In this example, the network devices are connected to a switch or router, and a modem
(shown here connected to the computer on the left) provides Internet access. The
modem is connected to the computer using a phone cord and jack. Only one computer
has Internet access. Neither the HP all-in-one nor any of the other computers on the
network have access to the Internet. If you use this configuration, connect your HP all-
in-one to the switch or router with an Ethernet cable. For connection instructions, see
Connect with an Ethernet cable.
12
Ethernet connection to a wired network without Internet
In this example, the network devices are connected to a switch or router, and there is no
Internet connection. Devices use AutoIP, which means IP addresses are configured
automatically. If you have this configuration, connect your HP all-in-one to the switch or
router with an Ethernet cable. For connection instructions, see Connect with an
Ethernet cable.
Ethernet connection to a wireless network
Your access point connects a wired device to a wireless network. In this model, your
computer is configured for wireless networking using a wireless network adapter, and
transfers and receives data through the access point. Your HP all-in-one is configured
for wired networking and is connected with an Ethernet cable to the access point. A
DSL or cable modem can provide Internet access. For connection instructions, see
Connect with an Ethernet cable.
Note In this configuration, we recommend that you route the Internet connection
directly through the access point using an Ethernet cable.

Chapter 3
14
4 Connect to a wireless network
with an access point
Use this chapter if you want to use a wireless (802.11b or g) access point to connect
your HP all-in-one and the other network elements. When network elements are
connected through an access point, this is called infrastructure mode.
The benefits of using an access point include:
● advanced network security
● enhanced reliability
● network flexibility
● better performance, especially with 802.11 g mode
For ideas on ways you can set up a wireless network using an access point, see
Wireless connection networks.
For wireless setup without an access point, see Connect to a wireless network without
an access point.
To connect your HP all-in-one to your computer, first see the next section for the things
you will need. When you are finished connecting your HP all-in-one, you will need to
install the software as described in Install the software.
What you need

To connect your HP all-in-one to a wireless network, you will need the following things:
● A wireless 802.11b or g network that includes a wireless access point. If you are a
Macintosh owner, Apple sells an easy-to-configure access point called AirPort.
AirPort has to be connected to a Macintosh, but it accepts signals from any
802.11b-compatible wireless network card, whether PC or Macintosh-based.
● A desktop computer or laptop with either wireless networking support, or a network
interface card (NIC). You can use either an Ethernet (wired) connection or a
wireless connection from the computer to the access point. For Macintosh, wireless
network support is usually offered by AirPort card. Most Apple computers have a

Chapter 4
built-in Ethernet (wired network) port. For a wired connection, you might have to
purchase a longer Ethernet cable than the one provided.
● Broadband Internet access (recommended). If you connect your HP all-in-one on a
wireless network that has Internet access, we recommend that you use a wireless
router (access point or base station) that uses Dynamic Host Configuration
Protocol (DHCP).
Broadband Internet access is required if you want to access HP Instant Share
directly from the device. For more information on HP Instant Share, see the printed
User Guide that came with your HP all-in-one.
Connect to the network

1 Write down the following information about your access point:
– Network Name (also called SSID)
– WEP Key, WPA Password or Passkey (if needed)
If you do not know where to find this information, see the documentation that came
with your wireless access point. You might be able to find this information on the
Embedded Web Server for the access point.
Note For Macintosh users: If the network is set up with an Apple AirPort Base
station and you are using a password instead of WEP HEX or WEP ASCII to
access this network, you need to get the equivalent WEP key. Your network
administrator can get the equivalent WEP key by running the AirPort Admin
utility.
2 On the control panel of your HP all-in-one, press the Setup button.

3 Press 8, and then press 4.
This displays the Network menu and then selects Wireless Setup Wizard. The
setup wizard searches for available networks, and then displays a list of detected
network names (SSIDs). The infrastructure networks appear first in the list. The
networks with the strongest signal appear first, the weakest appear last.
4 Press to highlight the name of the network you wrote down in step 1, and then
press OK.
If you do not see your network name in the list, do the following:
a Select Enter a New Network Name (SSID). If necessary, use the to
highlight it, and then press OK.
The visual keyboard appears.
b Enter the SSID. Use the arrow buttons on the HP all-in-one control panel to
highlight a letter or number on the visual keyboard, and then press OK to
select it.
For more information on using the visual keyboard, see the printed User Guide
Note You must enter the exact uppercase (capital) and lowercase (small)
letters. Otherwise, the wireless connection will fail.
c When you are finished entering the new SSID, use the arrow buttons to
highlight Done on the visual keyboard, and then press OK.
d Press 1 to select the infrastructure mode..
16
e Press 2 to select WEP encryption.
OR
Press 3 to select WPA encryption.
5 If prompted, enter your WPA or WEP key. Use the arrow buttons to highlight a
letter or number on the visual keyboard, and then press OK to select it.
Note You must enter the exact uppercase (capital) and lowercase (small) letters.
Otherwise, the wireless connection will fail.
If a message says you entered an invalid WPA or WEP key, check the key you
wrote down for your new network, and then re-enter the key.
6 When you are finished entering the WPA or WEP key, use the arrow buttons to
7 Press OK to confirm.
The HP all-in-one will attempt to connect to the network. If the connection fails,
follow the prompts to correct the key, and then try again. See also, Network
troubleshooting
8 When the HP all-in-one connects successfully to the network, go to your computer
to install the software. See Install the software.

Chapter 4
18
5 Connect to a wireless network
without an access point
Use this chapter if you want to connect your HP all-in-one to a computer on a wireless
network without using an access point. This is sometimes called a peer-to-peer or ad
hoc network. On Macintosh networks, this is called a computer-to-computer network.
Note This type of connection is available if you do not have an access point. However,
it provides little flexibility, a low level of network security, and slower network
performance than with an access point. In addition, you will likely not have
shared broadband access (such as cable or DSL), and therefore not be able to
use the HP Instant Share feature on your HP all-in-one. For information on
connecting your HP all-in-one using an access point, see Connect to a wireless
network with an access point.
To connect your HP all-in-one to your computer, see the next section for the things you
will need. Then follow the steps in the remaining sections to do the following:
● prepare your computer
● create a wireless network profile on your computer
● connect the HP all-in-one to the wireless network
When finished, install the software as described in Install the software.
What you need

A computer with a wireless network adapter. For Macintosh, you must have an AirPort
card.
Prepare your computer

See the instructions below for your operating system.

Chapter 5
For Windows
Make sure to check the following:
● Quit all applications running on your computer, including the internal XP firewall
and any other firewall or virus detection software.
● Disable your Internet connection. If you have cable or DSL, disconnect the
Ethernet cable from the back of your computer. If you have dial-up, disconnect the
phone cord.
● Disable all LAN connections (including Ethernet) other than your wireless
connection. Also, disable all IEEE 1394 (such as Firewire, i.LINK or Lynx) to
Ethernet connections.
For Windows XP:
– Click the Windows Start button, click Control Panel, and then double-click
Network Connections.
– Right-click each Local Area Connection, and then click Disable. If you see
Enable on the pop-up menu, the Local Area Connection is already disabled.
For Macintosh
Quit all applications running on your computer.
Create a network profile

See the instructions below for your operating system.
For operating systems other than Windows XP and Mac OS X

If you have an operating system other than Windows XP or Mac OS X, we recommend
that you use the configuration program for your wireless LAN card. To find the
configuration program for your wireless LAN card, access your computer's list of
programs.
Using the LAN card configuration program, create a network profile that has the
following values:
● Network name (SSID): Mynetwork
● Communication mode: Ad Hoc
● Encryption: enabled
Note You can use a different name for your network other than the example
shown here, such as your initials. Just remember that the network name is
case sensitive. Therefore, you must remember which letters are uppercase
and lowercase.
For Windows XP
Your HP all-in-one comes configured with a network profile named hpsetup. However,
for security and privacy we recommend you create a new network profile on your
computer as described here, and then use the Wireless Setup Wizard to detect the new
network (as described in the next section).
1 Make sure you have followed all of the instructions in the previous section, Prepare
your computer.
2 In the Control Panel, double-click Network Connections.
20
3 On the Network Connections window, right-click the Wireless Network
Connection. If you see Enable on the pop-up menu, choose it. Otherwise, if you
see Disable on the menu, the wireless connection is already enabled.
4 Right-click the Wireless Network Connection icon, and then click Properties.
5 Click the Wireless Networks tab.
6 Select the Use Windows to configure my wireless network settings check box.
7 Click Add, and then do the following:
a In Network name (SSID) box, type in the name Mynetwork (or something
more meaningful, such as your initials).
Note Notice that the M in Mynetwork is uppercase (capital), and the rest of
the letters are lowercase (small). This is important to remember in case
you need to enter the SSID at a later time on the Wireless Setup
Wizard.
b If there is a Network Authentication list, select Open. Otherwise, go to the

next step.
c In the Data encryption list, select WEP.
Note It is possible to create a network that does not use a WEP key.
However, we recommend using a WEP key in order to secure your
network.
d Make sure that the check box is not selected next to The key is provided for
me automatically. If it is selected, click to clear it.
e In the Network key box, type an WEP key that has exactly 5 or exactly 13
alphanumeric (ASCII) characters. For example, if you enter 5 characters, you
might enter ABCDE or 12345. Or, if you enter 13 characters, you might enter
ABCDEF1234567.
Alternatively, you can use HEX (hexidecimal) characters for the WEP key. A
HEX WEP key must be 10 characters for 40 bit encryption, or 26 characters
for 128 bit encryption. For definitions of ASCII and HEX, see the Glossary.
f In the Confirm network key box, type the same WEP key you typed in the
previous step.
g Write down the WEP key exactly as you typed it, including uppercase and
lowercase letters.
Note You must remember the exact uppercase (capital) and lowercase
(small) letters. If you enter your WEP key incorrectly on the HP all-in-
one, the wireless connection will fail.
h Select the check box for This is a computer-to-computer (ad hoc) network;
wireless access points are not used.
i Click OK, to close the Wireless network properties window. and then click
OK again.
j Click OK again to close the Wireless Network Properties Connection
window.
8 Go to your HP all-in-one and use the Wireless Setup Wizard to connect your
HP all-in-one to the wireless network. See Connect to the network using the
Wireless Setup Wizard.

Chapter 5
For Mac OS X
Your HP all-in-one comes configured with a network profile named hpsetup. However,
for security and privacy we recommend you create a new network profile on your
Macintosh as described here, and then use the Wireless Setup Wizard to detect the new
network (as described in the next section).
To create a new network profile on your Mac OS X

1 Make sure that your AirPort is turned on.
AirPort icon
To check this, click on the Airport icon in the upper-right part of the screen.
If Turn Airport On is available, select it to turn on the AirPort.
If the AirPort icon is not present, do the following:
a On the Network Preferences screen, select Airport Panel.
b Enable Allow the computer to create networks.
c Enable Show Airport status in menu bar.
2 Click the AirPort icon.
3 Select Create Network….
4 On the Computer to Computer dialog, click in the Name box and enter a new
network name.
For example you can type the name Mynetwork (or something more meaningful,
such as your initials).
Note Notice that the M in Mynetwork is uppercase (capital), and the rest of the
letters are lowercase (small). This is important to remember in case you
need to enter the SSID at a later time on the Wireless Setup Wizard.
5 In the Channel box, use the default Automatic setting.

6 Click Show Options.
7 To enable encryption for security, select the Encryption checkbox.
8 In the Password box, type a password that has exactly 5 or exactly 13
alphanumeric (ASCII) characters. For example, if you enter 5 characters, you
might enter ABCDE or 12345. Or, if you enter 13 characters, you might enter
ABCDEF1234567.
Alternatively, you can use HEX (hexidecimal) characters for the password. A HEX
password must be 10 characters for 40 bit encryption, or 26 characters for 128 bit
encryption. For definitions of ASCII and HEX, see the Glossary.
9 In the Confirm box, type the same password.
10 Write down your password, which on your HP all-in-one is called a WEP key. You
will need your WEP key when set up you use the Wireless Setup Wizard.
11 Click OK.
12 Go to your HP all-in-one and use the Wireless Setup Wizard to connect your
HP all-in-one to the wireless network. See Connect to the network using the
Wireless Setup Wizard.
22
Connect to the network using the Wireless Setup Wizard
1 On the control panel of your HP all-in-one, press the Setup button.
This displays the Network menu and then selects Wireless Setup Wizard. The
setup wizard searches for available networks, and then displays a list of detected
network names (SSIDs).
3 On the color graphics display, look for the network name you created on your
computer (for example, Mynetwork).
4 Use the arrow keys to highlight the network name, and then press OK.
If you found your network name and selected it, go on to step 5. However, if you do
not see your network name in the list, do the following:
a Select Enter a New Network Name (SSID).
The visual keyboard appears.
b Enter the SSID. Use the arrow buttons on the HP all-in-one control panel to
highlight a letter or number on the visual keyboard, and then press OK to
select it.
For more information on using the visual keyboard, see the printed User Guide
Note You must enter the exact uppercase (capital) and lowercase (small)
letters. Otherwise, the wireless connection will fail.
c When you are finished entering the new SSID, use the arrow buttons to
d Press 2 to select ad hoc mode.
e Press 2 to select Yes, my network uses WEP encryption and display the
visual keyboard.
If you do not want to use WEP encryption, press 1 to select No, my network
does not use encryption. When the Confirm Settings screen appears, press
OK, and then go to step 8.
5 (Do this step only if you have a WEP key. If you do not have a WEP key, go to step
8.) Enter your WEP key. Use the arrow buttons to highlight a letter or number on
the visual keyboard, and then press OK to select it.
Note You must enter the exact uppercase (capital) and lowercase (small) letters.
Otherwise, the wireless connection will fail.
If a message says you entered an invalid WEP key, check the key you wrote down
for your new network, and then re-enter the WEP key.
6 When you are finished entering the WEP key, use the arrow buttons to highlight
Done on the visual keyboard, and then press OK.
7 Press OK to confirm.
The HP all-in-one will attempt to connect to the SSID. If the connection fails, follow
the prompts to correct the WEP key, and then try again.
8 When the HP all-in-one connects successfully to the network, go to your computer
to install the software. See Install the software.
Note If you encounter a problem, please see Network troubleshooting.

Chapter 5
24
6 Connect with an Ethernet
cable
Use this chapter to connect your HP all-in-one to a router, switch, or access point using
an Ethernet cable.
For ideas on how to set up a wired network, see Choose a recommended Ethernet
network.
To connect your HP all-in-one to your computer, first see the next section for the things
you will need. When you are finished connecting your HP all-in-one, you will need to
install the software as described in Install the software.
What you need

● A functional Ethernet network that includes an Ethernet router, switch, or a wireless
access point with Ethernet ports.
● CAT-5 Ethernet cable. If the Ethernet cable provided is not long enough for your
network configuration, you might need to purchase a longer cable.
Although standard Ethernet cables look similar to standard telephone cables, they
are not interchangeable. There is a different number of wires in each one, and each
has a different connector. An Ethernet cable connector (also called an RJ-45
connector) is wider and thicker and always has 8 contacts on the end. A phone
connector has between 2 and 6 contacts.
● A desktop computer or laptop with either a wired or wireless connection to the
router or access point.

Chapter 6
Note The HP all-in-one supports both 10 Mbps and 100 Mbps Ethernet networks.
If you are purchasing, or have purchased, a network interface card (NIC),
make sure it can operate at either speed.
● Broadband Internet access such as cable or DSL (only if you want to access
HP Instant Share directly from the device). For more information on HP Instant
Share, see the printed User Guide that came with your HP all-in-one.
Connect your HP all-in-one

1 Remove the yellow plug from the back of the HP all-in-one.
2 Connect the Ethernet cable to the Ethernet port on the back of your HP all-in-one.
3 Connect the other end of the Ethernet cable to an available port on your Ethernet
router, switch, or wireless access point.
4 Once you have connected the HP all-in-one to the network, go to your computer to
install the software. See Install the software.
26
7 Install the software
Use this chapter to install your HP all-in-one software on either a Windows or Macintosh
computer. However, before you install the software, make sure you have connected
your HP all-in-one as described in one of the previous chapters.
Note 1 If you intend to use multiple WEP keys, or advanced authentication protocols
(EAP/802.1x or EAP-PSK) and encryption methods (WPA), use the Embedded
Web Server to configure your wireless settings prior to software installation.
For more information, see Use the Embedded Web Server.
Note 2 If your computer is configured to connect to a series of network drives, make

sure that your computer is currently connected to these drives before installing
the software. Otherwise, HP all-in-one installation software might take one of
the reserved drive letters, and you will not be able to access that network drive
on your computer.
See the instructions below for your Windows or Macintosh computer.
For Windows
The following instructions are for Windows computers only.
Note Installation time can range from 20 to 45 minutes depending on your operating
system, the amount of available space, and the processor speed of your
computer.
To install your HP all-in-one software

1 Quit all applications running on your computer, including the internal XP firewall
and any other firewall or virus detection software.
2 Insert the Windows CD that came with your HP all-in-one into your computer's
CD-ROM drive.
The Welcome screen appears.
Note Windows XP only: If the startup screen does not appear, double-click My
Computer, double-click the CD-ROM icon, and then double-click setup.exe.
3 Click Next on the installation screens for checking and preparing the system, and
for installing drivers, plug-ins, and software.
After several screens, the Connection Type screen appears.
4 On the Connection Type screen, select Through the network, and then click
Next.
The Searching screen appears as the Setup program searches for your HP all-in-
one on the network.
5 On the Printer Found screen, verify that the printer description is correct.
If more than one printer is found on the network, the Printers Found screen
appears. Select the device you wish to connect.
To see the device settings on your HP all-in-one:
a Go to the control panel on your device.

Chapter 7
b Select View Network Settings on the Network Menu, and then select
Display Summary.
Note If the software is unable to find the HP all-in-one, see The Printer Not Found
screen appears during installation.
6 If the device description is correct, select Yes, install this printer.

7 At the prompt, restart your computer to finish the installation process.
When you have finished installing the software, your HP all-in-one is ready for
service.
8 To test your network connection, go to your computer and print a test page to your
HP all-in-one. For more information, see the printed User Guide that came with
yourHP all-in-one.
For Macintosh
The following instructions are for Macintosh computers only.
Note Installation time can range from 20 to 45 minutes depending on your operating
system, the amount of available space, and the processor speed.
To install your HP all-in-one software

1 Quit all applications running on your computer.
2 Insert the Macintosh CD that came with your HP all-in-one into your computer's
CD-ROM drive.
3 Double-click the HP all-in-one installer icon.
Macintosh installer icon
4 On the Authentication screen, enter the Administrator pass phrase used to access
your computer or network.
The installer software looks for HP all-in-one devices, and then lists them.
5 On the Select Device, select your HP all-in-one.
6 Follow the onscreen instructions to complete all the installation steps, including the
Setup Assistant.
When you have finished installing the software, your HP all-in-one is ready for
service.
7 To test your network connection, go to your computer and print a test page to your
HP all-in-one. For more information, see the printed User Guide that came with
your device.
28
8 Manage your network
This chapter describes how to use the network tools on the device control panel and the
Embedded Web Server. These tools enable you to view and edit network settings, and
add advanced security to your network.
Use the HP all-in-one control panel

The HP all-in-one control panel enables you to perform a variety of network
management tasks, including viewing the network settings, restoring the network
defaults, and turning the wireless radio on and off, and changing the network settings.
View network settings

You can display a summary of the network settings on the device control panel. Or you
can print a more detailed configuration page.
Display a network summary

Choose whether to display a network summary or print a detailed report.
To display a network summary

1 On the control panel of the HP all-in-one, press the Setup button.
This displays the Network Menu and then selects View Network Settings.
3 Press 2.
This displays a summary of the network settings.
Print and view a network configuration page

The Network Configuration Page lists all of the important network settings such as the
IP address, link speed, DNS, and DNS-SD.
To print a network configuration page

This displays the Network Menu and then selects View Network Settings.
3 Press 1.
This prints the network configuration page.
For definitions of the items on the configuration page, see Configuration page
definitions.
Restore network defaults

If necessary, you can reset the HP all-in-one network to factory defaults.
Note This will erase all wireless setup information that you have entered. In order to
restore this information, you will need to use the Wireless Setup Wizard again.

Chapter 8
To reset to factory defaults

This displays the Network menu and then selects Restore Network Defaults.
3 Press 1 to confirm.
Turn the wireless radio on and off

The wireless radio is on by default, as indicated by the blue light on the front of the
HP all-in-one. In order to stay connected to the network, the radio must stay on.
However, if your HP all-in-one is not connected to a network and you only have a USB
connection, the radio is not used. In this case you might want to turn the radio off.
To turn the wireless network radio on

2 Press 8, press 5, and then press 1.
To turn the wireless network radio off

Advanced network settings

The Advanced Setup options enable you to change link speed, IP settings, and
memory card security.
Note Unless you are an advanced user, you should not change any of these settings.
Set link speed

You can change the speed at which data is transmitted over the network. The default is
Automatic.
To set the link speed

This displays the Network menu and then selects Advanced Setup.
3 Press 1 to select Change Link Speed.
4 Press the number next to the link speed:
– 1. Automatic
– 2. 10-Full
– 3. 10-Half
– 4. 100-Full
– 5. 100-Half
Change IP settings
The default IP setting is Automatic. However, if necessary, you can manually change
the IP address, subnet mask, or the default gateway. To see the IP address and subnet
mask of your HP all-in-one, print a network configuration page from your HP all-in-one
30
(see Print and view a network configuration page). For a description of the items on the
configuration page, including the IP address and subnet mask, see Configuration page
definitions.
To change an IP setting
This displays the Network menu and then selects Advanced Setup.
3 Press 2 to select IP Settings.
4 Press the number next to the IP setting:
– 1. IP Address
– 2. Subnet Mask
– 3. Default Gateway
5 Enter your changes, and then press OK when done.
Change memory card security

The Memory Card Security option on the Advanced Setup menu enables you to set
the HP all-in-one so that it does not share memory card data with computers on a
wireless network. However, we do not recommended this security method for your
memory card because it prevents you from accessing your memory card from your
computer. Also, this feature does not work on an Ethernet network. All computers on an
Ethernet network can access the memory card on a HP all-in-one connected to the
network.
If you want security for your memory card, we recommend using WEP or WPA-PSK
security on your network. For more information on memory card security, see the
printed User Guide that came with your HP all-in-one. For information on setting up
your wireless network using security, see Connect to a wireless network with an access
point and Connect to a wireless network without an access point. See also Add security
to the network.
Use the Embedded Web Server

The best way to manage the general network settings for the HP all-in-one is through
the HP all-in-one control panel. However, for more advanced settings you can use the
Embedded Web Server (EWS). When you open the your web browser, you can monitor
status, configure HP all-in-one networking parameters, or access HP all-in-one
features. For more information about these and other features available in the EWS,
see the onscreen Help within the Embedded Web Server. To access Embedded Web
Server help, open the Embedded Web Server as described below, then click the Help
link under Other Links on the Embedded Web Server Home tab.
Access the Embedded Web Server

To access the Embedded Web Server
This prints configuration page for your HP all-in-one, including the IP address. You
will use the IP address in the next step.

Chapter 8
3 In the Address box in your web browser, enter the IP address of the HP all-in-one,
as shown on the network configuration page. For example, http://195.168.0.5.
The Embedded Web Server Home page appears, showing the HP all-in-one device
information.
Note If you are using a proxy server in your browser, you might need to disable it
to access the Embedded Web Server.
4 If you need to change the language displayed in the Embedded Web Server, do the
following:
a Click the Settings tab.
b Click Select Language in the Settings navigation menu.
c In the Select Language list, click the appropriate language.
d Click Apply.
5 Click the Home tab to access device and network information, or click the
Networking tab to access more network information or to modify network
information.
Caution Be very careful when changing the wireless network settings for the
print server; you could lose your network connection. If you lose your network
connection, you might need to use the new settings to reconnect. If the print
server loses its network connection, you might need to reset it to factory-default
and reinstall the software.
Note Do not disable TCP/IP (Transmission Control Protocol/Internet Protocol) on your

computer. It is required for communication with the Embedded Web Server.
Add security to the network

As with other networks, security for wireless local area networks (WLANs) focuses on
access control and privacy. Traditional WLAN security includes the use of Service Set
Identifiers (SSIDs), open or shared-key authentication, static Wired Equivalent Privacy
(WEP) keys, and optional Media Access Control (MAC) authentication. This
combination offers a rudimentary level of access control and privacy.
If you are using an access point, you might also employ advanced forms of
authentication and encryption on the WLAN, such as the Pre-Shared Key mode of Wi-
Fi Protected Access (WPA-PSK). For definitions of any terms not defined here, see the
Glossary.
To protect your wireless network, HP strongly suggests you implement a wireless
security scheme (either WEP or WPA) during setup, use an antivirus program to
protect against computer viruses, and follow basic security rules such as setting strong
passwords and not opening unknown attachments. Other network components,
including firewalls, intrusion-detection systems, and segmented networks, should also
be considered as part of your network design.
Note If you decide to add encryption and authentication to your network after installing
the HP all-in-one, change the settings on your HP all-in-one prior to changing
them on other devices on your network.
32
To add WPA-PSK security
Note You will lose the connection to the HP all-in-one until the encryption/
authentication settings are applied to the rest of the devices on the network.
1 Quit all applications running on your computer. On a Windows computer, this

includes any firewall or virus detection software.
2 Set up WPA-PSK on your wireless access point, router, or gateway.
3 Set up WPA-PSK on any wireless computer that will be on the same wireless
network.
4 Open the Embedded Web Server, as described in Access the Embedded Web
Server.
5 Click the Networking tab.
The Device page appears.
6 In the Connections navigation menu, choose Wireless (802.11).
7 Click Start Wizard.
The Wireless Network Name page appears.
8 Click a network name (SSID) from the list of detected networks, or enter the name
of a new wireless network.
9 Click Next.
10 Click Infrastructure, and then click Next.
The Wireless Authentication page appears.
11 Click WPA-PSK, and enter a WPA Password (from 8 to 63 characters in length,
including spaces) that will be used by the software to generate a pre-shared key.
12 Click Next.
The configuration review page appears.
13 Verify that the information is accurate, and then click Finish.
14 Configure your HP all-in-one for advanced authentication and security schemes as
appropriate.
To add WEP encryption
Note You will lose the connection to the HP all-in-one until the encryption/
authentication settings are applied to the rest of the devices on the network.
1 Set up WEP on your wireless access point, gateway, or router.

2 Set up WEP on any wireless computer that will be on the same wireless network.
3 Open the Embedded Web Server, as described in Access the Embedded Web
Server.
The Device page appears.
5 In the Connections navigation menu, choose Wireless (802.11).
The Wireless Network Name page appears.
7 Click a network name (SSID) from the list of detected networks, or enter the name
of a new wireless network.
8 Click Next.
9 Click Infrastructure, and then click Next.
The Wireless Authentication page appears.

Chapter 8
10 Click Open/Shared System, and then click Next.

11 Click Encryption, and then click Next.
12 Enter the WEP key in the WEP Key box and in the Confirm WEP Key box.
13 Click Next.
14 Confirm the settings, and then click Finish.
34
9 Network troubleshooting
This section contains network troubleshooting information for the HP all-in-one. Specific
information is provided for installation and configuration issues.
For wired issues, see Wired network setup troubleshooting.

For file system issues, see Common Internet File System troubleshooting.
Wireless setup wizard troubleshooting

This section addresses problems you might encounter using the wireless setup wizard.
For more information on wireless network setup and device discovery, see Wireless
network setup troubleshooting and Wireless discovery troubleshooting.
Error message: Cannot connect to network
Cause
The equipment is not turned on.
Solution
Turn on the networked devices, such as the access point for an infrastructure
network, or the computer for an ad hoc network.
Cause
The HP all-in-oneNo is not receiving a signal.
Solution
Move the access point and the HP all-in-one closer together. Then run the HP all-
in-one wireless setup wizard again. For more information, see Setup failed.
Cause
You have entered the SSID incorrectly.
Solution
Enter the SSID correctly. Remember that the SSID is case sensitive.
Cause
You entered the wrong mode (ad hoc or infrastructure) or security type.
Solution
Enter the correct mode or security type.
Error message: Cannot connect to network. Unsupported authentication or

encryption type.

Chapter 9
Cause
Your network is configured with an authentication protocol not supported by the
installation software.
Solution
Use one of the supported protocol types listed in the Embedded Web Server.
Types not supported include: WPA2-AES, WPA2-TKIP, LEAP, PEAP, EAP-MD5,
EAP-TLS, or EAP-TTLS.
Error message: Invalid passkey.
Cause
You have entered the WPA passkey incorrectly.
Solution
Enter the correct passkey, making sure it has between 8 and 63 characters.
Cause
I don't know the WEP key, or what to enter for the WPA passkey.
Solution
See the documentation that came with your access point. The WEP key is stored
within the access point. Usually you can find the WEP key by logging on to the
access point through your computer.
You don't see the SSID
Cause
Your access point is not broadcasting its network name (SSID), or the access point
is out of range.
Solution
Use the Enter a New Network Name (SSID) option in the Wireless Setup Wizard.
For more information, see Connect to the network. Also, see the user guide that
came with your access point and check the access point settings.
Cause
The SSID is out of sight at the bottom of the list.
Solution
Press to scroll to the bottom of the list. Infrastructure entries are listed first, ad
hoc last.
Wireless network setup troubleshooting

Use this section to solve wireless network setup problems.
36
I received a System Requirements Error: No TCP/IP
Cause
Your Local Area Network (LAN) card (NIC) is not installed properly.
Solution
Make sure your LAN card is installed properly and set up for TCP/IP. See the
instructions that came with your LAN card.
The Printer Not Found screen appears during installation
Cause
The software failed to find the network.
Solution
Use the installation software to specify the HP all-in-one by its IP address as
follows:
1 On the Printer Not Found screen, click Next.
2 On the Connection Type screen, select Wired Network (not Wireless).
3 On the Check Cable Connection screen, select Specify a printer by
address.
This displays a summary of the HP all-in-one network settings on the color
graphics display, including the IP address. You will use the IP address in the
next step.
6 On the Specify Printer screen, select IP Address, and enter the IP address
for your HP all-in-one.
7 Continue to click Next on the screens that follow. Do not select Change
Settings or plug in a cable to the device. This will cause device discovery to
fail.
Cause
The HP all-in-one is not turned on.
Solution
Turn on the HP all-in-one.
Cause
You do not have an active network connection.
Solution
Make sure that you have an active network connection.

Chapter 9
To check your network connection

1 Check the radio on indicator light on the lid of your HP all-in-one to see
whether the radio is on.
2 If the indicator light is off, do the following:
a On the control panel of the HP all-in-one, press the Setup button.
b Press 8, press 5, and then press 1.
3 If the radio is on, or goes on as a result of step 2, press the On button to turn
off the HP all-in-one, and then press it again to turn it on. Also, turn off the
power on your router and then turn it on again.
Cause
There is radio interference.
Solution
If there is a long distance between your computer and the HP all-in-one, move them
closer together. If possible, provide a clear path between the computer and print
server, and minimize sources of radio interference. Devices such as cordless
phones and microwave ovens may also cause radio interference.
Unable to determine or verify network name during installation
Cause
Setup has either detected multiple networks or has been unable to read or verify
the network name from the access point.
Solution
Select a new network name (SSID).
To select a new network name, do one of the following

● In the Select Network Name screen, enter a new SSID. If you choose to
enter the wireless Network Name (SSID), also select the Communication
Mode (ad hoc or Infrastructure).
Note The SSID entry is case-sensitive, and it can be up to 32 alphanumeric

characters long, including spaces. You cannot leave the Network Name
box blank.
● In the Select Network Name screen, select an existing network name from the
list. Up to 12 SSIDs might be listed. The SSIDs are detected when the internal
networking component boots up.
Verification fails at end of installation
Cause
You might not have the correct wireless authentication or encryption type selected.
You might be using an unsupported authentication or encryption type.
38
Solution
Add encryption security to your network. For information, see Add security to the
network.
Cause
Your SSID or WEP key might be set incorrectly.
Solution
You can use either the Embedded Web Server or the control panel to change the
SSID or WEP.
To use the control panel

This displays the Network menu and then selects Wireless Setup Wizard.
3 Press to highlight your network, and then press OK.
4 When prompted, use the visual keyboard to enter the new Network Name and
WEP key.
5 Complete the Wireless Setup Wizard.
To use the Embedded Web Server

1 With an Ethernet cable attached, print a network configuration page. For
information, see Print and view a network configuration page.
2 Make sure the network SSID and WEP key shown on the configuration page
match those used on your wireless network.
3 If one or both are incorrect, enter either the URL or device IP address from the
configuration page into the Address box on your Web browser. For example,
http://195.168.0.5.
The HP all-in-one Embedded Web Server Home page appears.
5 In the Connections navigation menu, click Wireless.
7 Enter the correct values in the appropriate sections (Network Name and
Encryption).
8 Click Apply.
Cause
You are using an authentication protocol not supported by the installation
software.
Solution
Use one of the supported protocol types listed in the Embedded Web Server.
Types not supported include: WPA2-AES, WPA2-TKIP, LEAP, PEAP, EAP-MD5,
EAP-TLS, or EAP-TTLS.

Chapter 9
Cause
Your network uses multiple WEP keys, and you have chosen the wrong key for
transmitting.
Solution
Choose the correct WEP key using the Embedded Web Server. For information,
see Add security to the network
Setup failed
Cause
The HP all-in-one is not receiving a signal.
Solution
In order to establish a good signal between the HP all-in-one and access point
(infrastructure) or computer (ad hoc), you might have to experiment a bit. Assuming
the equipment is functioning properly, try doing the following things separately or in
combination:
● If there is a long distance between your computer or access point and the
HP all-in-one, move them closer together. Also, be aware that the HP all-in-
one broadcasts to the front, back and above. Therefore, do not place an
access point directly below the HP all-in-one. If the HP all-in-one is on the
second floor of a two-story house, and you must put the access point on the
first floor, place the HP all-in-one and access point on opposite ends of the
house or as far apart laterally as possible.
● If there are objects in the transmission path, clear the path between the
HP all-in-one and the computer or access point.
● If a cordless telephone, microwave, or other device that emits radio signals is
nearby, move it farther away to reduce radio interference.
40
Wireless discovery troubleshooting
Use this section to solve problems with wireless networks that have an access point.
The computer is unable to discover the HP all-in-one
Cause
Your cables are not connected properly.
Solution
Check the following cables to ensure they are connected properly:
● Power cords to the HP all-in-one and the router
● Cables between the router and your computer (if applicable)
● Cables to and from your modem or HP all-in-one Internet connection (if
applicable)
Cause
The network connection is not active.
Solution
Check to see if you have an active network connection.
To make sure your network connection is active

1 Check the radio on light on the front of your HP all-in-one. If the light is solid
blue, the wireless radio is on. This light does not indicate whether or not the
HP all-in-one is connected to the network.
2 If the wireless radio is on, check the color graphics display to see if the
wireless network icon is active.
Network icon
The icon on the left shows an active wireless network. The icon on the right
shows an inactive wireless network.
If the wireless network icon is not active, make sure all cable connections are
secure. This includes connections from your cable or DSL modem, gateway,
or router.
3 If the HP all-in-one is connected to the network, check the signal strength on
the wireless network icon to make sure there is a strong signal.
4 If the network light is off, check cable connections from the HP all-in-one to
your gateway or router to ensure connections are secure.
5 If the connections are secure, press the On button to turn off the HP all-in-
one, and then press it again to turn it on. Also, turn off the power on your
router and then turn it on again.

Chapter 9
Cause
The firewall is preventing the HP all-in-one from accessing your computer.
Solution
Try temporarily disabling the firewall to determine whether the firewall is preventing
the HP all-in-one from accessing your computer. If the firewall is preventing
access, grant access permission to the HP all-in-one.
The HP all-in-one cannot find the WLAN/access point (infrastructure)
Cause
Your access point is not broadcasting its network name (SSID).
Solution
Verify your access point is broadcasting its network name (SSID).
Cause
Setup has failed.
Solution
Turn off the access point, and then turn it on again. Then uninstall and reinstall the
HP all-in-one software.
For more information on uninstalling and reinstalling the software, see the printed
Cause
The access point is out of range.
Solution
Move the access point and the HP all-in-one closer together. Then uninstall and
reinstall the HP all-in-one software.
Cause
The access firmware needs updating.
Solution
Check for firmware updates for your access point on the manufacturer's website.
Update the firmware on the access point. Then uninstall and reinstall the HP all-in-
one software.
42
When using the control panel to scan to a computer on the network, the HP all-
in-one cannot find my computer (infrastructure)
Cause
Your wireless network is not functioning.
Solution
Make sure that your access point is turned on and functioning properly. And make
sure that your computer is communicating with the access point.
Cause
The HP all-in-one and computer are on different networks.
Solution
Make sure that your HP all-in-one and computer are on the same network by
verifying that they both have the same IP address and subnet mask. To see the IP
address and subnet mask of your HP all-in-one, print a network configuration page
from your HP all-in-one (see Print and view a network configuration page). For a
description of the items on the configuration page, including the IP address and
subnet mask, see Configuration page definitions. To change the IP address or
subnet mask, see Manage your network.
Cause
The encryption settings on your access point are not correct.
Solution
Verify the encryption settings on your access point. The same encryption key and
settings must be used on both the access point and the HP all-in-one.
Cause
The destination you are attempting to scan to does not appear in the Scan To
menu.
Solution
Designate which applications and other destinations appear on the Scan To menu
by using the HP Image Zone on your computer.
The HP all-in-one cannot find the computer (ad hoc)
Cause
You do not have a functioning network.

Chapter 9
Solution
Verify you have a functioning wireless ad hoc network by using another wireless
device.
Cause
Solution
Look at the color graphics display on HP all-in-one. If the color graphics display is
blank and the light next to the On button is not lit, the HP all-in-one is turned off.
Make sure the power cord is firmly connected to the HP all-in-one and plugged into a
power outlet. Press the On button to turn on the HP all-in-one.
Cause
The HP all-in-one and computer are on different networks.
Solution
Make sure that your HP all-in-one and computer are on the same network by
verifying that they both have the same IP address and subnet mask. To see the IP
address and subnet mask of your HP all-in-one, print a network configuration page
from your HP all-in-one (see Print and view a network configuration page). For a
description of the items on the configuration page, including the IP address and
subnet mask, see Configuration page definitions. To change the IP address or
subnet mask, see Manage your network.
Cause
Your computer's wireless adapter is not broadcasting its network name (SSID).
Solution
Verify your computer's wireless adapter is broadcasting its network name (SSID).
Print a network configuration page from your HP all-in-one (see Print and view a
network configuration page), and verify that the SSID for the wireless adapter
appears on the network configuration page. If the wireless adapter is not
broadcasting its SSID, see the documentation that came with your computer.
Cause
Encryption settings are incorrect.
Solution
Verify the encryption settings on your access point. The same encryption key and
settings must be used on both the access point and the HP all-in-one.
44
Cause
The firmware for your wireless adapter needs updating.
Solution
Check for firmware updates for your wireless adapter on the manufacturer's
website, and then update the firmware.
Cause
The software setup for the HP all-in-one has failed.
Solution
Uninstall and then reinstall the HP all-in-one software.
Wired network setup troubleshooting

Use this section to solve wired network setup problems.
The Computer is unable to discover the HP all-in-one
Cause
Cables are not connected properly.
Solution
● Cables between the router and your computer
applicable)
Cause
Your Local Area Network (LAN) card (NIC) is not set up properly.
Solution
Make sure that your LAN card is set up properly.
To check your LAN card in Windows XP

1 Right-click My Computer.
2 In the System Properties dialog box, click the Hardware tab.
3 Click Device Manager.
4 Make sure your card shows up under Network Adapters.
5 Refer to the documentation that came with your card.

Chapter 9
Cause
Solution
Check to see if you have an active network connection.
To make sure your network connection is active

1 Check to see if the wired network icon (below on the left) is present on the
color graphics display. If the icon is present, the HP all-in-one is connected to
the network.
The icon on the left shows an active wired network. The icon on the right
shows an inactive network.
Wired network icon
2 If the wired network icon is not present, check the cable connections from the
HP all-in-one to your gateway or router to ensure connections are secure.
3 Make sure the HP all-in-one is connected to the network with a CAT-5
Ethernet cable.
4 Check the two Ethernet indicator lights on the top and bottom of the RJ-45
Ethernet jack on the back of the HP all-in-one. The lights indicate the
following:
a Top light: If this light is a solid green, the device is properly connected to
the network, and communications have been established. If the top light is
off, there is no network connection.
b Bottom light: This yellow light flashes when data is being sent or received
by the device over the network.
5 If the connections are secure, turn off the power on your HP all-in-one, and
then turn it on again. On the control panel of the HP all-in-one, press the On
button to turn off the HP all-in-one, and then press it again to turn it on. Also,
turn off the power on your router and then turn it on again.
To establish an active network connection

1 If the wired network icon is not active, check the cable connections from the
HP all-in-one to your gateway or router to ensure connections are secure.
2 If the connections are secure, press the On button to turn off the HP all-in-
one, and then press it again to turn it on. Also, turn off the power on your
router and then turn it on again.
I received a System Requirements Error: No TCP/IP
Cause
Your Local Area Network (LAN) card (NIC) is not installed properly.
46
Solution
Make sure your LAN card is installed properly and set up for TCP/IP. See the
instructions that came with your LAN card.
The Printer Not Found screen appears during installation
Cause
Solution
Look at the color graphics display on HP all-in-one. If the color graphics display is
blank and the light next to the On button is not lit, the HP all-in-one is turned off.
Make sure the power cord is firmly connected to the HP all-in-one and plugged into a
power outlet. Press the On button to turn on the HP all-in-one.
Cause
Solution
Make sure you have an active network connection. For more information, see You
do not have an active network connection.
Cause
Cables are not connected properly.
Solution
● Cables between the router and your computer
applicable)
I am using a cable modem without a router and I do not have IP addresses
Cause
If you have a PC with a cable modem, a separate Local Area Network (LAN) for
your other computers, and no DHCP or router, you must use AutoIP to assign IP
addresses to the other computers and to the HP all-in-one.
Solution
To obtain an IP address for the PC with the cable modem

➔ Your Internet Service Provider (ISP) assigns either a static or dynamic IP
address to the PC with the cable modem.

Chapter 9
To assign IP addresses to the remaining computers and the HP all-in-one

➔ Use AutoIP to assign IP addresses to the remaining computers and the
HP all-in-one. Do not assign a static IP address.
Common Internet File System troubleshooting

The Common Internet File System (CIFS) server provides network drive letter access to
the memory card in the HP all-in-one. This lets you read and write files on the network
from the memory card in the HP all-in-one. The CIFS server appears on your computer
as a network drive. In addition to reading and writing files from your memory card, you
can also create folders and store other information. Use this section to address CIFS
server limitations and errors.
Other users on the network can access my memory card
Cause
This is a limitation of the Common Internet File System (CIFS) server.
Solution
The CIFS server does not support authentication. However, you can increase the
privacy of data on your memory cards.
For more information on increasing memory card security, see Change memory
card security and the printed User Guide that came with your HP all-in-one.
Error message: Cannot find the file or item. Make sure the path and file name are
correct.
Cause
The CIFS server is not operational.
Solution
Retry your task at a later time. Also, you might need to turn off CIFS security. For
more information, see Change memory card security .
Cannot access CIFS server in Windows 98.
Cause
You cannot access the CIFS server in Windows 98 unless you first log on to the
network.
Solution
Make sure you log on to the network before attempting to access the CIFS server.
File names have arbitrary characters
Cause
CIFS sometimes displays file names created by other applications as arbitrary text.
Solution
Change the file names to something more meaningful.
48
a Configuration page definitions
This appendix explains the items that appear on the network configuration page.
General network settings

The following table describes the general network settings shown on the network configuration
page.
Parameter Description
Network Status Status of the HP all-in-one:

● Ready: the HP all-in-one is ready to receive or transmit data.
● Offline: the HP all-in-one is offline.
Active Network mode of the HP all-in-one:

Connection Type ● Wired: the HP all-in-one is connected by Ethernet cable to an IEEE
802.3 network.
● Wireless: the HP all-in-one is connected wirelessly to an IEEE 802.11b
or g network.
● None: Both network connection types are disabled.
Note Only one connection type can be active at a time.
URL The web or IP address of the Embedded Web Server.
Note You will need to know this URL when you try to access the
Embedded Web Server.
Hardware The Media Access Control (MAC) address that uniquely identifies the
Address (MAC) HP all-in-one. This is a unique 12-digit identification number assigned to
networking hardware for identification. No two pieces of hardware have the
same MAC address.
Note Some Internet service providers (ISPs) require that you register the
MAC address of the Network Card or LAN Adapter that was
connected to your cable or DSL modem during installation.
Firmware The internal networking component and device firmware revision code
Revision separated by a hyphen.
Note If you call in for support, depending on the problem, you might be
asked to provide the firmware revision code.
Hostname The TCP/IP name assigned by the install software to the device. By default,
this is the letters HP followed by the last 6 digits of the MAC address.
IP Address This address uniquely identifies the device on the network. IP addresses are
assigned dynamically through DHCP or AutoIP. You can also set up a static
IP address, though this is not recommended.
Note Manually assigning an invalid IP address during install will prevent

your network components from seeing the HP all-in-one.

Appendix a
(continued)
Subnet Mask A subnet is an IP address assigned by the install software to make an
additional network available as part of a larger network. Subnets are
specified by a subnet mask. This mask determines which of the HP all-in-one
IP address bits identify the network and subnet, and which bits identify the
device itself.
Note It is recommended that the HP all-in-one and the computers that use
it all reside on the same subnet.
Default A node on a network that serves as an entrance to another network. A node

Gateway in this instance can be a computer or some other device.
Note The address of the default gateway is assigned by the install

software.
Configuration The protocol used to assign the IP address to the HP all-in-one:

Source ● AutoIP: the installation software automatically determines the
configuration parameters.
● DHCP: the configuration parameters are supplied by a dynamic host
configuration protocol (DHCP) server on the network. On small
networks, this could be a router.
● Manual: the configuration parameters are set manually, such as a
static IP address.
● Not Specified: the mode used when the HP all-in-one is initializing.
DNS Server The IP address of the domain name service (DNS) for the network. When
you use the web or send an e-mail message, you use a domain name to do
it. For example, the URL http://www.hp.com contains the domain name hp.
com. The DNS on the Internet translates the domain name into an IP
address. Devices use the IP addresses to refer to one another.
● IP Address: the domain name server's IP address.
● Not Specified: the IP address is not specified, or the device is
initializing.
Note Check to see if a DNS IP address appears on the network

configuration page. If no address is shown, obtain the DNS IP
address from your Internet service provider (ISP). The DNS IP
address is required to use HP Instant Share from the device, and can
be entered through the Embedded Web Server.
mDNS Rendezvous is used with local and ad hoc networks that don't use central
DNS servers. To perform name services, Rendezvous uses a DNS
alternative called mDNS.
With mDNS, your computer can find and use any HP all-in-one connected to
your local area network. It can also work with any other Ethernet-enabled
device that appears on the network.
Admin Status of the administrator's password for the Embedded Web Server:
Password ● Set: password is specified. You must enter the password to make
changes to the Embedded Web Server parameters.
● Not Set: no password is set. A password is not required for making
changes to the Embedded Web Server parameters.
50
(continued)
Link The speed at which data is transmitted over a network:
Configuration ● 802.11b: for wireless network.
● 10TX-Full: for wired network.
● 10TX-Half: for wired network.
● 100TX-Full: for wired network.
● 100TX-Half: for wired network.
● None: networking is disabled.
Wireless network settings

The following table describes the wireless network settings shown on the network configuration
page.
Wireless Status Status of the wireless network:

● Connected: the HP all-in-one is connected to a wireless LAN and
everything is working.
● Disconnected: the HP all-in-one is not connected to the wireless LAN
due to incorrect settings (such as the wrong WEP key), or the HP all-
in-one is out of range.
● Disabled: either the radio is turned off, or the Ethernet cable is plugged
in.
● Not applicable: this parameter does not apply to this network type.
Communication An IEEE 802.11 networking framework in which devices or stations

Mode communicate with each other:
● Infrastructure: the HP all-in-one communicates with other network
devices through a wireless access point, such as a wireless router or
base station.
● ad hoc: the HP all-in-one communicates directly with each device on
the network. No wireless access point is used. This is also called a
peer-to-peer network. On Macintosh networks, ad hoc mode is called
computer-to-computer mode.
Network Name Service Set Identifier. A unique identifier (up to 32 characters) that
(SSID) differentiates one wireless local area network (WLAN) from another. The
SSID is also referred to as the network name. This is the name of the
network to which the HP all-in-one is connected.
Signal Strength The transmitting or return signal graded on a scale of 1 to 5:

(1-5) ● 5: Excellent
● 4: Good
● 3: Fair
● 2: Poor
● 1: Marginal
● No signal: no signal detected on the network.
Channel The channel number currently being used for wireless communication. This
depends on the network in use, and might differ from the requested channel

Appendix a
(continued)
number. Value is from 1 to 14; countries/regions might limit the range of
approved channels.
● <number>: value ranging from 1 to 14, depending on country/region.
● None: no channel is in use.
● Not Applicable: the WLAN is disabled or this parameter does not apply
to this network type.
Note In ad hoc mode, if you are not able to receive or transmit data
between your computer and the HP all-in-one, make sure that you are
using the same communication channel on your computer and the
HP all-in-one. In infrastructure mode, the channel is dictated by the
access point.
Authentication Type of authentication in use:

type ● None: no authentication in use.
● Open System (ad hoc and infrastructure): no authentication.
● Shared Key (infrastructure only): WEP key is required.
● WPA-PSK (infrastructure only): WPA with Pre-Shared Key.
Authentication verifies the identity of a user or device before granting access
to the network, making it more difficult for unauthorized users to get at
network resources. This security method is common on wireless networks.
A network using Open System authentication does not screen network users
based on their identities. Any wireless user can have access from the
network. However, such a network might use WEP (Wired Equivalent
Privacy) encryption to provide a first level of security against casual
eavesdroppers.
A network using Shared Key authentication provides increased security by
requiring users or devices to identify themselves with a static key (a
hexadecimal or alphanumeric string). Every user or device on the network
shares the same key. WEP encryption is used along with shared key
authentication, using the same key for both authentication and encryption.
A network using server-based (WPA-PSK) authentication provides
significantly stronger security, and is supported in most wireless access
points and wireless routers. The access point or router verifies the identity of a
user or device requesting access to the network before granting that access.
Several different authentication protocols might be used on an authentication
server.
Note Shared key and WPA-PSK authentication can only be entered

through the Embedded Web Server.
Encryption The type of encryption in use on the network:

● None: no encryption is in use.
● 64-bit WEP: a 5-character or 10-hex-digit WEP key is in use.
● 128-bit WEP: a 13-character or 26-hex-digit WEP key is in use.
● WPA-AES: Advanced Encryption Standard encryption is in use. This is
an encryption algorithm for securing sensitive but unclassified material
by US Government agencies.
● WPA-TKIP: Temporal Key Integrity Protocol, an advanced encryption
protocol, is in use.
52
(continued)
● Automatic: AES or TKIP is in use.
WEP aims to provide security by encrypting data over radio waves so that it
is protected as it is transmitted from one end point to another. This security
method is common on wireless networks.
Access Point HW The hardware address of the access point on the network to which the
Address HP all-in-one is connected:
● <MAC address>: the unique MAC (media access control) hardware
address of the access point.
Miscellaneous
The following table describes the data transmission and receipt information shown on the network
configuration page.
Total Packets The number of packets transmitted by the HP all-in-one without error since it
transmitted has been turned on. The counter clears after the HP all-in-one is turned off.
When a message is transmitted over a packet-switching network, it is broken
up into packets. Each packet contains the destination address as well as the
data.
Total Packets The number of packets received by the HP all-in-one without error since it
received has been turned on. The counter clears after the HP all-in-one is turned off.

Appendix a
54
b Glossary
802.11b or g Signalling protocols for wireless networks. 802.11g was developed more
recently and provides more advanced functionality.
access point Also known as a wireless router, an access point provides a secure and
flexible connection for your HP all-in-one and other network elements. A
wireless network with an access point is called an infrastructure network.
ad hoc A wireless network that does not use an access point.
ASCII American Standard Code for Information Interchange. The standard for
numbers used by computers to represent all the uppercase and lowercase
Latin letters, numbers, punctuation, etc.
authentication A network security method that verifies the identity of a user or device
before granting access to the network, making it more difficult for
unauthorized users to access network resources. This security method is
common on wireless networks.
autoIP A feature of the installation software, which determines the configuration

parameters of devices on the network.
DHCP Dynamic Host Configuration Protocol. A server on the network that

supplies configuration parameters to devices on the network. On small
networks, this could be a router.
DNS Domain Name Service. When you use the web or send an e-mail
message, you use a domain name to do it. For example, the URL http://
www.hp.com contains the domain name hp.com. The DNS on the
Internet translates the domain name into an IP address. Devices use the
IP addresses to refer to one another.
DNS-SD See DNS. The SD portion stands for Service Discovery. This is part of a
protocol developed by Apple that enables automatic discovery of
computers, devices, and services on IP networks.
DSL Digital Subscriber Line. A high-speed connection to the Internet.
Ethernet The most common local network technology that connects computers
using copper cabling.
Ethernet cable The cable used to connect network elements in a wired network. The
CAT-5 Ethernet cable is also known as a straight-through cable. When
using an Ethernet cable, the network elements must be attached to a
router. The Ethernet cable uses an RJ-45 connector.
EWS Embedded Web Server. A browser-based utility that provides a simple

way to manage your HP all-in-one. You can monitor status, configure
HP all-in-one networking parameters, or access HP all-in-one features.
For more information, see Use the Embedded Web Server.
HEX Hexidecimal. The base 16 numbering system, which uses the digits 0-9
plus the letters A-F.

Appendix b
(continued)
hub No longer used much in modern home networks, a hub takes its signal
from each computer and sends it to all of the other computers connected
to the hub. Hubs, are passive; other devices on the network plug into the
hub in order to communicate with one another. A hub does not manage
the network.
IP address A number that uniquely identifies the device on the network. IP addresses
are assigned dynamically through DHCP or AutoIP. You can also set up a
static IP address, though this is not recommended.
infrastructure An infrastructure network uses a router, switch, or access point to

connect network elements.
MAC address Media Access Control (MAC) address that uniquely identifies the HP all-
in-one. This is a unique 12-digit identification number assigned to
networking hardware for identification. No two pieces of hardware have
the same MAC address.
NIC Network Interface Card. A card on your computer that provides an

Ethernet connection so that you can connect your computer to a network.
RJ-45 connector The connector on the ends of an Ethernet cable. Although standard
Ethernet cable connectors (RJ-45 connectors) look similar to standard
telephone cable connectors, they are not interchangeable. An RJ-45
connector is wider and thicker and always has 8 contacts on the end. A
phone connector has between 2 and 6 contacts.
SSID Service Set Identifier. A unique identifier (up to 32 characters) that

differentiates one wireless local area network (WLAN) from another. The
SSID is also referred to as the network name. This is the name of the
network to which the HP all-in-one is connected.
router A router provides a bridge between two or more networks. A router can
link a network to the Internet, link two networks and connect both to the
Internet, and help secure networks through the use of firewalls and
assigning dynamic addresses. A router can also act as a gateway, while a
switch cannot.
switch A switch makes it possible for several users to send information over a
network at the same time without slowing each other down. Switches allow
different nodes (a network connection point, typically a computer) of a
network to communicate directly with one another.
WEP key The passkey for Wired Equivalent Privacy encryption, which provides a
first level of security against casual eavesdroppers.
WPA Password or The password for Wi-Fi Protected Access. The passkey is 8 to 63
Passkey characters long, including spaces. WPA provides security by verifying the
identity of a user or device before granting access to the network, making
it more difficult for unauthorized users to get at network resources. This
security method is common on wireless networks.
56
Index
A display summary 29 I
access point connection 7, 15 DNS server (general network infrastructure mode 15
access point HW address settings) 50 infrastructure network 7, 11
(wireless network settings) 53 DSL 8 install software
ad hoc network 19 Macintosh 28
additional computers 5 E Windows 27
admin password (general Embedded Web Server (EWS) Instant Share, HP
network settings) 50 password settings 50 Ethernet connection 11
advanced setup 30 using 31 wireless ad hoc
AirPort 15 encryption connection 19
authentication type (wireless settings 52 wireless infrastructure
network settings) 52 troubleshooting 38, 43, 44 connection 8
WEP key 21 interface card 16
B Ethernet connection Internet
base station. see access point Internet access 11 broadband 16, 26
connection setting up 25 DSL or cable with router
broadband Internet 16, 19, 26 types of 11 gateway 11
wireless 13 Internet access
C EWS modem 12
cable Internet access 8 password settings 50 IP
cards, interface 16 using 31 address (general network
CAT-5 Ethernet cable 25 settings) 49
channel (wireless network F settings 30
settings) 51 factory defaults 29
Common Internet File file system troubleshooting 48 L
System 48 firmware version (general link config (general network
communication mode (wireless network settings) 49 settings) 51
network settings) 51 link speed 30
computer gateway 12 G
computer-to-computer gateway M
network 19 computer 12 Macintosh software
config source (general network default setting 50 installation 28
settings) 50 router 11 mDNS service name (general
configuration page 29, 49 general network settings 49 network settings) 50
connect Media Access Control (MAC)
using an Ethernet cable 25 H address 49
without an access hardware address (general memory card security 31
point 15, 19 network settings) 49 multiple computers 5
connection type screen, hostname (general network
Windows 27 settings) 49 N
control panel 29 HP Instant Share network configuration page 29
Ethernet connection 11 network connection type
D wireless ad hoc (general network settings) 49
default gateway (general connection 19 network interface card 16
network settings) 50 wireless infrastructure network name (wireless network
defaults, restoring 29 connection 8 settings) 51

network profile 20 cannot find the file or setting up 21
network security item 48 troubleshooting 39, 40
settings 32 Common Internet File Windows software
troubleshooting 35, 38, 43, System 48 installation 27
44 encryption, WPA, or WPA- wired connection
WEP key 21 PSK (wireless) 38 setting up 25
network troubleshooting. see HP all-in-one cannot find my troubleshooting 45
troubleshooting computer (wireless wireless networks
network upgrade 4 infrastructure mode) 43 setting up 7
HP all-in-one cannot find the troubleshooting 36
P WLAN/access point 42 wireless radio 30
password, Embedded Web multiple WEP keys wireless router 8
Server 50 (wireless) 40 wireless status (wireless
peer-to-peer network 19 network 35 network settings) 51
printer found screen, No TCP/IP (wired) 46
Windows 27 No TCP/IP (wireless) 37
profile, network 20 others on network can
access my memory
R card 48
radio, turning off 30 Printer not Found
recommended networks 7, 11 (wired) 47
restore network defaults 29 Printer not Found
RJ-45 plug 25, 55, 56 (wireless) 37
router 7, 11, 26, 33 setup failed (wireless) 40
signal not received by
device (wireless) 40
S
SSID or WEP key incorrectly
security, network 32
set (wireless) 39
set link speed 30
unable to determine network
settings, restoring defaults 29
name (wireless) 38
sharing 5
unable to discover device
signal strength (wireless
(wired) 45
network settings) 51
unable to discover device
software installation
(wireless) 41
Macintosh 28
using a cable modem
Windows 27
without a router (wired) 47
SSID
verification fails
(wireless network
(wireless) 38
settings) 51
wired network setup 45
troubleshooting 36, 38, 39
wireless discovery 41
status (general network
wireless network setup 36
settings) 49
wireless setup wizard 35
subnet mask (general network
turn off the wireless radio 30
settings) 50
switch from USB to network 4
U
upgrade from USB to
T
network 4
total packets received 53
URL (general network
total packets transmitted 53
settings) 49
troubleshooting
authentication protocols not
supported by installation W
software (wireless) 39 WEP key
58
Printed on at least 50% total recycled fiber
with at least 10% post-consumer paper
© 2004 Hewlett-Packard Development Company, L.P.
Electronic Edition
www.hp.com
*Q3462-90198*
*Q3462-90198*
Q3462-90198
Introduction to Security Architecture
Security architecture is defined as the architectural design that includes all the threats and
potential risks which can be present in the environment or that particular scenario. This also
includes the security controls and the use of security controls. For the security architecture, the
proper documentation is done that include all the security specifications and include all the
detailed information about the architecture. The organization uses for their system, and it is
mainly used because the architecture is affordable and cost-effective and can be used easily by
the organization.
Security Architecture with Diagram
This is defined as the part of enterprise architecture that is particularly design for addressing
the information system and fulfill the security requirements of the organization. The system
architecture system has a role that it meets the security requirements and also helps to protect
the company operating environment. It is beneficial for the company as it includes other
activities like risk management activities that require continuous improvement, and security
architecture helps to meet the organization requirements. It defines proper polices, rules and
regulations that need to reinforce in the organization and provide proper information about
them. The architecture is also used for allocating the controls for technical security so that the
information system of the organization can be maintained properly. As the same can be
followed in a whole organization, it helps to define common regulations and standards for every
employee so that everyone can follow the rules and maintain data integrity and security in the
organization.
In the above diagram, the high-level design of the system architecture is shown. The abstraction
is given here.
Components of Security Architecture
For making the security architecture important, there are certain components that are involved
in the design. The components are people, process and the tools. All these components combine
helps to protect the organization assets. After defining the components, the next step is to make
the policy and the reinforcement technique for the policies. After the other important steps are
the method procedural for the implementation of security architecture and how the architecture
will get enforced. By this, the overall design and architecture are designed for the organization
that will protect them throughout their business operations. For a proper security architecture,
some of the components are briefly discussed:
1. Guidance
The policies and procedures that act as the guidance should be design and implement properly.
The policies should include the documentation that includes the objectives and goals for
designing the architecture, standards, policies, rules and regulations for the organization,
identification of scope and function, identification of other security policies.
2. Identity Management
It is the type of system that include the organization processes, technologies and policies that
directly help users to gain access to the online applications and other network resources. For
the organization, the proper responsibilities and roles need to be clearly stated, and individual
tasks need to be designed for the employees.
3. Inclusion & Exclusion
The other components are the inclusion and exclusion that include the security of elements of
the organization in which company resources are protected. The company resources include
web resources, e-mail servers, private HR data and other reporting system information. The
access should be grant to authorized users only so that the privacy and integrity can be
maintained in the organization.
4. Access and Border Control
The organization should develop an architecture that is able to control the access to the business
resources and can use the layer system for providing access to the company employees. Only
authorized users should gain complete access to the system, and the rest should be provided
with limited access of the system.
5. Validation of Architecture
As the technology advances, the company need to renew the policies and laws as per the
changes, and continuous effort is needed by the organization in this change. For that, the
continuous monitoring is required, and according to that, proper changes can be made in the
architecture.
6. Training
As for the organization, to maintain the privacy and integrity, the security architecture system
is very important. AS there is a continuous change in the system, it becomes important that the
employee should know about the changes and proper training is given to them so that they can
use the system and protect the company assets and elements.
7. Technology
To reinforce the security architecture, the software and hardware used for making the
architecture become very crucial for the organization. Because of continuous change in
technology, there is a requirement of continuous change in the system so that the system can
be up to date and help to make the system secure and private.
Benefits of Using the Security Architecture
Some of the benefits are mentioned below.
 Help to protect the important company assets from the outside and provide security to
the important resources to the organization. The architecture provides the limited access
to the user so that the confidential data can be kept secure and safe.
 The architecture defines the common policies and standards that can be used by the
every employee of the company and also define common rules so that no one face any
difficulty to use the system. It helps the organization to reach their goal and easily
conduct their business operations smoothly.
 The other benefit is risk management activities covered by the architecture as the risk
management activity requires continuous assistance and also need continuous
improvement, the security architecture act as a better solution for them.
Conclusion
Security architecture is a type of enterprise architecture and is very important for the
organization to protect the company resources from the outside world. A strong security
architecture is used by the organization to main security and data integrity in the system, and
the policies and rules defined by the system are followed by the employee of an organization.
Security Device
Management-SDM
Unit-2
Why SDM
provides various options to meet your organization’s business
requirements. And also Improved operational and technical efficiency
Improved operational and technical efficiency
• Manage your security devices for improved operational and technical

efficiency, with minimal technology investment and reduced
expenditure – without sacrificing quality or breadth of control. We
provide specialized expertise in managing devices, policies, releasing
in-house staff for other vital initiatives. It also provides on-demand
device configuration, tuning, updates and maintenance, and meeting
all best practice and regulatory requirements.
Security Device Management – Standard:
• Always-on: Active and consistent management control on your behalf
year-round, steering you past both the known and unknown threats
to your devices.
• Consistent updates: Devices, applications and endpoint security
solutions are properly provisioned, configured, updated and patched
to protect against internal and external threats. We also ensure that
policies, signatures, and rules are updated and maintained to
guarantee accessibility and provide security and compliance.
Security Device Management – Enhanced
• Asset management: Release management with patches, tuning options, and security hotfixes.
Back-up options for security device and OS configurations. Restoration and recovery for devices
brought down by malicious activities and threats.
• Policy management: For security devices and secure access service edge (SASE)
• Service request fulfilment: Fully support change management with move, add, change and delete
(MACD) bundles.
• Additional MACDs: Optional within the enhanced tier for additional MACD bundles, depending
upon your extra requirements.
Types of Network Security Devices
• Firewalls
• Intrusion Protection Systems (IPS)
• Unified Threat Management (UTM)
• Network Access Control
• Email Security Gateways
• Web Application Firewalls (WAF)
• VPN Gateways
• Access control
• Antivirus and anti-malware software
• Application security
• Behavioral analytics
• Data loss prevention
• Distributed denial of service prevention
• Mobile device security
• Network segmentation
• Security information and event management
Firewalls
• Firewalls are one of the most fundamental network security appliances. Like
many other security devices, firewalls can come in hardware or software forms.
Most of the time, businesses choose to use dedicated, specialized hardware since
it can handle more traffic and has better vendor support.
• Firewalls provide separation between your internal network and the wider
Internet. They can block connections on specific ports, from specific IP addresses,
and from machines or networks matching other criteria. Most firewalls are
configured to deny incoming traffic by default, providing a baseline of security for
your network.
Intrusion Protection Systems (IPS)
• Network-based intrusion protection systems proactively monitor all of the traffic

going through your network. Using pre-made profiles, signature detection,
artificial intelligence, and anomaly detection, IPS systems can detect many kinds
of network intrusions, from malware on endpoint devices to denial of service
attacks.
• One of the most useful features of network-based intrusion protection is that it
can talk to firewalls and other network hardware in real time as threats are
discovered. As an example, an IPS system could detect a device with malware
installed from the unusual and suspicious network traffic it produces. Afterwards,
the IPS can request that the firewall quarantines this infected device on its own
partitioned subnet so that it is unable to cause further damage.
Unified Threat Management (UTM)
• In a modern business network, administrators might control a half dozen or more
separate network appliances with security functions. If multiple products come
from different vendors, managing a quickly-unfolding network threat can be
challenging.
• UTMs combine a network firewall, an intrusion detection system, an intrusion
prevention system, and other features. For smaller businesses or those without
significant IT resources, using a UTM can save lots of time and money. However,
UTMs are not always better than discrete equipment: they create a single point
of failure that can take down the whole network if something goes wrong.
Network Access Control
• Keeping infected or insecurely configured endpoint devices off of the corporate

network is critical to security. As a result, network access control devices link
network authentication with the state of endpoint devices.
• For example, an integrated network access control solution could make sure that
devices could not authenticate themselves without having the latest security
updates installed.
Email Security Gateways
• While more and more businesses move to cloud-hosted email solutions, network
email gateways can still be useful. These devices monitor incoming and outgoing
email traffic for spam, viruses, phishing attempts, and compromised accounts.
Recent, advanced email security gateways also use historical data and statistical
analysis to detect anomalies with more accuracy.
• Some vendors sell hardware email security gateways, while others provide
services that run on mail servers or alongside cloud-based email hosting.
Web Application Firewalls (WAF)
• Like a regular network firewall, a WAF selectively allows or blocks traffic based on
predefined criteria or suspicious activity. Web applications commonly have
security vulnerabilities that can be used to compromise a company’s network and
leak data. While finding and fixing all of these issues would be the ideal solution,
using a web application firewall is a good next layer of defence.
• A WAF can block URLs and requests containing suspicious payloads, evidence of
SQL injection attempts, and other attacks. They can come in the form of a
physical device, a software extension to another network security device, or
software installed on a standard reverse proxy server.
VPN Gateways
• With the rise of remote work, every company needs to ensure that their internal
network resources are accessible securely from anywhere. A virtual private
network or VPN device can help here.
• In effect, when employees connect to the VPN, their traffic enters the internal
network from the VPN device instead of going straight to the Internet.
• In addition to security benefits, VPN gateways give employees access to printers,
Intranet sites, and other internal devices, saving time and improving productivity
Network Device Backup and Recovery
• With so many individual network devices, applying and rolling back configuration
changes can be challenging. Additionally, large numbers of separate devices are
difficult to recover quickly in the event of a disaster.
• For these reasons, centralised backup and recovery for network devices is very
useful. Network configuration management tools automate the backup process
by securely storing the configuration and state of network devices, simplifying
rollback or restore operations.
Access control
• This refers to controlling which users have access to the network or especially
sensitive sections of the network. Using security policies, you can restrict network
access to only recognized users and devices or grant limited access to
noncompliant devices or guest users.
Antivirus and anti-malware software
• Malware, or “malicious software,” is a common form of cyberattack that comes in
many different shapes and sizes. Some variations work quickly to delete files or
corrupt data, while others can lie dormant for long periods of time and quietly
allow hackers a back door into your systems.
• The best antivirus software will monitor network traffic in real time for malware,
scan activity log files for signs of suspicious behavior or long-term patterns, and
offer threat remediation capabilities.
Application security
• Each device and software product used within your networking environment
offers a potential way in for hackers. For this reason, it is important that all
programs be kept up-to-date and patched to prevent cyberattackers from
exploiting vulnerabilities to access sensitive data.
• Application security refers to the combination of hardware, software, and best
practices you use to monitor issues and close gaps in your security coverage.
Behavioral analytics
• In order to identify abnormal behavior, security support personnel need to
establish a baseline of what constitutes normal behavior for a given customer’s
users, applications, and network.
• Behavioral analytics software is designed to help identify common indicators of
abnormal behavior, which can often be a sign that a security breach has occurred.
By having a better sense of each customer’s baselines, MSPs can more quickly
spot problems and isolate threats
Data loss prevention
• Data loss prevention (DLP) technologies are those that prevent an organization’s
employees from sharing valuable company information or sensitive data—
whether unwittingly or with ill intent—outside the network.
• DLP technologies can prevent actions that could potentially expose data to bad
actors outside the networking environment, such as uploading and downloading
files, forwarding messages, or printing.
Distributed denial of service prevention
• Distributed denial of service (DDoS) attacks are becoming increasingly common.
They function by overloading a network with one-sided connection requests that
eventually cause the network to crash.
• A DDoS prevention tool scrubs incoming traffic to remove non-legitimate traffic
that could threaten your network, and may consist of a hardware appliance that
works to filter out traffic before it reaches your firewalls
Email security
• Email is an especially important factor to consider when implementing
networking security tools. Numerous threat vectors, like scams, phishing,
malware, and suspicious links, can be attached to or incorporated into emails.
• Because so many of these threats will often use elements of personal information
in order to appear more convincing, it is important to ensure an organization’s
employees undergo sufficient security awareness training to detect when an
email is suspicious. Email security software works to filter out incoming threats
and can also be configured to prevent outgoing messages from sharing certain
forms of data
Network segmentation.
• Dividing and sorting network traffic based on certain classifications streamlines
the job for security support personnel when it comes to applying policies.
• Segmented networks also make it easier to assign or deny authorization
credentials for employees, ensuring no one is accessing information they should
not be. Segmentation also helps to sequester potentially compromised devices or
intrusions
Security information and event management
• These security systems (called SIEMs) combine host-based and network-based
intrusion detection systems that combine real-time network traffic monitoring
with historical data log file scanning to provide administrators with a
comprehensive picture of all activity across the network.
• SIEMs are similar to intrusion prevention systems (IPS), which scan network traffic
for suspicious activity, policy violations, unauthorized access, and other signs of
potentially malicious behaviour in order to actively block the attempted
intrusions. An IPS can also log security events and send notifications to the
necessary players in the interest of keeping network administrators informed.
• With the importance of the information traveling over every company’s network
today, not using the appropriate network security devices would be irresponsible.
Through the use of these devices, companies can stop cyberattacks before they
happen.
• Firewalls are the oldest and most well-established variety of network security
device. Other appliances like intrusion detection and prevention devices expand
the firewall’s capabilities to a wide range of emerging threats. Other devices can
protect email communications, web applications hosted on the local network,
and remote VPN connections
Security Device
Management-SDM
Unit-2
Why SDM
provides various options to meet your organization’s business
requirements. And also Improved operational and technical efficiency
Improved operational and technical efficiency
• Manage your security devices for improved operational and technical

efficiency, with minimal technology investment and reduced
expenditure – without sacrificing quality or breadth of control. We
provide specialized expertise in managing devices, policies, releasing
in-house staff for other vital initiatives. It also provides on-demand
device configuration, tuning, updates and maintenance, and meeting
all best practice and regulatory requirements.
Security Device Management – Standard:
• Always-on: Active and consistent management control on your behalf
year-round, steering you past both the known and unknown threats
to your devices.
• Consistent updates: Devices, applications and endpoint security
solutions are properly provisioned, configured, updated and patched
to protect against internal and external threats. We also ensure that
policies, signatures, and rules are updated and maintained to
guarantee accessibility and provide security and compliance.
Security Device Management – Enhanced
• Asset management: Release management with patches, tuning options, and security hotfixes.
Back-up options for security device and OS configurations. Restoration and recovery for devices
brought down by malicious activities and threats.
• Policy management: For security devices and secure access service edge (SASE)
• Service request fulfilment: Fully support change management with move, add, change and delete
(MACD) bundles.
• Additional MACDs: Optional within the enhanced tier for additional MACD bundles, depending
upon your extra requirements.
Types of Network Security Devices
• Firewalls
• Intrusion Protection Systems (IPS)
• Unified Threat Management (UTM)
• Network Access Control
• Email Security Gateways
• Web Application Firewalls (WAF)
• VPN Gateways
• Access control
• Antivirus and anti-malware software
• Application security
• Behavioral analytics
• Data loss prevention
• Distributed denial of service prevention
• Mobile device security
• Network segmentation
• Security information and event management
Firewalls
• Firewalls are one of the most fundamental network security appliances. Like
many other security devices, firewalls can come in hardware or software forms.
Most of the time, businesses choose to use dedicated, specialized hardware since
it can handle more traffic and has better vendor support.
• Firewalls provide separation between your internal network and the wider
Internet. They can block connections on specific ports, from specific IP addresses,
and from machines or networks matching other criteria. Most firewalls are
configured to deny incoming traffic by default, providing a baseline of security for
your network.
Intrusion Protection Systems (IPS)
• Network-based intrusion protection systems proactively monitor all of the traffic

going through your network. Using pre-made profiles, signature detection,
artificial intelligence, and anomaly detection, IPS systems can detect many kinds
of network intrusions, from malware on endpoint devices to denial of service
attacks.
• One of the most useful features of network-based intrusion protection is that it
can talk to firewalls and other network hardware in real time as threats are
discovered. As an example, an IPS system could detect a device with malware
installed from the unusual and suspicious network traffic it produces. Afterwards,
the IPS can request that the firewall quarantines this infected device on its own
partitioned subnet so that it is unable to cause further damage.
Unified Threat Management (UTM)
• In a modern business network, administrators might control a half dozen or more
separate network appliances with security functions. If multiple products come
from different vendors, managing a quickly-unfolding network threat can be
challenging.
• UTMs combine a network firewall, an intrusion detection system, an intrusion
prevention system, and other features. For smaller businesses or those without
significant IT resources, using a UTM can save lots of time and money. However,
UTMs are not always better than discrete equipment: they create a single point
of failure that can take down the whole network if something goes wrong.
Network Access Control
• Keeping infected or insecurely configured endpoint devices off of the corporate

network is critical to security. As a result, network access control devices link
network authentication with the state of endpoint devices.
• For example, an integrated network access control solution could make sure that
devices could not authenticate themselves without having the latest security
updates installed.
Email Security Gateways
• While more and more businesses move to cloud-hosted email solutions, network
email gateways can still be useful. These devices monitor incoming and outgoing
email traffic for spam, viruses, phishing attempts, and compromised accounts.
Recent, advanced email security gateways also use historical data and statistical
analysis to detect anomalies with more accuracy.
• Some vendors sell hardware email security gateways, while others provide
services that run on mail servers or alongside cloud-based email hosting.
Web Application Firewalls (WAF)
• Like a regular network firewall, a WAF selectively allows or blocks traffic based on
predefined criteria or suspicious activity. Web applications commonly have
security vulnerabilities that can be used to compromise a company’s network and
leak data. While finding and fixing all of these issues would be the ideal solution,
using a web application firewall is a good next layer of defence.
• A WAF can block URLs and requests containing suspicious payloads, evidence of
SQL injection attempts, and other attacks. They can come in the form of a
physical device, a software extension to another network security device, or
software installed on a standard reverse proxy server.
VPN Gateways
• With the rise of remote work, every company needs to ensure that their internal
network resources are accessible securely from anywhere. A virtual private
network or VPN device can help here.
• In effect, when employees connect to the VPN, their traffic enters the internal
network from the VPN device instead of going straight to the Internet.
• In addition to security benefits, VPN gateways give employees access to printers,
Intranet sites, and other internal devices, saving time and improving productivity
Network Device Backup and Recovery
• With so many individual network devices, applying and rolling back configuration
changes can be challenging. Additionally, large numbers of separate devices are
difficult to recover quickly in the event of a disaster.
• For these reasons, centralised backup and recovery for network devices is very
useful. Network configuration management tools automate the backup process
by securely storing the configuration and state of network devices, simplifying
rollback or restore operations.
Access control
• This refers to controlling which users have access to the network or especially
sensitive sections of the network. Using security policies, you can restrict network
access to only recognized users and devices or grant limited access to
noncompliant devices or guest users.
Antivirus and anti-malware software
• Malware, or “malicious software,” is a common form of cyberattack that comes in
many different shapes and sizes. Some variations work quickly to delete files or
corrupt data, while others can lie dormant for long periods of time and quietly
allow hackers a back door into your systems.
• The best antivirus software will monitor network traffic in real time for malware,
scan activity log files for signs of suspicious behavior or long-term patterns, and
offer threat remediation capabilities.
Application security
• Each device and software product used within your networking environment
offers a potential way in for hackers. For this reason, it is important that all
programs be kept up-to-date and patched to prevent cyberattackers from
exploiting vulnerabilities to access sensitive data.
• Application security refers to the combination of hardware, software, and best
practices you use to monitor issues and close gaps in your security coverage.
Behavioral analytics
• In order to identify abnormal behavior, security support personnel need to
establish a baseline of what constitutes normal behavior for a given customer’s
users, applications, and network.
• Behavioral analytics software is designed to help identify common indicators of
abnormal behavior, which can often be a sign that a security breach has occurred.
By having a better sense of each customer’s baselines, MSPs can more quickly
spot problems and isolate threats
Data loss prevention
• Data loss prevention (DLP) technologies are those that prevent an organization’s
employees from sharing valuable company information or sensitive data—
whether unwittingly or with ill intent—outside the network.
• DLP technologies can prevent actions that could potentially expose data to bad
actors outside the networking environment, such as uploading and downloading
files, forwarding messages, or printing.
Distributed denial of service prevention
• Distributed denial of service (DDoS) attacks are becoming increasingly common.
They function by overloading a network with one-sided connection requests that
eventually cause the network to crash.
• A DDoS prevention tool scrubs incoming traffic to remove non-legitimate traffic
that could threaten your network, and may consist of a hardware appliance that
works to filter out traffic before it reaches your firewalls
Email security
• Email is an especially important factor to consider when implementing
networking security tools. Numerous threat vectors, like scams, phishing,
malware, and suspicious links, can be attached to or incorporated into emails.
• Because so many of these threats will often use elements of personal information
in order to appear more convincing, it is important to ensure an organization’s
employees undergo sufficient security awareness training to detect when an
email is suspicious. Email security software works to filter out incoming threats
and can also be configured to prevent outgoing messages from sharing certain
forms of data
Network segmentation.
• Dividing and sorting network traffic based on certain classifications streamlines
the job for security support personnel when it comes to applying policies.
• Segmented networks also make it easier to assign or deny authorization
credentials for employees, ensuring no one is accessing information they should
not be. Segmentation also helps to sequester potentially compromised devices or
intrusions
Security information and event management
• These security systems (called SIEMs) combine host-based and network-based
intrusion detection systems that combine real-time network traffic monitoring
with historical data log file scanning to provide administrators with a
comprehensive picture of all activity across the network.
• SIEMs are similar to intrusion prevention systems (IPS), which scan network traffic
for suspicious activity, policy violations, unauthorized access, and other signs of
potentially malicious behaviour in order to actively block the attempted
intrusions. An IPS can also log security events and send notifications to the
necessary players in the interest of keeping network administrators informed.
• With the importance of the information traveling over every company’s network
today, not using the appropriate network security devices would be irresponsible.
Through the use of these devices, companies can stop cyberattacks before they
happen.
• Firewalls are the oldest and most well-established variety of network security
device. Other appliances like intrusion detection and prevention devices expand
the firewall’s capabilities to a wide range of emerging threats. Other devices can
protect email communications, web applications hosted on the local network,
and remote VPN connections
Color profile: Generic CMYK printer profile
Composite Default screen All-In-One / CISSP Certification All-in-One Exam Guide / Harris / 222966-7/ Chapter 5
Security Models
and Architecture
CHAPTER
5
In this chapter, you will learn about the following topics:
• Computer architecture and the items that fall within it
• Trusted computing base and security mechanisms
• Components within an operating system
• Various security models
• Security criteria and ratings
• Certification and accreditation processes
Computer and information security covers many areas within an enterprise. Each area has
security vulnerabilities and, hopefully, some corresponding countermeasures that raise
the security level and provide better protection. Not understanding the different areas and
security levels of network devices, operating systems, hardware, protocols, and applica-
tions can cause security vulnerabilities that can affect the environment as a whole.
Two fundamental concepts in computer and information security are the security
model, which outlines how security is to be implemented—in other words, providing a
“blueprint”—and the architecture of a computer system, which fulfills this blueprint.
A security policy outlines how data is accessed, what level of security is required, and
what actions should be taken when these requirements are not met. The policy outlines
the expectations of a computer system or device. A security model is a statement that out-
lines the requirements necessary to properly support and implement a certain security
policy. If a security policy dictates that all users must be identified, authenticated, and au-
thorized before accessing network resources, the security model might lay out an access
control matrix that should be constructed so that it fulfills the requirements of the security
policy. If a security policy states that no one from a lower security level should be able to
view or modify information at a higher security level, the supporting security model will
outline the necessary logic and rules that need to be implemented to ensure that under no
circumstances can a lower-level subject access a higher-level object in an unauthorized
manner. A security model provides a deeper explanation of how a computer operating
system should be developed to properly support a specific security policy.
185
P:\010Comp\All-in-1\966-7\ch05.vp
Monday, May 19, 2003 3:39:48 PM
CISSP Certification All-in-One Exam Guide

186
NOTE Individual systems and devices can have their own security policies. We
are not talking about organizational security policies that contain management’s
directives. The systems’ security policies and models they use should enforce
the higher-level organizational security policy that is in place.
Security Models and Architecture

Computer security can be a slippery term because it means different things to different
people. There are many aspects of a system that can be secured, and security can happen
at various levels and to varying degrees. We have stated in previous chapters that infor-
mation security is made up of the following main attributes:
• Availability Prevention of loss of access to resources and data

• Integrity Prevention of unauthorized modification of data
• Confidentiality Prevention of unauthorized disclosure of data
From here these main attributes branch off into more granular security attributes
such as authenticity, accountability, non-repudiation, and dependability. How does a
company know which of these it needs, to what degree they are needed, and if the oper-
ating systems and applications they use actually provide these features and protection?
These questions get much more complex as one looks deeper into the questions and
systems themselves. Companies are not just concerned about e-mail messages being
encrypted as they pass through the Internet. They are also concerned about the confi-
dential data stored in their databases, the security of their Web farms that are connected
directly to the Internet, the integrity of data entry values going into applications that
process business-oriented information, the internal users sharing trade secrets, the ex-
ternal attackers bringing down servers and affecting productivity, viruses spreading, the
internal consistency of data warehouses, and much more. These issues not only affect
productivity and profitability, but also raise legal and liability issues with securing data.
Companies, and the management that runs them, can be held accountable if many of
the previously mentioned issues go wrong. So it is, or at least it should be, very impor-
tant for companies to know what security they need and how to be properly assured that
the protection is actually being provided by the products they purchase.
Many of these security issues must be thought through before and during the design
and architectural phase for a product. Security is best if it is designed and built into the
foundation of operating systems and applications and not added on as an afterthought.
Once security is integrated as an important part of the design, it has to be engineered,
implemented, tested, audited, evaluated, certified, and accredited. The security that a
product provides has to be rated on the availability, integrity, and confidentiality it
claims. Consumers then use these ratings to determine if specific products provide the
level of security they require. This is a long road, with many entities involved with differ-
ent responsibilities. This chapter takes you from the steps necessary before actually
developing an operating system to how these systems are evaluated and rated by govern-
ments and other agencies, and what these ratings actually mean.
Monday, May 19, 2003 3:39:49 PM
Chapter 5: Security Models and Architecture

187
However, before we dive into these concepts, it is important to understand how the
basic elements of a computer system work. These elements are the pieces that make up
any computer’s architecture.
Computer Architecture
Put the processor over there by the plant, the memory by the window, and the secondary storage
upstairs.
Computer architecture encompasses all the parts of a computer system necessary for
it to function, including the operating system, memory chips, circuits, hard drive, secu-
rity components, buses, and networking components. The interrelationships and inter-
nal working of all of these parts can be quite complex, and making them work together
in a secure fashion is comprised of complicated methods and mechanisms. Thank
goodness for the smart people who figured this stuff out! Now it is up to us to learn how
they did it and why.
The more you understand how these different pieces work and process data, the more
you will understand how vulnerabilities actually occur and how countermeasures work
to impede and hinder vulnerabilities from being introduced, found, and exploited.
Central Processing Unit

Hey, when is it my turn to use the CPU? Answer: When the control unit says it’s your turn.
The central processing unit (CPU) is a microprocessor that contains a control unit, an
arithmetic logic unit (ALU), and registers, which are holding places for data and instruc-
tions. The control unit manages and synchronizes the system while different applica-
tions’ code and operating system instructions are being executed. It determines what
application instructions get processed and in what priority and time slice. It controls
when instructions are executed and this execution enables applications to process data.
The control unit does not actually process the data; it is like the traffic cop telling traffic
when to stop and start again, as shown in Figure 5-1.
The chips within the CPU cover only a couple of square inches, but contain over a
million transistors. All operations within the CPU are performed by electrical signals at
different voltages in different combinations, and each transistor holds this voltage,
which represents 0s and 1s to the computer. The CPU contains registers that point to
memory locations that contain the next instructions to be executed and enable the CPU
to keep status information of the data that needs to be processed. The ALU performs
mathematical functions and logical operations on data. The ALU can be thought of as
the brain of the CPU and the CPU as the brain of the computer.
Software holds its instructions and data in memory. When action needs to take place
on the data, the instructions and data are passed to the CPU portion of the system, as
shown in Figure 5-2. The CPU components handle the flow of instructions from the op-
erating system and applications. The data that needs to be processed is passed into the
instruction registers. When the control unit indicates that the CPU can process them,
they are passed to the CPU for actual processing, number crunching, and data manipu-
lation. The results are sent back to the computer’s memory so the application can use
this processed data to continue its tasks.
Monday, May 19, 2003 3:39:49 PM

188
Figure 5-1 The control unit works as a traffic cop, indicating when instructions are sent
to the processor.
Instructions and data are held in registers until needed by the CPU. The software in-
structions are first ported into the CPU because these instructions indicate what actually
needs to happen to the data. The registers are not permanent storage areas, but a tempo-
rary memory area to hold instructions that are to be interpreted by the CPU and used for
data processing.
The data being processed is entered into the CPU in blocks at a time. If the software
instructions do not properly set the boundaries for how much data can come in as a
block (for example, 64 bits at a time), extra data can slip in and be executed. This is how
buffer overflows work. If a buffer overflow takes place, it is due to the operating system or
Figure 5-2 Instructions and data are passed to the CPU for processing.
Monday, May 19, 2003 3:39:50 PM

189
application software instructions that are processing the data, not the computer system
itself. If extra data slips in, it can be executed in a privileged mode and cause disruption
and lead to unauthorized access or different degrees of damage. This can result in the
computer system freezing, rebooting, or allowing data corruption. Buffer overflows can
be corrected by well-written programs that verify how much data is being accepted and
sent to the CPU at any given point in time.
A CPU’s time and processing power has to be shared between many tasks. Software and
system interrupts are used to make sure that all data is processed in a timely manner and
priorities are used to ensure that critical tasks are performed before less important tasks.
Memory
The operating system instructions, applications, and data are held in memory, but so
are the basic input/output system (BIOS), device controller instructions, and firmware.
They do not all reside in the same memory location or even the same type of memory.
The different types of memory, what they are used for, and how each is accessed can get
a bit confusing because the CPU deals with several different types for different reasons.
The following paragraphs quickly outline the different types of memory within a
computer system.
Random access memory (RAM) is a type of temporary storage facility where data can
be held and altered. It is used for read/write activities by the operating system and appli-
cations. It is described as volatile because if the computer’s power supply is terminated,
then all information within this type of memory is lost. There are different types of
RAM, but the most well-known types are dynamic and static RAM. Static RAM lives up to
its name, because when it stores data, it stays there without the need of being continu-
ally refreshed. Dynamic RAM, on the other hand, requires that the data held within it be
periodically refreshed because the data can dissipate and decay.
Read-only memory (ROM) is a nonvolatile storage facility, meaning that when a com-
puter’s power is turned off, the data is still held within the memory chips. For the most
part, when data is inserted into ROM memory chips, it cannot be altered. The software
that is stored within ROM is called firmware.
Erasable and programmable read-only memory (EPROM) can be modified, deleted, or
upgraded. EPROM holds data that can be electrically erased or written to.
References
How RAM Works: www.howstuffworks.com/ram.htm
Unix/Linux Internals Course and Links: www.softpanorama.org/Internals
Cache Memory
I am going to need this later, so I will just stick it into cache for now.
Cache memory is a type of memory that is used for high-speed writing and reading
activities. It holds instructions and data from primary storage and is accessed when ap-
plication instructions and data are being executed. When the system assumes that it will
need to access specific information many times throughout its processing activities, it
will store it in cache memory so that it is easily and quickly accessible. Data being
retrieved from cache can be accessed much more quickly than if it was stored in real
Monday, May 19, 2003 3:39:50 PM

190
memory; thus, it affects the overall speed of the computer system. Therefore, any informa-
tion needed by the CPU very quickly, and very often, is often stored in cache memory.
An analogy is how the brain stores information that is used often. If one of Marge’s pri-
mary functions at her job is ordering parts and telling vendors the company’s address, this
information is held within a portion of her brain that is easily and quickly accessible for
Marge when she needs it. This information is held in a type of cache. If Marge was asked to
recall her third grade teacher’s name, this information would not necessarily be held in
cache memory, but in a more long-term storage facility within her noggin. The long-term
storage within her brain is comparable to a system’s hard drive. It takes more time to track
down and return information from a hard drive than specialized cache memory.
Memory Mapping
Okay, here is your memory, here is my memory, and here is Bob’s memory. No one use each
other’s memory!
Because there are different types of memory holding different types of data, a com-
puter system does not want to let every user, process, and application access all types of
memory anytime they want to. Access to memory needs to be controlled to ensure that
data does not get corrupted. This type of control takes place through memory mapping
and addressing.
The CPU is one of the most trusted components within a system, and therefore it can
access memory directly. It uses physical addresses instead of pointers to memory seg-
ments. The CPU has physical wires connecting it to the memory chips within the com-
puter. Because there are physical wires connecting the two types of components,
physical addresses are used to represent the intersection between the wires and the tran-
sistors on a memory chip. Software does not use physical addresses; instead, it uses vir-
tual or logical memory. Accessing memory indirectly provides an access control layer
between the software and the memory, which is done for protection and efficiency.
Figure 5-3 illustrates how the CPU can access memory directly using physical addresses
and how software must use memory indirectly through a memory mapper.
Let’s look at an analogy. You would like to talk to Mr. Marshall about possibly buying
some acreage in Iowa. You don’t know Mr. Marshall personally, and you do not want to
give out your physical address and have him show up at your doorstep. Instead, you
would like to use a more abstract and controlled way of communicating, so you give Mr.
Marshall your phone number so you can talk about the land and you can make a deter-
mination if you want to meet Mr. Marshall in person. The same type of thing happens in
computers. When a computer runs software, it does not want to expose itself unneces-
sarily to software written by good and bad programmers. Computers enable software to
use memory indirectly using index tables and pointers, instead of giving them the right
to access the memory directly. Only the system itself can access memory directly and
programs can access the memory indirectly, but it is the same memory storage. This is
one way the computer system protects itself.
When a program attempts to access memory, its access rights are verified and then in-
structions and commands are carried out in a way to ensure that badly written code does
not affect other programs or the system itself. Applications, and their processes, can only
Monday, May 19, 2003 3:39:51 PM

191
Figure 5-3 The CPU and applications access memory differently.
access the memory allocated to them, as shown in Figure 5-4. This type of memory ar-
chitecture provides protection and efficiency.
If programs accessed data held in memory directly, each program would have to wait
until the prior program is done before it could access and process data. Mapped mem-
ory enables different programs to access the data and perform their own separate func-
tions on it in a more economical and resourceful manner.
Secondary storage is considered nonvolatile storage media, which can be the com-
puter’s hard drive, floppy disks, or CD-ROM.
When RAM and secondary storage are combined, the result is virtual storage. The
system uses hard drive space to extend RAM memory space capability. The hard drive
space that is used to extend the RAM memory capabilities is incremented in pages.
When a system fills up its volatile memory space, it will write data from memory
onto the hard drive. When a program or user requests access to this data, it is brought from
the hard drive back into memory. This process is called paging. Accessing data that is
kept in pages on the hard drive takes more time than accessing data kept in memory
because actual disk access has to take place; however, the payoff is that it seems as
Monday, May 19, 2003 3:39:51 PM

192
Figure 5-4 Applications, and the processes they use, only access their own memory segments.
though the system can hold an incredible amount of information in memory, as shown
in Figure 5-5.
The different types of memory we looked at are summed up here:
• Primary storage Main memory directly accessed by the CPU and indirectly
accessed by applications, considered volatile memory
• Secondary storage Nonvolatile storage (floppy disk, CD-ROM disk, hard
drive, and so on)
• Virtual storage RAM and secondary storage used together
• RAM Random access memory, where instructions and data are placed when
being executed
Application
M EMORY
Application
Application
Pages Disk drive
Figure 5-5 Systems send data from memory to the hard drive in units of pages to enable memory to
reach gigabyte sizes.
Monday, May 19, 2003 3:39:52 PM

193
CPU Modes and Protection Rings
If I am corrupted, very bad things can happen. Response: Then you need to go into ring 0.
If an operating system is going to be stable, it must be able to protect itself from its
users and their applications. This requires the capability to distinguish between opera-
tions performed on behalf of the operating system itself and operations performed on
behalf of the users or applications. This can be complex because the operating system
software can be accessing memory segments, sending instructions to the CPU for pro-
cessing, and accessing secondary storage devices. Each user application (e-mail client,
antivirus, Web browser, word processor, personal firewall, and so on) can be attempt-
ing the same types of activities at the same time. The operating system must keep track
of all of these events and ensure that none of them violates the security policy.
The operating system has several protection mechanisms to ensure that processes do
not negatively affect each other or the critical components of the system itself. One has
already been mentioned: memory segments. Another security mechanism that the sys-
tem uses is protection rings. These rings provide strict boundaries and definitions for
what the processes that work within each ring can access and what operations they can
successfully execute. The processes that operate within the inner rings have more privi-
leges than the processes operating in the outer rings. This is because the inner rings only
permit the most trusted components and processes to operate within them. Although
operating systems can vary in the number of protection rings, processes that execute
within the inner rings are usually referred to as existing in a privileged, or supervisor,
mode. The processes working in the outer rings are said to execute in a user mode.
NOTE The actual ring architecture that is being used by a system is dictated
by the processor and the operating system. The hardware chip (processor) is
constructed to work with a certain number of rings, and the operating system
must be developed to also work in this ring structure. This is one reason why
one operating system platform may work with an Intel chip, but not an Alpha chip. They
have different architectures and ways to interpret instruction sets.
Operating system components operate in a ring that gives them the most access to
memory locations, peripheral devices, system drivers, and sensitive configuration pa-
rameters. Because this ring provides much more dangerous access to critical resources, it
is the most protected. Applications usually operate in ring 3, which limits the type of
memory, peripheral device, and driver access activity, and is controlled through the op-
erating system functions or system calls. The different rings are illustrated in Figure 5-6.
The type of commands and instructions that are sent to the CPU from applications in
the outer rings are more restrictive in nature. If an application tries to send instructions
to the CPU that fall outside of its permission level, the CPU treats this violation as an ex-
ception and may show a general protection fault, panic, or exception error and attempt
to shut down the offending application.
Monday, May 19, 2003 3:39:53 PM

194
Figure 5-6 More trusted processes operate within lower-numbered rings.
Protection rings support the availability, integrity, and confidentiality requirements

of multitasking operating systems. Many systems use four protection rings:
• Ring 0 Operating system kernel
• Ring 1 Remaining parts of the operating system
• Ring 2 I/O drivers and utilities
• Ring 3 Applications and programs
These protection rings provide an intermediate layer between subjects and objects,
and are used for access control when a subject tries to access an object. The ring deter-
mines the access level to sensitive system resources. The lower the number, the greater
the amount of privilege that is given to the process that runs within that ring. Each sub-
ject and object is logically assigned a number (0 through 3) depending upon the level of
trust the operating system assigns it. A subject in ring 3 cannot directly access an object
Monday, May 19, 2003 3:39:53 PM

195
in ring 1, but subjects in ring 1 can directly access an object in ring 3. Entities can only
access objects within their own ring and outer rings, as shown in Figure 5-7. When an
application needs access to components in rings that it is not allowed to directly access,
it makes a request of the operating system to perform the necessary tasks. This is han-
dled through system calls, where the operating system executes instructions not allowed
in user mode. The request is passed off to an operating system service, which works
at a higher privilege level and can carry out the necessary task.
When the operating system executes instructions for processes in rings 0 and 1, it op-
erates in system mode or privileged mode. When the operating system executes instruc-
tions for applications and processes in ring 3, it operates in user mode. User mode
provides a much more restrictive environment for the application to work in, which in
turn protects the system from misbehaving programs.
Process Activity
Computers can run different applications and programs at the same time. They have to
share resources and play nice with each other to ensure a stable and safe computing en-
vironment that maintains its integrity. Some memory, data files, and variables are actu-
ally shared between different applications. It is critical that more than one process does
not attempt to read and write to these items at the same time. The operating system is
the master program that prevents this type of action from taking place and ensures that
programs do not corrupt each other’s data held in memory. The operating system works
with the CPU to provide time slicing and interrupts to ensure that processes are pro-
vided with adequate access to the CPU. This also ensures that critical system functions
are not negatively affected by rogue applications.
Figure 5-7
Ring 3
Processes in
inner rings can
Ring 2
directly access
processes in Ring 1
outer modes but
not vice versa.
Ring 0
Ring 0—Operating system kernel

Ring 1—Remaining parts of the operating system
Ring 2—I/O drivers and utilities
Ring 3—Applications and programs
Monday, May 19, 2003 3:39:54 PM

196
Process versus Thread

A process is a program in execution that works in its own address space and can
only communicate with other processes in a controlled manner. A thread repre-
sents a piece of code that is executed within a process, as shown here. A process can
have one or more threads running at one time, depending upon the tasks it needs
to carry out.
Operating States
I am in a problem state. Is that bad? Answer: Nope, the CPU is just carrying out your request.
The operating system itself can be in one of two modes at any given point in time. The
operating system can operate in privileged (supervisor state) or user mode (problem
state) depending on what process made a request to execute instructions, but there are
also different operating states in which the different processes can work within. The fol-
lowing outlines the four possible states a process can operate in:
• Stopped The process is not running.
• Waiting The process is waiting for an interrupt to be able to be interact with
the CPU.
• Running The process’s instructions are being executed by the CPU.
• Ready The process is available to be used and waiting for an instruction.
These protection rings, operational modes, and operating states work together to en-
sure a secure and predictable operating environment. They enable the system to protect
itself and work to protect the availability, integrity, and confidentiality of the system,
the information that is being processed, and the applications installed.
Monday, May 19, 2003 3:39:56 PM

197
When an application runs on a computer, it thinks it is the only program running. It
does not necessarily know that it is sharing resources with several other types of pro-
grams, the operating system, and other processes. This simplifies the issues that pro-
grammers need to be concerned about when writing an application. Because the
application thinks it is the only one executing, it needs to be presented with an environ-
ment that reflects this type of reality. This can be done through virtual machines and
virtual memory. The operating system creates a virtual environment (virtual machine)
for the application to work in and allots it a segment of virtual memory, as shown in
Figure 5-8. Another application could have its own virtual machine and virtual address
segment, and the two would not know that each other even existed. This way the two ap-
plications do not interact with each other’s data in memory or step on each other’s toes
while being executed by the CPU. It is a very orchestrated, controlled, and timed
event-oriented atmosphere. An analogy is two people with two different offices. George
has his office, computer, file cabinet, closet, and window. Marge has an office with the
same materials. If George and Marge had to use the same computer, file cabinet, and
closet, they could easily move each other’s items around, accidentally delete each
other’s files, or wear each other’s coat home. However, because they each have their own
office and components, these events will not take place.
The granularity of this type of separation and protection becomes very detailed
within a computer system. A process is used to request resource access and carry out data
manipulation activities, and is the mechanism used to enable applications and the op-
erating system to communicate. A process is like a phone call. If an application wants to
print a form, it calls (or communicates via a process) the operating system, which calls
the printer driver, and the printer driver calls the printer. These processes can only com-
municate in a way that has been previously approved by the operating system and out-
lined in the security model. The application cannot make a direct call to the printer
driver because it does not operate in a privileged ring; thus, it does not have the neces-
sary type of authority. The security architecture of the operating system dictates this type
of communication authority.
Figure 5-8 Virtual machines only access their allotted memory segments.
Monday, May 19, 2003 3:39:56 PM

198
One application can make several calls at one time. It can ask to print a form, accept a
fax, display data to the monitor, and ask for an address from the address book. These
different calls use different threads and are an example of multithreading. A system that
can process more than one request at a time is capable of multithreading. If the CPU can
process more than one process, or task, at one time, it is considered a multitasking sys-
tem. If a computer has more than one CPU (also called processor), it can use them in
parallel to execute instructions; this activity is called multiprocessing. Multiprogramming
is the interleaved execution of two or more programs by a CPU. The system can run
more than one application, but not necessarily perform multithreading or multitasking.
Older operating systems used multiprogramming instead of multitasking, but this was
not an effective practice because a process could commit a resource and no other pro-
cesses could use that resource until it was properly released by the first process. This ap-
proach to operating system operations gives the processes too much control. Newer
operating systems gave this control to the operating system instead of the individual
processes.
An operating system has to protect its integrity and ensure that users do not acciden-
tally or intentionally access someone else’s data. Multitasking systems interleave the ex-
ecution of processes belonging to different users, which adds complexity to protecting
itself and users’ data. The operating system uses logical separation between users’ data,
which takes place in file and memory management.
Input/Output Device Management

When a user chooses to print a document, or a word processor displays a file previously
stored, or if a user saves files to a zip drive, these requests are going from the application
the user is working in, through the operating system, and to the device requested. The
operating system uses a device driver to communicate to a device controller, which is an
electrical component with its own software used to provide a communication path that
enables the device and operating system to exchange data. The operating system sends
commands to the device controller’s registers and the controller then writes data to the
peripheral device or extracts data to be processed by the CPU, depending on the given
commands. This communication happens through specific communication channels
dedicated just for these types of functions. Once the device controller retrieves the re-
quested information, it is stored in main memory for the operating system, application,
and CPU to perform their necessary functions.
It is important that the devices and computer resources are properly accessed and re-
leased. Different operating systems handle accessing devices and resources differently.
For example, Windows NT is considered a more stable and safer data processing envi-
ronment than Windows 9x because applications cannot make direct requests to hard-
ware devices. Windows NT and Windows 2000 have a much more controlled method of
accessing devices than Windows 9x. This helps to protect the system from badly written
code that does not properly request and release resources. This level of protection helps
to ensure the resources’ integrity and availability.
Proper input/output management is a core component of operating systems. When a
request for a resource (memory allocation, printer, secondary storage devices, disk
space) is made, certain data structures are built and processes are dedicated for this
Monday, May 19, 2003 3:39:56 PM

199
action to take place. Once the action takes place (a document is printed, a file is saved,
or data is retrieved from the drive), the program, or operating system, needs to tear
down these built structures and release the resources back into a pool to be available for
other programs and processes. If this does not happen properly, a deadlock situation can
occur or a computer may not have enough resources to process other requests (result of
a denial-of-service attack). A deadlock situation can happen with peripheral devices,
memory, database, or file access. If Sean accesses a database and his process never prop-
erly releases the necessary resources back to the system, when Debbie attempts to per-
form the same action, a deadlock situation can occur and Sean, Debbie, and the system
that contains the database can be negatively affected. This has a direct correlation to a
main security principle: availability. The database software should apply a software lock
when Sean accesses information in the database, which will ensure that no one else,
including Debbie, can access and modify the same data until Sean is done.
Another common deadlock situation is when process A commits resource 1 and
needs to use resource 2 to properly complete its task. But process B has committed re-
source 2 and needs resource 1 to finish its job. So both processes are “hung” because
they do not have the resources they need to finish the function they are to carry out. This
activity does not take place as much as it used to because better programming is usually
performed. Also the environment (operating system, database software, application)
now has the intelligence to detect this activity and will either release committed re-
sources or control how resources are going to be properly shared between processes.
Operating systems have different methods of dealing with resource requests and re-
leases and solving deadlock situations. In some systems, if a requested process is unavail-
able for a certain period of time, some operating systems will kill that process. This action
releases the process from the application that had committed it, releases the supporting
system resources necessary to commit this resource, and restarts the process so it is “clean”
and available to be used by other applications. Other operating systems might require a
program to request all of the resources it needs before it actually starts executing instruc-
tions or requires a program to release its currently committed resources before being able
to acquire more. Input/output management is a core responsibility of the operating sys-
tem, along with memory management, CPU tasks, and file system management.
Tying It Together
Each of the topics discussed in earlier sections have complete books written on them be-
cause of their complexity and importance to the computing world. Each topic also relates
in some way to a part of security. An operating system is a complex beast that performs
many complicated tasks in order to provide a useful and secure work environment for a
user. It must recognize each process and program that is running, make access decisions,
support system calls, protect memory segments, validate requested commands, properly
process instructions, and ensure that none of these activities introduce vulnerabilities that
can violate the security policy of the system. It does this by enforcing protection rings,
mapping memory, implementing virtual machines, working in different states, and as-
signing trust levels to each and every process. These are integral parts of the security model
for the operating system.
Monday, May 19, 2003 3:39:56 PM

200
System Architecture
Designing a system from the ground up is a complicated task and has many intricate
and abstract goals that have to be achieved through mathematics, logic, design, pro-
gramming code, and implementation. There are fundamental design decisions that
need to be made when constructing a system. Security is only one of the goals of a sys-
tem, but it is the goal security professionals are most concerned about.
Availability, integrity, and confidentiality can be enforced at different places within
an enterprise. For example, a company may store customer credit card information in a
database that many users can access. This information, obviously, requires protection to
ensure that it is not accessed or modified in an unauthorized manner. We start with gen-
eral questions and gradually drill down into the details. Where should this protection
be placed? Should there be access controls that screen users when they log in and assign
them their rights at that point dictating what data they can and cannot access? Should
the data files holding the credit card information be protected at the file system level?
Should protection be provided by restricting users’ operations and activities? Or should
there be a combination of all of these? The first and most general question is “Where
should the protection take place: at the user’s end, where the data is stored, or by restrict-
ing user activities within the environment?” This is illustrated in Figure 5-9.
Once these general questions have been answered, the placement of the mechanisms
needs to be addressed. Security mechanisms can be placed at the hardware, kernel, oper-
ating system, services, or program layers. At which layer(s) should security mechanisms
be implemented? If protection is implemented at the hardware layer, the protection
mechanisms will be more simplistic and provide broad and general protection. As we
ascend up the layers, more complexity is added, and functionality becomes more spe-
cific and granular. The top layer holds the most complexity because it is directed toward
providing the user with a vast amount of functionality and options. Functionality and
complexity of security increases as it approaches the layers that are closer to the user. The
increased complexity lowers the assurance levels of the security mechanisms. This is
shown in Figure 5-10.
The more complex a security mechanism becomes, the less assurance it provides. This
is because the complexity of the mechanism demands more technical understanding
from the individuals who install, test, maintain, and use it. The more complex the tools,
the more chances there are for errors, and therefore increased chances for security com-
promises. The more complex the security mechanism, the harder it is to fully test it under
Figure 5-9 Security can take place at three main areas.
Monday, May 19, 2003 3:39:57 PM

201
Figure 5-10
As functionality
increases,
complexity
increases and
the assurance of
security decreases.
all possible conditions. On the other hand, simplistic mechanisms cannot provide the de-
sired richness of functionality and options, although they are easier to install, maintain,
use, and test. So the tradeoffs between functionality and assurance need to be fully under-
stood to make the right security mechanism choices when designing a system.
Once the designers have an idea of what the security mechanisms should focus on
(users, operations, or data), what layer(s) the mechanisms should be placed at (hard-
ware, kernel, operating system, services, or program), and the complexity of each mech-
anism, the mechanisms need to be built and integrated in a way to have a proper
relationship with other parts of the system.
The first step is to decide what system mechanisms need to be trusted and specify how
these entities can interact in a secure manner. Although it might seem that you would
want to trust all the components within the system, this would cause too much overhead,
complexity, and performance bottlenecks. For a mechanism to be trusted, it means that it
protects itself and the data it is processing, it performs in predictable and secure manners,
and it does not adversely affect other trusted or untrusted mechanisms. In return, these
trusted components have access to more privileged services, have direct access to memory,
usually have higher priority when requesting CPU processing time, and have more con-
trol over system resources. So the trusted subjects and objects need to be identified and
distinguished from the untrusted ones and placed into defined subsets.
Monday, May 19, 2003 3:39:58 PM

202
Defined Subset of Subjects and Objects
I totally trust you. You can do whatever you want. Response: I want to leave.
As stated previously, not all components need to be trusted and therefore do not fall
within the trusted computing base (TCB). The TCB is defined as the total combination of
protection mechanisms within a computer system. The TCB includes hardware, soft-
ware, and firmware. These are part of the TCB because the system is sure that these com-
ponents will enforce the security policy and not violate it.
The components that do fall under the TCB need to be identified and their accepted ca-
pabilities defined. For example, a system that has a lower trust level rating may permit all
authenticated users to access and modify all files on the computer. This subset of subjects
and objects is large and the relationship between them is loose and relaxed. A system with
a much higher trust level rating may permit only two subjects to access all files on a com-
puter system, and only one of those subjects can actually modify all the files. This subset is
much smaller and the rules being enforced are more stringent and detailed.
Again, it depends upon what type of system the developers are aiming at building. If
developers want to develop a system that achieves an Orange Book security rating of D
(very low), then what makes up the TCB or not is not much of an issue because the sys-
tem will not be expected to provide a very high level of security. However, if the develop-
ers want to develop a system with an Orange Book rating of B2 or B1 (much higher than
rating D), they will need to specify what makes up the TCB. They need to enforce strict
rules that dictate how subjects and objects interact. The developers also need to ensure
that these items are identified, authenticated, and audited because these are the compo-
nents that will be scrutinized, tested, and evaluated before a rating of B2 or B1 can be
given. (The Orange Book and its ratings are addressed in the section “The Orange Book”
later in the chapter.)
Trusted Computing Base

The term “trusted computing base” originated from the Orange Book and does not ad-
dress the level of security a system provides, but the level of trust, albeit from a security
sense. This is done because no computer system can be totally secure. The types of attacks
and vulnerabilities change and evolve over time, and with enough time and resources,
most attacks can become successful. However, if a system meets a certain criteria, it is
looked upon as providing a certain level of trust, again, from a security perspective.
The TCB does not just address operating systems, because a computer system is not
made up of only an operating system. The TCB addresses hardware, software compo-
nents, and firmware. Each can affect the computer’s environment in a negative and posi-
tive manner, and each has a responsibility to support and enforce the security policy of
that particular system. Some components and mechanisms have direct responsibilities in
supporting the security policy, such as firmware that will not let a user boot a computer
from a floppy disk or the memory manager that will not let users overwrite other users’
data. Then there are components that do not enforce the security policy, but must behave
properly and not violate the trust of a system. The types of violations a component could
cause against the system’s security policy could be an application that attempts to make a
direct call to a piece of hardware instead of using the proper calls through the operating
system, a program that attempts to read data outside of its approved memory space, or
a piece of software that does not properly release resources after use.
Monday, May 19, 2003 3:39:58 PM

203
Not every part of a system needs to be trusted. Part of evaluating the trust level of a
system is to identify the architecture, security services, and assurance mechanisms that
make up the TCB. It must be shown how the TCB is protected from accidental or inten-
tional tampering and compromising activity. For systems to achieve a higher trust level,
they must meet well-defined TCB requirements, and the details of their operational
states, developing stages, testing procedures, and documentation will be reviewed with
more granularity than systems that are attempting to achieve a lower trust rating.
By using specific security criteria, trust can be built into a system, evaluated, and certified.
This approach can provide a measurement system for customers to use when comparing
one system to another. It also gives vendors guidelines on what expectations are put upon
their systems and provides a common security rating so when one group talks about a C2
rating, everyone else is on the same page and understands what these terms mean.
The Orange Book defines a trusted system as hardware and software that utilize mea-
sures to protect the integrity of unclassified or classified data for a range of users without
violating access rights and the security policy. It looks at all protection mechanisms
within a system to enforce the security policy and provide an environment that will be-
have in a manner expected of it. This means that each layer of the system must trust the
underlying layer to perform the expected functions, provide the expected functionality,
and operate in an expected manner under many different situations. When the operat-
ing system makes calls to hardware, it is anticipating data to be returned in a specific
data format and to behave in a consistent and predictable manner. Applications that
run on top of the operating system expect to be able to make certain system calls and re-
ceive the required data in return and to be able to operate in a reliable and dependable
environment. Users expect the hardware, operating system, and applications to perform
in particular fashions and provide a certain level of functionality. For all of these actions
to behave in such predicable manners, the requirements of a system must be addressed
in the planning stages of development, not afterwards.
Security Perimeter
Now, whom do we trust? Answer: Anyone inside the security perimeter.
As stated previously, not every component and resource falls within the TCB, so some
resources fall outside of this imaginary boundary referred to as the security perimeter. A
perimeter is a boundary that divides the trusted from the untrusted. For the system to stay
in a secure and trusted state when a component within the TCB needs to communicate
with a component outside of the TCB, precise communication standards must be devel-
oped to ensure that this type of communication cannot bring on unexpected security
compromises. This type of communication is handled and controlled through interfaces.
For example, a resource that is within the boundary of the TCB, or security perimeter,
must not pass confidential information to resources outside the TCB. The resource
within the TCB must also be careful about the commands and information it accepts
from less-trusted resources. These limitations and restrictions are built into the inter-
faces that permit this type of communication to take place and are the mechanisms that
enforce the security perimeter, as shown in Figure 5-11. Communication between
trusted components and untrusted components needs to be controlled to ensure that
confidential information does not flow in an unintended way.
Monday, May 19, 2003 3:39:58 PM

204
Figure 5-11 Interfaces control the communication between trusted and untrusted processes.
NOTE The TCB and security perimeter are not physical entities, but
conceptual constructs used by the operating system to delineate between
trusted and untrusted components. They are illustrated here to show the
relationship of the TCB, security perimeter, and different components.
Reference Monitor and Security Kernel

Up to now, our computer system architecture developers have accomplished many
things in developing their system. They have defined where the security mechanisms
will be located (hardware, kernel, operating system, services, or program), they have de-
fined the objects that are within the TCB and how those components will interact with
each other. The security perimeter that separates the trusted components and the
untrusted components has been constructed. They have developed proper interfaces for
these entities to communicate securely. Now they need to develop and implement a
mechanism that ensures that the subjects that access objects have been given the neces-
sary permissions to do so. This means the developers need to develop and implement
a reference monitor and security kernel.
The reference monitor is an abstract machine, which mediates all access subjects have to
objects to ensure that the subjects have the necessary access rights and to protect the ob-
jects from unauthorized access and destructive modification. For a system to achieve a
higher level of trust, it must enforce subjects (programs, users, or processes) to be fully au-
thorized prior to accessing an object (file, program, or resource). It must be made certain
that the subject has been granted access privileges prior to letting the subject use the re-
quested object. The reference monitor is an access control concept, not an actual physical
component, and that is why it is normally referred to as the “reference monitor concept.”
Monday, May 19, 2003 3:39:59 PM

205
The security kernel is made up of mechanisms that fall within the TCB and implements
and enforces the reference monitor concept. The security kernel is made up of hardware,
firmware, and software components that mediate all access and functions between sub-
jects and objects. The security kernel is the core of the TCB and is the most commonly
used approach to building trusted computing systems. There are four main requirements
of the security kernel:
• It must provide isolation for the processes carrying out the reference monitor
concept and they must be tamperproof.
• The reference monitor must be invoked for every access attempt and must be
impossible to circumvent. Thus, the reference monitor must be implemented
in a complete and foolproof way.
• The reference monitor must be verifiable as being correct. This means that all
decisions made by the reference monitor should be written to an audit log, and
verified as being correct.
• It must be small enough to be able to be tested and verified in a complete and
comprehensive manner.
These are the requirements of the reference monitor; therefore, they are the require-
ments of the components that provide and enforce the reference monitor concept—the
security kernel.
These issues work in the abstract, but are implemented in the physical world of hard-
ware devices and software code. The assurance that the components are enforcing the
abstract idea of the reference monitor is proved through testing and functionality.
NOTE The reference monitor is a concept where an abstract machine

mediates all accesses to objects by subjects. The security kernel is the
hardware, firmware, and software of a TCB that implements this concept.
The TCB is the totality of protection mechanisms within a computer system
that work together to enforce a security policy. The TCB contains the security kernel and
all other security protection mechanisms.
Figure 5-12 provides a quick analogy to show you the relationship between the com-
ponents that make up the kernel, the kernel itself, and the reference monitor concept.
Individuals make up a society. The individuals can represent the components and the
society can represent the kernel. For a society to have a certain standard of living, it
needs to react in specific ways, which is why we have laws. The laws represent the refer-
ence monitor, which enforces proper activity. Each individual is expected to stay within
the bounds of the laws and act in specific ways so society as a whole is not adversely af-
fected and the standard of living is not threatened. The components within a system
must stay within the bounds of the reference monitor’s laws so that they will not ad-
versely affect other components and threaten the security of the system.
Monday, May 19, 2003 3:39:59 PM

206
Figure 5-12 Components, like people, need to say inside the bounds of the rules.
References
Rationale Behind the Evaluation Classes: www.kernel.org/pub/linux/libs/
security/Orange-Linux/refs/Orange/OrangeI-II-6.html
The Reference Monitor Concept: citeseer.nj.nec.com/299300.html
Implementing Complete Mediation: www.cs.cornell.edu/html/cs513-sp99/
NL05.html
Domains
Okay, here are all the marbles you can play with. We will call that your domain of resources.
A domain is defined as a set of objects that a subject is able to access. This domain can
be all the resources a user can access, all the files available to a program, the memory seg-
ments available to a process, or the services and processes available to an application. A
subject needs to be able to access and use objects (resources) to perform tasks, and the
domain defines which objects are available to the subject and which objects are un-
touchable and therefore unusable by the subject.
These domains have to be identified, separated, and strictly enforced. An operating
system may work in a privileged mode and a user mode. The reason to even use these
two different modes is to define two different domains. The privileged mode has a much
larger domain to work with (or more resources to access); thus, it can provide much
more functionality. When an operating system works in privileged mode, it can physi-
cally access memory modules, transfer data from an unprotected domain to a protected
Monday, May 19, 2003 3:40:00 PM

207
domain, and directly access and communicate with hardware devices. An application
that functions in user mode cannot access memory directly and has a more limited
amount of resources available to it. Only a certain segment of memory is available to
this application and it must be accessed in an indirect and controlled fashion. The appli-
cation can copy files only within its own domain and cannot access hardware directly.
A program that resides in a privileged domain needs to be able to execute its instruc-
tions and process its data with the assurance that programs in a different domain cannot
negatively affect its environment. This is referred to as an execution domain. Because pro-
grams in a privileged domain have access to sensitive resources, the environment needs
to be protected from rogue program code or unexpected activities resulting from pro-
grams in other domains. Some systems may only have distinct user and privilege areas,
whereas other systems may have complex architectures that contain up to ten security
domains.
A security domain has a direct correlation to the protection ring that a subject or ob-
ject is assigned to. The lower the protection ring number, the higher the privilege and
the larger the security domain. This concept is depicted in Figure 5-13.
Figure 5-13 The higher the level of trust, the larger the number of available resources.
Monday, May 19, 2003 3:40:00 PM

208
Resource Isolation
You, go into this room and play all by yourself.
To properly enforce access control, auditing, and determining what subjects and ob-
jects reside in specific domains, each resource has to be clearly separated from one an-
other. This modularity requirement enables each subject and object to be identified
uniquely, permissions and rights to be assigned independently, accountability to be en-
forceable, and intricate activities to be tracked precisely. The subjects, objects, and protec-
tion controls need to be clearly isolated from each other, and the isolation methods and
enforcement are a requirement of the architecture of a system and its security model.
Processes are also resources that need to be isolated and this is usually done through
distinct address allocation. Virtual memory (explained in the section “Process Activity”
earlier in the chapter) techniques are used to make sure different processes have their
own memory addresses to use and do not access each other’s memory. If a process has a
particular memory range allocated to it, it does not know there is other memory in the
system. The process works happily in the memory allocated and does not stomp on an-
other process’s data in another segment of memory.
Systems of a higher trust level may need to implement hardware segmentation of the
memory used by different processes. This means that memory is separated physically
instead of just logically. This adds another layer of protection to ensure that a lower-
privileged process does not access and modify a higher-level process’s memory space.
Security Policy
We have stated that the TCB contains components that directly enforce the security pol-
icy, but what is a security policy?
A security policy is a set of rules and practices dictating how sensitive information is
managed, protected, and distributed. A security policy expresses exactly what the secu-
rity level should be by setting the goals of what the security mechanisms are to accom-
plish. This is an important element that has a major role in defining the design of the
system. The security policy is a foundation for the specifications of a system and pro-
vides the baseline for evaluating a system. In Chapter 3, security policies were examined
in depth, but those policies were directed toward the company itself. The security poli-
cies being addressed here are for operating systems and applications. The different policies
are similar but have different targets: an organization as opposed to an individual com-
puter system.
A system provides trust by fulfilling and enforcing the security policy and typically
deals with the relationships between subjects and objects. The policy must indicate
what subjects can access individual objects, and what actions are acceptable and unac-
ceptable. The definition of what trust means is derived from a framework and the secu-
rity policy works as this framework for computing systems.
For a system to provide an acceptable level of trust, it must be based on an architec-
ture that provides the capabilities to protect itself from untrusted processes, intentional
or accidental compromises, and attacks at different layers of the system. A majority of
the trust ratings require a defined subset of subjects and objects, explicit domains, and
Monday, May 19, 2003 3:40:00 PM

209
the isolation of resources so their access can be controlled and activities performed on
them can be audited.
Let’s regroup. We know that a system’s trust is defined by a set of criteria. When a sys-
tem is tested against this set of criteria, a rating is assigned to the system and this rating is
used by customers, vendors, and the computing society as a whole. The criteria will de-
termine if the security policy is being properly supported and enforced. The security pol-
icy lays out the rules and practices pertaining to how a system will manage, protect, and
distribute sensitive information. The reference monitor is a concept that says all subjects
must have proper authority to access objects and is implemented by the security kernel.
The security kernel is made of all the resources that supervise system activity in accor-
dance with the system’s security policy and is part of the operating system that controls
access to system resources. For this to work correctly the individual resources need to be
isolated from each other and domains need to be defined to dictate what objects are
available to what subjects.
Security policies that prevent information from flowing from a high security level to
a lower security level are called multilevel security policies. These types of policies per-
mit a subject to access an object only if the subject’s security level is higher than or
equal to the object’s classification.
As we said, these are abstract ideas that will be manifested into physical hardware
components, firmware, software code, and activities through designing, building, and im-
plementing a system. These ideas are like abstract goals and dreams we would like to ac-
complish, which are accomplished by our physical hard work and items that we produce.
Least Privilege
Once resources and processes are isolated properly, least privilege needs to be enforced.
This means that a process has no more privileges than necessary to be able to fulfill its
functions. Only processes that need to carry out critical system functions should be al-
lowed to, and other less-privileged processes should call upon the more privileged pro-
cesses to carry out these types of activities when necessary. This type of indirect activity
protects the system from poorly written or misbehaving code. Processes should possess
a level of privilege only as long as they really need it. If a process needs to have its status
elevated so it can interact directly with sensitive information, as soon as its tasks are
complete, the process’s status should be dropped to a lower privilege to ensure that an-
other mechanism cannot use it to adversely affect the system. Only processes needing
complete system privileges are located in the kernel; other less-privileged processes call
upon them to process sensitive or delicate operations.
References
Access Control Policies and Mechanisms: www.cs.cornell.edu/html/
cs513-sp99/NL03.html
Information Warfare Site: www.iwar.org.uk/comsec/resources/standards/
rainbow/NCSC-TG-028.htm
Discretionary Protection: www.kernel.org/pub/linux/libs/security/
Orange-Linux/refs/Orange/OrangeI-II-2.html
Monday, May 19, 2003 3:40:01 PM

210
Layering, Data Hiding, and Abstraction
You can’t see me, you don’t know that I exist, so you can’t talk to me. Response: Fine by me.
Systems that meet certain trust levels must supply mechanisms that force processes to
work in layers, which means certain functionality takes place in different layers of a sys-
tem. This requires a structured and hierarchical architecture that has the basic function-
ality taking place at lower layers and more complex, sensitive functions at the higher
layers. Layering further separates processes and resources and adds modularity to the
system. The layers can communicate, but only through detailed interfaces that uphold
the security integrity of the system. In some instances, it is required that processes in dif-
ferent layers do not communicate; therefore, they are not supplied with interfaces to in-
teract with each other. This process is called data hiding in that the data in one layer is
hidden because the subjects in another layer do not even know that the data exists. If a
subject in one layer has no interface to be able to communicate with data at another
layer, this data is hidden from that subject.
Objects can be grouped into sets called classes. When a class of objects is assigned spe-
cific permissions and acceptable activities are defined, it is called abstraction. This makes
management of different objects easier because classes can be dealt with instead of each
and every individual object. When a class is defined, all the objects within that class are as-
signed an abstract data type, which is a precise definition of the format the object will ac-
cept data and the format it will present its processed data to other objects and subjects.
This provides a predictable way of communicating and helps prevent authorized entities
from modifying the data within an object in an inappropriate way. For example, when
one object passes a registry value to another object, it is done in a predefined manner and
the receiving object will not accept values outside of these predefined boundaries. If the
receiving object is expecting a binary value, it will not accept a hexadecimal value in its
place. This type of restriction is defined in the object’s abstract data type.
Layering, data hiding, and abstraction are all methods to protect subjects, objects, and
the data within the objects. These concepts are foundational pieces to a security model.
Security Models
An important concept in the design and analysis of secure systems is the security model,
because it incorporates the security policy that should be enforced in the system. A
model is a symbolic representation of a policy. It maps the desires of the policy makers
into a set of rules that are to be followed by a computer system.
We have continually mentioned the security policy and its importance, but it is an ab-
stract term that represents the objectives and goals a system must meet and accomplish to
be deemed secure and acceptable. How do we get from an abstract security policy to an
administrator being able to uncheck a box on the graphical user interface (GUI) to disal-
low David from accessing configuration files on his system? There are many complex
steps in between that take place during the system’s design and development.
A security model maps the abstract goals of the policy to information system terms by
specifying explicit data structures and techniques necessary to enforce the security pol-
icy. A security model is usually represented in mathematics and analytical ideas, which
are then mapped to system specifications, and then developed by programmers through
Monday, May 19, 2003 3:40:01 PM

211
Analogy of the Relationship Between a Security Policy and a Security Model

If someone tells you to live a healthy and responsible life, this is a very broad,
vague, and abstract notion. So when you ask this person how this is accomplished,
they outline the things you should and should not do (do not harm others, do not
lie, eat your vegetables, and brush your teeth). The security policy provides the ab-
stract goals, and the security model provides the dos and don’ts necessary to fulfill
these goals.
programming code. So we have a policy that encompasses security goals like “each sub-
ject must be authorized to access each object.” The security model takes this require-
ment and provides the necessary mathematical formulas, relationships, and structure to
be followed to accomplish this goal. From here, specifications are developed per operat-
ing system type (Unix, Windows, or Macintosh), and individual vendors can decide
how they are going to implement mechanisms that meet these necessary specifications.
So in a very general and simplistic example, if a security policy states that subjects need
to be authorized to access objects, the security model would provide the mathematical re-
lationships and formulas explaining how x can access y only through outlined specific
methods. Specifications are then developed to provide a bridge to what this means in a
computing environment and how it maps to components and mechanisms that need to
be coded and developed. The developers then write the program code to produce the
mechanisms that provide a way for a system to use access control lists and give adminis-
trators some degree of control. This mechanism presents the network administrator with
a GUI representation, like check boxes, to choose which subjects can access what objects,
to be able to set this configuration within the operating system. This is a rudimentary ex-
ample because security models can be very complex, but it is used to demonstrate the rela-
tionship between the security policy and the security model.
Some security models enforce rules to protect confidentiality, such as the Bell- LaPadula
model. Other models enforce rules to protect integrity, such as the Biba model. Formal se-
curity models, such as Bell-LaPadula and Biba, are used to provide high assurance in secu-
rity. Informal models, such as Clark-Wilson, are used more as a framework to describe how
security policies should be expressed and executed.
A security policy outlines goals with no idea of how they would be accomplished. A
model is a framework that gives the policy form and solves security problems for partic-
ular situations. Several security models have been developed to enforce security poli-
cies, and the following sections provide overviews of each model.
State Machine Models

No matter what state I am in, I am always trustworthy.
In state machine models, to verify the security of a system, the state is used, which
means all current permissions and all current instances of subjects accessing objects
Monday, May 19, 2003 3:40:01 PM

212
must be captured. Maintaining the state of a system deals with each subject’s associa-
tion with objects. If the subjects can only access objects by means that are concurrent
with the security policy, the system is secure. State machines have provided a basis for
important security models. A state of a system is a snapshot of a system in one moment
of time. There are many activities that can alter this state, which is referred to as a state
transition. The developers of an operating system that will implement the state ma-
chine model need to look at all of the different state transitions that are possible and as-
sess if a system starts up in a secure state, can any of these events put the system into an
insecure state? If all of the activities that are allowed to happen in the system do not
compromise the system and put it into an insecure state, then the system executes a secure
state machine model.
So a system that has employed a state machine model will be in a secure state in
each and every instance of its existence. It will boot up into a secure state, execute com-
mands and transactions securely, allow subjects to access resources only in secure states,
and shut down and fail in a secure state. Failing in a secure state is extremely important.
It is imperative that if anything unsafe takes place that the system can “save itself” and
not make itself vulnerable. When a user sees error messages, or a system reboots or
freezes, these are all safety measures. The operating system has experienced something
that is deemed illegal and it cannot take care of the situation itself, so to make sure it
does not enter an insecure state it reacts in one of these fashions. So if an application or
system freezes on you, know that it is the system just trying to protect itself and your data.
Bell-LaPadula Model
I don’t want anyone to know my secrets. Response: We need Mr. Bell and Mr. LaPadula in
here then.
In the 1970s, the U.S. military used time-sharing mainframe systems and was con-
cerned about the security of these systems and leakage of classified information. The
Bell-LaPadula model was developed to address these concerns. It was the first mathe-
matical model of a multilevel security policy used to define the concept of a secure state
machine and modes of access and outline rules of access. Its development was funded
by the U.S. government to provide a framework for computer systems that would be
used to store and process sensitive information. The model’s main goal is to prevent secret
information from being accessed in an unauthorized manner.
A system that employs the Bell-LaPadula model is called a multilevel security system
because users with different clearances use the systems, and the systems process data
with different classifications. The level at which information is classified determines the
handling procedures that should be used. These access rights together form a lattice,
which is an upper bound and lower bound of authorized access. A subject that has top
secret clearance can access top-secret, secret, and unclassified data. Top secret is the upper
bound and unclassified is the lower bound. Mandatory access control is based on a lattice
of security labels.
The Bell-LaPadula model is a state machine model enforcing the confidentiality as-
pects of access control. A matrix and security levels are used to determine if subjects can
access different objects. The subject’s clearance is compared to the object’s classification;
Monday, May 19, 2003 3:40:01 PM

213
if the clearance is higher or equal to the object’s classification, the subject can access the
object without violating the security policy.
The model uses subjects, objects, access operations (read, write, and read/write), and
security levels. Subjects and objects can reside at different security levels and have rela-
tionships and rules dictating the acceptable activities between them. If properly imple-
mented and enforced, this model has been mathematically proven to prevent data from
a higher security level from flowing to a lower security level. It is an information flow se-
curity model also, which means that information does not flow in an insecure manner.
The Bell-LaPadula model is a subject-to-object model. An example would be how
you could take an element from a specific database and write it into another database.
The Bell-LaPadula has a focus of ensuring that subjects are properly authenticated, by
having the necessary security clearance and need-to-know, before accessing an object.
There are three main rules used and enforced in the Bell-LaPadula model: the simple
security rule, the *-property rule, and the strong star property rule. The simple security
rule states that a subject at a given security level cannot read data that resides at a higher
security level. The *-property rule states that a subject in a given security level cannot
write information to a lower security level. The simple security rule is referred to as the
“no read up” rule, and the *-property rule is referred to the as the “no write down” rule,
as shown in Figure 5-14. The third rule, the strong star property rule, states that a subject
that has read and write capabilities can only perform those functions at the same secu-
rity level, nothing higher and nothing lower. The simple security and *-property rules,
and the strong star property rule, indicate what states the system can go into.
The state of a system changes as different operations take place. The Bell-LaPadula
model defines a secure state, meaning a secure computing environment and the allowed
actions, which are security-preserving operations. This means that the model provides a
secure state and only permits operations that will keep the system within a secure state
and not let it enter into an insecure state. So if 100 people access 2,000 objects in a day
using this one system, this system is put through a lot of work and several complex activ-
ities have to take place. However, at the end of the day, the system is just as secure as it
Bell La-Padula Model
Top Secret
Secret Upper Bound

cannot “Read Up” Lattice
cannot “Write Down”
Confidential Lower Bound
Public
= Subject
Figure 5-14 In the Bell-LaPadula model, each subject has a lattice of rights.
Monday, May 19, 2003 3:40:02 PM

214
was in the beginning of the day. This is the definition of the Basic Security Theorem used
in computer science.
NOTE The definition of the Basic Security Theorem is that if a system

initializes in a secure state and all state transitions are secure, then every
subsequent state will be secure no matter what inputs occur.
An important thing to note is that the Bell-LaPadula model was developed to make
sure secrets stay secret; thus, it provides and addresses confidentiality only. This model
does not address integrity of the data the system maintains—only who can and cannot
access the data.
So What Does This Mean and Why?

Subjects and objects are assigned labels. The subject’s label is a clearance label (top se-
cret, secret, confidential, and so on) and the object’s label is a classification label (top secret,
secret, confidential, and so on). When a subject attempts to access an object, the system
compares the subject’s clearance label and the object’s classification label and looks at a
matrix to see if this is a legal and secure activity. So let’s say it is a perfectly fine activity,
and the subject is given access to the object. Now if the subject’s clearance label is top se-
cret and the object’s classification label is secret, the subject cannot write to this object,
because of the *-property rule. This makes sure that subjects cannot accidentally or in-
tentionally share confidential information by writing to an object at a lower security
level. Let’s say a busy and clumsy general in the army opens up a briefing letter that will
go to all clerks at all bases all around the world. He attempts to write that the United
States is attacking Cuba. The Bell-LaPadula model will come into action and not permit
this general to write this information to this type of file because his clearance is higher
than that of the memo.
Likewise, if a nosey clerk tried to read a memo that was available only to generals and
above, the Bell-LaPadula model would stop this activity also. The clerk’s clearance is
lower than that of the object, the memo, and this violates the simple security rule of the
model. It is all about keeping secrets secret.
The following lists some criticisms of the Bell-LaPadula model:
• It deals only with confidentiality and does not address integrity.

• It does not address management of access control, because there is no mechanism
to modify access rights.
• The model does not prevent or address covert channels.
• The model does not address file sharing used in more modern systems.
Biba Model
The Biba model was developed after the Bell-LaPadula model. It uses a state machine
model and is very similar to the Bell-LaPadula model. Biba addresses the integrity of
data being threatened when subjects at lower integrity levels are able to write to
Monday, May 19, 2003 3:40:02 PM

215
objects at higher integrity levels and when subjects can read data at lower levels. If im-
plemented and enforced properly, the Biba model prevents data from any integrity
level from flowing to a higher integrity level. Biba has two main rules to provide this
type of protection. The first rule, referred to as “no write up,” states that a subject can-
not write data to an object at a higher integrity level. The second rule, referred to as “no
read down,” states that a subject cannot read data from a lower integrity level. This sec-
ond rule might sound a little goofy, but it is protecting the subject and data at a higher
integrity level from being corrupted by data in a lower integrity level. An analogy
would be if you were writing an article for the New York Times about the security trends
over the last year, the amount of money businesses lost, and the cost/benefit ratio of
implementing firewalls, intrusion detection systems, and vulnerability scanners. You
do not want to get your data and numbers from any old Web site without knowing
how those figures were calculated and the sources of the information. Your article
(data at a higher integrity level) can be compromised if mixed with unfounded infor-
mation from a bad source (data at a lower integrity level).
When first learning about the Bell-LaPadula and Biba models, they seem very similar,
and the reasons for their differences may bring about some confusion. The Bell-
LaPadula model was written for the U.S. government, and the government is very para-
noid about the leakage of their secret information. In their model, a user cannot write to
a lower level because that user might let out some secrets. Similarly, a user at a lower
level cannot read anything at a higher level because that user might learn some secrets.
However, not everyone is so worried about confidentiality and has such big, important
secrets to protect. The commercial industry is more concerned about the integrity of its
data. An accounting firm is more worried about keeping their numbers straight and
making sure decimal points are not dropped or extra zeros are not added in a process
carried out by an application. The accounting firm is more concerned about the integrity
of this data and is usually under little threat of someone trying to steal these numbers, so
they would employ the Biba model. Of course, the accounting firm does not look for the
name Biba on the back of a product or make sure it is in the design of their application.
It is something that was decided upon and implemented when the application was be-
ing developed. The security ratings are what consumers use to determine if a system is
right for them. So even if the accountants are using a system using the Biba model, they
would not know (and we’re not going to tell them).
Bell-LaPadula versus Biba

The Bell-LaPadula model is used to provide confidentiality. The Biba model is
used to provide integrity. The Bell-LaPadula and Biba models are informational
flow models because they are most concerned about data flowing from one level
to another. Bell-LaPadula uses security levels and Biba uses integrity levels.
Monday, May 19, 2003 3:40:02 PM

216
Confusion of the Different Rules

It is important for CISSP test takers to know the rules of Biba and Bell-LaPadula.
Their rules sound very similar, simple and *-rules—one writing one way and one
reading another way. A tip to remember them is that if the word “simple” is used,
the rule is talking about reading. If the rule uses * or “star”, it is talking about writ-
ing. So now you just need to remember reading and writing in which direction for
the different models.
Clark-Wilson Model
The Clark-Wilson model was developed after Biba and takes some different approaches
to protecting the integrity of information by focusing on preventing authorized users
from making unauthorized modification of data, or commit fraud and errors within
commercial applications.
As stated earlier, military institutions are usually more concerned about confidential-
ity, and the commercial sector is usually more concerned with the integrity of the data
they process. In the Clark-Wilson model, users cannot access and manipulate objects di-
rectly, but must access the object through a program. This provides another layer of pro-
tection between the subject and the object and further restricts the type of actions that
can take place on that object, thus protecting the integrity of the object.
Let’s say Emily is a user of an application that has been built using the Clark-Wilson
model. She cannot access files directly, but must open and manipulate files through the
program built upon the Clark-Wilson model. The programs have their own set of restric-
tions dictating what actions the users can and cannot perform on objects. This stream-
lines the way objects are protected and reduces the methods that could cause the data to
be corrupted or changed in an undesirable manner.
NOTE Ensuring that subjects can only access objects through the use
of an application is referred to as access triple. A subject has to go through
an application to access an object: subject – application – object.
This model also enforces separation of duties, which divides an operation into differ-
ent parts and requires different users or rules to perform each part. This ensures that a
critical task cannot be carried out by one entity. Auditing is also required in this model
to track the information coming in from the outside of the system.
So the Clark-Wilson model prevents authorized users from making modifications by
requiring them to go through programs to modify objects. It also prevents authorized
users from making improper modifications by enforcing separation of duties, and
maintains an audit log for external transactions.
Monday, May 19, 2003 3:40:03 PM

217
Goals of Integrity
There are three main goals of integrity:
• Prevent unauthorized users from making modifications

• Prevent authorized users from making improper modifications
• Maintain internal and external consistency
Clark-Wilson addresses each of these goals in its model. Biba only addresses the
first goal.
Information Flow Model

Now, which way is the information flowing in this system? Answer: Not to you.
The Bell-LaPadula model is concerned about information that can flow from a high
security level to a low security level. The Biba model is concerned about information
that can flow from a high integrity level to a low integrity level. Both of these were built
upon the information flow model. Information flow models can deal with any kind of in-
formation flow, not only the direction of the flow. This type of model looks at insecure
informational flow that can happen at the same level and between objects along with
the flow between different levels. When the information flow model is used, a system is
secure if there is no illegal information flow permitted.
Basically, information can flow from one security level to another or from one object
to another in the same security level until a restricted operation is attempted. In most sys-
tems, once a restricted operation is attempted, the system looks at an access control matrix
to see if this action has been specifically permitted for this specific subject or object.
Noninterference Model
Stop touching me. Stop touching me. You are interfering with me!
Multilevel security properties can be expressed in other ways, one being
noninterference. This concept is implemented to ensure that any actions that take place at
a higher security level do not affect, or interfere, with actions that take place at a lower
level. This type of model does not concern itself with the flow of data, but with what a
subject knows about the state of the system. So if an entity at a higher security level per-
forms an action, it cannot change the state for the entity at the lower level.
If a lower-level entity was aware of a certain activity that took place by an entity at a
higher level and the state of system changed for this lower-level entity, the entity might
be able to deduce too much information about the activities of the higher state, which
in turn is a way of leaking information.
Users at a lower security level should not be aware of the commands executed by users
at a higher level and should not be affected by those commands in any way.
Monday, May 19, 2003 3:40:03 PM

218
Brewer and Nash Model
The Brewer and Nash model, also called the Chinese Wall model, was created to provide ac-
cess controls that can change dynamically depending upon a user’s previous actions. The
main goal of the model is to protect against users accessing data that could be seen as con-
flicts of interest. For example, if a large marketing company provided marketing promo-
tions and materials for several banks, one individual working on a project for Bank A
should not be looking at information the marketing company has for Bank B. So this mar-
keting company could implement a product that tracked the different marketing represen-
tatives’ access activities and disallow certain access requests that would present a conflict of
interest. In Figure 5-15, we see that when a representative accesses Bank A’s information
the system automatically makes Bank B’s information off limits. If the representative ac-
cessed Bank B’s data, Bank A’s information would be off limits. These access controls
change dynamically depending upon the user’s activities and previous access requests.
Graham-Denning and Harrison-Ruzzo-Ullman Models

Remember that these are all models, thus they are not very specific in nature. Each indi-
vidual vendor must decide upon how it is going to actually meet the rules outlined in
the chosen model. Bell-LaPadula and Biba don’t define how the security and integrity
ratings are defined and modified, nor do they provide a way to delegate or transfer ac-
cess rights. The Graham-Denning model addresses these issues and defines a set of basic
rights in terms of commands that a specific subject can execute on an object. The Harrison-
Ruzzo-Ullman model outlines how access rights can be changed and how subjects and
objects should be created and deleted.
These newer models provide more granularity and direction for vendors on how to
actually meet the goals outlined in the earlier models.
Figure 5-15 The Chinese Wall model provides dynamic access controls.
Monday, May 19, 2003 3:40:03 PM

219
Security Models
• Bell-LaPadula model A model that protects the confidentiality of the
information within a system.
• Simple security rule A subject cannot read data at a higher security
level (no read up).
• *-property rule A subject cannot write data to an object at a lower
security level (no write down).
• Strong star property rule A subject that has read and write
capabilities can only perform those functions at the same security level.
• Biba model A model that protects the integrity of the information
within a system.
• Simple integrity axiom A subject cannot read data at a lower
integrity level (no read down).
• *-integrity axiom A subject cannot modify an object in a higher
integrity level (no write up).
• Clark-Wilson model An integrity model implemented to protect
the integrity of data and to ensure that properly formatted transactions
take place.
• Subjects can only access objects through authorized programs
(access triple).
• Separation of duties is enforced.
• Auditing is required.
• Information flow model Information is restricted in its flow to only go
to and from entities in a way that does not negate the security policy.
• Noninterference model Commands and activities performed at one
security level should not be seen or affect subjects or objects at a different
security level.
• Brewer and Nash model A model that allows for dynamically changing
access controls that protect against conflicts of interest
• Graham-Denning model A model that creates rights for subjects, which
correlate to the operations that can be execute on objects.
• Harrison-Ruzzo-Ullman model A model that allows for access rights
to be changed and specifies how subjects and objects should be created
and deleted.
Monday, May 19, 2003 3:40:03 PM

220
References
Access Control Models: www.cccure.org/Documents/HISM/087-089.html
Models of OS Protection: all.net/books/ip/Chap3-3.html
Computer Security Models: infoeng.ee.ic.ac.uk/~malikz/surprise2001/
spc99e/article1
Database Security: www.wi-inf.uni-essen.de/~ifs/summerschool
Security Modes of Operation

A system can operate at different types of modes depending on the sensitivity of the data
being processed, the clearance level of the users, and what those users are authorized to
do. The mode of operation describes the security conditions under which the system ac-
tually functions. There are four modes of operations a system can function under and
the following sections describe each one.
Dedicated Security Mode

A system is operating in a dedicated security mode if all users have the clearance and for-
mal need-to-know to all data processed within the system. All users have been given
formal access approval for all information on the system and have signed nondisclosure
agreements pertaining to this information. The system can handle a single classification
level of information.
Many military systems have been designed to handle only one level of security, which
works in dedicated security mode. This requires everyone who uses the system to have the
highest level of clearance required by any and all data on the system. If a system held top-
secret data, only users with this clearance could use the system. Other military systems
work with multiple security levels, which is done by compartmentalizing the data. These
types of systems can support users with high and low clearances simultaneously.
System-High Security Mode

A system is operating in system-high security mode when all users have a security clear-
ance or authorization to access the information but not necessarily a need-to-know for
all the information processed on the system. So the difference between the dedicated se-
curity mode and the system-high security mode is that in the dedicated security mode,
all users have a need-to-know pertaining to all data on the system; in system-high secu-
rity mode, all users have a need-to-know pertaining to some of the data.
This mode also requires all users to have the highest level of clearance required by
any and all data on the system. However, just because a user has the necessary security
level to access an object, the user could be restricted because they do not have a need-
to-know pertaining to that specific object.
Compartmented Security Mode

A system is operating in compartmented security mode when all users have the clearance
to access all the information processed by the system, but might not have the need-to-
know and formal access approval. In compartmented security mode, users are
Monday, May 19, 2003 3:40:04 PM

221
restricted from being able to access some information because they do not need to ac-
cess it to perform the functions of their jobs and they have not been given formal ap-
proval to access this data. In this mode, users can access a segment, or compartment, of
data only.
The objective is to ensure that the minimum possible number of people learn of in-
formation at each level. Compartments are categories of data with limited number of
subjects cleared to access data at each level. Compartmented mode workstations (CMWs)
enable users to process multiple compartments of data at the same time, if they have the
necessary clearance.
Multilevel Security Mode

A system is operating in multilevel security mode when it permits two or more classification
levels of information to be processed at the same time when all the users do not have the
clearance or formal approval to access all the information being processed by the system.
The Bell-LaPadula model is an example of a multilevel security model because it han-
dles multiple information classifications at a number of different security levels within
one system.
References
Data Protection Measures: www.tpub.com/ans/51.htm
Personal Computer Security: www.cs.nps.navy.mil/curricula/tracks/security/
notes/chap02_17.html
Physical Model of Operations: chacs.nrl.navy.mil/publications/CHACS/1997/
jifi_web/node24.html
Defense Security Service, NISPOM Chapter 8: www.dss.mil/isec/ch8nispom/
toc.htm
Trust and Assurance

I trust that you will act properly, thus I have a high level of assurance in you.
We discussed the TCB concept in the section “Trusted Computing Base” and ex-
plained that no system is really secure because with enough resources almost any system
can be compromised in one way or another; however, systems can provide levels of
trust. The trust level tells the customer how much he can expect out of this system, what
level of security it will provide, and the assurance that the system will act in a correct and
predictable manner in each and every computing situation.
The TCB is made up of all the protection mechanisms within a system (software,
hardware, firmware). All of these mechanisms need to work in an orchestrated way to
enforce all the requirements of a security policy. When evaluated, these mechanisms are
tested, their designs are inspected, and the supporting documentation is reviewed and
evaluated. How the system is developed, maintained, and even delivered to the cus-
tomer are all under review when the trust for a system is being gauged. All of these differ-
ent evaluation components are put through an evaluation process to assign the correct
level of trust and assurance. Customers then use this assignment, or rating, to determine
which system best fits their security needs.
Monday, May 19, 2003 3:40:04 PM

222
Assurance and trust are similar in nature, but slightly different when we are looking at
rating computer systems. A trusted system means that all protection mechanisms work
together to process sensitive data for many types of uses and still keeps the same secure
computing environment. Assurance looks at the same issues but with more depth and
detail. Systems that provide higher levels of assurance means that their designs were
thoroughly inspected, the development stages were reviewed, the technical specifica-
tions and test plans were evaluated, and the system was tested extensively. You can buy a
car and you can trust it, but you have a much deeper sense of assurance of that trust if
you know how it was built, what it was built with, who built it, what tests it was put
through, and how it performed in many different situations.
In the Trusted Computer Security Evaluation Criteria, commonly known as the Or-
ange Book, which we will address shortly, the lower security level ratings look at a sys-
tem’s performance and testing results to produce a security rating, but the higher
security level ratings look more at the system design, specifications, development proce-
dures, supporting documentation, and the testing results. The protection mechanisms
in the higher security level systems may not necessarily be much different from those in
the lower security level systems, but the way they were designed and built is under much
more scrutiny. With this extra scrutiny comes higher levels of assurance of the trust that
can be put into a system.
Systems Evaluation Methods

A security evaluation examines the security-relevant parts of a system, meaning the TCB,
access control mechanisms, reference monitor, kernel, and protection mechanisms. The
relationship and interaction between these components are also evaluated. There are
different methods of evaluating and assigning assurance and trust levels to systems. The
reason that there is more than one type of security evaluation process is that the meth-
ods and ideologies have evolved over time and because various parts of the world look
at computer security differently and rate some aspects of security differently than others.
Each method will be explained and then at the end of the section they will be compared
to each other to show the differences and strengths, and look at where security evalua-
tion methods are heading.
The Orange Book

The U.S. Department of Defense developed the Trusted Computer System Evaluation
Criteria (TCSEC), which is used to evaluate operating systems, applications, and differ-
ent products. This evaluation criteria is published in a book with an orange cover, which
is called appropriately the Orange Book. (We like to keep things simple in security!)
Customers use the security rating that the criteria presents so they have a metric to use
when comparing different systems. It also provides direction for manufactures so they
know what specifications to build to, and provides a one-stop evaluation process so cus-
tomers do not need to have individual components within the systems evaluated.
The Orange Book evaluates products to assess if they contain the security properties
they claim and evaluate if the product is appropriate for a specific application or function.
Monday, May 19, 2003 3:40:04 PM

223
The Orange Book looks at the functionality, effectiveness, and assurance of a system dur-
ing its evaluation, and it uses classes that were devised to address typical patterns of secu-
rity requirements.
TCSEC provides a graded classification of systems that is divided into hierarchical di-
visions of security levels:
A Verified protection
B Mandatory protection
C Discretionary protection
D Minimal security
The classification A represents the highest level of security and D represents the low-
est level of security.
Each division can have one or more numbered classes and each has a corresponding
set of requirements that must be met for a system to achieve that particular rating. The
classes with higher numbers indicate a greater degree of trust and assurance. So B2
would offer more trust than B1, and C2 would offer more trust than C1.
The criteria includes four main topics: security policy, accountability, assurance, and
documentation, but these actually break down into seven different areas:
• Security policy The policy must be explicit and well defined and enforced by
the mechanisms within the system.
• Identification Individual subjects must be uniquely identified.
• Labels Access control labels must be associated properly with objects.
• Documentation This includes the test, design, specification documents, user
guides, and manuals.
• Accountability Audit data must be captured and protected to enforce
accountability.
• Life cycle assurance Software, hardware, and firmware must be able to be
tested individually to ensure that each enforces the security policy in an effective
manner throughout their lifetimes.
• Continuous protection The security mechanisms and the system as a whole
must perform predictably and acceptably in different situations continuously.
These categories are evaluated independently, but the rating that is assigned at the
end does not specify these different objectives individually. The rating is a sum total of
these items.
Each division and class incorporates the requirements of the ones below it. This
means that C2 must meet its criteria requirements and all of C1 requirements, and B3
has its requirements to fulfill along with those of C1, C2, B1, and B2. Each division or
class ups the ante on security requirements and is expected to fulfill the requirements of
all the classes and divisions below it.
Monday, May 19, 2003 3:40:04 PM

224
When a vendor submits a product for evaluation, the product is submitted to the Na-
tional Computer Security Center (NCSC). The process of evaluation is called the Trusted
Products Evaluation Program (TPEP). Successfully evaluated products are placed on the
Evaluated Product List (EPL) with their corresponding rating. When consumers are in-
terested in certain products and systems, they can check the EPLs to find out the security
level that are assigned to these products.
Division D: Minimal Protection

There is only one class in this division. It is reserved for systems that have been evaluated
but fail to meet the criteria and requirements of the higher divisions.
Division C: Discretionary Protection

The C rating category has two individual assurance ratings within it; these ratings are de-
scribed below. The higher the number of the assurance rating, the more protection that
is provided.
C1: Discretionary Security Protection

Discretionary access control is based on individuals and/or groups. It requires a separa-
tion of users and information, and identification and authentication of individual enti-
ties. Some type of access control is necessary so users can ensure that their data will not
be accessed and corrupted by others. The system architecture must supply a protected
execution domain so privileged system processes are not adversely affected by lower-
privileged processes. There must be specific ways of validating the system’s operational
integrity. The documentation requirements include design documentation, which shows
the way the system was built to include protection mechanisms, test documentation
(test plan and results), a facility manual so companies know how to install and config-
ure the system’s correctly, and user manuals.
The environment that would require this rating would be where users are processing
information at the same sensitivity level; thus, strict access control and auditing mea-
sures are not required. It would be a trusted environment with low security concerns.
C2: Controlled Access Protection

Users need to be identified individually to provide more precise access control and au-
diting functionality. Logical access control mechanisms are used to enforce authentica-
tion and the uniqueness of each individual’s identification. Security-relevant events are
audited and these records must be protected from unauthorized modification. The ar-
chitecture must provide resource, or object, isolation so proper protection can be ap-
plied to the resource and that actions taken upon it can be properly audited. The object
reuse concept must also be invoked, meaning that any medium holding data must not
contain any remnants of information after it is released for another subject to use. If a
subject uses a segment of memory, that memory space must not hold any information
after the subject is done using it. The same is true for storage media, objects being popu-
lated, temporary files being created—all data must be efficiently erased once the subject
is done with that medium.
Monday, May 19, 2003 3:40:04 PM

225
This class requires a more granular method of providing access control. The system
must enforce strict logon procedures and provide decision-making capabilities when
subjects request access to objects. A C2 system cannot guarantee that it will not be com-
promised, but it supplies a level of protection that would make compromising attempts
harder to accomplish.
The environment that would require systems with a C2 rating would be one that con-
tains users that are trusted, but a certain level of accountability is required. C2, overall, is
regarded to be the most reasonable class for commercial applications, but the level of
protection is still relatively weak.
Division B: Mandatory Protection

Mandatory access control is enforced by the use of security labels. The architecture is
based on the Bell-LaPadula security model and evidence of reference monitor enforce-
ment must be available.
B1: Labeled Security

Each data object must contain a classification label and each subject must have a clear-
ance label. When a subject attempts to access an object, the system must compare the
subject and object’s security labels to ensure the requested actions are acceptable. Data
leaving the system must also contain an accurate security label. The security policy is
based on an informal statement and the design specifications are reviewed and verified.
It is intended for environments that require systems to handle classified data.
NOTE Security labels are not required until security rating B; thus, C2 does
not require security labels but B1 does.
B2: Structured Protection

The security policy is clearly defined and documented, and the system design and im-
plementation are subjected to more thorough review and testing procedures. This class
requires more stringent authentication mechanisms and well-defined interfaces among
layers. Subjects and devices require labels, and the system must not allow covert chan-
nels. A trusted path for logon and authentication processes must be in place, which
means there are no trapdoors. A trusted path means that the subject is communicating
directly with the application or operating system. There is no way to circumvent or com-
promise this communication channel. There is a separation of operator and administra-
tion functions within the system to provide more trusted and protected operational
functionality. Distinct address spaces must be provided to isolate processes, and a covert
channel analysis is conducted. This class adds assurance by adding requirements to the
design of the system.
The environment that would require B2 systems could process sensitive data that re-
quires a higher degree of security. This environment would require systems that are rela-
tively resistant to penetration and compromise.
Monday, May 19, 2003 3:40:04 PM

226
(A trusted path means that the user can be sure that he is talking to a genuine copy of
the operating system.)
B3: Security Domains

In this class, more granularity is provided in each protection mechanism, and the
programming code that is not necessary to support the security policy is excluded. The de-
sign and implementation should not provide too much complexity because as the com-
plexity of a system increases, the ability of the individuals who need to test, maintain, and
configure it reduces; thus, the overall security can be threatened. The reference monitor
components must be small enough to test properly and be tamperproof. The security ad-
ministrator role is clearly defined, and the system must be able to recover from failures
without its security level being compromised. When the system starts up and loads its op-
erating system and components, it must be done in an initial secure state to ensure that
any weakness of the system cannot be taken advantage of in this slice of time.
An environment that requires B3 systems is a highly secured environment that
processes very sensitive information. It requires systems that are highly resistant to
penetration.
Division A: Verified Protection

Formal methods are used to ensure all subjects and objects are controlled with the nec-
essary discretionary and mandatory access controls. The design, development, imple-
mentation, and documentation are looked at in a formal and detailed way. The security
mechanisms between B3 and A1 are not very different, but the way that the system
was designed and developed is evaluated in a much more structured and stringent
procedure.
A1: Verified Design

The architecture and protection features are not much different from systems that
achieve a B3 rating, but the assurance of an A1 system is higher than a B3 system because
the formality in the way the system was designed, the way the specifications were devel-
oped, and the level of detail in the verification techniques. Formal techniques are used
to prove the equivalence between the TCB specifications and the security policy model.
More stringent change configuration is put in place with the development of an A1 sys-
tem, and the overall design can be verified. In many cases, even the way that the system
is delivered to the customer is under scrutiny to ensure that there is no way of compro-
mising the system before it reaches its destination.
An environment that would require A1 systems is the most secure of secured environ-
ments. This environment deals with top-secret information and cannot adequately trust
anyone using the systems without strict authentication, restrictions, and auditing.
NOTE TCSEC addresses confidentiality, but not integrity. Functionality of

the security mechanisms and the assurance of those mechanisms are not
evaluated separately, but combined and rated as a whole.
Monday, May 19, 2003 3:40:05 PM

227
References
Trusted Computer System Evaluation Criteria: www.boran.com/security/
tcsec.html
Trusted Computer Systems: williamstallings.com/Extras/Security-Notes/
lectures/trusted.html
Rainbow Series
Why are there so many colors in the rainbow? Answer: Because there are so many security topics
in the computing world that needed names.
The Orange Book mainly addresses government and military requirements and ex-
pectations from their computer systems. Many people within the security field have
pointed out several deficiencies of the Orange Book, particularly when it is being applied
to systems that are to be used in commercial areas instead of government organizations.
The following summarizes a majority of the troubling issues security practitioners have
expressed about the use of the Orange Book:
• The Orange Book looks specifically at the operating system and not other issues
like networking, databases, and so on.
• The Orange Book focuses mainly on one attribute of security, confidentiality,
and not at integrity, availability, and authenticity.
• The Orange Book works with government classifications and not the protection
classifications that commercial industries use.
• The Orange Book has a relatively small number of ratings, which means many
different aspects of security are not evaluated and rated independently.
The Orange Book places great emphasis on controlling which users can access a system
and virtually ignores controlling what those users do with the information once they are
authorized. Authorized users can, and usually do, cause more damage to data than out-
side attackers. Commercial organizations have expressed more concern about the integ-
rity of their data while the military organizations stress that their top concern is
confidentiality. Because of these different goals, the Orange Book is a better evaluation
tool for government and military systems.
Because the Orange Book focuses on the operating system, many other areas of secu-
rity were left out. The Orange Book provides a broad framework for building and evalu-
ating trusted systems, but it leaves many questions about topics other than just an
operating system unanswered. So more books were written to extend the coverage of the
Orange Book into other areas of security. These books provide detailed information and
interpretations of certain Orange Book requirements and describe the evaluation pro-
cesses. These books are collectively called the Rainbow Series because each book has
a different color cover.
For an explanation of each book and its usage, please refer to the following references.
Monday, May 19, 2003 3:40:05 PM

228
References
Rainbow Series Library: www.radium.ncsc.mil/tpep/library/rainbow
Rainbow Series: csrc.ncsl.nist.gov/secpubs/rainbow
Rainbow Series and Related Documents: www.fas.org/irp/nsa/rainbow.htm
Red Book
The Orange Book addresses single-system security, but networks are a combination
of systems and the network needs to be secure without having to fully trust each and ev-
ery system connected to it. The Trusted Network Interpretation (TNI), also called the Red
Book because of the color of its cover, addresses security evaluation topics for networks
and network components. It addresses isolated local area networks and wide area
internetwork systems.
Like the Orange Book, the Red Book does not supply specific details about how to
implement security mechanisms; instead, it provides a framework for securing different
types of networks. A network has a security policy, architecture, and design, as does an
operating system. Subjects accessing objects on the network need to be controlled, mon-
itored, and audited. In a network, the subject could be a workstation and an object
could be a network service on a server.
The Red Book rates confidentiality and integrity of data and operations that happen
within a network and the network products. Data and labels need to be protected from
unauthorized modification, and the integrity of information as it is transferred needs to
be ensured. The source and destination mechanisms used for messages are evaluated
and tested to ensure that modification is not allowed.
Encryption and protocols are components that provide a lot of the security within
a network, and the Red Book measures their functionality, strength, and assurance.
The following is a brief overview of the security items addressed in the Red Book:
• Communication integrity:
• Authentication Protects against masquerading and playback attacks.
Mechanisms include digital signatures, encryption, timestamp, and passwords.
• Message integrity Protects protocol header, routing information, and
the packet payload from being modified. Mechanisms include message
authentication and encryption.
• Nonrepudiation Ensures that a sender cannot deny sending a message.
Mechanisms include encryption, digital signatures, and notary.
• Denial-of-service prevention:
• Continuity of operations Ensures that network is available even if
attacked. Mechanisms include fault tolerant and redundant systems and
the capability to reconfigure network parameters in case of an emergency.
• Network management Monitors network performance and identifies
attacks and failures. Mechanisms include components that enable network
administrators to monitor and restrict resource access.
Monday, May 19, 2003 3:40:05 PM

229
• Compromise protection:
• Data confidentiality Protects data from being accessed in an unauthorized
method during transmission. Mechanisms include access controls, encryption,
and physical protection of cables.
• Traffic flow confidentiality Ensures that unauthorized entities are not
aware of routing information or frequency of communication via traffic
analysis. Mechanisms include padding messages, sending noise, or false
messages.
• Selective routing Routes messages in a way to avoid specific threats.
Mechanisms include network configuration and routing tables.
Assurance is derived from a theory of how things should work and then compared to
how they actually perform. Assurance is also derived by testing configurations in many
different scenarios, evaluating engineering practices, and validating and verifying secu-
rity claims. The Red Book ratings available are the following:
• None
• C1 Minimum
• C2 Fair
• B2 Good
TCSEC was introduced in 1985 and retired in December 2000. It was the first me-
thodical and logical set of standards developed to secure computer systems. It was
greatly influential to several countries who based their evaluation standards on the
TCSEC guidelines. TCSEC was finally replaced with the Common Criteria.
Information Technology
Security Evaluation Criteria
The Information Technology Security Evaluation Criteria (ITSEC) was the first attempt at
establishing a single standard for evaluating security attributes of computer systems by
many European countries. ITSEC is only used in Europe. The United States looked to the
Orange Book and Rainbow Series, and Europe employed the ITSEC to evaluate and rate
computer systems. (Actually, today everyone is migrating to the Common Criteria, ex-
plained in the next section.)
There are two main attributes of a system when it is evaluated under ITSEC: functional-
ity and assurance. When the functionality of a system is being evaluated, the services that
are provided to the users (access control mechanisms, auditing, authentication, and so
on) are examined and measured. System functionality can be very diverse in nature be-
cause systems are developed differently just to provide different functionality to users.
Nonetheless, when functionality is evaluated, it is tested to see if the system delivers what
it says it delivers. Assurance, on the other hand, is more abstract and harder to test. Assur-
ance is the degree of confidence in a security component, and its effectiveness and capa-
bility to perform consistently. Assurance is generally tested by examining development
practices, documentation, configuration management, and testing mechanisms.
Monday, May 19, 2003 3:40:05 PM

230
It is possible for two systems that provide the same functionality to have very differ-
ent assurance levels. This is because of the underlying mechanisms providing the func-
tionality, and the way it was developed, engineered, and implemented. ITSEC actually
separates these two attributes and rates them separately, whereas TCSEC clumps them
together and assigns them one rating (D through A1).
When we look back at our example of two systems that provide the same functional-
ity but have very different assurance levels, using the TCSEC approach will make this in-
dividual factor hard to distinguish. Under the ITSEC approach, the functionality is rated
separately from the assurance. In the ITSEC criteria, classes F1 to F10 rate the functional-
ity of the system, whereas E0 to E6 rate the assurance of a system.
So the fundamental difference between ITSEC and TCSEC is that TCSEC bundles
functionality and assurance, whereas ITSEC evaluates these two attributes separately.
The following is a general mapping of the two evaluation schemes to show you their
relationship to each other:
ITSEC TCSEC
E0 = D
F1 + E1 = C1
F2 + E2 = C2
F3 + E3 = B1
F4 + E4 = B2
F5 + E5 = B3
F5 + E6 = A1
F6 = Systems the provide high integrity
F7 = Systems that provide high availability
F8 = Systems that provide data integrity during communication
F9 = Systems that provide high confidentiality (like cryptographic devices)
F10 = Networks with high demands on confidentiality and integrity
As you can see, a majority of the ITSEC ratings can be mapped to the Orange Book rat-
ings, but then ITSEC took a step farther and added F6 through F10 for specific needs
consumers might have that the Orange Book does not address.
ITSEC is a criteria for operating systems and other products and refers to them as the
target of evaluation (TOE). So if you are reading literature discussing the ITSEC rating of
a product and it states that the TOE has a rating of F1 and E5, you know that the TOE is
the product that was evaluated and that it has a low functionality rating and a high as-
surance rating.
References
Criteria and Methods of Evaluations of Information Systems: www.cordis.lu/
infosec/src/crit.htm
ITSEC: www.iwar.org.uk/comsec/resources/standards/itsec.htm
Monday, May 19, 2003 3:40:05 PM

231
Common Criteria
“The TCSEC is too hard, the ITSEC is too soft, but the Common Criteria is just right,” said the
baby bear.
The Orange and Red Books provided evaluation schemes that were too rigid. ITSEC
attempted to provide a more flexible approach by separating the functionality and as-
surance attributes and considering the evaluation of entire systems. However, this flexi-
bility added complexity because evaluators could mix and match functionality and
assurance ratings, which ended up in too many classifications to keep straight. Because
we are a species that continues to try to get it right, the next attempt for an effective and
usable evaluation criteria was the Common Criteria.
In 1990, the International Organization for Standardization (ISO) identified the need
of international standard evaluation criteria to be used globally. The Common Criteria
project started in 1993 when several organizations came together to combine and align
existing and emerging evaluation criteria (TCSEC, ITSEC, Canadian Trusted Computer
Product Evaluation Criteria [CTCPEC], and the Federal Criteria). It was developed
through a collaboration among national security standards organizations within the
United States, Canada, France, Germany, the United Kingdom, and the Netherlands.
The benefit of having a worldwide recognized and accepted criteria helps consumers
by reducing the complexity of the ratings and eliminating the need to understand the
definition and meaning of different ratings within various evaluation schemes. This also
helps manufacturers because now they can build to one specific set of requirements if
they want to sell their products internationally, instead of having to meet several differ-
ent ratings with varying rules and requirements.
The Orange Book evaluated all systems by how they compared to the Bell-LaPadula
model. The Common Criteria provides more flexibility by evaluating a product against a
protection profile, which is structured to address specific security problems. So while the
Orange Book said, “Everyone march this direction in this form using this path,” the Com-
mon Criteria says, “Okay, what are the threats we are facing today and what are the best
ways of battling them?”
An evaluation is carried out on a product and is assigned an evaluation assurance level
(EAL). The thoroughness and stringent testing increases in detailed-oriented tasks as the
levels increase. The Common Criteria has seven assurance levels. The ranges go from
EAL1, where functionality testing takes place, to EAL7, where thorough testing is per-
formed and the system design is verified. The different EAL packages are listed here:
• EAL 1 Functionally tested

• EAL 2 Structurally tested
• EAL 3 Methodically tested and checked
• EAL 4 Methodically designed, tested, and reviewed
• EAL 5 Semiformally designed and tested
• EAL 6 Semiformally verified design and tested
• EAL 7 Formally verified design and tested
Monday, May 19, 2003 3:40:05 PM

232
The Common Criteria uses protection profiles to evaluate products. The protection
profile contains the set of security requirements, their meaning and reasoning, and the
corresponding EAL rating that the intended product will require. The profile describes
the environmental assumptions, the objectives, and functional and assurance level ex-
pectations. Each relevant threat is listed along with how it is to be controlled by specific
objectives. It also justifies the assurance level and requirements for the strength of each
protection mechanism.
The protection profile provides a means for a consumer, or others, to identify specific
security needs; this is the security problem that is to be conquered. If someone identifies
a security need that is not currently being addressed by any current product, this person
can write a profile of the product that would be a solution for this real-world problem.
The profile goes on to provide the necessary goals and protection mechanisms to
achieve the necessary level of security and a list of the things that can go wrong during
this type of system development. This list is used by the engineers who develop the sys-
tem and the same list is used by the evaluators to make sure the engineers dotted every i
and crossed every t.
The Common Criteria was developed to stick to evaluation classes but also to retain
some degree of flexibility. Protection profiles were developed to describe the functional-
ity, assurance, description, and rationale of its findings.
Like other evaluation criteria before it, Common Criteria works to answer two basic
and general questions about products being evaluated: what does it do (functionality),
and how sure are you of that (assurance)? This system sets up a framework for consum-
ers to be able to clearly specify their security issues and problems; developers to specify
their security solution to those problems; evaluators to unequivocally determine what
the product actually accomplishes.
A protection profile contains the following five sections:
• Descriptive elements Name of profile and a description of the security
problem that is to be solved.
• Rationale Justification of the profile and a more detailed description of the
real-world problem to be solved. The environment, usage assumptions, and
threats are illustrated along with guidance on the security policies that can be
supported by products and systems that conform to this profile.
• Functional requirements A protection boundary is established, meaning the
threats or compromises that are within this boundary to be countered. The product
or system must enforce the boundary established in this section.
• Development assurance requirements The development phases from design
to implementation have specific requirements established that the product or
system must meet.
• Evaluation assurance requirements Establishes the type and intensity of the
evaluation.
The evaluation process is just one leg of determining the functionality and assurance of
a product. Once a product achieves a specific rating, it only applies to that particular ver-
sion and only to certain configurations of that product. So if a company buys a firewall
Monday, May 19, 2003 3:40:05 PM

233
product because it has a high assurance rating, it doesn’t mean the next version of that soft-
ware automatically inherits that rating. The next version will need to go though its own
evaluation review. If this same company buys the firewall product and installs it with con-
figurations not recommended, the level of security they were hoping to achieve can easily
go down the drain. So all of this rating stuff is a formalized method of a system being eval-
uated in a lab. When the product is implemented into a real environment, other factors
than just its rating need to be addressed and assessed to ensure that it is properly protecting
resources and the environment.
Different Components of the Common Criteria

The different components of the Common Criteria are shown in Figure 5-16 and de-
scribed here:
• Protection profile Description of needed security solution.

• Target of evaluation Product proposed to provide needed security solution.
• Security target Written by vendor explaining security functionality and
assurance mechanisms that meet the needed security solution. In other words,
“This is what our product does and how it does it.”
• Packages—evaluation assurance levels (EALs) Functional and assurance
requirements are bundled into packages for reuse. This component describes
what must be met to achieve specific EAL ratings.
Figure 5-16 Relationship of the different components
Monday, May 19, 2003 3:40:06 PM

234
References
CSRC, Common Criteria: csrc.nist.gov/cc
Common Criteria, The Standard for Information Security:
www.commoncriteria.org
Common Criteria overview: www.rycombe.com/cc.htm
Certification versus Accreditation

We have gone through the different types of evaluation criteria a system can be ap-
praised against to receive a specific rating. This is a very formalized process, and the eval-
uated system or product will then be placed on an EPL indicating what rating it
achieved. Consumers can check this listing and compare the different products and sys-
tems to see how they rank against each other in the property of security. However, once
a consumer buys this product and sets it up in his environment, it does not guarantee se-
curity. Security is made up of system administration, physical security, installation, and
configuration mechanisms within the environment, and other security issues. To fairly
say a system is secure, all of these items need to be taken into account. The rating is just
one piece in the puzzle of security.
Certification
How did you certify this product? Answer: It came in a very pretty box.
Certification is the comprehensive technical evaluation of the security components
and their compliance for the purpose of accreditation. A certification process can use
safeguard evaluation, risk analysis, verification, testing, and auditing techniques to as-
sess the appropriateness of a specific system, which processes a certain classification
level of information within a particular environment. For example, if Dan were the secu-
rity officer for a company that just purchased new systems to be used to process their
confidential data, he would like to know if these systems are appropriate for these tasks
and if they are going to provide the necessary level of protection. He could pay a com-
pany that specializes in these matters to perform the necessary procedures to certify the
systems. The company will perform tests on the software configurations, hardware,
firmware, design, implementation, system procedures, and the physical and communi-
cation controls. The certification will indicate the good, bad, and the ugly about the se-
curity protection level and the mechanisms that support it within these systems and
how they work within the given environment. If the outcome of this process looks good
to Dan, he will take it to his management to start the accreditation process.
Accreditation
Accreditation is the formal acceptance of the adequacy of a system’s overall security and
functionality by management. The certification information is presented to manage-
ment, or the responsible body, and it is up to the management to ask questions, review
the reports and findings, and decide upon the acceptance of the safeguards and if any
Monday, May 19, 2003 3:40:07 PM

235
corrective action needs to take place. Once satisfied with the system’s overall security as
it is presented, management makes a formal accreditation statement. By doing this,
management is stating that it understands the level of protection the system will provide
in its current environment and understands the security risks associated with installing
this system.
To summarize, certification is a technical review that assesses the security mecha-
nisms and controls and evaluates their effectiveness. Accreditation is management’s of-
ficial acceptance of the information in the certification process findings.
Because software, systems, and environments continually change and evolve, the cer-
tification and accreditation should also continue to take place. Any major addition of
software, change to the system, or modification of the environment should initiate a new
certification and accreditation cycle.
7799 Standards
The British Standard 7799 is a risk-based method for assessing, evaluating, and manag-
ing risks. It takes a holistic approach to security, instead of just focusing on the technical
issues. It is a standard and a framework for developing a security program. This can pro-
vide guidelines for organizations all around the world on how to develop and imple-
ment a security program and how to improve currently deployed programs. Companies
can be certified against these standards, which evaluate and “grade” their overall secu-
rity posture.
The British Standard is divided into ten sections:
• Security policy
• Security organization
• Assets classification and control
• Personnel security
• Physical and environmental security
• Computer and network management
• System access control
• System development and maintenance
• Business continuity planning
• Compliance
The British Standard 7799 was developed in England (who would of thought) and
became a de facto standard. A de facto standard just means that the industry basically
stated, “Hey, that’s a good idea. Let’s all do that.” A de facto standard is not dictated by a
standards board. Then a standards board did get into the act. The International Organi-
zation for Standardization (ISO), which develops standards for 145 countries, formal-
ized the approach a bit and gave it a more international name, ISO I7799, which is also
referred to as the Code of Practice for Information Security Management.
Monday, May 19, 2003 3:40:07 PM

236
Open versus Closed Systems

Computer systems can be developed to integrate easily with other systems and products
(open systems) or can be developed to be more proprietary in nature and work with
only a subset of other systems and products (closed systems). The following sections de-
scribe the difference between these approaches.
Open Systems
I want to be able to work and play well with others.
Systems that are described as open are built upon standards, protocols, and interfaces
that have published specifications, which enable third-party vendors to develop add-on
components and devices. This type of architecture provides interoperability between
products by different vendors of different operating systems, applications, and hard-
ware devices. This interoperability is provided by all the vendors involved who follow
specific standards and provide interfaces that enable each system to easily communicate
with other systems and allow add-ons to hook into the system easily.
A majority of the systems in use today are open systems. The reason that an adminis-
trator can have Windows NT 4.0, Windows 2000, Macintosh, and Unix computers on
the same network communicating easily is because these platforms are open. If a soft-
ware vendor creates a closed system, they are restricting their sales to proprietary envi-
ronments instead of to the whole world.
Closed Systems
I only want to work and play with you and him.
Systems that are referred to as closed use an architecture that does not follow industry
standards. Interoperability and standard interfaces are not employed to enable easy
communication between different types of systems and add-on features. Closed systems
are proprietary, meaning that the system can only communicate with like systems.
A closed architecture can provide more security to the system because it does not
have as many doorways in, and it operates in a more secluded environment than open
environments. Because a closed system is proprietary, there are not as many tools to
thwart the security mechanisms and not as many people who understand its design, lan-
guage, and security weaknesses to exploit. However, more security brings less function-
ality. A majority of the systems today are built with open architecture to enable them to
work with other types of systems, easily share information, and take advantage of the
functionality that third-party add-ons bring. However, this opens the doors to more
hacks, cracks, and attacks. You can’t have your cake and eat it too.
A Few Threats to Security Models

and Architectures
Now that we have talked about how everything is supposed to work, let’s take a quick
look at some of the things that can go wrong when designing a system.
Software almost always has bugs and vulnerabilities. The rich functionality de-
manded by users brings about deep complexity, which usually opens the doors to problems
Monday, May 19, 2003 3:40:07 PM

237
in the computer world. Also, vulnerabilities are always around because attackers contin-
ually find ways of using system operations and functionality in a negative and destruc-
tive way. Just like there will always be cops and robbers, there will always be attackers
and security professionals. It is a game of trying to outwit each other and seeing who will
put the necessary effort into winning the game.
Covert Channels
A covert channel is a way for an entity to receive information in an unauthorized man-
ner. It is an information flow that is not controlled by a security mechanism or the
mechanism has been successfully compromised. This type of information path is usu-
ally not used for communication; thus, the system does not properly protect this path
because the developers never envisioned information being passed this way. For an en-
tity to receive information in this manner violates the security policy of the system.
There are two types of covert channels: timing and storage. In a covert timing channel,
one process relays information to another by modulating its use of system resources.
The modulation of system resources can be accessing the hard drive, using excessive
CPU cycles, or head placement on a hard drive track. For example, if one process wrote
to the hard drive 30 times within 30 seconds this could mean something to another pro-
cess that is programmed to look for this type of activity. The second process watches out
for this “signal” and once it receives it, the second process carries out whatever evil activ-
ity it is programmed to do. You can think of it as a type of Morse code, but with the use
of some type of system resource.
A covert storage channel is when a process writes data to a storage location and an-
other process directly, or indirectly, reads it. The problem occurs when the processes are
at different security levels, and therefore not supposed to be sharing sensitive data.
Maybe an attacker figures out that two processes with different trust levels can view
the pagefile.sys file. Process 1 writes some type of confidential information to the
pagefile.sys file, and process 2 reads it. This would go against the information flow of
the system and directly negate the security policy.
The most common covert channel in use today is the Loki attack. This attack uses the
ICMP protocol for communication purposes. This protocol was not developed to be
used in this manner, it is only supposed to send status and error messages. But someone
developed a tool (Loki) that will allow an attacker to write data right behind the ICMP
header. This allows the attacker to communicate to another system through a covert
channel. It is usually very successful because most firewalls are configured to allow
ICMP traffic in and out of their environments. This is a covert channel because it is using
something for communication purposes that was not developed for this type of com-
munication functionality.
NOTE An overt channel is a channel of communication that was developed

specifically for communication purposes. Processes should be communicating
through overt channels, not covert channels.
Monday, May 19, 2003 3:40:07 PM

238
Countermeasures
Because all operating systems have some type of covert channels, it is not always feasi-
ble to attempt to get rid of them all. The number of acceptable covert channels usually
depends on the security rating of a system. A system that has a B2 rating has fewer con-
vert channels than a C1 system. There is not much a user can do to countermeasure
these channels; instead, they are addressed when constructing and developing a system.
In the Orange Book, covert channels in operating systems are not addressed until the
security level B2 and above because these are the systems that would be holding data
sensitive enough for others to go through all the necessary trouble to access data in this
fashion.
Detecting a covert channel is very difficult to do; the following are some points about
countermeasures:
• It is unlikely that intrusion detection systems will detect this type of attack
within an operating system, but it’s always worth a try.
• A network and host intrusion detection system can be more successful in
identifying covert channels within the network.
• Auditing should be enabled to try and detect a covert channel use pattern,
although it can be hard to detect within an operating system or product. Auditing
for covert channel violations within the network could be much more successful.
Backdoors
In the programming world, backdoors are also called maintenance hooks. They are in-
structions within software that only the developer knows about and can invoke. They
are placed in the software for easy access. They also allow the developer to view and edit
the code without having to go through regular access controls. During the development
phase of the software, these can be very useful, but if they are not removed before going
into production, they can cause major security issues.
The backdoor is usually initiated by a random sequence of keystrokes that provides
access into the software without having to go through normal access control and secu-
rity checks and mechanisms.
An application that has a maintenance hook enables the developer to execute specific
commands by using a specific sequence of keystrokes. Once this is done successfully,
the developer is inside the application looking directly at the code. She might do this to
watch problem areas within the code, check variable population, export more code into
the program, or fix problems that she sees that are taking place. Although this sounds
nice and healthy, if an attacker finds out about this maintenance hook, more sinister ac-
tions may be taken. So all backdoors need to be removed from software before it goes
into production.
Countermeasures
Because backdoors are usually inserted by programmers, they are the ones who usually
have to take them out before the programs and systems go into production. Code re-
views and unit and integration testing should always be looking out for backdoors in
Monday, May 19, 2003 3:40:07 PM

239
case the programmer overlooked extracting them. Because backdoors are within the
code of an application or system, there is not much a user can do to prevent their pres-
ence, but when a vendor finds out that a backdoor exists in their product, they usually
develop and release a patch to reduce this vulnerability. Because most vendors sell their
software without selling the associated source code with it, it may be very difficult for
companies who have purchased software to identify backdoors. The following lists
some preventative measures against backdoors:
• A host intrusion detection system can be used to watch for an attacker using a
backdoor into the system.
• File system permissions can be set to try and protect configuration files and
sensitive information from being modified.
• Strict access control can be added to prevent access to the system in the first place.
• File system encryption can be used to protect sensitive information.
• Auditing should be in place to detect any type of backdoor use.
Asynchronous Attack
Specific attacks can take place on a system that take advantage of the way a system pro-
cesses requests and performs tasks. An asynchronous attack deals with the sequences of
steps a system uses to complete a task. For example, if a system uses an autoexec.bat file,
the system first goes through a boot process and checks to see if an autoexec.bat file exists
on the system. If one does not exist, it will continue with its bootup procedures, but if it
does exist, it will open the file and process it line by line. There is a timing difference of
when the system checks to see if an autoexec.bat file exists and actually executing the
contents of the file. There are actually two different and distinct steps here. A time-of-check
versus time-of-use (TOC/TOU) attack could replace the autoexec.bat with a different
autoexec.bat that compromises the system before the system actually initiates it.
A similar but different issue is called a race condition. When two different processes
need to carry out their tasks on a resource, they need to follow the correct sequence. Pro-
cess 1 needs to carry out its work before process 2 accesses the same resource and carries
out its tasks. If process 2 goes before process 1, the outcome could be very different. If an
attacker could manipulate the processes so that process 2 did its thing first, she is con-
trolling the outcome of the processing procedure.
Countermeasures
It would take a dedicated attacker with great precision to perform these types of at-
tacks, but it is possible and has been done. The following can be used to protect
against this type of attack:
• A host intrusion detection system can be used to watch for this type of
suspicious behavior.
• File system permissions and encryption can be set to protect sensitive files.
Monday, May 19, 2003 3:40:07 PM

240
• Strict access control measures can be used to prevent an intruder from accessing
the system in the first place.
• Auditing should be in place to catch patterns or indications of TOC/TOU attacks.
NOTE This attack would be extremely hard to detect because it deals with the
sequence of steps processes take when carrying out their tasks. There are few,
if any, protection tools that look at these issues to this level of granularity. It is
best addressed during the development of the product.
Buffer Overflows
Buffer overflows happen when programs do not check the length of data that is inputted
into a program. The programmer can set the value of a required input to be 80 charac-
ters, but does not ensure that only up to 80 are actually inputted from a user or another
program. If more than 80 characters are entered, this extra data overflows its allotted
memory segment and is executed by the CPU. The extra data can launch another pro-
gram or be a set of code that was devised to perform disruptive behavior in the system.
This is sometimes referred to as “smashing the stack.” A buffer overflow is usually aimed
at systems that let the extra code be executed with privileged rights, meaning the soft-
ware executes in a more privileged mode and has access to more critical resources.
Countermeasures
The first and best countermeasure to buffer overflows is proper programming and good
coding practices. There are also several types of tools available to help prevent buffer
overflows. Some tools monitor dynamic link library (DLL) usage, and other tools pro-
vide a wrapper around the kernel that monitors calls and watches for known buffer
overflow attacks.
There is not much a user can do to prevent buffer overflows, because they are part of
the program code. But when vendors discover these issues, they develop and distribute
patches to reduce this type of vulnerability. The following can be used to protect against
buffer overflows:
• A host intrusion detection system can be used to watch for this type of
suspicious behavior.
• File system permissions and encryption can be set to protect sensitive files.
• Strict access control measures can be used to prevent an intruder from accessing
the system in the first place.
• Auditing should be in place to catch patterns or indications of buffer overflow
attacks.
Summary
The architecture of a computer system is very important and covers many topics. The
system has to make sure that memory is properly segregated and protected, ensure that
only authorized subjects access objects, ensure that untrusted processes cannot perform
Monday, May 19, 2003 3:40:08 PM

241
activities that would put other processes at risk, control the flow of information, and de-
fine a domain of resources for each subject. It also must ensure that if the computer ex-
periences any type of disruption, it will not result in an insecure state. Many of these
issues are dealt with in the system’s security policy, and the security model is built to
support the requirements of this policy.
Once the security policy, architecture, and model have been developed, the computer
operating system, or product, must be built, tested, evaluated, and rated. An evaluation
is done by comparing the system to a predefined criteria. The rating that is assigned to
the system depends upon how it fulfills the requirements in the criteria. Customers use
this rating to understand what they are really buying and how much they can trust this
new product. Once the customer buys the product, it must be tested within their own
environment to make sure it meets their company’s needs, which takes place through
certification and accreditation processes.
Quick Tips
• A system can have the exact same hardware, software components, and
applications, but provide different levels of protection because of the different
security policies and security models that the systems were built upon.
• A CPU contains a control unit, which controls the timing of the execution of
instructions and data, and an ALU, which performs mathematical functions
and logical operations.
• Most systems use protection rings. The more privileged processes run in the
lower ring numbers and have access to all or most of the system resources.
Applications run in higher-numbered rings and have access to a smaller
amount of resources.
• Operating system processes are executed in privileged or supervisory mode,
and applications are executed in user mode, also known as “problem” state.
• Secondary storage is nonvolatile and can be a hard drive, CD-ROM, floppy
drive, tape backup, or a zip drive.
• Virtual storage combines RAM and secondary storage so the system seems to
have a larger bank of memory.
• A deadlock situation occurs when two processes are trying to access the same
resource at the same time or when a process commits a resource and does not
release it.
• Security mechanisms can focus on different issues, work at different layers,
and vary in complexity.
• The more complex a security mechanism is, the less amount of assurance it
can provide.
• Not all system components fall under the TCB, only those that enforce the
security policy directly and protect the system. These components are within
the security perimeter.
Monday, May 19, 2003 3:40:08 PM

242
• Components that make up the TCB are hardware, software, and firmware that
provides some type of security protection.
• A security perimeter is an imaginary boundary that has trusted components
within it (those that make up the TCB) and untrusted components on the
outside of the boundary.
• The reference monitor concept is an abstract machine that ensures that all
subjects have the necessary access rights before accessing objects. Therefore,
it mediates all accesses to objects by subjects.
• The security kernel is the mechanism that actually enforces the rules of the
reference monitor concept.
• The security kernel must isolate processes carrying out the reference monitor
concept, must be tamperproof, must invoke the reference monitor for each
access attempt, and must be small enough to be properly tested.
• A security domain is all the objects available to a subject.
• Processes need to be isolated, which can be done through segmented memory
addressing.
• A security policy is a set of rules that dictate how sensitive data is to be managed,
protected, and distributed. It provides the security goals that the system must
accomplish.
• The level of security a system provides depends upon how well it enforces the
security policy.
• A multilevel security system processes data at different classifications (security
levels), and users with different clearances (security levels) can use the system.
• Processes should be assigned least privilege so that they have just enough
system privileges to fulfill their tasks and no more.
• Some systems provide functionality at different layers of the system, which is
called layering. This separates the processes and provides more protection for
them individually.
• Data hiding is when the processes at different layers do not know about each
other, and therefore do not have a way to communicate to each other. This
provides more protection for the data.
• When a class of objects is assigned permissions, it is called abstraction.
• A security model maps the abstract goals of a security policy to computer
system terms and concepts. It gives the security policy structure and provides
a framework for the system.
• The Bell-LaPadula model deals only with confidentiality, and the Biba and
Clark-Wilson models deal with integrity.
• A state machine model deals with the different states a system can enter. If a system
starts in a secure state, all state transitions take place securely, and the system shuts
down and fails securely, the system will never end up in an insecure state.
Monday, May 19, 2003 3:40:08 PM

243
• A lattice provides an upper bound and a lower bound of authorized access.
• An information flow security model does not permit data to flow to an object
in an insecure manner.
• The Bell-LaPadula model has a simple security rule, which means that a subject
cannot read data from a higher level (no read up). The *-property rule means
that a subject cannot write to an object at a lower level (no write down). The
strong star property rule dictates that a subject can only perform an operation
at the exact same classification level, nothing higher, and nothing lower.
• The Biba model does not let subjects write to objects at a higher integrity level
(no write up), and it does not let subjects read data at a lower integrity level (no
read down). This is done to protect the integrity of the data.
• The Bell-LaPadula model is used mainly in military systems. The Biba and
Clark-Wilson models are used in the commercial sector.
• The Clark-Wilson model dictates that subjects can only access objects through
applications, that separation of duties is enforced, and auditing is in place.
• If a system is working in a dedicated security mode, it only deals with one level
of data classification and all users must have this level of clearance to be able to
use the system.
• Compartmented and multilevel security modes enable the system to process
data classified at different classification levels.
• Trust means that a system uses all of its protection mechanisms properly
to process sensitive data for many types of users. Assurance is the level of
confidence you have in this trust and that the protection mechanisms behave
properly in all circumstances predictably.
• The lower ratings in the evaluation criteria review the performance of a system
and its testing results. The higher ratings look at this information and the
system design, development procedures, and documentation.
• The Orange Book, also called Trusted Computer System Evaluation Criteria
(TCSEC), was developed to evaluate systems built to be used mainly by the
military.
• In the Orange Book, D classification means a system provides minimal security
and is used for systems that were evaluated but failed to meet the criteria of
higher divisions.
• In the Orange Book, the C division deals with discretionary protection and
division B deals with mandatory protection (security labels).
• In the Orange Book, the A division means the system’s design and level of
protection is verifiable and provides the highest level of assurance and trust.
• In the Orange Book, C2 requires object reuse protection and auditing.
• In the Orange Book, B1 is the first rating that requires security labels.
Monday, May 19, 2003 3:40:08 PM

244
• In the Orange Book, B2 requires all subjects and devices to have security
labels, there must be a trusted path and covert channel analysis, and separate
administrator functionality is provided.
• In the Orange Book, B3 requires that a security administrator role is defined,
trusted recovery takes place, and the system monitors events and notifies
security personnel.
• In the Orange Book, C1 outlines access control to be based on individuals and/
or groups. It requires a separation of users and information, and identification
and authentication of individual entities.
• The Orange Book deals mainly with stand-alone systems, so a range of books
were written to cover many other topics in security. These books are called the
Rainbow Series.
• The Red Book, or Trusted Network Interpretation (TNI), provides guidelines for
networks and network components.
• The Information Technology Security Evaluation Criteria (ITSEC) was an
attempt by European countries to develop and use one set of evaluation criteria
instead of several.
• The ITSEC evaluates the assurance and functionality of a system separately,
whereas the TCSEC combines the two into one rating.
• The Common Criteria was developed to provide a globally recognized evaluation
criteria and is in use today. It combines sections of the TCSEC, ITSEC, CTCPEC,
and the Federal Criteria.
• The Common Criteria uses protection profiles and ratings from EAL1 to EAL7.
• Certification is the technical evaluation of a system and its security components.
Accreditation is management’s formal approval and acceptance of the security
provided by a system.
• An open system provides better interoperability with other systems and products.
A closed system works within a proprietary environment, which lowers its
interoperability and functionality possibilities.
• A covert channel is an unintended communication path that transfers data
in a way that violates the security policy. There are two types: timing and
storage covert channels.
• A covert timing channel enables a process to relay information to another
process by modulating its use of system resources.
• A covert storage channel enables a process to write data to a storage medium
so another process can read it.
• A maintenance hook is developed to let a programmer into the application
quickly for maintenance or adding functionality. This should be removed
before the application goes into production or it can cause a serious security risk.
Monday, May 19, 2003 3:40:08 PM

245
• An execution domain is where instructions are executed by the CPU. The
operating system’s instructions are executed in a privileged mode, and
applications’ instructions are executed in user mode.
• Process isolation ensures that multiple processes can run concurrently and the
processes will not interfere with each other or affect each other’s memory segments.
• The only processes that need complete system privileges are located in the
system’s kernel.
• A single state machine processes data of a single security level. A multistate
machine processes data at two or more security levels without risk of
compromising the system’s security.
• Strong typing indicates that there is strong enforcement of abstract data types.
• TOC/TOU stands for time-of-check versus time-of-use. This is a class of
asynchronous attacks.
• The Biba model is based on a hierarchical lattice of integrity levels.
• The Biba model addresses the first goal of integrity, which is to prevent
unauthorized users from making modifications.
• The Clark-Wilson model addresses all three integrity goals: prevent unauthorized
users from making modifications, prevent authorized users from making improper
modifications, and maintain internal and external consistency.
• In the Clark-Wilson model, users can only access and manipulate objects
through programs. It uses access triple, which is subject-program-object.
• ITSEC was developed for European countries. It was not an international
evaluation criterion.
Questions
Please remember that these questions are formatted and asked in a certain way for a reason.
You must remember that the CISSP exam is asking questions at a conceptual level. Ques-
tions may not always have the perfect answer, and the candidate is advised against always
looking for the perfect answer. The candidate should look for the best answer in the list.
1. What flaw creates buffer overflows?

A. Application executing in privileged mode
B. Inadequate memory segmentation
C. Inadequate protection ring use
D. Insufficient parameter checking
2. The operating system performs all except which of the following tasks?
A. Memory allocation
B. Input and output tasks
Monday, May 19, 2003 3:40:08 PM

246
C. Resource allocation
D. User access to database views
3. If an operating system allows sequential use of an object without refreshing it,
what security issue can arise?
A. Disclosure of residual data
B. Unauthorized access to privileged processes
C. Data leakage through covert channels
D. Compromising the execution domain
4. What is the final step in authorizing a system for use in an environment?
A. Certification
B. Security evaluation and rating
C. Accreditation
D. Verification
5. What feature enables code to be executed without the usual security checks?
A. Antivirus software
B. Maintenance hook
C. Timing channel
D. Ready state
6. If a component fails, a system should be designed to do which of the following?
A. Change to a protected execution domain
B. Change to a problem state
C. Change to a more secure state
D. Release all data held in volatile memory
7. What security advantage does firmware have over software?
A. It is difficult to modify without physical access.
B. It requires a smaller memory segment.
C. It does not need to enforce the security policy.
D. It is easier to reprogram.
8. Which is the first level of the Orange Book that requires classification labeling
of data?
A. B3
B. B2
C. B1
D. C2
Monday, May 19, 2003 3:40:08 PM

247
9. Which of the following best describes the reference monitor concept?
A. A software component that monitors activity and writes security events to an
audit log
B. A software component that determines if a user is authorized to perform a
requested operation
C. A software component that isolates processes and separates privilege and
user modes
D. A software component that works in the center protection ring and provides
interfaces between trusted and untrusted objects
10. The Information Technology Security Evaluation Criteria was developed for
which of the following?
A. International use
B. U.S. use
C. European use
D. Global use
11. A security kernel contains which of the following?
A. Software, hardware, and firmware
B. Software, hardware, and system design
C. Security policy, protection mechanisms, and software
D. Security policy, protection mechanisms, and system design
12. What characteristic of a trusted process does not allow users unrestricted access
to sensitive data?
A. Process isolation enforcement
B. Security domain enforcement
C. Need-to-know enforcement
D. TCB enforcement
13. The Orange Book states that a system should uniquely identify each user for
accountability purposes and _______________.
A. Require the user to perform object reuse operations
B. Associate this identity with all auditable actions taken by that individual
C. Associate this identity with all processes the user initiates
D. Require that only that user have access to his specific audit information
14. The trusted computing base (TCB) controls which of the following?
A. All trusted processes and software components
B. All trusted security policies and implementation mechanisms
Monday, May 19, 2003 3:40:08 PM

248
C. All trusted software and design mechanisms
D. All trusted software and hardware components
15. What is the imaginary boundary that separates components that maintain
security from components that are not security related?
A. Reference monitor
B. Security kernel
C. Security perimeter
D. Security policy
16. Which model deals only with confidentiality?
A. Bell-LaPadula
B. Clark-Wilson
C. Biba
D. Reference monitor
17. What is the best description of a security kernel from a security point of view?
A. Reference monitor
B. Resource manager
C. Memory mapper
D. Security perimeter
18. When is security of a system most effective and economical?
A. If it is designed and implemented from the beginning of the development of
the system
B. If it is designed and implemented as a secure and trusted front end
C. If it is customized to fight specific types of attacks
D. If the system is optimized before security is added
19. In secure computing systems, why is there a logical form of separation used
between processes?
A. Processes are contained within their own security domains so that each does
not make unauthorized accesses to other objects or their resources.
B. Processes are contained within their own security perimeter so that they can
only access protection levels above them.
C. Processes are contained within their own security perimeter so that they can
only access protection levels equal to them.
D. The separation is hardware and not logical in nature.
Monday, May 19, 2003 3:40:08 PM

249
20. What type of attack is taking place when a higher level subject writes data to
a storage area and a lower level subject reads it?
A. TOC/TOU
B. Covert storage attack
C. Covert timing attack
D. Buffer overflow
21. What type of rating does the Common Criteria give to products?
A. PP
B. EPL
C. EAL
D. A–D
22. Which best describes the *-integrity axiom?
A. No write up in the Biba model
B. No read down in the Biba model
C. No write down in the Bell-LaPadula model
D. No read up in the Bell-LaPadula model
23. Which best describes the simple security rule?
A. No write up in the Biba model
B. No read down in the Biba model
C. No write down in the Bell-LaPadula model
D. No read up in the Bell-LaPadula model
24. Which of the following was the first mathematical model of a multilevel
security policy used to define the concept of a security state, modes of access,
and outlines rules of access?
A. Biba
B. Bell-LaPadula
C. Clark-Wilson
D. State machine
25. Which of the following is not a characteristic of the Bell-LaPadula model?
A. Confidentiality model
B. Integrity model
C. Developed and used by the U.S. DoD
D. First mathematical multilevel security model
Monday, May 19, 2003 3:40:09 PM

250
Answers
1. D. A buffer overflow takes place when too much data is accepted as input.
Programmers should implement the correct security controls to ensure that
this does not take place. This means they need to perform bounds checking
and parameter checking to ensure only the allowed amount of data is actually
accepted and processed by the system.
2. D. The operating system has a long list of responsibilities, but implementing
database views is not one of them. This is the responsibility of the database
management software.
3. A. If an object has confidential data and this data is not properly erased before
another subject can access it, this leftover or residual data can be accessible. This
can compromise the data and system’s security by disclosing this confidential
information.
4. C. Certification is a technical review of a product, and accreditation is
management’s formal approval of the findings of the certification process.
This question asked you which step was the final step of authorizing a system
before it is to be used in an environment, and that is what accreditation is
all about.
5. B. Maintenance hooks get around the system’s or application’s security and
access control checks by allowing whoever knows the key sequence to access
the application and most likely its code. Maintenance hook should be removed
from any code before it gets into production.
6. C. The state machine model dictates that a system should start up securely,
carry out secure state transitions, and even fail securely. This means that if the
system encounters something it deems as unsafe, it should change to a more
secure state for self-preservation and protection.
7. A. Firmware is a type of software that is held in a ROM or EROM chip. It is
usually used to allow the computer to be able to communicate with some type
of peripheral device. The system’s BIOS instructions are also held in firmware
on the motherboard. In most situations firmware cannot be modified unless
someone has physical access to the system. This is different from other types
of software that may be modified remotely.
8. C. These assurance ratings are from the Orange Book. B levels and on up
require security labels to be used, but the question asks which is the first
level to require this. B1 comes before B2 and B3, thus it is the correct answer.
9. B. A reference monitor is the abstract machine that holds all of the rules of
access for the system. The security kernel is the active entity that enforces the
reference monitor’s rules. They control the access attempts of any and all subjects,
a user is just one example of a subject.
10. C. In ITSEC, the I does not stand for international, it stands for information. This
is a criteria that was developed to be used by European countries to evaluate and
rate their security products.
Monday, May 19, 2003 3:40:09 PM

251
11. A. The security kernel makes up the main component of the TCB, which is
made up of software, hardware, and firmware. The security kernel performs
a lot of different activities to protect the system; enforcing the reference
monitor’s access rules is just one of those activities.
12. C. A system that enforces need-to-know does not allow subjects to access
objects unless they have been granted the formal approval, which is based
on a need-to-know. This question is targeting MAC-based systems that would
use security labels, clearances, and classifications also in its access criteria.
13. B. Proper security implementations include tracking individuals and their
actions. The users need to be identified uniquely to be able to track their
individual activities. If all users logged in and authenticated to a system as
user001, the system could never be able to distinguish which user actually
carried out specific actions.
14. D. The TCB contains and controls all protection mechanisms within the
system, whether they be software, hardware, or firmware.
15. C. The security perimeter is a boundary between items that are within the
TCB and the ones that are not part of the TCB. It is just a mark of delineation
between these two groups of items.
16. A. The Bell-LaPadula model was developed for the U.S. government with
the main goal of keeping sensitive data unreachable to those who were not
authorized to access and view it. This model was the first mathematical model
of a multilevel security policy used to define the concept of a security state,
modes of access, and outlines rules of access. The Biba and Clark-Wilson
models do not deal with confidentiality, but with integrity instead.
17. A. The security kernel is a portion of the operating system’s kernel and enforces
the rules outlined in the reference monitor. It is the enforcer of the rules and is
invoked each time a subject makes a request to access an object. A portion of the
kernel is the resource manager, not the security kernel. A memory mapper is a
distinct function of the kernel also, and the security perimeter delineates between
what is within the TCB and what is not.
18. A. It is difficult to add useful and effective security at the end of developing a
product or adding security as a front end to an existing product. Adding security
at the end of a project is usually more expensive because it will break items and
the team will need to go back to the drawing board and redesign and recode
portions of the product.
19. A. Processes are assigned their own variables, system resources, and memory
segments, which makes up their domain. This is done so that they do not
corrupt each other’s data or processing activities.
20. B. A covert channel is being used when something is using a resource
for communication purposes and that is not the reason this resource was
created. A process can write to some type of shared media or storage place
that another process will be able to access. The first process writes to this
media and the second process reads it. This action goes against the security
policy of the system.
Monday, May 19, 2003 3:40:09 PM

252
21. C. The Common Criteria uses a different assurance rating system than the
previously used systems. It has packages of specifications that must be met
for a product to obtain the corresponding rating. These ratings and packages
are called evaluation assurance levels (EALs). Once a product achieves any
type of rating, customers can view this information on an Evaluated Products
List (EPL).
22. A. The *-integrity axiom (or star integrity axiom) indicates that a subject of a
lower integrity level cannot write to an object of a higher integrity level. This
rule is put into place to protect the integrity of the data that resides at the
higher level.
23. D. The simple security rule is implemented to ensure that any subject at a lower
security level cannot view data that resides at a higher level. The reason this type
of rule is put into place is to protect the confidentiality of the data that resides
at the higher level. This rule is used in the Bell-LaPadula model. Remember that
if you see “simple” in a rule it pertains to reading, and * or “star” pertains to
writing.
24. B. This is a formal definition of the Bell-LaPadula model, which was created
and implemented to protect government and military confidential information.
25. B. The Bell-LaPadula security model was the first mathematical state machine
model that provided multilevel security systems. The model was developed
because the U.S. DoD had concerns about the systems it was depending upon
to keep its military secrets and confidential information. Bell-LaPadula is
a confidentiality model and does not address integrity.
Monday, May 19, 2003 3:40:09 PM
Fernandez et al. Cybersecurity (2022) 5:7
https://doi.org/10.1186/s42400-022-00109-w
Cybersecurity
RESEARCH Open Access
Abstract security patterns and the design

of secure systems
Eduardo B. Fernandez1* , Nobukazu Yoshioka2, Hironori Washizaki3 and Joseph Yoder4
Abstract
During the initial stages of software development, the primary goal is to define precise and detailed requirements
without concern for software realizations. Security constraints should be introduced then and must be based on the
semantic aspects of applications, not on their software architectures, as it is the case in most secure development
methodologies. In these stages, we need to identify threats as attacker goals and indicate what conceptual security
defenses are needed to thwart these goals, without consideration of implementation details. We can consider the
effects of threats on the application assets and try to find ways to stop them. These threats should be controlled with
abstract security mechanisms that can be realized by abstract security patterns (ASPs), that include only the core func-
tions of these mechanisms, which must be present in every implementation of them. An abstract security pattern
describes a conceptual security mechanism that includes functions able to stop or mitigate a threat or comply with
a regulation or institutional policy. We describe here the properties of ASPs and present a detailed example. We relate
ASPs to each other and to Security Solution Frames, which describe families of related patterns. We show how to
include ASPs to secure an application, as well as how to derive concrete patterns from them. Finally, we discuss their
practical value, including their use in “security by design” and IoT systems design.
Keywords: Security patterns, Secure software development, Security requirements, Secure software architecture, IoT
systems design
Introduction software. In the requirements and analysis stages of soft-

When solving a problem, we should try to produce first ware development we are trying to understand the prob-
an abstract, conceptual solution, before we get con- lem, it is too early to introduce implementation aspects
cerned with implementation details. Those details may that just would make the problem harder. This is also true
obscure the objectives of the solution adding unneces- for security. Security is a quality aspect that constrains
sary complexity and might make us overlook the possi- the behavior of applications by imposing access and use
bility of solving a similar problem in the same way. We restrictions on the data and other assets, which means
need to understand the problem before we can solve it; that the requirements stage is the appropriate stage to
according to Polya: “Visualize the problem as a whole as start addressing security. We only want to indicate at this
clearly and as vividly as you can. Do not concern your- stage which security controls are needed, not their most
self with details for the moment” (Polya 1957). Building efficient or convenient implementation. If we consider a
a software application is solving a specific type of prob- financial application example, we only want to specify the
lem, where the abstract solution must be realized using business rules of accounts, customers, and transactions
with their corresponding restrictions. These restrictions
may include: “customers are the only ones who can per-
*Correspondence: fernande@fau.edu form transactions on their own accounts”, “an account
1
Department of Electrical Engineering and Computer Science, Florida owner can close his/her account”, and similar type of con-
Atlantic University, Boca Raton, FL, USA straints. The constraints come from the semantics of the
Full list of author information is available at the end of the article
© The Author(s) 2022. Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which
permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the
original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or
other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line
to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory
regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this
licence, visit http://creativecommons.org/licenses/by/4.0/.
Fernandez et al. Cybersecurity (2022) 5:7 Page 2 of 17
application—they may reflect business rules and regula- a hierarchy of patterns going from abstract security pat-
tions, and from the necessity to defend against possible terns to platform-oriented versions of these patterns and
threats. At this stage, we can add patterns (or other arti- their code realizations.
facts), to define abstract security mechanisms to express ASPs are different from principles of good security
these restrictions. From our concern for security, by pat- design, e.g., Single-Point-of-Access (Yoder and Barcalow
tern we mean a security pattern, an encapsulated solution 2000) or Need to Know (Fernandez et al. 2011), even if
to a security problem (Fernandez 2013; Steel et al. 2005). these can be represented as patterns. ASPs correspond
These abstract patterns would include only the funda- to application defenses, intended to be realized later by
mental characteristics of the security mechanism, not specific computational mechanisms, they do not describe
including implementation aspects. In Avgeriou (2003), principles, that may have many realizations. In each use
we introduced1 the idea of abstract security pattern case of the requirements stage we can specify what secu-
(ASP), that describes a conceptual security mechanism rity controls we need and in the conceptual model of the
that realizes one or more security policies able to con- analysis stage we add the corresponding ASPs after we
trol (stop or mitigate) a threat or comply with a security have enumerated the expected threats.
regulation or policy. Most works using security patterns Our contributions include:
(Blakeley and Heath 2004; Fernandez 2013; Schumacher
et al. 2006; Steel et al. 2005) apply concrete patterns, • Development and characterization of the concept of
which provide protection at specific architectural levels ASP by means of analysis and examples.
or components, e.g., secure virtual address space (VAS) • Description of the relationships of ASPs to other
in operating systems (Fernandez 2013). In fact, an exami- ASPs and to SSFs to structure the defenses needed
nation of the literature did not find any work on patterns for an application.
(security or other types), where abstraction is explic- • Demonstrating the value of ASPs by showing how
itly considered. While this concept is mentioned in the they can be used to build conceptual models, to
patterns of the GOF (Gamma et al. 1994), they did not derive new patterns, and other possible uses for
develop their possibilities. We develop here the concept secure application development, including security
of ASP based on the definition above and we show its by design and IoT systems design.
possibilities. The common context of all Abstract Secu-
rity Patterns is the problem space of the corresponding “Security patterns and security solution frames” sec-
applications, that can be expressed using domain models tion presents some background, while “Abstract security
for specific knowledge areas. ASPs can be related to each patterns (ASPs)” section discusses the nature of ASPs
other using pattern diagrams or more precisely through and presents a complete example of one of them. “ASP-
Security Solution Frames. Pattern diagrams indicate how based hierarchies” section considers the properties of
patterns relate to each other, showing the contribution a ASP-based hierarchies, while “Relationships between
pattern brings to another. Security solution frames (SSFs) ASPs and security solution frames” section relates ASPs
are sets of patterns that correspond to specific concerns to SSFs. “ASPs in secure conceptual models” section
of a solution, e.g., authentication (Uzunov et al. 2015a, b; shows how to use ASPs to build secure conceptual mod-
Uzunov and Fernandez 2021). els. “Deriving concrete patterns from ASPs” section illus-
Some of the ASPs correspond to standard security trates the derivation of concrete patterns starting from
mechanisms, e.g., Access control (Authorization and Ref- ASPs. “Formalization of ASPs” section formalizes ASPS,
erence Monitor), Security Logger/Auditor, and Authen- while “Evaluation of effectiveness” section evaluates their
ticator. Others may specify more detailed aspects, e.g., effectiveness. “Related work and discussion” section dis-
Access Control/Authorization models including the cusses related work, while “Conclusions and future work”
Access Matrix, role-based access control (RBAC), and section presents some conclusions and possible future
Multilevel models (Fernandez 2013); although those may work.
not be strictly abstract models, they correspond to insti-
tution policies. Starting from ASPs, when developing Security patterns and security solution frames
the lifecycle steps of a complete application we can use A security pattern is a solution to a security problem,
intended to control (stop or mitigate) a specific type
of threat by defining a security mechanism, or a way to
1
We introduced the idea in a two-page paper (Fernandez et al. 2008), but did realize a security policy or regulation, applicable in a
not develop its properties. We further developed the idea in (Fernandez et al. given context (Fernandez 2013; Schumacher et al. 2006).
2014). This paper considerably expands these previous works. We have also The problem solved by the pattern is briefly described
published four complete ASPs (Fernandez et al. 2016, 2018;, 2019, 2020).
in its “Intent” section and elaborated in a “Problem”
section. A set of forces define constraints for the solu- We have developed a systematic way of enumerating
tion, e.g., “the solution must accommodate a variety of threats (Fernandez 2013) which consists of analysis of the
users”. The solution is typically expressed using UML flow of events in a use case or a sequence of use cases, in
class, sequence, state, and activity diagrams (although which each activity is analyzed to uncover related threats.
we usually need only one or two of these models). A set This analysis should be performed for all the system uses
of consequences indicate how well the solution satisfied cases. We use pattern diagrams and unified modeling
the forces; in particular, how well the attacks were con- language (UML) class, sequence, and use case diagrams
trolled, or a regulation was fulfilled. An implementation to describe patterns and architectures. A pattern diagram
section provides guidelines on how to use the pattern in (Buschmann et al. 1996) shows the relationships between
an application, indicating what steps are needed, their patterns, where patterns are shown as rounded rectan-
possible realizations, and variants. A “related patterns” gles; each arc from pattern A to pattern B indicates the
section enumerates other patterns that complement the contribution of pattern A to the pattern it points (B).
pattern or that provide alternative solutions. A domain model (DM) is a model of an area of knowl-
Security patterns are classified as architecture patterns edge, e.g., health systems, using an appropriate language.
because they describe global architecture concepts, e.g., A DM can be defined using sets of related patterns that
“what type of authentication is needed to control access represent specific aspects of the domain. The compo-
for the users of a system?” A few of them can also (or nents of domain models are usually described in UML
instead) be considered as design patterns because they or some ontology language like OWL. A reference archi-
handle aspects of the security code of a component. ASPs tecture (RA) is an abstract architecture, with concepts of
are in effect a variety of analysis patterns. An analysis a particular domain (or set of domains), with no imple-
pattern describes a semantic aspect of an application, e.g., mentation aspects (Avgeriou 2003; Taylor et al. 2010).
the description of types of accounts in a financial institu- RAs are reusable, extensible, and configurable; they can
tion (Fowler 1997). Some security patterns are more use- be built as a set of related patterns describing some type
ful by looking at them in more than one perspective. For of architecture and they can be instantiated into a con-
example, the Security Logger in (Steel et al.2005) concen- crete software architecture by adding implementation
trates on the software implementation of this pattern, so aspects. Security reference architectures (SRAs) include a
this is a design pattern; the Security Logger in Fernandez set of ASPs (or other artifacts) that provide defenses for
(2013) is an ASP because it emphasizes the core functions the threats of a reference architecture (Fernandez 2015).
of this pattern. If we combine both perspectives, this pat-
tern can be useful to software architects and developers. Abstract security patterns (ASPs)
We call the patterns derived from an ASP concrete pat- As indicated earlier, an ASP is a security pattern that
terns, because they refer to some specific software envi- describes a conceptual semantic restriction in a domain,
ronment, e.g., a distributed system. There are different which can be a defense to a threat or a way to comply with a
degrees of concreteness depending on how specific they regulation, with no implementation aspects. That is, an ASP
are. It is possible to even define patterns with contexts provides only the necessary core functions for those objec-
using specific technologies or architectural styles, e.g., tives. In this section, we use the Authenticator ASP as exam-
IoT patterns (van Heesch et al. 2011; Washizaki et al. ple (developed as a complete pattern in (Fernandez et al.
2021). In the development of a software system, we need 2018); further examples of ASPs include Secure IaaS (Fer-
to use patterns for several architectural levels. nandez et al. 2016), Secure Network Segmentation (Fernan-
Security solution frames (SSFs) are sets of patterns that dez et al. 2019), and Secure Publish/Subscribe (Fernandez
correspond to a specific aspect or concern of a security et al. 2020). The Intent section of an Authenticator pattern
solution (Uzunov et al. 2015a; Uzunov and Fernandez as described in (Fernandez 2013) is: “A user or system (sub-
2021). Their vertical grouping collects together all the ject) requesting access to a system identifies itself, how does
patterns that are related to a security concern, often in the system verify that the subject is who it says it is? The
a hierarchical structure; an Authentication SSF could subject must present some information that is recognized
look like Fig. 4 (Uzunov and Fernandez 2021). Different by the system as identifying this subject. After being authen-
levels of abstraction (concreteness) of a security mecha- ticated, the requestor is given some proof of this fact.”
nism define a vertical structuring, while we can define a Authentication restricts access to a system to only
horizontal association by connecting different concerns. registered users; it handles the threat where an intruder
Security patterns and SSFs are not very useful in isola- enters a system and tries to perform unauthorized access
tion (Fernandez 2013; Uzunov et al. 2015b), they should to information or other resources.2 This definition is what
be applied in the stages of a systematic methodology to 2
Systems usually also have another level of control that restricts access to
build secure systems. specific resources, this is Authorization.
type of interface to class Authenticator by providing a

request Proof of Identity (owned by the subject). The Authen-
Subject Authenticator
* Authent 1 ticator then searches class Authentication Information
to decide if the subject is legitimate. Class Authentica-
tion Information includes information previously stored
<<create>>
by the subject, which is needed to authenticate it, e.g., a
1
list of passwords, a set of fingerprints, a cryptographic
1.. * 1
protocol, a history of past interactions, or similar. The
Proof of Proof of Authentication Authenticator provides the subject with a Proof of
Identity Authentication Information Authentication, so that the requestor needs not authen-
Fig. 1 Class diagram of the abstract authenticator pattern ticate itself again in later accesses. Dynamic models for
this pattern include sequence diagrams for the use cases
“Register a subject” and “Request access”, which real-
ize the scenario above (Fernandez 2013; Fernandez et al.
is usually called entity authentication (Song et al. 2003).
2018). Figure 2 shows the successful execution of the use
There are many ways to perform this authentication, that
case “Request access”. This diagram performs the steps
go from manual ways, as done in voting places during
described above: after validating the proof of identity
elections, to purely automatic ways, as when accessing a
presented by the subject; the Authenticator then creates
restricted web site. Authentication as an abstract func-
a proof of authentication which is assigned to the subject.
tion requires a core sequence of activities:
Even in the absence of any implementation, we can
define abstract threats in the ASP. These threats repre-
1. The subject requests to enter a system providing its sent violations of the semantic constraints of the applica-
identity and some proof of identity. tion. For the Abstract Authenticator we can have:
2. If the system, using its identity information, recog-
nizes the subject, it grants it entrance to the system
• T1. Present fake or stolen proof of identity, to let the
and creates for it a proof of authentication (token) for
attacker impersonate a legitimate subject and get
later use. If not, the request is denied.
access to the system.
• T2. Steal a proof of authentication for later attempts
Concrete realizations of this sequence may implement to enter the system.
these steps in different ways, but all must perform these • T3. Unauthorized reading of authentication informa-
two steps. Figure 1 is the class model of the Abstract tion to obtain a proof of identity.
Authenticator, which shows the classes used to perform • T4. Unauthorized modification of authentication
the activities above. Class Subject indicates the active information, to produce disruption.
entity that requests access to the system through some
<<actor>> : Authentication
: Authenticator
: Subject Info
request
Authentication verify (subject, proof)
(subject, proof)
OK
create
: Token
(subject)
assign
(token)
Fig. 2 Sequence diagram for the use case “authenticate a subject”
The threats to the Credential-based Authenticator

request include implementation-oriented versions of the abstract
Principal Authenticator
* Authent 1 threats; for example, using a stolen certificate, as well as
new threats like using expired credentials (Morrison and
<<create>>
Fernandez 2006).
1.. * 1 1 ASP‑based hierarchies

We can define hierarchies that show the concrete pat-
Validated Authentication terns that can be derived from ASPs. For example, Fig. 43
Credential
Credential Information
describes a hierarchy of authenticators. ASP-based hier-
Fig. 3 Class diagram of the credential-based authenticator pattern archies are a way to organize Security Solution Frames,
discussed in “Security patterns and security solution
frames” section. We show relationships between patterns
using pattern diagrams (Buschmann et al. 1996), where
rounded rectangles represent patterns and directed arcs
Authenticator indicate the contribution of a pattern to another pattern.
The patterns in these diagrams can have relationships
such as generalization and aggregation. A generalization
hierarchy can relate several patterns with the same con-
cern. The Credential-based Authentication is a concrete
security pattern derived from the Abstract Authentica-
Credential-based Password-based tor, as discussed earlier. Credential-based Authenticators
Authenticator Authenticator
use portable proofs of identity and include X.509 Cer-
tificates and SAML-based Authentication, among others.
The X.509 Authenticator (Fig. 5) requires an extra class
to describe the Certification Authority, while SAML-
based Authentication (Fig. 6) uses assertions and
X.509 SAML-based requires accessing a specific site for validation. The
Certificate Authenticator Password-based Authenticator uses a List of Passwords
Fig. 4 Pattern diagram for an authentication hierarchy
as Authentication Information (Fig. 7). We can deduce
some properties, using the Authenticator pattern as an
example.
• T5. Register a subject that has more privileges using The class models of the concrete patterns derived from
false information and then impersonate that subject. an ASP must include all the classes of the ASP from
which they were derived as well as classes that handle
Figure 3 shows the class model of a concrete type of new aspects required by the specific environment. There
Authenticator. The Credential-based Authenticator pat- may be new or modified attributes and operations in
tern includes the complete Abstract Authenticator func- the classes derived from the ASP. If Ci = set of classes in
tions where its classes are reinterpreted as: Principal ASPi, Cci = set of classes in a concrete pattern derived
corresponds to a responsible subject, Proof of Identity from ASPi, and Cnew = new classes in concrete pattern
becomes a Credential presented by the Principal, Proof Cci, we have: Cci = Ci ∪ Cnew. By “class” we mean the
of Authentication becomes a Validated Credential, and information in that class; the actual class may be split or
the Authentication Information is a procedure to validate merged with another class in the concrete levels but the
credentials (Fernandez 2013). For X.509 Certificates the application’s semantic information in the ASP must be
Certification Authority generates credentials, and the preserved.
Credential includes a set of Attributes that carry the sig- The context defines the environment where the pat-
nature of a Certification Authority, authenticate a sub- tern is valid and any conditions for its application; it is
ject, and maybe include authorization rights and other the main determinant of the difference of a pattern with
descriptions of the subject. Authentication is performed another in a hierarchy. In general, the context of a pattern
by the Authenticator using the certificate and confirming
the validity of the Certification Authority that issued the
credential. 3
This is a partial authentication hierarchy; there are many other ways to per-
form authentication.
request *
* Authent 1
<<create>>
1.. * 1 1 1
X.509 Validated Certification Certification
Certificate Certificate Info Authority
Fig. 5 Class model of the X.509-based authenticator
threats due to the extra elements in the class diagram

request (classes or attributes); that is Tj ⊇ Ti , where i precedes j
* Authent 1 in the hierarchy.
* The forces in a pattern define constraints on its solu-
tion indicating a tension that motivates the need for the
pattern. Forces are given names indicating which aspect
1.. * 1
they constrain. The following forces apply to the possible
1
solution of the Abstract Authenticator:
SAML Validated Certification
Assertion Assertion Info
• Closed system If the authentication information pre-
Fig. 6 Class model of the SAML-based authenticator sented by the user is not recognized, no access is
granted (Saltzer and Schroeder 1975). In an open
system, all subjects can have access except those who
are blacklisted for some reason. A closed system pro-
request vides a higher degree of security, but some systems
Subject Authenticator are open because of their objectives.
* Authent 1
• Registration Users must register their identity and
provide identity information to let the system recog-
<<create>> nize them later.
• Flexibility Large systems may have a variety of indi-
1 1 1 viduals or systems (users) who require access to the
Password Session Password system, as well as a variety of system units with dif-
List ferent access restrictions. We must be able to handle
this heterogeneity appropriately, or we risk security
Fig. 7 Class model of the password-based authenticator
exposures.
• Dependability We need to authenticate users in a
reliable and secure way. This means a robust pro-
(CL) subsumes the context of its descendants: CLi ⊇ CLj , tocol and a high degree of availability. Otherwise,
where i precedes (it is higher) j in the hierarchy. For users may deceive the authentication process or
example, the context of an Abstract Authenticator applies enter when the system authenticator is down.
to any domain while the context of a Credential-based • Protection of authentication information Users
Authenticator is valid only for distributed systems, and must not be able to read or modify the authen-
the context of an X.509 certificate applies only to distrib- tication information. Otherwise, they can give
uted systems that follow this standard. The threats of the themselves access to the system, simulate to be
concrete patterns are specific realizations of the abstract somebody else, or disrupt the access of legitimate
pattern’s threats using the changed context, or are new subjects.
• Simplicity The authentication process must be rela-

tively simple; otherwise, the users or administrators Security
may be confused. User errors are annoying to them, Solution
administrator errors may lead to security exposures. Frame
• Reach Successful authentication only gives access to
the system, not to any specific resource of the system.
Access to these resources must be controlled using 1..*
other mechanisms, typically authorization. Security 1
• Tamper freedom It should be very difficult to falsify Pattern ASP
the proof of identity presented by the user; otherwise Family
we can have impostors. Fig. 8 From SSFs to ASPs
• Cost There should be tradeoffs between security and
cost, higher security can be obtained at a higher cost.
• Performance (response time) Authentication should
Patterns in general are obtained by abstracting com-
not take a long time or users will be annoyed. How-
mon concepts of implementations found in real systems
ever, more secure authentication methods may take a
(best practices); ASPs can be obtained by abstracting the
longer time.
properties of several concrete patterns or directly from
• Frequency Subjects should not have to authenti-
the security constraints of several applications. There is
cate often. Frequent authentications waste time and
no algorithm to produce ASPs, abstraction is a human
annoy the users.
activity which depends on the experience and ability of
the pattern builder. Deciding what is really essential in
Note that there are no implementation aspects in these
an ASP is not always clear and judgment is necessary; for
forces, i.e., they describe security requirements for the
example, the first force of the Authenticator (closed sys-
solution that complement its conceptual class model. In
tem) may be interpreted to be a property (principle) of
fact, these forces apply to any system where access should
the system where it is used, and not of the pattern itself.
be restricted only to specific subjects. Concrete versions
of this pattern would add aspects related to their specific
context. For example, a Password-based Authenticator Relationships between ASPs and security solution
would add (among other forces): frames
Figure 4 shows authenticators related to each other by
• Strength A password must be hard to discover, even generalization, e.g. an X.509 certificate pattern “is a” cre-
for an attacker who has access to the password file dential pattern. As shown later, there can be directed
and high computational power. associations between ASPs that describe peer associa-
• Protection of Authentication Information The pass- tions between them. As discussed earlier, patterns can be
word file must not be accessible to the users. Other- associated also by aggregation (Rumbaugh et al. 1999),
wise, they could use powerful computers to discover where a pattern is composed of other patterns.
passwords by trial and error. An important use of ASPs is to identify and organize
• Validity There should be convenient ways to revoke SSFs. As indicated earlier, SSFs are solution structures
or invalidate registered passwords. that encapsulate and organize security patterns; they
realize security requirements. SSFs can facilitate the
The forces of the ASP may appear under more specific work of designers by collecting together all the relevant
forms in a concrete pattern, e.g., in the examples above, patterns to realize some security requirements, guiding
protection of authentication information takes specific the designer from an abstract conceptual level to a con-
forms. New forces can be introduced to consider a new crete implementation-oriented level. SSFs define hori-
context; in this example “Strength” is a new force, specific zontal and vertical pattern structures. As shown in Fig. 4,
to passwords (although it can be considered a special vertical structures are hierarchies of patterns specialized
case of tamper freedom). going from ASPs to technological implementations. Hor-
The reverse of what happens for contexts is true about izontal structures, security pattern families (SPFs), are
forces and consequences, the forces in concrete patterns sets of peer-related patterns that complement each other
include (maybe modified) those of the abstract pattern and define different aspects of a security policy. ASPs act
plus new forces (and their consequences) due to their as roots of these hierarchies and can be used to charac-
more specific environments. That is: Fj ⊇ Fi , where i pre- terize SSFs, where each lower level is a pattern special-
cedes j in the hierarchy. ized for some specific context (Fig. 8). For example, an
subjectIdentity logging Security

Authenticator Access Controller
Logger/
Auditor
Credential Password Reference

Authorizer
Authenticator Authenticator Monitor
X.509 Access
SAML RBAC
Certificate Matrix
Authenticator Authorizer
Authenticator Authorizer
Fig. 9 Combining SSFs
SSF for Authentication includes (among others) a family combines patterns where SSF.pi denotes pattern i in an
of Authenticator patterns, which includes Credential- SSF. SCs can be catalogued by defining a start SSF and
based Authenticator, Password-based Authenticator, and using it as index. Figure 10 (a group of pattern diagrams
others. If we add an Authorization/Access Control hier- representing SSFs) shows the construction of a Secu-
archy (as in Fig. 9), we would have an SSF, although Fig. 4 rity Cluster, SC1. To define SC1 the designer decided to
itself is also an SSF. Figure 9 relates an Authenticator use credentials as authentication artefact, then selected
SSF to an Access Controller SSF. The Access Controller attribute-based access control (ABAC), for securing
includes an Authorizer, which defines authorization rules its communications she chose the Advanced Encryp-
that may correspond to and Access Matrix or an RBAC tion Standard, a symmetric encryption algorithm, and
model. The Authorizer must be complemented with a finally used Distributed Logging. This specific selection
Reference Monitor (Fernandez 2013) to enforce the rules. was based on the analysis of the expected threats of this
We can draw an SSF in its own graph or draw sepa-
rate graphs for each level to correlate patterns from dif-
ferent families. The latter type of diagram is useful when
we want to understand a complete system; for example,
when building a banking application we can correlate Authencator Authorizer
all the security patterns needed to protect accounts (see
next section). A given security pattern can belong to
more than one family or to more than one SSF. Ref. (Uzu-
nov et al. 2015a) contains complete descriptions of two Distributed ABAC RBAC
SSFs: Authorization and Security Information Manage- Authencator
ment. Authorization includes three SPFs: Conceptual Encrypon
Authorization Model, Enforcement Architecture, and
Security Process. The Conceptual Authorization Model SC1
SSO Credenal
SPF includes one ASP: Abstract Authorization. The
Enforcement Architecture SPF includes the ASP Abstract Sym Asym
Authorization Architecture. The Security Information Security
Management SSF contains the Policy Management SPF, Logging
which in turn contains the ASP Abstract Policy Manager. AES
Reference (Uzunov and Fernandez 2021) contains SSFs
for secure communications.
A security cluster (SC) is a selection of patterns from Distributed
different SSFs (Fernandez and Yoshioka 2018). Formally: Logging
SCa = {SSFi.pa, SSFj.pb, SSFk.pc,…}, where cluster SCa Fig. 10 An SC definition (from 11)
Authorizer
Authenticator Access Control
Enforcer
authenticates controls
access access
Functional Entity
Access
RBAC Multilevel ABAC
Matrix
logs access
Security Logger
Fig. 11 Entity security services
application, obtained by the method described in “Secu- • Enforcer (Reference Monitor, Policy Enforcement
rity patterns and security solution frames” section. As Point) (Fernandez 2013). Enforces authorizations
we have shown elsewhere, we can map threats to secu- when a process requests access to an object. Done
rity patterns that can stop them (Fernandez 2013; Uzu- through an abstract process that intercepts all
nov et al. 2015b). In a catalog, each SC description should requests for resources from processes and deter-
include recommended applications or include analysis mines if they are authorized by some rule.
patterns where it would fit, as shown in Fig. 10. • Access matrix (Fernandez 2013). Describes authori-
zation rules where subjects are individual users or
systems.
ASPs in secure conceptual models • Role-Based Access Control (RBAC) (Fernandez 2013).
We show now how ASPs are useful to secure applica- Subjects are assigned rights based on their functions
tions by simplifying the work of the designer, who may or tasks in an environment in which there is a large
not have much experience on security. Figure 11 shows number of users or a large variety of resources.
how abstract patterns can provide security controls to a • Multilevel Security pattern (Fernandez 2013). Defines
functional entity (Gollmann 2011). Pattern Functional how to decide access in an environment with security
Entity represents some functional unit in a conceptual classifications for subjects and resources.
model of an application and its basic security services • Attribute-based access control (ABAC) (Priebe et al.
are described by patterns Authenticator, Access Con- 2004). Defines access to resources based on the
troller (showing some common authorization models), attributes of the subjects and the properties of the
and Security Logger. These patterns solve the problems objects.
described below. • Security Logger (Fernandez 2013). Logs all security-
sensitive actions performed by subjects (who did
• Authenticator (Fernandez 2013; Fernandez et al. what to what data and when) and provides controlled
2018). Controls access to the functional entity as a access to records for Audit purposes.
whole unit. We described this pattern in “Abstract
security patterns (ASPs)” section. It is not necessary to attach these controls to each func-
• Authorizer (Fernandez 2013). Describes who is tional entity; from the threat enumeration process we can
authorized to access specific resources in the func- determine which services are actually required to stop
tional entioty and how, in an environment in which the threats (Fernandez 2013). Regulations and institution
we have resources whose access needs to be con- policies may also require additional security mechanisms.
trolled. It indicates for each active entity, which In general, we must not add in each entity all possible
resources a subject can access, what it can do with security mechanisms, which results in systems that:
them, and under what conditions.
•Are overly complex, with many redundancies, which

bring administrative confusion, a source of possible
vulnerabilities.
IaaS Secure IaaS
•Have a high performance overhead, because of
redundant checks.
•Are costly, because most security mechanisms are Secure
COTS components, and they have to be bought and Open IaaS
Open Iaas
maintained.
There is also a basic difference between adding design Secure

patterns and adding security patterns to an applica- Open Stack
Open Stack
tion. Design patterns have no effect on the semantics of
the application; adding design patterns is optional and
is intended to improve some code aspect such as flex- Specific Secure Specific
ibility, performance, or extensibility. Adding security
Open Stack Open Stack
patterns, on the other hand, can make the application
more secure and unless we apply patterns to protect all Fig. 12 Deriving secure IaaS patterns
significant security vulnerabilities the application will
not be secure. Security is not based on local transfor-
mations as when using design patterns, but requires architecture required for the sharing of distributed vir-
a global transformation of the whole architecture. By tualized computational resources such as servers, stor-
showing the needed security mechanisms and when age, and networks, including a set of security services;
they are combined with SSFs, ASPs can simplify the the implementation of these services is open source
job of the designer who has now a guide to decide what and different architectures may have different security
security mechanisms are needed according to the pos- services. The Secure Open Stack describes the architec-
sible threats and what specific concrete patterns to use. ture required for the sharing of distributed virtualized
In this sense, they can effectively complement a secure computational resources such as servers, storage, and
development methodology (Fernandez 2013; Uzunov networks, including a set of security services; the imple-
et al. 2015b). mentation of these services is also open source and dif-
ferent architectures may have different security services
(OpenStack defines a standard that contains a set of
Deriving concrete patterns from ASPs
security services but specific implementations may have
We have written four patterns that can be used to dem-
additional security services). The Secure Concrete Open
onstrate the power of the ASP concept by showing the
Stack corresponds to a generic implementation of the
derivation of concrete patterns from some ASPs. One
standard. This example shows that from a generalization
of them (Fernandez et al. 2018) shows derivation of
hierarchy of functional patterns we can derive a corre-
Authenticators in the style of “Security patterns and
sponding hierarchy of security patterns. Finally, from a
security solution frames” section; starting from the
Secure Publish/Subscribe ASP we derived an IoT Secure
Authenticator ASP we derive the Credential-based
Publish/Subscribe which introduces new defenses to
Authenticator. Another (Fernandez et al. 2019), start-
control the new threats present in that context (Fernan-
ing from a Network Segmentation ASP derives a pattern
dez et al. 2020).
for IoT Segmentation, which partitions a network of IoT
devices and other entities into subnetworks in order to
isolate groups of devices and entities with different secu- Formalization of ASPs
rity requirements; IoT networks because of their het- Many pattern authors include UML models, that are
erogeneity have a large variety of threats different from semi-formal models, in the solution section of a pat-
standard IT threats. Another (Fernandez et al. 2016), tern. However, patterns are suggestions and this is not
describes the derivation of IaaS patterns in a cloud as a requirement, they are given as examples, not strict
shown in Fig. 12. The Secure Infrastructure-as-a-Service guidelines that the designer must follow. Requir-
pattern describes the architecture required for the sharing to follow the formalization of a pattern solution
ing of distributed virtualized computational resources would restrict the freedom of the designer when using
such as servers, storage, and networks, including a set the pattern in her applications; a formal description
of security services. The Secure Open IaaS describes the may constrain possible implementations or make
additional assumptions that may modify the intended

meaning of the pattern. Also, many developers do not
ASP
have enough background to understand formal mod-
els; in fact, some authors avoid even UML models to
make their patterns more usable. However, there are
several drawbacks to the informal representation of
patterns (Warmer and Kleppe 2003; Dong et al. 2007):
informal specifications may be ambiguous, and pat- P11 ... P1j
tern solutions may not be able to be expressed pre-
cisely in an informal language; a pattern may have
some particular properties that characterize it, and
the application of a pattern should maintain these
properties. More important, formal specifications
Pi1 ... Pik
allow the use of automated tools to check some prop-
erties; for example, object constraint language (OCL) Fig. 13 Metamodel for an ASP and its derived patterns
(Warmer and Kleppe 2003), allows querying the
model to find out new information. Formal specifica-
tions of patterns can be used to discover new patterns Another type of formalization is the use of ontologies;
or detect the use of patterns in large software systems. an ontology for security patterns is shown in Pereira-Vale
Even if a pattern requires tailoring, starting from a and Fernandez (2019). That ontology applies to ASPs,
precise description facilitates its selection, applica- since they are security patterns. In that model, OWL
tion, and implementation. allows queries like: “Obtain the list of concerns of the
A common option is to add formal constraints to the security patterns used in the lifecycle design stage for
UML diagram of its solution. As indicated, OCL can operating systems contexts.”
be used to define constraints on the data and to query Some researchers have formalized structural or syn-
this data. For example, the following could be a post- tactic properties of design patterns. Ref. (Le Guennec
condition that describes that a proof of authentication et al. 2000), proposed a set of modifications to the UML
is created if the subject ID and its authentication infor- 1.3 meta-model to make it possible to model design pat-
mation are found in the Authentication Information terns and represent their occurrences in UML, with the
class: objective of facilitating automatic processing of applica-
tions using patterns. Ref. (Hamid et al. 2016) provided
a formal representation and its associated validation
mechanisms for the verification of security properties
of security patterns. Ref. (Dong et al. 2007) presented a
formal specification for design patterns based on first-
order logic, temporal logic of action, and Prolog.
Table 1 Summary of ASPs structural formalization in OCL
The class models of the concrete patterns derived from an ASP must include all the classes of the ASP from which they were derived as well as
classes that handle new aspects. If Ci = set of classes in ASPi, Cci = set of classes in a concrete pattern derived from ASPi, and Cnew = new classes
in concrete pattern Cci, we have: Cci = Ci ∪ Cnew. In OCL:
context Cci
Cci:: = Ci- > union(Cnew)
The context of a pattern subsumes the context of its descendants: CLi ⊇ CLj , where i precedes (it is higher) j in the hierarchy. A CL defines a
domain of application (it includes a set of contextual attributes). However, the pattern context is not shown in the class model and OCL expres-
sions are not applicable
The threats of the concrete patterns are specific realizations of the ASP’s threats using the changed context, or are new threats due to the extra
elements in the class diagram (classes or attributes); that is, Tj ⊇ Ti , where i precedes j in the hierarchy and Ti is a list of the threats of pattern Pi.
Again, OCL constraints are not applicable because the threats are not shown in the class model of the pattern
The forces in concrete patterns include (maybe modified) those of the abstract pattern plus new forces due to their more specific environments.
If Fi is the list of forces of pattern Pi we have that: Fj ⊇ Fi , where i precedes j in the hierarchy. This relationship is also valid for the consequences of
ASP-based hierarchies.; that is, if CSi is the list of consequences of pattern Pi, we have: CSj ⊇ CSi if Pi precedes Pj in the hierarchy. OCL expressions
are not applicable
The related patterns in the derived patterns, RDj, include the related patterns of the ASP and those of the patterns above them in the hierarchy;
that is RDj ⊇ RDi
An invariant I in an ASP must be propagated to all its derived patterns, adjusting the variable names in the derived pattern classes. Each ASP has
its own invariants (see example above)
To formalize the structure of ASPs and their derived Pi is an abstract or concrete pattern that provides a
patterns we can use a semiformal approach, combin- solution composed by classes Ci in order to mitigate the
ing a metamodel with formal annotations (Washizaki corresponding security problem consisting of threats Ti,
et al. 2009b). Figure 13 shows a metamodel for ASPs when considering specific forces Fi in the context of CLi,
and their derived patterns (subpatterns). We first resulting in consequences CSi. Alternative or comple-
need to define what the UML operation of generali- mentary solutions are defined by RDi.
zation means for patterns. The UML security model Also, a pattern is more than its solution; the texts
in the pattern solution is a set of classes and asso- in its sections are very important guidelines for its
ciations; we can then define constraints among these correct application. Ref. (Maña et al. 2013) did a for-
classes. A subpattern must preserve those constraints malization of complete security patterns (not just
and may possibly add more. Considering Fig. 3, where their solutions), with the intention of enabling their
we have a concrete pattern derived from the pattern automatic handling. We try below to formalize all the
of Fig. 1, we can see that the derived pattern includes sections of the patterns; a set of assertions describe
all the classes of Fig. 1, renamed to indicate their dif- the sections of each pattern. A formal language like
ferent context. If we go down one more step in the OCL, Z, or Alloy could be used to describe each sec-
class hierarchy, we get Fig. 5 where there is a new tion more precisely, but we only use here standard
class. Note that the hierarchies starting from ASPs are set notation, where a tuple is indicated as (…), a set
generalization trees. as {}, optional elements as [], ID is a unique identifier
We summarize the formal aspects of ASPs in Table 1, assigned in a catalog for each pattern, SUD refers to
where the following definitions apply: C is the set of System Under Development. We first show the asser-
classes of a class model, CL is a set of contextual attrib- tions for ASPs and then assertions for their derived
utes, T is a set of threats, F is a set of forces, CSi is a set patterns. A derived pattern (DPattern) shows only its
of consequences, and RDi is the set of related patterns. changes with respect to the ASP.
Then, we may define a pattern Pi as follows
Pi = (CLi , Ti , Fi , Ci , CSi , RDi )
Evaluation of effectiveness e.g., web services or cloud computing. This was illus-
ASPs are abstract entities that can be implemented in trated in “Deriving concrete patterns from ASPs” sec-
many ways; this means they cannot be evaluated with tion.
respect to security or performance through experimen- • Can serve as abstract prototypes for existing concrete
tation or testing. Evaluating a specific implementation patterns and to verify they are complete with respect
would not say anything about the model if its secu- to functions and threat coverage. Starting from an
rity failed. As indicated above, patterns are suggestions abstract pattern it is easy to see what security con-
for designers, they do not require to be built exactly as straints (forces, threats) must at least be applied at
described; a designer can cut or add classes, rename a specific architectural level. For example, from an
classes and attributes, or split classes, as far as their ASP for VPNs we can derive TLS and IPSec VPNs
semantics are respected. The evaluation of ASPs must (Fernandez 2013). Other examples were shown in
be based on how well they represent the relevant con- “Relationships between ASPs and security solution
cepts of the systems they describe, how well they handle frames” section. The formalization section can help
abstract threats, how complete they are, how precise they building those patterns.
are, how they can be applied to the design or evaluation • Can serve as ways to connect and relate different
of systems, and how useful they are for other relevant families of patterns. For example, a Communica-
functions. tion Channel can use Intrusion Detection (see “ASP-
From the cases of ““ASP-based hierarchies”– “Deriving based hierarchies” and “Relationships between ASPs
concrete patterns from ASPs” sections, and our experi- and security solution frames” sections). If we build
ence, we have found the following uses of ASPs: a fairly extensive catalog of Security Clusters we can
simplify the work of developers.
• ASPs can be combined with other ASPs to cover all the • We can build Domain models and/or Security Refer-
security concerns of an application, including all their ence Architectures using ASPs. As indicated, DMs and
architectural levels if we use SSFs. In this way, they SRAs are also abstract architectures.
can be applied during the stages of a secure systems • ASPs are a good basis to separate and classify distinct
development methodology such as ASE (Uzunov patterns (Washizaki et al. 2009a). Pattern catalogs
et al. 2015b) or similar. ASPs can also be combined usually include several varieties of the same security
with patterns describing security principles or good pattern, perhaps with different names; ASPs can help
general design principles. For example, the Abstract recognize similar patterns.
Authorizer can be combined with Need-to-Know • IoT patterns are often variations of more general pat-
(Fernandez et al. 2011) to assign rights according terns. When classifying IoT patterns, ASPs help to
to the needs of the subjects; Single Point of Access establish the difference between ASPs and IoT pat-
(Yoder and Barcalow 2000) can be combined with terns, and we can concentrate in finding the changes
Firewall (Saltzer and Schroeder 1975), to restrict the needed in the pattern description due to the specific
placement of firewalls in a network. environment without having to redefine its core
• Can be used to check for security coverage in a com- structure, as we have shown in some examples (Fer-
plete design One of the problems with protecting nandez et al. 2020). This helps also with the problem
complex systems is that it is hard for the designers to of the variety of IoT pattern descriptions found in the
see if all the high-level security threats have been cov- literature (Washizaki et al. 2021).
ered with the applied defenses. This is much easier • Several methodologies that claim to apply “security
when we work at the application level, we can enu- by design”, e.g., Microsoft Security Development Life-
merate all threats and find the corresponding secu- cycle (Howard 2006), start from the system architec-
rity patterns to defend against them; using SSFs we ture, ignoring threats to applications. ASPs empha-
can propagate the defenses to the lower levels. This size the need to start earlier to consider the needs of
explicit handling of threats also allows evaluation of applications; this will result in more secure systems
the security degree reached by the design (Villagran- because methods that start from lower levels ignore
Velasco et al. 2020), a security measure is the number higher-level threats.
of threats covered by the security patterns present in • The forces in ASPs can become security policies for
the design. the derived patterns, thus contributing to make them
• Can guide the search for new patterns (pattern min- more secure.
ing) An abstract pattern defines a range of patterns • ASPs can simplify the job of the designer who has
and one can see if corresponding patterns exist at all now a guide to decide what security mechanisms are
the lower levels, including different environments, needed according to the possible threats and what
specific concrete patterns to use. In this sense, they thus they can also express application constraints. ASPs
can effectively complement a secure development are more detailed than those patterns and are very
methodology (Fernandez 2013; Uzunov et al. 2015b). close in style to standard patterns as those in (Fernan-
• An advantage of standard patterns, and also of dez 2013, Gamma et al. 1994); after defining them in
ASPs, is that they are seamless with respect to life- the analysis stage their transition to design is straight-
cycle approaches such as the rational unified process forward: the design stage just needs to refine them and
(RUP) (Rumbaugh et al. 1999), and use similar nota- express them in terms of software artifacts, something
tion and concepts, which facilitate their use in prac- not easy to do with patterns using different styles.
tice.
• Security usability patterns can complement ASPs
by defining interface requirements to make patterns Conclusions and future work
clearer and easier to use; ASPs can be combined with We have elaborated and characterized the concept
interface patterns (Brambilla et al. 2017). of ASP, introduced by us in earlier work (Fernandez
• We have used ASPs in our own research. In (Fernan- et al. 2008, 2014). We have shown their possible uses
dez et al. 2021, Washizaki et al. 2021), ASPs provided to prove that they have several potential advantages,
a convenient way to classify IoT patterns; in (Uzunov including providing insight into the nature of security
et al. 2015b), they are used to embody a subset of patterns, helping define the early stages of a method-
the early security requirements in a secure software ology to build secure systems, for pattern mining, and
development methodology; in (Villagran-Velasco to build SRAs, among others (Fernandez 2015). To real-
et al. 2020) they were used to evaluate the degree of ize their advantages, we need a good catalog of ASPs
security reached by a secure software methodology that can be used by designers to define secure concep-
using patterns. tual models that address crosscutting concerns. We
already have a good number of ASPs, but we need to
collect them in a specialized catalog of SSFs organ-
Related work and discussion ized according to ASPs; this catalog would be useful to
As indicated earlier, the concept of abstract pattern is help designers satisfy security requirements. This is an
present in the original patterns of the GOF (Gamma et al. important future work.
1994), but they did not develop their possibilities because As indicated earlier, there is no automatic way to build
they were not concerned with the analysis stage, they ASPs. It takes experience and abstraction ability to build
were trying to improve code. them. Pattern builders build catalogs and designers use the
Other varieties of security patterns intended to empha- catalogs to build systems. We have shown two formaliza-
size abstract properties include: tions of ASPs, but specific applications and extensions of
this formalization are left for future work. Combining ASPs
• Jackson’s Problem Frames (Jackson 2001), have been with SSFs and with a systematic methodology such as ASE
used to define patterns for security requirements (Uzunov et al. 2015b) we believe we have a powerful tool to
(Hatebur et al. 2007). build secure applications. We have started exploring their
• Mouratidis uses Secure Tropos, an approach to sup- use to build IoT applications (Fernandez et al. 2021).
port multiple views of security, including organiza- Acknowledgements
tional and external aspects (Mouratidis et al. 2006). We thank the National Institute of Informatics (NII) of Japan for supporting the
visits of E. B. Fernandez and J. Yoder to Tokyo. The CIbSE 2014 and the Cyberse-
curity referees provided useful comments that helped improve this paper.
The approaches based on problem frames have in com-
mon with ASPs that they emphasize the core security Authors’ contributions
EF proposed the main idea, wrote the paper, and supervised the structure of
requirements of the system. However, their patterns use the paper. NY provided ideas, made corrections, and organized discussion
a totally different style, they do not follow the standard meetings. HW provided ideas, references, and helped with the formalization.
pattern structure and use different concepts and nota- JY proofread the paper. All the authors participated in discussions to define
and refine the results of the paper. All the authors have read and approved of
tion. As indicated, an important advantage of standard this content.
patterns and also of ASPs is that they are seamless with
respect to lifecycle approaches such as the rational uni- Funding
This work received no external funding, but the National Institute of Informat-
fied process (RUP) (Rumbaugh et al. 1999), and use simi- ics of Japan funded the trip of the first and fourth authors to Tokyo to partici-
lar notation and concepts, which facilitate their use in pate in meetings where the idea of this paper was developed.
practice.
Availability of data and materials
The patterns in (Moral-García et al. 2014) describe Not applicable.
enterprise activities and their security constraints and
Declarations Gollmann D (2011) Computer security, 3rd edn. Wiley, New York
Hamid B, Gürgens S, Fuchs A (2016) Security patterns modeling and formaliza-
Competing interests tion for pattern-based development of secure software systems. Innov
The authors declare no competing interests. Syst Softw Eng 12:109–140. https://doi.org/10.1007/s11334-015-0259-1
Hatebur D, Heisel M, Schmidt H (2007) A pattern system for security require-
Author details ments engineering. In: Proceedings of ARES, pp 356–365
1
Department of Electrical Engineering and Computer Science, Florida Atlantic Howard M (2006) The security development lifecycle: SDL: a process for
University, Boca Raton, FL, USA. 2 GRACE Center, National Institute of Informat- developing demonstrably more secure software, 1st edn. Microsoft Press,
ics, Tokyo, Japan. 3 Waseda University, Tokyo, Japan. 4 The Refactory, Inc, Urbana, Redmond
IL, USA. Jackson M (2001) Problem frames: analyzing & structuring software develop-
ment problems. Addison-Wesley, Reading
Received: 22 July 2021 Accepted: 6 January 2022 Le Guennec A, Sunyé G, Jézéquel J-M (2000) Precise modeling of design pat-
terns. In: International conference on the unified modeling language, pp
482–496
Maña A, Fernandez EB, Ruiz J, Rudolph C (2013) Towards computer-based
security patterns. In: 20th Conference on pattern languages of programs
References (PLoP)
Avgeriou P (2003) Describing, instantiating and evaluating a reference archi- Moral-García S, Moral-Rubio S, Rosado DG, Fernández EB, Fernández-Medina
tecture: a case study. Enterp Archit J 342:1–24 E (2014) Enterprise security pattern: a new type of security pattern. Secur
Blakeley B, Heath C (2004) Members of the open group security forum: techni- Commun Netw (wiley) 7(11):1670–1690. https://doi.org/10.1002/sec.863
cal guide: security design patterns. The Open Group, London http:// Morrison P, Fernandez EB (2006) The credential pattern. In: Proceedings of the
www.opengroup.org/bookstore/catalog/g031.htm. conference on pattern languages of programs, PLoP 2006, Portland, OR.
Brambilla M et al (2017) “Model-driven development of user interfaces for IoT http://hillside.net/plop/2006/
systems via domain-specific components and patterns. J Internet Serv Mouratidis H, Weiss M, Georgini P (2006) Modelling secure systems using an
Appl 8(1):1–21 agent-oriented approach and security patterns. Int J Soft Eng Knowl Eng
Buschmann F, Meunier R, Rohnert H, Sommerland P, Stal M (1996) Pattern- ori- 16(3):471–498
ented software architecture. Wiley, New York Pereira-Vale A, Fernandez EB (2019) An ontology for security patterns. In: 38th
Dong J, Alencar P, Cowan D (2007) Formal specification and verification of International conference of the chilean computer science society (SCCC
design patterns, chapter 5. In: Taibi T (ed.) Design pattern formalization 2019), Concepción—Chile. November 4–8
techniques. IGI Publishing, pp 94–108 Polya G (1957) How to solve it, 2nd edn. Doubleday Anchor Books, New York
Fernandez EB (2013) Security patterns in practice: building secure architec- Priebe T, Fernandez EB, Mehlau JI, Pernul G (2004) A pattern system for access
tures using software patterns. Wiley series on software design patterns. control. In: Research directions in data and applications security XVIII,
Wiley, New York Farkas C, Samarati P (Eds.) Proceedings of the 18th annual IFIP WG 11.3
Fernandez EB, Yoshioka N (2018) Using a variety of patterns in a secure working conference on da-ta and applications security, Sitges, Spain, July
software development methodology. In: Proceedings 25th Asia-Pacific 25–28
software engineering conference, Nara, Japan Rumbaugh J, Jacobson I, Booch G (1999) The unified modeling language refer-
Fernandez EB, Washizaki H, Yoshioka N (2008) Abstract security patterns. In: ence manual. Addison-Wesley, Boston
Position paper in Proceedings of the 2nd workshop on software patterns Saltzer J, Schroeder M (1975) The protection of information in computer
and quality (SPAQu’08), in conjunction with the 15th conference on pat- systems. Proc IEEE 63(9):1278–1308
tern languages of programs (PLoP 2008), October 18–20, Nashville, TN Schumacher M, Fernandez EB, Hybertson D, Buschmann F, Sommerlad P
Fernandez EB, Mujica S, Valenzuela f (2011) Two security patterns: least privi- (2006) Security patterns: integrating security and systems engineering.
lege and security logger/auditor. In: Proceedings of Asian PLoP. http:// Wiley, New York
patterns-wg.fuka.info.waseda.ac.jp/asianplop/proceedings2011/asian Song Z, Li Z, Dou W (2003) Different approaches for the formal defini-
plop2011_submission_7.pdf tion of authentication property. In: 9th Asia-Pacific conference on
Fernandez EB, Yoshioka N, Washizaki H, Yoder J (2014) Abstract security pat- communications
terns for requirements specification and analysis of secure systems. In: Steel C, Nagappan R, Lai R (2005) Core security patterns: best strategies for
Proceedings of the WER 2014 conference, a track of the 17th Ibero-Amer- J2EE, web services, and identity management. Prentice Hall, Upper Sad-
ican conference on software engineering (CIbSE 2014), Pucon, Chile dle River
Fernandez EB, Monge R, Hashizume K (2015) Building a security reference Taylor RN, Medvidovic N, Dashofy N (2010) Software architecture: foundation,
architecture for cloud systems. Requir Eng. https://doi.org/10.1007/ theory, and practice. Wiley, New York
s00766-014-0218-7 Uzunov AV, Fernandez EB (2021) Cryptography-based security patterns and
Fernandez EB, Washizaki H, Yoshioka N (2016) Patterns for secure cloud IaaS. In: security solution frames for networked and distributed systems. Submit-
5th Asian conference on pattern languages of programs (AsianPLoP) ted for publication (available from the authors)
Fernandez EB, Yoshioka N, Washizaki H (2018) An abstract security pattern for Uzunov A, Fernandez EB, Falkner K (2015a) Security solution frames and
Authentication and a derived concrete pattern, the Credential-based security patterns for authorization in distributed, collaborative systems.
Authentication. In: Asian pattern languages of programs conference Comput Secur 55:193–234. https://doi.org/10.1016/j.cose.2015.08.003
(AsianPLoP) Uzunov A, Fernandez EB, Falkner K (2015b) ASE: a comprehensive pattern-
Fernandez EB, Yoshioka N, Washizaki H (2019) Abstract and IoT security pat- driven security methodology for distributed systems. J Comput Stand
terns for network segmentation. In: Proceedings of the 8th Asian confer- Interfaces 41:112–137. https://doi.org/10.1016/j.csi.2015.02
ence on pattern languages of programs (Asian PLoP) van Heesch U, Hezavehi SM, Avgeriou P (2011) Combining architectural pat-
Fernandez EB, Yoshioka N, Washizaki H (2020) Secure distributed publish/sub- terns and software technologies in one design language. In: Proceedings
scribe (P/S) pattern for IoT. AsianPLoP of the 16th European conference on pattern languages of programs
Fernandez EB, Washizaki H, Yoshioka N, Okubo T (2021) The design of secure (EuroPLoP)
IoT applications using patterns: State of the art and directions for Villagran-Velasco O, Fernandez EB, Ortega-Arjona J (2020) Refining the evalua-
research. Internet Things 15:100408. https://doi.org/10.1016/j.iot.2021. tion of the degree of security of a system built using security patterns. In:
100408 Proceedings 15th international conference on availability, reliability and
Fowler M (1997) Analysis patterns—reusable object models. Addison-Wesley, security (ARES 2020), Dublin, Ireland
Reading Warmer J, Kleppe A (2003) The object constraint language, 2nd edn. Addison-
Gamma E, Helm R, Johnson R, Vlissides J (1994) Design patterns—elements of Wesley, Reading
reusable object-oriented software. Addison-Wesley, Reading Washizaki H, Fernandez EB, Maruyama K, Kubo A, Yoshioka N (2009a)
Improving the classification of security patterns. In: Proceedings 20th
international workshop on database and expert systems application, pp

165–170
Washizaki H, Fernandez EB, Maruyama K, Kubo A, Yoshioka N (2009b) Improv-
ing the classification of security patterns. In: 20th International workshop
on database and expert systems application, pp 165–170
Washizaki H, Hazeyama A, Okubo T, Kanuka H, Ogata S, Yoshioka N (2021)
Analysis of IoT pattern descriptions. In: SERP4IoT
Yoder J, Barcalow J (2000) Architectural patterns for enabling application
security. In: Harrison N, Foote B, Rohnert H (eds.) Proceedings PLOP’97,
Also, Chapter 15 in pattern languages of program design, vol 4.
Addison-Wesley
Publisher’s Note
Springer Nature remains neutral with regard to jurisdictional claims in pub-
lished maps and institutional affiliations.
Unified Threat Management (UTM) provides multiple security features and services in a single
device or service on the network, protecting users from security threats in a simplified way.
UTM includes functions such as antivirus, antispam, content filtering, and web filtering. UTM
secures the network from viruses, malware, or malicious attachments by scanning the incoming
data using Deep Packet Inspection and prevents access to unwanted websites by installing
Enhanced Web filtering. For more information, see the following topics:
Unified Threat Management Overview

Unified Threat Management (UTM) is a term used to describe the consolidation of several
security features into one device, protecting against multiple threat types. The advantage of
UTM is streamlined installation and management of these multiple security capabilities.
The security features provided as part of the UTM solution are:
 Antispam Filtering— E-mail spam consists of unwanted e-mail messages, usually sent
by commercial, malicious, or fraudulent entities. The antispam feature examines
transmitted e-mail messages to identify e-mail spam. When the device detects an e-mail
message deemed to be spam, it either drops the message or tags the message header or
subject field with a preprogrammed string. The antispam feature uses a constantly
updated spam block list (SBL). Sophos updates and maintains the IP-based SBL. The
antispam feature is a separately licensed subscription service.
 Content Filtering— Content filtering blocks or permits certain types of traffic based
on the MIME type, file extension, protocol command, and embedded object type.
Content filtering does not require a separate license.
 Web Filtering— Web filtering lets you manage Internet usage by preventing access to
inappropriate Web content. There are three types of Web filtering solutions. The
integrated Web filtering solution, the decision-making for blocking or permitting Web
access is done on the device after it identifies the category for a URL either from user-
defined categories or from a category server (Websense provides the CPA Server). The
integrated Web filtering feature is a separately licensed subscription service which is
supported only on SRX Series devices. The redirect Web filtering solution intercepts
HTTP requests and forwards the server URL to an external URL filtering server
provided by Websense to determine whether to block or permit the requested Web
access. Redirect Web filtering does not require a separate license. With Juniper Local
Web Filtering, the decision-making for blocking or permitting Web access is done on
the device after it identifies the category for a URL from user-defined categories stored
on the device. With Local filtering, there is no additional Juniper license or remote
category server required.
 Starting with Junos OS Release 15.1X49-D60 and Junos OS Release 17.3R1, on
SRX1500 Services Gateways and vSRX instances, UTM policies, profiles, MIME
patterns, filename extensions, and protocol-command numbers are increased to 500;
custom URL patterns and custom URL categories are increased to 1000.
Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, SRX4100
and SRX4200 devices support up to 500 UTM policies, profiles, MIME patterns,
filename extensions, and protocol commands, and up to 1000 custom URL patterns and
custom URL categories.
Starting with Junos OS Release 18.2R1, NFX150 devices support up to 500 UTM
policies, profiles, MIME patterns, filename extensions, and protocol commands, and
up to 1000 custom URL patterns and custom URL categories.
Starting with Junos OS Release 18.2R1, the following commands under the [edit
security utm feature-profile] hierarchy level are deprecated:
o set web-filtering type

o set web-filtering url-blacklist
o set web-filtering url-whitelist
o set web-filtering http-persist
o set web-filtering http-reassemble
o set web-filtering traceoptions
o set web-filtering juniper-enhanced cache
o set web-filtering juniper-enhanced reputation
o set web-filtering juniper-enhanced query-type
o set anti-virus mime-whitelist
o set anti-virus url-whitelist
o set anti-virus type
o set anti-virus traceoptions
o set anti-virus sophos-engine
o set anti-spam address-blacklist
o set anti-spam address-whitelist
o set anti-spam traceoptions
o set content-filtering traceoptions
Starting with Junos OS Release 18.4R3, on SRX1500, SRX4100, SRX4200, SRX4600,

SRX4800, SRX5400, SRX5600, and SRX5800 devices, UTM policies, profiles, MIME
patterns, filename extensions, protocol commands, and custom messages, are increased
up to 1500. Custom URL patterns and custom URL categories are increased up to 3000.
This feature requires a license. To understand more about UTM Licensing, see,
Understanding UTM Licensing. Please refer to the Juniper Licensing Guide for general
information about License Management. Please refer to the product Data Sheets at SRX
Series Services Gateways for details, or contact your Juniper Account Team or Juniper
Partner.
 Antivirus— The Avira antivirus module in the unified threat management (UTM)
solution consists of a virus pattern database, an application proxy, a scan manager, and
a configurable scan engine. The antivirus module on the SRX Series device scans
specific application layer traffic to protect the user from virus attacks and to prevent
viruses from spreading.
Understanding UTM Custom Objects
Before you can configure most UTM features, you must first configure the custom objects for
the feature in question. Custom objects are global parameters for UTM features. This means
that configured custom objects can be applied to all UTM policies where applicable, rather than
only to individual policies.
The following UTM features make use of certain custom objects:
 Web Filtering (see Example: Configuring Integrated Web Filtering)

 Anti-Spam (see Server-Based Antispam Filtering Configuration Overview)
 Content Filtering (see Content Filtering Configuration Overview)
Starting in Junos OS Release 18.2R1, a new dynamic application policy match condition is
added to SRX Series devices, allowing an administrator to more effectively control the
behavior of Layer 7 applications. To accommodate Layer 7 application-based policies in UTM,
the [edit security utm default-configuration] hierarchy level is introduced. If any
parameter in a specific UTM feature profile configuration is not configured, then the
corresponding parameter from the UTM default configuration is applied. Additionally, during
the initial policy lookup phase which occurs prior to a dynamic application being identified, if
there are multiple policies present in the potential policy list which contains different UTM
profiles, the SRX Series device applies the default UTM profile until a more explicit match has
occurred.
Junos® OS
Unified Threat Management User Guide
Published
2022-09-08
ii
Juniper Networks, Inc.

1133 Innovation Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. All other trademarks, service marks, registered marks, or registered service
marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right
to change, modify, transfer, or otherwise revise this publication without notice.
Junos® OS Unified Threat Management User Guide

Copyright © 2022 Juniper Networks, Inc. All rights reserved.
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related
limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use
with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License
Agreement ("EULA") posted at https://support.juniper.net/support/eula/. By downloading, installing or using such
software, you agree to the terms and conditions of that EULA.
iii
Table of Contents
About This Guide | xxiii
1 Overview
UTM Overview | 2
Unified Threat Management Overview | 2
UTM Supported Features | 6
WELF Logging for UTM Features | 6
Understanding WELF Logging for UTM Features | 7
Example: Configuring WELF Logging for UTM Features | 8
Explicit Proxy for UTM | 12
Understanding Explicit Proxy | 12
Configuring the Explicit Proxy on Juniper Enhanced Server | 13
Verifying the Explicit Proxy Configuration on Juniper Enhanced Server | 15
Configuring the Predefined Category Upgrading and Base Filter Configuration Using Explicit
Proxy | 15
Verifying the Predefined Category Upgrading and Base Filter Configuration | 17
Configuring the Sophos Antivirus Pattern Update | 18
Verifying the Sophos Antivirus Pattern Update | 19
Unified Policies for UTM | 20
Understanding Unified Policies [Unified Threat Management (UTM)] | 20
UTM Support for Chassis Cluster | 22
Understanding UTM Support for Active/Active Chassis Cluster | 22
Understanding UTM Support for Active/Backup Chassis Cluster | 23
Allowlist | 24
Understanding MIME Allowlist | 24
Example: Configuring MIME Allowlist to Bypass Antivirus Scanning | 25
Understanding URL Allowlist | 27
Configuring URL Allowlist to Bypass Antivirus Scanning (CLI Procedure) | 27
2 Antivirus Protection
iv
On-Device Avira Antivirus | 29
Avira Antivirus Overview | 29
Example: Configure Avira Antivirus | 31
Requirements | 32
Overview | 32
Configuration | 33
Verification | 44
Sophos Antivirus Protection | 46
Sophos Antivirus Protection Overview | 47
Sophos Antivirus Features | 48
Understanding Sophos Antivirus Data File Update | 49
Comparison of Sophos Antivirus to Kaspersky Antivirus | 50
Sophos Antivirus Configuration Overview | 51
Example: Configuring Sophos Antivirus Custom Objects | 51
Requirements | 51
Overview | 52
Configuration | 52
Verification | 55
Example: Configuring Sophos Antivirus Feature Profile | 55
Requirements | 56
Overview | 56
Configuration | 56
Verification | 63
Example: Configuring Sophos Antivirus UTM Policies | 64
Requirements | 64
Overview | 64
Configuration | 65
Verification | 66
Example: Configuring Sophos Antivirus Firewall Security Policies | 67
Requirements | 67
Overview | 67
v
Configuration | 67
Verification | 69
Example: Configuring Sophos Antivirus Scanner with SSL Forward Proxy | 70
Requirements | 70
Overview | 71
Configuration | 71
Verification | 75
Managing Sophos Antivirus Data Files | 80
Virus-Detected Notifications | 82
Understanding Protocol-Only Virus-Detected Notifications | 83
Configuring Protocol-Only Virus-Detected Notifications (CLI Procedure) | 83
Understanding E-Mail Virus-Detected Notifications | 83
Configuring E-Mail Virus-Detected Notifications (CLI Procedure) | 84
Understanding Custom Message Virus-Detected Notifications | 85
Configuring Custom Message Virus-Detected Notifications (CLI Procedure) | 85
HTTP Trickling to Prevent Timeouts | 87
Understanding HTTP Trickling | 87
Configuring HTTP Trickling to Prevent Timeouts During Antivirus Scanning (CLI Procedure) | 88
3 Antispam Filtering
Antispam Filtering Overview | 90
Server-Based Antispam Filtering | 92
Understanding Server-Based Antispam Filtering | 92
Server-Based Antispam Filtering Configuration Overview | 93
Example: Configuring Server-Based Antispam Filtering | 94
Requirements | 95
Overview | 95
Configuration | 95
Verification | 101
vi
Local-List Antispam Filtering | 102
Understanding Local List Antispam Filtering | 103
Local List Antispam Filtering Configuration Overview | 103
Example: Configuring Local List Antispam Filtering | 104
Requirements | 104
Overview | 105
Configuration | 105
Verification | 111
4 Content Filtering
Content Filtering | 114
Content Filtering Overview | 114
Understanding Content Filtering Protocol Support | 118
Specifying Content Filtering Protocols (CLI Procedure) | 120
Content Filtering Configuration Overview | 121
Example: Configuring Content Filtering Custom Objects | 122
Requirements | 122
Overview | 122
Configuration | 122
Verification | 125
Example: Configuring Content Filtering UTM Policies | 126
Requirements | 126
Overview | 126
Configuration | 127
Verification | 128
Example: Attaching Content Filtering UTM Policies to Security Policies | 128
Requirements | 129
Overview | 129
Configuration | 129
Verification | 131
Monitoring Content Filtering Configurations | 132

vii
5 Web Filtering
Web Filtering Overview | 135
Enhanced Web Filtering | 137
Enhanced Web Filtering Overview | 137
Understanding the Enhanced Web Filtering Process | 139
Predefined Category Upgrading and Base Filter Configuration Overview | 147
Example: Configuring Enhanced Web Filtering | 149
Requirements | 150
Overview | 150
Configuration | 152
Verification | 164
Understanding the Quarantine Action for Enhanced Web Filtering | 167
Example: Configuring Site Reputation Action for Enhanced Web Filtering | 170
Requirements | 170
Overview | 170
Configuration | 171
Verification | 175
TAP Mode Support Overview for UTM | 179
Local Web Filtering | 182
Understanding Local Web Filtering | 182
Example: Configuring Local Web Filtering | 185
Requirements | 186
Overview | 186
Configuration | 188
Verification | 197
Redirect Web Filtering | 199
Understanding Redirect Web Filtering | 200
Example: Enhancing Security by Configuring Redirect Web Filtering Using Custom Objects | 202
Requirements | 202
Overview | 202
viii
Configuration | 203
Verification | 212
Safe Search Enhancement for Web Filtering | 216
Safe Search Enhancement for Web Filtering Overview | 216
Configure Web Filtering with Safe Search | 219
Requirements | 219
Overview | 220
Configuration | 220
Verification | 225
Monitoring Web Filtering Configurations | 226
UTM Support for SRX100, SRX110, SRX210, SRX240, SRX550, SRX650,

6 and SRX1400 Devices
Express Antivirus Protection | 230
Express Antivirus Protection Overview | 230
Express Antivirus Configuration Overview | 233
Example: Configuring Express Antivirus Custom Objects | 234
Requirements | 234
Overview | 234
Configuration | 235
Verification | 237
Configuring Express Antivirus Custom Objects (J-Web Procedure) | 237
Example: Configuring Express Antivirus Feature Profiles | 240
Requirements | 240
Overview | 240
Configuration | 241
Verification | 246
Configuring Express Antivirus Feature Profiles (J-Web Procedure) | 247
Example: Configuring Express Antivirus UTM Policies | 249
Requirements | 249
Overview | 249
ix
Configuration | 250
Verification | 250
Configuring Express Antivirus UTM Policies (J-Web Procedure) | 251
Example: Attaching Express Antivirus UTM Policies to Security Policies | 251
Requirements | 252
Overview | 252
Configuration | 252
Verification | 253
Attaching Express Antivirus UTM Policies to Security Policies (J-Web Procedure) | 254
Express Antivirus Pattern Updates | 256
Understanding Express Antivirus Scanner Pattern Updates | 256
Example: Automatically Updating Express Antivirus Patterns | 257
Requirements | 257
Overview | 258
Configuration | 258
Verification | 258
Example: Automatically Updating Express Antivirus Patterns (J-Web Procedure) | 259
Manually Updating, Reloading, and Deleting Express Antivirus Patterns (CLI Procedure) | 259
Full Antivirus Protection | 260
Full Antivirus Protection Overview | 261
Full Antivirus Configuration Overview | 262
Example: Configuring Full Antivirus Custom Objects | 263
Requirements | 264
Overview | 264
Configuration | 264
Verification | 267
Configuring Full Antivirus Custom Objects (J-Web Procedure) | 268
Example: Configuring Full Antivirus Feature Profiles | 271
Requirements | 271
Overview | 271
x
Configuration | 273
Verification | 278
Configuring Full Antivirus Feature Profiles (J-Web Procedure) | 279
Example: Configuring Full Antivirus UTM Policies | 281
Requirements | 282
Overview | 282
Configuration | 282
Verification | 283
Configuring Full Antivirus UTM Policies (J-Web Procedure) | 283
Example: Attaching Full Antivirus UTM Policies to Security Policies | 284
Requirements | 284
Overview | 284
Configuration | 285
Verification | 286
Attaching Full Antivirus UTM Policies to Security Policies (J-Web Procedure) | 286
Full Antivirus Pattern Updates | 288
Understanding Full Antivirus Pattern Updates | 288
Example: Configuring the Full Antivirus Pattern Update Server | 289
Requirements | 290
Overview | 290
Configuration | 290
Verification | 291
Full Antivirus Pattern Update Configuration Overview | 291
Example: Automatically Updating Full Antivirus Patterns | 292
Requirements | 293
Overview | 293
Configuration | 293
Verification | 294
Example: Automatically Updating Full Antivirus Patterns (J-Web Procedure) | 294
Manually Updating, Reloading, and Deleting Full Antivirus Patterns (CLI Procedure) | 295
xi
Full Antivirus File Scanning | 297
Understanding the Full Antivirus Scan Engine | 297
Understanding Full Antivirus Scan Mode Support | 298
Configuring Full Antivirus File Extension Scanning (CLI Procedure) | 299
Example: Configuring Full Antivirus File Extension Scanning | 300
Requirements | 300
Overview | 300
Configuration | 301
Verification | 302
Understanding Full Antivirus Scan Level Settings | 302
Example: Configuring Full Antivirus Scan Settings at Different Levels | 303
Requirements | 303
Overview | 303
Configuration | 304
Verification | 305
Understanding Full Antivirus Intelligent Prescreening | 306
Example: Configuring Full Antivirus Intelligent Prescreening | 306
Requirements | 307
Overview | 307
Configuration | 307
Verification | 308
Understanding Full Antivirus Content Size Limits | 309
Configuring Full Antivirus Content Size Limits (CLI Procedure) | 309
Understanding Full Antivirus Decompression Layer Limits | 309
Configuring Full Antivirus Decompression Layer Limits (CLI Procedure) | 310
Understanding Full Antivirus Scanning Timeouts | 311
Configuring Full Antivirus Scanning Timeouts (CLI Procedure) | 311
Understanding Full Antivirus Scan Session Throttling | 311
Configuring Full Antivirus Scan Session Throttling (CLI Procedure) | 312

xii
Full Antivirus Scan Results and Fallback Options | 314
Understanding Full Antivirus Scan Result Handling | 314
Monitoring Antivirus Scan Engine Status | 315
Monitoring Antivirus Session Status | 316
Monitoring Antivirus Scan Results | 317
Understanding Antivirus Scanning Fallback Options | 320
Example: Configuring Antivirus Scanning Fallback Options | 321
Requirements | 322
Overview | 322
Configuration | 322
Verification | 325
Full Antivirus Application Protocol Scanning | 326
Understanding Full Antivirus Application Protocol Scanning | 327
Understanding HTTP Scanning | 328
Enabling HTTP Scanning (CLI Procedure) | 329
Understanding FTP Antivirus Scanning | 329
Enabling FTP Antivirus Scanning (CLI Procedure) | 330
Understanding SMTP Antivirus Scanning | 330
Enabling SMTP Antivirus Scanning (CLI Procedure) | 333
Understanding POP3 Antivirus Scanning | 333
Enabling POP3 Antivirus Scanning (CLI Procedure) | 335
Understanding IMAP Antivirus Scanning | 335
Enabling IMAP Antivirus Scanning (CLI Procedure) | 338
Integrated Web Filtering | 339
Understanding Integrated Web Filtering | 339
Example: Configuring Integrated Web Filtering | 343
Requirements | 343
Overview | 343
xiii
Configuration | 344
Verification | 353
Displaying Global SurfControl URL Categories | 355
7 Configuration Statements
action (Security UTM Web Filtering) | 364
address-blacklist | 365
address-whitelist | 367
admin-email | 368
administrator-email (Security Fallback Block) | 369
administrator-email (Security Virus Detection) | 371
allow-email (Security Fallback Block) | 372
allow-email (Security Virus Detection) | 374
application (Security Policies) | 375
application-proxy (Security UTM) | 377
anti-spam | 379
anti-spam (Security UTM Policy) | 381
anti-virus | 383
anti-virus (Security UTM Policy) | 387
avira-engine | 389
block-command | 391
block-content-type | 392
block-extension | 394
block-message (Security UTM) | 395
block-mime | 397
cache | 398
xiv
category (Security Logging) | 400
category (Security Web Filtering) | 402
content-filtering (Security Feature Profile) | 413
content-filtering (Security UTM Policy) | 416
content-size | 419
content-size (Security Antivirus Sophos Engine) | 421
content-size-limit | 423
corrupt-file | 424
custom-block-message | 426
custom-message (Security Content Filtering) | 427
custom-message (Security Email Notify) | 429
custom-message (Security Fallback Block) | 430
custom-message (Security Fallback Non-Block) | 432
custom-message (Security Virus Detection) | 433
custom-message (Security Web Filtering) | 435
custom-message-subject (Security Email Notify) | 437
custom-message-subject (Security Fallback Block) | 438
custom-message-subject (Security Fallback Non-Block) | 440
custom-message-subject (Security Virus Detection) | 441
custom-objects | 443
custom-page | 445
custom-page-file | 447
custom-tag-string | 449
custom-url-category | 450
decompress-layer | 452
xv
decompress-layer-limit | 454
default (Security Antivirus) | 457
default (Security Antivirus Sophos Engine) | 458
default (Security UTM) | 460
default (Security Web Filtering) | 461
display-host (Security Fallback Block) | 463
display-host (Security Virus Detection) | 465
download-profile (Security Antivirus FTP) | 466
download-profile (Security Content Filtering FTP) | 468
email-notify | 469
engine-not-ready | 471
engine-not-ready (Security Antivirus Sophos Engine) | 472
exception | 474
exception (Security Content Filtering) | 475
fallback-block (Security Antivirus) | 477
fallback-non-block (Security Antivirus) | 479
fallback-options (Security Antivirus Juniper Express Engine) | 480
fallback-options (Security Antivirus Kaspersky Lab Engine) | 482
fallback-options (Security Antivirus Sophos Engine) | 484
fallback-settings (Security Web Filtering) | 486
fallback-settings (Security Web Filtering Juniper Local) | 487
fallback-settings (Security Web Filtering Websense Redirect) | 489
feature-profile | 491
filename-extension | 502
flag (SMTP) | 504

xvi
format (Security Log Stream) | 506
forwarding-mode (Security UTM Policy) | 508
from-zone (Security Policies) | 510
ftp (UTM Policy Anti-Virus) | 514
ftp (UTM Policy Content Filtering) | 516
hold-interval | 518
host (Security Web Filtering) | 519
http-profile (Security Antivirus) | 521
http-profile (Security Content Filtering) | 522
http-profile (Security Web Filtering) | 523
imap-profile (Security UTM Policy Antivirus) | 525
imap-profile (Security UTM Policy Content Filtering) | 526
http-persist | 527
http-reassemble | 529
intelligent-prescreening | 530
interval (Security Antivirus) | 532
ipc | 534
juniper-enhanced | 535
juniper-express-engine | 538
juniper-local | 541
kaspersky-lab-engine | 543
limit (UTM Policy) | 546
list | 547
list (Security Content Filtering Block Mime) | 549
log (Security) | 550

xvii
mime-pattern | 555
mime-whitelist | 557
no-autoupdate | 559
no-intelligent-prescreening | 560
no-notify-mail-recipient | 562
no-notify-mail-sender (Security Content Filtering Notification Options) | 564
no-notify-mail-sender (Security Fallback Block) | 565
no-notify-mail-sender (Security Virus Detection) | 567
no-sbl-default-server | 568
notification-options (Security Antivirus) | 570
notification-options (Security Content Filtering) | 572
notify-mail-recipient | 573
notify-mail-sender (Security Content Filtering Notification Options) | 575
notify-mail-sender (Security Fallback Block) | 576
notify-mail-sender (Security Virus Detection) | 578
no-uri-check | 579
out-of-resources | 581
out-of-resources (Security Antivirus Sophos Engine) | 582
over-limit | 584
packet-filter | 586
password (Security Antivirus) | 588
password-file | 590
pattern-update (Security Antivirus) | 591
permit-command | 593
policies | 594
xviii
pop3-profile (Security UTM Policy Antivirus) | 605
pop3-profile (Security UTM Policy Content Filtering) | 606
port (Security Antivirus) | 607
port (Security Web Filtering Server) | 609
primary-server | 610
profile (Security Antispam SBL) | 612
profile (Security Antivirus Juniper Express Engine) | 613
profile (Security Antivirus Kaspersky Lab Engine) | 616
profile (Security Content Filtering) | 619
profile (Security Sophos Engine Antivirus) | 621
profile | 623
profile (Security Web Filtering Juniper Enhanced) | 626
profile (Security Web Filtering Juniper Local) | 628
profile (Security Web Filtering Surf Control Integrated) | 630
profile (Security Web Filtering Websense Redirect) | 632
protocol-command | 634
proxy (Security Antivirus) | 635
proxy-profile | 637
quarantine-message (Security UTM) | 638
routing-instance (Security UTM) | 640
sbl | 642
sbl-default-server | 644
scan-extension | 645
scan-mode | 646
scan-options (Security Antivirus Juniper Express Engine) | 648

xix
scan-options (Security Antivirus Kaspersky Lab Engine) | 650
scan-options (Security Antivirus Sophos Engine) | 652
scan-options (Security Antivirus Avira Engine) | 653
secondary-server | 655
server (Security Antivirus) | 657
server (Security Sophos Engine Antivirus) | 658
server (Security Web Filtering) | 660
server-connectivity | 662
session-scan | 664
site-reputation-action | 665
size (Security Web Filtering Cache) | 667
smtp-profile (Security UTM Policy Antispam) | 669
smtp-profile (Security UTM Policy Antivirus) | 670
smtp-profile (Security UTM Policy Content Filtering) | 671
sockets | 673
sophos-engine | 674
source-address | 677
spam-action | 678
start-time | 680
surf-control-integrated | 681
sxl-retry | 684
sxl-timeout | 685
timeout (Security Antivirus Fallback Options) | 687
timeout (Security Antivirus Fallback Options Sophos Engine) | 689
timeout (Security Antivirus Scan Options) | 690

xx
timeout (Security Web Filtering) | 692
timeout (Security Web Filtering Cache) | 693
timeout (Security Web Filtering Fallback Settings) | 695
too-many-requests (Security Antivirus Fallback Options) | 697
too-many-requests (Security Antivirus Fallback Options Sophos Engine) | 699
too-many-requests (Security Web Filtering Fallback Settings) | 701
to-zone (Security Policies) | 703
traceoptions (Security Antispam) | 706
traceoptions (Security Antivirus) | 708
traceoptions (Security Application Proxy) | 710
traceoptions (Security Content Filtering) | 713
traceoptions (Security UTM) | 714
traceoptions (Security Web Filtering) | 716
traceoptions (SMTP) | 718
traffic-options | 720
trickling | 721
type (Security Antivirus Feature Profile) | 723
type (Security Content Filtering Notification Options) | 725
type (Security Fallback Block) | 727
type (Security Virus Detection) | 729
type (Security Web Filtering) | 731
upload-profile (Security Antivirus FTP) | 733
upload-profile (Security Content Filtering FTP) | 734
uri-check | 735
url (Security Antivirus) | 737

xxi
url-blacklist | 738
url-pattern | 740
url-whitelist | 743
url-whitelist | 745
username (Security Antivirus) | 746
utm | 748
default-configuration | 760
utm-policy | 768
utm-policy (Application Services) | 771
virus-detection (Security Antivirus) | 772
web-filtering | 774
web-filtering (Security UTM Policy) | 780
websense-redirect | 782
8 Operational Commands
clear security utm anti-spam statistics | 787
clear security utm antivirus statistics | 790
clear security utm content-filtering statistics | 793
clear security utm session | 797
clear security utm web-filtering statistics | 798
request security utm anti-virus juniper-express-engine | 801
request security utm anti-virus kaspersky-lab-engine | 803
request security utm anti-virus sophos-engine | 805
request security utm anti-virus avira-engine | 807
request security utm web-filtering category install | 810
request security utm web-filtering category uninstall | 812

xxii
request security utm web-filtering category download-install [version] | 813
request security utm web-filtering category download [version] | 815
request security utm web-filtering custom-page reload | 816
show configuration smtp | 818
show groups junos-defaults | 820
show security log | 822
show security policies | 826
show security utm anti-spam statistics | 848
show security utm anti-spam status | 853
show security utm anti-virus statistics | 855
show security utm anti-virus status | 862
show security utm content-filtering statistics | 866
show security utm session | 878
show security utm status | 880
show security utm web-filtering category base-filter | 881
show security utm web-filtering category category | 884
show security utm web-filtering category status | 886
show security utm web-filtering statistics | 888
show security utm web-filtering status | 895
test security utm anti-spam | 898
test security utm enhanced-web-filtering url-check | 903
test security utm web-filtering profile | 907

xxiii
About This Guide
Use this guide to configure, monitor, and manage the Unified Threat Management (UTM) features in
Junos OS NFX Series and SRX Series devices to secure the network from viruses, malware, or malicious
attachments and protect the users from security threats.
1 CHAPTER
Overview
UTM Overview | 2

2
UTM Overview
IN THIS SECTION
Unified Threat Management (UTM) provides multiple security features and services in a single device or
service on the network, protecting users from security threats in a simplified way. UTM includes
functions such as antivirus, antispam, content filtering, and web filtering. UTM secures the network from
viruses, malware, or malicious attachments by scanning the incoming data using Deep Packet Inspection
and prevents access to unwanted websites by installing Enhanced Web filtering. For more information,
see the following topics:
Unified Threat Management Overview
IN THIS SECTION
Understanding UTM Custom Objects | 4
Unified Threat Management (UTM) is a term used to describe the consolidation of several security
features into one device, protecting against multiple threat types. The advantage of UTM is streamlined
installation and management of these multiple security capabilities.
The security features provided as part of the UTM solution are:
• Antispam Filtering— E-mail spam consists of unwanted e-mail messages, usually sent by commercial,
malicious, or fraudulent entities. The antispam feature examines transmitted e-mail messages to
identify e-mail spam. When the device detects an e-mail message deemed to be spam, it either drops
the message or tags the message header or subject field with a preprogrammed string. The antispam
feature uses a constantly updated spam block list (SBL). Sophos updates and maintains the IP-based
SBL. The antispam feature is a separately licensed subscription service.
3
• Content Filtering— Content filtering blocks or permits certain types of traffic based on the MIME
type, file extension, protocol command, and embedded object type. Content filtering does not
require a separate license.
• Web Filtering— Web filtering lets you manage Internet usage by preventing access to inappropriate
Web content. There are three types of Web filtering solutions. The integrated Web filtering solution,
the decision-making for blocking or permitting Web access is done on the device after it identifies
the category for a URL either from user-defined categories or from a category server (Websense
provides the CPA Server). The integrated Web filtering feature is a separately licensed subscription
service which is supported only on SRX Series devices. The redirect Web filtering solution intercepts
HTTP requests and forwards the server URL to an external URL filtering server provided by
Websense to determine whether to block or permit the requested Web access. Redirect Web
filtering does not require a separate license. With Juniper Local Web Filtering, the decision-making
for blocking or permitting Web access is done on the device after it identifies the category for a URL
from user-defined categories stored on the device. With Local filtering, there is no additional Juniper
license or remote category server required.
• Starting with Junos OS Release 15.1X49-D60 and Junos OS Release 17.3R1, on SRX1500 Services
Gateways and vSRX instances, UTM policies, profiles, MIME patterns, filename extensions, and
protocol-command numbers are increased to 500; custom URL patterns and custom URL categories
are increased to 1000.
Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, SRX4100 and SRX4200
devices support up to 500 UTM policies, profiles, MIME patterns, filename extensions, and protocol
commands, and up to 1000 custom URL patterns and custom URL categories.
Starting with Junos OS Release 18.2R1, NFX150 devices support up to 500 UTM policies, profiles,
MIME patterns, filename extensions, and protocol commands, and up to 1000 custom URL patterns
and custom URL categories.
Starting with Junos OS Release 18.2R1, the following commands under the [edit security utm feature-
profile] hierarchy level are deprecated:
• set web-filtering type
• set web-filtering url-blacklist
• set web-filtering url-whitelist
• set web-filtering http-persist
• set web-filtering http-reassemble
• set web-filtering traceoptions
• set web-filtering juniper-enhanced cache

4
• set web-filtering juniper-enhanced reputation
• set web-filtering juniper-enhanced query-type
• set anti-virus mime-whitelist
• set anti-virus url-whitelist
• set anti-virus type
• set anti-virus traceoptions
• set anti-virus sophos-engine
• set anti-spam address-blacklist
• set anti-spam address-whitelist
• set anti-spam traceoptions
• set content-filtering traceoptions
Starting with Junos OS Release 18.4R3, on SRX1500, SRX4100, SRX4200, SRX4600, SRX4800,
SRX5400, SRX5600, and SRX5800 devices, UTM policies, profiles, MIME patterns, filename
extensions, protocol commands, and custom messages, are increased up to 1500. Custom URL
patterns and custom URL categories are increased up to 3000.
This feature requires a license. To understand more about UTM Licensing, see, Understanding UTM
Licensing. Please refer to the Juniper Licensing Guide for general information about License
Management. Please refer to the product Data Sheets at SRX Series Services Gateways for details, or
contact your Juniper Account Team or Juniper Partner.
• Antivirus— The Avira antivirus module in the unified threat management (UTM) solution consists of a
virus pattern database, an application proxy, a scan manager, and a configurable scan engine. The
antivirus module on the SRX Series device scans specific application layer traffic to protect the user
from virus attacks and to prevent viruses from spreading.
Understanding UTM Custom Objects
Before you can configure most UTM features, you must first configure the custom objects for the
feature in question. Custom objects are global parameters for UTM features. This means that configured
custom objects can be applied to all UTM policies where applicable, rather than only to individual
policies.
The following UTM features make use of certain custom objects:
• Web Filtering (see "Example: Configuring Integrated Web Filtering" on page 343)
5
• Anti-Spam (see "Server-Based Antispam Filtering Configuration Overview" on page 93)
• Content Filtering (see "Content Filtering Configuration Overview" on page 121)
Starting in Junos OS Release 18.2R1, a new dynamic application policy match condition is added to SRX
Series devices, allowing an administrator to more effectively control the behavior of Layer 7
applications. To accommodate Layer 7 application-based policies in UTM, the [edit security utm default-
configuration] hierarchy level is introduced. If any parameter in a specific UTM feature profile
configuration is not configured, then the corresponding parameter from the UTM default configuration
is applied. Additionally, during the initial policy lookup phase which occurs prior to a dynamic application
being identified, if there are multiple policies present in the potential policy list which contains different
UTM profiles, the SRX Series device applies the default UTM profile until a more explicit match has
occurred.
SEE ALSO
Release History Table
Release Description
18.4R3 Starting with Junos OS Release 18.4R3, on SRX1500, SRX4100, SRX4200, SRX4600, SRX4800,
SRX5400, SRX5600, and SRX5800 devices, UTM policies, profiles, MIME patterns, filename
extensions, protocol commands, and custom messages, are increased up to 1500. Custom URL
patterns and custom URL categories are increased up to 3000
18.2R1 Starting with Junos OS Release 18.2R1, NFX150 devices support up to 500 UTM policies, profiles,
MIME patterns, filename extensions, and protocol commands, and up to 1000 custom URL patterns
and custom URL categories.
18.2R1 Starting with Junos OS Release 18.2R1, the following commands under the [edit security utm
feature-profile] hierarchy level are deprecated:
18.2R1 Starting in Junos OS Release 18.2R1, a new dynamic application policy match condition is added to
SRX Series devices, allowing an administrator to more effectively control the behavior of Layer 7
applications. To accommodate Layer 7 application-based policies in UTM, the [edit security utm
default-configuration] hierarchy level is introduced. If any parameter in a specific UTM feature
profile configuration is not configured, then the corresponding parameter from the UTM default
configuration is applied. Additionally, during the initial policy lookup phase which occurs prior to a
dynamic application being identified, if there are multiple policies present in the potential policy list
which contains different UTM profiles, the SRX Series device applies the default UTM profile until a
more explicit match has occurred.
6
15.1X49- Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, SRX4100 and
D70 SRX4200 devices support up to 500 UTM policies, profiles, MIME patterns, filename extensions,
and protocol commands, and up to 1000 custom URL patterns and custom URL categories.
15.1X49- Starting with Junos OS Release 15.1X49-D60 and Junos OS Release 17.3R1, on SRX1500 Services
D60 Gateways and vSRX instances, UTM policies, profiles, MIME patterns, filename extensions, and
protocol-command numbers are increased to 500; custom URL patterns and custom URL
categories are increased to 1000.
RELATED DOCUMENTATION

UTM Supported Features
IN THIS SECTION
WELF Logging for UTM Features | 6
Explicit Proxy for UTM | 12
Unified Policies for UTM | 20
Allowlist | 24
WELF Logging for UTM Features
IN THIS SECTION
Understanding WELF Logging for UTM Features | 7

7
Example: Configuring WELF Logging for UTM Features | 8
Understanding WELF Logging for UTM Features

UTM features support the WELF standard. The WELF Reference defines the WebTrends industry
standard log file exchange format. Any system logging to this format is compatible with Firewall Suite
2.0 and later, Firewall Reporting Center 1.0 and later, and Security Reporting Center 2.0 and later.
A WELF log file is composed of records. Each record is a single line in the file. Records are always in
chronological order. The earliest record is the first record in the file; the most recent record is the last
record in the file. WELF places no restrictions on log filenames or log file rotation policies.
NOTE: Each WELF record is composed of fields. The record identifier field (id=) must be the first
field in a record. All other fields can appear in any order.
The following is a sample WELF record:
id=firewall time="2000-2-4 12:01:01" fw=192.168.0.238 pri=6 rule=3 proto=http

src=192.168.0.23 dst=6.1.0.36 rg=www.example.com/index.html op=GET result=0
rcvd=1426
The fields from the example WELF record include the following required elements (all other fields are
optional):
• id (Record identifier)
• time (Date/time)
• fw (Firewall IP address or name)
• pri (Priority of the record)

8
Example: Configuring WELF Logging for UTM Features
IN THIS SECTION
Requirements | 8
Overview | 8
Configuration | 8
Verification | 11
This example shows how to configure WELF logging for UTM features.
Requirements
Before you begin, review the fields used to create a WELF log file and record. See "UTM Overview" on
page 2.
Overview
A WELF log file is composed of records. Each record is a single line in the file. Records are always in
chronological order. The earliest record is the first record in the file; the most recent record is the last
record in the file. WELF places no restrictions on log filenames or log file rotation policies. In this
example, the severity level is emergency and the name of the security log stream is utm-welf.
Configuration
IN THIS SECTION
Procedure | 9
9
Procedure
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
set security log source-address 1.2.3.4 stream utm-welf

set security log source-address 1.2.3.4 stream utm-welf format welf
set security log source-address 1.2.3.4 stream utm-welf format welf category content-security
severity emergency
severity emergency host 5.6.7.8
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure WELF logging for UTM features:
1. Set the security log source IP address.
[edit security log]

user@host# set source-address 1.2.3.4
NOTE: You must save the WELF logging messages to a dedicated WebTrends server.
2. Name the security log stream.
[edit security log]

user@host# set source-address 1.2.3.4 stream utm-welf
10
3. Set the format for the log messages.
[edit security log]

user@host# set source-address 1.2.3.4 stream utm-welf format welf
4. Set the category of log messages that are sent.
[edit security log]

user@host# set source-address 1.2.3.4 stream utm-welf format welf category content-security
5. Set the severity level of log messages that are sent.
[edit security log]

severity emergency
6. Enter the host address of the dedicated WebTrends server to which the log messages are to be sent.
[edit security log]

severity emergency host 5.6.7.8
Results
From configuration mode, confirm your configuration by entering the show security log command. If the
output does not display the intended configuration, repeat the configuration instructions in this example
to correct it.
[edit]
user@host# show security log
stream utm-welf {
severity emergency;
format welf;
category content—
security;
11
host {
5.6.7.8;
If you are done configuring the device, enter commit from configuration mode.
Verification
IN THIS SECTION
Verifying the Security Log | 11
Verifying the Security Log
Purpose
Verify that the WELF log for UTM features is complete.
Action
From operational mode, enter the show security utm status command to verify if the UTM service is
running or not.
SEE ALSO

Understanding UTM Licensing
12
Explicit Proxy for UTM
IN THIS SECTION
Understanding Explicit Proxy | 12
Configuring the Explicit Proxy on Juniper Enhanced Server | 13
Verifying the Explicit Proxy Configuration on Juniper Enhanced Server | 15
Configuring the Predefined Category Upgrading and Base Filter Configuration Using Explicit
Proxy | 15
Verifying the Predefined Category Upgrading and Base Filter Configuration | 17
Configuring the Sophos Antivirus Pattern Update | 18
Verifying the Sophos Antivirus Pattern Update | 19
UTM support the use of an explicit proxy for the cloud-based connectivity for Enhanced Web Filtering
(EWF) and Sophos antivirus (SAV) on unified threat management (UTM). The explicit proxy hides the
identity of the source device and establishes a connection with the destination device.
Understanding Explicit Proxy

An explicit proxy hides the identity of source device, communicates directly with the Websense
Threatseeker Cloud (TSC) server and establishes a connection with the destination device. The explicit
proxy configuration consists of port address and direct IP address or hostname.
To use the explicit proxy, create one or more proxy profiles and refer to those profiles:
• In EWF, the explicit proxy is configured by referring to the created proxy-profile in security utm default-
configuration web-filtering juniper-enhanced server hierarchy. The connection is established with the TSC
server.
• In EWF predefined category upgrading and base filter, the explicit proxy is configured by referring to
the created proxy-profile in security utm custom-objects category-package proxy-profile hierarchy. You can
download and dynamically load new EWF categories without any software upgrade. The proxy-profile
category file is installed and used for transfer of the traffic.
SRX device sends CONNECT request to the proxy server, the SRX device and TSC server
communicates through the HTTP connection. Then the proxy server is expected to identify the
configured IP addresses, allowlist and allow SRX device to send traffic to the TSC server in cloud via
proxy. After proxy filtering, it will create connection to real TSC server.
13
• In Sophos Antivirus (SAV), the explicit proxy is configured by referring to the created proxy-profile in
security utm default-configuration anti-virus sophos-engine pattern-update hierarchy. The utmd process
connects to the proxy host instead of the SAV pattern update server on the cloud.
On EWF, if the proxy profile is configured in UTM Web filtering configuration, the TSC server
connection is established with the proxy host instead of the UTM server on the cloud.
On SAV, if the proxy profile is configured, the utmd process connects to the proxy host instead of the
SAV pattern update server on the cloud.
NOTE: The proxy server authentication is not supported if the proxy-profile is configured.
Configuring the Explicit Proxy on Juniper Enhanced Server

Create a proxy profile with host and port information, and refer it in the Juniper enhanced server to
establish a connection to the UTM cloud server.
The following configuration shows how to configure the explicit proxy on Juniper enhanced server.
1. Assigning host IP address for proxy profile.
[edit services proxy profile]

user@host# set proxy1 protocol http host 192.0.2.1
2. Assigning port address for proxy profile.

user@host# set proxy1 protocol http port 3128
3. Assign the proxy profile to the Web filtering Juniper enhanced server.
[edit security utm default-configuration web-filtering juniper-enhanced server]

user@host# set proxy-profile proxy1
Results
14
From configuration mode, confirm your configuration by entering the show security and show services
command. If the output does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@host# show security
default-configuration {
web-filtering {
type juniper-enhanced;
juniper-enhanced {
server {
proxy-profile proxy1;
}
}
}
}
[edit]
user@host# show services
proxy {
profile proxy1 {
protocol {
http {
host 192.0.2.1;
port 3128;
}
}
}
}
15
Verifying the Explicit Proxy Configuration on Juniper Enhanced Server
IN THIS SECTION
Purpose | 15
Action | 15
Meaning | 15
Purpose
Display the status of explicit server on Juniper enhanced server.
Action
From operational mode, enter the show security utm web-filtering status command.
user@host> show security utm web-filtering status

UTM web-filtering status: Server status: Juniper Enhanced using Websense server UP
Meaning
This command provides information on server status of Enhanced Web Filtering (EWF) using Websense
Threatseeker Cloud (TSC).
Configuring the Predefined Category Upgrading and Base Filter Configuration Using
Explicit Proxy
Create a proxy profile with host and port information, and refer it in the predefined category upgrade
and base filter to download and dynamically load new EWF categories without any software upgrade.
The following configuration shows how to configure the explicit proxy on predefined category upgrading
and base filter.
16

2. Assign port address for proxy profile.

3. Assign the proxy profile to the category packages in the custom objects.
[edit security utm custom-objects]

user@host# set category-package proxy-profile proxy1
Results
[edit]
custom-objects {
category-package {
}
}
[edit]
proxy {
profile proxy1 {
protocol {
http {
host 203.0.113.1;
port 3128;
17
}
}
}
}
Verifying the Predefined Category Upgrading and Base Filter Configuration
IN THIS SECTION
Purpose | 17
Action | 17
Meaning | 18
Purpose
Display the Enhanced Web Filtering (EWF) predefined category package download, install, and update
status.
Action
From operational mode, enter the show security utm web-filtering category status CLI command to see the
web filtering category status.
NOTE: Before you execute the show security utm web-filtering category status CLI command, you
must execute the request security utm web-filtering category download-install CLI command to get
the results.
user@host> show security utm web-filtering category status

UTM category status:
Installed version: 1
Download version: 0
Update status: Done
18
Meaning
This command provides information on the number of installed and downloaded categories and the
update status.
Configuring the Sophos Antivirus Pattern Update

Create a proxy profile with host and port information, and refer it in the Sophos Antivirus (SAV) pattern
update. The utmd process connects to the proxy host instead of the SAV pattern update server on the
cloud.
The following configuration shows how to configure the explicit proxy on SAV pattern update.
[edit services proxy profile ]

2. Assign port address for proxy profile.
[edit services proxy profile ]

3. Assign the proxy profile to the Sophos antivirus pattern update.
[edit security utm default-configuration anti-virus sophos-engine pattern-update]

user@host# set proxy-profile proxy1
Results
[edit]
19
anti-virus {
sophos-engine {
pattern-update {
}
}
}
}
[edit]
proxy {
profile proxy1 {
protocol {
http {
host 203.0.113.1;
port 3128;
}
}
}
}
Verifying the Sophos Antivirus Pattern Update
IN THIS SECTION
Purpose | 19
Action | 20
Meaning | 20
Purpose
Display the Sophos Antivirus (SAV) update pattern status.

20
Action
From operational mode, enter the show security utm anti-virus status CLI command to see the UTM
antivirus status.
user@host> show security utm anti-virus status

UTM anti-virus status:
Anti-virus key expire date: 2018-08-02 00:00:00

Update server: https://host2.example.com/SAV/
Interval: 1000 minutes
Pattern update status: next update in 979 minutes
Pattern update via proxy server: 203.0.113.1:3128
Last result: already have latest database
Anti-virus signature version: 1.13 (1.02)
Scan engine type: sophos-engine
Scan engine information: last action result: No error
Meaning
This command provides information on the the Sophos Antivirus (SAV) pattern update server, update
status, antivirus signature version, antivirus engine type and antivirus engine information.
Unified Policies for UTM
IN THIS SECTION
Understanding Unified Policies [Unified Threat Management (UTM)] | 20
Understanding Unified Policies [Unified Threat Management (UTM)]
IN THIS SECTION
Understanding Default UTM Policy | 21

21
Unified policies are now supported on SRX Series devices, allowing granular control and enforcement of
dynamic Layer 7 applications within the traditional security policy.
Unified policies are security policies in which you can use dynamic applications as match conditions
along with existing 5-tuple or 6-tuple matching conditions (with user firewall) to detect application
changes over time. The use of unified policies enable you to enforce a set of rules for the transit traffic.
It uses the match criteria, namely, source zone, destination zone, source addresses, destination
addresses, and application names. This results in potential match policies.
The unified policy configuration handles all Application Firewall (AppFW) functionalities and simplifies
the task of configuring firewall policy to permit or block application traffic from the network. As part of
the unified policy, a new dynamic application policy match condition is added to SRX Series devices,
allowing an administrator to more effectively control the behavior of Layer 7 applications.
To accommodate Layer 7 application-based policies in UTM, the [edit security utm default-configuration]
command is introduced. If any parameter in a specific UTM feature profile configuration is not
configured, then the corresponding parameter from the UTM default configuration is applied.
Additionally, during the initial policy lookup phase which occurs prior to a dynamic application being
identified, if there are multiple policies present in the potential policy list which contains different UTM
profiles, the SRX Series device applies the default UTM profile until a more explicit match has occurred.
Understanding Default UTM Policy
A new predefined default UTM policy is available with the factory default configuration to provide a
default UTM configuration. This predefined global UTM policy inherits the configuration from the
default UTM configuration profile.
If there is an existing UTM policy defined, it will continue to be used to evaluate traffic based on the
existing security policy configuration.
When a policy lookup is performed, existing UTM policies are evaluated prior to global policies. The
predefined UTM default policy is leveraged if multiple UTM policies exist in the potential policy list
during the UTM session creation process.
The predefined UTM default policy parameters are included under [edit security utm default-configuration]
hierarchy level. These parameters are available for Web filtering, content filtering, antivirus, and
antispam profile. If no UTM feature profile is configured (Web filtering, content filtering, antivirus, and
antispam), the parameters in the predefined global UTM configuration are applied.
The predefined UTM default policy is available in [edit groups junos-defaults security utm]. You can modify
certain parameters for Web filtering, content filtering, antivirus, and antispam. You can also modify
default UTM profile parameters for Web filtering, content filtering, antivirus, and antispam features
profiles at [edit security utm default-configuration].
22
SEE ALSO
Global Policy Overview

UTM Support for Chassis Cluster
IN THIS SECTION
Understanding UTM Support for Active/Active Chassis Cluster | 22
Understanding UTM Support for Active/Backup Chassis Cluster | 23
UTM is supported for active/active chassis cluster and active/backup chassis cluster configuration. For
more information, see the following topics:
Understanding UTM Support for Active/Active Chassis Cluster

UTM requires a license for each device in the chassis cluster setup. For information about how to
purchase a software license, contact your Juniper Networks sales representative at https://
www.juniper.net/in/en/contact-us/ and for more information refer Licensing guide.
All the following UTM features are supported in active/active chassis cluster:
• Antispam Filtering
• Content Filtering
• Sophos Antivirus Scanning
• Enhanced Web Filtering
• Local Web Filtering
• Websense Redirect Web Filtering
• On-box/Avira AV
UTM supports active/active chassis cluster configuration from Junos OS Release 19.4R1 onwards.
Active/Active cluster is a cluster where interfaces can be active on both cluster nodes simultaneously.
23
This is the case when there are more than one data-plane redundancy-groups, that is redundancy-
groups 1 and higher or when local (non-reth) interfaces are used on the cluster nodes.
Enhanced Web Filtering cloud connection does not support failover, it will create new connection
automatically after the old connection is retired.
Understanding UTM Support for Active/Backup Chassis Cluster

UTM requires a license for each device in the chassis cluster setup. For information about how to
purchase a software license, contact your Juniper Networks sales representative at https://
www.juniper.net/in/en/contact-us/.
The following UTM features are supported in chassis cluster:
• Content filtering
• URL (Web) filtering
• Antispam filtering
• Full file-based antivirus scanning
• Sophos antivirus scanning
Active/Active cluster is a cluster where interfaces can be active on both cluster nodes at the same time.
This is the case when there are more than one data-plane redundancy-groups, i.e. redundancy-groups 1
and higher or when local (non-reth) interfaces are used on the cluster nodes.
If multiple data-plane redundancy-groups are configured, UTM works only if all the redundancy groups
are active in the single node. In case one of the redundancy-group failed over automatically to another
node, UTM won't work.
SEE ALSO
Chassis Cluster Overview

Preparing Your Equipment for Chassis Cluster Formation
Understanding Chassis Cluster Redundancy Groups
Understanding Chassis Cluster Redundant Ethernet Interfaces

24

Allowlist
IN THIS SECTION
Understanding MIME Allowlist | 24
Example: Configuring MIME Allowlist to Bypass Antivirus Scanning | 25
Understanding URL Allowlist | 27
Configuring URL Allowlist to Bypass Antivirus Scanning (CLI Procedure) | 27
A URL allowlist defines all the URLs listed for a specific category to always bypass the scanning process.
The allowlist include hostnames that you want to exempt from undergoing SSL proxy processing. For
Understanding MIME Allowlist

The gateway device uses MIME (Multipurpose Internet Mail Extension) types to decide which traffic
may bypass antivirus scanning. The MIME allowlist defines a list of MIME types and can contain one or
many MIME entries.
A MIME entry is case-insensitive. An empty MIME is an invalid entry and should never appear in the
MIME list. If the MIME entry ends with a / character, prefix matching takes place. Otherwise, exact
matching occurs.
There are two types of MIME lists used to configure MIME type antivirus scan bypassing:
• mime-allowlist list—This is the comprehensive list for those MIME types that can bypass antivirus
scanning.
• exception list—The exception list is a list for excluding some MIME types from the mime-allowlist list.
This list is a subset of MIME types found in the mime-allowlist.
For example, if the mime-allowlist includes the entry,video/ and the exception list includes the entry
video/x-shockwave-flash, by using these two lists, you can bypass objects with “video/” MIME type but
not bypass “video/x-shockwave-flash” MIME type.
You should note that there are limits for mime-allowlist entries as follows:
25
• The maximum number of MIME items in a MIME list is 50.
• The maximum length of each MIME entry is restricted to 40 bytes.
• The maximum length of a MIME list name string is restricted to 40 bytes.
Example: Configuring MIME Allowlist to Bypass Antivirus Scanning
IN THIS SECTION
Requirements | 25
Overview | 25
Configuration | 25
Verification | 26
This example shows how to configure MIME allowlists to bypass antivirus scanning.
Requirements
Before you begin, decide the type of MIME lists used to configure MIME type antivirus scan bypassing.
See Understanding MIME Allowlist.
Overview
In this example, you create MIME lists called avmime2 and ex-avmime2 and add patterns to them.
Configuration
IN THIS SECTION
Procedure | 26
26
Procedure
To configure MIME allowlists to bypass antivirus scanning:
1. Create MIME lists and add patterns to the lists.
[edit]
user@host# set security utm custom-objects mime-pattern avmime2 value [video/quicktime
image/x-portable-anymap x-world/x-vrml]
user@host# set security utm custom-objects mime-pattern ex-avmime2 value [video/quicktime-
inappropriate]
2. If you are done configuring the device, commit the configuration.
[edit]
user@host# commit
Verification
IN THIS SECTION
Verify the MIME Allowlist Configuration | 26
Verify the MIME Allowlist Configuration
Purpose
To verify the MIME allowlist configuration is working properly.
Action
From operational mode, enter the show security utm command.

27
Understanding URL Allowlist

A URL allowlist defines all the URLs listed for a specific category to always bypass the scanning process.
The allowlist includes hostnames that you want to exempt from undergoing SSL proxy processing. There
are also legal requirements to exempt financial and banking sites; such exemptions are achieved by
configuring URL categories corresponding to those hostnames under the URL allowlists. If any URLs do
not require scanning, corresponding categories can be added to this allowlisting.
Starting with Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, the allowlisting feature is
extended to include URL categories supported by UTM in the allowlist configuration of SSL forward
proxy. For more information, see Application Security User Guide for Security Devices.
Starting with Junos OS Release 17.4R1, the allowlisting feature is extended to support custom URL
categories supported by UTM in the allowlist configuration of SSL forward proxy.
Configuring URL Allowlist to Bypass Antivirus Scanning (CLI Procedure)

To configure URL allowlists, use the following CLI configuration statements:
security utm custom-objects {

custom-url-category { ; set of list
name url-category-name; #mandatory
value url-pattern-name;
}
}

Release Description
17.4R1 Starting with Junos OS Release 17.4R1, the allowlisting feature is extended to support custom URL
categories supported by UTM in the allowlist configuration of SSL forward proxy.
15.1X49-D80 Starting with Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, the allowlisting
feature is extended to include URL categories supported by UTM in the allowlist configuration of
SSL forward proxy. For more information, see Application Security User Guide for Security
Devices.
2 CHAPTER
Antivirus Protection
Sophos Antivirus Protection | 46

29
On-Device Avira Antivirus
IN THIS SECTION
Avira Antivirus Overview | 29
Example: Configure Avira Antivirus | 31
Read this topic to understand about how to use Avira Antivirus for scanning application traffic and
preventing viruses from entering your network.
You can also watch the video Avira Antivirus Solution on SRX Series Devices to understand about
installing and using Avira antivirus on your security device.
Avira Antivirus Overview
IN THIS SECTION
Benefits | 31
Junos OS unified threat management (UTM) integrates with Avira’s Antivirus functionality and provides
full file-based scan engine. This antivirus protection secures your device by scanning the application
layer traffic and blocks the harmful content such as infected files, trojans, worms, spyware, and other
malicious data.
Avira Antivirus scans the network traffic by accessing the virus pattern database and identifies the virus.
Avira Antivirus drops the infected file and notifies the user.
Table 1 on page 30 lists the components and license details for Avira Antivirus.
30
Table 1: Components and License Details for Avira Antivirus
Components Detailed Information
Virus pattern Avira Antivirus checks the virus signature database to identify and then remove signatures.
database
The virus pattern database is available at the following locations:
• Default: https://update.juniper-updates.net/avira
• For SRX4100, SRX4200, and SRX4600 Series devices: https://update.juniper-updates.net/

AVIRA/SRXTVP
• For SRX5K-SPC3 devices: https://update.juniper-updates.net/AVIRA/SPC3
• For vSRX: https://update.juniper-updates.net/AVIRA/VSRX
By default, SRX Series devices downloads the updates for pattern database. See "Configure
Avira Antivirus Scanning Options" on page 31 to schedule the automatic download option.
Avira Antivirus Avira Antivirus provides the scan engine that examines a file for known viruses at real-time.
scan engine You must install and activate Avira Antivirus scan engine on your SRX Series device. See
"Example: Configure Avira Antivirus" on page 31 for steps to install and activate Avira
Antivirus scan engine.
Avira Antivirus scan engine decompresses files before scanning for virus detection. For more
information, see "decompress-layer-limit" on page 454.
In the following scenarios, Avira Antivirus scan engine on the SRX Series device does not scan
the application traffic:
• The scan engine is not ready.
• There are too many scanning requests.
• The scanned file size is larger than a configured limit.
• The scanned file has too many nested layers of compression.
• The memory file system is full.

31
Table 1: Components and License Details for Avira Antivirus (Continued)
Components Detailed Information
License details Avira Antivirus scan engine is a licensed subscription service.
With this license, you can use a full file-based and real-time Avira Antivirus scanning function.
The antivirus functionality uses the latest updated virus signature database.
When the license expires, you can continue to use the locally stored antivirus signatures
without any updates. If you delete the local database, you cannot run antivirus scanning.
For more information about licenses, see Licenses for SRX Series.
Benefits
• Secures your device and protects your network from viruses, trojans, rootkits, and other types of
malicious code.
• Provides improved scanning performance as the virus signature database and Avira Antivirus scan
engine reside locally on the device.
SEE ALSO

Example: Configure Avira Antivirus
IN THIS SECTION
Requirements | 32
Overview | 32
Configuration | 33
Verification | 44
32
In this example, you’ll learn how to configure Avira antivirus on your security device. This topic includes
the details about using default antivirus profile and customized antivirus profile to secure your device
from the harmful content such as infected files, trojans, worms, spyware, and other malicious data.
Requirements
Before you begin:
• Verify that you have a Avira antivirus license. For more information on how to verify licenses on your
device, see Understanding Licenses for SRX Series Devices.
• SRX Series device with Junos OS Release 18.4R1 or later.
We’ve tested this example using an SRX1500 device with Junos OS Release 18.4R1.
Overview
Let’s take a look at a typical enterprise network. An end user unknowingly visits a compromised Website
and downloads a malicious content. This action results in compromise of the endpoint. The harmful
content on the endpoint also becomes a threat to other hosts within the network. It is important to
prevent the download of the malicious content.
You can use an SRX Series device with Avira antivirus to protect users from virus attacks and to prevent
spreading of viruses in your system, Avira antivirus scans network traffic for viruses, trojans, rootkits,
and other types of malicious code and blocks the malicious content immediately when detected.
33
Figure 1 on page 33 shows an example of Avira antivirus on SRX Series device usage.
Figure 1: Avira Antivirus on SRX Series
In this example, you’ll learn how to configure Avira antivirus on your security device. You have the
following options.
• To use default Avira antivirus options to get started, see "Use Default Antivirus Profile to Start
Antivirus Scanning" on page 34.
• To customize antivirus options as per your requirements, see "Configure Avira Antivirus Scanning
Options" on page 35 .
• To set antivirus scanning options, see "Configure Avira Antivirus Scanning with Custom Profile" on
page 37 .
Configuration
IN THIS SECTION
Use Default Antivirus Profile to Start Antivirus Scanning | 34
Configure Avira Antivirus Scanning Options | 35

34
Configure Avira Antivirus Scanning with Custom Profile | 37
Results | 41
You can enable the Juniper Networks pre-configured antivirus profile. When you use the default
antivirus feature profile option, you don't have to configure additional parameter. In this procedure, you
create an UTM policy with default antivirus profiles for all protocols and apply the UTM policy in a
security policy for the permitted traffic.
Use Default Antivirus Profile to Start Antivirus Scanning
To use default antivirus profile, complete the following steps:
1. Enable Avira antivirus scan on your security device.
user@host# set security utm default-configuration anti-virus type avira-engine
After configuring Avira as the antivirus type, reboot the device for the new scan engine to take
effect.
2. Select default antivirus profile for HTTP, FTP, SMTP, POP3, and IMAP protocols.
[edit]
user@host# set security utm default-configuration anti-virus type avira
user@host# set security utm utm-policy P1 anti-virus http-profile junos-av-defaults
user@host# set security utm utm-policy P1 anti-virus ftp upload-profile junos-av-defaults
user@host# set security utm utm-policy P1 anti-virus ftp download-profile junos-av-defaults
user@host# set security utm utm-policy P1 anti-virus smtp-profile junos-av-defaults
user@host# set security utm utm-policy P1 anti-virus pop3-profile junos-av-defaults
user@host# set security utm utm-policy P1 anti-virus imap-profile junos-av-defaults
3. Apply the UTM policy to the security policy.
[edit]
user@host# set security policies from-zone trust to-zone untrust policy POLICY-1 match source-
address any
35
user@host# set security policies from-zone trust to-zone untrust policy POLICY-1 match
destination-address any
application any
user@host# set security policies from-zone trust to-zone untrust policy POLICY-1 then permit
application-services utm-policy P1
4. Commit the configuration.
[edit]
user@host# commit
You can also watch the video Avira Antivirus Solution on SRX Series Devices to understand about
installing and using Avira antivirus on your security device.
Configure Avira Antivirus Scanning Options
In this procedure, you’ll perform optional steps to prepare your security device to use Avira antivirus.
1. 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, https://update.juniper-updates.net/avira. By default, your
security device downloads the pattern updates from https://update.juniper-updates.net/avira. The
location of virus pattern database depends on your SRX Series mode. See Table 1 on page 30 for
more details.
[edit]
user@host# set security utm default-configuration anti-virus avira-engine pattern-update url
http://www.example.net/
This step downloads the pattern and engine files from the specified URL.
2. Set an interval for regular download of antivirus pattern update.
[edit]
user@host# set security utm default-configuration anti-virus avira-engine pattern-update
interval 2880
36
In this step, you are changing the default from every 24 hours to every 48 hours. The default
antivirus pattern-update interval is 1440 minutes (every 24 hours).
3. Send an e-mail notification once pattern update completes.
[edit]
user@host# set security utm default-configuration anti-virus avira-engine pattern-update email-
notify admin-email admin@email.net custom-message “Avira antivirus data file was updated”
custom-message-subject “AV data file updated”
4. (Optional) Configure pattern update from an proxy profile.
[edit]
set security utm default-configuration anti-virus avira-engine pattern-update proxy-profile
proxy-profile <proxy-profile>
Use this option in case your internal network device do not have direct access to the Internet and the
device can reach the Internet only through a proxy server.
5. (Optional) Configure on-box antivirus to heavy mode.
[edit]
user@host# set chassis onbox-av-load-flavor heavy
This step allocates additional resources for improved performance.
To use the antivirus scan in light mode, use the delete chassis onbox-av-load-flavor heavy command.
Reboot the device once you change the modes.
6. (Optional) Change the operating mode from the default continuous delivery function (CDF) to hold
mode. When you change to hold mode, the system withhold all the packets until you get the final
result.
[edit]
user@host# set security utm default-configuration anti-virus forwarding-mode hold
For more details on CDF mode and Inline Tap mode, see forwarding-mode.
37
Configure Avira Antivirus Scanning with Custom Profile
You must complete the steps as in Table 2 on page 37 to configure Avira antivirus with custom options
on your security device.
Table 2: Steps for Avira Antivirus Scanning Using Custom Profile
Step Details
Step 1: Define custom objects In this step, you will define antivirus scanning options:
• MIME allowlist—Include type of traffic that you want to bypass antivirus

scanning
• MIME exception list—Specify excluding some MIME types from the MIME
allowlist
• Custom URL categories—Define URLs that you want to bypass antivirus

scanning.
Alternatively, you can use the default list junos-default-bypass-mime.
Step 2: Create antivirus feature • Apply MIME list, exception list, and custom URL category created in step 1
profile to the antivirus feature profile.
• Configure antivirus scanning settings such as data file update interval,

notification options for administrators, fallback options, and file size limits.
Step 3: Create UTM policy Associate the antivirus profile created in Step 2 for FTP, HTTP, POP3, SMTP,
and IMAP traffic. UTM policies control which protocol traffic is sent to the
antivirus scanning engine.
Step 4: Apply UTM policy to a Specify UTM policy as application services in the security policy. The UTM
security policy antivirus settings are applied for the traffic that matches the security policy
rules.
See scan-options and trickling to understand about the scanning configuration parameters available for
antivirus feature.
To quickly configure this section of the example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network configuration, copy
38
and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from
configuration mode.
set security utm default-configuration anti-virus type avira-engine

set security utm custom-objects mime-pattern Mime_1 value video/
set security utm custom-objects mime-pattern Mime_exception value video/x-shockwave-flash
set security utm custom-objects url-pattern Pattern_List_1 value www.juniper.net
set security utm custom-objects custom-url-category Cust_URL_Cat value Pattern_List_1
set security utm feature-profile anti-virus profile Avira-AV-Profile fallback-options default
log-and-permit
set security utm feature-profile anti-virus profile Avira-AV-Profile fallback-options content-
size block
set security utm feature-profile anti-virus profile Avira-AV-Profile fallback-options engine-not-
ready log-and-permit
set security utm feature-profile anti-virus profile Avira-AV-Profile fallback-options timeout
log-and-permit
set security utm feature-profile anti-virus profile Avira-AV-Profile fallback-options out-of-
resources log-and-permit
set security utm feature-profile anti-virus profile Avira-AV-Profile fallback-options too-many-
requests log-and-permit
set security utm feature-profile anti-virus profile Avira-AV-Profile notification-options
fallback-block type protocol-only
fallback-block notify-mail-sender
fallback-block custom-message " fallback block action occured “
fallback-block custom-message-subject " Antivirus Fallback Alert "
set security utm feature-profile anti-virus profile Avira-AV-Profile mime-whitelist list Mime_1
set security utm feature-profile anti-virus profile Avira-AV-Profile url-whitelist Cust_URL_Cat
set security utm feature-profile anti-virus profile Avira-AV-Profile mime-whitelist list
Mime_exception
set security utm utm-policy UTM-AV-Policy anti-virus http-profile Avira-AV-Profile
set security utm utm-policy UTM-AV-Policy anti-virus ftp upload-profile Avira-AV-Profile
set security utm utm-policy UTM-AV-Policy anti-virus ftp download-profile Avira-AV-Profile
set security utm utm-policy UTM-AV-Policy anti-virus smtp-profile Avira-AV-Profile
set security utm utm-policy UTM-AV-Policy anti-virus pop3-profile Avira-AV-Profile
set security utm utm-policy UTM-AV-Policy anti-virus imap-profile Avira-AV-Profile
set security policies from-zone trust to-zone untrust policy POLICY-1 match source-address any
set security policies from-zone trust to-zone untrust policy POLICY-1 match destination-address
any
set security policies from-zone trust to-zone untrust policy POLICY-1 match application any
39
set security policies from-zone trust to-zone untrust policy POLICY-1 then permit application-
services utm-policy UTM-AV-Policy
NOTE: The [edit security utm feature-profile] hierarchy level is deprecated in Junos OS Release
18.2R1. For more information, see "UTM Overview" on page 2.
To configure the on-device antivirus feature profile using the CLI:
1. Enable Avira antivirus scan on your security device if you have not already enabled..
[edit]
user@host# set security utm default-configuration anti-virus type avira-engine
After configuring Avira as the antivirus type, reboot the device for the new scan engine to take
effect.
2. Create custom objects.
[edit]
user@host# set security utm custom-objects mime-pattern Mime_1 value video/
user@host# set security utm custom-objects mime-pattern Mime_exception value video/x-shockwave-
flash
user@host# set security utm custom-objects url-pattern Pattern_List_1 value www.juniper.net
user@host# set security utm custom-objects custom-url-category Cust_URL_Cat value
Pattern_List_1
3. Create the antivirus profile.
[edit]
user@host# set security utm feature-profile anti-virus profile Avira-AV-Profile
4. Configure a list of fallback options.
[edit]
user@host# set security utm feature-profile anti-virus profile Avira-AV-Profile fallback-
40
options default log-and-permit

options content-size block
options engine-not-ready log-and-permit
options timeout log-and-permit
options out-of-resources log-and-permit
options too-many-requests log-and-permit
Fallback options specify the actions to take when traffic cannot be scanned.
5. Configure notification options for fallback blocking actions.
[edit]
user@host# set security utm feature-profile anti-virus profile Avira-AV-Profile notification-
options fallback-block type protocol-only
options fallback-block notify-mail-sender
options fallback-block custom-message " fallback block action occured “
options fallback-block custom-message-subject " Antivirus Fallback Alert "
6. Configure the antivirus module to use MIME bypass lists and exception lists.
[edit]
user@host# set security utm feature-profile anti-virus profile Avira-AV-Profile mime-whitelist
list Mime_exception
7. Configure the antivirus module to use URL bypass lists. URL allowlists are valid only for HTTP traffic.
In this example you use the lists that you set up earlier.
[edit]
user@host# set security utm feature-profile anti-virus profile Avira-AV-Profile mime-whitelist
list Mime_1
user@host# set security utm feature-profile anti-virus profile Avira-AV-Profile url-whitelist
Cust_URL_Cat
41
8. Configure a UTM policy attach the antivirus feature profile Avira-AV-Profile.
[edit]
user@host# set security utm utm-policy UTM-AV-Policy anti-virus http-profile Avira-AV-Profile
user@host# set security utm utm-policy UTM-AV-Policy anti-virus ftp upload-profile Avira-AV-
Profile
user@host# set security utm utm-policy UTM-AV-Policy anti-virus ftp download-profile Avira-AV-
Profile
user@host# set security utm utm-policy UTM-AV-Policy anti-virus smtp-profile Avira-AV-Profile
user@host# set security utm utm-policy UTM-AV-Policy anti-virus pop3-profile Avira-AV-Profile
user@host# set security utm utm-policy UTM-AV-Policy anti-virus imap-profile Avira-AV-Profile
9. Configure a security policy and apply the UTM policy UTM-AV-Policy as application services for the
permitted traffic.
[edit]
user@host# set security policies from-zone trust to-zone untrust policy POLICY-1 match source-
address any
application any
user@host# set security policies from-zone trust to-zone untrust policy POLICY-1 then permit
application-services utm-policy UTM-AV-Policy
Results
From configuration mode, confirm your configuration by entering the show security utm, show services, and
show security policies commands. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.
user@host# show security utm

custom-objects {
mime-pattern {
Mime_1 {
value video/;
}
Mime_exception {
value video/x-shockwave-flash;
}
42
}
url-pattern {
Pattern_List_1 {
value www.juniper.net;
}
}
custom-url-category {
Cust_URL_Cat {
value Pattern_List_1;
}
}
}
feature-profile {
anti-virus {
profile Avira-AV-Profile {
fallback-options {
default log-and-permit;
content-size block;
engine-not-ready log-and-permit;
timeout log-and-permit;
out-of-resources log-and-permit;
too-many-requests log-and-permit;
}
notification-options {
fallback-block {
type protocol-only;
notify-mail-sender;
custom-message " fallback block action occured ";
custom-message-subject " Antivirus Fallback Alert ";
}
}
mime-whitelist {
list Mime_1;
}
url-whitelist Cust_URL_Cat;
}
}
}
utm-policy P1 {
anti-virus {
http-profile junos-av-defaults;
ftp {
upload-profile junos-av-defaults;
43
download-profile junos-av-defaults;
}
smtp-profile junos-av-defaults;
pop3-profile junos-av-defaults;
imap-profile junos-av-defaults;
}
}
utm-policy UTM-AV-Policy {
anti-virus {
http-profile Avira-AV-Profile;
ftp {
upload-profile Avira-AV-Profile;
download-profile Avira-AV-Profile;
}
smtp-profile Avira-AV-Profile;
pop3-profile Avira-AV-Profile;
imap-profile Avira-AV-Profile;
}
}
[edit]
user@host# show security policies
from-zone untrust to-zone trust {
policy POLICY-1 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
application-services {
utm-policy UTM-AV-Policy;
}
}
}
}
}
44
Verification
IN THIS SECTION
Obtaining Information About the Current Antivirus Status | 44
Validate Avira Antivirus on Your Security Device | 45
To verify the configuration is working properly, use the following steps:
Obtaining Information About the Current Antivirus Status
Purpose
Action
From operational mode, enter the show security utm anti-virus status command to view the antivirus
status.
Sample Output
command-name
user@host>show security utm anti-virus status

Update server: https://update.example-juniper.net/avira
Last result: Downloading certs failed
Scan engine type: avira-engine
Scan engine information: 8.3.52.102
Anti-virus signature version: 8.15.11.42
Onbox AV load flavor: running heavy, configure heavy
Meaning
• Antivirus key expire date—The license key expiration date.

45
• Update server—URL for the data file update server.
• Interval—The time period, in minutes, when the device will update the data file from the update
server.
• Pattern update status—When the data file will be updated next, displayed in minutes.
• Last result—Result of the last update.
• Antivirus signature version—Version of the current data file.
• Scan engine type—The antivirus engine type that is currently running.
• Scan engine information—Version of the scan engine.
Validate Avira Antivirus on Your Security Device
Purpose
Validate whether Avira Antivirus Solution is working on SRX Series Device
Action
Use the safe way of testing the antivirus capability using Eicar.org website. Your security device displays
an error message as shown when you try to download an unsafe file.
Figure 2: Validating Antivirus Solution

46
Meaning
The message indicates that your security device has blocked a malicious content.
Avira Antivirus Solution on SRX Series Devices

Sophos Antivirus Protection
IN THIS SECTION
Sophos Antivirus Protection Overview | 47
Sophos Antivirus Features | 48
Understanding Sophos Antivirus Data File Update | 49
Comparison of Sophos Antivirus to Kaspersky Antivirus | 50
Example: Configuring Sophos Antivirus Custom Objects | 51
Example: Configuring Sophos Antivirus Feature Profile | 55
Example: Configuring Sophos Antivirus UTM Policies | 64
Example: Configuring Sophos Antivirus Firewall Security Policies | 67
Example: Configuring Sophos Antivirus Scanner with SSL Forward Proxy | 70
Managing Sophos Antivirus Data Files | 80
The Sophos antivirus scanner uses a local internal cache to maintain query responses from the external
list server to improve lookup performance. The Sophos antivirus scanning is offered as a less CPU-
intensive alternative to the full file-based antivirus feature. For more information, see the following
topics:
47
Sophos Antivirus Protection Overview
Sophos antivirus is as an in-the-cloud antivirus solution. The virus pattern and malware database is
located on external servers maintained by Sophos (Sophos Extensible List) 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 cache to maintain query responses from the external list server to improve
lookup performance.
Because a significant amount of traffic processed by Juniper Unified Threat Management (UTM) 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.
The full file-based antivirus feature is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, 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
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.
Starting with Junos OS Release 15.1X49-D100, IPv6 pass-through traffic for HTTP, HTTPS, FTP, SMTP,
POP3, IMAP protocols is supported for Sophos antivirus, Web filtering and Content filtering security
features of UTM.
Starting with Junos OS Release 12.3X48-D35 and Junos OS Release 17.3R1, the UTM Sophos antivirus
(SAV) single session throughput is increased for optimizing tcp-proxy forwarding.
Starting from Junos OS Release 19.4R1, the antivirus feature supports implicit and explicit SMTPS,
IMAPS, and POP3S protocol, and supports only explicit passive mode FTPS.
Implicit mode—Connect to SSL/TLS encrypted port using secure channel.
Explicit mode—First connect to unsecured channel, then secure the communication by issuing
STARTTLS command. For POP3S, use STLS command.
SEE ALSO
Understanding TCP Proxy

Enabling TCP Proxy Session to Increase the Network Transmit Speed
48
Sophos Antivirus Features
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 antivirus supports HTTPS traffic—Starting with Junos OS Release 12.3X48-D25 and Junos
OS Release 17.3R1, Sophos antivirus over SSL forward proxy supports HTTPS traffic. Sophos
antivirus over SSL forward proxy does so by intercepting HTTPS traffic passing through the SRX
Series device. The security channel from the SRX Series device is divided as one SSL channel
between the client and the SRX Series device and another SSL channel between the SRX Series
device and the HTTPS server. SSL forward proxy acts as the terminal for both channels and forwards
the cleartext traffic to UTM. UTM extracts the URL and the file checksum information from cleartext
traffic. The Sophos antivirus scanner determines whether to block or permit the requests.
SSL forward proxy does not support client authentication. If client authentication is required by the
server, UTM bypasses the traffic. UTM bypasses the HTTPS traffic under the following conditions:
• If SSL proxy does not parse the first handshake packet from the client, SSL forward proxy
bypasses the traffic.
• If the SSL proxy handshake with the client and server is incomplete because of compatibility
issues, connection drops.
• If the system resource is low, SSL forward proxy cannot handle the new connection and Sophos
antivirus bypasses the traffic.
• If HTTPS traffic hits the allowlist of SSL forward proxy, SSL forward proxy and Sophos antivirus
bypass the traffic.
• Sophos antivirus scan result handling—With Sophos antivirus, the TCP, traffic is closed gracefully
when a virus is found and the data content is dropped.
The following fail mode options are supported: content-size, default, engine-not-ready, out-of-
resource, timeout, and too-many-requests. You can set the following actions: block, log-and-permit,
and permit. Fail mode handling of supported options with Sophos is much the same as with full
antivirus.
• Sophos Uniform Resource Identifier checking—Sophos provides Uniform Resource Identifier (URI)
checking, which is similar to antispam realtime null route list (RBL) lookups. URI checking is a way of
49
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).
If you have a Juniper Networks device protecting an internal network that has no HTTP traffic, or has
webservers that are not accessible to the outside world, you might want to turn off URI checking. If
the webservers are not accessible to the outside world, it is unlikely that they contain URI
information that is in the Sophos URI database. URI checking is on by default.
Starting from Junos OS Release 18.4R1 onwards, the URI checking is off by default.
SEE ALSO

Understanding Sophos Antivirus Data File Update
Sophos antivirus uses a small set of data files that need to be updated periodically. These data files only
contain information on guiding scanning logic and do not contain the full pattern database. The main
pattern database, which includes protection against critical viruses, URI checks, malware, worms,
Trojans, and spyware, is located on remote Sophos Extensible List servers maintained by Sophos.
The Sophos data files are updated over HTTP or HTTPS and can be updated manually or scheduled to
update automatically. With Sophos antivirus:
• The signature database auto-update interval is once a day by default. This interval can be changed.
• There is no interruption in virus scanning capability during the data file update. If the update fails, the
existing data files will continue to be used.
• By default, the URL for Sophos antivirus data file update is http://update.juniper-updates.net/SAV/.
NOTE: The Sophos antivirus scanning feature is a separately licensed subscription service. When
your antivirus license key expires, functionality will no longer work because the pattern lookup
database is located on remote Sophos servers. You have a 30-day grace period in which to
update your license.
50
SEE ALSO
Licenses Required for UTM Features

Comparison of Sophos Antivirus to Kaspersky Antivirus
The Kaspersky and Express Antivirus feature is not supported from Junos OS Release 15.1x49-D10 and
Junos OS Release 17.3R1 onwards. For previous releases, Sophos Antivirus is much like Juniper Express
Antivirus and also has similarities to the Full Antivirus feature:
• Unlike the Juniper Express and Full Antivirus solutions, the antivirus and malware database for
Sophos is stored on a group of remote Sophos Extensible List servers. Queries are performed using
the DNS protocol. Sophos maintains these servers, so there is no need to download and maintain
large pattern databases on the Juniper device. Because the database is remote, and there is a quicker
response to new virus outbreaks. The Antivirus database has no size limitation, but there is a
limitation with the scan file size.
NOTE: Sophos antivirus uses a set of data files that need to 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 automatic download.
• Sophos does not provide the same prescreening detection as Kaspersky Antivirus. Sophos does
provide a similar solution that is part of the Sophos engine and cannot be turned on and off.
• 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.
SEE ALSO

51
Sophos Antivirus Configuration Overview
Sophos antivirus is part of the Unified Threat Management (UTM) feature set, so you first configure
UTM options (custom objects), configure the Sophos Feature, then create a UTM policy and a security
policy. The security policy controls all traffic that is forwarded by the device, and the UTM policy
specifies which parameters to use to scan traffic. The UTM policy is also used to bind a set of protocols
to one or more UTM feature profiles, including Sophos antivirus in this case.
You must complete the following tasks to configure Sophos antivirus:
1. Configure UTM custom objects and MIME lists. See "Example: Configuring Sophos Antivirus Custom
Objects" on page 51,
2. Configure the Sophos antivirus feature profile. See "Example: Configuring Sophos Antivirus Feature
Profile" on page 55.
3. Configure a UTM policy. See "Example: Configuring Sophos Antivirus UTM Policies" on page 64
4. Configure a security policy. See "Example: Configuring Sophos Antivirus Firewall Security Policies" on
page 67.
Example: Configuring Sophos Antivirus Custom Objects
IN THIS SECTION
Requirements | 51
Overview | 52
Configuration | 52
Verification | 55
This example shows you how to create UTM global custom objects to be used with Sophos antivirus.
Requirements
Before you begin, read about UTM custom objects. See "UTM Overview" on page 2.
52
Overview
Configure MIME lists. This includes creating a MIME allowlist and a MIME exception list for antivirus
scanning. In this example, you bypass scanning of QuickTime videos, unless if they contain the MIME
type quicktime-inappropriate.
Configuration
IN THIS SECTION
Procedure | 52
Procedure
GUI Quick Configuration
To configure a MIME list:
1. Click the Configure tab from the taskbar, and then select Security>UTM>Custom Objects.
2. Click the MIME Pattern List tab and then click Add.
3. In the MIME Pattern Name box, type avmime2.
4. In the MIME Pattern Value box, type video/quicktime, and click Add.
5. In the MIME Pattern Value box, type image/x-portable-anympa, and click Add.
6. In the MIME Pattern Value box, type x-world/x-vrml, and click Add.
To configure a MIME exception list:
2. Click the MIME Pattern List tab and then select Add.
3. In the MIME Pattern Name box, type exception-avmime2.
4. In the MIME Pattern Value box, type video/quicktime-inappropriate and click Add.
53
Configure a URL pattern list (allowlist) of URLs or addresses that will be bypassed by antivirus scanning.
After you create the URL pattern list, you will create a custom URL category list and add the pattern list
to it.
NOTE: Because you use URL pattern lists to create custom URL category lists, you must
configure URL pattern list custom objects before you configure custom URL category lists.
To configure a URL pattern allowlist:
2. Click the URL Pattern List tab, and then click Add.
3. In the URL Pattern Name box, enter urlist2.
4. In the URL Pattern Value box, enter http://example.net. (You can also us the IP address of the server
instead of the URL.)
Save your configuration:
1. Click OK to check your configuration and save it as a candidate configuration.
2. If you are done configuring the device, click Actions>Commit.
NOTE: URL pattern wildcard support—The wildcard rule is as follows: \*\.[]\?* and you must
precede all wildcard URLs with http://. You can use “*” only if it is at the beginning of the URL
and is followed by a “.”. You can only use “?” at the end of the URL.
The following wildcard syntax is supported: http://*.example.net, http://www.example.ne?, http://
www.example.n??. The following wildcard syntax is not supported: *.example.net ,
www.example.ne?, http://*example.net, http://*.
To configure antivirus protection using the CLI, you must create your custom objects in the following
order:
1.
54
Create the MIME allowlist.
[edit security utm]

user@host# set custom-objects mime-pattern avmime2 value [video/quicktime image/x-portable-
anymap x-world/x-vrml]
Create the MIME exception list.
[edit security utm]

user@host# set custom-objects mime-pattern exception-avmime2 value [video/quicktime-
inappropriate]
2. Configure a URL pattern list (allowlist) of URLs or addresses that you want to bypass. After you
create the URL pattern list, you create a custom URL category list and add the pattern list to it.
Configure a URL pattern list custom object by creating the list name and adding values to it as
follows. As you use URL pattern lists to create custom URL category lists, you must configure URL
pattern list custom objects before you configure custom URL category lists.
[edit security utm]

user@host# set custom-objects url-pattern urllist2 value [http://www. example.net 192.168.1.5]
NOTE: URL pattern wildcard support—The wildcard rule is as follows: \*\.[]\?* and you must
precede all wildcard URLs with http://. You can only use “*” if it is at the beginning of the URL
and is followed by a “.”. You can only use “?” at the end of the URL.
The following wildcard syntax is supported: http://*.example.net, http://www.example.ne?,
http://www.example.n??. The following wildcard syntax is not supported: *.example.net ,
www.example.ne?, http://*example.net, http://*.
3. Configure a custom URL category list custom object by using the URL pattern list urllist2 that you
created earlier:
[edit security utm]

user@host# set custom-objects custom-url-category custurl2 value urllist2
55
Verification
IN THIS SECTION
Verify the Sophos Antivirus Custom Objects Configuration | 55
Verify the Sophos Antivirus Custom Objects Configuration
Purpose
To verify the Sophos Antivirus custom objects configuration., enter the show security utm custom-objects
command.
Action
From the operational mode, enter the show security utm custom-objects command to verify the Sophos
Antivirus custom objects configuration.
SEE ALSO
Allowlist | 24
Example: Configuring Sophos Antivirus Feature Profile
IN THIS SECTION
Requirements | 56
Overview | 56
Configuration | 56
Verification | 63
56
This example shows you how to configure a Sophos antivirus profile that defines the parameters that
will be used for virus scanning.
Requirements
Before you begin:
• Install a Sophos antivirus license. See Installation and Upgrade Guide.
• Configure custom objects for UTM. See "Example: Configuring Sophos Antivirus Custom Objects" on
page 51.
Overview
The following configuration defines Sophos as the antivirus engine and sets parameters, such as the data
file update interval, notification options for administrators, fallback options, and file size limits.
Configuration
IN THIS SECTION
Procedure | 56
Procedure
The following example shows you how to create a custom Sophos profile. If you want to use the Juniper
Networks preconfigured profile, use the profile named junos-sophos-av-defaults in your UTM policy.
See "Example: Configuring Sophos Antivirus UTM Policies" on page 64.
1. Select and configure the engine type. Because you are configuring Sophos antivirus, you configure
sophos-engine:
57
a. Click the Configure tab from the taskbar, and then select Security>UTM>Anti-Virus.
b. Click the Global Options tab and then click Sophos.
c. Click OK and commit your changes.
2. Return to the antivirus Global Options screen as you did in step 1, and set the following parameters:
a. In the MIME allowlist list, select exception-avmime2.
b. In the URL allowlist list, select custurl2.
c. In the Pattern update interval (sec) box, type 2880.
d. In the box, type the e-mail address that will receive SophosAdmin e-mail data file update
notifications. For example - admin@ example.net.
e. In the Custom message subject box, type Sophos Data File Updated.
f. Click OK to check your configuration and save it as a candidate configuration.
3. Configure a profile for the sophos-engine and set parameters.
a. Click the Configure tab from the taskbar and then select Security>UTM>Anti-Virus. Click Add.
b. In the Add profile box, click the Main tab.
c. In the Profile name box, type sophos-prof1.
d. In the Trickling timeout box, type 180.
When enabling the trickling option, it is important to understand that trickling might send part of
the file to the client during the antivirus scan. It is possible that some of the content could be
received by the client and the client might become infected before the file is fully scanned.
e. URI checking is on by default. To turn it off, clear yes in the URI check box.
f. In the Content size Limit box, type 20000.
g. In the Scan engine timeout box, type 1800.

58
4. Configure fallback settings by clicking the Fallback settings tab. In this example, all fallback options
are set to log and permit. Click Log and permit for the following items: Default action, Content size,
Engine not ready, Timeout, Out of resource, Too many requests.
5. Configure notification options by clicking the Notification options tab. You can configure
notifications for both fallback blocking and fallback nonblocking actions and for virus detection.
To configure notifications for Fallback settings:
a. For Notification type, click Protocol.
b. For Notify mail sender, click yes.
c. In the Custom message box, type Fallback block action occurred.
d. In the Custom message subject box, type ***Antivirus fallback Alert***.
6. To configure notification options for virus detection, click the Notification options cont... tab.
a. For the Notification type option button, select Protocol.
b. For the Notify mail sender option button, select yes.
c. In the Custom message box, type Virus has been detected.
d. In the Custom message subject box, type ***Virus detected***.
8. If you are done configuring the device, click Actions>Commit.
To configure the Sophos antivirus feature profile using the CLI:
The following example shows you how to create a custom Sophos profile. If you want to use the Juniper
Networks preconfigured profile, use the profile named junos-sophos-av-defaults in your UTM policy.
See "Example: Configuring Sophos Antivirus UTM Policies" on page 64.
59
1. Select and configure the engine type. Because you are configuring Sophos antivirus, you configure
sophos-engine.
[edit]
user@host# set security utm default-configuration anti-virus type sophos-engine
2. Commit the configuration.
3. Select a time interval for updating the data files. The default antivirus pattern-update interval is
1440 minutes (every 24 hours). You can choose to leave this default, or you can change it. You can
also force a manual update, if needed. To change the default from every 24 hours to every 48
hours:
[edit security utm default-configuration anti-virus]

user@host# set sophos-engine pattern-update interval 2880
4. Configure the network device with the proxy server details, to download the pattern update from a
remote server:

user@host# set sophos-engine pattern-update proxy
5. In most circumstances, you will not need to change the URL to update the pattern database. If you
do need to change this option, use the following command:

user@host# set sophos-engine pattern-update url http://www.example.net/test-download
6. You can configure the device to notify a specified administrator when data files are updated. This is
an e-mail notification with a custom message and a custom subject line.

user@host# set sophos-engine pattern-update email-notify admin-email admin@example.net
custom-message “Sophos antivirus data file was updated” custom-message-subject “AV data
file updated”
7. Configure a list of fallback options as block, log and permit, or permit. The default setting is log-
and-permit. You can use the default settings, or you can change them.
60
Configure the content size action. In this example, if the content size is exceeded, the action taken
is block.
First create the profile named sophos-prof1.
[edit security utm feature-profile anti-virus]

user@host# set profile sophos-prof1
Configure the content size fallback-option to block.
[edit security utm feature-profile anti-virus profile sophos-prof1]

user@host# set fallback-options content-size block
Configure the default fallback option to log-and-permit.

user@host# set fallback-options default log-and-permit
Configure log-and-permit if the antivirus engine is not ready.

user@host# set fallback-options engine-not-ready log-and-permit
Configure log-and-permit if the device is out of resources.

user@host# set fallback-options out-of-resources log-and-permit
Configure log-and-permit if a virus scan timeout occurs.

user@host# set fallback-options timeout log-and-permit
Configure log-and-permit if there are too many requests for the virus engine to handle.

user@host# set fallback-options too-many-requests log-and-permit
61
8. Configure notification options. You can configure notifications for fallback blocking, fallback
nonblocking actions, and virus detection.
In this step, configure a custom message for the fallback blocking action and send a notification for
protocol-only actions to the administrator and the sender.

user@host# set notification-options fallback-block custom-message ***Fallback block action
occurred*** custom-message-subject Antivirus Fallback Alert notify-mail-sender type
protocol-only allow email administrator-email admin@example.net
9. Configure a notification for protocol-only virus detection, and send a notification.

user@host#set notification-options virus-detection type protocol-only notify-mail-sender
custom-message-subject ***Virus detected*** custom-message Virus has been detected
10. Configure content size parameters.
When you configure the content-size value, keep in mind that in certain cases, content size is
available in the protocol headers, so the max-content-size fallback is applied before a scan request
is sent. However, in many cases, content size is not provided in the protocol headers. In these cases,
the TCP payload is sent to the antivirus scanner and accumulates until the end of the payload. If the
accumulated payload exceeds the maximum content size value, then max-content-size fallback is
applied. The default fallback action is log and permit, so you may want to change this option to
block, in which case such a packet is dropped and a block message is sent to the client.
In this example, if the content size exceeds 20 MB, the packet is dropped.

user@host# set scan-options content-size-limit 20000
11. URI checking is on by default. To turn off URI checking:

user@host# set scan-options no-uri-check
62
12. Configure the timeout setting for the scanning operation to 1800 seconds.

user@host# set scan-options timeout 1800
13. The Sophos Extensible List servers contain the virus and malware database for scanning operations.
Set the response timeout for these servers to 3 seconds (the default is 2 seconds).

user@host# set scan-options sxl-timeout 3
14. Configure the Sophos Extensible List server retry option to 2 retries (the default is 1).

user@host# set scan-options sxl-retry 2
15. Configure the trickling setting to 180 seconds. If you use trickling, you can also set timeout
parameters. Trickling applies only to HTTP. HTTP trickling is a mechanism used to prevent the
HTTP client or server from timing out during a file transfer or during antivirus scanning.
When you enable the trickling option, keep in mind that trickling might send part of a file to the
client during its antivirus scan. It is therefore possible that some of the content could be received by
the client before the file has been fully scanned.

user@host# set trickling timeout 180
16. Configure the antivirus module to use MIME bypass lists and exception lists. You can use your own
custom object lists, or you can use the default list that ships with the device called junos-default-
bypass-mime. In this example, you use the lists that you set up earlier.

user@host# set mime-whitelist list avmime2
user@host# set mime-whitelist list exception-avmime2
63
17. Configure the antivirus module to use URL bypass lists. If you are using a URL allowlist, this is a
custom URL category you have previously configured as a custom object. URL allowlists are valid
only for HTTP traffic. In this example you use the lists that you set up earlier.

user@host# set url-whitelist custurl2
Verification
IN THIS SECTION
Obtaining Information About the Current Antivirus Status | 63
Obtaining Information About the Current Antivirus Status
Purpose
Action
status.
user@host>show security utm anti-virus status
Meaning
• Interval—The time period, in minutes, when the device will update the data file from the update
server.
• Pattern update status—When the data file will be updated next, displayed in minutes.
• Last result—Result of the last update. If you already have the latest version, this will display already
have latest database.
64
• Antivirus signature version—Version of the current data file.
• Scan engine type—The antivirus engine type that is currently running.
• Scan engine information—Result of the last action that occurred with the current scan engine.
SEE ALSO

Allowlist | 24
Example: Configuring Sophos Antivirus UTM Policies
IN THIS SECTION
Requirements | 64
Overview | 64
Configuration | 65
Verification | 66
This example shows how to create a UTM policy for Sophos antivirus.
Requirements
Before you create the UTM policy, create custom objects and the Sophos feature profile.
Objects" on page 51.
Overview
After you have created an antivirus feature profile, you configure a UTM policy for an antivirus scanning
protocol and attach this policy to a feature profile. In this example, HTTP will be scanned for viruses, as
65
indicated by the http-profile statement. You can scan other protocols as well by creating different
profiles or adding other protocols to the profile, such as: imap-profile, pop3-profile, and smtp-profile.
Configuration
IN THIS SECTION
Procedure | 65
Procedure
To configure a UTM policy for Sophos antivirus:
1. Click the Configure tab from the taskbar, and then select Security>Policy>UTM Policies. Then click
Add.
2. Click the Main tab. In the Policy name box, type utmp3.
3. Click the Anti-Virus profiles tab. In the HTTP profile list, select sophos-prof1.
5. If you are done configuring the device, select Actions>Commit.
To configure a UTM policy for Sophos antivirus:
1. Go to the edit security utm hierarchy.
[edit]
user@host# edit security utm
66
2. Create the UTM policy utmp3 and attach it to the http-profile sophos-prof1. You can use the default
Sophos feature profile settings by replacing sophos-prof1 in the above statement with junos-sophos-
av-defaults.
[edit security utm]

user@host# set utm-policy utmp3 anti-virus http-profile sophos-prof1
Verification
IN THIS SECTION
Verify the UTM Policy Configuration | 66
Verify the UTM Policy Configuration
Purpose
To verify the UTM policy configuration.
Action
From the operational mode, enter the show security utm utm-policy utmp3 command.
SEE ALSO

67
Example: Configuring Sophos Antivirus Firewall Security Policies
IN THIS SECTION
Requirements | 67
Overview | 67
Configuration | 67
Verification | 69
This example shows how to create a security policy for Sophos antivirus.
Requirements
Before you create the security policy, create custom objects, the Sophos feature profile, and the UTM
policy.
3. Configure a UTM policy. See "Example: Configuring Sophos Antivirus UTM Policies" on page 64.
Overview
Create a firewall security policy that will cause traffic from the untrust zone to the trust zone to be
scanned by Sophos antivirus using the feature profile settings defined in "Example: Configuring Sophos
Antivirus Feature Profile" on page 55. Because the match application configuration is set to any, all
application types will be scanned.
Configuration
IN THIS SECTION
Procedure | 68
68
Procedure
To configure a security policy for Sophos antivirus:
1. Configure the untrust to trust policy to match any source address or destination address, and select
the applications to be scanned to any.
a. Click the Configure tab from the taskbar, and then select Security>Policy>FW Policies. Then
select Add.
b. In the Policy Name box, type p3.
c. In the Policy Action box, select permit.
d. In the From Zone list, select untrust.
e. In the To Zone list, select trust.
f. In the Source Address and Destination Address boxes, make sure that Matched is set to any.
g. In the Applications boxes, select any from the Application/Sets list, and move it to the Matched
list.
2. Attach the UTM policy named utmp3 to the firewall security policy. This will cause matched traffic to
be scanned by the Sophos antivirus feature.
a. From the Edit Policy box, click the Application Services tab.
b. In the UTM Policy list, select utmp3.
4. If you are done configuring the device, select Actions>Commit.
To configure a security policy for Sophos antivirus:

69
1. Configure the untrust to trust policy to match any source-address.
[edit security]
user@host# set policies from-zone untrust to-zone trust policy p3 match source-address any
2. Configure the untrust to trust policy to match any destination-address.
[edit security]
user@host# set policies from-zone untrust to-zone trust policy p3 match destination-address
any
3. Configure the untrust to trust policy to match any application type.
[edit security]
user@host# set policies from-zone untrust to-zone trust policy p3 match application any
4. Attach the UTM policy named utmp3 to the firewall security policy. This will cause matched traffic to
be scanned by the Sophos antivirus feature.
[edit security]
user@host# set policies from-zone untrust to-zone trust policy p3 then permit application-
services utm-policy utmp3
Verification
IN THIS SECTION
Verify the Security Policy Configuration | 70
To verify the configuration, enter the show security policies command.

70
Verify the Security Policy Configuration
Purpose
To verify the security policy configuration, enter the show security policies command.
Action
From the operational mode, enter the show security policies command.
SEE ALSO
Allowlist | 24
Example: Configuring Sophos Antivirus Scanner with SSL Forward Proxy
IN THIS SECTION
Requirements | 70
Overview | 71
Configuration | 71
Verification | 75
This example shows how to configure Sophos antivirus over SSL forward proxy to support HTTPS traffic
passing through SRX Series devices.
NOTE: Starting with Junos OS Release 12.3X48-D25 and Junos OS Release 17.3R1, Sophos
antivirus over SSL forward proxy supports HTTPS traffic.
Requirements
Before you begin, understand Sophos antivirus features. See "Sophos Antivirus Features" on page 48.
71
Overview
In this example, you configure Sophos antivirus over SSL forward proxy to support HTTPS traffic. You
load the PKI certificate, generate a self-signed CA certificate, configure a trusted CA list, configure an
SSL proxy profile using the root certificate, and enable SSL forward proxy. To configure UTM over SSL
forward proxy, first match the source/destination/application, set up the SSL proxy service, and perform
scanning to determine whether to block or permit the requests.
Configuration
IN THIS SECTION
CLI Quick Configuration | 71
Procedure | 72
Results | 73
commands into the CLI at the edit hierarchy level, and then enter commit from configuration mode.
request security pki generate-key-pair certificate-id ssl-inspect-ca size 2048 type rsa
request security pki local-certificate generate-self-signed certificate-id ssl-inspect-ca domain-
name www.example.net subject "CN=www.example.net,OU=IT,O=example,L=Sunnyvale,ST=CA,C=US" email
security-admin@example.net
set security pki ca-profile trusted-ca-example ca-identity trusted-ca-example
request security pki ca-certificate load ca-profile trusted-ca-example filename trusted-ca-
example.crt
set services ssl proxy profile ssl-inspect-profile root-ca ssl-inspect-ca
set services ssl proxy profile ssl-inspect-profile trusted-ca trusted-ca-example
set security policies from-zone untrust to-zone trust policy 1 then permit application-services
ssl-proxy profile-name ssl-inspect-profile
72
Procedure
To configure Sophos Antivirus over SSL forward proxy:
1. Generate a self-signed CA certificate on the device.
user@host> request security pki generate-key-pair certificate-id ssl-inspect-ca size 2048

type rsa
user@host> request security pki local-certificate generate-self-signed certificate-id ssl-
inspect-ca domain-name www.example.net subject
"CN=www.example.net,OU=IT,O=example,L=Sunnyvale,ST=CA,C=US" email security-admin@example.net
2. Configure a trusted CA list.
[edit]
user@host# set security pki ca-profile trusted-ca-example ca-identity trusted-ca-example
user@host> request security pki ca-certificate load ca-profile trusted-ca-example filename

trusted-ca-example.crt
3. Configure an SSL proxy profile using a root certificate.
[edit]
user@host# set services ssl proxy profile ssl-inspect-profile root-ca ssl-inspect-ca
user@host# set services ssl proxy profile ssl-inspect-profile trusted-ca trusted-ca-example
4. Enable SSL forward proxy.
[edit]
user@host# set security policies from-zone untrust to-zone trust policy 1 then permit
application-services ssl-proxy profile-name ssl-inspect-profile
73
Results
From configuration mode, confirm your configuration by entering the show security utm, show services, and
show security policies commands. If the output does not display the intended configuration, repeat the
[edit]
traceoptions {
flag all;
}
application-proxy {
traceoptions {
flag sophos-anti-virus;
}
}
anti-virus {
type sophos-engine;
scan-options {
uri-check;
sxl-timeout 4;
}
traceoptions {
flag all;
}
profile profile1 {
fallback-options {
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;
}
virus-detection {
type message;
}
fallback-block {
type message;
}
74
}
}
}
}
}
utm-policy policy1 {
anti-virus {
http-profile profile1;
}
}
[edit]
ssl {
traceoptions {
file ssl_trace size 1g;
flag all;
}
proxy {
profile ssl-p {
root-ca haojue;
actions {
ignore-server-auth-failure;
}
}
}
}
[edit]
from-zone trust to-zone untrust {
policy trust_2_untrust {
match {
source-address any;
application [ junos-http junos-https ];
}
then {
permit {
ssl-proxy {
profile-name ssl-p;
}
utm-policy policy1;
}
75
}
}
}
}
Verification
IN THIS SECTION
Verifying the Security PKI Local Certificate | 75
Verifying UTM Antivirus Statistics | 76
Verifying UTM Antivirus Statistics Details | 77
Verifying UTM Antivirus Status | 79
To confirm that the configuration is working properly, perform these tasks:
Verifying the Security PKI Local Certificate
Purpose
Verify the security PKI local certificate.
Action
From configurationl mode, enter the show security pki local-certificate command.
user@host# show security pki local-certificate

Certificate identifier: SELF-SIGNED
Issued to: abc, Issued by: CN = abc
Validity:
Not before: 02-20-2015 00:49 UTC
Not after: 02-19-2020 00:49 UTC
Public key algorithm: rsaEncryption(2048 bits)
Certificate identifier: ssl-inspect-ca

Issued to: www.example.net, Issued by: CN = www.example.net, OU = IT, O = example, L =
76
Sunnyvale, ST = CA, C = US
Validity:
Not before: 01-28-2016 22:28 UTC
Not after: 01-26-2021 22:28 UTC
Public key algorithm: rsaEncryption(2048 bits)
Meaning
The sample output confirms that the PKI local ceritificate ssl-inspect-ca is configured.
Verifying UTM Antivirus Statistics
Purpose
Verify UTM antivirus statistics.
Action
From operational mode, enter the show security utm anti-virus statistics command.
user@host> show security utm anti-virus statistics

UTM Anti Virus statistics:
Intelligent-prescreening passed: 0
MIME-whitelist passed: 0
URL-whitelist passed: 0
Session abort: 0
Scan Request:
Total Clean Threat-found Fallback

0 0 0 0
Fallback:
Log-and-Permit Block Permit
Engine not ready: 0 0 0
Out of resources: 0 0 0
Timeout: 0 0 0
Maximum content size: 0 0 0
Too many requests: 0 0 0
77
Decompress error: 0 0 0
Others: 0 0 0
Meaning
The sample output shows the list of UTM antivirus statistics.
Verifying UTM Antivirus Statistics Details
Purpose
Verify UTM antivirus statistics details.
Action
From operational mode, enter the show security utm anti-virus statistics detail command.
user@host> show security utm anti-virus statistics detail

HTTP
URI request:
Total Clean Threat-found Need-further-inspection Abort
10 1 1 8 0
File request:
Total Clean Threat-found Fallback Abort
8 6 1 1 0
Fall back: log-and-permit block permit

Timeout: 0 0 0
Maxmium content size: 1 0 0
Others 0 0 0
FTP
Scan request:
78
10 8 1 1 0

Timeout: 0 0 0
Others 0 0 0
SMTP
Scan request:
10 8 1 1 0

Timeout: 0 0 0
Others 0 0 0
POP3
Scan request:
10 8 1 1 0

Timeout: 0 0 0
Others 0 0 0
IMAP
Scan request:
10 8 1 1 0

79
Timeout: 0 0 0
Others 0 0 0
Meaning
The sample output shows the list of antivirus statistics details.
Verifying UTM Antivirus Status
Purpose
Verify UTM antivirus status.
Action
status.
Anti-virus Key Expiry Date: 07/01/2010 00:00:00

Update server: http://update.juniper-updates.net//
Auto update status: next update in 1440 minutes
Last result: No error
Anti-virus data file info:
Version:
Scan engine information:
Last action result: No error(0x00000000)
Engine type: sophos-engine
Meaning

80
• Interval—The time period, in minutes, when the device updates the data file from the update
server.
• Auto update status—Displays the next automatic update of the data file in minutes.
• Last result—Result of the last database update.
• Antivirus signature version—Version of the current antivirus signature data file.
• Scan engine type—The antivirus scan engine type that is currently running.
• Scan engine information—Result of the last action that occurred with the current scan engine.
SEE ALSO
SSL Proxy Overview
Managing Sophos Antivirus Data Files
Before you begin:
• Install a Sophos antivirus license. See the Installation and Upgrade Guide.
• Configure Sophos as the antivirus feature for the device. See "Example: Configuring Sophos Antivirus
Feature Profile" on page 55. To set the antivirus engine type, you run the set security utm feature-
profile anti-virus type sophos-engine statement.
In this example, you configure the security device to update the data files automatically every 4320
minutes (every 3 days). The default data file update interval is 1440 minutes (every 24 hours).
To automatically update Sophos data files:

user@host# set sophos-engine pattern-update interval 4320
NOTE: The following commands are performed from CLI operational mode.
81
To manually update data files:
user@host> request security utm anti-virus sophos-engine pattern-update
To manually reload data files:
user@host> request security utm anti-virus sophos-engine pattern-reload
To manually delete data files:
user@host> request security utm anti-virus sophos-engine pattern-delete
To check the status of antivirus, which also shows the data files version:
To check the status of the proxy server:
SEE ALSO
Understanding UTM Licensing
Release Description
15.1X49-D100 Starting with Junos OS Release 15.1X49-D100, IPv6 pass-through traffic for HTTP, HTTPS, FTP,
SMTP, POP3, IMAP protocols is supported for Sophos antivirus, Web filtering and Content
filtering security features of UTM.
15.1X49-D10 The full file-based antivirus feature is not supported from Junos OS Release 15.1X49-D10 and
Junos OS Release 17.3R1 onwards.
15.1X49-D10 The Kaspersky and Express Antivirus feature is not supported from Junos OS Release 15.1x49-
D10 and Junos OS Release 17.3R1 onwards.
82
12.3X48-D35 Starting with Junos OS Release 12.3X48-D35 and Junos OS Release 17.3R1, the UTM Sophos
antivirus (SAV) single session throughput is increased for optimizing tcp-proxy forwarding.
12.3X48-D25 Starting with Junos OS Release 12.3X48-D25 and Junos OS Release 17.3R1, Sophos antivirus
over SSL forward proxy supports HTTPS traffic.
12.3X48-D25 Starting with Junos OS Release 12.3X48-D25 and Junos OS Release 17.3R1, Sophos antivirus
over SSL forward proxy supports HTTPS traffic.
Licenses Required for UTM Features
Enabling TCP Proxy Session to Increase the Network Transmit Speed
Virus-Detected Notifications
IN THIS SECTION
Configuring Protocol-Only Virus-Detected Notifications (CLI Procedure) | 83
Configuring E-Mail Virus-Detected Notifications (CLI Procedure) | 84
Understanding Custom Message Virus-Detected Notifications | 85
Configuring Custom Message Virus-Detected Notifications (CLI Procedure) | 85
Virus-Detected notification is used to notify the sender or the recipient about the detected viruses or
the scanning errors. For more information, see the following topics:
83
Understanding Protocol-Only Virus-Detected Notifications
The Protocol-Only Virus-Detected Notifications are not supported from Junos OS Release 15.1X49-
D10 and Junos OS Release 17.3R1 onwards. For previous releases, when content is blocked because a
virus is found or a scan error occurs, the client generally still receives a successful response code but
with modified content (file replacement) containing a warning message. But with protocol-only
notifications, a protocol-specific error code may be returned to the client. This way, the client
determines that a virus was detected rather than interpreting that a file transfer succeeded.
Configuring Protocol-Only Virus-Detected Notifications (CLI Procedure)
The Protocol-Only Virus-Detected Notifications are not supported from Junos OS Release 15.1X49-
D10 and Junos OS Release 17.3R1 onwards. For previous releases, to configure protocol-only virus-
detected notifications, use the following CLI configuration statements:
security utm feature-profile anti-virus kaspersky-lab-engine profile name {

virus-detection {
type { protocol-only | message }
}
fallback-block {
type { protocol-only | message }
}
}
}
}
Understanding E-Mail Virus-Detected Notifications
The E-Mail Virus-Detected Notifications are not supported from Junos OS Release 15.1X49-D10 and
Junos OS Release 17.3R1 onwards. For previous releases, for mail protocols (SMTP, POP3, IMAP), e-mail
84
notification is used to notify the sender or the recipient about the detected viruses or the scanning
errors. There are three settings for e-mail notifications:
• virus-detection/notify-mail-sender — This setting is used when a virus is detected. If it is enabled, an

e-mail is sent to the sender upon virus detection.
• fallback-block/notify-mail-sender — This setting is used when other scan codes or scanning errors
are returned and the message is dropped. If it is enabled, an e-mail is sent to the sender when an
error code is returned.
• fallback-non-block/notify-mail-recipient — This setting is used when other scan codes or scanning

errors are returned and the message is passed. If it is enabled, the e-mail sent to the recipient is
tagged when an error code is returned.
Configuring E-Mail Virus-Detected Notifications (CLI Procedure)
The E-Mail Virus-Detected Notifications are not supported from Junos OS Release 15.1X49-D10 and
Junos OS Release 17.3R1 onwards. For previous releases, to configure the system to send e-mail
notifications when viruses are detected, use the following CLI configuration statements:

virus-detection {
notify-mail-sender
}
fallback-block {
notify-mail-sender
}
fallback-non-block {
notify-mail-recipient
}
}
}
}
85
Understanding Custom Message Virus-Detected Notifications
The Custom Message Virus-Detected Notifications are not supported from Junos OS Release 15.1X49-
D10 and Junos OS Release 17.3R1 onwards. For previous releases, custom message notifications are
mainly used in file replacement or in a response message when the antivirus scan result is to drop the
file. When using custom messages, you can provide a customized message in the message content you
can define customized subject tags.
NOTE: Custom-message in fallback-nonblock is used only by mail protocols.
Configuring Custom Message Virus-Detected Notifications (CLI

Procedure)
The Custom Message Virus-Detected Notifications are not supported from Junos OS Release 15.1X49-
D10 and Junos OS Release 17.3R1 onwards. For previous releases, to configure the system to send
custom messages when viruses are detected, use the following CLI configuration statements:

virus-detection {
custom-message msg
custom-message-subject subject-msg
}
fallback-block {
custom-message msg
}
custom-message msg
}
}
}
}
86
Release Description
15.1X49-D10 The Protocol-Only Virus-Detected Notifications are not supported from Junos OS Release
15.1X49-D10 and Junos OS Release 17.3R1 onwards.
15.1X49-D10 The Protocol-Only Virus-Detected Notifications are not supported from Junos OS Release
15.1X49-D10 The E-Mail Virus-Detected Notifications are not supported from Junos OS Release 15.1X49-D10
and Junos OS Release 17.3R1 onwards.
15.1X49-D10 The E-Mail Virus-Detected Notifications are not supported from Junos OS Release 15.1X49-D10
15.1X49-D10 The Custom Message Virus-Detected Notifications are not supported from Junos OS Release
15.1X49-D10 The Custom Message Virus-Detected Notifications are not supported from Junos OS Release

87
HTTP Trickling to Prevent Timeouts
IN THIS SECTION
HTTP trickling is a mechanism used to prevent the HTTP client or server from timing-out during a file
transfer or during antivirus scanning. For more information, see the following topics:
Understanding HTTP Trickling
transfer or during antivirus scanning. On some slow link transferring, a large file could timeout if too
much time is taken for the antivirus scanner to scan a complex file.
For Sophos Antivirus, the HTTP trickling is supported from Junos OS Release 10.1R1. Starting from
Junos OS Release 15.1X49-D10 and Junos OS Release 17.3R1, Kaspersky Anitvirus support is
discontinued. For Avira Antivirus, the HTTP Trickling is supported from Junos OS Release 18.4R1.
HTTP trickling is the forwarding of specified amounts of 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 security device forwards small amounts of data in advance of transferring an entire
scanned file.)
HTTP Trickling is time-based and there is only one parameter, the time-out interval, to configure for this
feature. By default, trickling is disabled.
The timeout based trickling is packet driven. This means, if no packet is received within a certain time
frame, HTTP trickling is discontinued. This setting is only supported for HTTP connections.
88
Configuring HTTP Trickling to Prevent Timeouts During Antivirus

Scanning (CLI Procedure)
To configure HTTP trickling, use the following CLI configuration statements:
security utm feature-profile anti-virus kaspersky-lab-engine {

profile name {
trickling timeout seconds;
}
}
Release Description
18.4R1 For Avira Antivirus, the HTTP Trickling is supported from Junos OS Release 18.4R1.
15.1X49-D10 Starting from Junos OS Release 15.1X49-D10 and Junos OS Release 17.3R1, Kaspersky Anitvirus
support is discontinued.

3 CHAPTER
Antispam Filtering
Server-Based Antispam Filtering | 92
Local-List Antispam Filtering | 102

90
Antispam Filtering Overview
IN THIS SECTION
Antispam filtering allows you to tag or block unwanted e-mail traffic by scanning inbound and outbound
SMTP e-mail traffic. Antispam filtering allows you to use both a third-party server-based spam block list
(SBL) and to optionally create your own local allowlists and blocklists for filtering against e-mail
messages. For more information, see the following topics:
IN THIS SECTION
Handling Spam Messages | 91
Spam consists of unwanted e-mail messages, usually sent by commercial, malicious, or fraudulent
entities. 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.
Antispam filtering allows you to use both a third-party server-based spam block list (SBL) and to
optionally create your own local allowlists (benign) and blocklists (malicious) for filtering against e-mail
messages. The antispam feature is not meant to replace your antispam server, but to complement it.
Starting in Junos OS Release 18.2R1, the antispam filtering supports IPv6 traffic.
Starting in Junos OS Release 19.4R1, the antispam filtering supports implicit and explicit SMTPS
protocol.

91
STARTTLS command.
Handling Spam Messages
Blocking Detected Spam
The device can block and drop detected spam at either the connection level or the e-mail level:
• Blocking spam at the connection level
When the SMTP sender is identified as a spam sender based on its IP address, the SMTP connection
is rejected and dropped. An error message with a proper error code from the firewall is sent out on
behalf of the SMTP server. An example of such an error message is:
554 Transaction failed due to anti spam setting
• Blocking spam at the e-mail level
When a particular e-mail sender is identified as spam sender based on its sender address, the e-mail
is rejected and dropped. An error message with a proper error code from the firewall is sent back to
the sender on behalf of the server. An example of such an error message is:
550 Requested action not taken: mailbox unavailable
Tagging Detected Spam
The device can allow and tag the e-mail if the message sender is detected as a spammer. This tagging
can occur at the connection level so that all the e-mails for the connection in question are tagged.
Otherwise, you can tag only an individual e-mail. Two tagging methods are supported:
• Tag the subject: A user-defined string is added at the beginning of the subject of the e-mail.
• Tag the header: A user-defined string is added to the e-mail header.
SEE ALSO

92

Server-Based Antispam Filtering
IN THIS SECTION
Server-based spam filtering supports only IP-based spam blocklist lookup. Server-based antispam
filtering requires Internet connectivity with the spam block list (SBL) server. For more information, see
the following topics:
Understanding Server-Based Antispam Filtering
Server-based antispam filtering requires Internet connectivity with the spam block list (SBL) server.
Domain Name Service (DNS) is required to access the SBL server. The firewall performs SBL lookups
through the DNS protocol. The lookups are against the IP address of the sender (or relaying agent) of
the e-mail, adding the name of the SBL server as the authoritative domain. The DNS server then
forwards each request to the SBL server, which returns a DNS response to the device. The device then
interprets the DNS response to determine if the e-mail sender is a spammer.
IP addresses that are included in the block lists are generally considered to be invalid addresses for mail
servers or easily compromised addresses. Criteria for listing an IP address as a spammer on the SBL can
include:
• Running an SMTP open relay service
• Running open proxy servers (of various kinds)
• Being a zombie host possibly compromised by a virus, worm, Trojan, or spyware

93
• Using a dynamic IP range
• Being a confirmed spam source with a known IP address
By default, the device first checks incoming e-mail against local allowlists and blocklists. If there are no
local lists, or if the sender is not found on local lists, the device proceeds to query the SBL server over
the Internet. When both server-based spam filtering and local list spam filtering are enabled, checks are
done in the following order:
1. The local allowlist is checked. If there is a match, no further checking is done. If there is no match...
2. The local blocklist is checked. If there is a match, no further checking is done. If there is no match...
3. The SBL server list is checked.
NOTE:
• SBL server matching stops when the antispam license key is expired.
• Server-based spam filtering supports only IP-based spam blocklist lookup. Sophos updates
and maintains the IP-based spam block list. Server-based antispam filtering is a separately
licensed subscription service. When your antispam license key expires, you can continue to
use locally defined blocklists and allowlists.
When you delete or deactivate a feature profile created for server based antispam filtering for
SBL server, the default SBL server configuration is applied automatically. When a default SBL
server configuration is applied, the default SBL server lookup is enabled. If you want to
disable the default SBL server lookup, that is, you want to configure the no-sbl-default-server
option as a default value, then you must use the set security utm default-configuration anti-spam
sbl no-sbl-default-server command.
SEE ALSO

Server-Based Antispam Filtering Configuration Overview
For each UTM feature, configure feature parameters in the following order:
94
1. Configure UTM custom objects for the feature:
user@host# set security utm custom-objects
2. Configure the main feature parameters, using feature profiles.
user@host# set security utm feature-profile anti-spam
3. Configure a UTM policy for each protocol, and attach this policy to a profile.
user@host# set security utm utm-policy utmp1 anti-spam smtp-profile smtp1
NOTE: Antispam filtering is only supported for the SMTP protocol.
4. Attach the UTM policy to a security policy.
user@host# set security policies from-zone trust to-zone untrust policy p1 then permit
application-services utm-policy utmp1
Example: Configuring Server-Based Antispam Filtering
IN THIS SECTION
Requirements | 95
Overview | 95
Configuration | 95
Verification | 101
This example shows how to configure server-based antispam filtering.

95
Requirements
Before you begin, review how to configure the feature parameters for each UTM feature. See "Server-
Based Antispam Filtering Configuration Overview" on page 93.
Overview
Server-based antispam filtering requires Internet connectivity with the spam block list (SBL) server.
Domain Name Service (DNS) is required to access the SBL server.
Configuration
IN THIS SECTION
Procedure | 95
Procedure
set security utm feature-profile anti-spam sbl profile sblprofile1 sbl-default-server

set security utm feature-profile anti-spam sbl profile sblprofile1 sbl-default-server spam-
action block
set security utm feature-profile anti-spam sbl profile sblprofile1 sbl-default-server custom-tag-
string ***spam***
set security utm utm-policy spampolicy1 anti-spam smtp-profile sblprofile1
set security policies from-zone trust to-zone untrust policy utmsecuritypolicy1 match source-
address any
set security policies from-zone trust to-zone untrust policy utmsecuritypolicy1 match
application junos-smtp
set security policies from-zone trust to-zone untrust policy utmsecuritypolicy1 then permit
application-services utm-policy spampolicy1
96
To configure server-based antispam filtering:
1. Configure a profile and enable/disable the SBL server lookup. Select Configure>Security>UTM>Anti-
Spam.
a. In the Anti-Spam profiles configuration window, click Add to configure a profile for the SBL server,
or click Edit to modify an existing item.
b. In the Profile name box, enter a unique name for the antispam profile that you are creating.
c. If you are using the default server, select Yes next to Default SBL server. If you are not using the
default server, select No.
The SBL server is predefined on the device. The device comes preconfigured with the name and
address of the SBL server. If you do not select Yes, you are disabling server-based spam filtering.
You should disable it only if you are using only local lists or if you do not have a license for server-
based spam filtering.
d. In the Custom tag string box, enter a custom string for identifying a message as spam. By default,
the devices uses ***SPAM***.
e. From the antispam action list, select the action that the device should take when it detects spam.
Options include Tag subject, Block email, and Tag header.
2. Configure a UTM policy for SMTP to which you attach the antispam profile.
a. Select Configure>Security>Policy>UTM Policies.
b. In the UTM policy configuration window, click Add.
c. In the policy configuration window, select the Main tab.
d. In the Policy name box, type a unique name for the UTM policy.
e. In the Session per client limit box, type a session per client limit. Valid values range from 0 to
2000.
97
f. From the Session per client over limit list, select the action that the device should take when the
session per client limit for this UTM policy is exceeded. Options include Log and permit and Block.
g. Select the Anti-Spam profiles tab in the pop-up window.
h. From the SMTP profile list, select an antispam profile to attach to this UTM policy.
a. Select Configure>Security>Policy>FW Policies.
b. In the Security Policy window, click Add to configure a security policy with UTM or click Edit to
modify an existing policy.
c. In the Policy tab, type a name in the Policy Name box.
d. Next to From Zone, select a zone from the list.
e. Next to To Zone, select a zone from the list.
f. Choose a source address.
g. Choose a destination address.
h. Choose an application by selecting junos-smtp (for antispam) in the Application Sets box and
move it to the Matched box.
i. Next to Policy Action, select one of the following: Permit, Deny, or Reject.
When you select Permit for Policy Action, several additional fields become available in the
Applications Services tab, including UTM Policy.
j. Select the Application Services tab.
k. Next to UTM Policy, select the appropriate policy from the list. This attaches your UTM policy to
the security policy.
l. Click OK to check your configuration and save it as a candidate configuration.
m. If the policy is saved successfully, you receive a confirmation, and you must click OK again. If the
profile is not saved successfully, click Details in the pop-up window to discover why.
NOTE:
98
• You must activate your new policy to apply it.
• In SRX Series devices the confirmation window that notifies you that the policy is
saved successfully disappears automatically.
n. If you are done configuring the device, click Commit Options>Commit.
To configure server-based antispam filtering:
1. Create a profile.
[edit security]
user@host# set utm feature-profile anti-spam sbl profile sblprofile1
2. Enable or disable the default SBL server lookup.
[edit security]
user@host# set utm feature-profile anti-spam sbl profile sblprofile1 sbl-default-server
If you are using server-based antispam filtering, you should type sbl-default-server to enable the
default SBL server. (The SBL server is predefined on the device. The device comes preconfigured with
the name and address of the SBL server.) You should disable server-based antispam filtering using the
no-sbl-default-server option only if you are using only local lists or if you do not have a license for
server-based spam filtering.
3. Configure the action to be taken by the device when spam is detected (block, tag-header, or tag-
subject).
[edit security]
user@host# set utm feature-profile anti-spam sbl profile sblprofile1sbl-default-server spam-
action block
99
4. Configure a custom string for identifying a message as spam.
[edit security]
user@host# set utm feature-profile anti-spam sbl profile sblprofile1 sbl-default-server
custom-tag-string ***spam***
5. Attach the spam feature profile to the UTM policy.
[edit security]
user@host# set utm utm-policy spampolicy1 anti-spam smtp-profile sblprofile1
6. Configure a security policy for UTM to which to attach the UTM policy.
[edit]
user@host# set security policies from-zone trust to-zone untrust policy utmsecuritypolicy1
match source-address any
match destination-address any
match application junos-smtp
then permit application-services utm-policy spampolicy1
NOTE: The device comes preconfigured with a default antispam policy. The policy is called
junos-as-defaults. It contains the following configuration parameters:
anti-spam {
sbl {
profile junos-as-defaults {
sbl-default-server;
spam-action block;
custom-tag-string "***SPAM***";
}
}
}
100
Results
From configuration mode, confirm your configuration by entering the show security utm and show security
policies commands. If the output does not display the intended configuration, repeat the configuration
[edit]
feature-profile {
anti-spam {
sbl {
profile sblprofile1 {
sbl-default-server;
spam-action block;
custom-tag-string ***spam***;
}
}
}
utm-policy spampolicy1 {
anti-spam {
smtp-profile sblprofile1;
}
}
[edit]
policy utmsecuritypolicy1 {
match {
source-address any;
application junos-smtp;
}
then {
permit {
utm-policy spampolicy1;
}
}
}
101
}
}
Verification
IN THIS SECTION
Verifying Antispam Statistics | 101
Verifying Antispam Statistics
Purpose
Verify the antispam statistics.
Action
From operational mode, enter the show security utm anti-spam status and show security utm anti-spam
statistics commands.
The following information appears:
SBL Whitelist Server:

SBL Blacklist Server:
msgsecurity.example.net
DNS Server:
Primary : 1.2.3.4, Src Interface: ge-0/0/0
Secondary: 2.3.4.5, Src Interface: ge-0/0/1
Ternary : 0.0.0.0, Src Interface: fe-0/0/2
Total connections: #
Denied connections: #
Total greetings: #
Denied greetings: #
Total e-mail scanned: #
White list hit: #
102
Black list hit: #

Spam total: #
Spam tagged: #
Spam dropped: #
DNS errors: #
Timeout errors: #
Return errors: #
Invalid parameter errors: #
Statistics start time:
Statistics for the last 10 days.
SEE ALSO

spam-action | 678
Allowlist | 24
Local-List Antispam Filtering
IN THIS SECTION
Local List Antispam Filtering Configuration Overview | 103
Antispam filtering allows you to use both a third-party server-based spam block list (SBL) and to
optionally create your own local allowlists (benign) and blocklists (malicious) for filtering against e-mail
messages. The antispam feature is not meant to replace your antispam server, but to complement it. For
103
Understanding Local List Antispam Filtering
When creating your own local allowlist and blocklist for antispam filtering, you can filter against domain
names, e-mail addresses, and/or IP addresses. Pattern matching works a bit differently depending upon
the type of matching in question. For example, pattern matching for domain names uses a longest suffix
match algorithm. If the sender e-mail address has a domain name of aaa.bbb.ccc, the device tries to
match "aaa.bbb.ccc" in the list. If no match is found, it tries to match "bbb.ccc", and then "ccc". IP address
matching, however, does not allow for partial matches.
Antispam filtering uses local lists for matching in the following manner:
1. Sender IP: The sender IP is checked against the local allowlist, then the local blocklist, and then the
SBL IP-based server (if enabled).
2. Sender Domain: The domain name is checked against the local allowlist and then against the local
blocklist.
3. Sender E-mail Address: The sender e-mail address is checked against the local allowlist and then
against the local blocklist.
By default, the device first checks incoming e-mail against the local allowlist and blocklist. If the sender
is not found on either list, the device proceeds to query the SBL server over the Internet. When both
server-based antispam filtering and local list antispam filtering are enabled, checks are done in the
following order:
1. The local allowlist is checked. If there is a match, no further checking is done. If there is no match...
Local blocklist and allowlist matching continues after the antispam license key is expired.
2. The local blocklist is checked. If there is a match, no further checking is done. If there is no match...
3. The SBL server list is checked.
SEE ALSO

Local List Antispam Filtering Configuration Overview
For each UTM feature, configure feature parameters in the following order:
104
1. Configure UTM custom objects for the feature:
user@host# set security utm custom-objects url-pattern url-pattern-name
2. Configure the main feature parameters, using feature profiles.
user@host# set security utm feature-profile anti-spam as-profile-name
3. Configure a UTM policy for each protocol, and attach this policy to a profile.
user@host# set security utm utm-policy utmp1 anti-spam smtp-profile smtp1
Example: Configuring Local List Antispam Filtering
IN THIS SECTION
Requirements | 104
Overview | 105
Configuration | 105
Verification | 111
This example shows how to configure local list antispam filtering.
Requirements
Before you begin, review how to configure the feature parameters for each UTM feature. See "Local List
Antispam Filtering Configuration Overview" on page 103.
105
Overview
Antispam filtering uses local lists for matching. When creating your own local allowlist and blocklist for
antispam filtering, you can filter against domain names, e-mail addresses, and/or IP addresses.
Configuration
IN THIS SECTION
Procedure | 105
Procedure
set security utm custom-objects url-pattern as-black value [150.61.8.134]

set security utm custom-objects url-pattern as-white value [150.1.2.3]
set security utm feature-profile anti-spam address-whitelist as-white
set security utm feature-profile anti-spam sbl profile localprofile1
set security utm feature-profile anti-spam sbl profile localprofile1 spam-action block
set security utm feature-profile anti-spam sbl profile localprofile1 custom-tag-string
***spam***
set security utm utm-policy spampolicy2 anti-spam smtp-profile localprofile1
set security policies from-zone trust to-zone untrust policy utmsecuritypolicy2 match source-
address any
application junos-smtp
set security policies from-zone trust to-zone untrust policy utmsecuritypolicy2 then permit
application-services utm-policy spampolicy2
106
To configure local list antispam filtering:
1. Create local allowlist and blocklist custom objects by configuring a URL pattern list.
a. Select Configure>Security>UTM>Custom Objects.
b. In the UTM custom objects configuration window, select the URL Pattern List tab.
c. Click Add to create URL pattern lists.
d. Next to URL Pattern Name, type a unique name.
NOTE: If you are creating a allowlist, it is helpful to indicate this in the list name. The same
applies to a blocklist. The name you enter here becomes available in the Address Allowlist
and Address Blocklist fields when you are configuring your antispam profiles.
e. Next to URL Pattern Value, type the URL pattern for allowlist or blocklist antispam filtering.
2. Configure antispam filtering to use the allowlist and blocklist custom objects.
a. Select Configure>Security>UTM>Global options.
b. In the right pane, select the Anti-Spam tab.
c. Under Anti-Spam, select an Address Allowlist and/or an Address Blocklist from the list for local
lists for spam filtering. (These lists are configured as custom objects.)
d. Click OK.
e. If the configuration item is saved successfully, you receive a confirmation, and you must click OK
again. If it is not saved successfully, click Details in the pop-up window to discover why.
f. In the left pane under Security, select the Anti-Spam tab.
g. Click Add to configure an anti-spam profile. The profile configuration pop-up window appears.
107
h. In the Profile name box, enter a unique name.
i. If you are using the default server, select Yes beside Default SBL server. If you are not using the
default server, select No.
If you select No, you are disabling server-based spam filtering. You disable it only if you are using
local lists or if you do not have a license for server-based spam filtering.
j. In the Custom tag string box, type a custom string for identifying a message as spam. By default,
the device uses ***SPAM***.
k. In the Actions list, select the action that the device should take when it detects spam. Options
include Tag subject, Block email, and Tag header.
3. Configure a UTM policy for SMTP to which you attach the antispam profile.
a. Select Configure>Security>Policy>UTM Policies.
b. In the UTM policy configuration window, click Add to configure a UTM policy. The policy
configuration pop-up window appears.
c. Select the Main tab.
d. In the Policy name box, type a unique name.
e. In the Session per client limit box, type a session per client limit. Valid values range from 0 through
2000.
f. From the Session per client over limit list, select the action that the device should take when the
g. Select the Anti-Spam profiles tab.
h. From the SMTP profile list, select the antispam profile that you are attaching to this UTM policy.
a. Select Configure>Security>Policy>FW Policies.
b. In the Security Policy window, click Add to configure a security policy with UTM. The policy
c. In the Policy tab, type a name in the Policy Name box.

108
d. Next to From Zone, select a zone from the list.
e. Next to To Zone, select a zone from the list.
f. Choose a source address.
g. Choose a destination address.
h. Choose an application by selecting junos-smtp (for antispam) in the Application Sets box and
move it to the Matched box.
i. Next to Policy Action, select one of the following: Permit, Deny, or Reject.
When you select Permit for policy action, several additional fields become available in the
j. Select the Application Services tab.
k. Next to UTM Policy, select the appropriate policy from the list. This attaches your UTM policy to
the security policy.
l. Click OK to check your configuration and save it as a candidate configuration.
m. If the policy is saved successfully, you receive a confirmation, and you must click OK again. If the
profile is not saved successfully, click Details in the pop-up window to discover why.
NOTE: You must activate your new policy to apply it.
n. If you are done configuring the device, click Commit Options>Commit.
To configure local list antispam filtering:
1. Configure the local list spam blocking by first creating your global local spam lists.
[edit security]
user@host# set utm custom-objects url-pattern as-black value [150.61.8.134]
user@host# set utm custom-objects url-pattern as-white value [150.1.2.3]
109
2. Configure the local list antispam feature profile by first attaching your custom-object blocklist or
allowlist or both.
When both the allowlist and the blocklist are in use, the allowlist is checked first. If there is no match,
then the blocklist is checked.
[edit security]
user@host# set utm feature-profile anti-spam address-whitelist as-white
3. Configure a profile for your local list spam blocking.
Although you are not using the SBL for local list spam blocking, you configure your profile from
within that command similar to the server-based spam blocking procedure.
[edit security]
user@host# set utm feature-profile anti-spam sbl profile localprofile1
4. Configure the action to be taken by the device when spam is detected (block, tag-header, tag-
subject).
[edit security]
user@host# set utm feature-profile anti-spam sbl profile localprofile1 spam-action block
5. Configure a custom string for identifying a message as spam.
[edit security]
user@host# set utm feature-profile anti-spam sbl profile localprofile1 custom-tag-string
***spam***
6. Attach the spam feature profile to the UTM policy.
[edit security]
user@host# set utm utm-policy spampolicy2 anti-spam smtp-profile localprofile1
7. Configure a security policy for UTM, and attach the UTM policy to the security policy.
[edit]
110
match source-address any

match destination-address any
match application junos-smtp
then permit application-services utm-policy spampolicy2
Results
From configuration mode, confirm your configuration by entering the show security utm and show security
policies commands. If the output does not display the intended configuration, repeat the configuration
[edit]
custom-objects {
anti-spam {
url-pattern patternwhite;
address-whitelist as-white;
sbl {
profile localprofile1 {
spam-action block;
custom-tag-string ***spam***;
}
}
}
utm-policy spampolicy2 {
anti-spam {
smtp-profile localprofile1;
}
}
[edit]
policy utmsecuritypolicy2 {
match {
source-address any;
111
application junos-smtp;
}
then {
permit {
utm-policy spampolicy2;
}
}
}
}
}
Verification
IN THIS SECTION
Verifying Antispam Statistics | 111
Verifying Antispam Statistics
Purpose
Verify the antispam statistics.
Action
From operational mode, enter the show security utm anti-spam status and show security utm anti-spam
statistics commands.
The following information appears:

DNS Server:
112

Total connections: #
Denied connections: #
Total greetings: #
Denied greetings: #
Total e-mail scanned: #
White list hit: #
Black list hit: #
Spam total: #
Spam tagged: #
Spam dropped: #
DNS errors: #
Timeout errors: #
Return errors: #
Invalid parameter errors: #
Statistics start time:
Statistics for the last 10 days.
SEE ALSO
spam-action | 678
Allowlist | 24
4 CHAPTER
Content Filtering

114
Content Filtering
IN THIS SECTION
Understanding Content Filtering Protocol Support | 118
Specifying Content Filtering Protocols (CLI Procedure) | 120
Content Filtering Configuration Overview | 121
Example: Configuring Content Filtering Custom Objects | 122
Example: Configuring Content Filtering UTM Policies | 126
Example: Attaching Content Filtering UTM Policies to Security Policies | 128
Monitoring Content Filtering Configurations | 132
Content Filtering provides basic data loss prevention functionality. Content filtering filters traffic is
based on MIME type, file extension, and protocol commands. You can also use the content filter module
to block ActiveX, Java Applets, and other types of content. Content filtering does not require a separate
license. For more information, see the following topics:
Content Filtering Overview
IN THIS SECTION
Content Filtering Based on File Type | 114
Content Filtering Based on File Content | 116
Content Filtering Based on File Type
Previously, content filtering was performed to block or permit certain types of traffic based on the
MIME type, file extension, and protocol command. The content filter controls file transfers across the
115
gateway by checking traffic against configured filter lists. This type of evaluation based on file type is
supported only on Junos OS Releases prior to Junos OS Release 21.4R1.
Starting in Junos OS Release 21.4R1, content evaluation is done based of the file content. The file type-
based evaluation of content is deprecated and the related configurations are hidden.
You can use the legacy functionality if you do not want to migrate to enhanced content filtering
functionality. You will be allowed to use the legacy configurations, but all the legacy configuration knobs
are deprecated and hidden. Also, you will receive system logs and error message warnings when you use
the legacy configuration options.
In this type of evaluation the content filter module evaluates the traffic before all other UTM modules,
except Web Filtering. Therefore, if traffic meets criteria configured in the content-filter, the content-
filter acts first upon this traffic.
You can configure the following types of content filters:
• MIME Pattern Filter — MIME patterns are used to identify the type of traffic in HTTP and MAIL
protocols. There are two lists of MIME patterns that are used by the content filter to determine the
action to be taken. The block MIME list contains a list of MIME type traffic that is to be blocked by
the content filter. The MIME exception list contains MIME patterns that are not to be blocked by the
content filter and are generally subsets of items on the blocklist. Note that the exception list has a
higher priority than the blocklist. If you have MIME entries that appear on both lists, those MIME
types are not blocked by the content filter because the exception list takes priority. Therefore, when
adding items to the exception list, it is to your advantage to be specific.
• Block Extension List — Because the name of a file is available during file transfers, using file
extensions is a highly practical way to block or allow file transfers. The content filter list contains a
list of file extensions to be blocked. All protocols support the use of the block extension list.
• Protocol Command Block and Permit Lists — Different protocols use different commands to
communicate between servers and clients. By blocking or allowing certain commands, traffic can be
controlled on the protocol command level.
The block and permit command lists are intended to be used in combination, with the permit list
acting as an exception list to the blocklist.
If a protocol command appears on the both the permit list and the blocklist, that command is
permitted.
Starting with Junos OS Release 15.1X49-D100, IPv6 pass-through traffic for HTTP, FTP, SMTP,
POP3, IMAP protocols is supported for Web filtering and Content filtering security features of UTM.
Because not all harmful files or components can be controlled by the MIME type or by the file extension,
you can also use the content filter module to block ActiveX, Java Applets, and other types of content.
The following types of content blocking are supported only for HTTP:
116
• Block ActiveX
• Block Java applets
• Block cookies
• Block EXE files
• Block ZIP files
Content Filtering Based on File Content
Content filtering was previously performed based on file type, mime-type, content-type, and protocol
command. File detection using the MIME type, protocol command filters, or by file extension filters is
not reliable always.The easiest way to identify a file type is by file name extensions, but it is not
authentic as any extension can be given to any kind of file.
Starting in Junos OS Release 21.4R1, UTM performs content filtering to determine the file type based
on the file content and not based on the file extensions. The file content is first analyzed to accurately
determine the file type. This feature complements application identification (App ID) and allows you to
configure the firewall for identifying and controlling access to Web (HTTP and HTTPS) traffic and to
protect your network from attacks. When the final application match is confirmed by App ID, the
matching UTM policy is considered for content filtering.
Content filtering based on file content is performed as follows:

117
• File identification: For every file type, there are rules defined to examine the content and determine
the file type. UTM process uses the file content and matches it against the rules defined to
determine the file type.
• Define content filtering rules for traffic direction: The UTM process reads configuration from CLI,
parses and interprets rule-sets and rules. You can define the content filtering rules and enforce the
rules to direct the traffic.
Rule-set and rules configurations are added under the [edit security utm utm-policy <utm-policy-name>
content-filtering] hierarchy level.
You can configure connection reset option in the content filter rule. When the content listed within
the rule is detected, protocol handlers perform TCP connection reset with the client and server
exactly as configured in the policy.
NOTE: Content filtering options based on mime-type, content-type, and protocol command is
not supported. After you upgrade to Junos OS Release 21.4R1, previously existing file
extension based content filtering options under the [edit security utm utm-policy <utm-policy-
name> content-filtering] and [edt security utm feature-profile content-filtering profile <profile-
name>hierarchies are not supported.
• Use the rules and rules sets defined for content filtering: You can use the rules and rule sets defined
above from the [edit security utm default-configuration content-filtering hierarchy. These rules and rule-
set allows you to configure direction specific content filters and connection reset.
• UTM policy selection for content filtering: Once final application match is confirmed by APP ID, the
matching potential UTM policy in which content filtering rules are defined is chosen for processing.
For every UTM policy, a chain is created with list of rule-set nodes and all rules configured under a
rule-set are added to a list and then attached to the respective rule-set node.
After all checks are passed, a unique ID is allocated for each rule-set and rule configured to preserve
and organize respective information in the local memory. This storage in the local memory is required
to track the configuration changes you make and to synchronize the updates.
• Verification: Use the following commands to view the content-filtering system statistics and errors.
• To display content filtering statistics in a policy within root-logical-system use the show security utm
content-filtering statistics utm policy <utm policy name> and show security utm content-filtering
statistics root-logical-system utm-policy <utm policy name> commands.
• To display content filtering statistics in a policy within a specified logical system use the show
security utm content-filtering statistics logical-system <logical-system-name> utm-policy <utm policy name>
command.
118
If you migrate to this new feature and if there are legacy options in your configurations, then you will
receive the following error messages and commit will fail.
Deprecated features can't go together with enhanced content filtering (rule-set/rule)\n");Remove

configuration marked as deprecated to get ahead (For details: show security utm)\n")
You can use legacy content filtering functionality if you don’t want to migrate to the enhanced content
filtering feature. The legacy configuration options are deprecated and are hidden. You will receive the
following error message when you use the deprecated legacy options.
ERRMSG (“The config \'%s\' is deprecated”, “security utm utm-policy <> content-filtering http-profile")
Benefits
• Provides safe web access and protects your network from attacks using accurately detected file-
types in the content filtering rules.
• Controls the traffic that traverses your network and enforces content filtering rules based on traffic
direction.
• Improved log messages to include user and source identity, session ID, and packet direction
information.
SEE ALSO

utm | 748
Allowlist | 24
Understanding Content Filtering Protocol Support
IN THIS SECTION
HTTP Support | 119
FTP Support | 119
E-Mail Support | 119

119
Each supported protocol may implement available content filters differently. Not all filtering capabilities
are supported for each protocol. This topic contains the following sections:
HTTP Support
The HTTP protocol supports all content filtering features. With HTTP, the content filter remains in the
gateway, checking every request and response between the HTTP client and server.
If an HTTP request is dropped due to content filtering, the client receives a response such as:
<custom drop message/user-configured drop message>.<src_port><dst_ip>:<dst_port>Download request

was dropped due to <reason>
Therefore, a message may appear as follows:
Juniper Networks Firewall Content Filtering blocked request. 5.5.5.1:80->4.4.4.1:55247 Download

request was dropped due to file extension block list
FTP Support
The FTP protocol does not support all content filtering features. It supports only the following: Block
Extension List and Protocol Command Block List.
When content filtering blocks an FTP request, the following response is sent through the control
channel:
550 <src_ip>:<src_port>-<dst_ip>:<dst_port><custom drop message/user-configured drop message>

for Content Filtering file extension block list.>
Therefore, a message may appear as follows:
550 5.5.5.1:21->4.4.4.1:45237 Requested action not taken and the request is dropped for Content
Filtering file extension block list
E-Mail Support
E-mail protocols (SMTP, IMAP, POP3) have limited content filtering support for the following features:
Block Extension List, Protocol Command Block List, and MIME Pattern Filtering. Support is limited for e-
mail protocols for the following reasons:
120
• The content filter scans only one level of an e-mail header. Therefore recursive e-mail headers and
encrypted attachments are not scanned.
• If an entire e-mail is MIME encoded, the content filter can only scan for the MIME type.
• If any part of an e-mail is blocked due to content filtering, the original e-mail is dropped and replaced
by a text file with an explanation for why the e-mail was blocked.
Starting from Junos OS Release 19.4R1, the antivirus and content filtering feature supports implicit and
explicit SMTPS, IMAPS, and POP3S protocol, and supports only explicit passive mode FTPS.
STARTTLS command. For POP3S, use STLS command.
SEE ALSO

Specifying Content Filtering Protocols (CLI Procedure)
To configure content filtering protocols, use the following CLI configuration statements:
content-filtering {
profile name {
permit-command cmd-list
block-command cmd-list
block-extension file-ext-list
block-mime {
list mime-list
exception ex-mime-list
}
block-content-type {
activex
java-applet
exe
zip
http-cookie
121
}
type { message }
notify-mail-sender
custom-message msg
}
}
traceoptions {
flag {
all
basic
detail
}
}
}
Content Filtering Configuration Overview
A content security filter blocks or allows certain type of traffic base on the mime type, file extension,
protocol commands and embedded object type. The content filter controls file transfers across the
gateway by checking traffic against configured filter lists. The content filtering module evaluates traffic
before all other UTM modules, if traffic meets the criteria configured in the content filter, the content
filter acts first upon this traffic. The following procedure lists the recommended order in which you
should configure content filters:
1. Configure UTM custom objects for the feature. See "Example: Configuring Content Filtering Custom
2. Configure the main feature parameters using feature profiles. See Example: Configuring Content
Filtering Feature Profiles .
3. Configure a UTM policy for each protocol and attach this policy to a profile. See "Example:
Configuring Content Filtering UTM Policies" on page 126.
4. Attach the UTM policy to a security policy. See "Example: Attaching Content Filtering UTM Policies
to Security Policies" on page 128.
122
Example: Configuring Content Filtering Custom Objects
IN THIS SECTION
Requirements | 122
Overview | 122
Configuration | 122
Verification | 125
This example shows how to configure content filtering custom objects.
Requirements
Before you begin:
1. Decide on the type of content filter you require. See "Content Filtering Overview" on page 114.
2. Understand the order in which content filtering parameters are configured. See "Content Filtering
Configuration Overview" on page 121.
Overview
In this example, you define custom objects that are used to create content filtering profiles. You perform
the following tasks to define custom objects:
1. Create two protocol command lists called ftpprotocom1 and ftpprotocom2, and add user, pass, port,
and type commands to it.
2. Create a filename extension list called extlist2, and add the .zip, .js, and .vbs extensions to it.
3. Define block-mime list call cfmime1 and add patterns to the list.
Configuration
IN THIS SECTION
Procedure | 123
123
Procedure
set security utm custom-objects protocol-command ftpprotocom1 value [user pass port type]
set security utm custom-objects protocol-command ftpprotocom2 value [user pass port type]
set security utm custom-objects filename-extension extlist2 value [zip js vbs]
set security utm custom-objects mime-pattern cfmime1 value [video/quicktime image/x-portable-
set security utm custom-objects mime-pattern ex-cfmime1 value [video/quicktime-inappropriate]
To configure content filtering custom objects:
1. Create two protocol command lists.
[edit security utm]

user@host# set custom-objects protocol-command ftpprotocom1
[edit security utm]
user@host# set custom-objects protocol-command ftpprotocom2
2. Add protocol commands to the list.
[edit security utm]

user@host# set custom-objects protocol-command ftpprotocom1 value [user pass port type]
[edit security utm]
user@host# set custom-objects protocol-command ftpprotocom2 value [user pass port type]
124
3. Create a filename extension list.
[edit security utm]

user@host# set custom-objects filename-extension extlist2
4. Add extensions to the list.
[edit security utm]

user@host# set custom-objects filename-extension extlist2 value [zip js vbs]
5. Create antivirus scanning lists.
[edit security utm]

user@host# set custom-objects mime-pattern cfmime1
user@host# set custom-objects mime-pattern ex-cfmime1
6. Add patterns to the lists.
[edit security utm]

user@host# set custom-objects mime-pattern cfmime1 value [video/quicktime image/x-portable-
user@host# set custom-objects mime-pattern ex-cfmime1 value [video/quicktime-inappropriate]
Results
From configuration mode, confirm your configuration by entering the show security utm command. If the
to correct it.
[edit]
userhost#show security utm
custom-objects {
mime-pattern {
cfmime1 {
value [ video/quicktime image/x-portable-anymap x-world/x-vrml ];
}
ex-cfmime1 {
value video/quicktime-inappropriate;
125
}
}
filename-extension {
extlist2 {
value [ zip js vbs ];
}
}
protocol-command {
ftpprotocom1 {
value [ user pass port type ];
}
}
protocol-command {
ftpprotocom2 {
value [ user pass port type ];
}
}
}
Verification
IN THIS SECTION
Verifying Content Filtering Custom Objects | 125
Verifying Content Filtering Custom Objects
Purpose
Verify the content filtering custom objects.
Action
From operational mode, enter the show configuration security utm command.
126
SEE ALSO
Allowlist | 24
Example: Configuring Content Filtering UTM Policies
IN THIS SECTION
Requirements | 126
Overview | 126
Configuration | 127
Verification | 128
This example describes how to create a content filtering UTM policy to attach to your feature profile.
Requirements
Before you begin:
1. Decide on the type of content filter you require. See "Content Filtering Overview" on page 114.
2. Configure UTM custom objects for each feature and define the content-filtering profile. See "Content
Filtering Configuration Overview" on page 121.
Overview
You configure UTM policies to selectively enforce various UTM solutions on network traffic passing
through a UTM-enabled device. Through feature profiles you associate custom objects to these policies
and specify blocking or permitting certain types of traffic.
In this example, you configure a UTM policy called utmp4, and then assign the preconfigured feature
profile confilter1 to this policy.
127
Configuration
IN THIS SECTION
Procedure | 127
Procedure
To configure a content filtering UTM policy:
You can configure different protocol applications in the UTM policy. The example only shows HTTP and
not other protocols. Earlier you configured custom objects for FTP (ftpprotocom1 and ftpprotocom2).
Next you should add a content filter policy for FTP, for example:
set security utm utm-policy utmp4 content-filtering ftp upload-profile confilter1
set security utm utm-policy utmp4 content-filtering ftp download-profile confilter1
1. Create a UTM policy.
[edit security utm]

user@host# set utm-policy utmp4
2. Attach the UTM policy to the profile.
[edit security utm]

user@host# set utm-policy utmp4 content-filtering http-profile contentfilter1
[edit]
user@host# commit
128
Verification
IN THIS SECTION
Verify the Security UTM Configuration | 128
Verify the Security UTM Configuration
Purpose
To verify the security UTM configuration is working properly.
Action
From the operational mode, enter the show security utm command.
SEE ALSO
Example: Attaching Content Filtering UTM Policies to Security Policies
IN THIS SECTION
Requirements | 129
Overview | 129
Configuration | 129
Verification | 131
This example shows how to create a security policy and attach the UTM policy to the security policy.
129
Requirements
Before you begin:
1. Configure UTM custom objects, define the content filtering profile, and create a UTM policy. See
"Content Filtering Configuration Overview" on page 121.
2. Enable and configure a security policy. See Example: Configuring a Security Policy to Permit or Deny
All Traffic.
Overview
By attaching content filtering UTM policies to security policies, you can filter traffic transiting from one
security zone to another.
In this example, you create a security policy called p4 and specify that traffic from any source address to
any destination address with an HTTP application matches the criteria. You then assign a UTM policy
called utmp4 to the security policy p4. This UTM policy applies to any traffic that matches the criteria
specified in the security policy p4.
Configuration
IN THIS SECTION
Procedure | 129
Procedure
To quickly attach a content filtering UTM policy to a security policy, copy the following commands, paste
them into a text file, remove any line breaks, change any details necessary to match your network
configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter
commit from configuration mode.
[edit]
set security policies from-zone trust to-zone untrust policy p4 match source-address any
set security policies from-zone trust to-zone untrust policy p4 match destination-address any
set security policies from-zone trust to-zone untrust policy p4 match application junos-htttp
130
set security from-zone trust to-zone untrust policy p4 then permit application-services utm-
policy utmp4
To attach a UTM policy to a security policy:
1. Create a security policy.
[edit]
user@host# edit security policies from-zone trust to-zone untrust policy p4
2. Specify the match conditions for the policy.
[edit security policies from-zone trust to-zone untrust policy p4]

user@host# set match source-address any
user@host# set match destination-address any
user@host# set match application junos-http
3. Attach the UTM policy to the security policy.

user@host# set then permit application-services utm-policy utmp4
Results
From configuration mode, confirm your configuration by entering the show security policies command. If
the output does not display the intended configuration, repeat the configuration instructions in this
example to correct it.
[edit]
policy p4 {
match {
131
source-address any;
application junos-http;
}
then {
permit {
utm-policy utmp4;
}
}
}
}
}
default-policy {
permit-all;
}
Verification
IN THIS SECTION
Verifying Attaching Content Filtering UTM Policies to Security Policies | 131
Verifying Attaching Content Filtering UTM Policies to Security Policies
Purpose
Verify the attachment of the content filtering UTM policy to the security policy.
Action
From operational mode, enter the show security policy command.
SEE ALSO

132
Monitoring Content Filtering Configurations
IN THIS SECTION
Purpose | 132
Action | 132
Purpose
View content filtering statistics.
Action
To view content filtering statistics in the CLI, enter the user@host > show security utm content-filtering
statistics command.
The content filtering show statistics command displays the following information:
Base on command list: # Blocked

Base on mime list: # Blocked
Base on extension list: # Blocked
ActiveX plugin: # Blocked
Java applet: # Blocked
EXE files: # Blocked
ZIP files: # Blocked
HTTP cookie: # Blocked
To view content filtering statistics using J-Web:
1. Select Clear Content filtering statisticsMonitor>Security>UTM>Content

FilteringMonitor>Security>UTM>Content Filtering.
The following statistics become viewable in the right pane.
Base on command list: # Passed # Blocked

Base on mime list: # Passed # Blocked
Base on extension list: # Passed # Blocked
ActiveX plugin: # Passed # Blocked
133
Java applet: # Passed # Blocked

EXE files: # Passed # Blocked
ZIP files: # Passed # Blocked
HTTP cookie: # Passed # Blocked
2. You can click Clear Content filtering statistics to clear all current viewable statistics and begin
collecting new statistics.
Release Description
15.1X49-D100 Starting with Junos OS Release 15.1X49-D100, IPv6 pass-through traffic for HTTP, FTP, SMTP,
POP3, IMAP protocols is supported for Web filtering and Content filtering security features of
UTM.

5 CHAPTER
Web Filtering
Safe Search Enhancement for Web Filtering | 216

135
Web Filtering Overview
IN THIS SECTION
Server Name Indication (SNI) Support | 136
The Web filtering lets you to manage Internet usage by preventing access to inappropriate Web content.
There are three types of Web filtering solutions:
• Redirect Web filtering—The redirect Web filtering solution intercepts HTTP and HTTPS requests and
sends them to an external URL filtering server, provided by Websense, to determine whether to
block the requests.
Redirect Web filtering does not require a license.
• Local Web filtering—The local Web filtering solution intercepts every HTTP request and the HTTPS
request in a TCP connection. In this case, the decision making is done on the device after it looks up
a URL to determine if it is in the allowlist or blocklist based on its user-defined category.
Local Web filtering does not require a license or a remote category server.
• Enhanced Web filtering—The enhanced Web filtering solution intercepts the HTTP and the HTTPS
requests and sends the HTTP URL or the HTTPS source IP to the Websense ThreatSeeker Cloud
(TSC). The TSC categorizes the URL into one of the 151 or more categories that are predefined and
also provides site reputation information. The TSC further returns the URL category and the site
reputation information to the device. The device determines if it can permit or block the request
based on the information provided by the TSC.
Starting in Junos OS Release 17.4R1, Websense redirect support IPv6 traffic.
You can bind either Web filtering profiles or antivirus profiles, or both, to a firewall policy. When both
are bound to a firewall policy, Web filtering is applied first, then antivirus is applied. If a URL is blocked
by Web filtering, the TCP connection is closed and no antivirus scanning is necessary. If a URL is
permitted, the content of the transaction is then passed to the antivirus scanning process.
Web filtering is applied by TCP port number.
Web filtering supports HTTPS protocol. Web filtering solution uses the IP address of the HTTPS packet
to make blocklist, allowlist, permit, or block decisions.
136
During a block decision, the Web filtering solution does not generate a block page because the clear text
is not available for a HTTPS session. However, the solution terminates the session and sends resets to
the client and the server for the blocked HTTPS sessions.
Web filtering configuration for HTTP is also applicable for the HTTPS sessions.
The sessions-per-client limit CLI command, which imposes a session throttle to prevent a malicious user
from generating large amounts of traffic simultaneously, does not support Web filtering.
Starting with Junos OS Release 15.1X49-D100, IPv6 pass-through traffic for HTTP, HTTPS, FTP, SMTP,
POP3, IMAP protocols is supported for Web filtering and Content filtering security features of UTM.
Server Name Indication (SNI) Support
SNI is an extension of SSL/TLS protocol to indicate what server name the client is contacting over an
HTTPS connection. SNI inserts the actual hostname of the destination server in "Client Hello" message
in clear text format before the SSL handshake is complete. Web filtering includes SNI information in the
query. In this implementation, the SNI includes only the server name, and not the full URL of the server.
Support of SNI enhances the Web filtering feature as using only destination IP address in the query
might lead to inaccurate results, because multiple HTTP servers might share the same host IP address.
With SNI support, Web filtering analyzes the first packet of the HTTPS traffic as a "Client Hello"
message and extracts the server name from the SNI extension, and uses server name along with the
destination IP address to maintain/run the query. If this packet has no SNI extension or if an error is
encountered during parsing, Web filtering reverts to using only destination IP address.
In Web Filtering (EWF), if HTTPS session with SSL forward proxy is enabled, then the Server Name
Indication (SNI) is obtained before Web filtering and used for pre-check query, site-reputation and
category in response. If the cache is enabled, then these responses populates the cache without any
action. EWF extracts the full path and checks if there is a cache. If the full path in the cache is not
matched, then the EWF sends a query.
The SNI functionality is enabled by default for all types of Web filtering, and therefore, no additional
configuration using the CLI is required.
Release Description
15.1X49-D100 Starting with Junos OS Release 15.1X49-D100, IPv6 pass-through traffic for HTTP, HTTPS, FTP,
SMTP, POP3, IMAP protocols is supported for Web filtering and Content filtering security
features of UTM.
137

Enhanced Web Filtering
IN THIS SECTION
Understanding the Quarantine Action for Enhanced Web Filtering | 167
Example: Configuring Site Reputation Action for Enhanced Web Filtering | 170
TAP Mode Support Overview for UTM | 179
Web Filtering provides URL filtering capability by using either a local Websense server or Internet-based
SurfControl server. For more information, see the following topics:
Enhanced Web Filtering Overview
IN THIS SECTION
User Messages and Redirect URLs for Enhanced Web Filtering (EWF) | 138
138
Enhanced Web Filtering (EWF) with Websense is an integrated URL filtering solution. When you enable
the solution on the device, it intercepts the HTTP and the HTTPS requests and sends the HTTP URL or
the HTTPS source IP to the Websense ThreatSeeker Cloud (TSC). The TSC categorizes the URL into one
of the 95 or more categories that are predefined and also provides site reputation information. The TSC
further returns the URL category and the site reputation information to the device. The device
determines if it can permit or block the request based on the information provided by the TSC.
Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, EWF supports HTTPS traffic
by intercepting HTTPS traffic passing through the SRX Series device. The security channel from the
device is divided as one SSL channel between the client and the device and another SSL channel
between the device and the HTTPS server. SSL forward proxy acts as the terminal for both channels and
forwards the cleartext traffic to the UTM. UTM extracts the URL from the HTTP request message.
You can consider the EWF solution as the next-generation URL filtering solution, building upon the
existing Surf-Control solution.
Enhanced Web Filtering supports the following HTTP methods:
• GET
• POST
• OPTIONS
• HEAD
• PUT
• DELETE
• TRACE
• CONNECT
User Messages and Redirect URLs for Enhanced Web Filtering (EWF)
Starting with Junos OS Release 15.1X49-D110, a new option, custom-message, is added for the custom-
objects command that enables you to configure user messages and redirect URLs to notify users when a
URL is blocked or quarantined for each EWF category. The custom-message option has the following
mandatory attributes:
• Name: Name of the custom message; maximum length is 59 bytes.
• Type: Type of custom message: user-message or redirect-url.
• Content: Content of the custom message; maximum length is 1024 bytes.

139
You configure a user message or redirect URL as a custom object and assign the custom object to an
EWF category.
• User messages indicate that website access has been blocked by an organization's access policy. To
configure a user message, include the type user-message content message-text statement at the [edit
security utm custom-objects custom-message message] hierarchy level.
• Redirect URLs redirect a blocked or quarantined URL to a user-defined URL. To configure a redirect
URL, include the type redirect-url content redirect-url statement at the [edit security utm custom-objects
custom-message message] hierarchy level.
The custom-message option provides the following benefits:
• You can configure a separate custom message or redirect URL for each EWF category.
• The custom-message option allows you to fine-tune messages to support your polices to know which
URL is blocked or quarantined.
Only one custom-message configuration option is applied for each category. The custom-message
configuration is supported only on Enhanced Web Filtering (EWF). Therefore, only the Juniper EWF
engine type is supported.
Starting with Junos OS Release 17.4R1, support for custom category configuration is available for local
and Websense redirect profiles.
SEE ALSO

Understanding the Enhanced Web Filtering Process
IN THIS SECTION
Functional Requirements for Enhanced Web Filtering | 141
140
Web filtering enables you to manage Internet access, preventing access to inappropriate Web content.
The Enhanced Web Filtering (EWF) feature intercepts, scans, and acts upon HTTP or HTTPS traffic in
the following way:
1. The device creates TCP socket connections to the Websense ThreatSeeker Cloud (TSC).
2. The device intercepts an HTTP or an HTTPS connection and extracts URL or hostname or IP address
to perform Web filtering. For an HTTPS connection, EWF is supported through SSL forward proxy.
Starting with Junos OS Release 12.3X48-D25 and Junos OS Release 17.3R1, Enhanced Web Filtering
(EWF) over SSL forward proxy supports HTTPS traffic.
3. The device looks for the URL in the user-configured blocklist or allowlist.
A blocklist or a allowlist action type is a user-defined category in which all the URLs or IP addresses
are always blocked or permitted and optionally logged.
• If the URL is in the user-configured blocklist, the device blocks the URL.
• If the URL is in the user-configured allowlist, the device permits the URL.
4. The device checks the user-defined categories and blocks or permits the URL based on the user-
specified action for the category.
5. The device looks for predefiend category in local cache or from cloud service.
• If the URL is not available in the URL filtering cache, the device sends the URL in HTTP format to
the TSC with a request for categorization. The device uses one of the connections made available
to the TSC to send the request.
• The TSC responds to the device with the categorization and a reputation score.
6. The device performs the following actions based on the identified category:
• If the URL is permitted, the device forwards the HTTP request to the HTTP server.
• If the URL is blocked, the device sends a deny page to the HTTP client and also sends a reset
message to the HTTP server to close the connection
• If the URL is quarantined, the device sends a quarantine page with set-cookie to the HTTP client.
If the client decided to continue, the device permits new request with cookie.
• If the category is configured and the category action is available, the device permits or blocks the
URL based on the category action.
• If the category is not configured, the device permits or blocks the URL based on the global
reputation action.
141
• If the global reputation is not configured, the device permits or blocks the URL based on the
default action configured in the Web filtering profile.
By default, the EWF processes a URL in the order of blocklist, allowlist, custom category, and then
predefined category.
Functional Requirements for Enhanced Web Filtering
The following items are required to use Enhanced Web Filtering (EWF):
• License key— You need to install a new license to upgrade to the EWF solution.
You can ignore the warning message "requires 'wf_key_websense_ewf' license” because it is
generated by routine EWF license validation check.
A grace period of 30 days, consistent with other UTM features, is provided for the EWF feature after
the license key expires.
This feature requires a license. To understand more about UTM Licensing, see, Understanding UTM
Licensing. Please refer to the Licensing Guide for general information about License Management.
Please refer to the product Data Sheets at SRX Series Services Gateways for details, or contact your
Juniper Account Team or Juniper Partner.
When the grace period for the EWF feature has passed (or if the feature has not been installed), Web
filtering is disabled, all HTTP requests bypass Web filtering, and any connections to the TSC are
disabled. When you install a valid license, the connections to the server are established again.
• The debug command provides the following information to each TCP connection available on the
device:
• Number of processed requests
• Number of pending requests
• Number of errors (dropped or timed-out requests)
• TCP connection between a Web client and a webserver—An application identification (APPID)
module is used to identify an HTTP connection. The EWF solution identifies an HTTP connection
after the device receives the first SYN packet. If an HTTP request has to be blocked, EWF sends a
block message from the device to the Web client. EWF further sends a TCP FIN request to the client
and a TCP reset (RST) to the server to disable the connection. The device sends all the messages
through the flow session. The messages follow the entire service chain.
• HTTP request interception—EWF intercepts the first HTTP request on the device and performs URL
filtering on all methods defined in HTTP 1.0 and HTTP 1.1. The device holds the original request
while waiting for a response from the TSC. If the first packet in the HTTP URL is fragmented or if the
device cannot extract the URL for some reason, then the destination IP address is used for the
142
categorization. If you turn on http-reassemble, EWF can recover the whole request from fragment and
get URL.
For HTTP 1.1 persistent connections, the subsequent requests on that session are ignored by the
EWF module.
If the device holds the original request for a long time, then the client will retransmit the request. The
URL filtering code will detect the retransmitted packets. If the original HTTP request has already
been forwarded, then EWF forwards the retransmitted packet to the server. However, if EWF is in
the middle of first-packet processing or makes the calculation to block the session, then the solution
drops the retransmitted packet. A counter tracks the number of retransmitted packets received by
the device.
If the TSC does not respond in time to the categorization request from the device, then the original
client request is blocked or permitted according to the timeout fallback setting.
• HTTPS request interception—Starting with Junos OS 15.1X49-D40 and Junos OS Release 17.3R1,
EWF intercepts HTTPS traffic passing through the SRX Series device. The security channel from the
device is divided as one SSL channel between the client and the device and another SSL channel
between the device and the HTTPS server. SSL forward proxy acts as the terminal for both channels
and forwards the cleartext traffic to the UTM. UTM extracts the URL from the HTTP request
message.
• Blocking message—The blocking message sent to the Web client is user-configurable and is of the
following types:
• The Juniper Networks blocking message is the default message defined in the device that can be
modified by the user. The default blocking message contains the reason why the request is
blocked and the category name (if it is blocked because of a category).
• Syslog message.
For example, if you have set the action for Enhanced_Search_Engines_and_Portals to block, and you
try to access www.example.com, the blocking message is of the following form: Juniper Web
Filtering:Juniper Web Filtering has been set to block this site. CATEGORY:
Enhanced_Search_Engines_and_Portals REASON: BY_PRE_DEFINED . However, the corresponding
syslog message on the device under test (DUT) is: WEBFILTER_URL_BLOCKED: WebFilter:
ACTION="URL Blocked" 56.56.56.2(59418)->74.125.224.48(80)
CATEGORY="Enhanced_Search_Engines_and_Portals" REASON="by predefined category"
PROFILE="web-ewf" URL=www.example.com OBJ=/ .
• Monitoring the Websense server—The URL filtering module uses two methods to determine if the
TSC is active: socket connections and heartbeat. EWF maintains persistent TCP sockets to the TSC.
The server responds with a TCP ACK if it is enabled. EWF sends an application layer NOOP
keepalive to the TSC. If the device does not receive responses to three consecutive NOOP
keepalives in a specific period, it determines the socket to be inactive. The EWF module attempts to
143
open a new connection to the TSC. If all sockets are inactive, the TSC is considered to be inactive.
Therefore an error occurs. The error is displayed and logged. Subsequent requests and pending
requests are either blocked or passed according to the server connectivity fallback setting until new
connections to the TSC are opened again.
• HTTP protocol communication with the TSC—EWF uses the HTTP 1.1 protocol to communicate
with the TSC. This ensures a persistent connection and transmission of multiple HTTP requests
through the same connection. A single HTTP request or response is used for client or server
communication. The TSC can handle queued requests; for optimal performance, an asynchronous
request or response mechanism is used. The requests are sent over TCP, so TCP retransmission is
used to ensure request or response delivery. TCP also ensures that valid in-order, non-retransmitted
HTTP stream data is sent to the HTTP client on the device.
• Responses—The responses adhere to the basic HTTP conventions. Successful responses include a
20x response code (typically 200). An error response includes a 4xx or 5xx code. Error responses in
the 4xx series indicate issues in the custom code. Error responses in the 5xx series indicate issues
with the service.
Error codes and meanings are as follows:
• 400–Bad request
• 403–Forbidden
• 404–Not found
• 408–Request canceled or null response
• 500–Internal server error
Errors in the 400 series indicate issues with the request. Errors in the 500 series indicate issues with
the TSC service. Websense is notified of these errors automatically and responds accordingly.
You can configure the default fallback setting to determine whether to pass or block the request:
set security utm feature-profile web-filtering juniper-enhanced profile juniper-enhanced fallback-settings
default ?
The response also contains the site categorization and site reputation information.
• Categories—A category list is available on the device. This list consists of categories, each containing
a category code, a name, and a parent ID. Categories can also be user-defined. Each category
consists of a list of URLs or IP addresses. Categories are not updated dynamically and are tied to the
Junos OS release because they have to be compiled into the Junos OS image. Any update in
categories needs to be synchronized with the Junos OS release cycle.
Starting with Junos OS Release 17.4R1, you can download and dynamically load new EWF
categories. The downloading and dynamic loading of the new EWF categories do not require a
144
software upgrade. Websense occasionally releases new EWF categories. EWF classifies websites into
categories according to host, URL, or IP address and performs filtering based on the categories.
If the category file transfer fails between the primary and secondary devices, then the file transfer
results in an upgrading error and an error log is generated.
During new category file installation, if the category filename is changed, then the new category file
overwrites the old category file in the internal system and all related output information is replaced
with the new category name.
Starting with Junos OS Release 17.4R1, predefined base filters, defined in a category file, are
supported for individual EWF categories. Each EWF category has a default action in a base filter,
which is attached to the user profile to act as a backup filter. If the categories are not configured in
the user profile, then the base filter takes the action.
A base filter is an object that contains a category-action pair for all categories defined in the category
file. A base filter is a structured object, and is defined with the help of a filter name and an array of
category-action pairs.
The following is an example of a base filter with an array of category-action pairs. For the
Enhanced_Adult_Material category, the action is block; for the Enhanced_Blog_Posting category, the
action is permit; and so on.
{
"predefined-filter": [
{
"filter-name": "ewf-default-filter",
"cat-action-table": [
{"name":"Enhanced_Adult_Material","action":"block"},
{"name":"Enhanced_Blog_Posting","action":"permit"},
{"name":"Enhanced_Blog_Commenting","action":"permit"}
]
}
]
}
EWF supports up to 16 base filters. Junos OS Release 17.4R1 also supports online upgradation of
base filters.
If the user profile has the same name as the base filter, then the Web filter uses the wrong profile.
• Caching—Successfully categorized responses are cached on the device. Uncategorized URLs are not
cached. The size of the cache can be configured by the user.
145
• Safe search (HTTP support only, not HTTPS)—A safe-search solution is used to ensure that the
embedded objects, such as images on the URLs received from the search engines, are safe and that
no undesirable content is returned to the client.
A URL is provided to the TSC to provide categorization information. If it is a search URL, the TSC also
returns a safe-search string. For instance, the safe-search string is safe=active. This safe-search string
is appended to the URL, and a redirect response for redirecting the client's query with safe search is
turned on. This ensures that no unsafe content is returned to the client. If the TSC indicates that it
needs to be safe-searched, then you can perform the safe-search redirect.
For example, the client makes a request to the URL https://www.google.com/search?q=test, which is
permitted by EWF profile. On packet mode, the EWF on the DUT will generate a HTTP 302
response, with the redirect URL: https://www.google.com/search?q=test&safe=active. This response
returns to the client. The client now sends out a safe redirect request to this URL. On stream mode,
the EWF on the DUT rewrites the URL to https://www.google.com/search?q=test&safe=active and
forwards it.
NOTE: Safe-search redirect supports HTTP only. You cannot extract the URL for HTTPS.
Therefore it is not possible to generate a redirect response for HTTPS search URLs. Safe-
search redirects can be disabled by using the CLI option no-safe-search.
• Site reputation—The TSC provides site reputation information. Based on these reputations, you can
choose a block or a permit action. If the URL is not handled by a allowlist or a blocklist and does not
fall in a user or predefined category, then the reputation can be used to perform a URL filtering
decision.
Starting with Junos OS Release 17.4R1, the reputation base scores are configurable. Users can apply
global reputation values, provided by the Websense ThreatSeeker Cloud (TSC). For the non-category
URLs, the global reputation value is used to perform filtering,
The reputation scores are as follows:
• 100-90–Site is considered very safe.
• 80-89–Site is considered moderately safe.
• 70-79–Site is considered fairly safe.
• 60-69–Site is considered suspicious.
• 0-59–Site is considered harmful.
The device maintains a log for URLs that are blocked or permitted based on site reputation scores.
146
• Profiles—A URL filtering profile is defined as a list of categories, with each profile having an action
type (permit, log-and-permit, block, quarantine) associated with it. A predefined profile, junos-wf-
enhanced-default, is provided to users if they choose not to define their own profile.
You can also define an action based on site reputations in a profile to specify the action when the
incoming URL does not belong to any of the categories defined in the profile. If you do not configure
the site reputation handling information, then you can define a default action. All URLs that do not
have a defined category or defined reputation action in their profile will be blocked, permitted,
logged-and-permitted, or quarantined depending on the block or permit handling for the default
action explicitly defined in the profile. If you do not specify a default action, then the URLs will be
permitted. For search engine requests, if there is no explicit user-defined configuration, and the URL
request is without the safe-search option, then EWF generates a redirect response and sends it to
the client. The client will generate a new search request with the safe-search option enabled.
A URL filtering profile can contain the following items:
• Multiple user-defined and predefined categories, each with a permit or block action
• Multiple site reputation handling categories, each with a permit or block action
• One default action with a permit or block action
The order of search is blocklist, allowlist, user-defined category, predefined category, safe-search, site
reputation, and default action.
objects statement that enables you to configure user messages and redirect URLs to notify users when a
• Name: Name of the custom message; maximum length is 59 ASCII characters.
• Content: Content of the custom message; maximum length is 1024 ASCII characters.
EWF category.
147
• The custom-message option allows you to fine-tune messages to support your polices to know which
Only one custom-message configuration option is applied for each category. The custom-message
SEE ALSO
Predefined Category Upgrading and Base Filter Configuration Overview
You can download and dynamically load new Enhanced Web Filtering (EWF) categories without any
software upgrade. The predefined base filters defined in a category file are supported for individual EWF
categories.
To configure a predefined category upgrade without any software upgrade:
1. Configure UTM custom objects for the UTM features. Set the interval, set the start time, and enter
the URL of category package download:
user@host# set security utm custom-objects

user@host# set security utm custom-objects category-package
user@host# set security utm custom-objects category-package automatic
user@host# set security utm custom-objects category-package automatic interval 60
user@host# set security utm custom-objects category-package automatic interval 60 enable
user@host# set security utm custom-objects category-package automatic interval 60 enable
start-time 2017-09-05.08.08.08
user@host# set security utm custom-objects category-package automatic route-instance VRF
148
user@host# set security utm custom-objects category-package automatic route-instance VRF url
https://update.juniper-updates.net/EWF
2. Configure the predefined base filters. Each EWF category has a default action in a base filter, which is
attached to the user profile to act as a backup filter. If the categories are not configured in the user
profile, then the base filter takes the action. You can also upgrade the base filters online.
user@host# set security utm feature-profile web-filtering juniper-enhanced juniper-enhanced-

profile
profile base-filter [base-filter]
profile base-filter [base-filter] category <category-action >
profile base-filter [base-filter] category category-action default <default-action>
profile base-filter [base-filter] category category-action default <default-action>site-
reputation-action <reputation-action>
show security utm custom-objects
category-package{
automatic{
interval 60;
enable;
start-time "2017-09-05.08.08.08";
}
route-instance VRF;
url https://update.juniper-updates.net/EWF;
}
show security utm feature-profile web-filtering juniper-enhanced
server {
host rp.cloud.threatseeker.com;
}
sockets 8;
profile ewf_p1 {
+ base-filter gov-filter;
timeout 15;
149
}
+reputation {
reputation-very-safe 90;
reputation-moderately-safe 80;
reputation-fairly-safe 70;
reputation-suspicious 60;
}
SEE ALSO

Example: Configuring Enhanced Web Filtering
IN THIS SECTION
Requirements | 150
Overview | 150
Configuration | 152
Verification | 164
This example shows how to configure Enhanced Web filtering (EWF) for managing website access. This
feature is supported on all SRX Series devices. The EWF solution intercepts HTTP and the HTTPS
requests and sends the HTTP URL or the HTTPS source IP to the Websense ThreatSeeker Cloud (TSC).
The TSC categorizes the URL into one of the 151 or more predefined categories and also provides site
reputation information. The TSC further returns the URL category and the site reputation information to
the device. The SRX Series device determines whether it can permit or block the request based on the
information provided by the TSC.
150
Requirements
This example uses the following hardware and software components:
• SRX5600 device
• Junos OS Release 12.1X46-D10 or later
Before you begin, you should be familiar with Web filtering and Enhanced Web filtering (EWF). See
"Web Filtering Overview" on page 135 and "Understanding Enhanced Web Filtering Process" on page
139.
Overview
Web filtering is used to monitor and control how users access the website over HTTP and HTTPS. In this
example, you configure a URL pattern list (allowlist) of URLs or addresses that you want to bypass. After
you create the URL pattern list, define the custom objects. After defining the custom objects, you apply
them to feature profiles to define the activity on each profile, apply the feature profile to the UTM
policy, and finally attach the Web filtering UTM policies to the security policies. Table 3 on page 150
shows information about EWF configuration type, steps, and parameters used in this example.
Table 3: Enhanced Web filtering (EWF) Configuration Type, Steps, and Parameters
Configuration Type Configuration Steps Configuration Parameters
URL pattern and custom objects Configure a URL pattern list • [http://www.example.net
(allowlist) of URLs or addresses that 1.2.3.4]
you want to bypass.
• value urllist3
Create a custom object called
urllist3 that contains the pattern • http://www.untrusted.com
http://www.example.net 1.2.3.4
• http://www.trusted.com
Add the urllist3 custom object to • urllistblack

the custom URL category custurl3.
• urllistwhite
Feature profiles Configure the Web filtering feature

profile:
151
Table 3: Enhanced Web filtering (EWF) Configuration Type, Steps, and Parameters (Continued)
• Set the URL blocklist filtering • custwhitelist

category to custblacklist, set
the allowlist filtering category • custblacklist
to custwhitelist, and set the
• juniper-enhanced
type of Web filtering engine to
juniper-enhanced. Then you set • cache size 500
the cache size and cache
timeout parameters. • cache timeout 1800
• Name the EWF server and • rp.cloud.threatseeker.com

enter the port number for
communicating with it. (Default • port 80
port is 80.) Then you create an
EWF profile name. • http-profile my_ewfprofile01
• Select a category from the • http-reassemble

included allowlist and blocklist
categories or select a custom • http-persist
URL category list you created
for filtering against. • Action: log-and-permit
• site-reputation-action:
• very-safe permit
152
Table 3: Enhanced Web filtering (EWF) Configuration Type, Steps, and Parameters (Continued)
• Enter a custom message to be • ewf_my_profile-default block

sent when HTTP requests are
blocked. Finally, enter a timeout • custom-block-message "***access
value in seconds. denied ***"
• fallback-settings:
• server-connectivity block
• timeout block
• too-many-requests block
• quarantine-custom-message “**The
requested webpage is blocked by
your organization's access
policy**”.
• quarantine-message type custom-

redirect-url
• quarantine-message url
besgas.spglab.example.net
• ewf_my_profile-default:
• timeout 10
• no-safe-search
Configuration
IN THIS SECTION
Configuring Enhanced Web Filtering Custom Objects and URL Patterns | 153
Configuring Enhanced Web Filtering Feature Profiles | 156
Attaching Web Filtering UTM Policies to Security Policies | 162

153
This example shows how to configure custom URL patterns, custom objects, feature profiles, and
security policies.
Configuring Enhanced Web Filtering Custom Objects and URL Patterns
configuration mode.
set security utm custom-objects url-pattern urllist3 value http://www.example.net

set security utm custom-objects url-pattern urllist3 value 1.2.3.4
set security utm custom-objects url-pattern urllistblack value http://www.untrusted.com
set security utm custom-objects url-pattern urllistblack value 13.13.13.13
set security utm custom-objects url-pattern urllistwhite value http://www.trusted.com
set security utm custom-objects url-pattern urllistwhite value 11.11.11.11
set security utm custom-objects custom-url-category custurl3 value urllist3
set security utm custom-objects custom-url-category custblacklist value urllistblack
set security utm custom-objects custom-url-category custwhiltelist value urllistwhite
Starting with Junos OS Release 15.1X49-D110, the “* “ in a wildcard syntax, required to create URL
pattern for Web filtering profile, matches all subdomains. For example, *.example.net matches:
• http://a.example.net
• http://example.net
• a.b.example.net
A custom category does not take precedence over a predefined category when it has the same name as
one of the predefined categories. Do not use the same name for a custom category that you have used
for a predefined category.
To configure custom objects and URL patterns in Enhanced Web Filtering:
1. Configure a URL pattern list (allowlist) of URLs or addresses that you want to bypass. After you
create the URL pattern list, you create a custom URL category list and add the pattern list to it.
154
Configure a URL pattern list custom object by creating the list name and adding values to it as
follows:
[edit security utm]

user@host# set custom-objects url-pattern urllist3 value [http://www. example.net 1.2.3.4]
NOTE: The guideline to use a URL pattern wildcard is as follows: Use \*\.[]\?* and precede all
wildcard URLs with http://. You can use “*” only if it is at the beginning of the URL and is
followed by “.”. You can use “?” only at the end of the URL.
The following wildcard syntaxes are supported: http://*.example.net, http://www.example.ne?,
http://www.example.n??. The following wildcard syntaxes are not supported: *.example.???,
http://*example.net, http://?.
2. Create a custom object called urllist3 that contains the pattern http://www.example.net and then add
the urllist3 custom object to the custom URL category custurl3.
[edit security utm]

3. Create a list of untrusted and trusted sites.
[edit security utm]

user@host# set custom-objects url-pattern urllistblack value [http://www.untrusted.com
13.13.13.13]
user@host# set custom-objects url-pattern urllistwhite value [http://www.trusted.com
11.11.11.11]
155
4. Configure the custom URL category list custom object by using the URL pattern list of untrusted and
trusted sites.
[edit security utm]

user@host# set custom-objects custom-url-category custblacklist value urllistblack
user@host# set custom-objects custom-url-category custwhitelist value urllistwhite
Results
From configuration mode, confirm your configuration by entering the show security utm custom-objects
command. If the output does not display the intended configuration, repeat the instructions in this
example to correct.
[edit]
userhost#show security utm custom-objects
url-pattern {
urllist3 {
value [ 1.2.3.4 http://www.example.net ];
}
urllistblack {
value [ 13.13.13.13 http://www.untrusted.com ];
}
urllistwhite {
value [ 11.11.11.11 http://www.trusted.com ];
}
}
custurl3 {
value urllist3;
}
custblacklist {
value urllistblack;
}
custwhiltelist {
value urllistwhite;
}
}
156
Configuring Enhanced Web Filtering Feature Profiles
configuration mode.
Starting in Junos OS Release 12.3X48-D25, new CLI options are available. The http-reassemble and http-
persist options are added in the show security utm feature-profile web-filtering command.
[edit security utm]

set security utm feature-profile web-filtering url-whitelist custwhitelist value
set security utm feature-profile web-filtering url-blacklist custblacklist value
set security utm feature-profile web-filtering juniper-enhanced
set security utm feature-profile web-filtering juniper-enhanced cache size 500
set security utm feature-profile web-filtering juniper-enhanced cache timeout 1800
set security utm feature-profile web-filtering juniper-enhanced server host
rp.cloud.threatseeker.com
set security utm feature-profile web-filtering juniper-enhanced server port 80
set security utm feature-profile web-filtering http-reassemble
set security utm feature-profile web-filtering http-persist
set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile category
Enhanced_Hacking action log-and-permit
set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile category
Enhanced_Government action quarantine
set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile site-
reputation-action very-safe permit
set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile custom-
block-message "***access denied ***"
set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile block-
message type custom-redirect-url
set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile block-
message url http://10.10.121.18
set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile default
block
set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile fallback-
settings server-connectivity block
settings timeout block
157
settings too-many-requests block

set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile timeout
10
set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile no-safe-
search
set security utm utm-policy mypolicy web-filtering http-profile ewf_my_profile
set security policies from-zone utm_clients to-zone mgmt policy 1 then permit application-
services utm-policy mypolicy
set security utm feature-profile web-filtering juniper-enhanced profile ewf-test-profile
quarantine-custom-message “**The requested webpage is blocked by your organization's access
policy**”.
quarantine-message type custom-redirect-url
quarantine-message url besgas.spglab.example.net
To configure the EWF feature profiles:
1. Configure the Web filtering URL blocklist, URL allowlist, and the Web filtering engine.
[edit security utm feature-profile web-filtering]

user@host# set url-blacklist custblacklist
user@host# set url-whitelist custwhitelist
user@host# set juniper-enhanced
2. Set the cache size and cache timeout parameters for the configured EWF engine.

user@host# set juniper-enhanced cache size 500
user@host# set juniper-enhanced cache timeout 1800
158
3. Set the server name or IP address and the port number for communicating with the server. The
default host value in the system is rp.cloud.threatseeker.com.

user@host# set juniper-enhanced server host rp.cloud.threatseeker.com
user@host# set juniper-enhanced server port 80
4. Set the http-reassemble statement to reassemble the requested packet and the http-persist statement
to check every HTTP request packet in the same session. If the http-reassemble statement is not
configured for cleartext HTTP traffic, then EWF does not reassemble the fragmented HTTP request
to avoid incomplete parsing in the packet-based inspection. If the http-persist statement is not
configured for cleartext HTTP traffic, then EWF does not check every HTTP request packet in the
same session.

user@host# set http-reassemble
user@host# set http-persist
5. Create a profile name, and select a category from the included allowlist and blocklist categories.

user@host# set juniper-enhanced profile ewf_my_profile category Enhanced_Hacking action log-
and-permit
user@host# set security utm feature-profile web-filtering juniper-enhanced profile
ewf_my_profile category Enhanced_Government action quarantine
6. Specify the action to be taken depending on the site reputation returned for the URL if there is no
category match found.

user@host#set juniper-enhanced profile ewf_my_profile site-reputation-action very-safe
permit
159
7. Enter a custom message to be sent when HTTP requests are blocked.

user@host# set juniper-enhanced profile ewf_my_profile custom-block-message "***access
denied ***"
8. Define a redirect URL server so that instead of the device sending a block page with plain text
HTML, the device will send an HTTP 302 redirect to this redirect server with some special variables
embedded in the HTTP redirect location field. These special variables can be parsed by the redirect
server and serve a special block page to the client with rich images and formatting.

user@host# set juniper-enhanced profile ewf_my_profile block-message type custom-redirect-
url http://10.10.1.1
user@host# set juniper-enhanced profile ewf_my_profile block-message url http://10.10.121.18
If you configure the security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile
block-message statement, then the default block message configuration takes precedence over the
security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile custom-block-message
configuration.
9. Specify a default action (permit, log and permit, block, or quarantine) for the profile, when no other
explicitly configured action (blocklist, allowlist, custom category, predefined category actions, or
site reputation actions) is matched .

user@host# set juniper-enhanced profile ewf_my_profile default block
10. Configure the fallback settings (block or log and permit) for this profile.

user@host# set juniper-enhanced profile ewf_my_profile fallback-settings default block
user@host# set juniper-enhanced profile ewf_my_profile fallback-settings server-
connectivity block
user@host# set juniper-enhanced profile ewf_my_profile fallback-settings timeout block
user@host# set juniper-enhanced profile ewf_my_profile fallback-settings too-many-requests
block
160
11. Enter a timeout value in seconds. When this limit is reached, fallback settings are applied. This
example sets the timeout value to 10. You can also disable the safe-search functionality. By default,
search requests have safe-search strings attached to them, and a redirect response is sent to ensure
that all search requests are safe or strict.

user@host# set juniper-enhanced profile ewf_my_profile timeout 10
user@host# set juniper-enhanced profile ewf_my_profile no-safe-search
NOTE: The timeout value range for SRX210, SRX220, SRX240, SRX300, SRX320, SRX345,
SRX380, SRX550, SRX1500, SRX4100, and SRX4200 is 0 through 1800 seconds and the
default value is 15 seconds. The timeout value range for SRX3400 and SRX3600 is 1
through 120 seconds and the default value is 3 seconds.
12. Configure a UTM policy (mypolicy) for the Web-filtering HTTP protocol, associating ewf_my_profile
to the UTM policy, and attach this policy to a security profile to implement it.
[edit security utm]

user@host# set utm-policy mypolicy web-filtering http-profile ewf_my_profile
user@host# set security policies from-zone utm_clients to-zone mgmt policy 1 then permit
application-services utm-policy mypolicy
Results
From configuration mode, confirm your configuration by entering the show security utm feature-profile
command. If the output does not display the intended configuration, repeat the instructions in this
example to correct.
[edit]
feature-profile{
web-filtering {
url-whitelist custwhitelist{
url-blacklist custblacklist;
http-reassemble;
http-persist;
juniper-enhanced;
juniper-enhanced {
161
cache {
timeout 1800;
size 500;
}
server {
port 80;
}
profile ewf_my_profile {
category {
Enhanced_Hacking {
action log-and-permit;
}
Enhanced_Government {
action quarantine;
}
}
site-reputation-action {
very-safe permit;
moderately-safe log-and-permit;
fairly-safe log-and-permit;
harmful block;
suspicious block;
}
default block;
custom-block-message "***access denied ***";
fallback-settings {
default block;
server-connectivity block;
timeout block;
too-many-requests block;
}
timeout 10;
no-safe-search;
}
utm-policy mypolicy {
web-filtering {
http-profile ewf_my_profile;
}
}
}
162
Attaching Web Filtering UTM Policies to Security Policies
configuration mode.
set security policies from-zone trust to-zone untrust policy sec_policy match source-address any
set security policies from-zone trust to-zone untrust policy sec_policy match destination-
address any
set security policies from-zone trust to-zone untrust policy sec_policy match application any
set security policies from-zone trust to-zone untrust policy sec_policy then permit application-
services utm-policy mypolicy
1. Create the security policy sec_policy.
[edit]
user@host# set security policies from-zone trust to-zone untrust policy sec_policy
2. Specify the match conditions for sec-policy.
[edit security policies from-zone trust to-zone untrust policy sec_policy]

user@host# set match application any
163
3. Attach the UTM policy mypolicy to the security policy sec_policy.
[edit security policies from-zone trust to-zone untrust policy sec_policy]

user@host# set then permit application-services utm-policy mypolicy
Results
[edit]
sec_policy {
match {
source-address any;
application any;
}
then {
permit {
utm-policy mypolicy;
}
}
}
}
}
default-policy {
permit-all;
}
After you are done configuring the device, enter commit from configuration mode.
164
Verification
IN THIS SECTION
Verifying the Status of the Web Filtering Server | 164
Verifying that Web Filtering Statistics Have Increased | 164
Verifying That the Web Filtering UTM Policy Is Attached to the Security Policy | 166
Verifying the Status of the Web Filtering Server
Purpose
Verify the Web filtering server status.
Action
From the top of the configuration in operational mode, enter the show security utm web-filtering status
command.

UTM web-filtering status:
Server status: Juniper Enhanced using Websense server UP
Meaning
The command output shows that the Web filtering server connection is up.
Verifying that Web Filtering Statistics Have Increased
Purpose
Verify the increase in Web filtering statistics. The initial counter value is 0; if there is an HTTP request
URL hit, then there is a increase in the Web filtering statistics.
165
Action
From the top of the configuration in operational mode, enter the show security utm web-filtering statistics
command.
user@host> show security utm web-filtering statistics

UTM web-filtering statistics:
Total requests: 0
white list hit: 0
Black list hit: 0
Queries to server: 0
Server reply permit: 0
Server reply block: 0
Server reply quarantine: 0
Server reply quarantine block: 0
Server reply quarantine permit: 0
Custom category permit: 0
Custom category block: 0
Custom category quarantine: 0
Custom category qurantine block: 0
Custom category quarantine permit: 0
Site reputation permit: 0
Site reputation block: 0
Site reputation quarantine: 0
Site reputation quarantine block: 0
Site reputation quarantine permit: 0
Site reputation by Category 0
Site reputation by Global 0
Cache hit permit: 0
Cache hit block: 0
Cache hit quarantine: 0
Cache hit quarantine block: 0
Cache hit quarantine permit: 0
Safe-search redirect: 0
SNI pre-check queries to server: 1
SNI pre-check server responses: 1
Web-filtering sessions in total: 128000
Web-filtering sessions in use: 0
Fallback: log-and-permit block
Default 0 0
Timeout 0 0
Connectivity 0 0
166
Too-many-requests 0 0
Meaning
The output displays Web filtering statistics for connections including allowlist and blocklist hits and
custom category hits. If there is an HTTP request URL hit, then there is a increase in the Web filtering
statistics from an earlier value.
Verifying That the Web Filtering UTM Policy Is Attached to the Security Policy
Purpose
Verify that the Web filtering UTM policy mypolicy is attached to the security policy sec_policy.
Action
From operational mode, enter the show security policy command.
user@host> show security policies global policy-name mypolicy detail

node0:
-
Global policies:
Policy: mypolicy, State: enabled, Index: 5, Scope Policy: 0, Sequence number: 1
From zones: zone1, zone2
To zones: zone3, zone4
Source addresses: any
Destination addresses: any
Applications: any
Action: permit
Unified Threat Management: enabled
Meaning
The output displays a summary of all security policies configured on the device. If a particular policy is
specified, it displays information specific to that policy. If UTM is enabled, then mypolicy is attached to
sec_policy.
167
SEE ALSO

Understanding the Quarantine Action for Enhanced Web Filtering
IN THIS SECTION
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 following sequence explains how the HTTP or HTTPs request is intercepted, redirected, and acted
upon by the quarantine action:
• The HTTP client requests URL access.
• The device intercepts the HTTP request and sends the extracted URL to the Websense Thread
Seeker Cloud (TSC).
• The TSC returns the URL category and the site reputation information to the device.
• If the action configured for the category is quarantine, the device logs the quarantine action and
sends a redirect response to HTTP client.
• The URL is sent to the HTTP server for redirecting.
• 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.
• 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.
NOTE: The quarantine action is supported only for UTM Enhanced Web Filtering or Juniper
enhanced type of Web filtering.
168
Quarantine Message
The quarantine message sent to the HTTP client is user-configurable and is of the following types:
• 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.example.com, the quarantine message is as follows:
***The requested webpage is blocked by your organization's access policy***.
• 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.example.com OBJ=/
Starting in Junos OS 12.1X47-D40 and Junos OS Release 17.3R1, the structured log fields have
changed. The structured log field changes in the UTM Web filter logs WEBFILTER_URL_BLOCKED,
WEBFILTER_URL_REDIRECTED, and WEBFILTER_URL_PERMITTED are as follows:
• name -> category
• error-message -> reason
• profile-name -> profile
• object-name -> url
• pathname -> obj

169
objects statement that enables you to configure user messages and redirect URLs to notify users when a
EWF category.
• The custom-message option enables you to fine-tune messages to support your polices to know which
• Only one custom-message configuration option is applied for each category. The custom-message
SEE ALSO

170
Example: Configuring Site Reputation Action for Enhanced Web Filtering
IN THIS SECTION
Requirements | 170
Overview | 170
Configuration | 171
Verification | 175
This example shows how to configure the site reputation action for both categorized and uncategorized
URLs.
Requirements
Before you begin, you should be familiar with Web Filtering and Enhanced Web Filtering. See "Web
Filtering Overview" on page 135 and "Understanding Enhanced Web Filtering Process" on page 139.
Overview
In this example, you configure Web Filtering profiles to URLs according to defined categories using the
site reputation action. You set the URL allowlist filtering category to url-cat-white and the type of Web
Filtering engine to juniper-enhanced. Then you set the cache size parameters for Web Filtering and the
cache timeout parameters to 1.
Then you create a juniper-enhanced profile called profile ewf-test-profile, set the URL allowlist category to
cust-cat-quarantine, and set the reputation action to quarantine.
You enter a custom message to be sent when HTTP requests are quarantined. In this example, the
following message is sent: The requested webpage is blocked by your organization's access policy.
You block URLs in the Enhanced_News_and_Media category and permit URLs in the
Enhanced_Education category. Then you quarantine the URLs in the Enhanced_Streaming_Media
category and configure the device to send the following message: The requested webpage is blocked by your
organization's access policy.
In this example, you set the default action to permit. You select fallback settings (block or log-and-
permit) for this profile in case errors occur in each configured category. Finally, you set the fallback
settings to block.
171
Configuration
IN THIS SECTION
Configuring Site Reputation Action | 171
Configuring Site Reputation Action
set security utm feature-profile web-filtering set url-whitelist url-cat-white

set security utm feature-profile web-filtering juniper-enhanced cache size
set security utm feature-profile web-filtering juniper-enhanced reputation reputation-very-safe
85
set security utm feature-profile web-filtering juniper-enhanced reputation reputation-moderately-
safe 75
set security utm feature-profile web-filtering juniper-enhanced reputation reputation-fairly-
safe 65
set security utm feature-profile web-filtering juniper-enhanced reputation reputation-suspicious
55
set security utm feature-profile web-filtering juniper-enhanced cache timeout 1
category cust-cat-quarantine action quarantine
category Enhanced_News_and_Media action block
category Enhanced_Education action permit
category Enhanced_Education reputation-action harmful block
category Enhanced_Streaming_Media action quarantine
set security utm feature-profile web-filtering juniper-enhanced profile ewf-test-profile default
permit
set security utm feature-profile web-filtering juniper-enhanced profile ewf-test-profile default
quarantine-message “*** The requested webpage is blocked by your organization’s access
172
policy***”.
fallback-settings server-connectivity block
fallback-settings timeout block
To configure the site reputation action:
1. Configure the Web Filtering URL allowlist.

2. Specify the Enhanced Web Filtering engine, and set the cache size parameters.

user@host# set juniper-enhanced cache size
3. Configure the base reputation scores.

set juniper-enhanced reputation reputation-very-safe 85
set juniper-enhanced reputation reputation-moderately-safe 75
set juniper-enhanced reputation reputation-fairly-safe 65
set juniper-enhanced reputation reputation-suspicious 55
NOTE: The base reputation value must be ordered.
4. Set the cache timeout parameters.

user@host# set juniper-enhanced cache timeout 1
173
5. Create a profile name, and select a category from the allowlist categories.

user@host# set juniper-enhanced profile ewf-test-profile category cust-cat-quarantine action
quarantine
6. Create a profile name, and select a category from the allowlist categories.

user@host# set juniper-enhanced profile ewf-test-profile category Enhanced_News_and_Media
action block
user@host# set juniper-enhanced profile ewf-test-profile category Enhanced_Education action
permit
user@host# set juniper-enhanced profile ewf-test-profile category Enhanced_Education action
harmful block
user@host# set juniper-enhanced profile ewf-test-profile category Enhanced_Streaming_Media
action quarantine
7. Enter a warning message to be sent when HTTP requests are quarantined.

user@host# set juniper-enhanced profile ewf-test-profile quarantine-custom-message "***The
requested webpage is blocked by your organization's access policy ***"
8. Select a default action (permit, log-and-permit, block, or quarantine) for the profile, when no other
explicitly configured action (blocklist, allowlist, custom category, predefined category or site
reputation ) is matched .

user@host# set juniper-enhanced profile ewf-test-profile default permit
9. Select fallback settings (block or log-and-permit) for this profile.

user@host# set juniper-enhanced profile ewf-test-profile fallback-settings server-
174
connectivity block
user@host# set juniper-enhanced profile ewf-test-profile fallback-settings timeout block
Results
output does not display the intended configuration, repeat the instructions in this example to correct.
[edit]
feature-profile{
web-filtering {
url-whitelist url-cat-white;
traceoptions;
flag all;
}
juniper-enhanced {
reputation {
reputation-very-safe 85
reputation-moderately-safe 75
reputation-fairly-safe 65
reputation-suspicious 55
cache {
timeout 1
}
profile ewf-test-profile {
category {
cust-cat-quarantine {
action quarantine;
}
Enhanced_News_and_Media {
action block;
reputation-action;
}
Enhanced_Education {
action permit;
reputation-action;
{
harmful block;
}
175
}
Enhanced_Streaming_Media {
action quarantine;
}
}
default permit;
quarantine-custom-message "***The requested webpage is blocked by your organization's
access policy***".
fallback-settings {
timeout block;
}
}
}
}
Verification
IN THIS SECTION
Verifying the Status of UTM Service | 175
Verifying the Status of UTM Session | 176
Verifying the Status of UTM Web Filtering | 176
Verifying the Statistics of UTM Web Filtering | 177
Verifying the URL status using Log file | 178
Confirm that the configuration is working properly.
Verifying the Status of UTM Service
Purpose
Verify the UTM service status.

176
Action
From operational mode, enter the show security utm status command.
Sample Output
command-name
user@host>show security utm status

UTM service status: Running
Verifying the Status of UTM Session
Purpose
Verify the UTM session status.
Action
From operational mode, enter the show security utm session command.
Sample Output
command-name
user@host>show security utm session

UTM session info:
Maximum sessions: 4000
Total allocated sessions: 0
Total freed sessions: 0
Active sessions: 0
Verifying the Status of UTM Web Filtering
Purpose
Verify the UTM Web filtering status.

177
Action
From operational mode, enter the show security utm web-filtering status command.
Sample Output
command-name
user@host>show security utm web-filtering status

Verifying the Statistics of UTM Web Filtering
Purpose
Verify the Web filtering statistics for connections including allowlist and blocklist hits and custom
category hits.
Action
From operational mode, enter the show security utm web-filtering statistics command.
Sample Output
command-name
user@host>show security utm web-filtering statistics

Total requests: 2594
white list hit: 0
Black list hit: 0
178

Cache hit permit: 41
Cache hit block: 0
Default 0 0
Timeout 0 0
Connectivity 0 1
Verifying the URL status using Log file
Purpose
Verify the blocked and allowed URL status using log file.
Action
To see blocked and allowed URLs, send the utm logs to a syslog server using stream mode. For more
information see: Configuring Off-Box Binary Security Log Files.
From operational mode, enter the show log messages | match RT_UTM command.
179
Sample Output
command-name
user@host>show log messages | match RT_UTM

RT_UTM: WEBFILTER_URL_BLOCKED: WebFilter: ACTION="URL Blocked" source-zone="trust" destination-
zone="untrust" 4.0.0.3(59466)->5.0.0.3(80) SESSION_ID=268436912 APPLICATION="UNKNOWN" NESTED-
APPLICATION="UNKNOWN" CATEGORY="URL_Blacklist" REASON="BY_BLACK_LIST" PROFILE="ewf"
URL=www.example1.com OBJ=/ username N/A roles N/A application-sub-category N/A urlcategory-risk 0
SEE ALSO
Allowlist | 24
TAP Mode Support Overview for UTM
In TAP mode, an SRX Series device will be connected to a mirror port of the switch, which provides a
copy of the traffic traversing the switch. An SRX Series device in TAP mode processes the incoming
traffic from TAP interface and generates security log to display the information on threats detected,
application usage, and user details.
Starting in Junos OS Release 19.1R1 you can enable TAP mode on UTM module. When you enable TAP
mode on UTM module, the SRX Series device inspects the incoming and outgoing traffic that matches a
firewall policy or policies with the enabled UTM service. TAP mode can’t block traffic but generates
security logs, reports, and statistics to show the number of threats detected, application usage, and user
details. If some packet gets lost in the TAP interface, the UTM terminates the connection, and the TAP
mode do not generate any security logs, reports, and statistics for this connection. The UTM
configuration remains the same as non-TAP mode.
UTM functionality configured on an SRX Series device continues to work and exchange information
from the server. To use UTM functionality when the SRX Series device is configured in TAP mode, you
must configure the DNS server to resolve the cloud server’s IP addresses.
To use TAP mode, the SRX device will be connected to a mirror port of the switch, which provides a
copy of the traffic traversing the switch. SRX Series device process the incoming traffic from TAP
interface and generates security log information to display the information on threats detected,
application usage, and user details.
When operating in TAP mode, the SRX Series device performs:

180
• Enhanced Web filtering (EWF) for mirrored HTTP traffic.
• Sophos antivirus (SAV) for mirrored HTTP/FTP/SMTP/POP3/IMAP traffic.
• Antispam (AS) for mirrored SMTP traffic.
SEE ALSO

Example: Configuring Security Flow Sessions in TAP mode
[SRX] Example - Configuring TAP Mode Interface
Release Description
17.4R1 Starting with Junos OS Release 17.4R1, support for custom category configuration is available for
local and Websense redirect profiles.
17.4R1 Starting with Junos OS Release 17.4R1, you can download and dynamically load new EWF
categories. The downloading and dynamic loading of the new EWF categories do not require a
software upgrade. Websense occasionally releases new EWF categories. EWF classifies websites
into categories according to host, URL, or IP address and performs filtering based on the
categories.
17.4R1 Starting with Junos OS Release 17.4R1, predefined base filters, defined in a category file, are
supported for individual EWF categories. Each EWF category has a default action in a base filter,
which is attached to the user profile to act as a backup filter. If the categories are not configured
in the user profile, then the base filter takes the action.
17.4R1 Starting with Junos OS Release 17.4R1, the reputation base scores are configurable. Users can
apply global reputation values, provided by the Websense ThreatSeeker Cloud (TSC). For the non-
category URLs, the global reputation value is used to perform filtering,
15.1X49-D40 Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, EWF supports HTTPS
traffic by intercepting HTTPS traffic passing through the SRX Series device.
181
15.1X49-D40 Starting with Junos OS 15.1X49-D40 and Junos OS Release 17.3R1, EWF intercepts HTTPS
traffic passing through the SRX Series device. The security channel from the device is divided as
one SSL channel between the client and the device and another SSL channel between the device
and the HTTPS server. SSL forward proxy acts as the terminal for both channels and forwards the
cleartext traffic to the UTM. UTM extracts the URL from the HTTP request message.
15.1X49- Starting with Junos OS Release 15.1X49-D110, a new option, custom-message, is added for the
D110 custom-objects command that enables you to configure user messages and redirect URLs to notify
users when a URL is blocked or quarantined for each EWF category.
D110 custom-objects statement that enables you to configure user messages and redirect URLs to notify
15.1X49- Starting with Junos OS Release 15.1X49-D110, the “* “ in a wildcard syntax, required to create
D110 URL pattern for Web filtering profile, matches all subdomains.
D110 custom-objects statement that enables you to configure user messages and redirect URLs to notify
12.3X48-D25 Starting with Junos OS Release 12.3X48-D25 and Junos OS Release 17.3R1, Enhanced Web
Filtering (EWF) over SSL forward proxy supports HTTPS traffic.
12.1X47-D40 Starting in Junos OS 12.1X47-D40 and Junos OS Release 17.3R1, the structured log fields have
changed.

182
Local Web Filtering
IN THIS SECTION
The Web filtering lets you to manage Internet usage by preventing access to inappropriate Web content.
There are four types of Web filtering solutions. For more information, see the following topics:
Understanding Local Web Filtering
IN THIS SECTION
Local Web Filtering Process | 183
User-Defined Custom URL Categories | 183
Local Web Filtering Profiles | 184
User Messages and Redirect URLs for Web Filtering | 184
Profile Matching Precedence | 185
Local web filtering allows you to define custom URL categories, which can be included in blocklists and
allowlists that are evaluated on the SRX Series device. All URLs for each category in a blocklist are
denied, while all URLs for each category in a allowlist are permitted.
With local Web filtering, a firewall intercepts every HTTP request in a TCP connection and extracts the
URL. A decision is made by the device after it looks up a URL to determine whether it is in the allowlist
or blocklist based on its user-defined category. A URL is first compared to the blocklist URLs. If a match
is found, the request is blocked. If no match is found, the URL is compared to the allowlist. If a match is
found, the request is permitted. If the URL is not in either list, the custom category is taken (block, log-
and-permit, or permit). If the URL is not in custom category, the defined default action is taken (block,
log-and-permit, or permit). You can permit or block access to a requested site by binding a Web filtering
183
profile to a firewall policy. Local Web filtering provides basic Web filtering without requiring an
additional license or external category server.
This topic contains the following sections:
Local Web Filtering Process
The following section describes on how Web traffic is intercepted and acted upon by the Web filtering
module.
1. The device intercepts a TCP connection.
2. The device intercepts each HTTP request in the TCP connection.
3. The device extracts each URL in the HTTP request and checks its URL against the user-defined
allowlist and blocklist.
4. If the URL is found in the blocklist, the request is not permitted and a deny page is sent to the http
client. If the URL is found in the allowlist, the request is permitted.
5. If the URL is not found in the allowlist or blocklist, the configured default fallback action is applied. If
no fallback action is defined, then the request is permitted.
User-Defined Custom URL Categories
To perform local Web filtering, you must define a blocklist and allowlist content that can be applied to
the profile.
When defining your own URL categories, you can group URLs and create categories specific to your
needs. Each category can have a maximum of 20 URLs. When you create a category, you can add either
the URL or the IP address of a site. When you add a URL to a user-defined category, the device
performs DNS lookup, resolves the hostname into IP addresses, and caches this information. When a
user tries to access a site with the IP address of the site, the device checks the cached list of IP
addresses and tries to resolve the hostname. Many sites have dynamic IP addresses, meaning that their
IP addresses change periodically. A user attempting to access a site can type an IP address that is not in
the cached list on the device. Therefore, if you know the IP addresses of sites you are adding to a
category, enter both the URL and the IP address(es) of the site.
You define your own categories using URL pattern list and custom URL category list custom objects.
Once defined, you assign your categories to the global user-defined url-blocklist (block) or url-allowlist
(permit) categories.
Web filtering is performed on all the methods defined in HTTP 1.0 and HTTP 1.1.
184
Local Web Filtering Profiles
You configure Web filtering profiles that permit or block URLs according to defined custom categories. A
Web filtering profile consists of a group of URL categories assigned one of the following actions:
• Blocklist — The device always blocks access to the websites in this list. Only user-defined categories
are used with local Web filtering.
• Allowlist — The device always allows access to the websites in this list. Only user-defined categories
are used with local Web filtering.
A Web filtering profile can contain one blocklist or one allowlist with multiple user-defined categories
each with a permit or block action. You can define a default fallback action when the incoming URL does
not belong to any of the categories defined in the profile. If the action for the default category is block,
the incoming URL is blocked if it does not match any of the categories explicitly defined in the profile. If
an action for the default action is not specified, the default action of permit is applied to the incoming
URL not matching any category.
Starting with Junos OS Release 17.4R1, custom category configuration is supported for local Web
filtering. The custom-message option is also supported in a category for local Web filtering and Websense
redirect profiles. Users can create multiple URL lists (custom categories) and apply them to a UTM Web
filtering profile with actions such as permit, permit and log, block, and quarantine. To create a global
allowlist or blocklist, apply a local Web filtering profile to a UTM policy and attach it to a global rule.
User Messages and Redirect URLs for Web Filtering
Starting with Junos OS Release 17.4R1, a new option, custom-message, is added for the custom-objects
statement that enables you to configure user messages and redirect URLs to notify users when a URL is
blocked or quarantined for each EWF category. The custom-message option has the following mandatory
attributes:
EWF category.
185
Profile Matching Precedence
When a profile employs several categories for URL matching, those categories are checked for matches
in the following order:
1. If present, the global blocklist is checked first. If a match is made, the URL is blocked. If no match is
found...
2. The global allowlist is checked next. If a match is made, the URL is permitted. If no match is found...
3. User-defined categories are checked next. If a match is made, the URL is blocked or permitted as
specified.
SEE ALSO

Example: Configuring Local Web Filtering
IN THIS SECTION
Requirements | 186
Overview | 186
Configuration | 188
Verification | 197
186
This example shows how to configure local Web filtering for managing website access.
Requirements
• SRX1500 device
• Junos OS Release 12.1X46-D10 or later
Before you begin, learn more about Web filtering. See "Web Filtering Overview" on page 135.
Overview
In this example you configure local Web filtering custom objects, local Web filtering feature profiles, and
local Web filtering UTM policies. You also attach local Web filtering UTM policies to security policies.
Table 4 on page 186 shows information about local Web filtering configuration type, steps, and
parameters used in this example.
Table 4: Local Web filtering Configuration Type, Steps, and Parameters
URL pattern and custom objects Configure a URL pattern list of • [http://www.example1.net
URLs or addresses that you want to 192.0.2.0]
bypass.
• [http://www.example2.net
192.0.2.3]
urllis1 that contains the pattern
[http://www.example1.net • [http://www.example3.net
192.0.2.0] 192.0.2.9]

• [http://www.example4.net
urllist2 that contains the pattern
192.0.2.8]
[http://www.example2.net
192.0.2.3] • value urllist3

• value urllist4
192.0.2.9]

192.0.2.8]
187
Table 4: Local Web filtering Configuration Type, Steps, and Parameters (Continued)
The urllist1 and urllist2 custom • value urllist1

objects are then added to the
custom URL categories cust- • value urllist2
blocklist, and cust-permit-list
respectively.
Feature profiles Configure the Web filtering feature

profile:
• Set the URL blocklist filtering • custurl3

category to custurl4 and the
URL allowlist filtering category • custurl4
to custurl3. Set the type of Web
filtering engine to juniper-local. • type juniper-local
• Create a juniper-local profile • localprofile1

name called localprofile1. Select
a default action (permit, log- • Action: block
and-permit, block) for this
profile for requests that • Action: log-and-permit
experience errors. This example
• cust-black-list
sets the default action to
permit. Add category cust-
• cust-permit-list
permit-list with log-and-permit
action and cus-blocklist with
block action.
188
Table 4: Local Web filtering Configuration Type, Steps, and Parameters (Continued)
• Define redirect url. Enter a • block-message type custom-

custom message to be sent redirect-url
when HTTP requests are
blocked. • block-message url 192.0.2.10
• Select fallback settings (block or • custom-block-message “**Access

log-and-permit) for this profile, to this site is not
in case errors occur in each permitted**”.
configured category. This
example sets fallback settings • fallback-settings:
to block.
• block
• log-and-permit
UTM policies Create the UTM policy utmp5 and • utm policy utmp5
attach it to the profile localprofile1.
In the final configuration example, • policy p5
attach the UTM policy utmp5 to
the security policy p5.
Configuration
IN THIS SECTION
Configuring Local Web Filtering Custom Objects and URL Patterns | 189
Apply Custom Objects to the Feature Profiles | 192
Attaching Web Filtering UTM Policies to Security Policies | 195
Attaching Local Web Filtering UTM Policies to Security Policies | 196

189
Configuring Local Web Filtering Custom Objects and URL Patterns
configuration mode.
set security utm custom-objects url-pattern urllist1 value http://www.example1.net

set security utm custom-objects custom-url-category cust-black-list value urllist1
set security utm custom-objects custom-url-category cust-permit-list value urllist2
Starting in Junos OS Release 15.1X49-D110, the “* “ in a wildcard syntax, used for URL pattern Web
filtering profile, matches all subdomains. For example, *.example.net matches:
• http://a.example.net
• http://example.net
• aaa.example.net
To configure local Web filtering using the CLI:
1. Configure a URL pattern list custom object by creating the list name and adding values to it as
follows:
190
[edit]
user@host# set security utm custom-objects url-pattern urllist1 value [http://
www.example1.net 192.0.2.0]
NOTE:
• The guideline to use a URL pattern wildcard is as follows: Use \*\.[]\?* and precede all
wildcard URLs with http://. You can use “*” only if it is at the beginning of the URL and is
followed by “.”. You can use “?” only at the end of the URL.
• The following wildcard syntaxes are supported: http://*.example.net, http://

www.example.ne?, http://www.example.n??. The following wildcard syntaxes are not
supported: *.example.???, http://*example.net, http://?.
2. Applying the URL pattern to a custom URL category.
[edit]
user@host# set security utm custom-objects custom-url-category cust-black-list value urllist1
user@host# set security utm custom-objects custom-url-category cust-permit-list value
urllist2
user@host# set security utm custom-objects custom-url-category custurl3 value urllist3
user@host# set security utm custom-objects custom-url-category custurl4 value urllist4
191
Results
[edit]
url-pattern {
urllist1 {
value [ http://www.example1.net 192.0.2.0 ];
}
urllist2 {
}
urllist3 {
}
urllist4 {
}
}
cust-black-list {
value urllist1;
}
cust-permit-list {
value urllist2;
}
custurl3 {
value urllist3;
}
custurl4 {
value urllist4;
}
}
192
Apply Custom Objects to the Feature Profiles
configuration mode.
set security utm feature-profile web-filtering url-whitelist custurl3

set security utm feature-profile web-filtering url-blacklist custurl4
set security utm feature-profile web-filtering type juniper-local
set security utm feature-profile web-filtering juniper-local profile localprofile1 category cust-
black-list action block
set security utm feature-profile web-filtering juniper-local profile localprofile1 category cust-
permit-list action log-and-permit
set security utm feature-profile web-filtering juniper-local profile localprofile1 block-message
type custom-redirect-url
set security utm feature-profile web-filtering juniper-local profile localprofile1 block-message
url http://192.0.2.10
set security utm feature-profile web-filtering juniper-local profile localprofile1 custom-block-
message "Access to this site is not permitted."
set security utm feature-profile web-filtering juniper-local profile localprofile1 default log-
and-permit
set security utm feature-profile web-filtering juniper-local profile localprofile1 fallback-
settings default block
set security utm feature-profile web-filtering juniper-local profile localprofile1 fallback-
settings too-many-requests block
To configure local Web filtering feature profiles:
1. Configure the Web filtering URL blocklist, URL allowlist, and the Web filtering engine.

193
user@host# set url-blacklist custurl4

user@host# set type juniper-local
2. Create a profile name, and select a category from the included permit and blocklist categories. The
custom category action could be block, permit, log-and-permit, and quarantine.

user@host# set juniper-local profile localprofile1 category cust-black-list action block
user@host# set juniper-local profile localprofile1 category cust-permit-list action log-and-
permit
3. Define a redirect URL server so that instead of the device sending a block page with plain text HTML,
the device send an HTTP 302 redirect to this redirect server with special variables embedded in the
HTTP redirect location field. These special variables are parsed by the redirect server and serve as a
special block page to the client with images and a clear text format.

user@host# set security utm feature-profile web-filtering juniper-local profile localprofile1
block-message type custom-redirect-url
user@host# set security utm feature-profile web-filtering juniper-local profile localprofile1
block-message url http://192.0.2.10

user@host# set juniper-local profile localprofile1 custom-block-message “Access to this site
is not permitted”
5. Specify a default action (permit, log and permit, block, or quarantine) for the profile, when no other
explicitly configured action (blocklist, allowlist, custom category, predefined category actions, or site
reputation actions) is matched .

user@host# set juniper-local profile localprofile1 default log-and-permit
194
6. Configure fallback settings (block or log and permit) for this profile.

user@host# set juniper–local profile localprofile1 fallback-settings default block
user@host# set juniper–local profile localprofile1 fallback-settings too-many-requests block
Results
[edit]
userhost#show security utm feature-profile
web-filtering {
url-whitelist custurl3;
url-blacklist custurl4;
type juniper-local;
juniper-local {
profile localprofile1 {
category {
cust-black-list {
action block;
}
cust-permit-list {
}
}
custom-block-message "Access to this site is not permitted.";
block-message {
type custom-redirect-url;
url http://192.0.2.10;
}
fallback-settings {
default block;
}
}
}
}
195
}
}
Attaching Web Filtering UTM Policies to Security Policies
configuration mode.
set security utm utm-policy utmp5 web-filtering http-profile localprofile1
To configure a UTM policy:
1. Create the UTM policy referencing a profile. Apply the Web filtering profile to the UTM policy.
[edit]
user@host# set security utm utm-policy utmp5 web-filtering http-profile localprofile1
Results
to correct it.
For brevity, this show command output includes only the configuration that is relevant to this example.
Any other configuration on the system has been replaced with ellipses (...).
[edit]
userhost# show security utm
utm-policy utmp5 {
web-filtering {
196
http-profile localprofile1;
}
}
Attaching Local Web Filtering UTM Policies to Security Policies
configuration mode.
set security policies from-zone trust to-zone untrust policy p5 match application junos-http
set security policies from-zone trust to-zone untrust policy p5 then permit application-services
utm-policy utmp5
1. Create and configure the security policy.

2. Apply the UTM policy to the security policy.

197
Results
[edit]
userhost# show security policies
policy p5 {
match {
source-address any;
}
then {
permit {
utm-policy utmp5;
}
}
}
}
}
Verification
IN THIS SECTION
Verifying the Statistics of UTM Web Filtering | 198
To confirm that the configuration is working properly, perform the following task:
198
Verifying the Statistics of UTM Web Filtering
Purpose
Verify the Web filtering statistics for connections including allowlist and blocklist hits and custom
category hits.
Action
From operational mode, enter the show security utm web-filtering statistics command.
Sample Output
command-name
user@host>show security utm web-filtering statistics

Total requests: 0
white list hit: 0
Black list hit: 0
Default 0 0
Timeout 0 0
Connectivity 0 0
SEE ALSO
199
Release Description
17.4R1 Starting with Junos OS Release 17.4R1, custom category configuration is supported for local Web
filtering. The custom-message option is also supported in a category for local Web filtering and
Websense redirect profiles. Users can create multiple URL lists (custom categories) and apply them
to a UTM Web filtering profile with actions such as permit, permit and log, block, and quarantine.
To create a global allowlist or blocklist, apply a local Web filtering profile to a UTM policy and
attach it to a global rule.
17.4R1 Starting with Junos OS Release 17.4R1, a new option, custom-message, is added for the custom-
objects statement that enables you to configure user messages and redirect URLs to notify users
when a URL is blocked or quarantined for each EWF category.
15.1X49- Starting in Junos OS Release 15.1X49-D110, the “* “ in a wildcard syntax, used for URL pattern
D110 Web filtering profile, matches all subdomains.

Allowlist | 24
Redirect Web Filtering
IN THIS SECTION
The redirect Web filtering solution intercepts HTTP requests and sends them to an external URL filtering
server, provided by Websense, to determine whether to block the requests. For more information, see
the following topics:
200
Understanding Redirect Web Filtering
IN THIS SECTION
User Messages and Redirect URLs for Web Filtering | 201
Dynamic Support for New Websense EWF Categories | 201
With redirect Web filtering, the Web filtering module intercepts an HTTP request. The URL in the
request is then sent to the external Websense server, which makes a permit or a deny decision. If access
is permitted to the URL in question, the original HTTP request and all the subsequent requests are sent
to the intended HTTP server. But if access is denied to the URL in question, a blocking message is sent
to the client.
This is a general description of how Web traffic is intercepted, redirected, and acted upon by the Web
filtering module:
1. A Web client establishes a TCP connection with the webserver.
2. The Web client then sends an HTTP request.
3. The device intercepts the requests and extracts the URL. The URL is checked against global Web
filtering allowlists and blocklists. If no match is made, the Websense server configuration parameters
are utilized. Otherwise the process continues with step 6.
4. The URL is sent to the Websense server for checking,
5. The Websense server returns a response indicating whether or not the URL is to be permitted or
blocked.
6. If access is allowed, the original HTTP request is sent to the webserver. If access is denied, the device
sends a blocking message to the client and tears down the TCP connection.
Web filtering is performed on all the methods defined in HTTP 1.0 and HTTP 1.1. However, redirect
Web filtering uses destination IP as URL when it is checking HTTPS traffic.
Decision making from real-time options provides a higher level of accuracy, therefore caching for
redirect Web filtering is not supported.
Redirect Web filtering does not require a subscription license.

201
User Messages and Redirect URLs for Web Filtering
Starting with Junos OS Release 17.4R1, a new option, custom-message, is added for the custom-objects
blocked or quarantined for each EWF category. The custom-message option has the following mandatory
attributes:
EWF category.
Dynamic Support for New Websense EWF Categories
Starting with Junos OS Release 17.4R1, you can download and dynamically load new Enhanced Web
Filtering (EWF) categories. The downloading and dynamic loading of the new EWF categories do not
require a software upgrade. Websense occasionally releases new EWF categories. EWF classifies
websites into categories according to host, URL, or IP address and performs filtering based on the
categories. Users can leverage new categories as soon as they are available rather than waiting for a
patch release.
NOTE: Existing configurations are not affected by the new categories but can be modified to
make use of the new categories.
202
SEE ALSO

Example: Enhancing Security by Configuring Redirect Web Filtering Using

Custom Objects
IN THIS SECTION
Requirements | 202
Overview | 202
Configuration | 203
Verification | 212
This example shows how to manage Internet usage by configuring redirect Web filtering using custom
objects and preventing access to inappropriate Web content.
Requirements
Overview
IN THIS SECTION
Topology | 203
The benefit of using Web filtering is that it extracts the URLs from HTTP request messages and
performs filtering according to the requirements. The advantage of configuring redirect Web filtering is
that it extracts the URLs from the HTTP requests and sends them to an external URL filtering server to
determine whether to allow or deny access.
203
In this example you configure redirect Web filtering custom objects, redirect Web filtering feature
profiles, and redirect Web filtering UTM policies. You also attach redirect Web filtering UTM policies to
security policies.
The default websense-redirect server port number is 15868.
You select fallback settings (block or log-and-permit) for this profile, in case errors occur in each
configured category. This example sets fallback settings to block the profile. You enter the number of
sockets used for communicating between the client and the server. The default is 32 for SRX Series
devices.
Finally, you enter a timeout value in seconds. Once this limit is reached, fail mode settings are applied.
The default is 15 seconds, and you can enter a value from 1 to 1800 seconds. This example sets the
timeout value to 10.
Topology
Figure 3 on page 203 shows the overall architecture for the Websense redirect feature.
Figure 3: Websense Redirect Architecture
Configuration
IN THIS SECTION
Configuring Redirect Web Filtering Custom Objects | 204

204
Configuring the Redirect Web Filtering Feature Profiles | 206
Configuring Redirect Web Filtering UTM Policies and Attaching the Redirect Web Filtering UTM
Policies to Security Policies | 209
Configuring Redirect Web Filtering Custom Objects
configuration mode.

set security utm custom-objects custom-url-category custwhitelist value urllistwhite
To configure redirect Web filtering custom objects:
1. Create custom objects and create the URL pattern list.
[edit security utm]

user@host# set custom-objects url-pattern urllist4 value [http://www.example.net 1.2.3.4]
2. Configure the custom URL category list custom object using the URL pattern list.
[edit security utm]

205
3. Create a list of untrusted sites
[edit security utm]

13.13.13.13]
4. Configure the custom URL category list custom object using the URL pattern list of untrusted sites.
[edit security utm]

5. Create a list of trusted sites.
[edit security utm]

user@host# set custom-objects url-pattern urllistwhite value [http://www.trusted.com 7.7.7.7]
6. Configure the custom URL category list custom object using the URL pattern list of trusted sites.
[edit security utm]

Results
[edit]
userhost# show security utm custom-objects
url-pattern {
urllist4 {
value [ http://www.example.net 1.2.3.4 ];
}
urllistblack {
value [ http://www.untrusted.com 13.13.13.13 ];
}
urllistwhite {
206
value [ http://www.trusted.com 7.7.7.7 ];

}
}
custurl4 {
value urllist4;
}
custblacklist {
value urllistblack;
}
custwhitelist {
value urllistwhite;
}
}
Configuring the Redirect Web Filtering Feature Profiles
configuration mode.
set security utm feature-profile web-filtering url-whitelist custwhitelist

set security utm feature-profile web-filtering url-blacklist custblacklist
set security utm feature-profile web-filtering type websense-redirect
set security utm feature-profile web-filtering websense-redirect profile websenseprofile1 server
host Websenseserver
set security utm feature-profile web-filtering websense-redirect profile p1 category cust-white-
list action log-and-permit
set security utm feature-profile web-filtering websense-redirect profile p1 category cust-list2
action permit
set security utm feature-profile web-filtering websense-redirect profile websenseprofile1 server
port 15868
set security utm feature-profile web-filtering websense-redirect profile websenseprofile1
207
fallback-settings too-many-requests block

timeout 10
sockets 1
To configure redirect Web filtering feature profiles:
1. Configure the Web filtering URL blocklist.

2. Configure the Web filtering URL allowlist.

3. Specify the Web filtering type, create a profile name, and set the server name or IP address.

user@host# set websense-redirect profile websenseprofile1 server host Websenseserver
4. Configure the custom category action log-and-permit and permit for the URL allowlist and cust-list2,
respectively.

user@host# set websense-redirect profile websenseprofile1 category cust-white-list action
log-and-permit
user@host# set websense-redirect profile websenseprofile1 category cust-list2 action permit
208
5. Enter the port number for communicating with the server.

user@host# set websense-redirect profile websenseprofile1 server port 15868
6. Configure the fallback settings action blockfor this profile.

user@host# set websense-redirect profile websenseprofile1 fallback-settings default block
user@host# set websense-redirect profile websenseprofile1 fallback-settings server-

connectivity block
user@host# set websense-redirect profile websenseprofile1 fallback-settings timeout block
user@host# set websense-redirect profile websenseprofile1 fallback-settings too-many-requests
block
7. Enter the number of sockets used for communicating between the client and the server.

user@host# set websense-redirect profile websenseprofile1 sockets 1
8. Enter a timeout value, in seconds.

user@host# set .websense-redirect profile websenseprofile1 timeout 10
Results
[edit]
userhost# show security utm feature-profile
web-filtering {
url-whitelist custwhitelist;
209
type websense-redirect {
profile websenseprofile1 {
server {
host Websenseserver;
port 15868;
}
category {
cust-white-list {
action log-and-permit ;
cust-list2 {
action permit;
}
}
}
fallback-settings {
timeout block;
}
timeout 10;
sockets 1;
}
}
}
content-filtering {
profile contentfilter1;
}
Configuring Redirect Web Filtering UTM Policies and Attaching the Redirect Web Filtering UTM
Policies to Security Policies
210
configuration mode.
set security utm utm-policy utmp6 web-filtering http-profile websenseprofile1

utm-policy utmp6
To configure a UTM policy and attach it to a security policy:
1. Create the UTM policy referencing a profile.
[edit security utm]

user@host# set utm-policy utmp6 web-filtering http-profile websenseprofile1


211
Results
to correct it.
[edit]
utm-policy utmp6 {
web-filtering {
http-profile websenseprofile1;
}
}
[edit]
policy p6 {
match {
source-address any;
}
then {
permit {
utm-policy utmp6;
}
}
}
}
}
212
Verification
IN THIS SECTION
Verifying the Configuration of Redirect Web Filtering Custom Objects | 212
Verifying the Configuration of Redirect Web Filtering Feature Profiles | 213
Verifying the Attachment of Redirect Web Filtering UTM Policies to Security Policies | 214
Verifying the Configuration of Redirect Web Filtering Custom Objects
Purpose
Verify the configuration of redirect Web filtering custom objects.
Action
From the top of the configuration in configuration mode, enter the show security utm custom-objects
command.
[edit]
userhost# show security utm custom-objects
url-pattern {
urllist4 {
}
urllistblack {
}
urllistwhite {
}
}
custurl4 {
value urllist4;
213
}
custblacklist {
value urllistblack;
}
custwhitelist {
value urllistwhite;
}
}
Meaning
The sample output shows the list of custom objects created.
Verifying the Configuration of Redirect Web Filtering Feature Profiles
Purpose
Verify the configuration of redirect Web filtering feature profiles.
Action
From the top of the configuration in configuration mode, enter the show security utm feature-profile
command.
[edit]
userhost# show security utm feature-profile
web-filtering {
type websense-redirect {
profile websenseprofile1 {
server {
host Websenseserver;
port 15868;
}
fallback-settings {
timeout block;
}
timeout 10;
214
sockets 1;
}
}
}
content-filtering {
}
Meaning
The sample output shows the feature profile configured for a Websense redirect server.
Verifying the Attachment of Redirect Web Filtering UTM Policies to Security Policies
Purpose
Verify the attachment of the newly created redirect Web filtering UTM policies to the security policies.
Action
From the top of the configuration in configuration mode, enter the show security utm and show security
policies commands.
[edit]
utm-policy utmp6 {
web-filtering {
http-profile websenseprofile1;
}
}
[edit]
policy p6 {
match {
source-address any;
215
}
then {
permit {
utm-policy utmp6;
}
}
}
}
}
Meaning
The sample output shows the security policies to which the newly created redirect Web filtering UTM
policies are attached.
SEE ALSO

Release Description
17.4R1 Starting with Junos OS Release 17.4R1, a new option, custom-message, is added for the custom-objects
blocked or quarantined for each EWF category.
17.4R1 Starting with Junos OS Release 17.4R1, you can download and dynamically load new Enhanced Web
Filtering (EWF) categories.

216
Safe Search Enhancement for Web Filtering
SUMMARY IN THIS SECTION
Learn about our safe search enhancement for Unified Safe Search Enhancement for Web Filtering
Threat Management (UTM) Web filtering solutions to Overview | 216
enforce the safest Web browsing mode available, by Configure Web Filtering with Safe
default. Search | 219
WHAT'S NEXT
Now that you’ve learned about safe search enhancement for Web filtering, you'll be interested to know
how to disable the safe search function. Check out juniper-local, websense-redirect, and juniper-
enhanced for more information.
Safe Search Enhancement for Web Filtering Overview
IN THIS SECTION
Benefits of Safe Search Enhancement for Web Filtering | 216
Features of Safe Search Enhancement for Web Filtering | 217
Limitations of Safe Search Enhancement for Web Filtering | 219
Benefits of Safe Search Enhancement for Web Filtering
• Provides the safest Web browsing mode available, by default.
• Protects the HTTPS-based search engine cache. This protection is a key security feature requirement
for organizations with multiple Web users in educational, financial, health-care, banking, and
corporate segments. In a campus or branch, enabling a default safe search solution for all users and
blocking the search engine cache provides secure and comfortable Web browsing.
217
Features of Safe Search Enhancement for Web Filtering
You use UTM Web filtering to manage Web browsing by preventing access to inappropriate Web
content. To do this, you use the following Web filtering solutions:
• Redirect Web filtering
• Local Web filtering
• Enhanced Web Filtering (EWF)
We've enhanced the safe search functionality for these UTM Web filtering solutions to provide an
extremely safe search environment for the Web user. Table 5 on page 218 describes the features of the
safe search enhancement.
218
Table 5: Safe Search Enhancement Features
Safe Search Description

Feature
Default safe By enabling the safe search enhancement feature, you enforce the safest Web browsing mode
search available by default on the well-known search engines. Doing so helps those users that are not
using the strictest safe search settings.
If you enable the safe search feature on your security device, it enforces the search service to
the strictest mode by URL query rewriting, which is transparent to you. For example, when you
do a search request on the search engines Google, Bing, Yahoo, or Yandex, the safe search
feature rewrites the requested URLs to the safest search URLs.
Here're a few examples of requested and converted URLs:
• Google search engine:
• Requested URL: https://www.google.com/search?q=test
• Converted URL: https://www.google.com/search?q=test&safe=active
• Bing search engine:
• Requested URL: https://www.bing.com/search?q=test
• Converted URL: https://www.bing.com/search?q=test&adlt=strict
• Yahoo search engine:
• Requested URL: https://search.yahoo.com/search?q=test
• Converted URL: https://search.yahoo.com/search?q=test&vm=r
• Yandex search engine:
• Requested URL: https://yandex.com/search/?text=test&lr=10619
• Converted URL: https://yandex.com/search/?text=test&lr=10619&filter=strict
Blocking By blocking the search engine cache on the well-known search engines, you can hide your
search engine Web-browsing activities from other users if you are a part of an organization that has multiple
cache Web users in educational, financial, health-care, banking, and corporate segments.
To block the search engine cache, you configure a general URL block pattern and category for
the search engine cache service.
219
You can disable the safe search option at the Web filtering-level and profile-level configurations. See
juniper-local, websense-redirect, and juniper-enhanced.
Limitations of Safe Search Enhancement for Web Filtering
• For HTTP safe search enhancement, you must enable stream mode by enabling the http-reassemble
option at the [edit security utm default-configuration web-filtering] hierarchy level. If you don't enable
stream mode, you can't use the safe search feature. As a result, the system sends an HTTP 302
redirect message to the user.
• For HTTPS safe search enhancement, you must enable the SSL proxy service on the security policy. If
SSL proxy bypasses the HTTPS traffic, then the safe search feature also bypasses the HTTPS traffic.
Configure Web Filtering with Safe Search
SUMMARY IN THIS SECTION
Use this example to configure UTM Web filtering Requirements | 219

solutions and verify the safe search enhancement Overview | 220
for UTM Web filtering.
Configuration | 220
Verification | 225
Requirements
• An SRX Series device
• Junos OS Release 20.2R1
Before you begin:
• Make sure you understand how to use Web filtering to manage Web browsing. See Web Filtering
Overview.
• Configure a Root CA Certificate. See Configuring a Root CA Certificate.

220
Overview
In this example, you configure the following policies and Web filtering profiles on your security device:
• UTM policies
• Security policies
• Web filtering profiles
• SSL proxy
After you've configured the policies and profiles, you generate the Web filtering statistics and verify the
performance of the safe search enhancement.
Figure 4 on page 220 shows the basic UTM Web filtering topology. When you enable your security
device with the safe search feature, the device rewrites the search requests from the user to the safest
search mode of the search engines. The cloud engine or the local engine performs Web filtering on the
search requests before forwarding to the Internet or external webserver.
Figure 4: Topology for Web Filtering Basic Function
Configuration
IN THIS SECTION
Procedure | 221
221
Procedure
set security utm default-configuration web-filtering type juniper-enhanced

set security utm default-configuration web-filtering http-reassemble
set security utm default-configuration web-filtering juniper-enhanced default log-and-permit
set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile1 category
Enhanced_Search_Engines_and_Portals action log-and-permit
set security utm feature-profile web-filtering juniper-enhanced profile ewf_my_profile1 default
log-and-permit
set security utm utm-policy utmpolicy1 web-filtering http-profile ewf_my_profile1
set security policies from-zone trust to-zone internet policy sec_policy match source-address any
set security policies from-zone trust to-zone internet policy sec_policy match destination-
address any
set security policies from-zone trust to-zone internet policy sec_policy match application junos-
ping
set security policies from-zone trust to-zone internet policy sec_policy match application junos-
http
set security policies from-zone trust to-zone internet policy sec_policy then permit application-
services utm-policy utmpolicy1
set security policies default-policy deny-all
set security zones security-zone trust host-inbound-traffic system-services all
set security zones security-zone trust host-inbound-traffic protocols all
set security zones security-zone trust interfaces xe-5/0/0.0
set security zones security-zone internet host-inbound-traffic system-services all
set security zones security-zone internet host-inbound-traffic protocols all
set security zones security-zone internet interfaces xe-5/0/2.0
set interfaces xe-5/0/0 unit 0 family inet address 192.0.2.254/24
set interfaces xe-5/0/2 unit 0 family inet address 203.0.113.254/24
instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User
Guide.
222
To configure UTM Web filtering:
1. Configure UTM Web filtering solution.
[edit security utm]

user@host# default-configuration web-filtering type juniper-enhanced
user@host# default-configuration web-filtering http-reassemble
user@host# default-configuration web-filtering juniper-enhanced default log-and-permit
user@host# feature-profile web-filtering juniper-enhanced profile ewf_my_profile1 category
Enhanced_Search_Engines_and_Portals action log-and-permit
user@host# feature-profile web-filtering juniper-enhanced profile ewf_my_profile1 default log-
and-permit
user@host# utm-policy utmpolicy1 web-filtering http-profile ewf_my_profile1
2. Configure the security policies to control HTTP or HTTPS traffic from the trust zone to the Internet
zone.
[edit security policies]

user@host# from-zone trust to-zone internet policy sec_policy match source-address any
user@host# from-zone trust to-zone internet policy sec_policy match destination-address any
user@host# from-zone trust to-zone internet policy sec_policy match application junos-ping
user@host# from-zone trust to-zone internet policy sec_policy match application junos-http
user@host# from-zone trust to-zone internet policy sec_policy then permit application-
services utm-policy utmpolicy1
user@host# default-policy deny-all
3. Configure security zones.
[edit security zones security-zone]

user@host# trust host-inbound-traffic system-services all
user@host# trust host-inbound-traffic protocols all
user@host# trust interfaces xe-5/0/0.0
user@host# internet host-inbound-traffic system-services all
user@host# internet host-inbound-traffic protocols all
user@host# internet interfaces xe-5/0/2.0
223
4. Configure interfaces.
[edit interfaces]
user@host# xe-5/0/0 unit 0 family inet address 192.0.2.254/24
user@host# xe-5/0/2 unit 0 family inet address 203.0.113.254/24
Results
From configuration mode, confirm your configuration by entering the show security policies, show security
utm, and show interfaces commands. If the output does not display the intended configuration, repeat the

from-zone trust to-zone internet {
policy sec_policy {
match {
source-address any;
application [ junos-ping junos-http ];
}
then {
permit {
utm-policy utmpolicy1;
}
}
}
}
}
default-policy {
deny-all;
}

web-filtering {
http-reassemble;
juniper-enhanced {
224
}
}
}
feature-profile {
web-filtering {
juniper-enhanced {
profile ewf_my_profile1 {
category {
Enhanced_Search_Engines_and_Portals {
}
}
}
}
}
}
utm-policy utmpolicy1 {
web-filtering {
http-profile ewf_my_profile1;
}
}
user@host# show interfaces

xe-5/0/0 {
unit 0 {
family inet {
address 192.0.2.254/24;
}
}
}
xe-5/0/2 {
unit 0 {
family inet {
address 203.0.113.254/24;
}
}
}
If you are done configuring the feature on your device, enter commit from configuration mode.
225
Verification
IN THIS SECTION
Verify Safe Search Function | 225
Verify Safe Search Function
Purpose
Verify that the safe search feature is enabled for UTM Web filtering solutions.
Action
From operational mode, enter the show security utm web-filtering statistics command to view the Web
filtering statistics. In the output, the Safe-search redirect and Safe-search rewrite fields display the
enhanced safe search redirect and rewrite statistics.

Total requests: 0
white list hit: 0
Black list hit: 0
No license permit: 0
226

Cache hit permit: 0
Cache hit block: 0
+Safe-search rewrite: 0
Default 0 0
Timeout 0 0
Connectivity 0 0
Meaning
The output displays that the safe search feature is enabled and there are no safe search redirects and
safe search rewrites.
Monitoring Web Filtering Configurations
IN THIS SECTION
Purpose | 227
Action | 227
227
Purpose
View Web-filtering statistics.
Action
To view Web-filtering statistics using the CLI, enter the following commands:

To view Web-filtering statistics using J-Web:
1. Select Clear Web Filtering Statistics.
The following information is displayed in the right pane.
Total Requests: #
White List Hit: #
Black List Hit: #
Queries to Server: #
Server Reply Permit: #
Server Reply Block: #
Custom Category Permit: #
Custom Category Block: #
Cache Hit Permit: #
Cache Hit Block: #
Web Filtering Session Total: #
Web Ffiltering Session Inuse: #
Fall Back: Log-and-Permit Block
Default # #
Timeout # #
Server-Connectivity # #
Too-Many-Requests # #
2. You can click the Clear Web Filtering Statistics button to clear all current viewable statistics and
begin collecting new statistics.
228

6 CHAPTER
UTM Support for SRX100, SRX110,

SRX210, SRX240, SRX550, SRX650,
and SRX1400 Devices
Express Antivirus Pattern Updates | 256

230
Express Antivirus Protection
IN THIS SECTION
Express Antivirus Protection Overview | 230
Example: Configuring Express Antivirus Custom Objects | 234
Configuring Express Antivirus Custom Objects (J-Web Procedure) | 237
Example: Configuring Express Antivirus Feature Profiles | 240
Configuring Express Antivirus Feature Profiles (J-Web Procedure) | 247
Example: Configuring Express Antivirus UTM Policies | 249
Configuring Express Antivirus UTM Policies (J-Web Procedure) | 251
Example: Attaching Express Antivirus UTM Policies to Security Policies | 251
Attaching Express Antivirus UTM Policies to Security Policies (J-Web Procedure) | 254
Express antivirus scanning is offered as a less CPU intensive alternative to the full file-based antivirus
feature. Express antivirus supports the same protocols as full antivirus and functions in much the same
manner. For more information, see the following topics:
Express Antivirus Protection Overview
IN THIS SECTION
Express Antivirus Packet-Based Scanning Versus File-Based Scanning | 231
Express Antivirus Expanded MIME Decoding Support | 231
Express Antivirus Scan Result Handling | 231
Express Antivirus Intelligent Prescreening | 232
Express Antivirus Limitations | 232

231
The Express Antivirus feature is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, Express antivirus scanning is offered as a less CPU
intensive alternative to the full file-based antivirus feature. Express antivirus supports the same
protocols as full antivirus and functions in much the same manner, however, it has a smaller memory
footprint, compatible with the smaller system memory present on lower end devices. 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. Rather, it just sends (streams) the received data packets, as is, to the scan
engine. With express antivirus, the virus scanning is executed by a hardware pattern matching engine.
This improves performance while scanning is occurring, but the level of security provided is lessened.
Juniper Networks provides the scan engine. The express antivirus scanning feature is a separately
licensed subscription service.
This topic includes the following sections:
Express Antivirus Packet-Based Scanning Versus File-Based Scanning
Express antivirus uses a different antivirus scan engine than the full file-based antivirus feature and a
different back-end hardware engine to accelerate pattern matching for higher data throughput.
The packet-based scanning done by express antivirus provides virus scanning data buffers without
waiting for entire file to be received by the firewall, whereas the file-based scanning done by full
antivirus can only start virus scanning when entire file is received.
Express Antivirus Expanded MIME Decoding Support
Express antivirus offers MIME decoding support for HTTP, POP3, SMTP, and IMAP. MIME decoding
support includes the following for each supported protocol:
• Multi-part and nested header decoding
• Base64 decoding, printed quote decoding, and encoded word decoding (in the subject field)
Express Antivirus Scan Result Handling
With express antivirus, the TCP traffic is closed gracefully when a virus is found and the data content is
dropped.
Express antivirus supports the following fail mode options: default, engine-not-ready, out-of-resource,
and too-many-requests. Fail mode handling of supported options with express antivirus is much the
same as with full antivirus.
232
Express Antivirus Intelligent Prescreening
Intelligent prescreening functionality is identical in both express antivirus and full antivirus.
Express Antivirus Limitations
Express antivirus has the following limitations when compared to full antivirus functionality:
• Express antivirus provides limited support for the scanning of file archives and compressed file
formats. Express antivirus can only support gzip, deflate and compressed compressing formats.
• Express antivirus provides limited support for decompression. Decompression is only supported with
HTTP (supports only gzip, deflate, and compress for HTTP and only supports one layer of
compression) and POP3 (supports only gzip for POP3 and only supports one layer of compression).
• Express antivirus does not support scanning by extension.
• Express antivirus scanning is interrupted when the scanning database is loading.
• Express antivirus may truncate a warning message if a virus has been detected and the replacement
warning message that is sent is longer than the original content it is replacing.
• If you switch from express antivirus protection to full file-based antivirus protection, you must
reboot the device in order for full file-based antivirus to begin working.
• Because express antivirus does only packet-based string matching, if you use the standard EICAR file
to test express antivirus, you will see false positives. To avoid these false positives, Juniper Networks
has disabled scanning on the standard EICAR file to create a modified EICAR file for testing express
antivirus. You can download this modified EICAR file from the following links:
https://www.juniper.net/security/avtest/ss-eicar.txt
https://www.juniper.net/security/avtest/ss-eicar.com
https://www.juniper.net/security/avtest/ss-eicar.zip
• The modified EICAR file must be tested with express antivirus only. The Kaspersky antivirus and
Sophos antivirus do not detect this file.
• The express antivirus feature provides better performance but lower security. If you switch from full
file-based antivirus protection to express antivirus protection, you must reboot the device in order
for express antivirus to begin working.
SEE ALSO

233

Express Antivirus Configuration Overview
Release 17.3R1 onwards. For previous releases, for each UTM feature, you should configure feature
parameters in the following order:
1. Configure UTM custom objects for the UTM features. The following example enables the mime-
pattern, url-pattern, and custom-url-category custom objects:
user@host# set security utm custom-objects mime-pattern

user@host# set security utm custom-objects url-pattern
user@host# set security utm custom-objects custom-url-category
2. Configure main feature parameters using feature profiles. The following examples enables the anti-
virus feature profile:
user@host# set security utm feature-profile anti-virus juniper-exress-engine
3. Configure a UTM policy for each protocol and attach this policy to a profile. The following example
creates the utmp3 UTM policy for the HTTP protocol:
user@host# set security utm utm-policy utmp3 anti-virus http-profile http1
4. Attach the UTM policy to a security policy. The following example attaches the utmp3 UTM policy to
the p3 security policy:
234
Example: Configuring Express Antivirus Custom Objects
IN THIS SECTION
Requirements | 234
Overview | 234
Configuration | 235
Verification | 237
Release 17.3R1 onwards. For previous releases, this example shows how to configure express antivirus
custom objects.
Requirements
Before you begin:
• Decide the type of express antivirus protection you require. See "Express Antivirus Protection
Overview" on page 230.
• Understand the order in which express antivirus parameters are configured. See "Express Antivirus
Overview
In this example, you define custom objects that are used to create express antivirus feature profiles. You
perform the following tasks to define custom objects:
• Create two MIME lists called avmime2 and ex-avmime2, and add patterns to the list.
• Configure a URL pattern list called urllist2.
When entering the URL pattern, note the following wildcard character support:
• The \*\.[]\?* wildcard characters are supported.
• You must precede all wildcard URLs with http://.
• You can use the asterisk * wildcard character only if it is at the beginning of the URL and is
followed by a period.
• You can use the question mark ? wildcard character only at the end of the URL.
235
• The following wildcard syntax is supported: http://*.example.net, http://www.example.ne?, http://

www.example.n??.
• The following wildcard syntax is not supported: *.example.net , www.example.ne?, http://

*example.net, http://* .
• Configure a custom URL category list called custurl2, using the urllist2 URL pattern list.
Configuration
IN THIS SECTION
Procedure | 235
Procedure
set security utm custom-objects mime-pattern avmime2 value [video/quicktime image/x-portable-

set security utm custom-objects mime-pattern ex-avmime2 value [video/quicktime-inappropriate]
set security utm custom-objects url-pattern urllist2 value [http://www.example.net 1.2.3.4]
To configure express antivirus filtering custom objects:

236
1. Create MIME lists, and add MIME patterns to the lists. As you use URL pattern lists to create custom
URL category lists, you must configure URL pattern list custom objects before you configure custom
URL category list.
[edit security utm]

user@host# set custom-objects mime-pattern ex-avmime2 value [video/quicktime-inappropriate]
2. Configure a URL pattern list custom object.
[edit security utm]

3. Configure a custom URL category list.
[edit security utm]

Results
to correct it.
[edit]
custom-objects {
mime-pattern {
avmime2 {
}
ex-avmime2 {
}
}
url-pattern {
urllist2 {
237
}
}
custurl2 {
value urllist2;
}
}
}
Verification
IN THIS SECTION
Verifying Express Antivirus Custom Objects | 237
Verifying Express Antivirus Custom Objects
Purpose
Verify the express antivirus custom objects.
Action
Configuring Express Antivirus Custom Objects (J-Web Procedure)
Release 17.3R1 onwards. For previous releases, to configure express antivirus protection using the J-
Web configuration editor, you must first create your custom objects (MIME pattern list, URL pattern list,
and custom URL category list).
Configure a MIME pattern list custom object as follows:
1. Select Configure>Security>UTM Custom Objects.

2. From the MIME Pattern List tab, click Add to create MIME pattern lists.
238
3. In the Add MIME Pattern pop-up window, next to MIME Pattern Name, enter a unique name.
Keep in mind that you are creating a MIME allowlist and a MIME exception list (if necessary). Both
MIME lists appear in the MIME Allowlist and Exception MIME Allowlist fields when you configure
antivirus. Therefore, the MIME list names you create should be as descriptive as possible.
4. Next to MIME Pattern Value, enter the MIME pattern.
5. Click Add to add your MIME pattern to the Values list box. Within this box, you can also select an
entry and use the Delete button to delete it from the list. Continue to add MIME patterns in this
manner.
6. Optionally, create a new MIME list to act as an exception list. The exception list is generally a subset
of the main MIME list.
7. Click OK to check your configuration and save the selected values as part of the MIME list, then click
Commit Options>Commit.
8. If the configuration item is saved successfully, you receive a confirmation and you must click OK
again. If it is not saved successfully, you can click Details in the pop-up window that appears to
discover why.
Configure a URL pattern list custom object as follows:
configure URL pattern list custom objects before you configure a custom URL category list.
1. Select Configure>Security>UTM>Custom Objects.
2. From the URL Pattern List tab, click Add to create URL pattern lists.
3. Next to URL Pattern Name, enter a unique name. This name appears in the Custom URL Category
List Custom Object page for selection.
4. Next to URL Pattern Value, enter the URL or IP address you want added to list for bypassing
scanning.
• You can only use the asterisk * wildcard character if it is at the beginning of the URL and is
• You can only use the question mark ? wildcard character at the end of the URL.
• The following wildcard syntax IS supported: http://*.example.net, http://www.example.ne?, http://

www.example.n??.
239
• The following wildcard syntax is NOT supported: *.example.net , www.example.ne?, http://

*example.net, http://*.
5. Click Add to add your URL pattern to the Values list box. The list can contain up to 8192 items. You
can also select an entry and use the Delete button to delete it from the list. Continue to add URLs or
IP addresses in this manner.
6. Click OK to check your configuration and save the selected values as part of the URL pattern list,
then click Commit Options>Commit.
discover why.
Configure a custom URL category list custom object using the URL pattern list that you created:
2. From the URL Category List tab, click Add to create URL category lists.
3. Next to URL Category Name, enter a unique name. This name appears in the URL Allowlist list when
you configure antivirus global options.
4. In the Available Values box, select a URL Pattern List name from the list for bypassing scanning and
click the right arrow button to move it to the Selected Values box.
5. Click OK to check your configuration and save the selected values as part of the URL list, then click
discover why.
SEE ALSO
Allowlist | 24
240
Example: Configuring Express Antivirus Feature Profiles
IN THIS SECTION
Requirements | 240
Overview | 240
Configuration | 241
Verification | 246
Release 17.3R1 onwards. For previous releases, this example shows how to configure an express
antivirus feature profile.
Requirements
Before you begin:
• Decide the type of express antivirus protection you require. See "Express Antivirus Protection
Overview" on page 230.
• Understand the order in which express antivirus parameters are configured. See "Express Antivirus
• MIME patterns must be defined for lists and exception lists. See Example: Configuring MIME
Allowlist to Bypass Antivirus Scanning.
• Custom objects must be defined. See "Example: Configuring Express Antivirus Custom Objects" on
page 234
• SMTP must be configured on the device. See "Understanding SMTP Antivirus Scanning" on page 330
Overview
In this example, you configure a feature profile called junexprof1 and specify custom objects to be used
for filtering content.
• Select and configure the Juniper Express Engine as the engine type.
• Select 120 as the time interval for updating the pattern database. The default antivirus pattern-
update interval is once a day.
241
NOTE: The command for changing the URL for the pattern database is:
[edit]
user@host# set security utm feature-profile anti-virus juniper-express-engine pattern-
update url http://...
Under most circumstances, you should not need to change the default URL.
• Enable an e-mail notification with a custom message as pattern file was updated and a custom
subject line as AV pattern file updated.
• Configure a list of fallback options as block.
• Configure the notification options for fallback blocking for virus detection. Configure a custom
message for the fallback blocking action, and send a notification.
• Configure a notification for protocol-only virus detection, and send a notification as Antivirus Alert.
• Configure content size parameters as 20000. For SRX100, SRX110, SRX210, SRX220, and SRX240
devices, the maximum value for content size is 20,000. For SRX650 devices, the maximum value for
content size is 40,000. Platform support depends on the Junos OS release in your installation.
• Enable intelligent prescreening and set its timeout setting to 1800 seconds and trickling setting
(applicable only to HTTP) to 600 seconds. This means that if the device receives a packet within a
600-second period during a file transfer or while performing an antivirus scan, it should not time out.
Intelligent prescreening is intended only for use with non-encoded traffic. It is not applicable to mail
protocols (SMTP, POP3, IMAP) or HTTP POST.
• Configure the antivirus scanner to use MIME bypass lists and exception lists. You can use your own
custom object lists, or you can use the default list, called junos-default-bypass-mime, which ships
with the device. The following example enables the avmime2 and ex-avmime2 lists.
• Configure the antivirus module to use URL bypass lists. If you are using a URL allowlist (valid only for
HTTP traffic), this is a custom URL category that you previously configured as a custom object. For
this example, you enable the custurl1 bypass list.
Configuration
IN THIS SECTION
Procedure | 242
242
Procedure
set security utm feature-profile anti-virus juniper-express-engine pattern-update interval 120

set security utm feature-profile anti-virus juniper-express-engine pattern-update email-notify
admin-email administrator@example.net custom-message “pattern file was updated” custom-message-
subject “AV pattern file updated”
set security utm feature-profile anti-virus juniper-express-engine profile junexprof1 fallback-
options default block
options engine-not-ready block
options out-of-resources block
options timeout block
options too-many-requests block
set security utm feature-profile anti-virus juniper-express-engine profile junexprof1
notification-options fallback-block custom-message “Dropped due to fallback condition”
notification-options virus-detection type protocol-only
notification-options virus-detection custom-message ***virus-found***
set security utm feature-profile anti-virus juniper-express-engine profile junexprof1 scan-
options content-size-limit 20000
options intelligent-prescreening
options timeout 1800
set security utm feature-profile anti-virus juniper-express-engine profile junexprof1 trickling
timeout 600
set security utm feature-profile anti-virus mime-whitelist list avmime2
set security utm feature-profile anti-virus mime-whitelist list avmime2 exception ex-avmime2
set security utm feature-profile anti-virus url-whitelist custurl2
243
To configure express antivirus feature profiles:
1. Select and configure the engine type.
[edit]
user@host# set security utm feature-profile anti-virus type juniper-express-engine
2. Select a time interval for updating the pattern database.
[edit security utm feature-profile anti-virus juniper-express-engine]

user@host# set pattern-update interval 120
3. Configure the device to notify a specified administrator when patterns are updated.

user@host# set pattern-update email-notify admin-email administrator@example.net custom-
message “pattern file was updated” custom-message-subject “AV pattern file updated”
4. Create a profile for the Juniper Express Engine, and configure fallback options as block.

user@host# set profile junexprof1 fallback-options content-size block
user@host# set profile junexprof1 fallback-options default block
user@host# set profile junexprof1 fallback-options engine-not-ready block
user@host# set profile junexprof1 fallback-options out-of-resources block
user@host# set profile junexprof1 fallback-options timeout block
user@host# set profile junexprof1 fallback-options too-many-requests block
5. Configure a custom notification for the fallback blocking action, and send a notification.

user@host# set profile junexprof1 notification-options fallback-block custom-message
“Dropped due to fallback condition”
244
6. Configure a notification for protocol-only virus detection, and send a notification.

user@host# set profile junexprof1 notification-options virus-detection type protocol-only
7. Configure a custom notification for virus detection.

set profile junexprof1 notification-options virus-detection custom-message ***virus-
found***
8. Configure content size parameter.

user@host# set profile junexprof1 scan-options content-size-limit 20000
9. Configure intelligent prescreening.

user@host# set profile junexprof1 scan-options intelligent-prescreening
10. Configure the timeout setting.

user@host# set profile junexprof1 scan-options timeout 1800
11. Configure trickling setting.

user@host# set profile junexprof1 trickling timeout 600
245
12. Configure the antivirus scanner to use MIME bypass lists and exception lists.

user@host# set mime-whitelist list avmime2 exception ex-avmime2
13. Configure the antivirus module to use URL bypass lists.

Results
anti-virus command. If the output does not display the intended configuration, repeat the configuration
[edit]
user@host# show security utm feature-profile anti-virus
mime-whitelist {
list avmime2;
exception ex-avmime2;
}
juniper-express-engine {
pattern-update {
email-notify {
admin-email "administrator@example.net";
custom-message "pattern file was updated";
custom-message-subject "AV pattern file updated";
}
interval 120;
}
profile junexprof1 {
fallback-options {
default block;
content-size block;
engine-not-ready block;
timeout block;
246
out-of-resources block;
}
scan-options {
intelligent-prescreening;
content-size-limit 20000;
timeout 1800;
}
trickling timeout 600;
virus-detection {
type protocol-only;
custom-message ***virus-found***;
}
fallback-block {
custom-message “Dropped due to fallback condition”;
}
}
}
}
Verification
IN THIS SECTION
Verifying the Configuration of Express Antivirus Feature Profile | 246
Verifying the Configuration of Express Antivirus Feature Profile
Purpose
Verify the express antivirus feature profile.
Action
From operational mode, enter any of the following commands:
• show configuration security utm

247
• show security utm anti-virus status
• show security utm anti-virus statistics
SEE ALSO

Configuring Express Antivirus Feature Profiles (J-Web Procedure)
Release 17.3R1 onwards. For previous releases, after you create your custom objects, configure the
antivirus feature profile:
1. Select Configure>Security>UTM>Global options.

2. In the Anti-Virus tab, next to MIME allowlist, select the custom object you created from the list.
3. Next to Exception MIME allowlist, select the custom object you created from the list.
4. Next to URL Allowlist, select the custom object you created from the list.
5. In the Engine Type section, select the type of engine you are using. For express antivirus protection,
you should select Juniper Express.
6. Next to Pattern update URL, enter the URL for the pattern database in the box. Note that the URL
is http://update.juniper-updates.net/EAV/<device version> and you should not change it.
7. Next to Pattern update interval, enter the time interval for automatically updating the pattern
database in the box. The default for express antivirus checking is once per day.
8. Select whether you want the pattern file to update automatically (Auto update) or not (No Auto
update).
9. Click OK to save the selected values.
discover why.
11. Under Security, in the left pane, select Anti-Virus.
12. Click Add in the right window to create a profile for the antivirus Juniper Express Engine. To edit an
existing item, select it and click Edit.
13. In the Main tab, next to Profile name, enter a unique name for this antivirus profile.
14. Select the Profile Type. In this case, select Juniper Express.
15. Next to Trickling timeout, enter timeout parameters.
248
Trickling applies only to HTTP. HTTP trickling is a mechanism used to prevent the HTTP client or
server from timing out during a file transfer or during antivirus scanning.
16. Next to Intelligent prescreening, select Yes or No.
Intelligent prescreening is only intended for use with non-encoded traffic. It is not applicable for
mail protocols (SMTP, POP3, IMAP, and HTTP POST).
17. Next to Content Size Limit, enter content size parameters. The content size check occurs before the
scan request is sent. The content size refers to accumulated TCP payload size.
18. Next to Scan engine timeout, enter scanning timeout parameters.
19. Select the Fallback settings tab.
20. Next to Default (fallback option), select Log and permit or Block from the list. In most cases, Block is
the default fallback option.
21. Next to Decompress Layer (fallback option), select Log and permit or Block from the list.
22. Next to Content Size (fallback option), select Log and permit or Block from the list.
23. Next to Engine Not Ready (fallback option), select Log and permit or Block from the list.
24. Next to Timeout (fallback option), select Log and permit or Block from the list.
25. Next to Out of Resource (fallback option), select Log and permit or Block from the list.
26. Next to Too Many Requests (fallback option), select Log and permit or Block from the list.
27. Select the Notification options tab.
28. In the Fallback block section, next to Notification type, select Protocol Only or Message to select
the type of notification that is sent when a fallback option of block is triggered.
29. Next to Notify mail sender, select Yes or No.
30. If you selected Yes, next to Custom Message, enter text for the message body of your custom
message for this notification (if you are using a custom message).
31. Next to Custom message subject, enter text to appear in the subject line of your custom message
for this notification (if you are using a custom message).
32. In the Fallback non block section, next to Notify mail recipient, select Yes or No.
35. Select the Notification options cont tab.
36. In the Virus detection section, next to Notification type, select Protocol Only or Message to select
for this notification (if you are using a custom message). The limit is 255 characters.
249
40. Click OK to check your configuration and save it as a candidate configuration, then click Commit
Options>Commit.
again. If it is not saved successfully, you can click Details in the pop-up that appears window to
discover why.
You create a separate antivirus profile for each antivirus protocol. These profiles may basically
contain the same configuration information, but when you are creating your UTM policy for
antivirus, the UTM policy configuration page provides separate antivirus profile selection fields for
each supported protocol.
SEE ALSO
Example: Configuring Express Antivirus UTM Policies
IN THIS SECTION
Requirements | 249
Overview | 249
Configuration | 250
Verification | 250
Release 17.3R1 onwards. For previous releases, this example shows how to create an express antivirus
UTM policy to attach to your feature profile.
Requirements
Before you begin, create an antivirus feature profile. See "Example: Configuring Express Antivirus
Feature Profiles" on page 240.
Overview
In this example, you configure an express antivirus UTM policy called utmp3 and attach the policy to the
antivirus profile called junexprof1.
250
Configuration
IN THIS SECTION
Procedure | 250
Procedure
To configure an express antivirus UTM policy:
1. Create a UTM policy for HTTP antivirus scanning and attach the policy to the profile.
[edit]
user@host# set security utm utm-policy utmp3 anti-virus http-profile junexprof1
[edit]
user@host# commit
Verification
IN THIS SECTION
Purpose
To verify the UTM configuration is working properly.

251
Action
Configuring Express Antivirus UTM Policies (J-Web Procedure)
Release 17.3R1 onwards. For previous releases, after you have created an antivirus feature profile,
configure a UTM policy to which you can attach the feature profile:
1. Select Configure>Security>Policy>UTM Policies.

2. From the UTM policy configuration window, click Add to configure a UTM policy. The policy
3. Select the Main tab.
4. In the Policy name box, enter a unique name.
5. In the Session per client limit box, enter a session per client limit from 0 to 20000 for this UTM
policy.
6. In the Session per client over limit list, select the action that the device should take when the
7. Select the Anti-Virus profiles tab.
8. Select the appropriate profile you have configured from the list for the corresponding protocol
listed.
9. Click OK.
10. If the policy is saved successfully, you receive a confirmation and you must click OK again. If the
profile is not saved successfully, you can click Details in the pop-up window that appears to
discover why.
Example: Attaching Express Antivirus UTM Policies to Security Policies
IN THIS SECTION
Requirements | 252
Overview | 252
Configuration | 252
252
Verification | 253
Release 17.3R1 onwards. For previous releases, this example shows how to attach an express antivirus
UTM policy to a security policy.
Requirements
Before you begin, create a UTM policy. See "Example: Configuring Express Antivirus UTM Policies" on
page 249.
Overview
In this example, you attach the express antivirus UTM policy called utmp3 to the security policy called
p3.
Configuration
IN THIS SECTION
Procedure | 252
Procedure
To attach an express antivirus UTM policy to a security policy:
1. Enable and configure the security policy.
[edit]
user@host# set security policies from-zone trust to-zone untrust policy p3 match source-
address any
user@host# set security policies from-zone trust to-zone untrust policy p3 match destination-
address any
253
user@host# set security policies from-zone trust to-zone untrust policy p3 match application
junos-http
[edit]
[edit]
user@host# commit
Verification
IN THIS SECTION
Verify the Security Policy Configuration | 253
Verify the Security Policy Configuration
Purpose
To verify the security policy configuration is working properly.
Action
From the operational mode, enter the show security policies detail command.
254
Attaching Express Antivirus UTM Policies to Security Policies (J-Web

Procedure)
Release 17.3R1 onwards. For previous releases, after you create a UTM policy, create a security policy
and attach the UTM policy to the security policy:
1. Select Configure>Security>Policy>FW Policies.

2. From the Security Policy window, click Add to configure a security policy with UTM. The policy
3. In the Policy tab, enter a name in the Policy Name box.
4. Next to Default Policy Action, select one of the following: Deny-All or Permit-All.
5. Next to From Zone, select a zone from the list.
6. Next to To Zone, select a zone from the list.
7. Under Zone Direction, click Add a Policy.
8. Choose a Source Address.
9. Choose a Destination Address.
10. Choose an application by selecting junos-protocol (for all protocols that support antivirus scanning)
in the Application Sets box and clicking the —> button to move it to the Matched box.
11. Next to Policy Action, select Permit.
12. Select the Application Services tab.
13. Next to UTM Policy, select the appropriate policy from the list. This action attaches your UTM
policy to the security policy.
14. Click OK.
Options>Commit.
discover why.
You must activate your new policy to apply it.
Release Description
15.1X49-D10 The Express Antivirus feature is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards.
255

256
Express Antivirus Pattern Updates
IN THIS SECTION
Example: Automatically Updating Express Antivirus Patterns (J-Web Procedure) | 259
Manually Updating, Reloading, and Deleting Express Antivirus Patterns (CLI Procedure) | 259
The express antivirus pattern database is updated over HTTP or HTTPS and can occur automatically or
manually. For more information, see the following topics:
Understanding Express Antivirus Scanner Pattern Updates
Release 17.3R1 onwards. For previous releases, Express antivirus uses a different signature database
than the full antivirus signature database. The express antivirus signature database is called Juniper
Express antivirus database and it is compatible with the hardware engine. The express signature
database targets only critical viruses and malware, including worms, Trojans, and spyware. This is a
smaller sized database, providing less coverage than the full antivirus signature database.
The express antivirus pattern database is updated over HTTP or HTTPS and can occur automatically or
manually. This is similar functionality to that found in full antivirus with some minor differences:
• With express antivirus, the signature database auto-update interval, is once a day.
• With express antivirus, there is no support for the downloading of multiple database types.
• With express antivirus, during database loading, all scan operations are interrupted. Scan operations
for existing traffic flows are stopped and no new scan operations are initiated for newly established
traffic flows. You can specify the desired action for this interruption period using the fall-back
parameter for engine-busy-loading-database. The available actions are block or log-and-permit.
• By default, the URL for express antivirus is http://update.juniper-updates.net/EAV/SRX-platform-

name where SRX-platform-name is the name of your device. If your device is an SRX210, then the
URL for express antivirus would be http://update.juniper-updates.net/EAV/SRX210. The SRX-
platform-name part of the URL is different and platform-specific. (Other than the platform name, you
257
should not change this URL unless you are experiencing problems with it and have called for support.
Platform support depends on the Junos OS release in your installation.)
Once your subscription expires, you have a 30 day grace period during which you can continue to
update the antivirus pattern file. Once that grace period expires, the update server no longer permits
antivirus pattern file updates.
The express Antivirus scanning feature is a separately licensed subscription service. When your
antivirus license key expires, you can continue to use locally stored antivirus signatures. But in that
case, if the local database is deleted, antivirus scanning is disabled.
SEE ALSO
Example: Automatically Updating Express Antivirus Patterns
IN THIS SECTION
Requirements | 257
Overview | 258
Configuration | 258
Verification | 258
Release 17.3R1 onwards. For previous releases, this example shows how to update the pattern file
automatically on a security device.
Requirements
Before you begin:
• Obtain a valid antivirus scanner license. See "Full Antivirus Protection Overview" on page 261.
• Get network connectivity and access to the pattern database server. See "Understanding Full
Antivirus Pattern Updates" on page 288.
• Configure your DNS settings and port settings (port 80) correctly. See DNS Overview.
258
Overview
In this example, you configure the security device to update the pattern file automatically every 120
minutes. (The default antivirus pattern-update interval is once a day.)
Configuration
IN THIS SECTION
Procedure | 258
Procedure
To configure the security device to update the pattern file automatically:
1. Set the interval.
[edit]
user@host# set security utm feature-profile anti-virus juniper-express-engine pattern-update
interval 120
[edit]
user@host# commit
Verification
IN THIS SECTION

259
Purpose
Action
Example: Automatically Updating Express Antivirus Patterns (J-Web

Procedure)
Release 17.3R1 onwards. For previous releases, in this example, you configure the security device to
update the pattern file automatically every 120 minutes. (The default antivirus pattern-update interval is
once a day.)
To automatically update antivirus patterns:
1. Select Configure>Security>UTM>Anti-Virus.
2. Next to Interval, in the Juniper Express Engine section, enter 120 in the box.
Options>Commit.
Manually Updating, Reloading, and Deleting Express Antivirus Patterns

(CLI Procedure)
Release 17.3R1 onwards. For previous releases, to manually update antivirus patterns, enter the
following CLI statement:
user@host> request security utm anti-virus juniper-express-engine pattern-update

260
To manually reload antivirus patterns, enter the following CLI statement:
user@host> request security utm anti-virus juniper-express-engine pattern-reload
To manually delete antivirus patterns, enter the following CLI statement:
user@host> request security utm anti-virus juniper-express-engine pattern-delete
SEE ALSO
Allowlist | 24
Release Description

Full Antivirus Protection
IN THIS SECTION
Example: Configuring Full Antivirus Custom Objects | 263
Configuring Full Antivirus Custom Objects (J-Web Procedure) | 268
Example: Configuring Full Antivirus Feature Profiles | 271

261
Configuring Full Antivirus Feature Profiles (J-Web Procedure) | 279
Example: Configuring Full Antivirus UTM Policies | 281
Configuring Full Antivirus UTM Policies (J-Web Procedure) | 283
Example: Attaching Full Antivirus UTM Policies to Security Policies | 284
Attaching Full Antivirus UTM Policies to Security Policies (J-Web Procedure) | 286
The full file-based antivirus feature provides file-based scanning on specific Application Layer traffic
checking for viruses against a virus signature database. It collects the received data packets until it has
reconstructed the original application content, such as an e-mail file attachment, and then scans this
content. For more information, see the following topics:
Full Antivirus Protection Overview
A virus is executable code that infects or attaches itself to other executable code in order to reproduce
itself. Some malicious viruses erase files or lock up systems, while other viruses merely infect files and
can overwhelm the target host or network with bogus data. The full file-based antivirus feature provides
file-based scanning on specific Application Layer traffic checking for viruses against a virus signature
database. It collects the received data packets until it has reconstructed the original application content,
such as an e-mail file attachment, and then scans this content.
The full file-based antivirus scanning feature is a separately licensed subscription service. Kaspersky Lab
provides the scan engine for full file-based antivirus. 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.
The express antivirus feature provides better performance but lower security. Note that if you switch
from full file-based antivirus protection to express antivirus protection, you must reboot the device in
order for express antivirus to begin working.
The Kaspersky and Express Antivirus feature is not supported from Junos OS Release 15.1X49-D10 and
Junos OS Release 17.3R1 onwards. For previous releases, the Kaspersky scan engine is provided as a
downloadable UTM module. To download the Kaspersky scan engine, your SRX Series device must have
an active UTM license. When you install the KAV license, the system automatically downloads the
Kaspersky module from the Juniper Networks server and runs it.
When you set the antivirus type to KAV, and if the SRX Series device had a preinstalled Kaspersky
engine, then the downloaded module replaces the original module on the device. Regardless of the UTM
262
license status, when the KAV license is deleted from the device, the Kaspersky engine and all files
associated with KAV are removed from the system immediately.
Use the set security utm feature-profile anti-virus type kaspersky-lab-engine command to set the antivirus
type to KAV. If Kaspersky engine is not available on the device, and if the Kaspersky engine cannot be
downloaded from the predefined URL, then use the set security utm feature-profile anti-virus kaspersky-
lab-engine pattern-update url url command to configure the downloading application URL.
SEE ALSO

Full Antivirus Configuration Overview
Junos OS Release 17.3R1 onwards. For previous releases, when configuring antivirus protection, you
must first create the antivirus custom objects you are using. Those custom objects may include the
MIME pattern list, MIME exception list, and the filename extension list. Once you have created your
custom objects, you can configure full antivirus protection, including intelligent prescreening, and
content size limits.
To configure full file-based antivirus protection:
1. Configure UTM custom objects for the UTM feature. The following example enables the mime-
pattern, filename-extension, url-pattern, and custom-url-category custom-objects:
user@host# set security utm custom-objects mime-pattern

user@host# set security utm custom-objects filename-extension
user@host# set security utm custom-objects url-pattern
user@host# set security utm custom-objects custom-url-category
2. Configure the main feature parameters using feature profiles. The following example enables options
using the anti virus feature profile:
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update

user@host# set security utm feature-profile anti-virus kaspersky-lab-engine profile
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine profile fallback-
263
options
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine profile
notification-options
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine profile scan-
options
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine profile trickling
user@host# set security utm feature-profile anti-virus mime-whitelist
user@host# set security utm feature-profile anti-virus url-whitelist
3. Configure a UTM policy for each protocol and attach this policy to a profile. The following example
configure the utmp2 UTM policy for the HTTP protocol:
user@host# set security utm utm-policy utmp2 anti-virus http-profile http1
4. Attach the UTM policy to a security policy. The following example attaches the utmp2 UTM policy to
the p2 security policy:
SEE ALSO

Example: Configuring Full Antivirus Custom Objects
IN THIS SECTION
Requirements | 264
Overview | 264
Configuration | 264
Verification | 267
264
Junos OS Release 17.3R1 onwards. For previous releases, this example shows how to configure full
antivirus custom objects.
Requirements
Before you begin:
• Decide the type of full antivirus protection you require. See "Full Antivirus Protection Overview" on
page 261.
• Understand the order in which full antivirus parameters are configured. See "Full Antivirus Pattern
Update Configuration Overview" on page 291.
Overview
In this example, you define custom objects that are used to create full antivirus feature profiles. You
perform the following tasks to define custom objects:
1. Configure a filename extension list called extlist1 and add extensions such as .zip, .js, and .vbs to the
list.
2. Create two MIME lists called avmime1 and ex-avmime1 and add patterns to the list.
3. Configure a URL pattern list called urllist1.
4. Configure a custom URL category list called custurl1 using the urllist1 URL pattern list.
Configuration
IN THIS SECTION
Procedure | 265
265
Procedure
set security utm custom-objects filename-extension extlist1 value [zip js vbs]

set security utm custom-objects mime-pattern avmime1 value [video/quicktime image/x-portable-
set security utm custom-objects mime-pattern ex-avmime1 value [video/quicktime-inappropriate]
set security utm custom-objects url-pattern urllist1 value [http://www.url.com 5.6.7.8]
To configure full antivirus filtering custom objects:
1. Configure the filename extension list and add extensions to it.
[edit security utm]

user@host# set custom-objects filename-extension extlist1 value [zip js vbs]
NOTE: The Kaspersky scan engine ships with a read-only default extension list that you can
use.
2. Create MIME lists and add MIME patterns to the lists.
[edit security utm]

user@host# set custom-objects mime-pattern ex-avmime1 value [video/quicktime-inappropriate]
266
3. Configure a URL pattern list.
[edit security utm]

user@host# set custom-objects url-pattern urllist1 value [http://www.url.com 5.6.7.8]
• The following wildcard syntax is supported: http://*.example.net, http://www.example.ne?, http://

www.example.n??.
• The following wildcard syntax is not supported: *.example.net , www.example.ne?, http://

4. Configure a custom URL category list.
[edit security utm]

Results
to correct it.
[edit]
custom-objects {
mime-pattern {
267
avmime1 {
}
ex-avmime1 {
}
}
filename-extension {
extlist1 {
value [ zip js vbs ];
}
}
url-pattern {
urllist1 {
value [ http://www.url.com 5.6.7.8 ];
}
}
custurl1 {
value urllist1;
}
}
}
Verification
IN THIS SECTION
Verifying Full Antivirus Custom Objects | 267
Verifying Full Antivirus Custom Objects
Purpose
Verify the full antivirus custom objects.

268
Action
SEE ALSO
Allowlist | 24
Configuring Full Antivirus Custom Objects (J-Web Procedure)
Junos OS Release 17.3R1 onwards. For previous releases, to configure antivirus protection, you must
first create your custom objects (MIME Pattern List, Filename Extension List, URL Pattern List, and
Custom URL Category List).
Configure a MIME pattern list custom object:

2. From the MIME Pattern List tab, click the Add button to create MIME pattern lists.
3. In the Add MIME Pattern pop-up window, next to MIME Pattern Name, enter a unique name.
Keep in mind that you are creating a MIME allowlist and a MIME exception list (if necessary). Both
MIME lists appear in the MIME Allowlist and Exception MIME Allowlist fields when you configure
antivirus. Therefore, the MIME list names you create should be as descriptive as possible.
4. Next to MIME Pattern Value, enter the MIME pattern.
5. Click Add to add your MIME pattern to the Values list box. Within this box, you can also select an
entry and use the Delete button to delete it from the list. Continue to add MIME patterns in this
manner.
6. Optionally, create a new MIME list to act as an exception list. The exception list is generally a subset
of the main MIME list.
7. Click OK to check your configuration and save the selected values as part of the MIME list, then click
discover why.
Configure a filename extension list custom object:
2. From the Filename Extension List tab, click the Add button to create filename extension lists.
269
3. Next to File Extension Name, enter a unique name. This name appears in the Scan Option By
Extension list when you configure an antivirus profile.
4. In the Available Values box, select one or more default values (press Shift to select multiple
concurrent items or press Ctrl to select multiple separate items) and click the right arrow button to
move the value or values to the Selected Values box.
Options>Commit.
again. If the profile is not saved successfully, you can click Details in the pop-up window that appears
to discover why.
Configure a URL pattern list custom object:
2. From the URL Pattern List tab, click the Add button to create URL pattern lists.
3. Next to URL Pattern Name, enter a unique name. This name appears in the Custom URL Category
List Custom Object page for selection.
4. Next to URL Pattern Value, enter the URL or IP address you want added to the list for bypassing
scanning.
• The following wildcard syntax IS supported: http://*.example.net, http://www.example.ne?, http://

www.example.n??.
• The following wildcard syntax is NOT supported: *.example.net , www.example.ne?, http://

270
5. Click Add to add your URL pattern to the Values list box. The list can contain up to 8192 items. You
can also select an entry and use the Delete button to delete it from the list. Continue to add URLs or
IP addresses in this manner.
6. Click OK to check your configuration and save the selected values as part of the URL pattern list you
have created, then click Commit Options>Commit.
discover why.
Configure a custom URL category list custom object:
NOTE: Because you use URL Pattern Lists to create custom URL category lists, you must
2. In the URL Category List tab, click Add to create URL category lists.
3. Next to URL Category Name, enter a unique name. This name appears in the URL Allowlist list when
you configure antivirus global options.
4. In the Available Values box, select a URL Pattern List name from the list for bypassing scanning and
click the right arrow button to move it to the Selected Values box.
5. Click OK to check your configuration and save the selected values as part of the URL list that you
have created, then click Commit Options>Commit.
Click OK to save the selected values as part of the custom URL list you have created.
discover why.
SEE ALSO
Allowlist | 24
271
Example: Configuring Full Antivirus Feature Profiles
IN THIS SECTION
Requirements | 271
Overview | 271
Configuration | 273
Verification | 278
The full antivirus feature profile is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, this example shows how to configure a full antivirus
feature profile.
Requirements
Before you begin:
• Decide the type of full antivirus protection you require. See "Full Antivirus Protection Overview" on
page 261.
• Understand the order in which full antivirus parameters are configured. See "Full Antivirus
• MIME patterns must be defined for lists and exception lists. See Example: Configuring MIME
Allowlist to Bypass Antivirus Scanning.
Overview
In this example, you configure a feature profile called kasprof1 and specify custom objects to be used for
filtering content:
• Select and configure the engine type as Kaspersky Lab Engine.
• Select 120 as the time interval for updating the pattern database. The default full file-based antivirus
pattern-update interval is 60 minutes.
The command for changing the URL for the pattern database is:
[edit]
user@host# edit security utm feature-profile anti-virus kaspersky-lab-engine
272
[edit security utm feature-profile anti-virus kaspersky-lab-engine]

user@host# set pattern-update url http://..
• Enable an e-mail notification with a custom message as pattern file was updated and a custom
subject line as AV pattern file updated.
• Configure a list of fallback options as block.
• Configure the notification options for fallback blocking for virus detection. Configure a custom
message for the fallback blocking action.
• Configure a notification for protocol-only virus detection.
• Configure scan options. For this example, configure the device to perform a TCP payload content size
check before the scan request is sent.
• Configure the decompression layer limit. For this example configure the device to decompress three
layers of nested compressed files before it executes the virus scan.
• Configure content size parameters as 20000.
For SRX100, SRX110, SRX210, SRX220, and SRX240 devices the content size is 20000. For SRX650
devices the content size is 40,000. Platform support depends on the Junos OS release in your
installation.
• Configure scan extension settings. The default list is junos-default-extension. For this example, you
select extlist1, which you created as a custom object.
• Configure the scan mode setting to configure the device to use a custom extension list. Although you
can choose to scan all files, for this example you select only files with the extensions that you specify.
• Enable intelligent prescreening and set its timeout setting to 1800 seconds and trickling setting
(applicable only to HTTP) to 600 seconds. This means that if the device receives a packet within a
600-second period during a file transfer or while performing an antivirus scan, it should not time out.
Intelligent prescreening is only intended for use with non-encoded traffic. It is not applicable for mail
protocols (SMTP, POP3, IMAP) and HTTP POST.
The following example disables intelligent prescreening for the kasprof1 profile:

user@host# set profile kasprof1 scan-options no-intelligent-prescreening
• Configure the antivirus scanner to use MIME bypass lists and exception lists. You can use your own
custom object lists, or you can use the default list that ships with the device called junos-default-
bypass-mime. For this example, you use the avmime1 and ex-avmime1 lists.
273
• Configure the antivirus module to use URL bypass lists. If you are using a URL allowlist (valid only for
HTTP traffic), this is a custom URL category that you have previously configured as a custom object.
For this example, you enable the custurl1 bypass list.
Configuration
IN THIS SECTION
Procedure | 273
Procedure
set security utm feature-profile anti-virus type kaspersky-lab-engine

set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update interval 120
set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update email-notify
admin-email administrator@example.net custom-message patternfilewasupdated custom-message-
subject AVpatternfileupdated
set security utm feature-profile anti-virus kaspersky-lab-engine profile kasprof1 fallback-
options corrupt-file block
options decompress-layer block
options password-file block
274

set security utm feature-profile anti-virus kaspersky-lab-engine profile kasprof1 notification-
options fallback-block custom-message “Dropped due to fallback settings”
set security utm feature-profile anti-virus kaspersky-lab-engine profile kasprof1 notification-
options virus-detection type protocol-only
set security utm feature-profile anti-virus kaspersky-lab-engine profile kasprof1 scan-options
content-size-limit 20000
decompress-layer-limit 3
intelligent-prescreening
scan-extension extlist1
scan-mode by-extension
timeout 1800
set security utm feature-profile anti-virus kaspersky-lab-engine profile kasprof1 trickling
timeout 600
set security utm feature-profile anti-virus mime-whitelist list avmime1
set security utm feature-profile anti-virus mime-whitelist list avmime1 exception ex-avmime1
set security utm feature-profile anti-virus url-whitelist custurl1
To configure full antivirus feature profiles:
[edit]
user@host# set security utm feature-profile anti-virus type kaspersky-lab-engine
user@host#set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update
interval 120
275
2. Configure the device to notify a specified administrator when patterns are updated.

user@host# set pattern-update email-notify admin-email administrator@example.net custom-
message patternfilewasupdated custom-message-subject AVpatternfileupdated
3. Create a profile for the Kaspersky Lab engine and configure fallback options as block.

user@host# set profile kasprof1 fallback-options content-size block
user@host# set profile kasprof1 fallback-options corrupt-file block
user@host# set profile kasprof1 fallback-options decompress-layer block
user@host# set profile kasprof1 fallback-options default block
user@host# set profile kasprof1 fallback-options engine-not-ready block
user@host# set profile kasprof1 fallback-options out-of-resources block
user@host# set profile kasprof1 fallback-options password-file block
user@host# set profile kasprof1 fallback-options timeout block
user@host# set profile kasprof1 fallback-options too-many-requests block
4. Configure a custom notification for the fallback blocking action and send a notification.

user@host# set profile kasprof1 notification-options fallback-block custom-message “Dropped
due to fallback settings”
5. Configure a notification for protocol-only virus detection.

user@host# set profile kasprof1 notification-options virus-detection type protocol-only
6. Configure content size parameter.

user@host# set profile kasprof1 scan-options content-size-limit 20000
276
7. Configure the decompression layer limit.

user@host# set profile kasprof1 scan-options decompress-layer-limit 3
8. Configure intelligent prescreening.

user@host# set profile kasprof1 scan-options intelligent-prescreening
9. Configure scan extension setting.

user@host# set profile kasprof1 scan-options scan-extension extlist1
10. Configure the scan mode setting.

user@host# set profile kasprof1 scan-options scan-mode by-extension
11. Configure the timeout setting.

user@host# set profile kasprof1 scan-options timeout 1800
12. Configure trickling setting.

user@host# set profile kasprof1 trickling timeout 600
13. Configure the antivirus scanner to use MIME bypass lists and exception lists.

user@host# set mime-whitelist list avmime1 exception ex-avmime1
277
14. Configure the antivirus module to use URL bypass lists.

Results
[edit]
user@host# show security utm feature-profile anti-virus
mime-whitelist {
list avmime1;
exception ex-avmime1;
}
kaspersky-lab-engine {
pattern-update {
email-notify {
admin-email "administrator@example.net";
custom-message patternfilewasupdated;
custom-message-subject AVpatternfileupdated;
}
interval 120;
}
profile kasprof1 {
fallback-options {
default block;
corrupt-file block;
password-file block;
decompress-layer block;
content-size block;
timeout block;
}
scan-options {
278
scan-mode by-extension;
scan-extension extlist1;
content-size-limit 20000;
timeout 1800;
decompress-layer-limit 3;
}
trickling timeout 600;
virus-detection {
type protocol-only;
custom-message ***virus-found***;
}
fallback-block {
custom-message “Dropped due to fallback settings”;
}
}
}
}
Verification
IN THIS SECTION
Verifying the Configuration of Full Antivirus Feature Profile | 278
Verifying the Configuration of Full Antivirus Feature Profile
Purpose
Verify the full antivirus feature profile.
Action
279
SEE ALSO

Configuring Full Antivirus Feature Profiles (J-Web Procedure)
Release 17.3R1 onwards. For previous releases, after you have created your custom object, configure an
antivirus feature profile:
1. Select Configure>Security>UTM>Global options.

2. In the Anti-Virus tab, next to MIME whitelist, select the custom object you created from the list.
3. Next to Exception MIME whitelist, select the custom object you created from the list.
4. Next to URL Whitelist, select the custom object you created from the list.
5. In the Engine Type section, select the type of engine you are using. For full antivirus protection, you
should select Kaspersky Lab.
6. In the Kaspersky Lab Engine Option section, in the Pattern update URL box, enter the URL for the
pattern database.
The URL is http://update.juniper-updates.net/AV/<device version> and you should not change it.
7. Next to Pattern update interval, enter the time interval, in seconds, for automatically updating the
pattern database in the box. The default interval is 60.
8. Select whether you want the pattern file to update automatically (Auto update) or not (No Auto
update).
9. Click OK to save the selected values.
again. If it is not saved successfully, you can click Details in a pop-up window that appears to
discover why.
11. Under Security, in the left pane, select Anti-Virus.
12. In the right window, click Add to create a profile for the antivirus Kaspersky Lab Engine. (To edit an
existing item, select it and click the Edit button.)
13. Next to Profile name, enter a unique name for this antivirus profile.
14. Select the Profile Type. In this case, select Kaspersky.
15. Next to Trickling timeout, enter timeout parameters.
280
NOTE: Trickling applies only to HTTP. HTTP trickling is a mechanism used to prevent the
HTTP client or server from timing out during a file transfer or during antivirus scanning.
16. Next to Intelligent prescreening, select Yes or No.

17. In the Scan Options section, next to Intelligent prescreening, select Yes if you are using it.
18. Next to Content Size Limit, enter content size parameters. The content size check occurs before the
scan request is sent. The content size refers to accumulated TCP payload size.
19. Next to Scan engine timeout, enter scanning timeout parameters.
20. Next to Decompress Layer Limit, enter decompression layer limit parameters.
21. In the Scan mode section, select either Scan all files, if you are scanning all content, or Scan files
with specified extension, if you are scanning by file extensions.
If you select Scan files with specified extension, you must select a filename extension list custom
object from the Scan engine filename extention list that appears.
22. Select the Fallback settings tab.
23. Next to Default (fallback option), select Log and permit or Block from the list. In most cases, Block is
the default fallback option.
24. Next to Corrupt File (fallback option), select Log and permit or Block from the list.
25. Next to Password File (fallback option), select Log and permit or Block from the list.
26. Next to Decompress Layer (fallback option), select Log and permit or Block from the list.
27. Next to Content Size (fallback option), select Log and permit or Block from the list.
28. Next to Engine Not Ready (fallback option), select Log and permit or Block from the list.
29. Next to Timeout (fallback option), select Log and permit or Block from the list.
30. Next to Out Of Resources (fallback option), select Log and permit or Block from the list.
31. Next to Too Many Request (fallback option), select Log and permit or Block from the list.
32. Select the Notification options tab.
33. In the Fallback block section, next to Notification type, select Protocol Only or Message to select
281
37. In the Fallback non block section, next to Notify mail recipient, select Yes or No.
40. Select the Notification options cont tab.
41. In the Virus detection section, next to Notification type, select Protocol Only or Message to select
for this notification (if you are using a custom message). The limit is 255 characters.
Options>Commit.
discover why.
You create a separate antivirus profile for each antivirus protocol. These profiles may basically
contain the same configuration information, but when you are creating your UTM policy for an
antivirus profile, the UTM policy configuration page provides separate antivirus profile selection
fields for each supported protocol.
SEE ALSO

Example: Configuring Full Antivirus UTM Policies
IN THIS SECTION
Requirements | 282
Overview | 282
282
Configuration | 282
Verification | 283
Release 17.3R1 onwards. For previous releases, this example shows how to create a UTM policy to
attach to a feature profile.
Requirements
Before you begin, create an antivirus feature profile. See "Example: Configuring Full Antivirus Feature
Profiles" on page 271.
Overview
In this example, you configure a full antivirus UTM policy called utmp2 and attach the policy to an HTTP
profile called kasprofile1 HTTP.
Configuration
IN THIS SECTION
Procedure | 282
Procedure
To configure a full antivirus UTM policy:
1. Create a UTM policy for HTTP antivirus scanning and attach the policy to the profile.
[edit]
user@host# set security utm utm-policy utmp2 anti-virus http-profile kasprofile1
283
[edit]
user@host# commit
Verification
IN THIS SECTION
Purpose
Action
SEE ALSO
Configuring Full Antivirus UTM Policies (J-Web Procedure)
The full antivirus UTM policies is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, after you have created an antivirus feature profile,
configure a UTM policy to which you can attach the feature profile:
1. Select Configure>Security>Policy>UTM Policies.

2. From the UTM policy configuration window, click Add to configure a UTM policy. This action takes
you to the policy configuration pop-up window.
3. Select the Main tab in pop-up window.
284
4. In the Policy name box, enter a unique name for the UTM policy.
5. In the Session per client limit box, enter a session per client limit from 0 to 20000 for this UTM
policy.
6. In the Session per client over limit list, select the action that the device should take when the
7. Select the Anti-Virus profiles tab in the pop-up window.
8. Select the appropriate profile you have configured from the list for the corresponding protocol
listed.
Options>Commit.
discover why.
Example: Attaching Full Antivirus UTM Policies to Security Policies
IN THIS SECTION
Requirements | 284
Overview | 284
Configuration | 285
Verification | 286
Release 17.3R1 onwards. For previous releases, this example shows how to attach a UTM policy to a
security policy.
Requirements
Before you begin, create a UTM policy. See "Example: Configuring Full Antivirus UTM Policies" on page
281.
Overview
In this example, you attach the UTM policy called utmp2 to the security policy called p2.
285
Configuration
IN THIS SECTION
Procedure | 285
Procedure
To attach a full antivirus UTM policy to a security policy:
1. Enable and configure the security policy.
[edit]
user@host# set security policies from-zone trust to-zone untrust policy p2 match source-
address any
user@host# set security policies from-zone trust to-zone untrust policy p2 match destination-
address any
user@host# set security policies from-zone trust to-zone untrust policy p2 match application
junos-http
[edit]
[edit]
user@host# commit
286
Verification
IN THIS SECTION
Verify the Security Policies Configuration | 286
Verify the Security Policies Configuration
Purpose
To verify the security policies configuration is working properly.
Action
From the operational mode, enter the show security policies command.
Attaching Full Antivirus UTM Policies to Security Policies (J-Web

Procedure)
Release 17.3R1 onwards. For previous releases, after you create a UTM policy, create a security policy
and attach the UTM policy to the security policy:
1. Select Configure>Security>Policy>FW Policies.

2. From the Security Policy window, click Add to configure a security policy with UTM. This action
takes you to the policy configuration pop-up window.
3. In the Policy tab, enter a name in the Policy Name box.
4. Next to From Zone, select a zone from the list.
5. Next to To Zone, select a zone from the list.
6. Choose a Source Address.
7. Choose a Destination Address.
8. Choose an application by selecting junos-protocol (for all protocols that support antivirus scanning)
in the Application Sets box and clicking the —> button to move it to the Matched box.
9. Next to Policy Action, select Permit.
287
10. Select the Application Services tab in the pop-up window.
11. Next to UTM Policy, select the appropriate policy from the list. This action attaches your UTM
policy to the security policy.
Options>Commit.
discover why.
You must activate your new policy to apply it.
Release Description
15.1X49-D10 The Kaspersky and Express Antivirus feature is not supported from Junos OS Release 15.1X49-
15.1X49-D10 The full antivirus feature profile is not supported from Junos OS Release 15.1X49-D10 and Junos
OS Release 17.3R1 onwards.
15.1X49-D10 The full antivirus UTM policies is not supported from Junos OS Release 15.1X49-D10 and Junos
288

Full Antivirus Pattern Updates
IN THIS SECTION
Full Antivirus Pattern Update Configuration Overview | 291
Example: Automatically Updating Full Antivirus Patterns | 292
Example: Automatically Updating Full Antivirus Patterns (J-Web Procedure) | 294
Manually Updating, Reloading, and Deleting Full Antivirus Patterns (CLI Procedure) | 295
The full file-based antivirus protection signature database is called the Juniper Full antivirus database, it
detects all destructive malicious code, including viruses (polymorphic and other advanced virus types),
worms, Trojans, and malware. For more information, see the following topics:
Understanding Full Antivirus Pattern Updates
The full antivirus Pattern Updates is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, the full file-based antivirus protection signature
database is called the Juniper Full antivirus database (downloaded by the pattern-update command).
This database is different from the database used by express antivirus. It detects all destructive
289
malicious code, including viruses (polymorphic and other advanced virus types), worms, Trojans, and
malware.
Updates to the pattern file are added as new viruses are discovered. When Kaspersky Lab updates the
signatures in its pattern database, the security device downloads these updates so that the antivirus
scanner is using the latest, most up-to-date signatures when scanning traffic. The security device can
perform these updates automatically (the default), or you can perform pattern update downloads
manually.
The database pattern server is accessible through HTTP or HTTPS. By default, the antivirus module
checks for database updates automatically every 60 minutes. You can change this interval and you can
trigger updates manually, as well. The number of files that are downloaded during an update and the
duration of the download process can vary.
A local copy of the pattern database is saved in persistent data storage (that is, the flash disk). If the
device is rebooted, the local copy remains available for the antivirus scan engine to use during the
antivirus scan engine initialization time, without the need for network access to the pattern database
server.
If the auto-update fails, the updater automatically retries to update three more times. If the database
download continues to fail, the updater stops trying and waits for the next periodic update before trying
again.
Once your subscription expires, you have a 30 day grace period during which you can continue to
update the antivirus pattern file. Once that grace period expires, the update server no longer permits
antivirus pattern file updates.
SEE ALSO
Example: Configuring the Full Antivirus Pattern Update Server
IN THIS SECTION
Requirements | 290
Overview | 290
Configuration | 290
Verification | 291
290
Release 17.3R1 onwards. For previous releases, this example shows how to configure the pattern-
update server on the security device.
Requirements
Before you begin:
Overview
To configure the pattern-update server on the security device, enter the URL address of the pattern-
update server.
By default, the Juniper-Kaspersky URL for full antivirus protection is http://update.juniper-

updates.net/AV/device-name, where device-name is the name of your device.
Configuration
IN THIS SECTION
Procedure | 290
Procedure
To configure the pattern-update server on a security device:
1. Specify the URL of the pattern-update server.
[edit]
url http://update.juniper-updates.net/AV/device-name
291
NOTE: Other than the platform name, you should not change this URL unless you are
experiencing problems with it and have called for support.
[edit]
user@host# commit
Verification
IN THIS SECTION
Purpose
Action
Full Antivirus Pattern Update Configuration Overview
The Kaspersky Antivirus feature is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, Before you begin, there are several prerequisites that
must be met in order to perform a successful pattern database update:
• You must have a valid antivirus scanner license.
• You must have network connectivity and access to the pattern database server.
• Your DNS settings and port settings (port 80) must be correct.
292
To update the patterns for the antivirus signature database:
1. On the security device, specify the URL address of the pattern-update server.
2. (Optional) Specify how often the device should automatically check for pattern-server updates.
After the security device downloads the server-initialization file, the device checks that the pattern file is
valid. The device then parses the file to obtain information about it, including the file version, size, and
location of the pattern file server.
If the pattern file on the security device is out-of-date (or nonexistent because this is the first time you
are loading it), and, if the antivirus pattern-update service subscription is still valid, the device
automatically retrieves an updated pattern file from the pattern file server.
The following is an example of the CLI for configuring the database update feature:
utm {
feature-profile {
anti-virus {
type
pattern-update
url url
interval minutes
}
}
}
}
Example: Automatically Updating Full Antivirus Patterns
IN THIS SECTION
Requirements | 293
Overview | 293
Configuration | 293
Verification | 294
293
Release 17.3R1 onwards. For previous releases, this example shows how to update the pattern file
automatically on a security device.
Requirements
Before you begin:
Overview
In this example, you configure the security device to update the pattern file automatically every 120
minutes. (The default antivirus pattern-update interval is 60 minutes.)
Configuration
IN THIS SECTION
Procedure | 293
Procedure
To configure the security device to update the pattern file automatically:
1. Set the interval.
[edit]
interval 120
294
[edit]
user@host# commit
Verification
IN THIS SECTION
Purpose
Action
Example: Automatically Updating Full Antivirus Patterns (J-Web

Procedure)
Release 17.3R1 onwards. For previous releases, in this example, you configure the security device to
update the pattern file automatically every 120 minutes. (The default antivirus pattern-update interval is
60 minutes.)
To automatically update antivirus patterns:
1. Select Configure>UTM>Anti-Virus.
2. Next to Interval, in the Kaspersky Lab Engine section, enter 120 in the box.
Options>Commit.
295
Manually Updating, Reloading, and Deleting Full Antivirus Patterns (CLI

Procedure)
Release 17.3R1 onwards. For previous releases, to manually update antivirus patterns, enter the
following CLI command:
user@host> request security utm anti-virus kaspersky-lab-engine pattern-update
To manually reload antivirus patterns, enter the following CLI command:
user@host> request security utm anti-virus kaspersky-lab-engine pattern-reload
To manually delete antivirus patterns, enter the following CLI command:
user@host> request security utm anti-virus kaspersky-lab-engine pattern-delete
You can update the Kaspersky antivirus signature database offline without using a direct Internet
connection. This is required in some security installations and for sites that access the Internet through a
proxy server.
To update the Kaspersky antivirus signature database offline, you must configure a local webserver.
To configure a webserver, use the following CLI statement.
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update url

<http_server>
user@host# commit
To update the Kaspersky antivirus signature database, perform the following tasks:
1. Based on your hardware platform, enter the following URLs in your computer browser.
2. Copy all the files to a directory on your local webserver. You might want to use a download manager
for your browser to get all the files more quickly.
3. Download the Kaspersky Lab engine from http://update.juniper-updates.net/KAV_engine/.
• For JSR, the URL is http://update.juniper-updates.net/KAV_engine/i386/.
• For SRX210, SRX220, SRX240, SRX550, and SRX650 devices, the URL is http://update.juniper-
updates.net/KAV_engine/octeon32/.
296
4. Copy all the files to the same directory on your local server.
NOTE: The Kaspersky Lab engine is automatically loadable. For updating the Kaspersky
antivirus signature database offline, both pattern update files and Kaspersky Lab engine files
must be placed in the same folder on the local webserver.
5. Set the directory as a sharepoint that can be accessed through HTTP from the SRX Series device.
6. Run the update command in the CLI.
user@host>request security utm anti-virus kaspersky-lab-engine pattern-update
Release Description
15.1X49-D10 The full antivirus Pattern Updates is not supported from Junos OS Release 15.1X49-D10 and
15.1X49-D10 The Kaspersky Antivirus feature is not supported from Junos OS Release 15.1X49-D10 and Junos

297
Full Antivirus File Scanning
IN THIS SECTION
Configuring Full Antivirus File Extension Scanning (CLI Procedure) | 299
Example: Configuring Full Antivirus File Extension Scanning | 300
Example: Configuring Full Antivirus Scan Settings at Different Levels | 303
Configuring Full Antivirus Content Size Limits (CLI Procedure) | 309
Configuring Full Antivirus Decompression Layer Limits (CLI Procedure) | 310
Configuring Full Antivirus Scanning Timeouts (CLI Procedure) | 311
Understanding Full Antivirus Scan Session Throttling | 311
Configuring Full Antivirus Scan Session Throttling (CLI Procedure) | 312
The full file-based antivirus module is the software subsystem on the gateway device that scans specific
Application Layer traffic to protect users from virus attacks and to prevent viruses from spreading. The
antivirus module allows you to configure scanning options on a global level, on a UTM profile level, or on
a firewall policy level. For more information, see the following topics:
Understanding the Full Antivirus Scan Engine
Release 17.3R1 onwards. For previous releases, the full file-based antivirus module is the software
subsystem on the gateway device that scans specific Application Layer traffic to protect users from virus
298
attacks and to prevent viruses from spreading. The antivirus software subsystem consists of a virus
signature database, an application proxy, the scan manager, and the scan engine.
Kaspersky Lab provides the scan engine and it works in the following manner:
1. A client establishes a TCP connection with a server and then starts a transaction.
2. If the application protocol in question is marked for antivirus scanning, the traffic is forwarded to an
application proxy for parsing.
3. When the scan request is sent, the scan engine scans the data by querying a virus pattern database.
4. The scan manager monitors antivirus scanning sessions, checking the properties of the data content
against the existing antivirus settings.
5. After scanning has occurred, the result is then handled by the scan manager.
The Kaspersky Lab scan engine supports regular file scanning and script file scanning. With regular file
scanning, the input object is a regular file. The engine matches the input content with all possible
signatures. With script file scanning, the input object is a script file. It can be JavaScript, VBScript, mIRC
script, bat scripts (DOS bat files), and other text scripts. The engine matches the input content only with
signatures for script files. Script scanning is only applicable for HTML content over the HTTP protocol.
There are two criteria for this scan type. First, the content-type field of this HTML document must be
text or HTML. Second, there is no content encoding in the HTTP header. If those two criteria are met,
an HTML parser is used to parse the HTML document for scripts.
SEE ALSO

Understanding Full Antivirus Scan Mode Support
The Kaspersky Lab scan engine is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, the Kaspersky Lab scan engine supports two modes of
scanning:
• scan-all—This option tells the scan engine to scan all the data it receives.
• scan-by-extension—This option bases all scanning decisions on the file extensions found in the traffic
in question.
299
When scanning content, you can use a file extension list to define a set of file extensions that are used
in file extension scan mode (scan-by-extension). The antivirus module can then scan files with
extensions on the scan-extension list. If an extension is not defined in an extension list, the file with that
extension is not scanned in scan-by-extension mode. If there is no extension present, the file in question
is scanned.
When using a file extension list to scan content, please note the following requirements:
• File extension entries are case-insensitive.
• The maximum length of the file extension list name is 29 bytes.
• The maximum length of each file extension entry is 15 bytes.
• The maximum entry number in a file extension list is 255.
SEE ALSO
Configuring Full Antivirus File Extension Scanning (CLI Procedure)
The Kaspersky Lab scan is not supported from Junos OS Release 15.1X49-D10 and Junos OS Release
17.3R1 onwards. For previous releases, to configure file-extension scanning, use the following CLI
configuration statements:
security utm {
custom-objects {
filename-extension { ; set of list
name extension-list-name; #mandatory
value windows-extension-string;
}
}
}

scan-options {
scan-extension ext-list
300
}
}
Example: Configuring Full Antivirus File Extension Scanning
IN THIS SECTION
Requirements | 300
Overview | 300
Configuration | 301
Verification | 302
17.3R1 onwards. For previous releases, this example shows how to configure full antivirus file extension
scanning.
Requirements
Before you begin, decide the mode of scanning you require. See "Understanding Full Antivirus Scan
Mode Support" on page 298.
Overview
In this example, you perform the following tasks:
1. Create a file called extlist1 for the kasprof1 profile, and add extensions such as .zip, .js, and .vbs to
the extlist1.
2. Configure the scan mode setting. You can choose to scan all files or to scan only the files that have
the extensions that you specify. This example uses the scan by-extension option to configure the
device to use the extlist1 file.
301
Configuration
IN THIS SECTION
Procedure | 301
Procedure
To configure full antivirus file extension scanning:
1. Create a extension for the list and add extensions to the filename extension list.
[edit]
user@host# set security utm custom-objects filename-extension extlist1 value [zip js vbs]
2. Configure scan extension settings.
[edit]
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine profile kasprof1
scan-options scan-extension extlist1
3. Configure the scan mode setting.
[edit]
scan-options scan-mode by-extension
[edit]
user@host# commit
302
Verification
IN THIS SECTION
Purpose
Action
SEE ALSO
Understanding Full Antivirus Scan Level Settings
17.3R1 onwards. For previous releases, the antivirus module allows you to configure scanning options
on a global level, on a UTM profile level, or on a firewall policy level. Each configuration level has the
following implications:
• Global antivirus settings—Settings are applied to all antivirus sessions. Global settings are general
overall configurations for the antivirus module or settings that are not specific for profiles.
• Profile-based settings—Antivirus settings are different for different protocols within the same policy.
• Policy-based settings—Antivirus settings are different for different policies. Policy-based antivirus
settings are applied to all scan-specified traffic defined in a firewall policy.
The majority of antivirus settings are configured within an antivirus profile, bound to specified protocols,
and used by designated policies. These UTM policies are then applied to the traffic according to firewall
303
policies. If a firewall policy with an antivirus setting matches the properties of a traffic flow, the antivirus
setting is applied to the traffic session. Therefore, you can apply different antivirus settings for different
protocols and for different traffic sessions.
SEE ALSO
Example: Configuring Full Antivirus Scan Settings at Different Levels
IN THIS SECTION
Requirements | 303
Overview | 303
Configuration | 304
Verification | 305
17.3R1 onwards. For previous releases, this example shows how to configure full antivirus scan settings
at different levels.
Requirements
Before you begin, decide the type of scanning option you require. See "Understanding Full Antivirus
Scan Level Settings" on page 302.
Overview
In this example, you define antivirus scanning options on any of the following levels:
• Global level
• UTM profile level using the kasprof1 UTM profile
• Firewall policy level using the p1 UTM policy

304
Configuration
IN THIS SECTION
Procedure | 304
Procedure
set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update interval 20

set utm-policy p1 anti-virus http-profile av-profile
To configure antivirus scanning options at different levels:
1. Configure scanning options at the global level.
[edit security utm]

user@host# set feature-profile anti-virus kaspersky-lab-engine pattern-update interval 20
2. Configure scanning options at the UTM profile level.
[edit security utm]

user@host# set feature-profile anti-virus kaspersky-lab-engine profile kasprof1 fallback-
305
3. Configure scanning options at the UTM policy level.
[edit security utm]

user@host# set utm-policy p1 anti-virus http-profile av-profile
Results
to correct it.
[edit]
...
utm-policy p1 {
anti-virus {
http-profile av-profile
ftp {
upload-profile av-profile
download-profile av-profile
}
}
}
...
Verification
IN THIS SECTION
Verifying Scan Settings at Different Levels | 306

306
Verifying Scan Settings at Different Levels
Purpose
Verify the scan settings at different levels.
Action
SEE ALSO
Understanding Full Antivirus Intelligent Prescreening
The Intelligent prescreening is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, by default, intelligent prescreening is enabled to
improve antivirus scanning performance. The antivirus module generally begins to scan data after the
gateway device has received all the packets of a file. Intelligent prescreening tells the antivirus module
to begin scanning a file much earlier. In this case, the scan engine uses the first packet or the first several
packets to determine if a file could possibly contain malicious code. The scan engine does a quick check
on these first packets and if it finds that it is unlikely that the file is infected, it then decides that it is safe
to bypass the normal scanning procedure.
Intelligent prescreening is only intended for use with non-encoded traffic. It is not applicable for MIME
encoded traffic, mail protocols (SMTP, POP3, IMAP) and HTTP POST.
Example: Configuring Full Antivirus Intelligent Prescreening
IN THIS SECTION
Requirements | 307
Overview | 307
Configuration | 307
307
Verification | 308
The Intelligent prescreening is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, this example shows how to configure full antivirus
intelligent prescreening. By default, intelligent prescreening is enabled to improve antivirus scanning
performance.
Requirements
Before you begin, understand how intelligent prescreening enables the improvement of antivirus
scanning performance. See "Understanding Full Antivirus Intelligent Prescreening" on page 306.
Overview
In this example, you perform the following tasks:
• Enable intelligent prescreening for the kasprof1 profile.
• Disable intelligent prescreening for the kasprof1 profile.
Configuration
IN THIS SECTION
Procedure | 307
Procedure
To enable or disable full antivirus intelligent prescreening:
1. Enable intelligent prescreening for the kasprof1 profile.
[edit]
scan-options intelligent-prescreening
308
2. Disable intelligent prescreening for the kasprof1 profile.
[edit]
scan-options no-intelligent-prescreening
NOTE: Intelligent prescreening is intended only for use with non-encoded traffic. It is not
applicable to mail protocols (SMTP, POP3, IMAP) or HTTP POST.
[edit]
user@host# commit
Verification
IN THIS SECTION
Purpose
Action
309
Understanding Full Antivirus Content Size Limits
The Content Size Limit is not supported from Junos OS Release 15.1X49-D10 and Junos OS Release
17.3R1 onwards. For previous releases, due to resource constraints, there is a default, device-dependent
limit on maximum content size for the database. The content size value is configurable. There is also a
lower and upper limit for maximum content size. (This range is device dependent and is not
configurable.)
The content size check occurs before the scan request is sent. The exact timing of this is protocol
dependent. If the protocol header contains an accurate content length field, the content size check takes
place when the content length field is extracted during header parsing. The content size usually refers to
file size. If there is no content length field, the size is checked while the antivirus module is receiving
packets. The content size, in this case, refers to accumulated TCP payload size. This setting can be used
in all protocols.
Configuring Full Antivirus Content Size Limits (CLI Procedure)
The Content Size Limit is not supported from Junos OS Release 15.1X49-D10 and Junos OS Release
17.3R1 onwards. For previous releases, to configure content size limits, use the following CLI

scan-options {
content-size-limit KB;
}
}
Understanding Full Antivirus Decompression Layer Limits
The Decompression Layer Limit is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, the decompression layer limit specifies how many layers
of nested compressed files and files with internal extractable objects, such as archive files (tar), MS Word
and PowerPoint files, the internal antivirus scanner can decompress before it executes the virus scan.
For example, if a message contains a compressed .zip file that contains another compressed .zip file,
there are two compression layers. Decompressing both files requires a decompress layer setting of 2.
310
It is worth noting that during the transfer of data, some protocols use content encoding. The antivirus
scan engine must decode this layer, which is considered a decompression level, before it scans for
viruses.
There are three kinds of compressed data:
• compressed file (zip, rar, gzip)
• encoded data (MIME)
• packaged data (OLE, .CAP, .MSI, .TAR, .EML)
A decompression layer could be a layer of a zipped file or an embedded object in packaged data. The
antivirus engine scans each layer before unpacking the next layer, until it either reaches the user-
configured decompress limit, reaches the device decompress layer limit, finds a virus or other malware,
or decompresses the data completely, whichever comes first.
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. The Juniper Networks device's level of security is limited by
decompress limit, which is based on the memory allocated to the security service. If a virus is not found
within the decompress limit, the user has an option to either pass or drop the data. This setting can be
used in all protocols.
Configuring Full Antivirus Decompression Layer Limits (CLI Procedure)
The Decompression Layer Limit is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, to configure decompression layer limits, use the
following CLI configuration statements:

scan-options {
decompress-layer-limit number
}
}
311
Understanding Full Antivirus Scanning Timeouts
The Scanning timeout parameter is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, the scanning timeout value includes the time frame
from when the scan request is generated to when the scan result is returned by the scan engine. The
time range can be 1 to 1800 seconds. By default, it is 180 seconds.
NOTE: This timeout parameter is used by all supported protocols. Each protocol can have a
different timeout value.
Configuring Full Antivirus Scanning Timeouts (CLI Procedure)
The Scanning timeout parameter is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, to configure scanning timeouts, use the following CLI

scan-options {
timeout-value seconds {
}
}
}
Understanding Full Antivirus Scan Session Throttling
The Scan session Throttling is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, in an attempt to consume all available resources and
hinder the ability of the scan engine to scan other traffic, a malicious user might generate a large amount
of traffic all at once. To prevent such activity from succeeding, a session throttle is imposed for antivirus
resources, thereby restricting 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 may change this default limit, but understand that if this limit is set high, that is
comparable to no limit.
312
Over-limit is a fallback setting for the connection-per-client limit. The default behavior of over-limit is to
block sessions. This is a per-policy setting. You can specify different settings for different UTM policies.
Configuring Full Antivirus Scan Session Throttling (CLI Procedure)
The Scan session Throttling is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, to configure scan session throttling, use the following
CLI configuration statements:
security utm utm-policy name

traffic-options {
sessions-per-client {
limit number;
over-limit { log-and-permit | block}
}
}
Release Description
15.1X49-D10 The Kaspersky Lab scan engine is not supported from Junos OS Release 15.1X49-D10 and Junos
15.1X49-D10 The Kaspersky Lab scan is not supported from Junos OS Release 15.1X49-D10 and Junos OS
313
15.1X49-D10 The Intelligent prescreening is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The Intelligent prescreening is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The Content Size Limit is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The Content Size Limit is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The Decompression Layer Limit is not supported from Junos OS Release 15.1X49-D10 and Junos
15.1X49-D10 The Decompression Layer Limit is not supported from Junos OS Release 15.1X49-D10 and Junos
15.1X49-D10 The Scanning timeout parameter is not supported from Junos OS Release 15.1X49-D10 and Junos
15.1X49-D10 The Scanning timeout parameter is not supported from Junos OS Release 15.1X49-D10 and Junos
15.1X49-D10 The Scan session Throttling is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The Scan session Throttling is not supported from Junos OS Release 15.1X49-D10 and Junos OS

314
Full Antivirus Scan Results and Fallback Options
IN THIS SECTION
Monitoring Antivirus Scan Engine Status | 315
Monitoring Antivirus Scan Results | 317
Fallback options tell the system how to handle the errors returned by either the scan engine or the scan
manager. Different antivirus scan results are handled in different manners. For example, if a scan result is
clean, the traffic is forwarded to the receiver. If the scan result is infected, the traffic is dropped. If the
scan results in an error, the result handling depends on the cause of the failure and the configuration
(fallback settings). For more information, see the following topics:
Understanding Full Antivirus Scan Result Handling
The Full Antivirus Scan Result Handling is not supported from Junos OS Release 15.1X49-D10 and
Junos OS Release 17.3R1 onwards. For previous releases, different antivirus scan results are handled in
different manners. For example, if a scan result is clean, the traffic is forwarded to the receiver. If the
scan result is infected, the traffic is dropped. If the scan results in an error, the result handling depends
on the cause of the failure and the configuration (fallback settings).
The following is a list of actions based on scan results:
• Scan Result = Pass
The scan result handling action is to pass the message. In this case, no virus is detected and no error
code is returned. Or, an error code is returned, but the fallback option for this error code is set to log-
and-permit.
• Scan Result = Block

315
The scan result handling action is to block the message. In this case, either a virus is detected or an
error code is returned and the fallback option for this error code is BLOCK.
SEE ALSO
Monitoring Antivirus Scan Engine Status
IN THIS SECTION
Purpose | 315
Action | 316
Purpose
The Monitoring Antivirus Scan Engine Status is not supported from Junos OS Release 15.1X49-D10 and
Junos OS Release 17.3R1 onwards. For previous releases, using the CLI, you can view the following scan
engine status items:
Antivirus license key status
• View license expiration dates.
Scan engine status and settings
• View last action result.
• View default file extension list.
Antivirus pattern update server settings
• View update URL (HTTP or HTTPS-based).
• View update interval.
Antivirus pattern database status
• View auto update status.

316
• View last result of database loading.
• If the download completes, view database version timestamp virus record number.
• If the download fails, view failure reason.
Action
In the CLI, enter the user@host> show security utm anti-virus status command.
Example status result:
AV Key Expire Date: 03/01/2010 00:00:00

Update Server: http://update.juniper-updates.net/AV/device-name
interval: 60 minutes
auto update status: next update in 12 minutes
last result: new database loaded
AV signature version: 12/21/2008 00:35 GMT, virus records: 154018
Scan Engine Info: last action result: No error(0x00000000)
SEE ALSO
Monitoring Antivirus Session Status
IN THIS SECTION
Purpose | 317
Action | 317
317
Purpose
The Monitoring Antivirus Session Status is not supported from Junos OS Release 15.1X49-D10 and
Junos OS Release 17.3R1 onwards. For previous releases, using the CLI, you can view the following
session status items:
Antivirus session status displays a snapshot of current antivirus sessions. It includes
• Maximum supported antivirus session numbers.
• Total allocated antivirus session numbers.
• Total freed antivirus session numbers.
• Current active antivirus session numbers.
Action
In the CLI, enter the user@host> show security utm session status command.
Monitoring Antivirus Scan Results
IN THIS SECTION
Purpose | 317
Action | 318
Purpose
The Monitoring Antivirus Scan Results are not supported from Junos OS Release 15.1X49-D10 and
Junos OS Release 17.3R1 onwards. For previous releases, view statistics for antivirus requests, scan
results, and fallback counters.
Scan requests provide
• The total number of scan request forwarded to the engine.
• The number of scan request being pre-windowed.
• The number of scan requests using scan-all mode.

318
• The number of scan requests using scan-by-extension mode.
Scan code counters provide
• Number of clean files.
• Number of infected files.
• Number of password protected files.
• Number of decompress layers.
• Number of corrupt files.
• When the engine is out of resources.
• When there is an internal error.
Fallback applied status provides either a log-and-permit or block result when the following has occurred
• Scan engine not ready.
• Maximum content size reached.
• Too many requests.
• Password protected file found.
• Decompress layer too large.
• Corrupt file found.
• Timeout occurred.
• Out of resources.
• Other.
Action
To view antivirus scan results using the CLI editor, enter the user@host> show security utm anti-virus
statistics status command.
To view antivirus scan results using J-Web:
1. Select Monitor>Security>UTM>Anti-Virus.
The following information becomes viewable in the right pane.
Antivirus license key status

319
• View license expiration dates.
Antivirus pattern update server settings
• View update URL (HTTP or HTTPS-based).
• View update interval.
Antivirus pattern database status
• View auto update status.
• View last result of database loading.
• If the download completes, view database version timestamp virus record number.
• If the download fails, view failure reason.
Antivirus statistics provide
• The number of scan request being pre-windowed.
• The total number of scan request forwarded to the engine.
• The number of scan requests using scan-all mode.
• The number of scan requests using scan-by-extension mode.
Scan code counters provide
• Number of clean files.
• Number of infected files.
• Number of password protected files.
• Number of decompress layers.
• Number of corrupt files.
• When the engine is out of resources.
• When there is an internal error.
Fallback applied status provides either a log-and-permit or block result when the following has
occurred
• Scan engine not ready.
• Password protected file found.

320
• Decompress layer too large.
• Corrupt file found.
• Out of resources.
• Timeout occurred.
• Maximum content size reached.
• Too many requests.
• Other.
2. You can click the Clear Anti-Virus Statistics button to clear all current viewable statistics and begin
collecting new statistics.
Understanding Antivirus Scanning Fallback Options
Fallback options notify the system how to handle the errors returned by either the scan engine or the
scan manager. The following is a list of possible errors:
• Scan engine is not ready (engine-not-ready)
The scan engine is initializing itself, for example, loading the signature database. During this phase,
the scan engine is not ready to scan a file. A file could either pass or be blocked according to this
setting.
• Corrupt file (corrupt-file)
Corrupt file is the error returned by the scan engine when engine detects a corrupted file.
• Decompression layer (decompress-layer)
Decompress layer error is the error returned by the scan engine when the scanned file has too many
compression layers.
• Password protected file (password-file)
Password protected file is the error returned by the scan engine when the scanned file is protected
by a password.
• Max content size (content-size)
If the content size exceeds a set limit, the content is passed or blocked depending on the max-
content-size fallback option.
321
• Too many requests (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 allowed request limit is
not configurable.)
• Timeout
Scanning a complex file could consume resources and time. If the time taken for the scan exceeds the
timeout setting in the antivirus profile, the processing is terminated and the content is passed or
blocked without completing the virus checking. The decision is made based on the timeout fallback
option.
• Out of resources (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 terminated.
• 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 fallback action for all the error types is log-and-permit.
Example: Configuring Antivirus Scanning Fallback Options
IN THIS SECTION
Requirements | 322
Overview | 322
Configuration | 322
Verification | 325
322
The Antivirus Scanning Fallback options are not supported from Junos OS Release 15.1X49-D10 and
Junos OS Release 17.3R1 onwards. For previous releases, this example shows how to configure antivirus
scanning fallback options.
Requirements
Before you begin, understand the possible error types and the default fallback actions for those error
types. See "Understanding Antivirus Scanning Fallback Options" on page 320.
Overview
In this example, you configure a feature profile called kasprof, and set the fallback scanning options for
default, content-size, corrupt-file, decompress-layer, engine-not-ready, out-of-resources, password-file,
timeout, too-many-requests, as block.
NOTE: The command for changing the URL for the pattern database is:
[edit]
user@host# edit security utm feature-profile anti-virus kaspersky-lab-engine
user@host# set pattern-update url http://update.juniper-updates.net/AV/<device-name>
The default URL is http://update.juniper-updates.net/AV/<device-version>. You should not

change this URL unless you are experiencing problems with it and have called for support.
Configuration
IN THIS SECTION
Procedure | 323
323
Procedure

options corrupt-file block
options decompress-layer block
options password-file block
To configure scanning fallback options:
[edit]
user@host# set security utm feature-profile anti-virus type kaspersky-lab-engine
324
2. Create a profile for the Kaspersky Lab engine and configure a list of fallback options as block or log-
and-permit.

user@host# set profile kasprof1 fallback-options content-size block
user@host# set profile kasprof1 fallback-options corrupt-file block
user@host# set profile kasprof1 fallback-options decompress-layer block
user@host# set profile kasprof1 fallback-options default block
user@host# set profile kasprof1 fallback-options engine-not-ready block
user@host# set profile kasprof1 fallback-options out-of-resources block
user@host# set profile kasprof1 fallback-options password-file block
user@host# set profile kasprof1 fallback-options timeout block
user@host# set profile kasprof1 fallback-options too-many-requests block
Results
[edit]
user@host#show security utm feature-profile anti-virus
profile kasprof1 {
fallback-options {
default block;
corrupt-file block;
password-file block;
decompress-layer block;
content-size block;
timeout block;
}
}
}
325
Verification
IN THIS SECTION
Verifying the Antivirus Scanning Fallback Options | 325
Verifying the Antivirus Scanning Fallback Options
Purpose
Verify the antivirus scanning fallback options.
Action
SEE ALSO

Release Description
15.1X49-D10 The Full Antivirus Scan Result Handling is not supported from Junos OS Release 15.1X49-D10 and
15.1X49-D10 The Monitoring Antivirus Scan Engine Status is not supported from Junos OS Release 15.1X49-
15.1X49-D10 The Monitoring Antivirus Session Status is not supported from Junos OS Release 15.1X49-D10
15.1X49-D10 The Monitoring Antivirus Scan Results are not supported from Junos OS Release 15.1X49-D10 and
326
15.1X49-D10 The Antivirus Scanning Fallback options are not supported from Junos OS Release 15.1X49-D10
Full Antivirus Application Protocol Scanning
IN THIS SECTION
Enabling HTTP Scanning (CLI Procedure) | 329
Enabling FTP Antivirus Scanning (CLI Procedure) | 330
Understanding SMTP Antivirus Scanning | 330
Enabling SMTP Antivirus Scanning (CLI Procedure) | 333
Understanding POP3 Antivirus Scanning | 333
Enabling POP3 Antivirus Scanning (CLI Procedure) | 335
Understanding IMAP Antivirus Scanning | 335
Enabling IMAP Antivirus Scanning (CLI Procedure) | 338
Full Antivirus uses a scanning engine and virus signature databases to protect against virus-infected
files, worms, trojans, spyware, and other malware over POP3, HTTP, SMTP, IMAP, and FTP protocols.
For more information, see the following topics:
327
Understanding Full Antivirus Application Protocol Scanning
The Full Antivirus Application Protocol Scanning is not supported from Junos OS Release 15.1X49-D10
and Junos OS Release 17.3R1 onwards. For previous releases, you can turn antivirus scanning on and off
on a per protocol basis. If scanning for a protocol is disabled in an antivirus profile, there is no
application intelligence for this protocol. Therefore, in most cases, traffic using this 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. For each content type that
you are scanning, you have different configuration options.
Profile-based settings, including enable/disable, scan-mode, and scan result handling settings, may not
be applicable to all supported protocols. The following table lists profile-based settings and their
protocol support.
Table 6: Supported Profile-based Settings By Protocol
Profile Setting Protocol Support
Enable or disable scanning on per protocol basis All protocols support this feature
"Understanding Full Antivirus Scan Mode Support" on page 298, including file All protocols support this feature
extension scanning
"Understanding Full Antivirus Content Size Limits" on page 309 All protocols support this feature
"Understanding Full Antivirus Decompression Layer Limits" on page 309 All protocols support this feature
"Understanding Full Antivirus Scanning Timeouts" on page 311 All protocols support this feature
"Understanding HTTP Trickling" on page 87 HTTP only
"Understanding Antivirus Scanning Fallback Options" on page 320 All protocols support this feature
Protocol specific messages All protocols support this feature

328
Table 6: Supported Profile-based Settings By Protocol (Continued)
Profile Setting Protocol Support
"Understanding E-Mail Virus-Detected Notifications" on page 83 SMTP, POP3, and IMAP only
"Understanding Custom Message Virus-Detected Notifications" on page 85 All protocols support this feature
SEE ALSO
Understanding HTTP Scanning
The HTTP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, if antivirus scanning is enabled for Hypertext Transfer
Protocol (HTTP) traffic in a content security profile, TCP traffic to defined HTTP service ports (generally
port 80) is monitored. For HTTP traffic, the security device scans both HTTP responses and requests
(get, post, and put commands).
For HTTP antivirus scanning, both HTTP 1.0 and 1.1 are supported. If the protocol version is HTTP 0.x ,
the antivirus scanner attempts to scan the traffic. Unknown protocols are bypassed. For example, some
application protocols use HTTP as the transport but do not comply with HTTP 1.0 or 1.1. These are
considered unknown protocols and are not scanned.
This is a general description of how HTTP traffic is intercepted, scanned, and acted upon by the antivirus
scanner:
1. An HTTP client sends an HTTP request to a webserver or a webserver responds to an HTTP request.
2. The security device intercepts the request and passes the data to the antivirus scanner, which scans
it for viruses.
3. After completing the scan, the device follows one of two courses:
• If there is no virus, the device forwards the request to the webserver.
• If there is a virus, the device drops the request and sends an HTTP message reporting the
infection to the client.
329
With script-only scanning, the input object is a script file. It can be JavaScript, VBScript, mIRC script, bat
scripts (DOS bat files) and other text scripts. The engine matches the input content only with signatures
for script files. Script scanning is applicable only for HTML content over the HTTP protocol. There are
two criteria for this scan-type. First, the content-type field of this HTML document must be text or
HTML. Second, there is no content encoding in the HTTP header. If those two criteria are met, an HTML
parser is used to parse the HTML document.
SEE ALSO
Enabling HTTP Scanning (CLI Procedure)
The HTTP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, to enable antivirus scanning for HTTP traffic, enter the
following CLI configuration statement:
user@host# set security utm utm-policy policy-name anti-virus http
Understanding FTP Antivirus Scanning
The FTP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 onwards. For
previous releases, if antivirus scanning is enabled for File Transfer Protocol (FTP) traffic in a content
security profile, the security device monitors the control channel and, when it detects one of the FTP
commands for transferring data, it scans the data sent over the data channel.
This is a general description of how FTP traffic is intercepted, scanned, and acted upon by the antivirus
scanner:
1. A local FTP client opens an FTP control channel to an FTP server and requests the transfer of some
data.
2. The FTP client and server negotiate a data channel over which the server sends the requested data.
The security device intercepts the data and passes it to the antivirus scan engine, which scans it for
viruses.
330
• If there is no virus, the device forwards the data to the client.
• If there is a virus, the device replaces the data with a drop message in the data channel and sends
a message reporting the infection in the control channel.
Enabling FTP Antivirus Scanning (CLI Procedure)
The FTP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 onwards. For
previous releases, to enable antivirus scanning for File Transfer Protocol (FTP) traffic, enter the following
CLI configuration statement:
user@host# security utm utm-policy policy-name anti-virus ftp
NOTE: In order to scan FTP traffic, the FTP ALG must be enabled.
SEE ALSO
FTP ALG Overview
Understanding SMTP Antivirus Scanning
IN THIS SECTION
Understanding SMTP Antivirus Mail Message Replacement | 331
Understanding SMTP Antivirus Sender Notification | 331
Understanding SMTP Antivirus Subject Tagging | 332
Starting from Junos OS Release 15.1X49-D10 and Junos OS Release 17.3R1, only Sophos Antivirus
supports the SMTP antivirus scanning. If SMTP (Simple Mail Transfer Protocol) antivirus scanning is
enabled in a content security profile, the security device redirects traffic from local SMTP clients to the
antivirus scanner before sending it to the local mail server.
331
Chunking is an alternative to the data command. It provides a mechanism to transmit a large message in
small chunks. It is not supported. Messages using chunking are bypassed and are not scanned.
This is a general description of how SMTP traffic is intercepted, scanned, and acted upon by the
antivirus scanner:
1. An SMTP client sends an e-mail message to a local mail server or a remote mail server forwards an e-
mail message via SMTP to the local mail server.
2. The security device intercepts the e-mail message and passes the data to the antivirus scanner, which
scans it for viruses.
• If there is no virus, the device forwards the message to the local server.
• If there is a virus, the device sends a replacement message to the client.
Understanding SMTP Antivirus Mail Message Replacement
If the antivirus scanner finds a virus in an e-mail message, the original message is dropped, the message
body is truncated, and the content is replaced by a message that may appear as follows:
nContent-Type: text/plain
Your mail <src_ip> : <src_port> — <dst_port>: <dst_port> contains contaminated file <filename>
with virus <virusname>, so it is dropped.
If a scan error is returned and the fail mode is set to drop, the original message is dropped and the entire
message body is truncated. The content is replaced by a message that may appear as follows:
Your mail <src_ip> : <src_port> — <dst_port>: <dst_port> is dropped for <reason>.
Understanding SMTP Antivirus Sender Notification
If notify-sender-on-virus is set and the message is dropped due to a detected virus, an e-mail is sent to the
mail sender. The content of the notification may appear as follows:
From: <admin>@<gateway_ip>
To: <sender_e-mail>
332
Subject: Mail Delivery Failure

This message is created automatically by mail delivery software. A message that you sent could
not be delivered to one or more of its recipients for the reason:
<src_ip> : <src_port> — <dst_port>: <dst_port> <ENVID> contaminated file <filename> with virus
<virusname>.
e-mail Header is:
<header of scanned e-mail>
If notify-sender-on-error-drop is set and the message is dropped due to a scan error, an e-mail is sent to the
mail sender of the scanned message. The content of the e-mail may appear as follows:
To: <sender_e-mail>
<src_ip> : <src_port> — <dst_port>: <dst_port> <ENVID> <reason>.
e-mail Header is:
NOTE: For information on the ENVID parameter, refer to RFC 3461.
Understanding SMTP Antivirus Subject Tagging
If a scan error is returned and the fail mode is set to pass, the antivirus module passes the message
through to the server. If notify-recipient-on-error-pass is set, the following string is appended to the end of
the subject field:
(No virus check: <reason>)
SEE ALSO

333
Enabling SMTP Antivirus Scanning (CLI Procedure)
The SMTP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, to enable antivirus scanning for SMTP traffic, enter the
user@host# set security utm utm-policy policy-name anti-virus smtp-profile
Understanding POP3 Antivirus Scanning
IN THIS SECTION
Understanding POP3 Antivirus Mail Message Replacement | 334
Understanding POP3 Antivirus Sender Notification | 334
Understanding POP3 Antivirus Subject Tagging | 335
The POP3 antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, if Post Office Protocol 3 (POP3) antivirus scanning is
enabled in a content security profile, the security device redirects traffic from a local mail server to
antivirus scanner before sending it to the local POP3 client.
This is a general description of how POP3 traffic is intercepted, scanned, and acted upon by the
antivirus scanner.
1. The POP3 client downloads an e-mail message from the local mail server.
3. After completing the scan, the security device follows one of two courses:
• If there is no virus, the device forwards the message to the client.
• If there is a virus, the device sends a message reporting the infection to the client.
See "Understanding Protocol-Only Virus-Detected Notifications" on page 83 for information on

protocol-only notifications for IMAP.
334
Understanding POP3 Antivirus Mail Message Replacement
Understanding POP3 Antivirus Sender Notification
mail sender.
To: <sender_e-mail>
<src_ip> : <src_port> — <dst_port>: <dst_port> contaminated file <filename> with virus
<virusname>.
e-mail Header is:
To: <sender_e-mail>
<src_ip> : <src_port> — <dst_port>: <dst_port> <reason>.
e-mail Header is:
335
Understanding POP3 Antivirus Subject Tagging
subject field:
SEE ALSO
Enabling POP3 Antivirus Scanning (CLI Procedure)
The POP3 antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, to enable antivirus scanning for POP3 traffic, enter the
user@host# set security utm utm-policy policy-name anti-virus pop3-profile
Understanding IMAP Antivirus Scanning
IN THIS SECTION
Understanding IMAP Antivirus Mail Message Replacement | 336
Understanding IMAP Antivirus Sender Notification | 336
Understanding IMAP Antivirus Subject Tagging | 337
Understanding IMAP Antivirus Scanning Limitations | 337

336
The IMAP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, if IMAP (Internet Message Access Protocol) antivirus
scanning is enabled in a content security profile, the security device redirects traffic from a local mail
server to the internal antivirus scanner before sending it to the local IMAP client.
This is a general description of how IMAP traffic is intercepted, scanned, and acted upon by the antivirus
scanner.
1. The IMAP client downloads an e-mail message from the local mail server.
3. After completing the scan, the security device follows one of two courses:
• If there is no virus, the device forwards the message to the client.
• If there is a virus, the device sends a message reporting the infection to the client.
See "Understanding Protocol-Only Virus-Detected Notifications" on page 83 for information on

protocol-only notifications for IMAP.
Understanding IMAP Antivirus Mail Message Replacement
Understanding IMAP Antivirus Sender Notification
mail sender.
To: <sender_e-mail>
337
<src_ip> : <src_port> — <dst_port>: <dst_port> contaminated file <filename> with virus

<virusname>.
e-mail Header is:
To: <sender_e-mail>
<src_ip> : <src_port> — <dst_port>: <dst_port> <reason>.
e-mail Header is:
Understanding IMAP Antivirus Subject Tagging
subject field:
Understanding IMAP Antivirus Scanning Limitations
Mail Fragments — It is possible to chop one e-mail into multiple parts and to send each part through a
different response. This is called mail fragmenting and most popular mail clients support it in order to
send and receive large e-mails. Scanning of mail fragments is not supported by the antivirus scanner and
in such cases, the message body is not scanned.
Partial Content — Some mail clients treat e-mail of different sizes differently. For example, small e-mails
(less than 10 KB) are downloaded as a whole. Large e-mails (for example, less than 1 MB) are chopped
into 10 KB pieces upon request from the IMAP server. Scanning of any partial content requests is not
supported by the antivirus scanner.
IMAP Uploads — Only antivirus scanning of IMAP downloads is supported. IMAP upload traffic is not
scanned.
338
Enabling IMAP Antivirus Scanning (CLI Procedure)
The IMAP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, to enable antivirus scanning for IMAP traffic, enter the
user@host# security utm utm-policy policy-name anti-virus imap-profile
Release Description
15.1X49-D10 The Full Antivirus Application Protocol Scanning is not supported from Junos OS Release 15.1X49-
15.1X49-D10 The HTTP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The HTTP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The FTP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 onwards.
15.1X49-D10 The FTP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 onwards.
15.1X49-D10 Starting from Junos OS Release 15.1X49-D10 and Junos OS Release 17.3R1, only Sophos
Antivirus supports the SMTP antivirus scanning.
15.1X49-D10 The SMTP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The POP3 antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The POP3 antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The IMAP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
339
15.1X49-D10 The IMAP antivirus scanning is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Integrated Web Filtering
IN THIS SECTION
Example: Configuring Integrated Web Filtering | 343
Enhanced Web Filtering (EWF) with Websense is an integrated URL filtering solution. When you enable
the solution on the device, the firewall intercepts the HTTP and the HTTPS requests and sends the
HTTP URL or the HTTPS source IP to the Websense ThreatSeeker Cloud (TSC). For more information,
see the following topics:
Understanding Integrated Web Filtering
IN THIS SECTION
Integrated Web Filtering Process | 341
Integrated Web Filtering Cache | 341

340
Integrated Web Filtering Profiles | 341
Profile Matching Precedence | 342
The Integrated Web Filtering is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, with integrated Web filtering, the firewall intercepts
every HTTP request in a TCP connection and extracts the URL from the HTTP request. Each individual
HTTP request is blocked or permitted based on URL filtering profiles defined by you. The decision
making is done on the device after it identifies a category for a URL.
The Surf-Control feature is not supported from Junos OS Release 15.1X49-D10 and Junos OS Release
17.3R1 onwards.
A URL category is a list of URLs grouped by content. URL categories are predefined and maintained by
Surf-Control or are defined by you. Surf-Control maintains about 40 predefined categories. When
defining your own URL categories, you can group URLs and create categories specific to your needs.
You define your own categories using URL pattern list and custom URL category list custom objects.
Once defined, you can select your categories when you configure your Web filtering profile. Each
category can have a maximum of 20 URLs. When you create a category, you can add either the URL or
the IP address of a site. When you add a URL to a user-defined category, the device performs DNS
lookup, resolves the host name into IP addresses, and caches this information. When a user tries to
access a site with the IP address of the site, the device checks the cached list of IP addresses and tries to
resolve the hostname. Many sites have dynamic IP addresses, meaning that their IP addresses change
periodically. A user attempting to access a site can type an IP address that is not in the cached list on the
device. Therefore, if you know the IP addresses of sites you are adding to a category, enter both the URL
and the IP address(es) of the site.
If a URL appears in both a user-defined category and a predefined category, the device matches the URL
to the user-defined category.
Web filtering is performed on all the methods defined in HTTP 1.0 and HTTP 1.1.
The integrated Web filtering solution intercepts every HTTP request in a TCP connection. In this case,
the decision making is done on the device after it identifies the category for a URL either from user-
defined categories or from a category server (SurfControl Content Portal Authority provided by
Websense). The Integrated Web filtering is not supported from Junos OS Release 15.1X49-D10
onwards.
The integrated Web filtering feature is a separately licensed subscription service. When the license key
for Web filtering has expired, no URLs are sent to the category server for checking, only local user-
defined categories are checked.
341
Integrated Web filtering solution is supported only on SRX210, SRX220, SRX240, SRX550, and SRX650
devices.
This topic contains the following sections:
Integrated Web Filtering Process
This is a general description of how Web traffic is intercepted and acted upon by the Web filtering
module.
1. The device intercepts a TCP connection.
2. The device intercepts each HTTP request in the TCP connection.
3. The device extracts each URL in the HTTP request and checks its URL filter cache.
4. Global Web filtering allowlists and blocklists are checked first for block or permit.
5. If the HTTP request URL is allowed based on cached parameters, it is forwarded to the webserver. If
there is no cache match, a request for categorization is sent to the SurfControl server. (If the HTTP
request URL is blocked, the request is not forwarded and a notification message is logged.)
6. In the allowed case, the SurfControl server responds with the corresponding category.
7. Based on the identified category, if the URL is permitted, the device forwards the HTTP request to
the webserver. If the URL is not permitted, then a deny page is sent to the HTTP client.
Integrated Web Filtering Cache
By default, the device retrieves and caches the URL categories from the SurfControl CPA server. This
process reduces the overhead of accessing the SurfControl CPA server each time the device receives a
new request for previously requested URLs. You can configure the size and duration of the cache,
according to the performance and memory requirements of your networking environment. The lifetime
of cached items is configurable between 1 and 1800 seconds with a default value of 300 seconds.
Caches are not preserved across device reboots or power losses.
Integrated Web Filtering Profiles
You configure Web filtering profiles that permit or block URLs according to defined categories. A Web
filtering profile consists of a group of URL categories assigned one of the following actions:
• Permit — The device always allows access to the websites in this category.
• Block — The device blocks access to the websites in this category. When the device blocks access to
this category of websites, it displays a message in your browser indicating the URL category.
342
• Blocklist — The device always blocks access to the websites in this list. You can create a user-defined
category.
• Allowlist — The device always allows access to the websites in this list. You can create a user-defined
category.
NOTE: A predefined profile is provided and can be used if you choose not to define your own
profile.
A Web filtering profile may contain one blocklist or one allowlist, multiple user-defined and/or
predefined categories each with a permit or block action, and an Other category with a permit or block
action. You can define an action for all Other categories in a profile to specify what to do when the
incoming URL does not belong to any of the categories defined in the profile. If the action for the Other
category is block, the incoming URL is blocked if it does not match any of the categories explicitly
defined in the profile. If an action for the Other category is not specified, the default action of permit is
applied to the incoming URL not matching any category.
Profile Matching Precedence
When a profile employs several categories for URL matching, those categories are checked for matches
in the following order:
1. If present, the global blocklist is checked first. If a match is made, the URL is blocked. If no match is
found...
2. The global allowlist is checked next. If a match is made, the URL is permitted. If no match is found...
3. User-defined categories are checked next. If a match is made, the URL is blocked or permitted as
specified. If no match is found...
4. Predefined categories are checked next. If a match is made, the URL is blocked or permitted as
specified. If no match is found...
5. The Other category is checked next. If a match is made, the URL is blocked or permitted as specified.
SEE ALSO

343
Example: Configuring Integrated Web Filtering
IN THIS SECTION
Requirements | 343
Overview | 343
Configuration | 344
Verification | 353
The Integrated Web Filtering is not supported from Junos OS Release 15.1X49-D10 and Junos OS
Release 17.3R1 onwards. For previous releases, this example shows how to configure integrated Web
filtering.
Requirements
Overview
In this example you configure integrated Web filtering custom objects, integrated Web filtering feature
profiles, and integrated Web filtering UTM policies. You also attach integrated Web filtering UTM
policies to security policies.
In the first example configuration you create a custom object called urllist3 that contains the pattern
http://www.example.net 1.2.3.4. The urllist3 custom object is then added to the custom URL category
custurl3.
In the second example configuration, you configure the Web filtering feature profile. You set the URL
blocklist filtering category to custblacklist, set the allowlist filtering category to custwhitelist and the type
of Web filtering engine to surf-control-integrated. Then you set the cache size parameters for Web
filtering to 500 KB, which is the default, and the cache timeout parameters to 1800.
You name the Surf Control server as surfcontrolserver and enter 8080 as the port number for
communicating with it. (Default ports are 80, 8080, and 8081.) Then you create a surf-control-
integrated profile name called surfprofile1.
Next you select a category from the included allowlist and blocklist categories or select a custom URL
category list you created for filtering against. Then you enter an action (permit, log and permit, block) to
go with the filter. You do this as many times as necessary to compile your allowlists and blocklists and
their accompanying actions. This example blocks URLs in the custurl3 category.
344
Then you enter a custom message to be sent when HTTP requests are blocked. This example configures
the device to send an ***access denied*** message. You select a default action (permit, log and permit,
block) for this profile for requests that experience errors. This example sets the default action to block.
You select fallback settings (block or log and permit) for this profile, in case errors occur in each
configured category. This example sets fallback settings to block.
Finally, you enter a timeout value in seconds. Once this limit is reached, fail mode settings are applied.
The default is 10 seconds, and you can enter a value from 10 to 240 seconds. This example sets the
timeout value to 10.
In the third example configuration, you create UTM policy utmp5 and attach it to profile surfprofile1.
In the final example configuration, you attach the UTM policy utmp5 to the security policy p5.
Configuration
IN THIS SECTION
Configuring Integrated Web Filtering Custom Objects | 344
Configuring the Integrated Web Filtering Feature Profiles | 347
Configuring Integrated Web Filtering UTM Policies | 350
Attaching Integrated Web Filtering UTM Policies to Security Policies | 352
Configuring Integrated Web Filtering Custom Objects
configuration mode.
set security utm custom-objects url-pattern urllist3 value http://www.example.net

345

set security utm custom-objects custom-url-category custwhiltelist value urllistwhite
Custom category does not take precedence over predefined categories when it has the same name as
one of the predefined categories. We do not recommend having a custom category name be the same as
the predefined category name.
To configure integrated Web filtering:
1. Create custom objects and create the URL pattern list.
[edit security utm]

2. Configure the custom URL category list custom object using the URL pattern list.
[edit security utm]

3. Create a list of untrusted sites.
[edit security utm]

13.13.13.13]
4. Configure the custom URL category list custom object using the URL pattern list of untrusted sites.
[edit security utm]

5. Create a list of trusted sites.
[edit security utm]

user@host# set custom-objects url-pattern urllistwhite value [http://www.trusted.com 7.7.7.7]
346
6. Configure the custom URL category list custom object using the URL pattern list of trusted sites.
[edit security utm]

Results
[edit]
url-pattern {
urllist3 {
value [ http://www.example.net ];
}
urllistblack {
}
urllistwhite {
}
}
custurl3 {
value urllist3;
}
custblacklist {
value urllistblack;
}
custwhiltelist {
value urllistwhite;
}
}
347
Configuring the Integrated Web Filtering Feature Profiles
configuration mode.
set security utm feature-profile web-filtering url-whitelist custwhitelist

set security utm feature-profile web-filtering url-blacklist custblacklist
set security utm feature-profile web-filtering surf-control-integrated cache timeout 1800
set security utm feature-profile web-filtering surf-control-integrated cache size 500
set security utm feature-profile web-filtering surf-control-integrated server host
surfcontrolserver
set security utm feature-profile web-filtering surf-control-integrated server port 8080
set security utm feature-profile web-filtering surf-control-integrated profile surfprofile1
category custurl3 action block
default block
custom-block-message "***access denied ***"
fallback-settings default block
fallback-settings too-many-requests block
timeout 10
set security utm feature-profile content-filtering profile contentfilter1
To configure integrated Web filtering feature profiles:

348
1. Configure the Web filtering URL Blocklist.

2. Configure the Web filtering URL Allowlist.

3. Specify the surf-control-integrated Web filtering engine and set the cache size parameters.

user@host# set surf-control-integrated cache size 500
4. Set the cache timeout parameters.

user@host# set surf-control-integrated cache timeout 1800
5. Set the server name or IP address.

user@host# set surf-control-integrated server host surfcontrolserver
6. Enter the port number for communicating with the server.

user@host# set surf-control-integrated server port 8080
7. Create a profile name and select a category from the included allowlist and blocklist categories.

user@host# set surf-control-integrated profile surfprofile1 category custurl3 action block
349

user@host# set surf-control-integrated profile surfprofile1 custom-block-message “***access
denied***”
9. Select a default action (permit, log and permit, block) for this profile for requests that experience
errors.

user@host# set surf-control-integrated profile surfprofile1 default block
10. Select fallback settings (block or log and permit) for this profile.

user@host# set surf-control-integrated profile surfprofile1 fallback-settings default block
user@host# set surf-control-integrated profile surfprofile1 fallback-settings server-

connectivity block
user@host# set surf-control-integrated profile surfprofile1 fallback-settings timeout block
user@host# set surf-control-integrated profile surfprofile1 fallback-settings too-many-
requests block
11. Enter a timeout value, in seconds.

user@host# set surf-control-integrated profile surfprofile1 timeout 10
Results
[edit]
userhost#show security utm feature-profile
350
web-filtering {
type juniper-local;
surf-control-integrated {
cache {
timeout 1800;
size 500;
}
server {
host surfcontrolserver;
port 8080;
}
profile surfprofile1 {
category {
custurl3 {
action block;
}
}
default block;
fallback-settings {
default block;
timeout block;
}
timeout 10;
}
}
content-filtering {
}
Configuring Integrated Web Filtering UTM Policies
351
configuration mode.
set security utm utm-policy utmp5 web-filtering http-profile surfprofile1
To configure a UTM policy:
1. Create the UTM policy referencing a profile.
[edit]
user@host# set security utm utm-policy utmp5 web-filtering http-profile surfprofile1
Results
From configuration mode, confirm your configuration by entering the show security utm utm-policy
[edit]
userhost#show security utm utm-policy
...
utm-policy utmp5 {
content-filtering {
http-profile contentfilter1;
}
web-filtering {
http-profile surfprofile1;
}
}
352
Attaching Integrated Web Filtering UTM Policies to Security Policies
configuration mode.
utm-policy utmp5


353
Results
[edit]
userhost#show security policies
policy p5 {
match {
source-address any;
}
then {
permit {
utm-policy utmp5;
}
}
}
}
}
Verification
IN THIS SECTION
Verifying the Configuration of Integrated Web Filtering Custom Objects | 354
Verifying the Configuration of Integrated Web Filtering Feature Profiles | 354
Verifying the Configuration of Integrated Web Filtering UTM Policies | 354
Verifying the Attachment of Integrated Web Filtering UTM Policies to Security Policies | 354

354
Verifying the Configuration of Integrated Web Filtering Custom Objects
Purpose
Verify the configuration of integrated Web filtering custom objects.
Action
From the top of the configuration in configuration mode, enter the show security utm custom-objects
command.
Verifying the Configuration of Integrated Web Filtering Feature Profiles
Purpose
Verify the configuration of integrated Web filtering feature profiles.
Action
From the top of the configuration in configuration mode, enter the show security utm feature-profile
command.
Verifying the Configuration of Integrated Web Filtering UTM Policies
Purpose
Verify the configuration of integrated Web filtering UTM policies.
Action
From the top of the configuration in configuration mode, enter the show security utm command.
Verifying the Attachment of Integrated Web Filtering UTM Policies to Security Policies
Purpose
Verify the attachment of integrated Web filtering UTM policies to security policies.
Action
From the top of the configuration in configuration mode, enter the show security policies command.
355
SEE ALSO
Displaying Global SurfControl URL Categories
IN THIS SECTION
Purpose | 355
Action | 355
Purpose
The Surf-Control feature is not supported from Junos OS Release 15.1X49-D10 and Junos OS Release
17.3R1 onwards. For previous releases, view global URL categories defined and maintained by
SurfControl.
Action
Enter the user@host# show groups junos-defaults CLI command. You can also look for custom-url-category.

Release Description
15.1X49-D10 The Integrated Web Filtering is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The Surf-Control feature is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The Integrated Web filtering is not supported from Junos OS Release 15.1X49-D10 onwards.
15.1X49-D10 The Integrated Web Filtering is not supported from Junos OS Release 15.1X49-D10 and Junos OS
15.1X49-D10 The Surf-Control feature is not supported from Junos OS Release 15.1X49-D10 and Junos OS
356

7 CHAPTER
Configuration Statements
action (Security UTM Web Filtering) | 364
address-blacklist | 365
address-whitelist | 367
admin-email | 368
administrator-email (Security Fallback Block) | 369
administrator-email (Security Virus Detection) | 371
allow-email (Security Fallback Block) | 372
allow-email (Security Virus Detection) | 374
application (Security Policies) | 375
application-proxy (Security UTM) | 377
anti-spam | 379
anti-virus | 383
anti-virus (Security UTM Policy) | 387
avira-engine | 389
block-command | 391
block-content-type | 392
block-extension | 394
block-message (Security UTM) | 395
block-mime | 397
cache | 398
category (Security Logging) | 400
content-filtering (Security Feature Profile) | 413
content-size | 419
content-size (Security Antivirus Sophos Engine) | 421
content-size-limit | 423
corrupt-file | 424
custom-block-message | 426
custom-message (Security Content Filtering) | 427
custom-message (Security Email Notify) | 429
custom-message (Security Fallback Block) | 430
custom-message (Security Fallback Non-Block) | 432
custom-message (Security Virus Detection) | 433
custom-message (Security Web Filtering) | 435
custom-message-subject (Security Email Notify) | 437
custom-message-subject (Security Fallback Block) | 438
custom-message-subject (Security Fallback Non-Block) | 440
custom-message-subject (Security Virus Detection) | 441
custom-objects | 443
custom-page | 445
custom-tag-string | 449
custom-url-category | 450
decompress-layer | 452
decompress-layer-limit | 454
default (Security Antivirus) | 457
default (Security Antivirus Sophos Engine) | 458
default (Security UTM) | 460
default (Security Web Filtering) | 461
display-host (Security Fallback Block) | 463
display-host (Security Virus Detection) | 465
download-profile (Security Antivirus FTP) | 466

download-profile (Security Content Filtering FTP) | 468
email-notify | 469
engine-not-ready | 471
engine-not-ready (Security Antivirus Sophos Engine) | 472
exception | 474
exception (Security Content Filtering) | 475
fallback-block (Security Antivirus) | 477
fallback-non-block (Security Antivirus) | 479
fallback-options (Security Antivirus Juniper Express Engine) | 480
fallback-options (Security Antivirus Kaspersky Lab Engine) | 482
fallback-options (Security Antivirus Sophos Engine) | 484
fallback-settings (Security Web Filtering) | 486
fallback-settings (Security Web Filtering Juniper Local) | 487
fallback-settings (Security Web Filtering Websense Redirect) | 489
filename-extension | 502
flag (SMTP) | 504
format (Security Log Stream) | 506
forwarding-mode (Security UTM Policy) | 508
from-zone (Security Policies) | 510
ftp (UTM Policy Anti-Virus) | 514
ftp (UTM Policy Content Filtering) | 516
hold-interval | 518
host (Security Web Filtering) | 519
http-profile (Security Antivirus) | 521
http-profile (Security Content Filtering) | 522
http-profile (Security Web Filtering) | 523
imap-profile (Security UTM Policy Antivirus) | 525
imap-profile (Security UTM Policy Content Filtering) | 526
http-persist | 527
http-reassemble | 529
intelligent-prescreening | 530
interval (Security Antivirus) | 532
ipc | 534
juniper-enhanced | 535
juniper-express-engine | 538
juniper-local | 541
limit (UTM Policy) | 546
list | 547
list (Security Content Filtering Block Mime) | 549
log (Security) | 550
mime-pattern | 555
mime-whitelist | 557
no-autoupdate | 559
no-intelligent-prescreening | 560
no-notify-mail-recipient | 562
no-notify-mail-sender (Security Content Filtering Notification Options) | 564
no-notify-mail-sender (Security Fallback Block) | 565
no-notify-mail-sender (Security Virus Detection) | 567
no-sbl-default-server | 568
notification-options (Security Antivirus) | 570
notification-options (Security Content Filtering) | 572
notify-mail-recipient | 573
notify-mail-sender (Security Content Filtering Notification Options) | 575
notify-mail-sender (Security Fallback Block) | 576
notify-mail-sender (Security Virus Detection) | 578
no-uri-check | 579
out-of-resources | 581
out-of-resources (Security Antivirus Sophos Engine) | 582
over-limit | 584
packet-filter | 586
password (Security Antivirus) | 588
password-file | 590
pattern-update (Security Antivirus) | 591
permit-command | 593
policies | 594
pop3-profile (Security UTM Policy Antivirus) | 605

pop3-profile (Security UTM Policy Content Filtering) | 606
port (Security Antivirus) | 607
port (Security Web Filtering Server) | 609
primary-server | 610
profile (Security Antispam SBL) | 612
profile (Security Antivirus Kaspersky Lab Engine) | 616
profile (Security Content Filtering) | 619
profile (Security Sophos Engine Antivirus) | 621
profile | 623
profile (Security Web Filtering Juniper Enhanced) | 626
profile (Security Web Filtering Juniper Local) | 628
profile (Security Web Filtering Surf Control Integrated) | 630
profile (Security Web Filtering Websense Redirect) | 632
protocol-command | 634
proxy (Security Antivirus) | 635
proxy-profile | 637
quarantine-message (Security UTM) | 638
routing-instance (Security UTM) | 640
sbl | 642
sbl-default-server | 644
scan-extension | 645
scan-mode | 646
scan-options (Security Antivirus Juniper Express Engine) | 648
scan-options (Security Antivirus Kaspersky Lab Engine) | 650
scan-options (Security Antivirus Sophos Engine) | 652
secondary-server | 655
server (Security Antivirus) | 657
server (Security Sophos Engine Antivirus) | 658
server (Security Web Filtering) | 660
server-connectivity | 662
session-scan | 664
site-reputation-action | 665
size (Security Web Filtering Cache) | 667
smtp-profile (Security UTM Policy Antivirus) | 670
smtp-profile (Security UTM Policy Content Filtering) | 671
sockets | 673
sophos-engine | 674
source-address | 677
spam-action | 678
start-time | 680
surf-control-integrated | 681
sxl-retry | 684
sxl-timeout | 685
timeout (Security Antivirus Fallback Options) | 687
timeout (Security Antivirus Fallback Options Sophos Engine) | 689
timeout (Security Antivirus Scan Options) | 690
timeout (Security Web Filtering) | 692
timeout (Security Web Filtering Cache) | 693
timeout (Security Web Filtering Fallback Settings) | 695
too-many-requests (Security Antivirus Fallback Options) | 697
too-many-requests (Security Antivirus Fallback Options Sophos Engine) | 699
too-many-requests (Security Web Filtering Fallback Settings) | 701
to-zone (Security Policies) | 703
traceoptions (Security Antispam) | 706
traceoptions (Security Antivirus) | 708
traceoptions (Security Application Proxy) | 710
traceoptions (Security Content Filtering) | 713
traceoptions (Security UTM) | 714
traceoptions (Security Web Filtering) | 716
traceoptions (SMTP) | 718
traffic-options | 720
trickling | 721
type (Security Antivirus Feature Profile) | 723
type (Security Content Filtering Notification Options) | 725
type (Security Fallback Block) | 727

type (Security Virus Detection) | 729
type (Security Web Filtering) | 731
upload-profile (Security Antivirus FTP) | 733
upload-profile (Security Content Filtering FTP) | 734
uri-check | 735
url-blacklist | 738
url-pattern | 740
url-whitelist | 743
url-whitelist | 745
username (Security Antivirus) | 746
utm | 748
utm-policy | 768
utm-policy (Application Services) | 771
virus-detection (Security Antivirus) | 772
web-filtering | 774
web-filtering (Security UTM Policy) | 780
websense-redirect | 782
364
action (Security UTM Web Filtering)
IN THIS SECTION
Syntax | 364
Hierarchy Level | 364
Description | 364
Options | 365
Required Privilege Level | 365
Release Information | 365
Syntax
action (block | log-and-permit | permit | quarantine);
Hierarchy Level
[edit security utm default-configuration]

[edit security utm feature-profile web-filtering surf-control-integrated profile profile-name
category customurl-last-name]
[edit security utm feature-profile web-filtering juniper-enhanced profile profile-name category
customurl-last-name]
Description
Enter an action to go with the customurl-list filter.

365
Options
• block—Log the error and deny the traffic.
• log-and-permit—Log the error and permit the traffic.
• permit—Permit the traffic.
• quarantine—Show the warning message and permit/block the traffic based on user input.
Required Privilege Level
security—To view this statement in the configuration.
security-control—To add this statement to the configuration.
Release Information
The Surf-Control feature is not supported from Junos OS Release 15.1X49-D10 onwards. For previous
releases, statement introduced in Junos OS Release 9.5.
Statement introduced in Junos OS Release 11.4 .
The [edit security utm default-configuration] hierarchy level is introduced in Junos OS Release 18.2R1.
address-blacklist
IN THIS SECTION
Syntax | 366
Description | 366

366
Syntax
address-blacklist list-name;
Hierarchy Level
[edit security utm feature-profile anti-spam]

Description
Enter an address blocklist (or allowlist) custom object for local list spam filtering.
Release Information
Statement introduced in Junos OS Release 9.5.
367
address-whitelist
IN THIS SECTION
Syntax | 367
Description | 367
Syntax
address-whitelist list-name;
Hierarchy Level

Description
Enter an address-allowlist (or blocklist) custom-object for local list spam filtering.

368
Release Information
admin-email
IN THIS SECTION
Syntax | 368
Description | 369
Syntax
admin-email email-address;
Hierarchy Level
[edit security utm feature-profile anti-virus juniper-express-engine pattern-update email-notify]

[edit security utm feature-profile anti-virus kaspersky-lab-engine pattern-update email-notify]
[edit security utm feature-profile anti-virus sophos-engine pattern-update email-notify]
[edit security utm default-configuration anti-virus avira-engine pattern-update email-notify]
369
Description
You can configure the device to notify a specified administrator when patterns are updated. This is an e-
mail notification with a custom message and a custom subject line.
Release Information
The Express and Kaspersky antivirus feature is not supported from Junos OS Release 15.1X49-D10
onwards. For previous releases, statement introduced in Junos OS Release 9.5.
Support for Avira engine added in Junos OS Release 18.4R1.
administrator-email (Security Fallback Block)
IN THIS SECTION
Syntax | 370
Description | 370

370
Syntax
administrator-email email-address;
Hierarchy Level

[edit security utm feature-profile anti-virus juniper-express-engine profile profile-name
notification-options fallback-block]
[edit security utm feature-profile anti-virus kaspersky-lab-engine profile profile-name
[edit security utm feature-profile anti-virus sophos-engine profile profile-name notification-
options fallback-block]
Description
Configure the administrator e-mail address that will be notified when a fallback-block occurs. This is an
e-mail notification with a custom message and a custom subject line.
Release Information
onwards. For previous releases, statement introduced in Junos OS Release 9.5. Support for Sophos
engine added in Junos OS Release 11.1.
371
administrator-email (Security Virus Detection)
IN THIS SECTION
Syntax | 371
Description | 371
Syntax
administrator-email email address;
Hierarchy Level

[edit security utm feature-profile anti-virus sophos-engine profile profile name notification-
options virus-detection]
Description
Configure the administrator e-mail address that will be notified when a virus is detected by Sophos
antivirus. This is an e-mail notification with a custom message and a custom subject line.
372
Release Information
allow-email (Security Fallback Block)
IN THIS SECTION
Syntax | 372
Description | 373
Syntax
allow-email;
373
Hierarchy Level

Description
Enable e-mail notification to notify a specified administrator when a fallback-block occurs.
Release Information
374
allow-email (Security Virus Detection)
IN THIS SECTION
Syntax | 374
Description | 374
Syntax
allow–email;
Hierarchy Level

[edit security utm feature-profile anti-virus profile notification-options virus-detect]
Description
Enable e-mail notification to notify a specified administrator when a virus is detected.

375
Release Information
application (Security Policies)
IN THIS SECTION
Syntax | 375
Description | 376
Options | 376
Syntax
application {
[application];
any;
}
376
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name match]
[edit security policies global policy policy-name match]
Description
Specify the IP or remote procedure call (RPC) application or set of applications to be used as match
criteria.
Starting in Junos OS Release 19.1R1, configuring the application statement at the [edit security policies
from-zone zone-name to-zone zone-name policy policy-name match] hierarchy level is optional if the dynamic-
application statement is configured at the same hierarchy level.
Options
application- Name of the predefined or custom application or application set used as match
name-or-set criteria.
any Any predefined or custom applications or application sets.
NOTE: A custom application that does not use a predefined destination port
for the application will not be included in the any option, and must be named
explicitly.

377
Release Information
Security Policies Overview

Configure Applications in Unified Policies
application-proxy (Security UTM)
IN THIS SECTION
Syntax | 377
Description | 378
Options | 378
Syntax
application-proxy {
traceoptions {
flag flag;
}
}
378
Hierarchy Level

[edit security utm]
Description
Configure trace options for the application proxy.
Options
The remaining statements are explained separately. See CLI Explorer.
Release Information
379
anti-spam
IN THIS SECTION
Syntax | 379
Description | 380
Options | 380
Syntax
anti-spam {
sbl {
profile profile-name {
custom-tag-string [string];
(sbl-default-server | no-sbl-default-server);
spam-action (block | tag-header | tag-subject);
}
}
traceoptions flag flag;
}
Hierarchy Level
[edit security utm feature-profile]

380
Description
Configure UTM antispam features. You can also configure the default UTM configuration for antispam
feature profile. If you do not configure any option in the antispam feature profile, the values configured
in the default UTM configuration are applied.
The antispam feature examines transmitted e-mail messages to identify e-mail 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. Antispam filtering uses both a third-party server-based Spam
Block List (SBL) and optionally created local allowlists (benign) and blocklists (malicious) for filtering
against e-mail messages.
NOTE: A license check for the antispam configuration is performed at the time of a commit and
will provide a warning if a valid license is not installed on the device. Once a valid license is
installed on the device then a custom antispam profile or the default profile will be able to
process traffic. If a license is expired or is not installed, the antivirus service will not process
traffic.
In the default UTM profile, the antispam type is configured as SBL instead of none. This
configuration enables SBL. However, to use this feature, you must enable the SBL server using
the [edit security utm default-configuration anti-spam sbl sbl-default-server] command.
Options
anti-spam Configure antispam feature.
address-blacklist Enter an address blocklist custom object for local list spam filtering.
address-whitelist Enter an address-allowlist custom-object for local list spam filtering.
sbl Antispam filtering allows you to use both a third-party server-based spam block list
(SBL) and to optionally create your own local allowlists and blocklists for filtering
against e-mail messages.
traceoptions Defines tracing operations for UTM antispam features.
type Antispam type.

381
Release Information
anti-spam (Security UTM Policy)
IN THIS SECTION
Syntax | 381
Description | 382
Options | 382
Syntax
anti-spam {
smtp-profile profile-name;
}
382
Hierarchy Level

[edit security utm utm-policy policy-name]
[edit logical-systems logical-system-name security utm utm-policy policy-name]
[edit tenants tenant-name security utm utm-policy policy-name]
Description
Configures a UTM policy for the antispam SMTP protocol and attach this policy to a security profile to
implement it. The device can block and drop detected spam at either the connection level or the e-mail
level. When the SMTP sender is identified as a spam sender based on its IP address, the SMTP
connection is rejected and dropped. When a particular e-mail sender is identified as spam sender based
on its sender address, the e-mail is rejected and dropped.
Options
The statements are explained separately. See CLI Explorer.
Release Information
Support for configuration in logical systems introduced in Junos OS Release 18.3R1.
Support for configuration in tenant systems introduced in Junos OS Release 19.2R1.

383
anti-virus
IN THIS SECTION
Syntax | 383
Description | 385
Options | 385
Syntax
anti-virus {
mime-whitelist {
exception;
list;
}
sophos-engine {
fallback-options {
content-size (block | log-and-permit | permit);
default (block | log-and-permit | permit);
engine-not-ready (block | log-and-permit | permit);
out-of-resources (block | log-and-permit | permit);
timeout (block | log-and-permit | permit);
too-many-requests (block | log-and-permit | permit);
}
fallback-block {
custom-message;
384
custom-message-subject;
(notify-mail-sender | no-notify-mail-sender);
type (message | protocol-only);
}
custom-message;
(notify-mail-recipient | no-notify-mail-recipient);
}
virus-detection {
custom-message;
}
}
pattern-update {
email-notify {
admin-email;
custom-message;
}
interval;
no-autoupdate;
proxy {
password;
port;
server;
username;
}
routing-instance;
url;
}
scan-options {
content-size-limit;
timeout seconds;
(uri-check | no-uri-check);
}
server {
ip;
routing-instance;
}
sxl-retry;
385
sxl-timeout seconds;
trickling timeout;
}
traceoptions {
flag name;
}
url-whitelist;
}
Hierarchy Level

Description
Configure UTM Sophos antivirus features. You can also configure the default UTM configuration for
antivirus feature profile. If you do not configure any option in the antivirus feature profile, the values
configured in the default UTM configuration are applied. Antivirus, one of several features including
content filtering, antispam, and Web filtering, makes up Juniper’s UTM suite, provides the ability to
prevent threats at the gateway before they enter the network.
NOTE: A license check for the antivirus configuration is performed at the time of a commit and
will provide a warning if a valid license is not installed on the device. Once a valid license is
installed on the device then a custom antivirus profile or the default profile will be able to
process traffic. If a license is expired or is not installed, the antivirus service will not process
traffic.
Options
anti-virus Configure antivirus feature.

386
mime-whitelist This is the comprehensive list for those MIME types that can bypass antivirus
scanning.
sophos-engine The antivirus engine that is used on the device. You can only have one engine type
running and you must restart the device if you change engines.
fallback-options Fallback options tell the system how to handle the errors.
notification-options There are multiple notification options you can configure to trigger when a virus is
detected.
fallback-non-block Notifications for fallback nonblocking actions.
virus-detection Notification to send when a virus is detected.
pattern-update You can configure the security device to regularly update the pattern file
automatically, or you can update the file manually.
scan-options Antivirus sophos-engine scan options.
server Sophos Antivirus (SAV) and antispam first hop DNS server.
sxl-retry Number of retry attempts to the remote Sophos Extensible List (SXL) server when a
request timeout occurs.
• Range: 0 through 5
sxl-timeout Timeout value for responses to a Sophos checksum or URI query.
trickling HTTP trickling is a mechanism used to prevent the HTTP client or server from
timing-out during a file transfer or during antivirus scanning.
traceoptions Define tracing operations for UTM antivirus features.
url-whitelist Antivirus URL allowlist. A URL allowlist is a unique custom list that you define in
which all the URLs or IP addresses in that list for a specified category are always
bypassed for scanning.

387
Release Information
anti-virus (Security UTM Policy)
IN THIS SECTION
Syntax | 387
Description | 388
Options | 388
Syntax
anti-virus {
ftp {
download-profile profile-name;
upload-profile profile-name;
}
388
http-profile profile-name;
imap-profile profile-name;
pop3-profile profile-name;
}
Hierarchy Level

[edit logical-systems logical-systems-name security utm utm-policy policy-name]
Description
Configures a UTM policy for the antivirus protocols and attaches this policy to a security profile to
implement it. 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.
Options

389
Release Information
UTM Overview | 2
avira-engine
IN THIS SECTION
Syntax | 389
Description | 390
Syntax
avira-engine {
pattern-update {
email-notify {
admin-email admin-email;
custom-message custom-message;
custom-message-subject custom-message-subject;
}
390
interval interval;
no-autoupdate;
proxy-profile proxy-profile;
routing-instance routing-instance;
start-time start-time;
url url;
}
}
Hierarchy Level
Description
The Avira scan engine is a licensed feature provided as a downloadable module. Download and install
the Avira scan engine either through SRX with Internet connectivity to Juniper hosted URL, user hosted
URL, or manually.
The Antivirus engine provides a full file-based virus scanning function which is available through a
licensed subscription service. When your antivirus license key expires, you can continue to use the
locally stored antivirus signatures without any updates. In case, the local database is deleted, antivirus
scanning is also disabled.
security— To view this statement in the configuration.
security-control— To add this statement to the configuration.
Release Information
391
Statement introduced in Junos OS Release 18.4R1.
block-command
IN THIS SECTION
Syntax | 391
Description | 391
Syntax
block-command protocol-command-list;
Hierarchy Level

[edit security utm feature-profile content-filtering profile profile-name]
Description
Apply protocol block command custom-objects to the content-filtering profile.

392
Release Information
block-content-type
IN THIS SECTION
Syntax | 392
Description | 393
Options | 393
Syntax
block-content-type (activex | exe | http-cookie | java-applet | zip);

393
Hierarchy Level

Description
Apply blocks to other available content such as exe, http-cookie, java-applet. This is for HTTP only.
Options
• activex—Block ActiveX.
• exe—Block EXE files.
• http-cookie—Block cookies.
• java-applet—Block Java applets.
• zip—Block ZIP files.
Release Information
394
block-extension
IN THIS SECTION
Syntax | 394
Description | 394
Syntax
block-extension extension-list;
Hierarchy Level

Description
Apply block extensions to the content-filtering profile.

395
Release Information
block-message (Security UTM)
IN THIS SECTION
Syntax | 395
Description | 396
Options | 396
Syntax
block-message {
type {
custom-redirect-url;
}
url url;
}
396
Hierarchy Level

[edit security utm feature-profile web-filtering juniper-enhanced profile profile-name]
Description
Configure Juniper enhanced block message settings.
Options
• type—Specify the following type of the block message:
• custom-redirect-url—Specify Custom redirect URL server.
• url url—Specify an URL of the block message.
Release Information
397
block-mime
IN THIS SECTION
Syntax | 397
Description | 397
Options | 398
Syntax
block-mime {
exception list-name;
list list-name;
}
Hierarchy Level

Description
Apply MIME pattern list custom-objects to the content-filtering profile for blocking MIME types.
398
Options
Release Information
cache
IN THIS SECTION
Syntax | 399
Description | 399
Options | 399

399
Syntax
cache {
size value;
timeout value;
}
Hierarchy Level

[edit security utm feature-profile web-filtering surf-control-integrated]
[edit security utm feature-profile web-filtering juniper-enhanced]
Description
Set the cache parameters for Surf-Control-Integrated Web filtering and Enhanced Web Filtering.
Options

400
Release Information
releases, statement introduced in Junos OS Release 9.5 for surf-control integrated.
Release Description
15.1X49-D10 The Surf-Control feature is not supported from Junos OS Release 15.1X49-D10 onwards.
category (Security Logging)
IN THIS SECTION
Syntax | 400
Description | 401
Options | 401
Syntax
category (all | content-security | fw-auth | screen | alg | nat | flow | sctp | gtp | ipsec |
idp | rtlog | pst-ds-lite | appqos | secintel | aamw | dnsf)
401
Hierarchy Level
[edit security log stream stream-name]

[edit logical-systems name security log stream stream-name]
[edit tenants tenant-name security log stream stream-name]
Description
Set the category of logging to all or content-security. Note that for the WELF format, the category must
be set to content-security.
Options
• all—All events are logged. By default, all the events listed in the category parameter are logged.
• content-security—Only content security events are logged.
• fw-auth—Firewall authentication events are logged.
• screen—Screen events are logged.
• alg—Application Layer Gateway (ALG) events are logged.
• nat—Network Address Translation (NAT) events are logged.
• flow—Flow events are logged.
• sctp—Stream Control Transmission Protocol (SCTP) events are logged.
• gtp—GPRS Tunneling Protocol (GTP) events are logged.
• ipsec—IPsec events are logged.
• idp—Intrusion Detection and Prevention (IDP) events are logged.
• rtlog—RTLOG system log events are logged.
• pst-ds-lite—PST dual-stack lite (DS-Lite) events are logged.
• appqos—Application quality of service (AppQoS) events are logged.

402
• secintel—Juniper Networks Security Intelligence (SecIntel) events are logged.
• aamw—Advanced-anti-malware (AAMW) events are logged.
• dnsf—DNS events are logged.
Release Information
Statement introduced in Junos OS Release 10.0. Statement modified in Junos OS Release 15.1X49-D40.
The [edit logical-systems name security log stream stream-name] hierarchy level introduced in Junos OS
Release 18.2R1.
The [edit tenants tenant-name security log stream stream-name] hierarchy levels introduced in Junos OS
Release 18.3R1.
The dnsf category is introduced in Junos OS Release 20.4R1.
Application Security User Guide for Security Devices

Logical Systems and Tenant Systems User Guide for Security Devices
category (Security Web Filtering)
IN THIS SECTION
Syntax | 403
403
Description | 403
Options | 412
Syntax
category name{
custom-message message-name;
}
Hierarchy Level

[edit security utm feature-profile web-filtering surf-control-integrated profile profile-name]
Description
Select a custom URL category list you created (custom objects) for filtering against. The custom-message
configuration option is used to notify the users when the URL is blocked or quarantined for each EWF
category. You can customize the message with options such as user message or redirect URL. User
messages indicate that website access has been blocked by an organization's access policy. Redirect
URLs redirect a blocked or quarantined URL to any user-defined URL. Table 7 on page 404 shows the
list of categories predefined by Websense.
404
categories.
NOTE: Existing configurations are not affected by the new categories but can be modified to
make use of the new categories.
Table 7: List of Categories Predefined by Websense
Category ID Category Name Parent ID
1 Adult Material 0
2 Business and Economy 0
3 Education 0
4 Government 0
5 News and Media 0
6 Religion 0
7 Society and Lifestyles 0
8 Special Events 0
9 Information Technology 0
10 Abortion 0
11 Advocacy Groups 0
12 Entertainment 0
405
Table 7: List of Categories Predefined by Websense (Continued)
13 Gambling 0
14 Games 0
15 Illegal or Questionable 0
16 Job Search 0
17 Shopping 0
18 Sports 0
19 Tasteless 0
20 Travel 0
21 Vehicles 0
22 Violence 0
23 Weapons 0
24 Drugs 0
25 Militancy and Extremist 0
26 Intolerance 0
27 Health 0
406
28 Website Translation 9
29 Advertisements 110
64 User-Defined 0
65 Nudity 1
66 Adult Content 1
67 Sex 1
68 Financial Data and Services 2
69 Cultural Institutions 3
70 Media File Download 12
72 Military 4
73 Political Organizations 4
74 General Email 91
75 Proxy Avoidance 9
76 Search Engines and Portals 9
78 Web Hosting 9
407
79 Web Chat 91
80 Hacking 9
81 Alternative Journals 5
82 Non-Traditional Religions 6
83 Traditional Religions 6
84 Restaurants and Dining 7
85 Gay or Lesbian or Bisexual Interest 7
86 Personals and Dating 7
87 Alcohol and Tobacco 7
88 Prescribed Medications 24
89 Nutrition 24
90 Abused Drugs 24
91 Internet Communication 0
92 Pro-Choice 10
93 Pro-Life 10
408
94 Sex Education 1
95 Lingerie and Swimsuit 1
96 Online Brokerage and Trading 110
97 Educational Institutions 3
98 Instant Messaging 110
99 Application and Software Download 110
100 Pay-to-Surf 110
101 Internet Auctions 17
102 Real Estate 17
103 Hobbies 7
107 Sport Hunting and Gun Clubs 18
108 Internet Telephony 116
109 Streaming Media 116
110 Productivity 0
111 Marijuana 24
409
112 Message Boards and Forums 110
113 Personal Network Storage and Backup 116
114 Internet Radio and TV 116
115 Peer-to-Peer File Sharing 116
116 Bandwidth 0
117 Social Networking and Personal Sites 7
118 Educational Materials 3
121 Reference Materials 3
122 Social Organizations 0
123 Service and Philanthropic Organizations 122
124 Social and Affiliation Organizations 122
125 Professional and Worker Organizations 122
126 Security 0
128 Malicious Web Sites 126
138 Computer Security 9

410
146 Miscellaneous 0
147 Web Infrastructure 146
148 Web Images 146
149 Private IP Addresses 146
150 Content Delivery Networks 146
151 Dynamic Content 146
152 Network Errors 146
153 Uncategorized 146
154 Spyware 126
156 File Download Servers 146
164 Phishing and Other Frauds 126
166 Keyloggers 126
167 Potentially Unwanted Software 126
172 Bot Networks 126
191 Extended Protection 0

411
192 Elevated Exposure 191
193 Emerging Exploits 191
194 Suspicious Content 191
195 Organizational Email 91
196 Text and Media Messaging 91
200 Web and Email Spam 9
220 Compromised Websites 0
221 Newly Registered Websites 0
222 Collaboration Office 0
223 Office Mail 222
224 Office Drive 222
225 Office Documents 222
226 Office Apps 222
227 Web Analytics 9
228 Web and Email Marketing 9

412
1529 Classifieds Posting 0
1530 Blog Posting 0
1531 Blog Commenting 0
Options
Release Information
Starting with Junos OS Release 15.1X49-D10, the SurfControl integrated feature is no longer supported.
For previous releases, statement introduced in Junos OS Release 9.5. The custom-message option
introduced in Junos OS Release 15.1X49-D110.

413
content-filtering (Security Feature Profile)
IN THIS SECTION
Syntax | 413
Description | 414
Options | 414
Syntax
content-filtering {
block-command;
activex;
exe;
http-cookie;
java-applet;
zip;
}
block-extension;
block-mime {
exception;
list;
}
custom-message;
log; /* New event logging global setting */
} permit-command;
rule-set rule-set-name { /* New provision to add to default rules */
rule rule-name {
414
}
}
traceoptions {
flag name;
}
type (content-filtering-none | local);
}
Hierarchy Level

Description
Configure UTM content-filtering features. You can also configure the default UTM configuration for
content filtering feature profile. If you do not configure any option in the content filtering feature profile,
the values configured in the default UTM configuration are applied. The content filtering feature
controls file transfers across the gateway by checking traffic against configured filter lists. It evaluates
the traffic before all other UTM features, except Web filtering.
NOTE: A license check for the content filtering configuration is performed at the time of a
commit and will provide a warning if a valid license is not installed on the device. Once a valid
license is installed on the device then a custom content filtering profile or the default profile will
be able to process traffic. If a license is expired or is not installed, the content filtering service will
not process traffic.
Options
block-command Protocol block command custom-objects to the content-filtering profile.

415
block-content-type Blocks to other available content such as exe, http-cookie, java-applet. This is for
HTTP only.
block-extension Block extensions to the content-filtering profile.
block-mime MIME pattern list custom-objects to the content-filtering profile for blocking MIME
types.
notification-options A message notification to trigger when a content filter is matched.
permit-command Protocol permit command custom-objects to the content-filtering profile.
traceoptions Defines tracing operations for default UTM configuration for content filtering
feature.
type Type of content filtering solution or URL filtering solution used by the device.
Release Information
Starting in Junos OS Release 21.4R1, content filtering is performed by detecting the file content and not
the file extensions. So, content filtering options based on mime-type, content-type, and protocol
command is not supported. After you upgrade to Junos OS Release 21.4R1, content filtering option
under the feature-profile hierarchy are no more available for configuration. The rule-set and rules
configurations are introduced under the [edit security utm utm-policy <utm-policy-name> content-filtering]
hierarchy level. These rules and rule-set allows you to configure direction specific content filters and
connection reset.
416
content-filtering (Security UTM Policy)
IN THIS SECTION
Syntax | 416
Description | 417
Options | 417
Syntax
content-filtering {
ftp {
}
rule-set rule-set-name { rule rule-name {
match {
application any; /*http, pop3, impa, smtp, ftp */
direction any; /* upload or download */
file-type exe; /*predetected file types*/
}
then {
action {
no-action; /* No action */
/* block Block and drop connection */
/* close-client Close client */
/* close-server Close server */
/* close-client-and-server Close client and server */
417
}
notification {
log; /* event logging */
endpoint { /* endpoint notification options */
type protocol-only;
notify-mail-sender;
custom-message "CF Blocks content";
}
Hierarchy Level

Description
Configures a UTM policy for the content filtering protocols and attach this policy to a security profile to
implement it. Each supported protocol may implement available content filters differently. Not all
filtering capabilities are supported for each protocol. The HTTP protocol supports all content filtering
features. The FTP protocol supports only lock Extension List and Protocol Command Block List. The e-
mail protocols (SMTP, IMAP, POP3) supports limited to Block Extension List, Protocol Command Block
List, and MIME Pattern Filtering.
Options

418
Release Information
the file extensions. We have introduced the rule-set and rules configurations under the [edit security utm
utm-policy <utm-policy-name> content-filtering] hierarchy level. These rules and rule-set allows you to
configure direction specific content filters and connection reset.
So, content filtering options based on mime-type, content-type, and protocol command is not
supported. After you upgrade to Junos OS Release 21.4R1, previously existing file extension based
content filtering options under the [edit security utm utm-policy <utm-policy-name> content-filtering]
hierarchy are no more available for configuration.
Junos OS Release 21.4R1 allows you to use legacy functionality if you don’t want to migrate to this
modern functionality. You will be allowed to use the legacy configurations but all the legacy
configuration knobs are deprecated and are hidden. Also, you will receive system logs and error message
warnings when you use all the legacy deprecated knobs.

419
content-size
IN THIS SECTION
Syntax | 419
Description | 419
Options | 420
Syntax
content-size (block | log-and-permit);
Hierarchy Level

fallback-options]
[edit security utm feature-profile anti-virus kaspersky-lab-engine profile profile-name fallback-
options]
Description
If the content size exceeds a set limit, the content is either passed or blocked. The default action is log-
and-permit.
420
NOTE: When you configure the content-size value, keep in mind that in certain cases, content
size is available in the protocol headers, so the max-content-size fallback is applied before a scan
request is sent. However, in many cases, content size is not provided in the protocol headers. In
these cases, the TCP payload is sent to the antivirus scanner and accumulates until the end of
the payload. If the accumulated payload exceeds the maximum content size value, then max-
content-size fallback is applied. The default fallback action is log and permit, so you may want to
change this option to block, in which case such a packet is dropped and a block message is sent
to the client.
Options
• block—Log the error and deny the traffic
• log-and-permit—Log the error and permit the traffic
Release Information
onwards. For previous releases, Statement introduced in Junos OS Release 9.5.
421
content-size (Security Antivirus Sophos Engine)
IN THIS SECTION
Syntax | 421
Description | 421
Options | 422
Syntax
Hierarchy Level

[edit security utm feature-profile anti-virus sophos-engine profile profile-name fallback-
options]
Description
If the content size exceeds a set limit, the content is either passed or blocked.
NOTE: When you configure the content-size value, keep in mind that in certain cases, content
size is available in the protocol headers, so the max-content-size fallback is applied before a scan
422
request is sent. However, in many cases, content size is not provided in the protocol headers. In
these cases, the TCP payload is sent to the antivirus scanner and accumulates until the end of
the payload. If the accumulated payload exceeds the maximum content size value, then max-
content-size fallback is applied. You might want to set the fallback action to block, in which case
such a packet is dropped and a block message is sent to the client.
Options
• permit—Permit the traffic
Release Information

423
content-size-limit
IN THIS SECTION
Syntax | 423
Description | 423
Syntax
content-size-limit value;
Hierarchy Level
[edit security utm feature-profile anti-virus juniper-express-engine profile profile-name scan-

options]
[edit security utm feature-profile anti-virus kaspersky-lab-engine profile profile-name scan-
options]
[edit security utm default-configuration anti-virus scan-options]
Description
The content size check occurs before the scan request is sent. The content size refers to accumulated
TCP payload size. The maximum configurable content size varies with different platforms. For example,
the content size ranges from 20 through 40,000 for SRX4100.
424
Release Information
corrupt-file
IN THIS SECTION
Syntax | 424
Description | 425
Options | 425
Syntax
corrupt-file (block | log-and-permit);

425
Hierarchy Level

options]
Description
Corrupt file is the error returned by the scan engine when engine detects a corrupted file. The default
action is log-and-permit.
Options
Release Information
The Kaspersky antivirus feature is not supported from Junos OS Release 15.1X49-D10 onwards. For
previous releases, statement introduced in Junos OS Release 9.5.
426
custom-block-message
IN THIS SECTION
Syntax | 426
Description | 426
Syntax
custom-block-message value;
Hierarchy Level

Description
Enter a custom message to be sent when HTTP requests are blocked.

427
Release Information
custom-message (Security Content Filtering)
IN THIS SECTION
Syntax | 427
Description | 428
Syntax
custom-message message;
428
Hierarchy Level

[edit security utm feature-profile content-filtering profile profile-name notification-options]
Description
Custom message notifications are generally used when content is blocked by the content filter.
Release Information

429
custom-message (Security Email Notify)
IN THIS SECTION
Syntax | 429
Description | 429
Syntax
Hierarchy Level

[edit security utm default-configuration anti-virus avira-engine pattern-update email-notify]
Description
mail notification with a custom message.
430
Release Information
custom-message (Security Fallback Block)
IN THIS SECTION
Syntax | 430
Description | 431
Syntax
431
Hierarchy Level

Description
Custom message notifications are mainly used in file replacement or in a response message when the
antivirus scan result is to drop the file.
Release Information
432
custom-message (Security Fallback Non-Block)
IN THIS SECTION
Syntax | 432
Description | 432
Syntax
Hierarchy Level

notification-options fallback-non-block]
options fallback-non-block]
Description
433
Release Information
custom-message (Security Virus Detection)
IN THIS SECTION
Syntax | 433
Description | 434
Syntax
434
Hierarchy Level

notification-options virus-detection]
Description
Release Information
435
custom-message (Security Web Filtering)
IN THIS SECTION
Syntax | 435
Description | 436
Options | 436
Syntax
custom-message custom-message;
Hierarchy Level
[edit security utm feature-profile web-filtering juniper-local profile profile-name]

[edit security utm feature-profile web-filtering websense-redirect profile profile-name]
[edit logical-systems name security utm feature-profile web-filtering juniper-local profile
profile-name]
[edit logical-systems name security utm feature-profile web-filtering juniper-enhanced profile
profile-name]
[edit logical-systems name security utm feature-profile web-filtering websense-redirect profile
profile-name]
[edit tenants name security utm feature-profile web-filtering juniper-enhanced profile profile-
name]
[edit tenants name security utm feature-profile web-filtering juniper-local profile profile-name]
[edit tenants name security utm feature-profile web-filtering websense-redirect profile profile-
name]
436
[edit security utm default-configuration web-filtering juniper-enhanced]

[edit security utm default-configuration web-filtering juniper-local]
[edit security utm default-configuration web-filtering websense-redirect]
Description
You can reference the custom-page type custom-message object at the Web filtering profile level. If the
category action is block or quarantine and no custom-message is configured in the category, the custom-
message under the profile will take effect.
Options
custom-message Specify the custom message object.
security
Release Information
custom-page | 445
437
custom-message-subject (Security Email Notify)
IN THIS SECTION
Syntax | 437
Description | 437
Syntax
custom-message-subject message-subject;
Hierarchy Level

[[edit security utm default-configuration avira-engine pattern-update email-notify]
Description
438
Release Information
custom-message-subject (Security Fallback Block)
IN THIS SECTION
Syntax | 438
Description | 439
Syntax
439
Hierarchy Level

Description
antivirus scan result is to drop the file. As part of a custom message, you can customize the message
subject line.
Release Information
440
custom-message-subject (Security Fallback Non-

Block)
IN THIS SECTION
Syntax | 440
Description | 441
Syntax
Hierarchy Level

441
Description
subject line.
Release Information
custom-message-subject (Security Virus Detection)
IN THIS SECTION
Syntax | 442
Description | 442

442
Syntax
Hierarchy Level

Description
subject line.
Release Information
443
custom-objects
IN THIS SECTION
Syntax | 443
Description | 444
Options | 444
Syntax
custom-objects {
custom-url-category object-name {
value [value];
}
custom-message {
name message-name;
type redirect-url | user-message;
content redirect-url by user| user-message by user;
}
filename-extension object-name {
value [value];
}
mime-pattern object-name {
value [value];
}
protocol-command object-name {
value [value];
}
444
url-pattern object-name {
value [value];
}
}
Hierarchy Level
[edit security utm]

[edit logical-systems logical-system-name security utm]
[edit tenants tenant-name security utm]
Description
Configure custom objects before configuring UTM feature-profile features.
WARNING: Custom category does not take precedence over predefined categories
when it has the same name as one of the predefined categories. We do not recommend
having a custom category name be the same as the predefined category name.
NOTE: Starting from Junos OS Release 17.4R1, support for custom category configuration is
available for EWF, local, and Websense redirect profiles.
Options

445
Release Information
The [edit security utm default-configuration] hierarchy level introduced in Junos OS Release 18.2R1.
UTM Overview | 2
custom-page
IN THIS SECTION
Syntax | 446
Description | 446
Options | 446

446
Syntax
custom-page {
custom-page-file custom-page-file;
}
Hierarchy Level
[edit security utm custom-objects custom-message name type]
Description
You can create your own custom response pages for a URL that is configured with block or quarantine
actions in the UTM Web filtering profile. The custom response pages can include predefined page
variables, your corporate branding, acceptable use policies, and links to your internal resources.
Options
• custom-page-file—Name of custom page file.
Release Information

447
custom-page-file
IN THIS SECTION
Syntax | 447
Description | 448
Options | 448
Syntax
custom-page-file custom-page-file;
Hierarchy Level
[edit security utm custom-objects custom-message]

[edit logical-systems name security utm custom-objects custom-message],
[edit tenants name security utm custom-objects custom-message]
448
Description
You can create your own custom response pages based on a predefined template HTML file for a URL
that is configured with block or quarantine actions in the UTM Web filtering profile. By default, Your
security device provides a predefined HTML template file, which is saved at the local folder /var/db/utm/
custom_page/wf_block_page_tmpl.html. You can update the following parameters in the HTML file based on
your requirements:
• Change the title and text content.
• Remove one or all lines of variables.
• Add links to your internal resources to communicate your specific acceptable use policies and
corporate branding.
The maximum size of the page file is limited to 2K bytes. We recommend you not add JavaScript in the
contents of the HTML template page, because the JavaScript will have full access to the cookies of the
blocked website.
If you accidentally change or delete the HTML file does not affect the response page until you reboot
the system or execute the request security utm web-filtering custom-page reload command.
If you configure a non-existent HTML file, the system displays a warning message when you commit the
configuration. The configuration will be successfully submitted, but this configuration will not be
available. The system displays the warning message every time you commit the configuration.
You cannot upload an HTML file for a user logical system. Therefore, you can only use the existing
HTML files in the device until Jweb supports HTML file upload for a user logical systems.
In the chassis cluster scenario, you need to ensure that there is the same HTML file in the specified path
of each node.
If the custom-message configuration is invalid or you do not configure an HTML file, the system displays
the default block page for a blocked or quarantined webpage.
Options
custom-page-file Name of custom page file.

449
security
Release Information
custom-page | 445
custom-tag-string
IN THIS SECTION
Syntax | 449
Description | 450
Syntax
450
Hierarchy Level

[edit security utm feature-profile anti-spam sbl profile profile-name]
Description
Configure a custom string for identifying a message as spam.
Release Information
custom-url-category
IN THIS SECTION
Syntax | 451
Description | 451
Options | 451
451
Syntax
value [value];
}
Hierarchy Level

Description
Use URL pattern lists to create Custom URL category lists. These are lists of patterns that bypass
scanning.
Options
• object-name—Name of the URL category-list object.

452
• value value—Value of the URL category-list object. You can configure multiple values separated by
spaces and enclosed in square brackets.
Release Information
UTM Overview | 2
decompress-layer
IN THIS SECTION
Syntax | 453
Description | 453
Options | 453

453
Syntax
decompress-layer (block | log-and-permit);
Hierarchy Level

options]
Description
The Kaspersky antivirus feature is not supported from Junos OS Release 15.1X49-D10 onwards. For
previous releases, 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.
Options

454
decompress-layer-limit
IN THIS SECTION
Syntax | 454
Description | 455
Options | 456
Syntax
decompress-layer-limit decompress-layer-limit;
Hierarchy Level

options]
[edit anti-virus scan-options]
455
Description
When an antivirus scan engine scans a file for viruses, the scan engine decompresses the layers of
nested compressed files and files with embedded extractable objects. Embedded extractable objects
include files such as archive files (tar), MS Word, and PowerPoint files. For example, if a message
contains a compressed .zip file that contains another compressed .zip file, then there are two
compression layers. Decompressing both files requires a decompress layer setting of 2. You can set the
decompression layer limit for the scan engine.
During the transfer of data, some protocols use content encoding. Before an antivirus scan engine scans
viruses, the scan engine decodes this layer, which is considered as a decompression level.
The decompression layer limit is applicable to the following compressed files:
• zip, rar, and gzip
• Encoded data such as Multipurpose Internet Mail Extension (MIME)
• Packaged data such as OLE, CAP, MSI, TAR, EML
• Files with internal extractable objects, such as archive files (tar), MS Word, and PowerPoint files.
If a file exceeds the compression layer limit, the scan engine drops or forwards the file based on the
fallback options.
The scan engine scans each layer before unpacking the next layer. The scan engine continues to scan
until any of the following conditions are met, whichever happens first:
• Reaches the decompression limit
• Exceeds the system resource allocated for decompression
• Finds a virus or other malware
• Decompresses the data completely.
When the virus signature database becomes larger and the scan algorithms are more sophisticated, the
scan engine can look deeper into the data for embedded malware. As a result, the scan engine uncovers
more layers of compressed data.
The Juniper Networks device's level of security is limited by the decompress layer limit. You define the
decompress layer limit based on the memory allocated to the security service.
456
Options
decompress-layer-limit Specify the number of decompression layer limit.
• Default: 3
Release Information
The Kaspersky antivirus feature is not supported from Junos OS Release 15.1X49-D10 onwards.
Support at the [edit security utm default-configuration] hierarchy level introduced in Junos OS Release
18.2R1.
Support for Avira Antivirus scan engine added in Junos OS Release 18.4R1.

457
default (Security Antivirus)
IN THIS SECTION
Syntax | 457
Description | 457
Options | 458
Syntax
default (block | log-and-permit);
Hierarchy Level

fallback-options]
options]
Description
All errors other than those specifically listed fall into this category. This could include either unhandled
system exceptions (internal errors) or other unknown errors.
458
Options
Release Information
default (Security Antivirus Sophos Engine)
IN THIS SECTION
Syntax | 459
Description | 459
Options | 459

459
Syntax
Hierarchy Level

options]
Description
All errors other than those specifically listed fall into this category. This could include either unhandled
system exceptions (internal errors) or other unknown errors.
Options

460
Release Information
default (Security UTM)
IN THIS SECTION
Syntax | 460
Description | 461
Options | 461
Syntax
default (block |log-and-permit | permit);
Hierarchy Level

461
Description
Specify the default action to take for a URL.
Options
• permit—Permit the traffic.
Release Information
default (Security Web Filtering)
IN THIS SECTION
Syntax | 462
Description | 462
462
Options | 462
Syntax
default (block | log-and-permit | permit | quarantine);
Hierarchy Level

fallback-settings]
[edit security utm feature-profile web-filtering websense-redirect profile profile-name fallback-
settings]
[edit security utm feature-profile web-filtering juniper–local profile profile-name fallback-
settings]
[edit security utm feature-profile web-filtering juniper-enhanced profile profile-name fallback-
settings]
Description
Specify an action for the profile, for requests that experience internal errors in the Web-filtering module.
Options

463
• permit —Permit the traffic.
• quarantine—Show the warning message and permit/block the traffic based on user input.
Release Information
display-host (Security Fallback Block)
IN THIS SECTION
Syntax | 464
Description | 464

464
Syntax
display-host;
Hierarchy Level

Description
Display the computer host name in the notification e-mail sent to the administrator when a fallback-
block notification occurs.
Release Information
465
Release Description
15.1X49-D10 The Express and Kaspersky antivirus feature is not supported from Junos OS Release 15.1X49-
D10 onwards.
display-host (Security Virus Detection)
IN THIS SECTION
Syntax | 465
Description | 466
Syntax
display-host;
Hierarchy Level

[edit security utm feature-profile anti-virus profile profile name notification-options virus-
detection]
466
Description
Display the computer host name in the notification e-mail sent to the administrator when a virus is
detected by Sophos antivirus.
Release Information
download-profile (Security Antivirus FTP)
IN THIS SECTION
Syntax | 467
Description | 467

467
Syntax
Hierarchy Level

[edit security utm utm-policy policy-name anti-virus ftp]
Description
Configure a UTM policy for the antivirus FTP (download) protocol and attach this policy to a security
profile to implement it.
Release Information
468
download-profile (Security Content Filtering FTP)
IN THIS SECTION
Syntax | 468
Description | 468
Syntax
Hierarchy Level

[edit security utm utm-policy policy-name content-filtering ftp]
Description
Configure a UTM policy for the content-filtering FTP (download) protocol and attach this policy to a
security profile to implement it.

469
Release Information
email-notify
IN THIS SECTION
Syntax | 469
Description | 470
Options | 470
Syntax
email-notify {
}
470
Hierarchy Level
[edit security utm feature-profile anti-virus kaspersky-lab-engine pattern-update]

[edit security utm feature-profile anti-virus juniper-express-engine pattern-update]
[edit security utm feature-profile anti-virus sophos-engine pattern-update]
[edit security utm default-configuration anti-virus avira-engine pattern-update]
Description
Options
Release Information

471
engine-not-ready
IN THIS SECTION
Syntax | 471
Description | 471
Options | 472
Syntax
engine-not-ready (block | log-and-permit);
Hierarchy Level

fallback-options]
options]
Description
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.
472
Options
Release Information
engine-not-ready (Security Antivirus Sophos Engine)
IN THIS SECTION
Syntax | 473
Description | 473
Options | 473

473
Syntax
Hierarchy Level

options]
Description
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.
Options

474
Release Information
Statement introduced in Release 11.1.
exception
IN THIS SECTION
Syntax | 474
Description | 475
Syntax
exception listname;
475
Hierarchy Level

[edit security utm feature-profile anti-virus mime-whitelist]
[edit security utm feature-profile anti-virus mime-whitelist list listname]
Description
Configure the antivirus scanner to use an exception list to the MIME bypass list (custom objects). To use
the exception list, you first create a allowlist custom-object list with the list statement. The system will
first look at any existing allowlist mime pattern. If it matches an item, it will then continue to look for any
exceptions to the allowlist and will then scan any item in the exception list.
Release Information
exception (Security Content Filtering)
IN THIS SECTION
Syntax | 476
476
Description | 476
Syntax
Hierarchy Level

[edit security utm feature-profile content-filtering profile profile-name block-mime]
Description
Configure the content filter to use an exception list to the MIME block list (custom objects).
Release Information

477
fallback-block (Security Antivirus)
IN THIS SECTION
Syntax | 477
Description | 478
Options | 478
Syntax
fallback-block {
allow-email;
display-host;
}
478
Hierarchy Level

notification-options]
options]
Description
Configure notifications for fallback blocking actions. Fallback options tell the system how to handle the
errors returned by either the scan engine or the scan manager.
Options
Release Information
479
fallback-non-block (Security Antivirus)
IN THIS SECTION
Syntax | 479
Description | 480
Options | 480
Syntax
}
Hierarchy Level

options]
480
Description
Configure notifications for fallback nonblocking actions.
Options
Release Information
fallback-options (Security Antivirus Juniper Express

Engine)
IN THIS SECTION
Syntax | 481
Description | 481
481
Options | 481
Syntax
fallback-options {
out-of-resources (block | (log-and-permit);
timeout (block | log-and-permit);
too-many-requests (block | log-and-permit);
}
Hierarchy Level

[edit security utm feature-profile anti-virus juniper-express-engine profile profile-name]
Description
Fallback options tell the system how to handle the errors.
Options

482
Release Information
The Express Antivirus feature is not supported from Junos OS Release 15.1X49-D10 onwards. For
fallback-options (Security Antivirus Kaspersky Lab

Engine)
IN THIS SECTION
Syntax | 483
Description | 483
Options | 483

483
Syntax
fallback-options {
password-file (block | (log-and-permit);
}
Hierarchy Level

[edit security utm feature-profile anti-virus kaspersky-lab-engine profile profile-name]
Description
Fallback options tell the system how to handle the errors returned by either the scan engine or the scan
manager.
Options

484
Release Information
The Kaspersky feature is not supported from Junos OS Release 15.1X49-D10 onwards. For previous
releases, statement introduced in Junos OS Release 9.5 .
fallback-options (Security Antivirus Sophos Engine)
IN THIS SECTION
Syntax | 484
Description | 485
Options | 485
Syntax
fallback-options {
485

}
Hierarchy Level

[edit security utm feature-profile anti-virus sophos-engine profile profile-name]
Description
Configure fallback options to instruct the system how to handle errors.
Options
Release Information
486
fallback-settings (Security Web Filtering)
IN THIS SECTION
Syntax | 486
Description | 487
Options | 487
Syntax
fallback-settings {
server-connectivity (block | log-and-permit);
}
Hierarchy Level

487
Description
Fallback settings tell the system how to handle errors.
Options
Release Information
releases, Statement introduced in Junos OS Release 9.5 .
fallback-settings (Security Web Filtering Juniper

Local)
IN THIS SECTION
Syntax | 488

488
Description | 488
Options | 488
Syntax
fallback-settings {
}
Hierarchy Level

[edit security utm feature-profile web-filtering juniper–local profile profile-name]
Description
Options

489
Release Information
fallback-settings (Security Web Filtering Websense

Redirect)
IN THIS SECTION
Syntax | 490
Description | 490
Options | 490

490
Syntax
fallback-settings {
}
Hierarchy Level

Description
Options

491
Release Information
feature-profile
IN THIS SECTION
Syntax | 491
Description | 500
Options | 500
Syntax
feature-profile {
anti-spam {
sbl {
492
}
}
}
anti-virus {
pattern-update {
email-notify {
}
interval value;
no-autoupdate;
proxy {
password password-string;
port port-number;
server address-or-url;
username name;
}
url url;
}
fallback-options {
}
fallback-block {
allow-email;
display-host;
}
493
}
virus-detection {
}
}
scan-options {
(intelligent-prescreening | no-intelligent-prescreening);
timeout value;
}
trickling {
timeout value;
}
}
}
pattern-update {
email-notify {
}
interval value;
no-autoupdate;
proxy {
port port-number;
username name;
}
url url;
}
fallback-options {
494

}
fallback-block {
allow-email;
display-host;
}
}
virus-detection {
}
}
scan-options {
decompress-layer-limit value;
scan-extension filename;
scan-mode (all | by-extension);
timeout value;
}
trickling {
timeout value;
}
}
}
mime-whitelist {
exception listname;
495
list listname {
exception listname;
}
}
sophos-engine {
pattern-update {
email-notify {
}
interval value;
no-autoupdate;
proxy {
port port-number;
username name;
}
url url;
}
profile <name> {
fallback-options {
}
fallback-block {
allow-email;
display-host;
}
496
}
virus-detection {
}
}
scan-options {
(no-uri-check | uri-check);
timeout value;
}
trickling {
timeout value;
}
}
sxl-retry value;
}
type (juniper-express-engine | kaspersky-lab-engine | sophos-engine);
url-whitelist listname;
}
content-filtering {
block-mime {
list list-name;
}
}
permit-command protocol-command-list;
}
}
497
web-filtering {
http-reassemble;
juniper-enhanced {
cache {
timeout 1800;
size 500;
}
server {
port 80;
}
profile junos-wf-enhanced-default {
category {
Enhanced_Hacking {
}
Enhanced_Government {
action quarantine;
}
}
very-safe permit;
moderately-safe log-and-permit;
fairly-safe log-and-permit;
harmful block;
suspicious block;
}
default block;
fallback-settings {
default block;
timeout block;
}
timeout 10;
no-safe-search;
}
utm-policy mypolicy {
web-filtering {
498
http-profile my_ewfprofile01;
}
}
}
web-filtering {
juniper-enhanced {
cache {
size value;
timeout value;
}
category customurl-list name {
}
custom-quarantine-message value;
fallback-settings {
}
no-safe-search;
fairly-safe (block | log-and-permit | permit | quarantine);
harmful (block | log-and-permit | permit | quarantine);
moderately-safe (block | log-and-permit | permit | quarantine);
suspicious (block | log-and-permit | permit | quarantine);
very-safe (block | log-and-permit | permit | quarantine);
}
timeout value;
}
server {
host host-name;
port number;
}
}
juniper-local {
fallback-settings {
499

}
timeout value;
no-safe-search;
}
}
cache {
size value;
timeout value;
}
action (block | log-and-permit | permit);
}
fallback-settings {
}
timeout value;
}
server {
host host-name;
port number;
}
}
type (juniper-enhanced | juniper-local | surf-control-integrated | websense-redirect);
url-blacklist listname;
websense-redirect {
account value;
fallback-settings {
500

}
server {
host host-name;
port number;
}
sockets value;
timeout value;
no-safe-search;
}
}
}
}
Hierarchy Level

[edit security utm]
Description
Configure UTM features, antivirus, antispam, content-filtering, and web-filtering by creating feature
profiles.
Options

501
Release Information
Starting in Junos OS Release 21.4R1, content evaluation is based of the file content. The file type-based
evaluation of content is deprecated and the related configurations are hidden. So, the content filtering
options in this hierarchy is deprecated and not supported from Junos OS Release 21.4R1.
You can use the legacy functionality if you do not want to migrate to enhanced content filtering
functionality. You will be allowed to use the legacy configurations, but all the legacy configuration knobs
are deprecated and hidden. Also, you will receive system logs and error message warnings when you use
the legacy configuration options.
The Kaspersky, Express antivirus and Surf-Control features are not supported from Junos OS Release
15.1X49-D10 onwards. For previous releases, statement introduced in Release 9.5.
Starting with Junos OS Release 18.2R1, the following commands under the [edit security utm feature-
profile] hierarchy level are deprecated:
• set web-filtering type
• set web-filtering url-blacklist
• set web-filtering url-whitelist
• set web-filtering http-persist
• set web-filtering http-reassemble
• set web-filtering traceoptions
• set web-filtering juniper-enhanced cache
• set web-filtering juniper-enhanced reputation
• set web-filtering juniper-enhanced query-type
• set anti-virus mime-whitelist
• set anti-virus url-whitelist

502
• set anti-virus type
• set anti-virus traceoptions
• set anti-virus sophos-engine
• set anti-spam address-blacklist
• set anti-spam address-whitelist
• set anti-spam traceoptions
• set content-filtering traceoptions
no-safe-search option added for Websense redirect and Juniper local in Junos OS Release 20.2R1.
filename-extension
IN THIS SECTION
Syntax | 503
Description | 503
Options | 503

503
Syntax
value [value];
}
Hierarchy Level

Description
When scanning content, you can use a file extension list to define a set of file extensions that are used
in file extension scan mode (scan-by-extension).
Options
• object-name—Name of the extension-list object.
• value value—Value of the extension-list object. You can configure multiple values separated by spaces
and enclosed in square brackets.

504
Release Information
flag (SMTP)
IN THIS SECTION
Syntax | 504
Description | 505
Options | 505
Syntax
flag {
all;
configuration;
IPC;
protocol-exchange;
send-request;
}
505
Hierarchy Level
[edit smtp traceoptions]
Description
Set flag for the SMTP traceoptions.
Options
The following flag options are supported:
• IPC—Trace interprocesss communication.
• all—Trace everything.
• configuration—Trace configuration event.
• protocol-exchange—Trace SMTP protocol exchanges.
• send-request—Trace send mail request event.
system—To view this statement in the configuration.
system-control—To add this statement to the configuration.
Release Information
Statement added in Junos OS Release 10.0.

506
format (Security Log Stream)
IN THIS SECTION
Syntax | 506
Description | 507
Options | 507
Syntax
format (binary | sd-syslog | syslog | welf)
Hierarchy Level
[edit security log stream stream-name]

[edit logical-systems name security log stream stream-name]
[edit tenants tenant-name security log stream stream-name]
507
Description
Set the format for remote security message logging to binary, syslog (system log), sd-syslog (structured
system log), or welf. Note that for the WELF format, the category must be set to content-security (see
"category" on page 400).
Options
• binary—Binary encoded text to conserve resources.
• sd-syslog—Structured system log file.
• syslog—Traditional system log file.
• welf—Web Trends Extended Log Format.
• Default: By default syslog (system log) is enabled.
Release Information
Statement introduced in Junos OS Release 10.0 . Updated in Junos OS Release 12.1 .
The [edit logical-systems name security log stream stream-name] hierarchy level introduced in Junos OS
Release 18.2R1.
The [edit tenants tenant-name security log stream stream-name] hierarchy level introduced in Junos OS
Release 18.3R1.
Application Security User Guide for Security Devices

508
Logical Systems and Tenant Systems User Guide for Security Devices
forwarding-mode (Security UTM Policy)
IN THIS SECTION
Syntax | 508
Description | 509
Options | 509
Syntax
forwarding-mode {
hold;
inline-tap;
}
Hierarchy Level

509
Description
The default configuration for anti-virus is to use the continuous delivery function (CDF). It holds the last
packet and sends out all other packets. It saves system memory and makes the packet transmission
faster. This mode sends the last packet if the result is “permit” and sends RST message to both the client
and the server to reset the connection if the result is “drop”. In CDF mode, you may save an incomplete
infected file because it only holds the last packet and sends out others. This file could be executable and
harmful, for example, an incomplete script file. CDF mode does not support Mail protocols. Change to
hold mode to hold all the packets until you get the final result. Configure inline-tap mode to permit the
traffic even if it is infected. This mode is off by default. You can set the hold and inline-tap mode
separately or simultaneously. When you set both modes simultaneously, inline-tap over-rules the hold
mode and permits the traffic.
To delete hold mode use #delete security utm default-configuration anti-virus forwarding-mode hold, and to
delete inline-tap mode use #delete security utm default-configuration anti-virus forwarding-mode inline-tap.
Options
hold —Hold mode (hold file until analysis is complete, default is CDF mode).
inline-tap —Detect-only mode without blocking (default is off).
Release Information

510
UTM Overview | 2
from-zone (Security Policies)
IN THIS SECTION
Syntax | 510
Description | 513
Options | 513
Syntax
from-zone zone-name to-zone zone-name {

policy policy-name {
description description;
match {
application {
[junos-defaults | application];
any;
junos-smtps;
junos-imaps;
junos-pop3s;
}
}
dynamic-application {
[dynamic-application-name |dynamic-application-group-name];
any;
none;
}
511
destination-address {
[address];
any;
any-ipv4;
any-ipv6;
}
source-address {
[address];
any;
any-ipv4;
any-ipv6;
}
source-identity {
[role-name];
any;
authenticated-user;
unauthenticated-user;
unknown-user;
}
source-end-user-profile {
profile-name;
}
}
scheduler-name scheduler-name;
then {
count {
alarm {
per-minute-threshold number;
per-second-threshold number;
}
}
deny;
log {
session-close;
session-init;
}
permit {
application-firewall {
rule-set rule-set-name;
}
application-traffic-control {
512
}
gprs-gtp-profile profile-name;
gprs-sctp-profile profile-name;
idp;
redirect-wx | reverse-redirect-wx;
ssl-proxy {
profile-name profile-name;
}
uac-policy {
captive-portal captive-portal;
}
utm-policy policy-name;
}
drop-translated;
drop-untranslated;
}
firewall-authentication {
pass-through {
access-profile profile-name;
client-match user-or-group-name;
ssl-termination-profile profile-name;
web-redirect;
web-redirect-to-https;
}
user-firewall {
domain domain-name
}
web-authentication {
}
}
services-offload;
tcp-options {
initial-tcp-mss mss-value;
reverse-tcp-mss mss-value;
sequence-check-required;
syn-check-required;
}
tunnel {
513
ipsec-group-vpn group-vpn;
ipsec-vpn vpn-name;
pair-policy pair-policy;
}
}
deny | reject;
deny | reject [profile name];
}
}
}
Hierarchy Level
[edit security policies]
Description
Specify a source zone and destination zone to be associated with the security policy.
Options
• from-zone zone-name—Name of the source zone.
• to-zone zone-name—Name of the destination zone.

514
Release Information
Statement introduced in Junos OS Release 8.5. Support for the services-offload option added in Junos OS
Release 11.4. Support for the source-identity option added in Junos OS Release 12.1. Support for the
description option added in Junos OS Release 12.1. Support for the ssl-termination-profile and web-
redirect-to-https options added in Junos OS Release 12.1X44-D10. Support for the user-firewall option
added in Junos OS Release 12.1X45-D10. Support for the initial-tcp-mss and reverse-tcp-mss options
added in Junos OS Release 12.3X48-D20. Support for the dynamic-application and deny options added in
Junos OS Release 18.2R1.

Understanding Security Policy Rules
Understanding Security Policy Elements
Unified Policies Configuration Overview
ftp (UTM Policy Anti-Virus)
IN THIS SECTION
Syntax | 515
Description | 515
Options | 515

515
Syntax
ftp {
}
Hierarchy Level

[edit security utm utm-policy policy-name anti-virus]
Description
Configure a UTM policy for the antivirus FTP protocol and attach this policy to a security profile to
implement it.
Options

516
Release Information

ftp (UTM Policy Content Filtering)
IN THIS SECTION
Syntax | 516
Description | 517
Options | 517
Syntax
ftp {
}
517
Hierarchy Level

[edit security utm utm-policy policy-name content-filtering]
Description
Configure a UTM policy for the content-filtering FTP protocol and attach this policy to a security profile
to implement it.
Options
Release Information

518
hold-interval
IN THIS SECTION
Syntax | 518
Description | 518
Options | 519
Syntax
hold-interval seconds;
Hierarchy Level
[edit security dynamic-address session-scan]
Description
If you enable the session-scan option at the [edit security dynamic-address address-name name] hierarchy level,
the security device initiates session scan when:
• You add a new address into the dynamic-address entry.
• The system reaches the configured hold-interval time.

519
Options
seconds Time interval before the session scan requests in seconds.
• Range: 1 thru 3600 seconds
• Default: 10 seconds
security
Release Information
session-scan | 664
host (Security Web Filtering)
IN THIS SECTION
Syntax | 520
Description | 520

520
Syntax
host host-name;
Hierarchy Level

[edit security utm feature-profile web-filtering surf-control-integrated server]
[edit security utm feature-profile web-filtering websense-redirect profile profile-name server]
[edit security utm feature-profile web-filtering juniper-enhanced profile profile-name server]
Description
Set server host parameters by entering the server name or IP address.
Release Information
521
http-profile (Security Antivirus)
IN THIS SECTION
Syntax | 521
Description | 521
Syntax
Hierarchy Level

Description
Configure a UTM policy for the antivirus HTTP protocol and attach this policy to a security profile to
implement it.

522
Release Information
http-profile (Security Content Filtering)
IN THIS SECTION
Syntax | 522
Description | 523
Syntax
Hierarchy Level

523
Description
Configure a UTM policy for the content-filtering HTTP protocol and attach this policy to a security
Release Information
http-profile (Security Web Filtering)
IN THIS SECTION
Syntax | 524
Description | 524

524
Syntax
Hierarchy Level

[edit security utm utm-policy policy-name web-filtering]
Description
Configure a UTM policy for the Web-filtering HTTP protocol and attach this policy to a security profile
to implement it.
Release Information

525
imap-profile (Security UTM Policy Antivirus)
IN THIS SECTION
Syntax | 525
Description | 525
Syntax
Hierarchy Level

Description
Configure a UTM policy for the antivirus IMAP protocol and attach this policy to a security profile to
implement it.

526
Release Information
imap-profile (Security UTM Policy Content Filtering)
IN THIS SECTION
Syntax | 526
Description | 527
Syntax
Hierarchy Level

527
Description
Configure a UTM policy for the content-filtering IMAP protocol and attach this policy to a security
Release Information
http-persist
IN THIS SECTION
Syntax | 528
Description | 528

528
Syntax
http-persist;
Hierarchy Level

Description
Checks all HTTP requests in a connection. By default, Web filtering first checks the HTTP request
method (for example, GET or PUT) in the same session. If there are multiple HTTP request methods in
the subsequent HTTP request of the same session, then Web filtering checks are not performed on
these methods. If http-persist command is enabled for clear text HTTP traffic, then Web filtering checks
every HTTP request packet in the same session.
view
Release Information
Statement introduced in Junos OS Release 12.3X48-D25.

529
http-reassemble
IN THIS SECTION
Syntax | 529
Description | 529
Syntax
http-reassemble;
Hierarchy Level

Description
Reassembles HTTP requests segments. When the http-reassemble option is enabled the requested
fragment is reassembled. By default, Web filtering checks only HTTP requests in the first HTTP request
packet. If HTTP request methods and URLs are fragmented in different packets, then these URLs are not
checked. If http-reassemble option is enabled for clear text HTTP traffic, then Enhanced Web Filtering
(EWF) reassembles the fragmented HTTP request to avoid evasion instead of packet-based inspection.
When a new URL is matched against the active Web Filtering profile and the profile dictates that the
URL should be dropped, the entire HTTP session will be blocked by the device.
530
view
Release Information
intelligent-prescreening
IN THIS SECTION
Syntax | 530
Description | 531
Syntax
531
Hierarchy Level

options]
options]
Description
Enable intelligent prescreening.
Intelligent prescreening tells the antivirus module to begin scanning a file much earlier. In this case, the
scan engine uses the first packet or the first several packets to determine if a file could possibly contain
malicious code. The scan engine does a quick check on these first packets and if the scan engine finds
that it is unlikely that the file is infected, it then determines that it is safe to bypass the normal scanning
procedure.
You can disable intelligent prescreening with the no-intelligent-prescreening statement.
Release Information
The Express and Kaspersky Antivirus feature is not supported from Junos OS Release 15.1x49-D10
532
Release Description
15.1X49-D10 The Express and Kaspersky Antivirus feature is not supported from Junos OS Release 15.1x49-
D10 onwards.
interval (Security Antivirus)
IN THIS SECTION
Syntax | 532
Description | 533
Options | 533
Syntax
interval value;
Hierarchy Level

533
Description
Set the pattern data files auto-update interval. You can choose to leave the default interval value or you
can change it by using this command. You can also force a manual update, if necessary.
NOTE: The data files used with Sophos are not typical virus pattern files; they are small files that
help guide virus scanning logic. The full virus pattern database is stored on an external Sophos
server called the Sophos Extensible List (SXL) server.
Options
value—Pattern data files auto-update interval in minutes.
• Range: 10 through 10,080 minutes (10 minutes through 7 days)
• Default: For Juniper Express engine and Kaspersky Lab engine, 60 minutes; for Sophos engine, 1440
minutes (every 24 hours)
Release Information
The Express and Kaspersky Antivirus feature is not supported from Junos OS Release 15.1X49-D10
onwards. For previous releases, statement introduced in Junos OS Release 9.5 for Juniper Express
engine and Kaspersky Lab engine. Support for Sophos engine added in Junos OS Release 11.1.

534
ipc
IN THIS SECTION
Syntax | 534
Description | 534
Options | 535
Syntax
ipc {
}
Hierarchy Level

[edit security utm]
Description
Configure trace options for IPC.

535
Options
• flag—Trace operation to perform. To specify more than one trace operation, include multiple flag
statements.
• all—Enable trace for all IPC trace options.
• basic—Trace basic IPC related information.
• connection-manager—Trace IPC connection manager information.
• connection-status—Trace IPC connection status information.
• detail—Trace IPC related detailed information.
• pfe—Trace communication with PFE.
• utm-realtime—Trace IPC realtime-thread information.
Release Information
juniper-enhanced
IN THIS SECTION
Syntax | 536
536
Description | 537
Options | 537
Syntax
juniper-enhanced {
cache {
size value;
timeout value;
}
}
fallback-settings {
}
no-safe-search;
}
timeout value;
}
server {
537
host host-name;
port number;
proxy-profile proxy profile name;
}
}
Hierarchy Level

[set security utm feature-profile web-filtering]
Description
Configure the UTM Enhanced Web Filtering feature.
Options
Release Information
538
The proxy-profile option is introduced under the security utm default-configuration web-filtering juniper-
enhanced server hierarchy level in Junos OS Release 18.3R1.
juniper-express-engine
IN THIS SECTION
Syntax | 538
Description | 540
Options | 540
Syntax
pattern-update {
email-notify {
}
interval value;
no-autoupdate;
proxy {
port port-number;
539
username name;
}
url url;
}
fallback-options {
}
fallback-block {
allow-email;
display-host;
}
}
virus-detection {
}
}
scan-options {
timeout value;
}
trickling {
timeout value;
540
}
}
}
Hierarchy Level

Description
Configure the UTM express antivirus feature.
Options
Release Information
541
juniper-local
IN THIS SECTION
Syntax | 541
Description | 542
Options | 542
Syntax
juniper-local {
block-message (Security UTM) value;
default (Security Web Filtering) (block | log-and-permit | permit);
fallback-settings (Security Web Filtering) {
default (Security Web Filtering) (block | log-and-permit);
timeout (Security Web Filtering Fallback Settings) (block | log-and-permit);
too-many-requests (Security Web Filtering Fallback Settings) (block | log-and-permit);
}
timeout value;
no-safe-search;
}
}
542
Hierarchy Level

Description
Configure the UTM Web-filtering local feature.
Options
no-safe-search Disable the safe search function.
Release Information
no-safe-search option added in Junos OS Release 20.2R1.

543
kaspersky-lab-engine
IN THIS SECTION
Syntax | 543
Description | 545
Options | 545
Syntax
pattern-update {
email-notify {
}
interval value;
no-autoupdate;
proxy {
port port-number;
username name;
}
url url;
}
fallback-options {
544

}
fallback-block {
allow-email;
display-host;
}
}
virus-detection {
}
}
scan-options {
timeout value;
}
trickling {
timeout value;
}
}
}
545
Hierarchy Level

Description
Configure the UTM full file-based antivirus feature.
Options
Release Information
The Kaspersky Antivirus feature is not supported from Junos OS Release 15.1x49-D10 onwards. For
546
limit (UTM Policy)
IN THIS SECTION
Syntax | 546
Description | 546
Syntax
limit value;
Hierarchy Level

[edit security utm utm-policy policy-name traffic-options sessions-per-client]
Description
In an attempt to consume all available resources and hinder the ability of the device, a malicious user
might generate a large amount of traffic all at once. To prevent such activity from succeeding, you can
impose a session throttle to limit sessions.
547
Release Information
list
IN THIS SECTION
Syntax | 547
Description | 548
Options | 548
Syntax
list listname {
exception listname;
}
548
Hierarchy Level

[edit security utm feature-profile anti-virus mime-whitelist]
Description
Configure the antivirus scanner to use MIME bypass lists (custom objects). If you want to have
exceptions to the allowlist, create a mime-pattern list with the exception statement in addition to the list
statement.
Options
Release Information
549
list (Security Content Filtering Block Mime)
IN THIS SECTION
Syntax | 549
Description | 549
Syntax
list list-name;
Hierarchy Level

[edit security utm feature-profile content-filtering profile profile-name block-mime]
Description
Configure the content filter to use MIME block lists (custom objects).

550
Release Information
log (Security)
IN THIS SECTION
Syntax | 550
Description | 553
Options | 553
Syntax
log {
(source-address source-address | source-interface source-interface);
cache {
exclude name {
destination-address destination-address;
destination-port destination-port;
551
event-id event-id;
failure;
interface-name interface-name;
policy-name policy-name;
process process;
protocol protocol;
source-address source-address;
source-port source-port;
success;
username username;
}
limit limit;
}
disable;
escape;
time-format (year | millisecond);
event-rate logs per second;
facility-override (authorization | daemon | ftp | kernel | local0 | local1 | local2 | local3 |
local4 | local5 | local6 | local7 | user);
file {
files files;
name name;
path path;
size size;
}
format (binary | sd-syslog | syslog);
max-database-record max-database-record;
message-rate-limit messages per second;
mode (event | stream | stream-event);
rate-cap logs per second;
report {
logs-per-table {
idp idp;
ipsec-vpn ipsec-vpn;
screen screen;
session-all session-all;
sky sky;
utm utm;
}
table-lifetime table-lifetime;
table-mode {
dense;
}
552
}
root-streaming;
stream stream-name {
category (all | content-security | fw-auth | screen | alg | nat | flow | sctp | gtp |
ipsec | idp | rtlog |pst-ds-lite | appqos |secintel |aamw);
filter {
threat-attack;
}
format (binary | sd-syslog | syslog | welf);
host {
ip-address;
port port-number;
routing-instanceinstance-name;
}
rate-limit {
log-rate;
}
severity (alert | critical | debug | emergency | error | info | notice | warning);
source-address {
ip-address;
}
time-format (year | millisecond);
transport {
protocol (tcp | tls | udp);
tcp-connections tcp-connections;
tls-profile tls-profile;
}
}
traceoptions {
file <filename> <files files> <match match> <size size> <(world-readable | no-world-
readable)>;
flag name;
no-remote-trace;
}
transport {
protocol (tcp | tls | udp);
tcp-connections tcp-connections;
tls-profile tls-profile;
}
utc-timestamp;
}
553
Hierarchy Level
[edit security]
[edit logical-systems name security]
[edit tenants tenant-name security]
Description
Configure security log. Set the mode of logging (event for traditional system logging or stream for
streaming security logs through a revenue port to a server). You can also specify all the other parameters
for security logging.
Options
cache Cache security log events in the audit log buffer.
disable Disable the security logging for the device.
escape Escapes the stream log forwarding to avoid parsing errors. Stream mode supports
escape in sd-syslog and binary format. Event mode supports escape only in binary
format.
time-format Specify the year, the millisecond, or both in the timestamp.
event-rate rate Limit the rate at which logs are streamed per second.
• Default: 1500
facility-override Alternate facility for logging to remote host.
file Specify the security log file options for logs in binary format.
• Values:
554
• max-file-number—Maximum number of binary log files.
• The range is 2 through 10 and the default value is 10.
• file-name—Name of binary log file.
• binary-log-file-path—Path to binary log files.
• maximum-file-size—Maximum size of binary log file in megabytes.
• The range is 1 through 10 and the default value is 10.
format Set the security log format for the device.
max-database-record The following are the disk usage range limits for the database:
• Range:
• SRX1500, SRX4100, and SRX4200: 0 through 15,000,000
• vSRX: 0 through 1,000,000
• Default:
• SRX1500, SRX4100, and SRX4200: 15,000,000
• vSRX: 1,000,000
Be sure there is enough free space in /var/log/hostlogs/, otherwise logs might be

dropped when written into the database.
mode Control how security logs are processed and exported.
rate-cap rate-cap- Work with event mode only. This option limits the rate at which data plane logs are
value generated per second.
• Range: 0 through 5000 logs per second
• Default: 5000 logs per second
root-streaming Allows the user logical systems to generate the logs using the root logical system's
stream configuration.
source-address Specify a source IP address or IP address used when exporting security logs, which
source-address is mandatory to configure stream host.
source-interface Specify a source interface name, which is mandatory to configure stream host.
interface-name
555
The source-address and source-interface are alternate values. Using one of the options
is mandatory.
stream Every stream can configure file or host.
traceoptions Specify security log daemon trace options.
transport Set security log transport settings.
utc-timestamp Specify to use UTC time for security log timestamps.
Release Information
The [edit logical-systems name security] and [edit tenants tenant-name security] hierarchy levels
introduced in Junos OS Release 19.1R1.
escape option added in Junos OS Release 20.2R1.
root-streaming option added in Junos OS Release 20.3R1.
mime-pattern
IN THIS SECTION
Syntax | 556
556
Description | 556
Options | 556
Syntax
value [value];
}
Hierarchy Level

Description
The gateway device uses MIME (Multipurpose Internet Mail Extension) types to decide which traffic is
allowed to bypass various types of scanning.
Options
• object-name—Name of the MIME object.
• value value—Value of the MIME object. You can configure multiple values separated by spaces and
enclosed in square brackets.
557
Release Information
mime-whitelist
IN THIS SECTION
Syntax | 557
Description | 558
Options | 558
Syntax
mime-whitelist {
exception listname;
list listname {
exception listname;
}
}
558
Hierarchy Level

Description
Configure the antivirus scanner to use MIME bypass lists and exception lists. You can use your own
custom object lists, or you can use the default list that ships with the device called junos-default-bypass-
mime.
WARNING: When you configure the MIME allowlist feature, be aware that, because
header information in HTTP traffic can be spoofed, you cannot always trust HTTP
headers to be legitimate. When a Web browser is determining the appropriate action
for a given file type, it detects the file type without checking the MIME header
contents. However, the MIME allowlist feature does refer to the MIME encoding in the
HTTP header. For these reasons, it is possible in certain cases for a malicious website to
provide an invalid HTTP header. For example, a network administrator might
inadvertently add a malicious website to a MIME allowlist, and, because the site is in
the allowlist, it will not be blocked by Sophos even though Sophos has identified the
site as malicious in its database. Internal hosts would then be able to reach this site and
could become infected.
Options

559
Release Information
Statement introduced in Junos OS Release 9.5. Statement updated.
no-autoupdate
IN THIS SECTION
Syntax | 559
Description | 560
Syntax
no-autoupdate;
Hierarchy Level

560
Description
Turn off automatic data file (pattern file) update for the Kaspersky Lab, Juniper Express, or Sophos
engines.
NOTE: The data files used with Sophos are not typical virus pattern files; they are small files that
help guide virus scanning logic. The full virus pattern database is stored on an external Sophos
server called the Sophos Extensible List (SXL) server.
Release Information
no-intelligent-prescreening
IN THIS SECTION
Syntax | 561

561
Description | 561
Syntax
no-intelligent-prescreening;
Hierarchy Level

options]
options]
Description
Disables intelligent prescreening.
Intelligent prescreening tells the antivirus module to begin scanning a file much earlier. In this case, the
scan engine uses the first packet or the first several packets to determine if a file could possibly contain
malicious code. The scan engine does a quick check on these first packets and if the scan engine finds
that it is unlikely that the file is infected, it then determines that it is safe to bypass the normal scanning
procedure.
You can enable intelligent prescreening with the intelligent-prescreening statement.

562
Release Information
no-notify-mail-recipient
IN THIS SECTION
Syntax | 562
Description | 563
Syntax
no-notify-mail-recipient;
563
Hierarchy Level

Description
Do not notify the e-mail recipient about errors returned by the antivirus scan engine when a fallback
nonblocking action occurs.
You can specify that the e-mail recipient is to be notified with the notify-mail-recipient statement.
Release Information
564
no-notify-mail-sender (Security Content Filtering

Notification Options)
IN THIS SECTION
Syntax | 564
Description | 564
Syntax
no-notify-mail-sender;
Hierarchy Level

Description
Do not notify the e-mail sender.

565
Release Information
no-notify-mail-sender (Security Fallback Block)
IN THIS SECTION
Syntax | 565
Description | 566
Syntax
566
Hierarchy Level

Description
Do not notify the e-mail sender about errors returned by the antivirus scan engine when a fallback
action occurs.
You can specify that the e-mail sender is to be notified with the notify-mail-sender statement.
Release Information
567
no-notify-mail-sender (Security Virus Detection)
IN THIS SECTION
Syntax | 567
Description | 567
Syntax
Hierarchy Level

Description
Do not notify the e-mail sender when a virus is detected by the antivirus engine.
You can specify that the e-mail sender is to be notified with the notify-mail-sender statement.
568
Release Information
no-sbl-default-server
IN THIS SECTION
Syntax | 568
Description | 569
Syntax
no-sbl-default-server;
569
Hierarchy Level

Description
Disable the default SBL server lookup.
Release Information

570
notification-options (Security Antivirus)
IN THIS SECTION
Syntax | 570
Description | 571
Options | 571
Syntax
fallback-block {
allow-email;
display-host;
}
}
virus-detection {
571
}
}
Hierarchy Level

Description
There are multiple notification options you can configure to trigger when a virus is detected.
Options
Release Information
572
notification-options (Security Content Filtering)
IN THIS SECTION
Syntax | 572
Description | 572
Options | 573
Syntax
}
Hierarchy Level

Description
You can configure a message notification to trigger when a content filter is matched.
573
Options
Release Information
notify-mail-recipient
IN THIS SECTION
Syntax | 574
Description | 574

574
Syntax
notify-mail-recipient;
Hierarchy Level

Description
Notify the e-mail recipient about errors returned by the antivirus scan engine when a fallback
nonblocking action occurs.
You can specify that the e-mail recipient is not to be notified with the no-notify-mail-recipient statement.
Release Information
575
notify-mail-sender (Security Content Filtering

Notification Options)
IN THIS SECTION
Syntax | 575
Description | 575
Syntax
notify-mail-sender;
Hierarchy Level

Description
Notify the e-mail sender.

576
Release Information
notify-mail-sender (Security Fallback Block)
IN THIS SECTION
Syntax | 576
Description | 577
Syntax
notify-mail-sender;
577
Hierarchy Level

Description
E-mail notification is used to notify the sender or the recipient about the errors returned by either the
scan engine or the scan manager when a fallback action occurs.
You can specify that the sender is not to be notified with the no-notify-mail-sender statement.
Release Information
onwards. For previous releases, statement introduced in Junos OS Release 9.5 . Support for Sophos
578
notify-mail-sender (Security Virus Detection)
IN THIS SECTION
Syntax | 578
Description | 578
Syntax
notify-mail-sender;
Hierarchy Level

Description
E-mail notification is used to notify the sender or the recipient about the detected viruses or the
scanning errors. When a virus is detected, an e-mail is sent to the sender upon virus detection.
579
You can specify that the sender is not to be notified with the no-notify-mail-sender statement.
Release Information
no-uri-check
IN THIS SECTION
Syntax | 579
Description | 580
Syntax
no-uri-check;
580
Hierarchy Level
Description
Do not perform Sophos antivirus Uniform Resource Identifier (URI) checking. URI checking is performed
by analyzing HTTP traffic URI content against a remote Sophos database server to identify malware or
malicious content. URI checking is on by default.
NOTE: Starting in Junos OS release 18.4R1, the URI checking is off by default.
You can enable Sophos antivirus URI checking with the uri-check statement.
Release Information
581
out-of-resources
IN THIS SECTION
Syntax | 581
Description | 581
Options | 582
Syntax
Hierarchy Level

fallback-options]
options]
Description
memory allocation requests can be denied by the system. When out-of-resources occurs, scanning is
terminated. The default action is block.
582
Options
Release Information
out-of-resources (Security Antivirus Sophos Engine)
IN THIS SECTION
Syntax | 583
Description | 583
Options | 583

583
Syntax
Hierarchy Level

options]
Description
memory allocation requests can be denied by the system. When out-of-resources occurs, scanning is
terminated.
Options

584
Release Information
Statement introduced in Release 11.1.
over-limit
IN THIS SECTION
Syntax | 584
Description | 585
Options | 585
Syntax
over-limit (block | log-and-permit);

585
Hierarchy Level

[edit security utm utm-policy policy-name traffic-options sessions-per-client]
Description
impose a session throttle to limit sessions and configure an action to occur when the limit is exceeded.
Options
Release Information
utm | 748
586
packet-filter
IN THIS SECTION
Syntax | 586
Description | 587
Options | 587
Syntax
packet-filter packet-filter-name {
action-profile profile-name {
destination-port (Security Forwarding Options) (port-range | protocol-name);
destination-prefix destination-prefix;
interface logical-interface-name;
protocol (Security Forwarding Options) (protocol-number | protocol-name;
source-port (Security Forwarding Options) (port-range | protocol- name);
source-prefix source-prefix;
}
Hierarchy Level
[edit security datapath-debug]

587
Description
Set packet filter for taking the datapath-debug action. A filter is defined to filter traffic, then an action
profile is applied to the filtered traffic. Be sure to configure multiple packet filters to capture the traffic.
One packet filter only captures the traffic as specified in it, such as from one source to one destination.
The same packet filter will not capture the traffic in the reverse direction. You need to configure another
packet filter to capture the traffic in reverse direction and specify the source and destination according
to the response packet in it. The action profile specifies a variety of actions on the processing unit. A
maximum of four filters are supported at the same time. Packet filters can be configured with source and
destination prefix and port (including ranges), and protocol.
Action-profile settings have no specific minimum setting, it is based on trace, count, packet summary
and packet-dump. Enabling end-to-end debugging without or with a very broad filter is not
recommended. This could result in a high PFE CPU usage. Therefore when selecting what to capture
through a filter care must be taken. List as many and specific criteria which then results in the minimum
amount of traffic to be captured.
NOTE: Packet filter is supported on SRX1400, SRX3400, SRX3600, SRX5400, SRX5600, and
SRX5800 devices.
Options
• action-profile profile-name—Identify the action profile to use. You can specify the name of the action
profile to use. Using the request security action-profile command, you can set the action for the
packet match for a specified filter. Action-profile must be defined.
• destination-port (port-range | protocol name)—Specify a destination port to match TCP/UDP destination

port.
• destination-prefix destination-prefix—Specify a destination IPv4/IPv6 address prefix.
• interface logical-interface-name—Specify a logical interface name.
• protocol (protocol-number | protocol-name—Match IP protocol type.
• source-port (port-range | protocol-name—Match TCP/UDP source port.
• source-prefix source-prefix—Specify a source IP address prefix.

588
security—To view this in the configuration
security-control—To add this to the configuration.
Release Information
Command introduced in Junos OS Release 9.6 ; Support for IPv6 addresses for the destination-prefix and
source-prefix options added in Junos OS Release 10.4.
password (Security Antivirus)
IN THIS SECTION
Syntax | 588
Description | 589
Syntax
589
Hierarchy Level

[edit security utm feature-profile anti-virus juniper-express-engine pattern-update proxy]
[edit security utm feature-profile anti-virus kaspersky-lab-engine pattern-update proxy]
[edit security utm feature-profile anti-virus sophos-engine pattern-update proxy]
Description
Set the password for the proxy server.
Release Information
onwards. For previous releases, statement introduced in Release 11.2.
utm | 748
590
password-file
IN THIS SECTION
Syntax | 590
Description | 590
Options | 591
Syntax
Hierarchy Level

options]
Description
Password protected file is the error returned by the scan engine when the scanned file is protected by a
password. The default action is log-and-permit.
591
Options
Release Information
pattern-update (Security Antivirus)
IN THIS SECTION
Syntax | 592
Description | 592

592
Syntax
pattern-update {
email-notify {
}
interval value;
no-autoupdate;
proxy-profile proxy profile name;
routing-instance name;
url url;
}
Hierarchy Level

[edit security utm feature-profile anti-virus sophos-engine]
[edit security utm default-configuration anti-virus avira-engine]
Description
Updates to the pattern file are added as new viruses are discovered. You can configure the security
device to regularly update the pattern file automatically, or you can update the file manually.

593
Release Information
The proxy-profile option is introduced under the security utm feature-profile anti-virus sophos-engine
hierarchy level in Junos OS Release 18.3R1.
permit-command
IN THIS SECTION
Syntax | 593
Description | 594
Syntax
Hierarchy Level

594
Description
Apply protocol permit command custom-objects to the content-filtering profile.
Release Information
policies
IN THIS SECTION
Syntax | 595
Description | 603
Options | 603

595
Syntax
policies {
default-policy (deny-all | permit-all);
from-zone from-zone-name {
to-zone;
policy name {
match (Security Policies Global) {
source-address (Security Policies);
destination-address (Security Policies);
application (Security Policies);
source-identity;
source-end-user-profile <source-end-user-profile-name>;
dynamic-application (Security Policies);
url-category;
from-zone (Security Policies Global);
to-zone (Security Policies Global);
source-l3vpn-vrf-group [ source-l3vpn-vrf-group ... ];
destination-l3vpn-vrf-group [ destination-l3vpn-vrf-group ... ];
destination-address-excluded;
source-address-excluded;
}
then {
deny;
permit {
(redirect-wx | reverse-redirect-wx);
advanced-anti-malware-policy advanced-anti-malware-policy;
rule-set rule-set;
}
gprs-gtp-profile gprs-gtp-profile;
gprs-sctp-profile gprs-sctp-profile;
icap-redirect icap-redirect;
idp;
idp-policy idp-policy;
security-intelligence-policy security-intelligence-policy;
ssl-proxy {
596
}
uac-policy {
}
utm-policy utm-policy;
web-proxy {
}
}
destination-address (Security IDP Policy) {
(drop-translated | drop-untranslated);
}
pass-through {
access-profile access-profile;
auth-only-browser;
auth-user-agent name;
client-match [ client-match ... ];
ssl-termination-profile ssl-termination-profile;
web-redirect;
}
user-firewall {
auth-only-browser;
domain domain;
web-redirect;
}
}
push-to-identity-management;
}
services-offload;
tcp-options {
initial-tcp-mss initial-tcp-mss;
reverse-tcp-mss reverse-tcp-mss;
syn-check-required;
window-scale;
597
}
tunnel {
}
}
reject {
profile profile;
ssl-proxy {
}
}
count {
}
log {
session-close;
session-init;
}
}
}
}
global {
policy name {
source-identity;
url-category;
}
then {
deny;
permit {
598
rule-set rule-set;
}
idp;
ssl-proxy {
}
uac-policy {
}
web-proxy {
}
}
}
pass-through {
auth-only-browser;
web-redirect;
}
user-firewall {
auth-only-browser;
domain domain;
web-redirect;
599
}
}
}
services-offload;
tcp-options {
syn-check-required;
window-scale;
}
tunnel {
}
}
reject {
profile profile;
ssl-proxy {
}
}
count {
}
log {
session-close;
session-init;
}
}
}
}
policy-rematch <extensive>;
policy-stats {
system-wide (disable | enable);
}
pre-id-default-policy {
then {
log {
session-close;
600
session-init;
}
session-timeout {
icmp seconds;
icmp6 seconds;
ospf seconds;
others seconds;
tcp seconds;
udp seconds;
}
}
}
stateful-firewall-rule name {
match-direction (input | input-output | output);
policy name {
source-identity;
url-category;
}
then {
deny;
permit {
rule-set rule-set;
}
601
idp;
ssl-proxy {
}
uac-policy {
}
web-proxy {
}
}
}
pass-through {
auth-only-browser;
web-redirect;
}
user-firewall {
auth-only-browser;
domain domain;
web-redirect;
}
}
}
services-offload;
602
tcp-options {
syn-check-required;
window-scale;
}
tunnel {
}
}
reject {
profile profile;
ssl-proxy {
}
}
count {
}
log {
session-close;
session-init;
}
}
}
}
stateful-firewall-rule-set name {
stateful-firewall-rule name;
}
traceoptions (Security Policies) {
file <filename> <files files> <match match> <size size> <(world-readable | no-world-
readable)>;
flag name;
no-remote-trace;
}
unified-policy {
max-lookups max-lookups;
}
}
603
Hierarchy Level
[edit security]
Description
Configure a network security policies with IPv6 addresses only if flow support for IPv6 traffic is enabled
on the device.
Options
default-policy Configure a default action when no user-defined policy match.
• Values:
• deny-all—Deny all traffic if no policy match
• permit-all—Permit all traffic if no policy match
policy-rematch Re-evaluate the policy when changed.
• Values:
• extensive—Perform policy extensive rematch
Release Information

604
Support for the services-offload option added in Junos OS Release 11.4.
Support for the source-identitiy option added in Junos OS Release 12.1.
Support for the description option added in Junos OS Release 12.1.
Support for the ssl-termination-profile and web-redirect-to-https options are added starting from Junos OS
Release 12.1X44-D10 and Junos OS Release 15.1X49-D40.
Support for the user-firewall option added in Junos OS Release 12.1X45-D10.
Support for the domain option, and for the from-zone and to-zone global policy match options, added in
Junos OS Release 12.1X47-D10.
Support for the initial-tcp-mss and reverse-tcp-mss options added in Junos OS Release 12.3X48-D20.
Support for the extensive option for policy-rematch added in Junos OS Release 15.1X49-D20.
Starting in Junos OS Release 18.2R1, an IDP policy is available within unified security policy. The IDP
policy access is simplified and made available under the unified policy as one of the policy. When an IDP
policy is available within a unified security policy, configuring source or destination address, source and
destination-except, from and to zone, or application is not required, because the match happens in the
security policy itself.
Starting in Junos OS Release 18.3R1, when an SRX Series device is configured with a unified policies,
you can configure multiple IDP policies and set one of those policies as the default IDP policy. If multiple
IDP policies are configured for a session and when policy conflict occurs, the device applies the default
IDP policy for that session and thus resolves any policy conflicts.
NOTE: If you have configured two or more IDP policies in a unified security policy, then you
must configure the default IDP policy.

605
pop3-profile (Security UTM Policy Antivirus)
IN THIS SECTION
Syntax | 605
Description | 605
Syntax
Hierarchy Level

Description
Configure a UTM policy for the antivirus POP3 protocol and attach this policy to a security profile to
implement it.

606
Release Information
pop3-profile (Security UTM Policy Content Filtering)
IN THIS SECTION
Syntax | 606
Description | 607
Syntax
Hierarchy Level

607
Description
Configure a UTM policy for the content filtering POP3 protocol and attach this policy to a security
Release Information
port (Security Antivirus)
IN THIS SECTION
Syntax | 608
Description | 608
Options | 608

608
Syntax
port port-number;
Hierarchy Level

Description
Set the port number for the proxy server.
Options
• Range: 0 through 65,535
Release Information
609
port (Security Web Filtering Server)
IN THIS SECTION
Syntax | 609
Description | 609
Syntax
port number;
Hierarchy Level

[edit security utm feature-profile web-filtering surf-control-integrated server]
[edit security utm feature-profile web-filtering juniper-enhanced profile profile-name server]
Description
Enter the port number for communicating with the server. (Default ports are 80, 8080, and 8081.)
610
Release Information
primary-server
IN THIS SECTION
Syntax | 610
Description | 611
Options | 611
Syntax
primary-server {
address ipv4-address;
login sender-email-address {
password password;
}
}
611
Hierarchy Level
[edit smtp]
Description
Configure Simple Mail Transfer Protocol (SMTP) primary server for access authorization for SMTP
requests.
Options
Release Information

612
profile (Security Antispam SBL)
IN THIS SECTION
Syntax | 612
Description | 612
Options | 613
Syntax
}
Hierarchy Level

[edit security utm feature-profile anti-spam sbl]
Description
Create a profile for the antispam sbl feature. This profile includes all subsequent configuration options.
613
Options
Release Information
profile (Security Antivirus Juniper Express Engine)
IN THIS SECTION
Syntax | 614
Description | 615
Options | 615

614
Syntax
fallback-options {
}
fallback-block {
allow-email;
display-host;
}
}
virus-detection {
}
}
scan-options {
timeout value;
}
trickling {
timeout value;
615
}
}
Hierarchy Level

Description
Create a profile for the Juniper express engine. This profile includes all subsequent configuration
options.
Options
Release Information
The express engine feature is not supported from Junos OS Release 15.1X49-D10 onwards. For
616
profile (Security Antivirus Kaspersky Lab Engine)
IN THIS SECTION
Syntax | 616
Description | 618
Options | 618
Syntax
fallback-options {
}
fallback-block {
allow-email;
617
display-host;
}
}
virus-detection {
}
}
scan-options {
timeout value;
}
trickling {
timeout value;
}
}
Hierarchy Level

618
Description
Create a profile for the Kaspersky Lab engine. This profile includes all subsequent configuration options.
Options
Release Information
619
profile (Security Content Filtering)
IN THIS SECTION
Syntax | 619
Description | 620
Options | 620
Syntax
block-mime {
list list-name;
}
}
}
620
Hierarchy Level

[edit security utm feature-profile content-filtering]
Description
Create a profile for the content-filtering feature. This profile includes all subsequent configuration
options.
Options
Release Information

621
profile (Security Sophos Engine Antivirus)
IN THIS SECTION
Syntax | 621
Description | 622
Options | 622
Syntax
profile <name> {
fallback-options {
}
fallback-block {
allow-email;
display-host;
}
622
}
virus-detection {
}
}
scan-options {
timeout value;
}
trickling {
timeout value;
}
}
Hierarchy Level

Description
Create a profile for the Sophos antivirus engine. This profile includes all subsequent configuration
options.
Options

623
Release Information
profile
IN THIS SECTION
Syntax | 624
Description | 625
Options | 625

624
Syntax
profile <name> {
fallback-options {
}
mime-whitelist {
exception exception;
list list;
}
fallback-block {
allow-email;
display-host;
}
}
virus-detection {
}
}
url-whitelist url-whitelist;
}
625
Hierarchy Level

[edit security utm feature-profile anti-virus profile profile1]
Description
Create a profile for the Avira antivirus engine. The antivirus feature profile settings include the scanning
options, such as virus detection type, allowlist, blocklist, fallback and notification options.
Options
Release Information

626
profile (Security Web Filtering Juniper Enhanced)
IN THIS SECTION
Syntax | 626
Description | 627
Options | 627
Syntax
}
fallback-settings {
}
no-safe-search;
}
627
timeout value;
}
Hierarchy Level

Description
Create a profile for the juniper-enhanced feature. This profile includes all subsequent configuration
options.
Options
Release Information
628
profile (Security Web Filtering Juniper Local)
IN THIS SECTION
Syntax | 628
Description | 629
Options | 629
Syntax
fallback-settings {
}
timeout value;
}
629
Hierarchy Level

[edit security utm feature-profile web-filtering juniper-local]
Description
Create a profile for the web-filtering juniper–local feature. This profile includes all subsequent
configuration options.
Options
Release Information

630
profile (Security Web Filtering Surf Control

Integrated)
IN THIS SECTION
Syntax | 630
Description | 631
Options | 631
Syntax
}
fallback-settings {
}
timeout value;
}
631
Hierarchy Level

Description
Create a profile for the web-filtering surf-control-integrated feature. This profile includes all subsequent
Options
Release Information
The Surf-Control feature is not supported from Junos OS Release 15.1x49-D10 onwards. For previous

632
profile (Security Web Filtering Websense Redirect)
IN THIS SECTION
Syntax | 632
Description | 633
Options | 633
Syntax
account value;
fallback-settings {
}
server {
host host-name;
port number;
}
sockets value;
timeout value;
}
633
Hierarchy Level

[security utm feature-profile web-filtering websense-redirect]
Description
Create a profile for the web-filtering web-sense feature. This profile includes all subsequent
Options
Release Information

634
protocol-command
IN THIS SECTION
Syntax | 634
Description | 634
Options | 635
Syntax
value [value];
}
Hierarchy Level

Description
Different protocols use different commands to communicate between servers and clients. By blocking or
allowing certain commands, traffic can be controlled on the protocol command level.
635
Options
• object-name—Name of the command-list object.
• value value—Value of the command-list object. You can configure multiple values separated by spaces
and enclosed in square brackets.
Release Information
UTM Overview | 2
proxy (Security Antivirus)
IN THIS SECTION
Syntax | 636
Description | 636
Options | 636

636
Syntax
proxy {
port port-number;
username name;
}
Hierarchy Level

Description
Update the pattern file on the proxy server.
Options

637
Release Information
proxy-profile
IN THIS SECTION
Syntax | 637
Description | 638
Syntax
proxy-profile proxy profile name

638
Hierarchy Level
[set security utm default-configuration web-filtering juniper-enhanced server]

Description
Specify the proxy profile name and is used for configuring the explicit proxy.
services—To view this statement in the configuration.
services-control—To add this statement to the configuration.
Release Information
Statement introduced in Junos OS Release 18.3R1. Support.
quarantine-message (Security UTM)
IN THIS SECTION
Syntax | 639
Description | 639
Options | 639
639
Syntax
quarantine-message {
type {
}
url url;
}
Hierarchy Level

Description
Configure Juniper enhanced quarantine message settings.
Options
• type—Specify the following type of the quarantine message:
• custom-redirect-url—Specify Custom redirect URL server.
• url url—Specify an URL of the quarantine message.

640
Release Information
routing-instance (Security UTM)
IN THIS SECTION
Syntax | 640
Description | 641
Options | 641
Syntax
641
Hierarchy Level

[edit security utm feature-profile web-filtering juniper-enhanced server]
[edit security utm feature-profile web-filtering websense-redirect profile wr server]
[edit security utm feature-profile anti-virus sophos-engine server]
Description
Configure the routing instance name. A routing instance is a collection of routing tables, interfaces, and
routing protocol parameters. The set of interfaces belongs to the routing tables, and the routing protocol
parameters control the information in the routing tables. Each routing instance has a unique name.
Options
name Specify the name of the routing instance.
Release Information

642
admin-email | 368
sbl
IN THIS SECTION
Syntax | 642
Description | 643
Options | 643
Syntax
sbl {
}
}
643
Hierarchy Level

Description
Configure UTM server-based antispam features.
Options
Release Information
644
sbl-default-server
IN THIS SECTION
Syntax | 644
Description | 644
Syntax
sbl-default-server;
Hierarchy Level

Description
Enable the default SBL server lookup. You should enable this feature if you are using server-based spam
filtering. (The SBL server is predefined on the device. It ships with the name and address of the SBL
server.)
645
Release Information
scan-extension
IN THIS SECTION
Syntax | 645
Description | 646
Syntax
646
Hierarchy Level

options]
Description
For antivirus file extension scanning, configure the scan extension setting by specifying the name of the
defined file extension list.
Release Information
scan-mode
IN THIS SECTION
Syntax | 647

647
Description | 647
Options | 647
Syntax
Hierarchy Level

options]
Description
You can scan all content or scan content with specific file extensions. You can use a file extension list to
define a set of file extensions that are used in file extension scan mode. The antivirus module can then
only scan files with extensions on the scan-extension list.
Options
• all—Scan all files.
• by-extension—Scan only files with extensions specified in a file extension list custom object.
648
Release Information
The scan-mode is not supported from Junos OS Release 15.1X49-D10 onwards. For previous releases,
the statement introduced in Junos OS Release 9.5.

Release Description
15.1X49-D10 The scan-mode is not supported from Junos OS Release 15.1X49-D10 onwards.
scan-options (Security Antivirus Juniper Express

Engine)
IN THIS SECTION
Syntax | 649
Description | 649
Options | 649

649
Syntax
scan-options {
timeout value;
}
Hierarchy Level

Description
Configure the antivirus feature to scan specific types of traffic based on various scanning configuration
parameters.
Options

650
Release Information
The scan-options (Security Antivirus Juniper Express Engine) is not supported from Junos OS Release
15.1X49-D10 onwards. For previous releases, statement introduced in Junos OS Release 9.5.
Release Description
15.1X49-D10 The scan-options (Security Antivirus Juniper Express Engine) is not supported from Junos OS
Release 15.1X49-D10 onwards.
scan-options (Security Antivirus Kaspersky Lab

Engine)
IN THIS SECTION
Syntax | 650
Description | 651
Options | 651
Syntax
scan-options {
651

timeout value;
}
Hierarchy Level

Description
parameters.
Options
Release Information
The Kaspersky Antivirus feature is not supported from Junos OS Release 15.1X49-D10 onwards. For
652
Release Description
15.1X49-D10 The Kaspersky Antivirus feature is not supported from Junos OS Release 15.1X49-D10 onwards.
scan-options (Security Antivirus Sophos Engine)
IN THIS SECTION
Syntax | 652
Description | 653
Options | 653
Syntax
scan-options {
timeout value;
}
Hierarchy Level
[edit security utm default-configuration antivirus scan-options]

653
Description
parameters.
Options
Release Information
scan-options (Security Antivirus Avira Engine)
IN THIS SECTION
Syntax | 654
Description | 654
Options | 654

654
Syntax
scan-options {
(no-pre-detection | pre-detection);
timeout value;
}
Hierarchy Level

[edit antivirus scan-options]
Description
parameters. The scan engine scans the data by accessing the virus pattern database. You can download
and uninstall the Avira scan engine. The antivirus module is the software subsystem on the gateway
device that scans specific application layer traffic to protect the user from virus attacks and to prevent
virus from spreading. The antivirus module software subsystem consists of a virus signature database, an
application proxy, the scan manager, and the scan engine. The scan engine requires a valid license
Options

655
Release Information
decompress-layer-limit
content-size-limit
secondary-server
IN THIS SECTION
Syntax | 656
Description | 656
Options | 656

656
Syntax
secondary-server {
address ipv4-address;
login sender-email-address {
password password;
}
}
Hierarchy Level
[edit smtp]
Description
Configure Simple Mail Transfer Protocol (SMTP) secondary server for access authorization for SMTP
requests.
Options

657
Release Information
server (Security Antivirus)
IN THIS SECTION
Syntax | 657
Description | 658
Syntax
Hierarchy Level

658
Description
Set the IP address or URL for the proxy server.
Release Information
server (Security Sophos Engine Antivirus)
IN THIS SECTION
Syntax | 659
Description | 659
Options | 659

659
Syntax
server ip;
Hierarchy Level

Description
Set server parameters by entering the server IP address.
Options
ip Specify Sophos anitivirus and antispam first-hop DNS server IP address.
routing-instance name Specify the name of the routing instance.
Release Information

660
utm | 748
server (Security Web Filtering)
IN THIS SECTION
Syntax | 660
Description | 661
Options | 661
Syntax
server {
host host-name;
port number;
}
Hierarchy Level

661

Description
Set server parameters by entering the server name or IP address.
Options
Release Information
The surf-control feature is not supported from Junos OS Release 15.1X49-D10 onwards. For previous
Release Description
15.1X49-D10 The surf-control feature is not supported from Junos OS Release 15.1X49-D10 onwards.
662
server-connectivity
IN THIS SECTION
Syntax | 662
Description | 663
Options | 663
Syntax
Hierarchy Level

fallback-settings]
settings]
settings]
663
Description
Fallback settings tell the system how to handle errors. This is the action that occurs when a request fails
for this reason.
Options
Release Information

Release Description
15.1X49-D10 The surf-control feature is not supported from Junos OS Release 15.1X49-D10 onwards.
664
session-scan
IN THIS SECTION
Syntax | 664
Description | 664
Syntax
session-scan;
Hierarchy Level
[edit security dynamic-address address-name name]
Description
Session scan provides an efficient method to traverse the session table to check and update each
session. You can configure the session-scan option at two levels, entry level and module level. The entry
level session-scan requests session scan only when the configured entries have the new addresses, while
the module level takes all the entries belong to dynamic address into the scope. By default, the session-
scan for dynamic address are disabled due to the session scan is CPU intensive.
665
security
Release Information
hold-interval | 518
site-reputation-action
IN THIS SECTION
Syntax | 665
Description | 666
Options | 666
Syntax
666

}
Hierarchy Level

[edit security utm feature-profile web-filtering juniper-enhanced profile profile-name category
category-name]
Description
Specify the action to be taken depending on the site reputation returned for all types of URLs whether it
is categorized or uncategorized.
NOTE: Starting with Junos OS Release 17.4R1, the reputation base scores are configurable.
Users can apply global reputation values, provided by the Websense ThreatSeeker Cloud (TSC).
For the non-category URLs, the global reputation value is used to perform filtering,
Options
fairly-safe Permit, log-and-permit, block, or quarantine a request if a site-reputation of 70

through 79 is returned.
harmful Permit, log-and-permit, block, or quarantine a request if a site-reputation of zero

moderately-safe Permit, log-and-permit, block, or quarantine a request if a site-reputation of 80

suspicious Permit, log-and-permit, block, or quarantine a request if a site-reputation of 60

667
very-safe Permit, log-and-permit, block, or quarantine a request if a site-reputation of 90

Release Information
size (Security Web Filtering Cache)
IN THIS SECTION
Syntax | 668
Description | 668
Options | 668

668
Syntax
size value;
Hierarchy Level

[edit security utm feature-profile web-filtering surf-control-integrated cache]
[edit security utm feature-profile web-filtering juniper-enhanced cache]
Description
Set the cache size parameters for Web filtering.
Options
• Range: 0 through 4096 kilobytes.
Release Information

669
smtp-profile (Security UTM Policy Antispam)
IN THIS SECTION
Syntax | 669
Description | 669
Syntax
Hierarchy Level

[edit security utm utm-policy policy-name anti-spam]
Description
Configure a UTM policy for the antispam SMTP protocol and attach this policy to a security profile to
implement it.
670
Release Information
smtp-profile (Security UTM Policy Antivirus)
IN THIS SECTION
Syntax | 670
Description | 671
Syntax
671
Hierarchy Level

Description
Configure a UTM policy for the antivirus SMTP protocol and attach this policy to a security profile to
implement it.
Release Information
smtp-profile (Security UTM Policy Content Filtering)
IN THIS SECTION
Syntax | 672
Description | 672
672
Syntax
Hierarchy Level

Description
Configure a UTM policy for the content-filtering SMTP protocol and attach this policy to a security
Release Information
673
sockets
IN THIS SECTION
Syntax | 673
Description | 673
Syntax
sockets value;
Hierarchy Level

Description
Enter the number of sockets used for communicating between the client and server. The default is 1.

674
Release Information
sophos-engine
IN THIS SECTION
Syntax | 674
Description | 676
Options | 676
Syntax
sophos-engine {
pattern-update {
email-notify {
}
interval value;
no-autoupdate;
proxy {
675
port port-number;
username name;
}
url url;
}
profile <name> {
fallback-options {
}
fallback-block {
allow-email;
display-host;
}
}
virus-detection {
}
}
scan-options {
timeout value;
}
trickling {
676
timeout value;
}
}
sxl-retry value;
}
Hierarchy Level

Description
Configure the UTM Sophos antivirus feature.
Options
Release Information
677
source-address
IN THIS SECTION
Syntax | 677
Description | 677
Options | 678
Syntax
source-address address;
Hierarchy Level
[edit security utm default-configuration web-filtering juniper-enhanced server]

[edit security utm default-configuration web-filtering websense-redirect server]
[edit security utm default-configuration anti-virus sophos-engine server]
Description
You can configure source address for Enhanced Web Filtering (EWF) cloud service, websense redirect
policy service, antivirus scan service, and antispam scan service. Configuring a source address for these
Unified Threat Management (UTM) services enhance the network disaster recovery. Since the antivirus
678
and antispam scan services shares the same Domain Name Service (DNS) to forward the scan request,
they share the same source address configuration under Sophos antivirus engine server.
The source address configuration is optional. If you do not configure the source address, the UTM find
the route and get the source address.
Options
address Source address.
Release Information
spam-action
IN THIS SECTION
Syntax | 679
Description | 679
Options | 679

679
Syntax
Hierarchy Level

Description
Configure the action to be taken by the device when spam is detected.
Options
• block— Block e-mail.
• tag-header—Tag header of e-mail.
• tag-subject—Tag subject of e-mail.
Release Information

680

start-time
IN THIS SECTION
Syntax | 680
Description | 681
Options | 681
Syntax
Hierarchy Level

[edit security utm default-configuration anti-virus sophos-engine pattern-update]
681
Description
Specify the time that the device automatically starts downloading the updated signature database from
the specified URL.
Options
start-time—Time in MM-DD.hh:mm format.
Release Information
surf-control-integrated
IN THIS SECTION
Syntax | 682
Description | 683
Options | 683

682
Syntax
cache {
size value;
timeout value;
}
}
fallback-settings {
}
timeout value;
}
}
server {
host host-name;
port number;
}
}
Hierarchy Level

683
Description
Configure the UTM web-filtering integrated feature.
Options
Release Information
The surf-control- integrated feature is not supported from Junos OS Release 15.1X49-D10 onwards. For

Release Description
15.1X49-D10 The surf-control- integrated feature is not supported from Junos OS Release 15.1X49-D10
onwards.
684
sxl-retry
IN THIS SECTION
Syntax | 684
Description | 684
Options | 685
Syntax
sxl-retry value;
Hierarchy Level

Description
Configure the number of retry attempts to the remote Sophos Extensible List (SXL) server when a
request timeout occurs.
685
Options
value —Number of retries.
• Default: 1
Release Information
sxl-timeout
IN THIS SECTION
Syntax | 686
Description | 686
Options | 686

686
Syntax
Hierarchy Level

Description
Configure the timeout value for responses to a Sophos checksum or URI query.
Options
seconds —Number of seconds before timeout occurs.
• Range: 1 through 5 seconds
• Default: 2 seconds
Release Information

687
timeout (Security Antivirus Fallback Options)
IN THIS SECTION
Syntax | 687
Description | 688
Options | 688
Syntax
Hierarchy Level

fallback-options]
options]
688
Description
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 terminated and the content is either passed or
option. The default action is block.
Options
Release Information
Release Description
15.1X49-D10 The Express and Kaspersky Antivirus feature is not supported from Junos OS Release 15.1X49-
D10 onwards.
689
timeout (Security Antivirus Fallback Options Sophos

Engine)
IN THIS SECTION
Syntax | 689
Description | 689
Options | 690
Syntax
Hierarchy Level

options]
Description
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 terminated and the content is either passed or
690
option.
Options
Release Information
timeout (Security Antivirus Scan Options)
IN THIS SECTION
Syntax | 691
Description | 691

691
Syntax
timeout value;
Hierarchy Level

options]
options]
Description
The scanning timeout value includes the time frame from when the scan request is generated to when
the scan result is returned by the scan engine. The time range can be 1 to 1800 seconds. By default, it is
180 seconds.

692
Release Information

Release Description
D10 onwards.
timeout (Security Web Filtering)
IN THIS SECTION
Syntax | 692
Description | 693
Syntax
timeout value;
693
Hierarchy Level

Description
Enter a timeout limit for requests. Once this limit is reached, fail mode settings are applied. The default
here is 15 seconds.
Release Information
timeout (Security Web Filtering Cache)
IN THIS SECTION
Syntax | 694

694
Description | 694
Options | 694
Syntax
timeout value;
Hierarchy Level

[edit security utm feature-profile web-filtering surf-control-integrated cache]
[edit security utm feature-profile web-filtering juniper-enhanced cache]
Description
Set the cache timeout parameters for surf-control-integrated web filtering (24 hours is the default and
the maximum allowed life span of cached items).
Options
• Range: 1 through 1800 minutes.

695
Release Information
The surf-control-integrated feature is not supported from Junos OS Release 15.1X49-D10 onwards. For

Release Description
15.1X49-D10 The surf-control-integrated feature is not supported from Junos OS Release 15.1X49-D10
onwards.
timeout (Security Web Filtering Fallback Settings)
IN THIS SECTION
Syntax | 696
Description | 696
Options | 696

696
Syntax
Hierarchy Level

fallback-settings]
settings]
settings]
Description
Options

697
Release Information
Release Description
onwards.
too-many-requests (Security Antivirus Fallback

Options)
IN THIS SECTION
Syntax | 697
Description | 698
Options | 698
Syntax

698
Hierarchy Level

fallback-options]
options]
Description
If the total number of messages received concurrently exceeds 4000, the content is either passed or
blocked depending on the too-many-request fallback option. The default action is block. (The allowed
request limit is not configurable.)
Options
Release Information
699
Release Description
D10 onwards.
too-many-requests (Security Antivirus Fallback

Options Sophos Engine)
IN THIS SECTION
Syntax | 699
Description | 700
Options | 700
Syntax
Hierarchy Level

options]
700
Description
If the total number of messages received concurrently exceeds the device limits, the content is either
passed or blocked depending on the too-many-request fallback option. (The allowed request limit is not
configurable.)
Options
Release Information
701
too-many-requests (Security Web Filtering Fallback

Settings)
IN THIS SECTION
Syntax | 701
Description | 702
Options | 702
Syntax
Hierarchy Level

fallback-settings]
settings]
settings]
702
Description
If the total number of messages received concurrently exceeds the device limits, the content is either
passed or blocked depending on the too-many-request fallback option. The default action is BLOCK.
(The allowed request limit is not configurable.)
Options
Release Information

Release Description
onwards.
703
to-zone (Security Policies)
IN THIS SECTION
Syntax | 703
Description | 705
Options | 706
Syntax
to-zone zone-name {
policy policy-name {
match {
application {
[application];
any;
}
[address];
any;
any-ipv4;
any-ipv6;
}
source-address {
[address];
any;
any-ipv4;
any-ipv6;
}
source-identity {
[role-name];
704
any;
authenticated-user;
unauthenticated-user;
unknown-user;
}
}
then {
count {
alarm {
per-minute-threshold number;
per-second-threshold number;
}
}
deny;
log {
session-close;
session-init;
}
permit {
application-firewall {
}
}
gprs-gtp-profile profile-name;
gprs-sctp-profile profile-name;
idp;
redirect-wx | reverse-redirect-wx;
ssl-proxy {
}
uac-policy {
}
}
drop-translated;
drop-untranslated;
}
705
pass-through {
web-redirect;
}
}
}
services-offload;
tcp-options {
syn-check-required;
}
tunnel {
ipsec-group-vpn group-vpn;
ipsec-vpn vpn-name;
}
}
reject;
}
}
}
Hierarchy Level
[edit security policies from-zone zone-name]
Description
Specify a destination zone to be associated with the security policy.

706
Options
• zone-name—Name of the destination zone object.
• junos-host—Default security zone for self-traffic of the device.
Release Information
Statement introduced in Junos OS Release 8.5. Support for the services-offload and junos-host options
added in Junos OS Release 11.4. Support for the source-identity option added in Junos OS Release 12.1.
Support for the ssl-termination-profile and web-redirect-to-https options added in Junos OS Release
12.1X44-D10.

traceoptions (Security Antispam)
IN THIS SECTION
Syntax | 707
707
Description | 707
Options | 707
Syntax
Hierarchy Level

Description
Define tracing operations for UTM antispam features.
Options
• flag:
• all—Enable all antispam trace flags.
• manager —Trace antispam manager information.
• sbl—Trace SBL server information.

708
Release Information
traceoptions (Security Antivirus)
IN THIS SECTION
Syntax | 708
Description | 709
Options | 709
Syntax

709
Hierarchy Level

Description
Define tracing operations for UTM antivirus features.
Options
statements.
• all—Enable trace all antivirus trace options.
• basic—Trace antivirus module generic basic information.
• detail—Trace antivirus module generic detail information.
• engine—Trace scan engine information.
• event—Trace communication events between routing engine side processes.
• ipc—Trace communication events with Packet Forwarding Engine.
• manager—Trace antivirus manager process activities.
• pattern—Trace detail information of pattern loading.
• sendmail—Trace mail notifying process activities.
• statistics—Trace statistics information.
• updater—Trace pattern updater process activities.
• worker—Trace antivirus worker process activities.

710
trace—To view this statement in the configuration.
trace-control—To add this statement to the configuration.
Release Information
traceoptions (Security Application Proxy)
IN THIS SECTION
Syntax | 710
Description | 711
Options | 711
Syntax
traceoptions {
flag flag;
}
711
Hierarchy Level

[edit security utm application-proxy]
[edit logical-system logical-system-name security]
Description
Configure tracing options for application proxy.
Options
statements.
• abort—Trace terminated sessions for application proxy.
• all—Trace with all flags enabled.
• anti-virus—Trace anti-virus information.
• application-objects—Trace application-proxy objects information.
• basic—Trace application-proxy related basic information.
• buffer— Trace application-proxy data buffer information.
• connection-rating—Trace connection rating information.
• detail—Trace application-proxy related detailed information.
• express-anti-virus—Trace anti-virus express engine information.
• ftp-control—Trace FTP control connection information.
• ftp-data—Trace FTP data connection information.
• http—Trace HTTP protocol information.
• imap—Trace IMAP protocol information.

712
• memory—Trace memory usage.
• mime—Trace MIME parser information.
• parser— Trace protocol parser information.
• pfe—Trace communication with PFE.
• pop3—Trace POP3 protocol information.
• queue—Trace queue information.
• regex-engine—Trace Pattern Match Engine (PME) information.
• smtp—Trace SMTP protocol information.
• sophos-anti-virus—Trace anti-virus sophos engine information.
• tcp—Trace TCP level information.
• timer—Trace timer processing.
• utm-realtime—Trace application-proxy realtime-thread information
Release Information
The logical system option is introduced in Junos OS Release 18.3R1.

713
traceoptions (Security Content Filtering)
IN THIS SECTION
Syntax | 713
Description | 713
Options | 714
Syntax
Hierarchy Level

[edit security utm feature-profile content-filtering]
Description
Define tracing options for content filtering features.

714
Options
• flag:
• all—Enable all content filtering trace flags.
• basic —Trace content filtering basic information.
• detail—Trace content filtering detailed information.
Release Information
traceoptions (Security UTM)
IN THIS SECTION
Syntax | 715
Description | 715
Options | 715

715
Syntax
Hierarchy Level

[edit security utm]
Description
Define tracing operations for UTM features.
Options
statements.
• all—Enable trace for all UTM trace options.
• cli—Trace CLI configuration activity and command changes.
• daemon—Trace daemon information.
• ipc—Trace communication events with Packet Forwarding Engine (PFE).
• pfe—Trace PFE information.

716
Release Information
traceoptions (Security Web Filtering)
IN THIS SECTION
Syntax | 716
Description | 717
Options | 717
Syntax
Hierarchy Level

717
Description
Define tracing operations for individual Web filtering modules. To specify more than one tracing
operation, include multiple flag statements.
Options
• flag:
• all—Enable all Web filtering trace flags.
• basic —Trace basic information on the Web filtering module.
• cache—Enable Web filtering flags for the Web filtering cache maintained on the Web filtering
module.
• enhanced—Enable Web filtering flags for processing through Enhanced Web Filtering.
• heartbeat—Trace connectivity information with Web filter server.
• ipc—Trace Web filtering IPC messages.
• packet—Trace packet information from session management.
• profile—Trace profile configuration information.
• requests—Trace requests sent to Web filter server.
• response—Trace response received from Web filter server.
• session manager—Trace session management information.
• socket—Trace the communication socket with Web filter server.
• timer—Trace aging information for requests sent to server.

718
Release Information
Command introduced in Junos OS Release 10.1.
traceoptions (SMTP)
IN THIS SECTION
Syntax | 718
Description | 719
Options | 719
Syntax
traceoptions {
flag {
all;
configuration;
IPC;
protocol-exchange;
send-request;
}
}
719
Hierarchy Level
[edit smtp]
Description
Set the Simple Mail Transfer Protocol (SMTP) traceoptions.
Options
Release Information
utm | 748
720
traffic-options
IN THIS SECTION
Syntax | 720
Description | 721
Options | 721
Syntax
traffic-options {
limit value;
}
}
Hierarchy Level

721
Description
impose a session throttle.
Starting in Junos OS Release 18.2R1 , we've deprecated the traffic-options statement at the [edit security
utm utm-policy policy-name] hierarchy level.
Options
Release Information
trickling
IN THIS SECTION
Syntax | 722
Description | 722
722
Options | 723
Syntax
trickling {
timeout value;
}
Hierarchy Level

Description
transfer or during antivirus scanning. HTTP Trickling is time-based and there is only one parameter to
configure for this feature, which is the timeout Interval. By default, trickling is disabled.
WARNING: When you enable the trickling option, keep in mind that trickling might
send part of a file to the client during its antivirus scan. It is therefore possible that
some of the content could be received by the client before the file has been fully
scanned.
723
Options
value—Timeout interval in seconds.
• Range: 0 through 600 seconds
Release Information
onwards. For previous releases, statement introduced in Junos OS Release 9.5. Statement updated for
Sophos support in Junos OS Release 11.1.
Release Description
D10 onwards.
type (Security Antivirus Feature Profile)
IN THIS SECTION
Syntax | 724
Description | 724
724
Syntax
Hierarchy Level

Description
Set the antivirus engine that will be used on the device. You can only have one engine type running and
you must restart the device if you change engines.

725
Release Information
The Kaspersky Antivirus feature is not supported from Junos OS Release 15.1X49-D10 onwards. For
previous releases, statement introduced in Junos OS Release 9.5. Statement updated for Sophos in
Junos OS Release 11.1.
Release Description
15.1X49-D10 The Kaspersky Antivirus feature is not supported from Junos OS Release 15.1X49-D10 onwards.
type (Security Content Filtering Notification

Options)
IN THIS SECTION
Syntax | 725
Description | 726
Options | 726
Syntax

726
Hierarchy Level

Description
When content is blocked, the client generally still receives a successful response code but with modified
content (file replacement) containing a warning message. But with protocol-only notifications, a
protocol-specific error code might be returned to the client.
Options
• message—Send a generic notification.
• protocol-only—Send a protocol-specific notification.
Release Information
727
type (Security Fallback Block)
IN THIS SECTION
Syntax | 727
Description | 728
Options | 728
Syntax
Hierarchy Level

728
Description
You can configure notifications for both fallback blocking and fallback nonblocking actions. With
protocol-only notifications, a protocol-specific error code may be returned to the client.
Options
Release Information
engine added in Junos OS Release 11.1 .

Release Description
D10 onwards.
729
type (Security Virus Detection)
IN THIS SECTION
Syntax | 729
Description | 730
Options | 730
Syntax
Hierarchy Level

730
Description
When content is blocked because a virus is found or a scan error occurs, the client generally still
receives a successful response code but with modified content (file replacement) containing a warning
message. But with protocol-only notifications, a protocol-specific error code might be returned to the
client.
Options
Release Information

Release Description
D10 onwards.
731
type (Security Web Filtering)
IN THIS SECTION
Syntax | 731
Description | 731
Options | 732
Syntax
type (juniper-enhanced | juniper-local | surf-control-integrated | websense-redirect);
Hierarchy Level

Description
Define the type of Web filtering solution or URL filtering solution used by the device.
732
Options
• juniper-enhanced—Enable Enhanced Web Filtering on the device.
• juniper-local —Enable Juniper Networks local URL filtering on the device.
• surf-control-integrated—Enable integrated Web filtering on the device.
• websense-redirect—Redirect the URL to the Websense server.
Release Information
previous releases, command introduced in Junos OS Release 9.5.
Command introduced in Junos OS Release 11.4 .

Release Description
onwards.
733
upload-profile (Security Antivirus FTP)
IN THIS SECTION
Syntax | 733
Description | 733
Syntax
Hierarchy Level

[edit security utm utm-policy policy-name anti-virus ftp]
Description
Configure a UTM policy for the antivirus FTP (upload) protocol and attach this policy to a security profile
to implement it.

734
Release Information
upload-profile (Security Content Filtering FTP)
IN THIS SECTION
Syntax | 734
Description | 735
Syntax
Hierarchy Level

[edit security utm utm-policy policy-name content-filtering ftp]
735
Description
Configure a UTM policy for the content-filtering FTP (upload) protocol and attach this policy to a
security profile to implement it.
Release Information
uri-check
IN THIS SECTION
Syntax | 736
Description | 736

736
Syntax
uri-check;
Hierarchy Level
Description
Perform Sophos antivirus Uniform Resource Identifier (URI) checking. URI checking is a way of analyzing
URI content in HTTP traffic against a remote Sophos database to identify malware or malicious content.
URI checking is on by default.
NOTE: Starting in Junos OS release 18.4R1, the URI checking is off by default.
You can disable Sophos antivirus URI checking with the no-uri-check statement.
Release Information
737
url (Security Antivirus)
IN THIS SECTION
Syntax | 737
Description | 737
Syntax
url url;
Hierarchy Level

Description
Specify the URL for the pattern database. You should not change the default URL unless you are
experiencing problems with it and have called for support.
738
Release Information
Release Description
D10 onwards.
url-blacklist
IN THIS SECTION
Syntax | 739
Description | 739
Options | 739

739
Syntax
Hierarchy Level

Description
This is a global blocklist category, blocking content for Web filtering.
Options
Release Information
740
url-pattern
IN THIS SECTION
Syntax | 740
Description | 740
Options | 743
Syntax
value [value];
}
Hierarchy Level
Description
Use URL pattern lists to create custom URL category lists. These are lists of patterns that bypass
scanning.
741
Starting in Junos OS Release 20.4R1, the URL filtering supports the regular expression format given in
Table 8 on page 741.
Table 8: Regular Expression Format
Syntax Pattern Format Description Example
Asterisk (*) in Pattern = [*].sub- Asterisk should be at the head *.juniper.net

domain name domain..sub-domain only.
*.net
Match 0-N words in domain
name.
Caret (^) in domain Pattern = [^]..[^].sub- Caret could be at any place. ^.google.^.^
name domain.[^]..[^].sub-domain.
Match one word in domain a.^.b
[^]..[^]
name.
Question Mark (?) Pattern = sub-domain.sub- Question mark should be at the dev.local?
in domain name domain.sub-do[?][?] tail only.
www.yahoo.??
Match one character in domain
name.
All wildcard Pattern = *, or *.*, or *.*.* Special pattern. Same as pattern.
Match all URLs.
Prefix in URL path Pattern = <domain-name>/ Match the longest prefix in the <domain>/watch?
[prefix] URL path.
<domain>/news/
Keywords in URL Pattern = <domain-name>/ Match keywords in URL path. <domain>/pub/*/crypto/

path [prefix][*token][*token] *.gz
Support 0-3 tokens.
[*token]
<domain>/video?
*key1*key
742
The system validate the URL patterns when you commit the configuration. If you configure an invalid
pattern, the system shows a popup warning with the first bad character in (). For example, the pattern
a.*.com shows a warning message Pattern a.(*).com not supported.
Starting in Junos OS Release 20.4R1, we have introduced a golden match for multiple URL patterns.
When you configure multiple patterns for one domain, sometimes a specific URL could match multiple
patterns, then the URL filtering module selects the best out of these patterns, which is the golden
match. For the selection of the golden match, the URL filtering module prioritizes the URL pattern in the
following sequence:
1. Select the best domain name pattern to match.
2. Within the same domain name pattern, select the longest prefix match of the URL path.
3. Within the same domain name pattern and same URL path prefix, keyword match will take the
priority.
For example, if you configure the following four patterns:
1. Pattern 1 = finance.abc.com/gb/chinainternet/
2. Pattern 2 = finance.abc.^/gb/chinamkt/
3. Pattern 3 = finance.abc.^/gb/chinamkt/*.shtml
4. Pattern 4 = *.abc.com/gb/chinamkt/chinamkt_cn
For the URL https://finance.abc.com/gb/chinamkt/chinamkt_cn/sinacn/2020-03-29/doc-

ifzuwpay8845719.shtml, the golden match section will be as follows:
1. URL filtering module considers all the four patterns as a potential match in the domain name match
stage, and the priority order is:
finance.abc.com > finance.abc.^ > *.abc.com.
2. Within the same domain name pattern, the URL filtering module considers the longest prefix match
of the URL path.
• Pattern 1 does not match the URL path and the URL filtering module skips pattern 1.
• Pattern 2 and pattern 3 have the same prefix in the URL path. Hence, the keywords match
controls the golden match selection. Finally, the URL filtering module prefers pattern 3 that has
the longest keywords match as the golden match.
743
Options
• object-name—Name of the URL list object.
• value value—Value of the URL list object. You can configure multiple values separated by spaces and
enclosed in square brackets.
Release Information
Security Policies User Guide for Security Devices
url-whitelist
IN THIS SECTION
Syntax | 744
Description | 744

744
Syntax
Hierarchy Level

Description
A URL allowlist is a unique custom list that you define in which all the URLs or IP addresses in that list
for a specified category are always bypassed for scanning.
Release Information
745
url-whitelist
IN THIS SECTION
Syntax | 745
Description | 745
Options | 746
Syntax
Hierarchy Level

Description
A URL allowlist is a unique custom list that you define in which all the URLs or IP addresses in that list
for a specified category are always bypassed for filtering
746
Options
Release Information
username (Security Antivirus)
IN THIS SECTION
Syntax | 746
Description | 747
Syntax
username name;
747
Hierarchy Level

Description
Set the username for the proxy server.
Release Information

Release Description
D10 onwards.
748
utm
IN THIS SECTION
Syntax | 748
Description | 758
Options | 759
Syntax
utm {
application-proxy {
traceoptions {
flag flag;
}
}
custom-objects {
value [value];
}
value [value];
}
value [value];
}
value [value];
}
value [value];
}
749
}
feature-profile {
anti-spam {
sbl {
}
}
traceoptions {
flag flag;
}
}
anti-virus {
pattern-update {
email-notify {
}
interval value;
no-autoupdate;
proxy {
port port-number;
username name;
}
url url;
}
fallback-options {
}
750
fallback-block {
allow-email;
display-host;
}
}
virus-detection {
}
}
scan-options {
timeout value;
}
trickling {
timeout value;
}
}
}
pattern-update {
email-notify {
}
interval value;
no-autoupdate;
proxy {
751
port port-number;
username name;
}
url url;
}
fallback-options {
}
fallback-block {
allow-email;
display-host;
}
}
virus-detection {
}
}
scan-options {
752
timeout value;
}
trickling {
timeout value;
}
}
}
mime-whitelist {
exception listname;
list listname {
exception listname;
}
}
sophos-engine {
pattern-update {
email-notify {
}
interval value;
no-autoupdate;
proxy {
port port-number;
username name;
}
url url;
}
profile <name> {
fallback-options {
}
753
fallback-block {
allow-email;
display-host;
}
}
virus-detection {
}
}
scan-options {
timeout value;
}
trickling {
timeout value;
}
}
sxl-retry value;
}
traceoptions {
flag flag;
}
}
content-filtering {
754
block-mime {
list list-name;
}
}
}
traceoptions {
flag flag;
}
}
web-filtering {
juniper-enhanced {
cache {
size value;
timeout value;
}
block-message {
type {
}
url url;
}
type {
}
url url;
}
}
fallback-settings {
755

}
no-safe-search;
very-safe (block | log-and-permit | permit |quarantine);
}
timeout value;
}
server {
host host-name;
port number;
}
}
juniper-local {
fallback-settings {
}
timeout value;
}
}
cache {
size value;
timeout value;
}
}
756
fallback-settings {
}
timeout value;
}
server {
host host-name;
port number;
}
}
traceoptions {
flag flag;
}
type (juniper-enhanced | juniper-local | surf-control-integrated | websense-
redirect);
websense-redirect {
account value;
fallback-settings {
}
server {
host host-name;
port number;
}
sockets value;
timeout value;
}
}
}
}
ipc {
}
757
traceoptions {
flag flag;
}
utm-policy policy-name {
anti-spam {
}
anti-virus {
ftp {
}
}
content-filtering {
ftp {
}
rule-set rule-set-name {
rule rule-name {
match {
file-type exe; /*predetected file types*/
}
then {
action {
}
notification {
seclog; /* event logging */
758
type protocol-only;
notify-mail-sender;
}
}
}
}
}
}
}
}
traffic-options {
limit value;
}
}
web-filtering {
}
}
}
Hierarchy Level

[edit security]
Description
Configure UTM features.

759
Options
Release Information
the file extensions. So, content filtering options based on mime-type, content-type, and protocol
command is not supported. After you upgrade to Junos OS Release 21.4R1 above listed options are no
more available for configuration. The rule-set and rules configurations are introduced under the [edit
security utm utm-policy <utm-policy-name> content-filtering] hierarchy level. These rules and rule-set allows
you to configure direction specific content filters and connection reset.
The Kaspersky, surf-control-integrated, and express antivirus features are not supported from Junos OS
Release 15.1X49-D10 onwards. For previous releases, statement introduced in Junos OS Release 9.5 .
Release Description
15.1X49-D10 The Kaspersky, surf-control-integrated, and express antivirus features are not supported from
Junos OS Release 15.1X49-D10 onwards.
760
default-configuration
IN THIS SECTION
Syntax | 760
Description | 766
Options | 766
Syntax
utm {
anti-spam {
address-blacklist;
address-whitelist;
sbl {
custom-tag-string;
}
traceoptions {
flag name;
}
type (anti-spam-none | sbl);
}
anti-virus {
mime-whitelist {
exception;
list;
}
sophos-engine {
fallback-options {
761

}
forwarding-mode {
hold;
inline-tap;
}
fallback-block {
custom-message;
}
custom-message;
}
virus-detection {
custom-message;
}
}
pattern-update {
email-notify {
admin-email;
custom-message;
}
interval;
no-autoupdate;
proxy {
password;
port;
server;
username;
762
}
routing-instance;
url;
}
scan-options {
content-size-limit;
timeout seconds;
(uri-check | no-uri-check);
}
server {
ip;
routing-instance;
}
sxl-retry;
trickling timeout;
}
traceoptions {
flag name;
}
url-whitelist;
}
content-filtering {
block-command;
activex;
exe;
http-cookie;
java-applet;
zip;
}
block-extension;
block-mime {
exception;
list;
}
custom-message;
seclog; /* New event logging global setting */
} permit-command;
traceoptions {
763
flag name;
}
rule-set rule-set-name { /* New provision to add to default rules */
rule rule-name {
}
}
type (content-filtering-none | local);
}
web-filtering {
http-persist;
http-reassemble;
juniper-enhanced {
base-filter;
block-message {
url;
}
cache {
size kilobytes;
timeout minutes;
}
category name {
custom-message;
}
custom-block-message;
fallback-settings {
}
no-safe-search;
quarantine-custom-message;
url;
}
reputation {
reputation-fairly-safe;
reputation-moderately-safe;
reputation-suspicious;
764
reputation-very-safe;
}
server {
host;
port;
routing-instance;
}
}
timeout seconds;
}
juniper-local {
block-message {
url;
}
category name {
custom-message;
}
fallback-settings {
}
url;
}
timeout seconds;
}
traceoptions {
flag name;
}
765
url-blacklist;
url-whitelist;
websense-redirect {
account;
block-message {
url;
}
category name {
custom-message;
}
fallback-settings {
}
url;
}
server {
host;
port;
routing-instance;
}
sockets;
timeout seconds;
}
}
}
application-proxy;
custom-objects;
feature-profile;
traceoptions;
utm-policy junos-default-utm-policy;
}
}
766
Hierarchy Level
[edit security utm]
Description
The UTM default configuration is used in two scenarios.
• UTM default configuration for unified policies—For security policies that enable UTM with no
custom UTM policy defined, the default UTM policy will be used.
• UTM default configuration for existing UTM policies—For existing security policies that have a UTM
policy enabled, the default UTM policy will NOT be used.
Options
default-configuration Global default UTM configurations.
anti-spam Configure the default UTM configuration for antispam feature profile.
anti-virus Configure the default UTM configuration for antivirus feature profile.
content-filtering Configure the default UTM configuration for content filtering feature profile.
web-filtering Configure the default UTM configuration for Web filtering feature profile.
utm-policy Configure a UTM policy for antivirus, antispam, content filtering, traffic options,
and Web filtering protocols and attach this policy to a security profile to implement
it.
traceoptions Define tracing operations for UTM features.
feature-profile Configure UTM features, antivirus, antispam, content filtering, and Web filtering by
creating feature profiles.
application-proxy Application proxy settings.

767
custom-objects Configure custom objects before configuring UTM feature-profile features. Custom
category does not take precedence over predefined categories when it has the
same name as one of the predefined categories. It is not recommended to have a
custom category name be the same as the predefined category name.
Release Information
Starting in Junos OS Release 21.4R1, the rule-set and rules configurations introduced under the [edit
security utm utm-policy <utm-policy-name> content-filtering] hierarchy level can be used from [edit security
utm default-configuration content-filtering hierarchy.
Content filtering options based on mime-type, content-type, and protocol command is not supported.
After you upgrade to Junos OS Release 21.4R1, previously existing file extension based content filtering
options under the [edit security utm utm-policy <utm-policy-name> content-filtering] hierarchy are no more
available for configuration.
Junos OS Release 21.4R1 allows you to use legacy functionality if you don’t want to migrate to this
modern functionality. You will be allowed to use the legacy configurations but all the legacy
configuration knobs are deprecated and are hidden. Also, you will receive system logs and error message
warnings when you use all the legacy deprecated knobs.

768
utm-policy
IN THIS SECTION
Syntax | 768
Description | 770
Options | 770
Syntax
utm-policy policy-name {
anti-spam {
}
anti-virus {
ftp {
}
}
content-filtering {
ftp {
}
769
rule-set rule-set-name {
rule rule-name {
match {
file-type exe; /*predetect magic supported file types*/
}
then {
action {
}
notification {
seclog; /* event logging */
type protocol-only;
notify-mail-sender;
}
}
traffic-options {
limit value;
}
}
web-filtering {
}
}
Hierarchy Level

[edit security utm]
770
Description
Configure a UTM policy for antivirus, antispam, content-filtering, traffic-options, and Web-filtering
protocols and attach this policy to a security profile to implement it.
Options
policy-name—Specify name of the UTM policy.
Release Information

771
utm-policy (Application Services)
IN THIS SECTION
Syntax | 771
Description | 771
Options | 772
Syntax
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name then permit
application-services]
Description
Configure a UTM policy for application services and attach this policy to a security profile to implement
it.
772
Options
policy-name—Specify the name of the UTM policy.
Release Information
virus-detection (Security Antivirus)
IN THIS SECTION
Syntax | 772
Description | 773
Options | 773
Syntax
virus-detection {
773
}
Hierarchy Level

options]
Description
Configure a notification to send when a virus is detected.
Options

774
Release Information
The Express and Kaspersky Antivirus features are not supported from Junos OS Release 15.1X49-D10
Release Description
15.1X49-D10 The Express and Kaspersky Antivirus features are not supported from Junos OS Release 15.1X49-
D10 onwards.
web-filtering
IN THIS SECTION
Syntax | 774
Description | 777
Options | 778
Syntax
web-filtering {
http-persist;
http-reassemble;
juniper-enhanced {
base-filter;
block-message {
775
url;
}
cache {
size kilobytes;
timeout minutes;
}
category name {
custom-message;
}
fallback-settings {
}
no-safe-search;
url;
}
reputation {
reputation-fairly-safe;
reputation-moderately-safe;
reputation-suspicious;
reputation-very-safe;
}
server {
host;
port;
routing-instance;
}
}
776
timeout seconds;
}
juniper-local {
block-message {
url;
}
category name {
custom-message;
}
fallback-settings {
}
url;
}
timeout seconds;
}
performance-mode;
traceoptions {
flag name;
}
url-blacklist;
url-whitelist;
websense-redirect {
account;
block-message {
url;
}
category name {
custom-message;
}
777
fallback-settings {
}
url;
}
server {
host;
port;
routing-instance;
}
sockets;
timeout seconds;
}
}
Hierarchy Level

Description
Configure UTM web filtering features. You can also configure the default UTM configuration for web
filtering feature profile. If you do not configure any option in the web filtering feature profile, the values
configured in the default UTM configuration are applied. The default UTM Web filtering configuration
for HTTP is also applicable for the HTTPS sessions. Web filtering feature’s potential policies conflict
check is independent of the content filtering, antivirus, and antispam features.
778
Options
http-persist Check all HTTP request in a connection. If http-persist option is enabled for clear
text HTTP traffic, then Web filtering checks every HTTP request packet in the same
session.
http-reassemble Reassemble HTTP request segments. If http-reassemble option is enabled for clear
text HTTP traffic, then Enhanced Web Filtering (EWF) reassembles the fragmented
HTTP request to avoid evasion instead of packet-based inspection.
juniper-enhanced Enable enhanced Web filtering on the device.
base-filter A base filter is an object that contains a category-action pair for all categories
defined in the category file.
block-message Juniper enhanced block message settings.
cache Set the cache parameters for Surf-Control-Integrated Web filtering and Enhanced
Web Filtering.
category Select a custom URL category list you created (custom objects) for filtering against.
custom-block-message Enter a custom message to be sent when HTTP requests are blocked.
default Specify an action for the profile, for requests that experience internal errors in the
Web filtering module.
fallback-settings Fallback settings tell the system how to handle errors.
no-safe-search Do not perform safe-search for Juniper enhanced protocol. Safe-search redirect
supports HTTP only. Therefore it is not possible to generate a redirect response for
HTTPS search URLs. Safe-search redirects can be disabled by using the CLI option
no-safe-search.
quarantine-custom- Juniper enhanced quarantine custom message.

message
quarantine-message Juniper enhanced quarantine message settings.
reputation Customize reputation level. The ThreatSeeker Cloud (TSC) provides site reputation
information. Based on these reputations, you can choose a block or a permit action.
server Set server parameters by entering the server name or IP address.

779
site-reputation- Specify the action to be taken depending on the site reputation returned for all
action types of URLs whether it is categorized or uncategorized.
timeout Enter a timeout limit for requests. Once this limit is reached, fail mode settings are
applied.
juniper-local Enable Juniper Networks local URL filtering on the device.
block-message Juniper local block message settings.
traceoptions Trace options for Web filtering feature.
url-blacklist This is a global blocklist category, blocking content for Web filtering.
url-whitelist A URL allowlist is a unique custom list that you define in which all the URLs or IP
addresses in that list for a specified category are always bypassed for filtering.
websense-redirect Web filtering websense redirect engine. Websense occasionally releases new EWF
categories. EWF classifies websites into categories according to host, URL, or IP
address and performs filtering based on the categories.
type Type of Web filtering solution or URL filtering solution used by the device.
performance-mode Improves the performance by only analyzing the traffic requests on ports 80 and
443.
Release Information
780
The [edit security utm default-configuration] hierarchy level introduced in Junos OS Release 18.2R1.
The performance-mode statement introduced in Junos OS Release 22.2R1.

web-filtering (Security UTM Policy)
IN THIS SECTION
Syntax | 780
Description | 781
Syntax
web-filtering {
http-profile http-profile;
}
Hierarchy Level

781

Description
Configures a UTM policy for the Web filtering protocols and attach this policy to a security profile to
implement it. Web filtering allows you to manage Internet usage by preventing access to inappropriate
Web content.
Release Information
Support in default configuration introduced in Junos OS Release 18.2R1.

782
websense-redirect
IN THIS SECTION
Syntax | 782
Description | 783
Options | 783
Syntax
websense-redirect {
account value;
fallback-settings {
}
server {
host host-name;
port number;
}
sockets value;
timeout value;
no-safe-search;
}
}
783
Hierarchy Level

Description
Configure the Websense redirect engine features.
categories.
The new categories do not affect the existing configurations. You can modify the existing configurations
to make use of the new categories.
Options
no-safe-search Disable the safe search function.
Release Information
784
no-safe-search option added in Junos OS Release 20.2R1.
8 CHAPTER
Operational Commands
request security utm anti-virus sophos-engine | 805
request security utm anti-virus avira-engine | 807
request security utm web-filtering custom-page reload | 816
show configuration smtp | 818
show groups junos-defaults | 820
show security log | 822
show security policies | 826

show security utm web-filtering category category | 884
test security utm anti-spam | 898
test security utm enhanced-web-filtering url-check | 903
test security utm web-filtering profile | 907

787
clear security utm anti-spam statistics
IN THIS SECTION
Syntax | 787
Description | 787
Options | 788
Sample Output | 788
Syntax

<root-logical-system>
<logical-system (logical-system-name | all)>
<all-logical-systems-tenants>
<tenant (tenant-name | all)>
Description
Clears antispam statistics information. With chassis cluster support for UTM, statistics from both the
nodes is cleared.
Starting in Junos OS Release 18.3R1, you can clear the antispam statistics information for the primary
logical system or for a specific user logical system or for all the user logical systems.
Starting in Junos OS Release 19.2R1, you can clear the antispam statistics information for a specific
tenant system or for all the tenant systems.
788
Options
none Clears the antispam statistics information for the primary logical system.
root-logical-system (Optional) Clears the antispam statistics information for the primary logical system.
logical-system logical- (Optional) Clears the antispam statistics information for a specific user
system-name logical system.
all (Optional) Clears the antispam statistics information for all the user logical systems.
all-logical-systems- (Optional) Clears the antispam statistics information for all the logical
tenants systems and tenant systems.
tenant tenant-name (Optional) Clears the antispam statistics information for a specific tenant system.
all (Optional) Clears the antispam statistics information for all the tenant systems.
clear
Sample Output
user@host> clear security utm anti-spam statistics

Anti-spam clear statistics result: clear done
clear security utm anti-spam statistics root-logical-system
user@host> clear security utm anti-spam statistics root-logical-system

789
clear security utm anti-spam statistics logical-system LSYS1
user@host> clear security utm anti-spam statistics logical-system LSYS1

clear security utm anti-spam statistics logical-system all
user@host> clear security utm anti-spam statistics logical-system all

clear security utm anti-spam statistics tenant TSYS1
user@host> clear security utm anti-spam statistics tenant TSYS1

clear security utm anti-spam statistics tenant all
user@host> clear security utm anti-spam statistics tenant all

clear security utm anti-spam statistics all-logical-systems-tenants
user@host> clear security utm anti-spam statistics all-logical-systems-tenants

Release Information
Support for UTM in chassis cluster added in Junos OS Release 11.4.
Support for UTM in logical system added in Junos OS Release 18.3R1.
Support for UTM in tenant system added in Junos OS Release 19.2R1.

790

clear security utm antivirus statistics
IN THIS SECTION
Syntax | 790
Description | 790
Options | 791
Sample Output | 791
Syntax
clear security utm anti-virus statistics

Description
Clears antivirus statistics information. With chassis cluster support for UTM, statistics from both the
nodes are cleared.
Starting in Junos OS Release 18.3R1, you can clear the antivirus statistics information for the primary
logical system or for a specific user logical system or for all the user logical systems.
791
Starting in Junos OS Release 19.2R1, you can clear the antivirus statistics information for a specific
Options
none Clears the antivirus statistics information for the primary logical system.
root-logical-system (Optional) Clears the antivirus statistics information for the primary logical system.
logical-system logical- (Optional) Clears the antivirus statistics information for a specific user
all (Optional) Clears the antivirus statistics information for all the user logical systems.
all-logical-systems- (Optional) Clears the antivirus statistics information for all the logical systems
tenants and tenant systems.
tenant tenant-name (Optional) Clears the antivirus statistics information for a specific tenant system.
all (Optional) Clears the antivirus statistics information for all the tenant systems.
clear
Sample Output
clear security utm anti-virus statistics
user@host> clear security utm anti-virus statistics

Anti-virus clear statistics result: clear done
792
clear security utm anti-virus statistics root-logical-system
user@host> clear security utm anti-virus statistics root-logical-system

clear security utm anti-virus statistics logical-system LSYS1
user@host> clear security utm anti-virus statistics logical-system LSYS1

clear security utm anti-virus statistics logical-system all
user@host> clear security utm anti-virus statistics logical-system all

clear security utm anti-virus statistics tenant TSYS1
user@host> clear security utm anti-virus statistics tenant TSYS1

clear security utm anti-virus statistics tenant all
user@host> clear security utm anti-virus statistics tenant all

clear security utm anti-virus statistics all-logical-systems-tenants
user@host> clear security utm anti-virus statistics all-logical-systems-tenants

793
Release Information
Support for Sophos Antivirus added in Junos OS Release 11.1.

clear security utm content-filtering statistics
IN THIS SECTION
Syntax | 794
Description | 794
Options | 794
Sample Output | 795

794
Syntax

Description
Clears content-filtering statistics information. With chassis cluster support for UTM, statistics from both
the nodes are cleared.
Starting in Junos OS Release 18.3R1, you can clear the content filtering statistics information for the
primary logical system or for a specific user logical system or for all the user logical systems.
Starting in Junos OS Release 19.2R1, you can clear the content filtering statistics information for a
specific tenant system or for all the tenant systems.
Options
none Clears the content filtering statistics information for the primary logical system.
root-logical- (Optional) Clears the content filtering statistics information for the primary logical
system system.
logical-system logical- (Optional) Clears the content filtering statistics information for a specific
system-name user logical system.
all (Optional) Clears the content filtering statistics information for all the user logical systems.
all-logical-systems- (Optional) Clears the content filtering statistics information for all the logical
tenant tenant-name (Optional) Clears the content filtering statistics information for a specific tenant
system.
795
all (Optional) Clears the content filtering statistics information for all the tenant systems.
clear
Sample Output
user@host> clear security utm content-filtering statistics

Content-filtering clear statistics result: clear done
clear security utm content-filtering statistics root-logical-system
user@host> clear security utm content-filtering statistics root-logical-system

clear security utm content-filtering statistics logical-system LSYS1
user@host> clear security utm content-filtering statistics logical-system LSYS1

clear security utm content-filtering statistics logical-system all
user@host> clear security utm content-filtering statistics logical-system all

796
clear security utm content-filtering statistics tenant TSYS1
user@host> clear security utm content-filtering statistics tenant TSYS1

clear security utm content-filtering statistics tenant all
user@host> clear security utm content-filtering statistics tenant all

clear security utm content-filtering statistics all-logical-systems-tenants
user@host> clear security utm content-filtering statistics all-logical-systems-tenants

Release Information

797
clear security utm session
IN THIS SECTION
Syntax | 797
Description | 797
Output Fields | 797
Syntax
clear security utm session
Description
Clear UTM session information. With chassis cluster support for UTM, sessions on both the nodes are
cleared.
clear
Output Fields
This command produces no output.

798
Release Information

clear security utm web-filtering statistics
IN THIS SECTION
Syntax | 798
Description | 799
Options | 799
Sample Output | 800
Syntax

799
Description
Clear web filtering statistics information. With chassis cluster support for UTM, statistics from both the
nodes is cleared.
Starting in Junos OS Release 18.3R1, you can clear the Web filtering statistics information for the
primary logical system or for a specific user logical system or for all the user logical systems.
Starting in Junos OS Release 19.2R1, you can clear the Web filtering statistics information for a specific
Options
none Clears the Web filtering statistics information for the primary logical system.
root-logical- (Optional) Clears the Web filtering statistics information for the primary logical
system system.
logical-system logical- (Optional) Clears the Web filtering statistics information for a specific user
all (Optional) Clears the Web filtering statistics information for all the user logical systems.
all-logical-systems- (Optional) Clears the Web filtering statistics information for all the logical
tenant tenant-name (Optional) Clears the Web filtering statistics information for a specific tenant
system.
all (Optional) Clears the Web filtering statistics information for all the tenant systems.
clear
800
Sample Output
user@host> clear security utm web-filtering statistics

Web-filtering clear statistics result: clear done
clear security utm web-filtering statistics root-logical-system
user@host> clear security utm web-filtering statistics root-logical-system

clear security utm web-filtering statistics logical-system LSYS1
user@host> clear security utm web-filtering statistics logical-system LSYS1

clear security utm web-filtering statistics logical-system all
user@host> clear security utm web-filtering statistics logical-system all

clear security utm web-filtering statistics tenant TSYS1
user@host> clear security utm web-filtering statistics tenant TSYS1

clear security utm web-filtering statistics tenant all
user@host> clear security utm web-filtering statistics tenant all

801
clear security utm web-filtering statistics all-logical-systems-tenants
user@host> clear security utm web-filtering statistics all-logical-systems-tenants

Release Information
Support for UTM in chassis cluster added in Junos OS Release 11.4 .

request security utm anti-virus juniper-express-

engine
IN THIS SECTION
Syntax | 802
Description | 802
Options | 802
Output Fields | 802
Sample Output | 803

802
Syntax
request security utm anti-virus juniper-express-engine
Description
previous releases, manually update the express antivirus pattern database using the command
described. You can update the express antivirus pattern database automatically or manually. With full
chassis cluster support for UTM this command is operational on both the nodes.
Options
• pattern-delete — Delete the current express antivirus pattern database.
• pattern-reload — Reload the express antivirus pattern database.
• pattern-update — Update the express antivirus pattern database with the latest signatures.
maintenance
Output Fields
request security utm anti-virus juniper-express-engine pattern-update
When you enter this command, you are provided feedback on the status of your request.
803
Sample Output
request security utm anti-virus juniper-express-engine pattern-update
user@host> request security utm anti-virus juniper-express-engine pattern-update
Release Information
previous releases, command introduced in Junos OS Release 9.5.

request security utm anti-virus kaspersky-lab-

engine
IN THIS SECTION
Syntax | 804
Description | 804
Options | 804
Output Fields | 804
Sample Output | 805

804
Syntax
request security utm anti-virus kaspersky-lab-engine
Description
The Kaspersky Antivirus feature is not supported from Junos OS Release 15.1x49-D10 onwards.For
previous releases, manually update the full file-based antivirus pattern database using the commands
described. You can update the full file-based antivirus pattern database automatically or manually. With
full chassis cluster support for UTM this command is operational on both the nodes.
Options
• pattern-delete — Delete the current full file-based antivirus pattern database.
• pattern-reload — Reload the full file-based antivirus pattern database.
• pattern-update — Update the full file-based antivirus pattern database with the latest signatures.
maintenance
Output Fields
request security utm anti-virus kaspersky-lab-engine pattern-update
805
Sample Output
request security utm anti-virus kaspersky-lab-engine pattern-update
user@host> request security anti-virus kaspersky-lab-engine pattern-update
Release Information

request security utm anti-virus sophos-engine
IN THIS SECTION
Syntax | 806
Description | 806
Options | 806
Output Fields | 806
Sample Output | 807

806
Syntax
request security utm anti-virus sophos-engine
Description
Manually update the Sophos antivirus pattern database using the command described. To update
automatically you use the configuration statement set security utm feature-profile anti-virus sophos-engine
pattern-update interval seconds. With full chassis cluster support for UTM this command is operational on
both the nodes.
Options
• pattern-delete — Delete the current Sophos antivirus pattern database.
• pattern-reload — Reload the Sophos antivirus pattern database.
• pattern-update — Update the Sophos antivirus pattern database with the latest signatures.
maintenance
Output Fields
request security utm anti-virus sophos-engine pattern-update
807
Sample Output
request security utm anti-virus sophos-engine pattern-update
user@host> request security utm anti-virus sophos-engine pattern-update
Release Information

request security utm anti-virus avira-engine
IN THIS SECTION
Syntax | 808
Description | 808
Options | 808
Output Fields | 809
Sample Output | 809
Sample Output | 809
Sample Output | 809

808
Sample Output | 810
Syntax
request security utm anti-virus avira-engine
Description
Manually update the Avira antivirus pattern database using the command described. To update
automatically you use the configuration statement set security utm default-configuration anti-virus avira-
engine pattern-update interval seconds. Avira is an internal scan engine that provides a full file-based
anitvirus scanning feature. The full file-based antivirus scanning feature is a separately licensed
subscription service. The Avira scan engine is provided as a downloadable UTM module. You can
download and install virus signature database.
Options
• pattern-delete — Delete the current Avira antivirus pattern database.
• pattern-local-update — Update the Avira antivirus pattern database from local folder.
• pattern-reload — Reload the Avira antivirus pattern database.
• pattern-update — Update the Avira antivirus pattern database with the latest signatures.
maintenance
809
Output Fields
request security utm anti-virus avira-engine pattern-delete
Sample Output
request security utm anti-virus avira-engine pattern-delete
user@host> request security utm anti-virus avira-engine pattern-delete

Anti-virus update request results:
Anti-virus update request results: Starting to delete avira files.
Sample Output
request security utm anti-virus avira-engine pattern-local-update <path>
user@host> request security utm anti-virus avira-engine pattern-local-update from </var/tmp/

db_0531>
av_mgr: pattern updater 30445 is started, updating from /var/tmp/db_0531
Sample Output
request security utm anti-virus avira-engine pattern-reload
user@host> request security utm anti-virus avira-engine pattern-reload

Reloading good database starts ...
810
Sample Output
request security utm anti-virus avira-engine pattern-update
user@host> request security utm anti-virus avira-engine pattern-update

av_mgr: pattern updater 44934 is started, downloading from https://update.juniper-updates.net/
avira.
Release Information
Command introduced in Junos OS Release 18.4R1.

request security utm web-filtering category install
IN THIS SECTION
Syntax | 811
Description | 811
Sample Output | 811

811
Syntax
Description
Install the predefined category and predefined filter on the system. Users could check the category or
filter using the following command: show security utm web-filtering category base-filter.
NOTE: During new category file installation, if the category filename is changed, then the new
category file overwrites the old category file in the internal system and all related output
information is replaced with the new category name.
maintenance
Sample Output
user@host> request security utm web-filtering category install

Category updater result: install done
Release Information

812

request security utm web-filtering category uninstall
IN THIS SECTION
Syntax | 812
Description | 812
Sample Output | 813
Syntax
Description
Reset the predefined category and the base filters to the factory default. This option helps for category
rollback.
maintenance
813
Sample Output
user@host> request security utm web-filtering category uninstall

Category updater result: Uninstall done
Release Information

request security utm web-filtering category

download-install [version]
IN THIS SECTION
Syntax | 814
Description | 814
Sample Output | 814

814
Syntax
request security utm web-filtering category download-install version;
Description
Download and install the category file, if no version is specified, the latest version is downloaded and
installed during category upgrade.
maintenance
Sample Output
request security utm web-filtering category download-install version 5
user@host> request security utm web-filtering category download-install version 5

Category updater result: Download scheduled
Release Information

815
request security utm web-filtering category

download [version]
IN THIS SECTION
Syntax | 815
Description | 815
Sample Output | 816
Syntax
request security utm web-filtering category download version;
Description
Download the category file, if no version is specified, the latest version of the category file is
downloaded during category upgrade.
maintenance
816
Sample Output
request security utm web-filtering category download version 3
user@host> request security utm web-filtering category download version 3

Category updater result: Download done
Release Information

request security utm web-filtering custom-page

reload
IN THIS SECTION
Syntax | 817
Description | 817
Sample Output | 817

817
Syntax
request security utm web-filtering custom-page reload
Description
You can this command to check and reload all custom page files in the configuration. It displays the
similar error or warning messages when you commit the configuration.
View
Sample Output
request security utm web-filtering custom-page reload
user@host> request security utm web-filtering custom-page reload

No such file cust_page1.html
The size of this page file (cust_page2.html) exceeds the limit, the maximum size is 2k bytes.
Custom page reload result: Reload Complete
Release Information
818
show configuration smtp
IN THIS SECTION
Syntax | 818
Description | 818
Options | 818
Output Fields | 819
Sample Output | 819
Syntax
Description
Display complete SMTP information.
Options
• apply-groups—Groups from which SMTP inherits configuration data.
• apply-groups-except—Groups from which SMTP restricts inheriting configuration data.

819
view
Output Fields
Table 9 on page 819 describes the output fields for the show configuration smtp command.
Table 9: show configuration smtp
Field Name Field Description Level of Output
address SMTP server's IPv4 address All levels
login Configure a mail sender account to the server All levels
password Default sender password for user authentication All levels
Sample Output
user@host> show configuration smtp

primary-server {
address 218.102.48.213;
login "dayone@example.com" {
password "$ABC123"; ## SECRET-DATA
}
}
820
Release Information
utm | 748
show groups junos-defaults
IN THIS SECTION
Syntax | 820
Description | 820
Syntax
show groups junos-defaults
Description
Display the full set of available preset statements from the defaults group.
user@host# show groups junos-defaults

groups {
junos-defaults {
applications {
821
# File Transfer Protocol

application junos-ftp {
application-protocol ftp;
protocol tcp;
destination-port 21;
}
# Trivial File Transfer Protocol
application junos-tftp {
application-protocol tftp;
protocol udp;
}
# RPC port mapper on TCP
application junos-rpc-portmap-tcp {
application-protocol rpc-portmap;
protocol tcp;
}
# RPC port mapper on UDP
}
}
}
view
Release Information
Command introduced before Junos OS Release 7.4.
Using Defaults Groups

822
show security log
IN THIS SECTION
Syntax | 822
Description | 822
Options | 822
Output Fields | 823
Sample Output | 824
Syntax
show security log {all| destination-address| destination-port| event-id| failure|interface-name|

newer-than| older-than| process| protocol|report| severity| sort-by| source-address| source-
port| success| user}
Description
Display security event logs. This command continuously displays security events on the screen. To stop
the display, press Ctrl+c.
Options
all Display all audit event logs stored in the device memory.
destination-address Display audit event logs with the specified destination address.
823
destination-port Display audit event logs with the specified destination port.
event-id Display audit event logs with the specified event identification number.
failure Display failed audit event logs.
interface-name Display audit event logs with the specified interface.
newer-than Display audit event logs newer than the specified date and time.
older-than Display audit event logs older than the specified date and time.
process Display audit event logs with the specified process that generated the event.
protocol Display audit event logs generated through the specified protocol.
report Display on-box reports for system traffic logs.
severity Display audit event logs generated with the specified severity.
sort-by Display audit event logs generated sorted with the specified options.
source-address Display audit event logs with the specified source address.
source-port Display audit event logs with the specified source port.
success Display successful audit event logs.
username Display audit event logs generated for the specified user.
view
Output Fields
Table 10 on page 824 lists the output fields for the show security log command. Output fields are listed
in the approximate order in which they appear.
824
Table 10: show security log Output Fields
Field Name Field Description
Event time The timestamp of the events received.
Security logs were always timestamped using the UTC time zone by running
set system time-zone utc and set security log utc-timestamp CLI commands.
Now, time zone can be defined using the local time zone by running the set
system time-zone time-zone command to specify the local time zone that the
system should use when timestamping the security logs.
Message Security events are listed.
Sample Output
show security log
user@host> show security log

Event time Message
2010-10-22 13:28:37 CST session created 1.1.1.2/1-->2.2.2.2/1308
icmp 1.1.1.2/1-->2.2.2.2/1308
None None 1 policy1 trustZone untrustZone 52 N/A(N/A) ge-0/0/1.0
2010-10-22 13:28:38 CST session created 1.1.1.2/1-->2.2.2.2/1308 icmp 1.1.1.2/1-->2.2.2.2/1308
None None 1 policy1 trustZone untrustZone 54 N/A(N/A) ge-0/0/1.0
...
2010-10-22 13:36:12 CST session denied m icmp 1(8) policy1 trustZone untrustZone N/A(N/A)
ge-0/0/1.0
2010-10-22 13:36:14 CST session denied 1.1.1.2/2-->2.2.2.2/54812 icmp 1(8) policy1 trustZone
untrustZone N/A(N/A) ge-0/0/1.0
...
2010-10-27 15:50:11 CST IP spoofing! source: 2.2.2.20, destination: 2.2.2.2, protocol-id: 17,
zone name: trustZone, interface name: ge-0/0/1.0, action: drop
2010-10-27 15:50:11 CST IP spoofing! source: source: 2.2.2.20, destination: 2.2.2.2, protocol-
id: 17, zone name: trustZone, interface name: ge-0/0/1.0, action: drop
825
...
2011-02-18 15:53:34 CST PKID_PV_OBJECT_READ: A PKI object was read into memory from /var/db/
certs/common/certification-authority/ca-profile1-ca1.cert
certs/common/crl/ca-profile1.crl
certs/system-key-pair/system-generated.priv
certs/system-cert/system-generated.cert
certs/common/key-pair/cert1.priv
certs/common/key-pair/test2.priv
...
2011-03-14 23:00:40 PDT IDP_COMMIT_COMPLETED: IDP policy commit is complete.
IDP_POLICY_LOAD_FAILED: IDP policy loading failed ;poli
cy[/var/db/idpd/bins/.bin.gz.v], detector[/usr/libdata/libidp-detector.so.tgz.v]
,failure detail[Policy loading failed :: Policy file not found
2011-03-14 23:00:58 PDT ]
2011-03-14 23:00:58 PDT ]
2011-03-14 23:00:58 PDT ]
...
Event time Message
2011-03-21 14:21:49 CST UI_CMDLINE_READ_LINE: User 'root', command 'set date ntp 9.9.9.1 source-
address 6.6.6.1 '
address 6.6.6.1 .5 '
2011-03-21 14:23:05 CST KMD_PM_SA_ESTABLISHED: Local gateway: 7.7.7.1, Remote gateway: 8.8.8.1,
Local ID: ipv4(any:0,[0..3]=6.6.6.1), Remote ID: ipv4(any:0,[0..3]=9.9.9.1), Direction: inbound,
SPI: 37a2a179, AUX-SPI: 0, Mode: tunnel, Type: dynamic
2011-03-21 14:23:05 CST KMD_PM_SA_ESTABLISHED: Local gateway: 7.7.7.1, Remote gateway: 8.8.8.1,
Local ID: ipv4(any:0,[0..3]=6.6.6.1), Remote ID: ipv4(any:0,[0..3]=9.9.9.1), Direction:
outbound, SPI: b2231c1f, AUX-SPI: 0, Mode: tunnel, Type: dynamic
826
address 6.6.6.1 '

2011-03-21 14:23:13 CST UI_CMDLINE_READ_LINE: User 'root', command 'show security log '
Release Information
exclude (Security Log)

clear security log
show security policies
IN THIS SECTION
Syntax | 826
Description | 827
Options | 827
Output Fields | 828
Sample Output | 834
Syntax

<checksum>
827
<count>
<detail>
<from-zone zone-name>
<global>
<hit-count>
<information>
<logical-system logical-system-name>
<policy-name policy-name>
<service-set>
<start>
<tenant tenant-name>
<to-zone zone-name>
<unknown-source-identity>
<zone-context>
Description
Displays a summary of all security policies configured on the device. If a particular policy is specified,
display information specific to that policy. The existing show commands for displaying the policies
configured with multiple tenant support are enhanced. A security policy controls the traffic flow from
one zone to another zone. The security policies allow you to deny, permit, reject (deny and send a TCP
RST or ICMP port unreachable message to the source host), encrypt and decrypt, authenticate,
prioritize, schedule, filter, and monitor the traffic attempting to cross from one security zone to another.
Options
• all-logical-systems-tenants—Displays all multitenancy systems.
• checksum—Displays the policy information checksum.
• count—Displays the number of policies to show. Range is 1 through 65,535.
• detail—(Optional) Displays a detailed view of all of the policies configured on the device.
• from-zone—Displays the policy information matching the given source zone.
• global—(Optional) Displays the policy information about global policies.
• hit-count—Displays the policies hit count.

828
• information—Displays the policy information.
• logical-system—Displays the logical system name.
• policy-name—(Optional) Displays the policy information matching the given policy name.
• root-logical-system—Displays root logical system as default.
• service-set—Displays the name of the service set.
• start—Displays the policies from a given position. Range is 1 through 65,535.
• tenant—Displays the name of the tenant system.
• to-zone—Displays the policy information matching the given destination zone.
• unknown-source-identity—Displays the unknown-source-identity of a policy.
• zone-context—Displays the count of policies in each context (from-zone and to-zone).
view
Output Fields
Table 11 on page 828 lists the output fields for the show security policies command. Output fields are
listed in the approximate order in which they appear.
Table 11: show security policies Output Fields
From zone Name of the source zone.
To zone Name of the destination zone.
Policy-name Name of the applicable policy.

829
Table 11: show security policies Output Fields (Continued)
Description Description of the applicable policy.
State Status of the policy:
• enabled: The policy can be used in the policy lookup process, which
determines access rights for a packet and the action taken in regard to it.
• disabled: The policy cannot be used in the policy lookup process, and
therefore it is not available for access control.
Index Internal number associated with the policy.
Sequence number Number of the policy within a given context. For example, three policies that
are applicable in a from-zoneA-to-zoneB context might be ordered with
sequence numbers 1, 2, 3. Also, in a from-zoneC-to-zoneD context, four
policies might have sequence numbers 1, 2, 3, 4.
Source addresses For standard display mode, the names of the source addresses for a policy.
Address sets are resolved to their individual names.
For detail display mode, the names and corresponding IP addresses of the
source addresses for a policy. Address sets are resolved to their individual
address name-IP address pairs.
Destination addresses Name of the destination address (or address set) as it was entered in the
destination zone’s address book. A packet’s destination address must match
this value for the policy to apply to it.
source-end-user-profile Name of the device identity profile (referred to as end-user-profile in the CLI)
that contains attributes, or characteristics of a device. Specification of the
device identity profile in the source-end-user-profile field is part of the device
identity feature. If a device matches the attributes specified in the profile and
other security policy parameters, then the security policy’s action is applied to
traffic issuing from the device.
Source addresses (excluded) Name of the source address excluded from the policy.
830
Destination addresses Name of the destination address excluded from the policy.
(excluded)
Source identities One or more user roles specified for a policy.
Applications Name of a preconfigured or custom application whose type the packet

matches, as specified at configuration time.
• IP protocol: The Internet protocol used by the application—for example,

TCP, UDP, ICMP.
• ALG: If an ALG is explicitly associated with the policy, the name of the ALG
is displayed. If application-protocol ignore is configured, ignore is
displayed. Otherwise, 0 is displayed.
However, even if this command shows ALG: 0, ALGs might be triggered for
packets destined to well-known ports on which ALGs are listening, unless
ALGs are explicitly disabled or when application-protocol ignore is not
configured for custom applications.
• Inactivity timeout: Elapsed time without activity after which the

application is terminated.
• Source port range: The low-high source port range for the session
application.
Source identity feeds Name of a source identity (user name) added as match criteria
Destination identity feeds Name of a destination identity (user name) added as match criteria
Dynamic Applications Application identification-based Layer 7 dynamic applications.

831
Destination Address Translation Status of the destination address translation traffic:
• drop translated—Drop the packets with translated destination addresses.
• drop untranslated—Drop the packets without translated destination

addresses.
Application Firewall An application firewall includes the following:
• Rule-set—Name of the rule set.
• Rule—Name of the rule.
• Dynamic applications—Name of the applications.
• Dynamic application groups—Name of the application groups.
• Action—The action taken with respect to a packet that matches the

application firewall rule set. Actions include the following:
• permit
• deny
• Default rule—The default rule applied when the identified application is

not specified in any rules of the rule set.
832
Action or Action-type • The action taken for a packet that matches the policy’s tuples. Actions
• permit
• feed
• firewall-authentication
• tunnel ipsec-vpn vpn-name
• pair-policy pair-policy-name
• source-nat pool pool-name
• pool-set pool-set-name
• interface
• destination-nat name
• deny
• reject
• services-offload
Session log Session log entry that indicates whether the at-create and at-close flags were
set at configuration time to log session information.
Scheduler name Name of a preconfigured scheduler whose schedule determines when the
policy is active and can be used as a possible match for traffic.
833
Policy statistics • Input bytes—The total number of bytes presented for processing by the
device.
• Initial direction—The number of bytes presented for processing by

the device from the initial direction.
• Reply direction—The number of bytes presented for processing by the

device from the reply direction.
• Output bytes—The total number of bytes actually processed by the device.
• Initial direction—The number of bytes from the initial direction

actually processed by the device.
• Reply direction—The number of bytes from the reply direction actually

processed by the device.
• Input packets—The total number of packets presented for processing by

the device.
• Initial direction—The number of packets presented for processing by

the device from the initial direction.
• Reply direction—The number of packets presented for processing by

the device from the reply direction.
• Output packets—The total number of packets actually processed by the

device.
• Initial direction—The number of packets actually processed by the

device from the initial direction.
• Reply direction—The number of packets actually processed by the

device from the reply direction.
• Session rate—The total number of active and deleted sessions.
• Active sessions—The number of sessions currently present because of

access control lookups that used this policy.
• Session deletions—The number of sessions deleted since system startup.
• Policy lookups—The number of times the policy was accessed to check for
a match.
834
dynapp-redir-profile Displays unified policy redirect profile. See profile(dynamic-application).
Per policy TCP Options Configured syn and sequence checks, and the configured TCP MSS value for
the initial direction, the reverse direction or, both.
Feed Feeds details added in the security policy. The supported feeds are:
• add-source-ip-to-feed
• add-destination-ip-to-feed
• add-source-identity-to-feed
• add-destination-identity-to-feed
Sample Output
user@host> show security policies
From zone: trust, To zone: untrust

Policy: p1, State: enabled, Index: 4, Sequence number: 1
Source addresses:
sa-1-ipv4: 198.51.100.11/24
sa-2-ipv6: 2001:db8:a0b:12f0::1/32
sa-3-ipv6: 2001:db8:a0b:12f0::22/32
sa-4-wc: 203.0.113.1/255.255.0.255
Destination addresses:
da-1-ipv4: 10.2.2.2/24
da-2-ipv6: 2001:db8:a0b:12f0::8/32
da-3-ipv6: 2001:db8:a0b:12f0::9/32
da-4-wc: 192.168.22.11/255.255.0.255
Source identities: role1, role2, role4
Applications: any
835
Action: permit, application services, log, scheduled

Application firewall : my_ruleset1
Policy: p2, State: enabled, Index: 5, Sequence number: 2
Source addresses:
sa-1-ipv4: 198.51.100.11/24
sa-2-ipv6: 2001:db8:a0b:12f0::1/32
sa-3-ipv6: 2001:db8:a0b:12f0::22/32
da-1-ipv4: 10.2.2.2/24
da-2-ipv6: 2001:db8:a0b:12f0::1/32
da-3-ipv6: 2001:db8:a0b:12f0::9/32
Source identities: role1, role4
Applications: any
Action: deny, scheduled
show security policies (Dynamic Applications)
user@host>show security policies
Policy: p1, State: enabled, Index: 4, Scope Policy: 0, Sequence number: 1

Applications: any
Dynamic Applications: junos:YAHOO
Action: deny, log
Applications: any
Dynamic Applications: junos:web, junos:web:social-networking:facebook,
junos:TFTP, junos:QQ
Action: permit, log
Applications: any
Dynamic Applications: junos:HTTP, junos:SSL
Action: permit, application services, log
836
The following example displays the output with unified policies configured.
Default policy: deny-all

Pre ID default policy: permit-all
Applications: junos-defaults
Dynamic Applications: junos:GMAIL, junos:FACEBOOK-CHAT
dynapp-redir-profile: profile1
show security policies policy-name p2
user@host> show security policies policy-name p2

From zones: any
To zones: any
Source vrf group: any
Destination vrf group: any
Applications: any
Dynamic Applications: any
Action: permit, application services, feed
show security policies policy-name detail
user@host> show security policies policy-name p2 detail
Policy: p2, action-type: permit, State: enabled, Index: 4, Scope Policy: 0

Policy Type: Configured, global
Sequence number: 1
From zones:
any
To zones:
any
837
Source vrf group:

any
Destination vrf group:
any
Source addresses:
any-ipv4(global): 0.0.0.0/0
any-ipv6(global): ::/0
Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination ports: [0-0]
Dynamic Application:
any: 0
Per policy TCP Options: SYN check: No, SEQ check: No, Window scale: No
Intrusion Detection and Prevention: disabled
Unified Access Control: disabled
Feed: add-source-ip-to-feed

Description: The policy p1 is for the sales team
Sequence number: 1
Source addresses:
sa-1-ipv4: 198.51.100.11/24
sa-2-ipv6: 2001:db8:a0b:12f0::1/32
sa-3-ipv6: 2001:db8:a0b:12f0::9/32
sa-4-wc: 203.0.113.1/255.255.0.255
da-1-ipv4: 192.0.2.0/24
da-2-ipv6: 2001:db8:a0b:12f0::1/32
da-3-ipv6: 2001:db8:a0b:12f0::9/32
da-4-wc: 192.168.22.11/255.255.0.255
Source identities:
role1
role2
role4
Application: any
838

Destination port range: [0-0]
Destination Address Translation: drop translated
Application firewall :
Rule-set: my_ruleset1
Rule: rule1
Dynamic Applications: junos:FACEBOOK-ACCESS, junos:YMSG
Dynamic Application groups: junos:web, junos:chat
Action: deny
Default rule: permit
Session log: at-create, at-close
Scheduler name: sch20
Per policy TCP Options: SYN check: No, SEQ check: No
Policy statistics:
Input bytes : 18144 545 bps
Initial direction: 9072 272 bps
Reply direction : 9072 272 bps
Output bytes : 18144 545 bps
Input packets : 216 6 pps
Output packets : 216 6 pps
Session rate : 108 3 sps
Active sessions : 93
Session deletions : 15
Policy lookups : 108
show security policies (Services-Offload)
Policy: p1, action-type: reject, State: enabled, Index: 4, Scope Policy: 0

Policy Type: Configured
Sequence number: 1
From zone: trust, To zone: trust
Source addresses:
839
Application: any
dynapp-redir-profile: profile1(1)
show security policies (Device Identity)

Policy: dev-id-marketing, State: enabled, Index: 5, Scope Policy: 0, Sequence number: 1
source-end-user-profile: marketing-profile
Applications: any
Action: permit
show security policies detail
user@host> show security policies detail

Policy: p1, action-type: permit, services-offload:enabled , State: enabled, Index: 4, Scope
Policy: 0
Sequence number: 1
Source addresses:
Source identities:
840
role1
role2
role4
Application: any
Policy statistics:
Active sessions : 93
Session deletions : 15
Policy lookups : 108
Policy: p2, action-type: permit, services-offload:enabled , State: enabled, Index: 5, Scope
Policy: 0
Sequence number: 1
From zone: untrust, To zone: trust
Source addresses:
Source identities:
role1
role2
role4
Application: any
841

The following example displays the output with unified policies configured.
user@host> show security policies detail

Policy: p2, action-type: reject, State: enabled, Index: 4, Scope Policy: 0
Sequence number: 1
Source addresses:
Application: junos-defaults
842

Dynamic Application:
junos:FACEBOOK-CHAT: 10704
junos:GMAIL: 51
dynapp-redir-profile: profile1(1)
show security policies detail (TCP Options)

node0:
--------------------------------------------------------------------------
Policy:p2, action-type:permit, State: enabled,Index: 4, Scope Policy: 0
Sequence number: 1
From zone: trust, To zone: trust
Source addresses:
843
Application: junos-defaults
IP protocol: tcp, ALG: 0, Inactivity timeout: 0
Dynamic-application: junos:HTTP
show security policies policy-name (Negated Address)

node0:
--------------------------------------------------------------------------
Source addresses(excluded): as1
Destination addresses(excluded): as2
Applications: any
Action: permit
show security policies policy-name detail (Negated Address)

node0:
--------------------------------------------------------------------------
Sequence number: 1
Source addresses(excluded):
ad1(ad): 255.255.255.255/32
ad2(ad): 198.51.100.1/24
ad3(ad): 198.51.100.6 ~ 198.51.100.56
ad4(ad): 192.0.2.8/24
ad5(ad): 198.51.100.99 ~ 198.51.100.199
ad6(ad): 203.0.113.9/24
ad7(ad): 203.0.113.23/24
Destination addresses(excluded):
ad13(ad2): 198.51.100.76/24
ad12(ad2): 198.51.100.88/24
844
ad11(ad2): 192.0.2.23 ~ 192.0.2.66

ad10(ad2): 192.0.2.93
ad9(ad2): 203.0.113.76 ~ 203.0.113.106
ad8(ad2): 203.0.113.199
Application: any
show security policies global
user@host> show security policies global policy-name Pa

node0:
--------------------------------------------------------------------------
Global policies:
Policy: Pa, State: enabled, Index: 6, Scope Policy: 0, Sequence number: 1
From zones: any
To zones: any
Source addresses: H0
Destination addresses: H1
Applications: junos-http
Action: permit
show security policies detail tenant
user@host> show security policies detail tenant TN1

Sequence number: 1
Application: junos-ping
ICMP Information: type=255, code=0
845
Application: junos-telnet
IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
Application: app_udp
IP protocol: udp, ALG: 0, Inactivity timeout: 1800
Application: junos-icmp6-all
ICMP Information: type=255, code=0
Session log: at-create, at-close
Policy statistics:
Active sessions : 0
Session deletions: 0
Policy lookups : 0
show security policies (threat profile feeds)

Source vrf group: any
Destination vrf group: any
846
Applications: any
Source identity feeds: user_feed_1, user_feed_2
Destination identity feeds: user_feed_3, user_feed_4
Action: permit, application services, feed
show security policies detail (threat profile feeds)

Sequence number: 2
Source vrf group:
any
Destination vrf group:
any
Source addresses:
any-ipv4(bob_addrbook_1): 0.0.0.0/0
any-ipv6(bob_addrbook_1): ::/0
any-ipv4(bob_addrbook_1): 0.0.0.0/0
any-ipv6(bob_addrbook_1): ::/0
Application: any
Destination ports: [0-0]
Source identity feeds:
user_feed_1
user_feed_2
Destination identity feeds:
user_feed_3
user_feed_4
Intrusion Detection and Prevention: disabled
Unified Access Control: disabled
Feed: add-source-ip-to-feed
Feed: add-destination-ip-to-feed
Feed: add-source-identity-to-feed
Feed: add-destination-identity-to-feed
847
Release Information
Command modified in Junos OS Release 9.2.
Support for IPv6 addresses is added in Junos OS Release 10.2.
Support for wildcard addresses is added in Junos OS Release 11.1.
Support for global policy and services offloading is added in Junos OS Release 11.4.
Support for source-identities and the Description output field is added in Junos OS Release 12.1.
Support for negated address added in Junos OS Release 12.1X45-D10.
The output fields for Policy Statistics expanded, and the output fields for the global and policy-name
options are expanded to include from-zone and to-zone global match criteria in Junos OS Release
12.1X47-D10.
Support for the initial-tcp-mss and reverse-tcp-mss options is added in Junos OS Release 12.3X48-D20.
Output field and description for source-end-user-profile option is added in Junos OS Release 15.1x49-
D70.
Output field and description for dynamic-applications option is added in Junos OS Release 15.1x49-D100.
Output field and description for dynapp-redir-profile option is added in Junos OS Release 18.2R1.
The tenant option is introduced in Junos OS Release 18.3R1.
The <all-logical-systems-tenants> option is introduced in Junos OS Release 18.4R1.
The information option is introduced in Junos OS Release 18.4R1.
The checksum option is introduced in Junos OS Release 18.4R1.

Unified Policies Configuration Overview
848
show security utm anti-spam statistics
IN THIS SECTION
Syntax | 848
Description | 848
Options | 849
Sample Output | 849
Syntax

Description
Displays antispam statistics for connections including total e-mail scanned, tagged, and dropped
connections.
Statistics from both the nodes (with full chassis cluster support for UTM) are displayed.
Starting in Junos OS Release 18.2R1, on SRX5000 Series devices, the options pic and fpc to view the
physical interface cards (PICs) and Flexible PIC Concentrator (FPC) statistics are not supported.
Starting in Junos OS Release 18.3R1, you can view the antispam statistics for the primary logical system
or for a specific user logical system or for all the user logical systems.
Starting in Junos OS Release 19.2R1, you can view the antispam statistics for the tenant system.
849
Options
none Displays antispam statistics for the primary logical system.
root-logical-system (Optional) Displays antispam statistics for the primary logical system.
logical-system logical-system- (Optional) Displays antispam statistics for a specific user logical
name system.
all (Optional) Displays antispam statistics for all the user logical systems.
<all-logical-systems- (Optional) Displays antispam statistics for all the logical systems and tenant
tenants> systems.
tenant tenant-name (Optional) Displays antispam statistics for a specific tenant system.
all (Optional) Displays antispam statistics for all the tenant systems.
view
Sample Output
user@host> show security utm anti-spam statistics

Total connections: 0
Denied connections: 0
Total greetings: 0
Denied greetings: 0
Total e-mail scanned: 0
White list hit: 0
Black list hit: 0
Spam total: 0
Spam tagged: 0
850
Spam dropped: 0
DNS errors: 0
Timeout errors: 0
Return errors: 0
Invalid parameter errors: 0
show security utm anti-spam statistics root-logical-system
user@host> show security utm anti-spam statistics root-logical-system

UTM Anti Spam statistics:
Total greetings: 0
Denied greetings: 0
White list hit: 0
Black list hit: 0
Spam total: 0
Spam tagged: 0
Spam dropped: 0
DNS errors: 0
Timeout errors: 0
Return errors: 0
show security utm anti-spam statistics logical-system LSYS1
user@host> show security utm anti-spam statistics logical-system LSYS1

Total greetings: 0
Denied greetings: 0
White list hit: 0
Black list hit: 0
Spam total: 0
Spam tagged: 0
851
Spam dropped: 0
DNS errors: 0
Timeout errors: 0
Return errors: 0
show security utm anti-spam statistics logical-system all
user@host> show security utm anti-spam statistics logical-system all

Total greetings: 0
Denied greetings: 0
White list hit: 0
Black list hit: 0
Spam total: 0
Spam tagged: 0
Spam dropped: 0
DNS errors: 0
Timeout errors: 0
Return errors: 0
show security utm anti-spam statistics tenant TSYS1
user@host> show security utm anti-spam statistics tenant TSYS1

Total greetings: 0
Denied greetings: 0
White list hit: 0
Black list hit: 0
Spam total: 0
Spam tagged: 0
852
Spam dropped: 0
DNS errors: 0
Timeout errors: 0
Return errors: 0
show security utm anti-spam statistics tenant all
user@host> show security utm anti-spam statistics tenant all

Total greetings: 0
Denied greetings: 0
White list hit: 0
Black list hit: 0
Spam total: 0
Spam tagged: 0
Spam dropped: 0
DNS errors: 0
Timeout errors: 0
Return errors: 0
show security utm anti-spam statistics all-logical-systems-tenants
user@host> show security utm anti-spam statistics all-logical-systems-tenants

Total greetings: 0
Denied greetings: 0
White list hit: 0
Black list hit: 0
Spam total: 0
Spam tagged: 0
853
Spam dropped: 0
DNS errors: 0
Timeout errors: 0
Return errors: 0
Release Information

show security utm anti-spam status
IN THIS SECTION
Syntax | 854
Description | 854
Output Fields | 854

854
Syntax
Description
Display antispam status for connections including allowlist and blocklist server information. Status of
both the nodes (with full chassis cluster support for UTM) is displayed.
view
Output Fields
Output fields are listed in the approximate order in which they appear.
command-name
user@host> show security utm anti-spam status

DNS Server:
855
Release Information

show security utm anti-virus statistics
IN THIS SECTION
Syntax | 855
Description | 856
Options | 856
Sample Output | 857
Syntax

856

<fpc <fpc-slot fpc-slot pic-slot pic-slot>>
Description
Displays antivirus statistics for connections including clean and infected files, scan engine status, and
aggregated statistics from all FPCs and PICs. Statistics from both the nodes (with full chassis cluster
support for UTM) are displayed.
Starting in Junos OS Release 18.3R1, you can view the antivirus statistics for the primary logical system
or for a specific user logical system or for all the user logical systems.
Starting in Junos OS Release 19.2R1, you can view the antivirus statistics for a specific tenant system or
for all the tenant systems.
Options
none Displays antivirus statistics for the primary logical system.
root-logical-system (Optional) Displays antivirus statistics for the primary logical system.
logical-system logical-system- (Optional) Displays antivirus statistics for a specific user logical
name system.
all (Optional) Displays antivirus statistics for all the user logical systems.
all-logical-systems-tenants (Optional) Displays antivirus statistics for all the logical systems and tenant
systems.
tenant tenant-name (Optional) Displays antivirus statistics for a specific tenant system.
all (Optional) Displays antispam statistics for all the tenant systems.
857
view
Sample Output
user@host> show security utm anti-virus statistics

Scan Request:

0 0 0 0
Fallback:
Timeout: 0 0 0
Others: 0 0 0
show security utm anti-virus statistics fpc
user@host> show security utm anti-virus statistics fpc
fpc-slot 5 pic-slot 0
Scan Request:

0 0 0 0
858
Fallback:
Timeout: 0 0 0
Others: 0 0 0
show security utm anti-virus statistics fpc fpc-slot 5 pic-slot 0
user@host> show security utm anti-virus statistics fpc fpc-slot 5 pic-slot 0

Scan Request:

0 0 0 0
Fallback:
Timeout: 0 0 0
Others: 0 0 0
show security utm anti-virus statistics root-logical-system
user@host> show security utm anti-virus statistics root-logical-system

Session abort: 0
Scan Request:

859
0 0 0 0
Fallback:
Log-and-permit Block
Engine not ready: 0 0
Out of resources: 0 0
Timeout: 0 0
Maximum content size: 0 0
Too many requests: 0 0
Others: 0 0
show security utm anti-virus statistics logical-system LSYS1
user@host> show security utm anti-virus statistics logical-system LSYS1

Session abort: 0
Scan Request:

0 0 0 0
Fallback:
Timeout: 0 0
Others: 0 0
show security utm anti-virus statistics logical-system all
user@host> show security utm anti-virus statistics logical-system all

Session abort: 0
Scan Request:
860

0 0 0 0
Fallback:
Timeout: 0 0
Others: 0 0
show security utm anti-virus statistics tenant TSYS1
user@host> show security utm anti-virus statistics tenant TSYS1

Session abort: 0
Scan Request:

0 0 0 0
Fallback:
Timeout: 0 0
Decompress error: 0 0
Others: 0 0
show security utm anti-virus statistics tenant all
user@host> show security utm anti-virus statistics tenant all

861
Session abort: 0
Scan Request:

0 0 0 0
Fallback:
Timeout: 0 0
Others: 0 0
show security utm anti-virus statistics all-logical-systems-tenants
user@host> show security utm anti-virus statistics all-logical-systems-tenants

Session abort: 0
Scan Request:

0 0 0 0
Fallback:
Timeout: 0 0
Others: 0 0
862
Release Information
Support for Sophos Antivirus added in Junos OS Release 11.1.
Support for Flexible PIC Concentrator (FPC) and PIC status added in Junos OS Release 12.1X46-D10.
Starting in Junos OS Release 18.2R1, on SRX5000 Series devices, the options pic and fpc are deprecated
—rather than immediately removed—to provide backward compatibility.

show security utm anti-virus status
IN THIS SECTION
Syntax | 863
Description | 863
Output Fields | 863
Sample Output | 863

863
Syntax
show security utm anti-virus status <fpc <fpc-slot fpc-slot pic-slot pic-slot>>
Description
Display antivirus status for connections including clean and infected files, scan engine status, and
aggregated status from all FPCs and PICs. Status of both the nodes (with full chassis cluster support for
UTM) is displayed.
view
Output Fields
Sample Output


Update server: https://update.juniper-updates.net/AVIRA/VSRX
Last result: Downloading file failed
864
Forwarding-mode: hold
Onbox AV load flavor: running Light, configure Light
Scan engine type: avira-engine
Scan engine information: 8.3.60.28
Anti-virus signature version: 8.16.46.24
show security utm anti-virus status fpc
user@host> show security utm anti-virus status fpc


Update server: https://update.juniper-updates.net/SAV/
Forwarding-mode: continuous delivery, inline-tap
show security utm anti-virus status fpc fpc-slot 5 pic-slot 0
user@host> show security utm anti-virus status fpc fpc-slot 5 pic-slot 0

Anti-virus key expire date: license not installed

Update server: http://update.juniper-updates.net/SAV/
Pattern update status: update disabled due to no license
Anti-virus signature version: 000000_00
Forwarding-mode: continuous delivery, inline-tap
865
Refer the sample output for Avira scan engine. Support for Avira is added in 18.4R1 release.

Update server: https://update.juniper-updates.net/AVIRA/VSRX
Pattern update status: av updater is running
Last result: downloading signature files
Forwarding-mode: hold
Release Information
Support for UTM in chassis cluster added in Junos OS Release 11.4. Support for Flexible PIC
Concentrator (FPC) and PIC status added in Junos OS Release 12.1X46-D10.
Starting in Junos OS Release 18.2R1, on SRX5000 Series devices, the options pic and fpc to display PIC
and FPC statistics are not supported.

866
show security utm content-filtering statistics
IN THIS SECTION
Syntax | 866
Description | 866
Options | 867
Sample Output | 868
Syntax

<root-logical-system> utm-policy utm-policy-name;
<logical-system (logical-system-name utm-policy utm-policy-name | all)>;
<all-logical-systems-tenants>;
<tenant (tenant-name | all)>;
utm-policy utm-policy-name;
Description
Displays the content filtering statistics for connections including lists of blocked files and the reasons for
blocking. Statistics from both the nodes (with full chassis cluster support for UTM) are displayed.
Starting in Junos OS Release 18.3R1, you can view the content filtering statistics for the primary logical
system or for a specific user logical system or for all the user logical systems.
Starting in Junos OS Release 19.2R1, you can view the content filtering statistics for a specific tenant
system or for all the tenant systems.
Starting in Junos OS Release 21.4R1, we have improved the UTM content filtering efficiency by adding
pre-detect technique to detect file types accurately. This techinque allows you to create rulesets and
867
rules to define content filter criteria. This enhnacemnet is a replacement of the existing file type
detection based on file name extensions and profile based filtering on application profiles. This
command is enhnaced to display the enhnaced content filtering statistics in a UTM policy.
Options
none Displays content filtering statistics for the primary logical system.
root-logical- (Optional) Displays content filtering statistics for the primary logical system.
system
utm-policy <utm-policy-name>
Starting in Junos OS Release 21.4R1, this option is added under the root-logical-system
option, to display content filtering statistics in a specified UTM policy within the root
logical system.
logical-system (Optional) Displays content filtering statistics for a specific user logical system.
logical-
system-name utm-policy <utm-policy-name>
Starting in Junos OS Release this option is added under the root-logical-system option,
to display content filtering statistics in a specified UTM policy within the specified
logical system.
all (Optional) Displays content filtering statistics for all the user logical systems.
all-logical-systems-tenants (Optional) Displays content filtering statistics for all logical systems and
tenant systems.
tenant tenant-name (Optional) Displays content filtering statistics for a specific tenant system.
all (Optional) Displays content filtering statistics for all the tenant systems.
utm-policy <utm- Starting in Junos OS Release 21.4R1, this option is added to display content
policy-name> filtering statistics in a specified UTM policy.
view
868
Sample Output
user@host> show security utm content-filtering statistics

Content-filtering-statistic: Blocked
Base on command list: 0
Base on mime list: 0
Base on extension list: 0
ActiveX plugin: 0
Java applet: 0
EXE files: 0
ZIP files: 0
HTTP cookie: 0
Number of Rule-sets : 1
Rule-set add failures : 0
Rule-set delete failures : 0
Number of Rules : 1
Rule add failures : 0
Rule delete failures : 0
Fatal errors : 0
Malloc failures : 0
Sanity errors : 0
Malloc blocks in use : 10
show security utm content-filtering statistics utm-policy <utm-policy-name>
user@host> show security utm content-filtering statistics utm-policy pol1

Number of rules configured w.r.t application
Any : 0
http : 1
ftp : 1
smtp : 0
imap : 0
pop3 : 0
Number of times content blocked w.r.t direction
Download : 0
869
Upload : 0
Number of times content blocked w.r.t application
http : 0
ftp : 0
smtp : 0
imap : 0
pop3 : 0
Number of rules matched w.r.t action
no-action : 0
block : 0
close-client : 0
close-server : 0
close-client-server : 0
Number of times content blocked w.r.t file-type

unknown : 0
7z : 0
ace : 0
applesingle : 0
arj : 0
bzip : 0
diskdupe : 0
dos : 0
eicar : 0
elf : 0
emf : 0
eml : 0
flash : 0
gea : 0
gzip : 0
ha : 0
hlp : 0
hybris : 0
itsf : 0
java : 0
jmp : 0
jpeg : 0
lha : 0
lnk : 0
870
map : 0
mime : 0
msasf : 0
mscf : 0
msi : 0
mso : 0
ntdetect : 0
ole : 0
paquet : 0
pdf : 0
pe : 0
perl : 0
pif : 0
png : 0
rar : 0
reg : 0
rtf : 0
script : 0
sh : 0
sis : 0
spis : 0
sys : 0
tar : 0
vba : 0
wmf : 0
wsf : 0
xml : 0
xz : 0
zip : 0
show security utm content-filtering statistics root-logical-system
user@host> show security utm content-filtering statistics root-logical-system

ActiveX plugin: 0
Java applet: 0
EXE files: 0
871
ZIP files: 0
HTTP cookie: 0
show security utm content-filtering statistics root-logical-system utm-policy <utm-policy-

name> (Commands to display CF statistics in a UTM policy within a root-logical-system)
user@host> show security utm content-filtering statistics root-logical-system utm-policy pol1

Any : 0
http : 1
ftp : 1
smtp : 0
imap : 0
pop3 : 0
Download : 0
Upload : 0
http : 0
ftp : 0
smtp : 0
imap : 0
pop3 : 0
no-action : 0
block : 0
close-client : 0
close-server : 0
unknown : 0
dos : 0
872
pe1 : 0
pe2 : 0
shockwave : 0
jpeg : 0
elf : 0
hlp : 0
java : 0
ole2 : 0
ole2-inverted : 0
sh : 0
perl1 : 0
perl2 : 0
itsf : 0
reg : 0
pdf : 0
wsf : 0
mime : 0
zip : 0
lnk : 0
vba : 0
xml : 0
ms-asf : 0
script-file : 0
script-file2 : 0
eicar : 0
ntdetect : 0
decrypt-hybris-plugin : 0
decrypt-hybris-plugin2 : 0
png : 0
wmf : 0
wmf2 : 0
emf : 0
map : 0
jmp : 0
ace : 0
lha : 0
paquet : 0
applesingle : 0
bzip : 0
diskdupe : 0
rtf : 0
gea : 0
gzip : 0
873
mso : 0
sis : 0
spis : 0
tar : 0
arj : 0
ha : 0
rar : 0
zip-pk : 0
mscf : 0
msi : 0
pif : 0
hybris-plugin : 0
dos-full-scan : 0
script-file-full-scan : 0
swf : 0
swf-cws : 0
sys : 0
eml : 0
7z : 0
xz : 0
show security utm content-filtering statistics logical-system LSYS1
user@host> show security utm content-filtering statistics logical-system LSYS1

ActiveX plugin: 0
Java applet: 0
EXE files: 0
ZIP files: 0
HTTP cookie: 0
show security utm content-filtering statistics logical-system <logical-system-name> utm-

policy <utm-policy-name>
user@host> show security utm content-filtering statistics root-logical-system utm-policy pol1

874
Any : 0
http : 1
ftp : 1
smtp : 0
imap : 0
pop3 : 0
Download : 0
Upload : 0
http : 0
ftp : 0
smtp : 0
imap : 0
pop3 : 0
no-action : 0
block : 0
close-client : 0
close-server : 0
unknown : 0
dos : 0
pe1 : 0
pe2 : 0
shockwave : 0
jpeg : 0
elf : 0
hlp : 0
java : 0
ole2 : 0
ole2-inverted : 0
sh : 0
875
perl1 : 0
perl2 : 0
itsf : 0
reg : 0
pdf : 0
wsf : 0
mime : 0
zip : 0
lnk : 0
vba : 0
xml : 0
ms-asf : 0
script-file : 0
script-file2 : 0
eicar : 0
ntdetect : 0
decrypt-hybris-plugin : 0
decrypt-hybris-plugin2 : 0
png : 0
wmf : 0
wmf2 : 0
emf : 0
map : 0
jmp : 0
ace : 0
lha : 0
paquet : 0
applesingle : 0
bzip : 0
diskdupe : 0
rtf : 0
gea : 0
gzip : 0
mso : 0
sis : 0
spis : 0
tar : 0
arj : 0
ha : 0
rar : 0
zip-pk : 0
mscf : 0
msi : 0
876
pif : 0
hybris-plugin : 0
dos-full-scan : 0
script-file-full-scan : 0
swf : 0
swf-cws : 0
sys : 0
eml : 0
7z : 0
xz : 0
show security utm content-filtering statistics logical-system all
user@host> show security utm content-filtering statistics logical-system all

ActiveX plugin: 0
Java applet: 0
EXE files: 0
ZIP files: 0
HTTP cookie: 0
show security utm content-filtering statistics tenant TSYS1
user@host> show security utm content-filtering statistics tenant TSYS1

ActiveX plugin: 0
Java applet: 0
EXE files: 0
ZIP files: 0
HTTP cookie: 0
877
show security utm content-filtering statistics tenant all
user@host> show security utm content-filtering statistics tenant all

ActiveX plugin: 0
Java applet: 0
EXE files: 0
ZIP files: 0
HTTP cookie: 0
show security utm content-filtering statistics all-logical-systems-tenants
user@host> show security utm content-filtering statistics all-logical-systems-tenants

ActiveX plugin: 0
Java applet: 0
EXE files: 0
ZIP files: 0
HTTP cookie: 0
Release Information
Starting in Junos OS Release 18.2R1, on SRX5000 Series devices, the options pic and fpc to display

878
Starting in Junos OS Release 21.4R1, This command is enhnaced to display the enhnaced content
filtering statistics in a UTM policy.
show security utm session
IN THIS SECTION
Syntax | 878
Description | 878
Output Fields | 879
Syntax
Description
Display general UTM session information including all allocated sessions and active sessions. Also,
display information from both nodes in a chassis cluster.
879
view
Output Fields
command-name
user@host> show security utm session

Maximum sessions: 4000
Total allocated sessions: 0
Total freed sessions: 0
Active sessions: 0
Release Information
Starting in Junos OS Release 18.2R1, on SRX5000 Series devices, the options pic and fpc to display

880
show security utm status
IN THIS SECTION
Syntax | 880
Description | 880
Output Fields | 880
Syntax
Description
Display whether the UTM service is running or not and status of both the nodes (with full chassis cluster
support for UTM).
view
Output Fields

881
command-name
user@host> show security utm status

UTM service status: Running
Release Information

show security utm web-filtering category base-filter
IN THIS SECTION
Syntax | 882
Description | 882
Sample Output | 882

882
Syntax
Description
Show the list of predefined base filters. A base filter is an object that contains a category-action pair for
all categories defined in the category file. A base filter is a structured object, and is defined with the help
of a filter name and an array of category-action pairs. Each Enhanced Web Filtering (EWF) category has
a default action in a base filter, which is attached to the user profile to act as a backup filter. If the
categories are not configured in the user profile, the base filter takes the action. Junos OS Release
17.4R1 also supports online upgradation of base filters.
view
Sample Output
user@host> show security utm web-filtering category base-filter

Base-filter: ewf-default-filter
Enhanced_Adult_Material block
Enhanced_Business_and_Economy permit
Enhanced_Education permit
Enhanced_Government permit
Enhanced_News_and_Media permit
Enhanced_Religion permit
Enhanced_Society_and_Lifestyles permit
Enhanced_Special_Events permit
Enhanced_Information_Technology permit
Enhanced_Abortion block
883
Enhanced_Advocacy_Groups permit
Enhanced_Entertainment permit
Enhanced_Gambling block
Enhanced_Games block
Enhanced_Illegal_or_Questionable block
Enhanced_Job_Search permit
Enhanced_Shopping permit
Enhanced_Sports permit
Enhanced_Tasteless permit
Enhanced_Travel permit
Enhanced_Vehicles permit
Enhanced_Violence block
Enhanced_Weapons block
Enhanced_Drugs block
Enhanced_Militancy_and_Extremist block
Enhanced_Intolerance permit
Enhanced_Health permit
Enhanced_Website_Translation permit
Enhanced_Advertisements permit
Enhanced_User_Defined permit
Enhanced_Nudity block
Enhanced_Adult_Content block
Enhanced_Sex block
Enhanced_Financial_Data_and_Services permit
Enhanced_Cultural_Institutions permit
Enhanced_Media_File_Download permit
Enhanced_Military permit
Enhanced_Political_Organizations permit
Enhanced_General_Email permit
Enhanced_Proxy_Avoidance block
Enhanced_Search_Engines_and_Portals permit
Enhanced_Web_Hosting permit
Enhanced_Web_Chat permit
Enhanced_Hacking block
Enhanced_Alternative_Journals permit
Enhanced_Non_Traditional_Religions block
Enhanced_Traditional_Religions permit
Enhanced_Restaurants_and_Dining permit
Enhanced_Gay_or_Lesbian_or_Bisexual_Interest permit
Enhanced_Personals_and_Dating permit
Enhanced_Alcohol_and_Tobacco permit
Enhanced_Prescribed_Medications permit
884
Release Information

show security utm web-filtering category category
IN THIS SECTION
Syntax | 884
Description | 884
Sample Output | 885
Syntax
Description
Show the list of categories predefined by Websense. A category list is available on the device. This list
consists of categories, each containing a category code, a name, and a parent ID. Categories can also be
user-defined. Each category consists of a list of URLs or IP addresses. Categories are not updated
885
dynamically and are tied to the Junos OS release because they have to be compiled into the Junos OS
image. Any update in categories needs to be synchronized with the Junos OS release cycle.
NOTE: Starting with Junos OS Release 17.4R1, you can download and dynamically load new
Enhanced Web Filtering (EWF) categories. The downloading and dynamic loading of the new
EWF categories do not require a software upgrade.
view
Sample Output
user@host> show security utm web-filtering category category

Enhanced_Adult_Material
Enhanced_Business_and_Economy
Enhanced_Education
Enhanced_Government
Enhanced_News_and_Media
Enhanced_Religion
Enhanced_Society_and_Lifestyles
Enhanced_Special_Events
Enhanced_Information_Technology
Enhanced_Abortion
Enhanced_Advocacy_Groups
Enhanced_Entertainment
Enhanced_Gambling
Enhanced_Games
Enhanced_Illegal_or_Questionable
Enhanced_Job_Search
Enhanced_Shopping
Enhanced_Sports
Enhanced_Tasteless
Enhanced_Travel
886
Enhanced_Vehicles
Enhanced_Violence
Release Information

show security utm web-filtering category status
IN THIS SECTION
Syntax | 886
Description | 887
Sample Output | 887
Syntax

887
Description
Show the current running version of the downloaded category file or the status of the installed
predefined file.
view
Sample Output
user@host> show security utm web-filtering category status

Installed version: 1
Download version: 0
Update status: Done
Release Information

888
show security utm web-filtering statistics
IN THIS SECTION
Syntax | 888
Description | 888
Options | 889
Sample Output | 889
Syntax

<fpc <fpc-slot fpc-slot pic-slot pic-slot>>
Description
Displays Web filtering statistics for connections including allowlist and blocklist hits and custom
category hits. The aggregated statistics from all FPCs and PICs and statistics from both the nodes (with
full chassis cluster support for UTM) are also displayed.
Starting in Junos OS Release 18.3R1, you can view the Web filtering statistics for the primary logical
system or for a specific user logical system or for all the user logical systems.
Starting in Junos OS Release 19.2R1, you can view the Web filtering statistics for a specific tenant
system or for all the tenant systems.
889
Options
none Displays Web filtering statistics for the primary logical system.
root-logical-system (Optional) Displays Web filtering statistics for the primary logical system.
logical-system logical-system- (Optional) Displays Web filtering statistics for a specific user logical
name system.
all (Optional) Displays Web filtering statistics for all the user logical systems.
all-logical-systems- (Optional) Displays Web filtering statistics for all the logical systems and
tenants tenant systems.
tenant tenant-name (Optional) Displays Web filtering statistics for a specific tenant system.
all (Optional) Displays Web filtering statistics for all the tenant systems.
view
Sample Output

Total requests: 0
white list hit: 0
Black list hit: 0
Default action hit: 0
No license permit: 0
890

Cache hit permit: 0
Cache hit block: 0
+Safe-search rewrite: 0
Default 0 0
Timeout 0 0
Connectivity 0 0
show security utm web-filtering statistics fpc
user@host> show security utm web-filtering statistics fpc
Total requests: 0
white list hit: 0
Black list hit: 0
891
Cache hit permit: 0
Cache hit block: 0
Default 0 0
Timeout 0 0
Connectivity 0 0
show security utm web-filtering statistics fpc fpc-slot 5 pic-slot 0
user@host> show security utm web-filtering statistics fpc fpc-slot 5 pic-slot 0

Total requests: 0
white list hit: 0
Black list hit: 0
892
Cache hit permit: 0
Cache hit block: 0
Default 0 0
Timeout 0 0
Connectivity 0 0
show security utm web-filtering statistics root-logical-system
user@host> show security utm web-filtering statistics root-logical-system

893
Default 0 0
Timeout 0 0
Connectivity 0 0
show security utm web-filtering statistics logical-system LSYS1
user@host> show security utm web-filtering statistics logical-system LSYS1

Default 0 0
Timeout 0 0
Connectivity 0 0
show security utm web-filtering statistics logical-system all
user@host> show security utm web-filtering statistics logical-system all

Default 0 0
Timeout 0 0
Connectivity 0 0
show security utm web-filtering statistics tenant TSYS1
user@host> show security utm web-filtering statistics tenant TSYS1

Default 0 0
Timeout 0 0
894
Connectivity 0 0
show security utm web-filtering statistics tenant all
user@host> show security utm web-filtering statistics tenant all

Default 0 0
Timeout 0 0
Connectivity 0 0
show security utm web-filtering statistics all-logical-system-tenants
user@host> show security utm web-filtering statistics all-logical-system-tenants

Default 0 0
Timeout 0 0
Connectivity 0 0
Release Information
Support for Flexible PIC Concentrator (FPC) and PIC statistics added in Junos OS Release 12.1X46-D10.
Starting in Junos OS Release 18.2R1, on SRX5000 Series devices, the options pic and fpc are deprecated
—rather than immediately removed—to provide backward compatibility.
895

show security utm web-filtering status
IN THIS SECTION
Syntax | 895
Description | 895
Output Fields | 896
Output Fields | 896
Sample Output | 897
Syntax
show security utm web-filtering status <fpc <fpc-slot fpc-slot pic-slot pic-slot>>
Description
Display whether the Web filtering server connection is up or not. The aggregated status from all FPCs
and PICs and status of both the nodes (with full chassis cluster support for UTM) are also displayed.
896
view
Output Fields
Output Fields
Table 12 on page 896 lists the output fields for the show security utm web-filtering status command.
Table 12: show security utm web-filtering status
Connectivity status Status of the connection:
• UP
• DOWN
JDPI Parser Status of the JDPI parser:
• Enabled: When the performance-mode is not configured at the [edit security utm default-
configuration web-filtering] hierarchy level.
• Disabled: When the performance-mode is configured at the [edit security utm default-
configuration web-filtering] hierarchy level.
Server status Status of the Web filtering server.

897
Sample Output

JDPI Parser: Enabled
show security utm web-filtering status fpc
user@host> show security utm web-filtering status fpc

UTM web-filtering status fpc:
Connectivity status: UP
show security utm web-filtering status fpc fpc-slot 5 pic-slot 0
user@host> show security utm web-filtering status fpc fpc-slot 5 pic-slot 0

show security utm web-filtering chassis cluster status
{primary:node0}
node0:
--------------------------------------------------------------------------
node1:
--------------------------------------------------------------------------
898

Server status: Juniper Enhanced using Websense server DOWN
Starting with 12.3X48-D10 and Junos OS Release 17.3R1, on SRX210, SRX220, SRX240, SRX300,
SRX320, SRX340, SRX345, and SRX550M devices, the UTM process has been moved to the Packet
Forwarding Engine (PFE). Starting with 12.1X46-D10 and Junos OS Release 17.3R1, on SRX1400,
SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600, SRX5400, and SRX5600 devices, the
UTM process has been moved to the PFE. Hence, the status shows down on the secondary node of the
cluster.
Release Information
Support for UTM in chassis cluster added in Junos OS Release 11.4. Support for Flexible PIC
Concentrator (FPC) and PIC status added in Junos OS Release 12.1X46-D10.
Starting in Junos OS Release 18.2R1, on SRX5000 Series devices, the options pic and fpc to display PIC
and FPC statistics are not supported.

test security utm anti-spam
IN THIS SECTION
Syntax | 899
Description | 899
Options | 899
Output Fields | 899

899
Sample Output | 900
Syntax
test security utm anti-spam ip-check <test-IP>

<test-IP> test security utm anti-spam.
Description
Use this command to check if the IP (Internet Protocol) is a spam source or it is a configuration problem
when the device doesn't block the spam. The anti-spam feature requires internet connectivity with the
Spam Block List (SBL) server. Domain Name Service (DNS) must be available to access the SBL server.
Options
test-IP Supports both IPv4 and IPv6.
view
Output Fields
Table 13 on page 900 lists the output fields for the test security utm anti-spam command. Output fields
are listed in the approximate order in which they appear.
900
Table 13: test security utm anti-spam
SBL Server Spam block list (SBL) contains the list of the disallowed IPs.
DNS Server The firewall performs SBL lookups through the Domain Name Service (DNS) protocol.
Sample Output
test security utm anti-spam
The following examples test IP 1.0.0.1 in SBL server msgsecurity.juniper.net through DNS server
172.29.151.60:
user@host> test security utm anti-spam ip-check 1.0.0.1
UTM anti-spam IP-check result:
SBL Server:
msgsecurity.juniper.net
DNS Server:
172.29.151.60
Test result for IP check:

SPAM (Match sbl server blacklist)
command-name
172.29.151.60:
user@host>test security utm anti-spam ip-check 1.0.0.2

901
SBL Server:
DNS Server:
172.29.151.60

NON SPAM (No match)
command-name
172.29.151.60:
SBL Server:
DNS Server:
172.29.151.60

NON SPAM (DNS error)
command-name
172.29.151.66:
SBL Server:
902
DNS Server:
172.29.151.66

NON SPAM (Timeout error)
command-name
172.29.151.66:
SBL Server:
DNS Server:
172.29.151.66

NON SPAM (Anti-Spam is not enable)
command-name
172.29.151.66:
SBL Server:
DNS Server:
172.29.151.66
903

No license
Release Information
test security utm enhanced-web-filtering url-check
IN THIS SECTION
Syntax | 903
Description | 904
Options | 904
Output Fields | 904
Sample Output | 905
Syntax
test security utm enhanced-web-filtering url-check

test-url Enhanced-web-filtering threat-check test URL
904
Description
Use this test command to send the test-string to web-filtering server (example: Websense ThreatSeeker
Cloud) to test the category and reputation of the test-string.
Options
<test-url> Enhanced-web-filtering threat-check test URL. The maximum length of test URL is 249.
view
Output Fields
Table 14 on page 904 lists the output fields for the test security utm enhanced-web-filtering url-check
command. Output fields are listed in the approximate order in which they appear.
Table 14: test security utm enhanced-web-filtering
Enhance web-filtering server Enhanced Web Filtering (EWF) supports HTTP methods.
905
Sample Output
test security utm enhanced-web-filtering
The following example sends URL www.google.com to EWF rp.cloud.threatseeker.com check the
category and reputation:
user@host> test security utm enhanced-web-filtering url-check www.google.com
UTM enhanced-web-filtering URL-check result:
Enhance web-filtering server:

Test result for URL check:

Category name: Enhanced_Search_Engines_and_Portals
Reputation: 90
Threat level: very-safe
command-name
The following example sends URL www.aaa.com to EWF rp.cloud.threatseeker.com check the category
and reputation:
user@host>test security utm enhanced-web-filtering url-check www.aaa.com


URL does not match on remote server
906
command-name
The following example sends URL www.bbb.com to EWF rp.cloud.threatseeker.com check the category
and reputation:
user@host>test security utm enhanced-web-filtering url-check www.bbb.com


UTM enhanced web filtering URL check test failed
command-name
The following example sends URL www.bbb.com to EWF rp.cloud.threatseeker.com check the category
and reputation:
user@host>test security utm enhanced-web-filtering url-check www.bbb.com


No license
command-name
The following example sends URL www.google.com to EWF rp.cloud.threatseeker.com check the
category and reputation:
user@host>test security utm enhanced-web-filtering url-check www.google.com

907
Enhanced web-filtering server:


EWF query timeout
Release Information
test security utm web-filtering profile
IN THIS SECTION
Syntax | 907
Description | 908
Options | 908
Sample Output | 908
Syntax
test security utm web-filtering profile <profile-name>

<test-url> Web-filtering test URL
908
Description
Use this command to check if the test-string matches the specific profile in the Web filtering server.
Options
test-url Enhanced Web filtering threat-check test URL. The maximum length of test URL is 249.
view
Sample Output
test security utm web-filtering profile
The following example sends profile sportclass and test url www.google.com to the Web filtering server
to check whether the test string matches the specific profile:
user@host> test security utm web-filtering profile sportclass www.google.com
UTM web-filtering profile test:
Test result: Match EWF category

Execute action: Permit
Match category: Enhanced_Search_Engines_and_Portals
909
command-name
The following example sends profile dangerclass and test url www.gun-clubs.com to the Web filtering
server to check whether the test string matches the specific profile:
user@host> test security utm web-filtering profile dangerclass www.gun-clubs.com
Test result: Match custom category

Match category: custom_category
command-name
Test result: Hit global reputation action

Match category: N/A
command-name

910
Test result: Web filtering engine is not ready, please try again later
command-name
Test result: Can't find webfilter profile dangerclass
command-name
Test result: No license

Match category: N/A
command-name
The following example sends profile junos-wf-enhanced-default and test www.google.com to the Web
filtering server to check whether the test string matches the specific profile:
user@host> test security utm web-filtering profile junos-wf-enhanced-default www.google.com

911
Test result: Fallback (query timeout)

Execute action: Log and permit
Match category: N/A
Release Information

ACS Midterm Merged

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ACS Midterm Merged

Uploaded by

Copyright:

Available Formats

2011 International Conference on Advanced Materials Engineering

IPCSIT vol.15 (2011) © (2011) IACSIT Press, Singapore

Intrusion Detection System (IDS): Case Study

Asmaa Shaker Ashoor and Sharad Gore+

Keywords: IDS, anomaly , misuse, NID

Intrusion detection functions include:

2. Intrusion Detection Systems: A Brief History

Fig. 1: Number of incidents reported Fig. 2: Vulnerabilities reported

3. Categories of Intrusion Detection System

3.1. Signature Based Detection Systems

3.2. Anomaly based Detection System

3.3. Specification based Detection System

4. Classification of Intrusion Detection System

4.1. Host based IDS (HIDS)

4.2. Network based IDS (NIDS)

4.3. Hybrid based IDS

Fig. 3: Layered security approach for reducing network risk

MID EXAM – Nov 2022

Answer all the Questions

Q. No. Question Description Marks

• Understanding your threats

• Manage your cyber security risks

• Prepare your response

• Safeguard your organization from cyber threats and gain peace

1. Subscriber edge routers and

Guide to Intrusion Detection

Recommendations of the National Institute

Recommendations of the National

Computer Security Division

U.S. Department of Commerce

Carlos M. Gutierrez, Secretary

Robert C. Cresanti, Under Secretary of Commerce for

William Jeffrey, Director

Reports on Computer Systems Technology

National Institute of Standards and Technology Special Publication 800-94

Certain commercial entities, equipment, or materials may be identified in this

4.4.1 Implementation ...........................................................................................4-14

Appendix A— Glossary .......................................................................................................... A-1

Appendix B— Acronyms........................................................................................................ B-1

Appendix C— Tools and Resources ..................................................................................... C-1

Appendix D— Index ................................................................................................................ D-1

Figure 4-1. TCP/IP Layers ........................................................................................................4-1

Table 8-1. Comparison of IDPS Technology Types..................................................................8-1

 Security capabilities, including information gathering, logging, detection, and prevention

This page has been left blank intentionally.

1.2 Purpose and Scope

1.4 Document Structure

 Sections 4 through 7 contain detailed discussions of particular categories of IDPS technologies:

– Section 6: Network behavior analysis

2. Intrusion Detection and Prevention Principles

2.1 Uses of IDPS Technologies

2.2 Key Functions of IDPS Technologies

2.3 Common Detection Methodologies

2.3.1 Signature-Based Detection

2.3.2 Anomaly-Based Detection

2.3.3 Stateful Protocol Analysis

2.4 Types of IDPS Technologies

3.1 Components and Architecture

3.1.1 Typical Components

The typical components in an IDPS solution are as follows:

3.2 Security Capabilities

3.2.1 Information Gathering Capabilities

3.2.2 Logging Capabilities

3.2.3 Detection Capabilities

Security capabilities, including information gathering, logging, detection, and prevention

Sections 4 through 7 contain detailed discussions of particular categories of IDPS technologies:

Where the sensors or agents should be placed

Performing regular vulnerability assessments

Appliance. An appliance-based sensor is comprised of specialized hardware and sensor software.

Timestamp (usually date and time)

Prevention action performed (if any).

Types of events detected

Timestamp (usually date and time)

Types of events detected

Source and destination IP addresses

Timestamp (usually date and time)